Module name conflict with standard library

[Felix Wiemann]

Hi!

I want to create a module myproject.ui.curses, which needs to import the
curses library.

However, if I just write ``import curses``, the module imports *itself*
instead of the standard library's curses module.

Is there any (reliable) way to access a module of the standard library
if the names conflict as in this case?

Thank you in advance,
Felix Wiemann

 

[Michele Simionato]

Hi!

I want to create a module myproject.ui.curses, which needs to import the
curses library.

However, if I just write ``import curses``, the module imports *itself*
instead of the standard library's curses module.

Is there any (reliable) way to access a module of the standard library
if the names conflict as in this case?

Thank you in advance,
Felix Wiemann

Dunno. I guess that when PEP328 will be fully implemented (this is NOT the
case in 2.4.a3)

from __future__ import absolute_import
import curses

will do the right thing, importing the standard library module and not
itself (which should happen with "import .curses").

Am I correct? I do really really like PEP328 since I was bitten by
this kind of problems myself in the past. Will it be implemented fully
in time for 2.4.b1?


Michele Simionato

 

[Anthony Baxter]

Am I correct? I do really really like PEP328 since I was bitten by
this kind of problems myself in the past. Will it be implemented fully
in time for 2.4.b1?

It seems doubtful, unfortunately, unless someone steps forward Real
Soon to champion the PEP and get it done.

 

[Nigel Rowe]

It seems doubtful, unfortunately, unless someone steps forward Real
Soon to champion the PEP and get it done.

In the mean time,

http://hkn.eecs.berkeley.edu/~dyoo/python/__std__

can help at least some of the problems.

 

[John Lenton]

Hi!

I want to create a module myproject.ui.curses, which needs to import the
curses library.

However, if I just write ``import curses``, the module imports *itself*
instead of the standard library's curses module.

Is there any (reliable) way to access a module of the standard library
if the names conflict as in this case?

not now. I think your best bet is to call your module 'Curses'.

--
John Lenton ([email protected]) -- Random fortune:
Civilization is the limitless multiplication of unnecessary necessities.
-- Mark Twain

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBOyFLgPqu395ykGsRAl6TAJ9uwPbvKbILgRV/m24Mw0QAsLdz5QCffy1/
hcoRxXzAzrNPcchjNiBncy4=
=CYIX
-----END PGP SIGNATURE-----

 

[Felix Wiemann]

In the mean time [until PEP 328 is implemented],

http://hkn.eecs.berkeley.edu/~dyoo/python/__std__

can help at least some of the problems.

This doesn't always work:

$ cat random.py
from __std__ import random

$ python random.py # this works

$ cat curses.py
from __std__ import curses

$ python curses.py # this does not work
Traceback (most recent call last):
File "curses.py", line 1, in ?
from __std__ import curses
File "/usr/lib/python2.3/curses/__init__.py", line 16, in ?
from curses.wrapper import wrapper <--- Uh-oh
File "/var/home/felix/tmp/curses.py", line 1, in ?
from __std__ import curses
ImportError: cannot import name curses

So I hope that absolute imports will get implemented in Python 2.4. I
think I'll name my module 'Curses', as John suggested (even if that's
asking for trouble on Windows systems).

 

[Jorge Godoy]

In the mean time [until PEP 328 is implemented],

http://hkn.eecs.berkeley.edu/~dyoo/python/__std__

can help at least some of the problems.

This doesn't always work:

$ cat random.py
from __std__ import random

$ python random.py # this works

$ cat curses.py
from __std__ import curses

$ python curses.py # this does not work
Traceback (most recent call last):
File "curses.py", line 1, in ?
from __std__ import curses
File "/usr/lib/python2.3/curses/__init__.py", line 16, in ?
from curses.wrapper import wrapper <--- Uh-oh
File "/var/home/felix/tmp/curses.py", line 1, in ?
from __std__ import curses
ImportError: cannot import name curses

So I hope that absolute imports will get implemented in Python 2.4. I
think I'll name my module 'Curses', as John suggested (even if that's
asking for trouble on Windows systems).

Do you really need to use the same name? How about something like
"mCurses" (myCurses) or "oCurses" (own Curses), etc. ?

It avoids the name clash on Windows and states that you are really not
referring to the standar curses module.

Avoiding to use an already existing name is good and it is even better
when you are using a name tha tis available at the standard library.
Not following this might cause more harm than good in the long run (or
short run, as you've noticed already).


Be seeing you,

 

[Felix Wiemann]

Do you really need to use the same name? How about something like
"mCurses" (myCurses) or "oCurses" (own Curses), etc. ?

Hmmm, yes. Or maybe "ncurses" (even though it's actually wrong, but at
least it's obvious).

It avoids the name clash on Windows and states that you are really not
referring to the standar curses module.

True.

 

[John Lenton]

So I hope that absolute imports will get implemented in Python 2.4. I
think I'll name my module 'Curses', as John suggested (even if that's
asking for trouble on Windows systems).

what kind of trouble, other than not being able to put it in the same
directory as curses.py ?

--
John Lenton ([email protected]) -- Random fortune:
No hay peor sordo que el que no quiere oir.
-- Refrán.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBPFyrgPqu395ykGsRAgezAKCD3PnoY1TuAQp2IHCv2oSWcr0Y3ACeId/n
tfnu9fpblUbWcsx1TrKlSyw=
=Ha8b
-----END PGP SIGNATURE-----