import bug

En Sun, 01 Nov 2009 19:01:42 -0300, MRAB <>
escribió:
> Gabriel Genellina wrote:

>>>> One way to avoid name clashes would be to put the entire standard
>>>> library under a package; a program that wants the standard re
>>>> module would write "import std.re" instead of "import re", or
>>>> something similar.
>>> You could do it in a backwards compatible way, by adding the std
>>> package directory into the path.
>> Unfortunately you can't, at least not without some special treatment
>> of the std package. One of the undocumented rules of the import
>> system is that you must not have more than one way to refer to the
>> same module (in this case, std.re and re). [...]
> Couldn't the entry in sys.modules be where the module was found, so that
> if 're' was found in 'std' then the entry is 'std.re' even if the import
> said just 're'?

What about a later 'import re'? 're' would not be found in sys.modules
then.
In any case, it requires a change in the current behavior, a PEP, and a
lot of discussion...

--
Gabriel Genellina

Gabriel Genellina

En Sun, 01 Nov 2009 19:51:04 -0300, Steven D'Aprano
<> escribió:
> On Sun, 01 Nov 2009 17:34:19 -0300, Gabriel Genellina wrote:
>> En Sun, 01 Nov 2009 02:54:15 -0300, Steven D'Aprano escribió:

>>> Shadowing a standard library module
>>> is no different.
>>
>> But that's what namespaces are for; if the standard library had its own
>> namespace, such collisions would not occur.
>
> Sure. But that's not a bug in the import system. If it's a bug, it's a
> bug in the layout of the standard library.

Half and half? The standard library cannot have a different structure
because the import system cannot handle it in a backgwards compatible way?

--
Gabriel Genellina

Gabriel Genellina

