A funny thing just happened to me. I tried out causing this error, just to see how the error message was somehow different, by creating a time.py in /tmp, and running python from there. Then I removed the time.py, and went on working.
Two days later, my usage of zc.buildout are broken with a "module time has no attribute time". Huh? Turns out, I created an empty time.py in /tmp, just to see the error message. By buildout will when creating eggs from checked out modules, copy them to a directory under /tmp, and evidently run python from /tmp to create the eggs. So that process finds the time.pyc, created from the empty time.py, which I hadn't deleted, and breaks! Heh. That was funny. Moral of the story: Don't create python modules with names that clash with build in modules in /tmp, even for testing. Or at least, of you do, remember to remove the pyc. :-P Or, reboot your Linux every night. Or well. I guess this could have been avoided in many ways. ;-) On Sun, Nov 16, 2008 at 17:43, Guilherme Polo <[EMAIL PROTECTED]> wrote: > On Sun, Nov 16, 2008 at 11:55 AM, Tal Einat <[EMAIL PROTECTED]> wrote: >> Steve Holden wrote: >>> Tal Einat wrote: >>>> It this desired behavior? >>>> >>>> At the very least the exception should be more detailed, perhaps to >>>> the point of suggesting the probable cause of the error (i.e. >>>> overriding the time module). >>>> >>> How is this different from any other case where you import a module with >>> a standard library name conflict, thereby confusing modules loaded later >>> standard library. Should we do the same for any error induced in such a way? >> >> The difference is that here the exception is generated directly in the >> C code so you don't get an intelligible traceback. The C code for >> datetime imports the time module via the Python C API. >> >> In other words, here a function from a module in the stdlib, datetime, >> barfs unexpectedly because I happen to have a file name time.py >> hanging around in some directory. There is no traceback and no >> intelligible exception message, just "AttributeError: time". I had to >> dig through datetime's C code to figure out which module was being >> imported via the Python C API, which turned out to be time. > > Just like Steve told you, this isn't different from other cases. But, > at least you get a message a bit more verbose in most cases, like: > > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > AttributeError: 'module' object has no attribute 'time' > > Then I went to look why this wasn't happening with datetime too, and I > found out that PyObject_CallMethod in abstract.c re sets the exception > message that would have been set by PyObject_GetAttr by now. Maybe > someone can tell me why it is doing that, for now a patch is attached > here (I didn't resist to not remove two trailing whitespaces). > >> >> This is rare enough that I've never had something like this happen to >> me in seven years of heavy Python programming. >> >> - Tal >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev@python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/ggpolo%40gmail.com >> > > > > -- > -- Guilherme H. Polo Goncalves > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/regebro%40gmail.com > > -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
