Re: PEP 420: Implicit Namespace Packages
Antoine Pitrou <[email protected]>
| Newsgroups | gmane.comp.python.import |
|---|---|
| Message-ID | <[email protected]> |
On Sat, 5 May 2012 16:27:26 +1000 Nick Coghlan <[email protected]> wrote: > On Sat, May 5, 2012 at 8:47 AM, Antoine Pitrou <[email protected]> wrote: > > Unless there are clear advantages over PEP 382, I'm -1 on this PEP, and > > would like to see PEP 382 revived. > > I raised this question as well, and the PEP as written doesn't do a > great job of summarising the thread that addressed it. > > There were two counterpoints raised that I found compelling: > > A. Guido simply doesn't like directory extensions. I have to agree > with him that using them to handle packaging would be a weird and > unusual approach, and, well, he *does* get to play the BDFL card in > cases like this. Well, I agree that "foo.pyp" isn't very pretty, but that's a pretty minor argument. At least it's explicit. (of course, another marker could have been chosen: for example an empty "foo/__namespace__.py", or whatever else floats our boat of aesthetics) > B. Current version control systems are still pretty abysmal when it > comes to coping with directory renames, and we want to avoid > unnecessary stumbling blocks on the migration path from the current > pkgutil.extend_path() based namespace packages to the new native > system. Isn't that baseless? AFAIU all modern DVCS should cope correctly with a directory rename. Even SVN may be ok. If anything, I'd like to see data points about these "current version control systems" being "pretty abysmal [!] when it comes to coping with directory renames". (preferably something else than a 2007 rant by Mark Shuttleworth in order to justify bzr's existence :-)) > The extra step required by the PEP 382 approach is exactly the kind of > pointless revision history noise that PEP 414's reintroduction of > explicit Unicode literals is designed to eliminate from Python 2 to > Python 3 migrations. Except that noone *has* to migrate to namespace packages. These are fairly rare and only useful for a couple of big projects. (I've only heard about Zope using them; Twisted AFAICT doesn't) Even then, renaming a directory is hardly comparable to the hurdle of migrating unicode literals from Python 2 to Python 3. The analogy sounds melodramatic. > Between "Guido doesn't like directory suffixes" and "version control > systems are still fairly bad at handling directory renames", I changed > my own opinion on PEP 420 from -1 to +0. This doesn't address PEP 420's issues, which will still come to bite us in 10 years: the potential for confusion, the weirdness of the lookup algorithm. > If we'd been starting from a > clean slate with no language history or migration of existing projects > to account for, then my opinion would be different, but given where we > are today, I find the pragmatic argument in favour of simply losing > the explicit markers compelling. The real pragmatic argument would be to avoid creating maintenance and support issues for the future, IMO. Regards Antoine.