Message205937
It looks like there are two concepts at play though:
1. side-effect-free vs. may-have-side-effects
2. just-find-the-spec-dangit vs. find-the-spec-relative-to-submodule-search-locations-I-already-know
In the case of #1, providing the path is just a means to an end. In contrast, for #2 providing the path is the whole point and side effects are something to which you may not have given any thought (but you probably aren't expecting them).
In both cases, it still boils down to (module name -> module spec). To me, handling both with a single function and a keyword-only "path" parameter seems sufficient, as long as people don't miss the fact that there are side effects in the default case.
The tricky part is that this is not a high-use API, so I'm trying not to think in terms of common case. (I'm tempted to say things like "in the common case you just want the spec and you don't care about that other stuff".) |
|
Date |
User |
Action |
Args |
2013-12-11 22:42:05 | eric.snow | set | recipients:
+ eric.snow, brett.cannon, ncoghlan, Arfrever |
2013-12-11 22:42:05 | eric.snow | set | messageid: <1386801725.54.0.249024980997.issue19944@psf.upfronthosting.co.za> |
2013-12-11 22:42:05 | eric.snow | link | issue19944 messages |
2013-12-11 22:42:05 | eric.snow | create | |
|