-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
expose _abcoll as collections.abc #55294
Comments
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 the collections.py namespace so that no one has to change existing code. Background: Experience with teaching ABCs and dealing with bug reports has shown that it is creating some confusion having the long list of abstract APIs commingled with the concrete APIs (for example, seeing collections.Mapping and thinking it is one of the various concrete types in the collections module). If it were to become a practice to write collections.abc.Mapping, it would be immediately clear that an ABC was being used rather than a concrete class like OrderedDict. The other reason to separate them is that the use cases tend to be different. People look to the abstract APIs either for a specification (reference purposes), for mixin methods (aid in building their own classes), or for registration (to control isinstance and issubclass). In contrast, people use concrete APIs directly for managing data. Accordingly, it makes senses to group the two different types of tools into separate toolboxes. |
Why not just put them in the 'abc' namespace? IMO, collections.abc.Callable makes a lot less sense than abc.Mapping. |
Two reasons:
|
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 whether it is a good idea to special-case collections. The docs already make the distinction pretty clear. My "flat is better than nested" alarm is going off here :) |
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. |
And what about those "collection" ABCs that aren't collections? These are at least
|
<shrug> Guido originally thought all these should live together and I don't see much of a win in separating them from the other. |
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. |
However done, I would prefer separation also. |
That makes things confusing: >>> import os.path
>>> os.path.__name__
'posixpath'
>>> import collections
>>> collections.Mapping
<class '_abcoll.Mapping'> yikes? |
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. |
I'll use the packaging approach. The os.path technique predated packages and is no longer the preferred way of doing things. |
Followed Brett's example with importlib and made collection into a package with an abc module. See r88490. |
Some missed doc changes. |
For the record, this made unloaded interpreter startup quite a bit slower since importing one of the abcs now imports the whole collection package and its dependencies. ### normal_startup ### ### startup_nosite ### It probably doesn't make much difference in practice, since 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 as possible. I also doubt IDLE uses collections to bring up its shell window. |
I don't think a 50ms startup time is a problem for the interactive
The collections module appeared in 2.4; antiquated code might indeed not |
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 double that of Python 2. |
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. |
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. |
Importing abstract base classes has been marked as deprecated in Python 3.3[0] and the deprecation has been finished in Python 3.9[1] [0] python/cpython#55294 [1] python/cpython#70176
Importing abstract base classes from collections has been marked as deprecated in Python 3.3[0] in favor of importing from collections.abc. The deprecation has been finished in Python 3.9[1] [0] python/cpython#55294 [1] python/cpython#70176
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: