[Import-SIG] PEP 420 issue: extend_path

Barry Warsaw barry at python.org
Thu May 10 04:22:04 CEST 2012


On May 10, 2012, at 10:55 AM, Nick Coghlan wrote:

>On Thu, May 10, 2012 at 10:41 AM, Barry Warsaw <barry at python.org> wrote:
>> On May 09, 2012, at 08:19 PM, Eric V. Smith wrote:
>>
>>>I modified the PEP to specify these as:
>>>
>>>1. (loader, None)
>>>2. (None, <sequence of strings>)
>>>3. (None, None)
>>
>> wfm.
>
>I'd prefer to keep a consistent constraint of "iterable of path
>entries" for the second value, and allow people to return a non-empty
>iterable when they're returning a loader (since it will be ignored
>anyway). See my proposed revision to PathFinder.find_module in my
>other reply.

I don't think the implementation should constrain the specification.  Rather,
what makes the most sense to someone reading the PEP, or the future language
reference?

In that respect, I think it's better to define the second item as "ignored" or
None when not-None is returned as the first element.  Requiring the return of
an empty sequence when the value is semantically ignored makes no sense.

There's also a semantic difference between returning None and returning an
empty sequence as the second element when the first element is None.  In the
matrix of return states, "(None, ())" means "I found some namespace portions,
and the number of portions I found is zero" which is clearly nonsensical, and
subtly different than "I found neither a normal package nor portions of a
namespace package."

So I still prefer the current wording of the PEP.

>I'm definitely *much* happier with the 2-tuple return format over the
>introspection based API, though :)

Yay! :)

-Barry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/import-sig/attachments/20120509/4c0bdae0/attachment.pgp>


More information about the Import-SIG mailing list