On 2014-11-21 07:52, Rick Johnson wrote:
> On Friday, November 21, 2014 4:29:48 AM UTC-6, Tim Chase wrote:
>
> > What messed-up version of Python are you running?
> > Or did you fail to test your conjecture?
> >
> > $ cat > calendar.py
> > print("This is my local calendar.py")
> > x=1
> > $ cat > importtest.py
> > import calendar
> > print(dir(calendar))
> > $ python2 importtest.py
> > This is my local calendar.py
> > ['__builtins__', '__doc__', '__file__', '__name__',
> > '__package__', 'x'] $ python3 importtest.py
> > This is my local calendar.py
> > ['__builtins__', '__cached__', '__doc__', '__file__', '__name__',
> > '__package__', 'x']
> >
> > It finds my local module, not the system "calendar" module.
>
> You failed to provide the needed information!
>
> 1. We need to see the values in sys.path. So print them
> directly before making the call to import.
>
> 2. Where did you store your custom "calendar.py" script?
Had you paid attention, having watched the creation of the two files
and the invocation of stock python, you would know that they were in
the same folder, and there's no modification of sys.path in the
process. So if you're seeing different behaviors due to a modified
sys.path, then you should be aware that *you* modified sys.path and
thus broke things.
The above was tested on Python2 and Python3, both on Linux (Debian
in this case) and Win32 (using "copy con" instead of "cat >") with the
out-of-box install.
The only time I've been stung by name overloading is in the indirect
case of creating a local email.py file and then importing smtplib
only to have things break in unforeseen ways. If smtplib used
relative imports for $STDLIB/email.py I suspect it would ameliorate
that particular issue for me.
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
