[issue20784] 'collections.abc' is no longer defined when collections is imported

Paweł added the comment: I had similar issue and it helped when as a workaround I use 'pip install .' as opposed to 'python setup.py develop' in my project. I hope this will give you a hint. -- components: +Library (Lib) nosy: +pawciobiel versions: +Python 2.7 _

[issue20784] 'collections.abc' is no longer defined when collections is imported

Changes by Christian Heimes : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue20784] 'collections.abc' is no longer defined when collections is imported

R. David Murray added the comment: I've documented that 'collections.abc' is no longer implicit, which I presume means we are going to keep this behavior. (Unless you tell me to revert that and we fix it as a regression in 3.4.1). As long as an application follows the note and explicitly impo

[issue20784] 'collections.abc' is no longer defined when collections is imported

Roundup Robot added the comment: New changeset d575398d1916 by R David Murray in branch 'default': whatsnew: collections no longer implicitly imports 'abc' (#20784). http://hg.python.org/cpython/rev/d575398d1916 -- ___ Python tracker

[issue20784] 'collections.abc' is no longer defined when collections is imported

Nick Coghlan added the comment: Oh, and yes, this is *definitely* a bug: _collections_abc.__name__ is set to "collections.abc", but if "collections.abc" isn't imported anywhere in the program, then cx-freeze and similar tools will miss the fact that "collections.abc" should be bundled. If "co

[issue20784] 'collections.abc' is no longer defined when collections is imported

Nick Coghlan added the comment: cx-freeze feedback is better added to issue 20884 - I currently still suspect that 3.4 has just uncovered some latent spec non-compliance in the cx-freeze import system emulation (although I need to investigate further to be sure, since it's also possible we acc

[issue20784] 'collections.abc' is no longer defined when collections is imported

STINNER Victor added the comment: >> I cannot reproduce your issue > Meaning you do not have the environment set up for this or that > you tried it and it worked for you? I mean that executing the following lines in Python doesn't fail: --- print("Hello world") import configparser --- It's spec

[issue20784] 'collections.abc' is no longer defined when collections is imported

Jurko Gospodnetić added the comment: > I cannot reproduce your issue Meaning you do not have the environment set up for this or that you tried it and it worked for you? If it 'worked for you', I can send you more detailed environment information when get back to my office in an hour or so

[issue20784] 'collections.abc' is no longer defined when collections is imported

STINNER Victor added the comment: > Item possibly related to this. I cannot reproduce your issue, it looks like a bug in cx_Freeze. "import collections" doesn't import "collections.abc" by default anymore, but configparser is correct: "from collections.abc import MutableMapping". So it import

[issue20784] 'collections.abc' is no longer defined when collections is imported

Jurko Gospodnetić added the comment: Item possibly related to this. When packaging a simple HelloWorld-like application like this: print("Hello world") import configparser using cx_Freeze and Python 3.4, you get the following error on packaged application startup: Traceback (most recent

[issue20784] 'collections.abc' is no longer defined when collections is imported

Antoine Pitrou added the comment: > > So, it's a very common idiom. > > "Common" doesn't imply "correct" or "supported". There are plenty of > other packages/modules who don't import their subpackages/submodules > during initialization. Unless explicitly supported by the module, > using a subm

[issue20784] 'collections.abc' is no longer defined when collections is imported

Larry Hastings added the comment: > So, it's a very common idiom. "Common" doesn't imply "correct" or "supported". There are plenty of other packages/modules who don't import their subpackages/submodules during initialization. Unless explicitly supported by the module, using a submodule wit

[issue20784] 'collections.abc' is no longer defined when collections is imported

Serhiy Storchaka added the comment: May be add temporary replacement for collections.abc? class _AbcModulePlaceholder(type(_collections_abc)): def __warn(self): import warnings warnings.warn('collections.abc used without importing', DeprecationWarning, 3

[issue20784] 'collections.abc' is no longer defined when collections is imported

Antoine Pitrou added the comment: A quick grep indicates at least the following modules use os.path but only import os: bdb, binhex, cgitb, compileall, cProfile, doctest, filecmp, fileinput, fnmatch, ftplib, gettext, glob, imghdr, imp, inspect, linecache, mailbox, mimetypes, modulefinder, netr

[issue20784] 'collections.abc' is no longer defined when collections is imported

Antoine Pitrou added the comment: > I'm pretty sure that if you import "x", there are zero guarantees that > "x.y" will work. The offical line is that you must explicitly import > all the deepest submodules you use. I'm not sure why you're saying that. I think it's quite common to only "import

[issue20784] 'collections.abc' is no longer defined when collections is imported

R. David Murray added the comment: If we decide we want this (small) backward compatibility break, to make collections.abc consistent with the other modules (except os.path), then I should mention it in the whatsnew porting section for 3.4, which is really why I opened this issue :) I that ca

[issue20784] 'collections.abc' is no longer defined when collections is imported

R. David Murray added the comment: It is a backward compatibility bug. Something that used to work doesn't any more. And it was explicitly *made* to work previously (the original __init__ statement was 'import collections.abc'). And it is is an implementation bug in the original patch becau

[issue20784] 'collections.abc' is no longer defined when collections is imported

Larry Hastings added the comment: I'm pretty sure that if you import "x", there are zero guarantees that "x.y" will work. The offical line is that you must explicitly import all the deepest submodules you use. So I don't think this is even a bug. -- _

[issue20784] 'collections.abc' is no longer defined when collections is imported

New submission from R. David Murray: collections.abc was renamed _collections_abc in issue 19218. The __init__ file was modified to load all the abc into the collections namespace, but the 'abc' name itself is no longer defined: Python 3.3.2 (default, Dec 17 2013, 17:24:42) [GCC 4.7.3] on li