Author eric.snow
Recipients Arfrever, brett.cannon, eric.snow, ncoghlan
Date 2013-12-11.22:42:05
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1386801725.54.0.249024980997.issue19944@psf.upfronthosting.co.za>
In-reply-to
Content
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".)
History
Date User Action Args
2013-12-11 22:42:05eric.snowsetrecipients: + eric.snow, brett.cannon, ncoghlan, Arfrever
2013-12-11 22:42:05eric.snowsetmessageid: <1386801725.54.0.249024980997.issue19944@psf.upfronthosting.co.za>
2013-12-11 22:42:05eric.snowlinkissue19944 messages
2013-12-11 22:42:05eric.snowcreate