[issue11085] expose _abcoll as collections.abc

[Brett Cannon]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Laurent Mazuel]

Changes by Laurent Mazuel :


--
nosy: +Laurent.Mazuel

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Florent Xicluna]

Changes by Florent Xicluna :


--
nosy: +flox

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Terry J. Reedy]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Georg Brandl]

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 double that of Python 2.

--
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Antoine Pitrou]

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 as fast as possible.

I don't think a 50ms startup time is a problem for the interactive
interpreter. Of course, it will be more noticeable on very slow
machines.

> I also doubt IDLE uses collections to bring up its shell window.

The collections module appeared in 2.4; antiquated code might indeed not
know about it ;)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Terry J. Reedy]

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 as possible. I also doubt IDLE uses collections 
to bring up its shell window.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Éric Araujo]

É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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Raymond Hettinger]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Raymond Hettinger]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Éric Araujo]

É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 tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Antoine Pitrou]

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.__name__
'posixpath'

>>> import collections
>>> collections.Mapping


yikes?

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Terry J. Reedy]

Terry J. Reedy  added the comment:

However done, I would prefer separation also.

--
nosy: +terry.reedy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Éric Araujo]

É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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Raymond Hettinger]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Georg Brandl]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Brett Cannon]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Daniel Urban]

Changes by Daniel Urban :


--
nosy: +durban

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[R. David Murray]

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 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 :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Raymond Hettinger]

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 with collections.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[R. David Murray]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11085] expose _abcoll as collections.abc

[Raymond Hettinger]

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 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.

--
components: Library (Lib)
messages: 127652
nosy: rhettinger
priority: low
severity: normal
status: open
title: expose _abcoll as collections.abc
type: feature request
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com