Module name conflict with standard library

[Jorge Godoy]

Felix Wiemann <Felix.Wiemann at gmx.net> writes:

> Nigel Rowe wrote:
>
>> 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,
-- 
Godoy.     <godoy at ieee.org>