On Oct 31, 7:12*am, kj <no.em...@please.post> wrote:
> I'm running into an ugly bug, which, IMHO, is really a bug in the
> design of Python's module import scheme. *Consider the following
> directory structure:
>
> ham
> |-- __init__.py
> |-- re.py
> `-- spam.py
>
> ...with the following very simple files:
>
> % head ham/*.py
> ==> ham/__init__.py <==
>
> ==> ham/re.py <==
>
> ==> ham/spam.py <==
> import inspect
>
> I.e. only ham/spam.py is not empty, and it contains the single line
> "import inspect".
>
> If I now run the innocent-looking ham/spam.py, I get the following
> error:
>
> % python26 ham/spam.py
> Traceback (most recent call last):
> * File "ham/spam.py", line 1, in <module>
> * * import inspect
> * File "/usr/local/python-2.6.1/lib/python2.6/inspect.py", line 35, in <module>
> * * import string
> * File "/usr/local/python-2.6.1/lib/python2.6/string.py", line 122, in <module>
> * * class Template:
> * File "/usr/local/python-2.6.1/lib/python2.6/string.py", line 116, in __init__
> * * 'delim' : _re.escape(cls.delimiter),
> AttributeError: 'module' object has no attribute 'escape'
>
> or, similarly,
>
> % python3 ham/spam.py
> Traceback (most recent call last):
> * File "ham/spam.py", line 1, in <module>
> * * import inspect
> * File "/usr/local/python-3.0/lib/python3.0/inspect.py", line 36, in <module>
> * * import string
> * File "/usr/local/python-3.0/lib/python3.0/string.py", line 104, in <module>
> * * class Template(metaclass=_TemplateMetaclass):
> * File "/usr/local/python-3.0/lib/python3.0/string.py", line 98, in __init__
> * * 'delim' : _re.escape(cls.delimiter),
> AttributeError: 'module' object has no attribute 'escape'
>
> My sin appears to be having the (empty) file ham/re.py. *So Python
> is confusing it with the re module of the standard library, and
> using it when the inspect module tries to import re.


Python is documented as behaving this way, so this is not a bug.

It is arguably poor design. However, Guido van Rossum already ruled
against using a single package for the standard library, and its not
likely that special case code to detect accidental name-clashes with
the standard library is going to be added, since there are legitimate
reasons to override the standard library.

So for better or worse, you'll just have to deal with it.


Carl Banks

Carl Banks

On Nov 3, 1:52*am, Carl Banks <pavlovevide...@gmail.com> wrote:
> On Oct 31, 7:12*am, kj <no.em...@please.post> wrote:
>
>
>
>
>
> > I'm running into an ugly bug, which, IMHO, is really a bug in the
> > design of Python's module import scheme. *Consider the following
> > directory structure:
>
> > ham
> > |-- __init__.py
> > |-- re.py
> > `-- spam.py
>
> > ...with the following very simple files:
>
> > % head ham/*.py
> > ==> ham/__init__.py <==
>
> > ==> ham/re.py <==
>
> > ==> ham/spam.py <==
> > import inspect
>
> > I.e. only ham/spam.py is not empty, and it contains the single line
> > "import inspect".
>
> > If I now run the innocent-looking ham/spam.py, I get the following
> > error:
>
> > % python26 ham/spam.py
> > Traceback (most recent call last):
> > * File "ham/spam.py", line 1, in <module>
> > * * import inspect
> > * File "/usr/local/python-2.6.1/lib/python2.6/inspect.py", line 35, in <module>
> > * * import string
> > * File "/usr/local/python-2.6.1/lib/python2.6/string.py", line 122, in <module>
> > * * class Template:
> > * File "/usr/local/python-2.6.1/lib/python2.6/string.py", line 116, in __init__
> > * * 'delim' : _re.escape(cls.delimiter),
> > AttributeError: 'module' object has no attribute 'escape'
>
> > or, similarly,
>
> > % python3 ham/spam.py
> > Traceback (most recent call last):
> > * File "ham/spam.py", line 1, in <module>
> > * * import inspect
> > * File "/usr/local/python-3.0/lib/python3.0/inspect.py", line 36, in <module>
> > * * import string
> > * File "/usr/local/python-3.0/lib/python3.0/string.py", line 104, in <module>
> > * * class Template(metaclass=_TemplateMetaclass):
> > * File "/usr/local/python-3.0/lib/python3.0/string.py", line 98, in __init__
> > * * 'delim' : _re.escape(cls.delimiter),
> > AttributeError: 'module' object has no attribute 'escape'
>
> > My sin appears to be having the (empty) file ham/re.py. *So Python
> > is confusing it with the re module of the standard library, and
> > using it when the inspect module tries to import re.
>
> Python is documented as behaving this way, so this is not a bug.
>
> It is arguably poor design. *However, Guido van Rossum already ruled
> against using a single package for the standard library, and its not
> likely that special case code to detect accidental name-clashes with
> the standard library is going to be added, since there are legitimate
> reasons to override the standard library.
>
> So for better or worse, you'll just have to deal with it.
>
> Carl Banks

Just have to add that you're not just affected by the standard
library.
If you have a module named myapp.django, and someone writes a cool
library called
django that you want to use, you can't use it unless you rename your
local django module.


file myapp/django.py:

from django.utils.functional import curry

ImportError: No module named utils.functional

At least that's what I get, maybe there is some workaround, some way
to say this is an absolute path?

Ask Solem

En Tue, 03 Nov 2009 12:29:10 -0300, Ask Solem <>
escribió:

> If you have a module named myapp.django, and someone writes a cool
> library called
> django that you want to use, you can't use it unless you rename your
> local django module.
>
>
> file myapp/django.py:
>
> from django.utils.functional import curry
>
> ImportError: No module named utils.functional
>
> At least that's what I get, maybe there is some workaround, some way
> to say this is an absolute path?

Yes, that's exactly the way to solve it. Either move on to Python 3, or
use:
from __future__ import absolute_import

When absolute imports are in effect, and assuming your code is inside a
package, then neither "import re" nor "from django.utils.functional import
curry" are affected by your own module names, because those statements
imply an absolute import ("absolute" means that the module is searched
along sys.path).
The only way to import a local file "re.py" is using "from .re import
something"; the leading dot means it's a relative import ("relative" means
that the module is searched in a single directory: the current package
directory and its parents, depending on how many dots are specified)

--
Gabriel Genellina

Gabriel Genellina

On Oct 31, 5:12 pm, kj <> wrote:
> I give up: what's the trick? (Of course, renaming ham/re.py is
> hardly "the trick." It's rather Procrustes' Bed.)

I realize that this is probably not the answer you were looking for,
but:

$ python -m ham.spam

or

==> ./spammain.py <==
import ham.spam

$ python spammain.py


I've found it easier to not fight the module/package system but work
with it. But yes, I also think the problem you're seeing is a wart or
bug even.

Best regards
Mark Leander

Mark Leander