[issue11085] expose _abcoll as collections.abc

Brett Cannon added the comment: I'm closing this again as 3.3 actually starts up faster than 3.2 thanks to importlib so this slowdown is no longer noticeable. -- status: open -> closed ___ Python tracker _

[issue11085] expose _abcoll as collections.abc

Changes by Laurent Mazuel : -- nosy: +Laurent.Mazuel ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mai

[issue11085] expose _abcoll as collections.abc

Changes by Florent Xicluna : -- nosy: +flox ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue11085] expose _abcoll as collections.abc

Changes by Raymond Hettinger : -- assignee: -> rhettinger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue11085] expose _abcoll as collections.abc

Terry J. Reedy added the comment: A couple of years ago, various people worked hard to remove unneeded imports from the interpreter startup routine. The result was both quite noticeable and much appreciated on my old xp machine. I hate to see much of that progress tossed away. -- __

[issue11085] expose _abcoll as collections.abc

Georg Brandl added the comment: You also have to think about command-line apps like Mercurial that need to be snappy. For those guys, a lot of added startup time is a big deal -- one of the reasons Matt Mackall hates thinking about a Python 3 port is that Python 3(.2) startup time is already

[issue11085] expose _abcoll as collections.abc

Antoine Pitrou added the comment: > > collections is one of those modules everyone will use in their code. > > Simply untrue, and definitely not in every program. It is also > irrelevant for bringing up the interactive interpreter, where there > initially is no user code and which should happen

[issue11085] expose _abcoll as collections.abc

Terry J. Reedy added the comment: > collections is one of those modules everyone will use in their code. Simply untrue, and definitely not in every program. It is also irrelevant for bringing up the interactive interpreter, where there initially is no user code and which should happen as fast

[issue11085] expose _abcoll as collections.abc

Éric Araujo added the comment: Some missed doc changes. -- keywords: +patch Added file: http://bugs.python.org/file20914/collections.abc-in-docs.diff ___ Python tracker ___

[issue11085] expose _abcoll as collections.abc

Raymond Hettinger added the comment: Followed Brett's example with importlib and made collection into a package with an abc module. See r88490. -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue11085] expose _abcoll as collections.abc

Raymond Hettinger added the comment: I'll use the packaging approach. The os.path technique predated packages and is no longer the preferred way of doing things. -- ___ Python tracker ___

[issue11085] expose _abcoll as collections.abc

Éric Araujo added the comment: Okay, I plead guilty of premature implementation talk. The clean solution is just moving collections.py to collections/__init__.py and _abcoll.py to collections/abc.py, but I will defer to Raymond here. -- ___ Python

[issue11085] expose _abcoll as collections.abc

Antoine Pitrou added the comment: > Regarding the implementation, knowing your reluctance to turn modules > into packages, I guess you’re talking about exposing collections.abc in > a similar manner to os.path, which is fine IMO. That makes things confusing: >>> import os.path >>> os.path.__n

[issue11085] expose _abcoll as collections.abc

Terry J. Reedy added the comment: However done, I would prefer separation also. -- nosy: +terry.reedy ___ Python tracker ___ ___ Pyth

[issue11085] expose _abcoll as collections.abc

Éric Araujo added the comment: Seems a good idea to me. Regarding the implementation, knowing your reluctance to turn modules into packages, I guess you’re talking about exposing collections.abc in a similar manner to os.path, which is fine IMO. -- nosy: +eric.araujo ___

[issue11085] expose _abcoll as collections.abc

Raymond Hettinger added the comment: > And what about those "collection" ABCs that aren't collections? Guido originally thought all these should live together and I don't see much of a win in separating them from the other. -- ___ Python tracker

[issue11085] expose _abcoll as collections.abc

Georg Brandl added the comment: And what about those "collection" ABCs that aren't collections? These are at least * Hashable * Callable * ByteString * Iterator -- nosy: +georg.brandl ___ Python tracker ___

[issue11085] expose _abcoll as collections.abc

Brett Cannon added the comment: Importlib puts all of its ABCs in importlib.abc, so at least one package has already taken this approach. I for one support the collections.abc idea. -- nosy: +brett.cannon ___ Python tracker

[issue11085] expose _abcoll as collections.abc

Changes by Daniel Urban : -- nosy: +durban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue11085] expose _abcoll as collections.abc

R. David Murray added the comment: Hmm. OK, so it is just Callable that is the odd man out. But in that case, shouldn't the pattern be adopted by the other modules that define abcs as well? And if the distinction isn't sharp enough in those other modules to justify that, then I question whe

[issue11085] expose _abcoll as collections.abc

Raymond Hettinger added the comment: > Why not just put them in the 'abc' namespace? Two reasons: * There are lots of ABCs scattered throughout the standard libary that aren't collections ABCs (the importlib ABCs and IO ABCs for example). * Guido viewed collections ABCs as tightly associated w

[issue11085] expose _abcoll as collections.abc

R. David Murray added the comment: Why not just put them in the 'abc' namespace? IMO, collections.abc.Callable makes a lot less sense than abc.Mapping. -- nosy: +r.david.murray ___ Python tracker ___

[issue11085] expose _abcoll as collections.abc

New submission from Raymond Hettinger : For the 3.3, make _abcoll (which is full of the collections abstract base classes) visible as a module called collections.abc and document that as the preferred way to access them. For backwards compatibility, continue to import the names directly into t