Re: PEP 420 issue: extend_path
"Eric V. Smith" <[email protected]>
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <[email protected]> |
On 5/9/2012 12:42 PM, [email protected] wrote: >>> I must have missed Nick's message where he explained it, so I still need >>> to ask again: how exactly would such a zip file be structured? >> >> I'll work on such an example. But I think Nick's example of a config >> file that has the configuration for multiple portions of a single >> namespace package is more compelling. I don't see where returning a list >> for the common case of a single portion is a large burden. > > Unfortunately, I still can't locate the message where he explains the > example. This sounds like a bit like .pth files, where the file contains > the list of locations to be added to the path. It was supported in an > early version of PEP 382, when the community declared YAGNI. I think that's this message: http://mail.python.org/pipermail/import-sig/2012-May/000585.html >> As Nick said, you'd return a loader, a list of portions, or neither. it >> would be an error to return both. > > Ah, ok. This is fine, then (except that I still think that returning > multiple > portions needs to be supported). I thought you were arguing that multiple portions per finder call didn't need to be supported. Maybe I misunderstand. Eric.