Re: PEP 420 issue: extend_path

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

>On Thu, May 10, 2012 at 10:41 AM, Barry Warsaw <[email protected]> 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

_______________________________________________
Import-SIG mailing list
[email protected]
http://mail.python.org/mailman/listinfo/import-sig

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQIcBAEBCAAGBQJPqyZNAAoJEBJutWOnSwa/+DwP/2bVhJcoHNS8Nfy/9Tv/Z/O6
8lPcDGqFvhUj6OAo4XRjfXY7ZbkbR8vbVUM7+f+MA12KbkxAPWIU1NX7mSngc9MQ
ggYFCYxvEA+V/eNX6mOQaSYh7gAtRwSshv8Xhx8oUecV5tZAIZCF2v/SSZJwqTay
XVKdiq8il+JyNQUUEYJmG+nxfpuP5mKWt98R1t6i3gIXCJWsx2GqhB91SqtQlmpc
2EpxrcR84NirDEpd++B9SvxAUWlAyiaIpCmEnyncuLoYoVlQyhSokyof5+8ag75o
0qit8Ps8xvFbopDA4QrvEmYiksvp6QLi0PNSy8QbqD2kddC/muc0cXVs6d+jpeKV
VbB5O+hQr5OLRaB4D9WBVi8MV9IfqB9Gw8Oy3NP949/wuzCXIhonoStm7iIvyQTT
eDuE7rnADoQ8T/F6Q+62khkL16uFH4cY6NZ2y7N1JeFEX3mWx8mtKhVqkL6V0X1D
0B/Xe/uPAmesqN6VMdgOz4XQTqDNZGLpuOCExs6gvVj6eFwO1J9rLnf70gjCLTTt
yGjEau2VGr1ncRW0ZaW5P90x8+DWRUib+xpZEoiU5N3N/dpVlr6TyhkSUsE9dL4J
yWcbuWWvD+qO/EpjUXyeCDWXBH3b0xioWz/8ykwS6tZox/KTaE0H1GikVMJNMivA
RZE2yC5E6YR1hRbgHcPk
=pa1R
-----END PGP SIGNATURE-----