Weird python behavior

[Forafo San]

Hello All,
I'm running Python version 2.7.3_6 on a FreeBSD system. The following session in a Python interpreter throws a mysterious TypeError:

------------------------------------------
[ppvora@snowfall ~/xbrl]$ python
Python 2.7.3 (default, Apr 22 2013, 18:42:18)
[GCC 4.2.1 20070719 [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "glob.py", line 14, in <module>
myl = glob.glob('data/*.xml')
TypeError: 'module' object is not callable

 

[Neil Cerutti]

Hello All,
I'm running Python version 2.7.3_6 on a FreeBSD system. The following session in a Python interpreter throws a mysterious TypeError:

------------------------------------------
[ppvora@snowfall ~/xbrl]$ python
Python 2.7.3 (default, Apr 22 2013, 18:42:18)
[GCC 4.2.1 20070719 [FreeBSD]] on freebsd8
Type "help", "copyright", "credits" or "license" for more information.Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "glob.py", line 14, in <module>
myl = glob.glob('data/*.xml')
TypeError: 'module' object is not callable
------------------------------------------
The file glob.py that the error refers to was run under another
screen session. It's a mystery why even that program threw an
error. Regardless, why should that session throw an import
error in this session? Weird. Any help is appreciated. Thanks,

'Cause Python's import statement looks in the current directory
first for files to import. So you're importing your own
error-riddled and mortal glob.py, rather than Python's pristine
and Olympian glob.py.

 

[Forafo San]

Hello All,

I'm running Python version 2.7.3_6 on a FreeBSD system. The following session in a Python interpreter throws a mysterious TypeError:

------------------------------------------

[ppvora@snowfall ~/xbrl]$ python

Python 2.7.3 (default, Apr 22 2013, 18:42:18)

[GCC 4.2.1 20070719 [FreeBSD]] on freebsd8

Type "help", "copyright", "credits" or "license" for more information.

Traceback (most recent call last):

File "<stdin>", line 1, in <module>

File "glob.py", line 14, in <module>

myl = glob.glob('data/*.xml')

TypeError: 'module' object is not callable

The file glob.py that the error refers to was run under another

screen session. It's a mystery why even that program threw an

error. Regardless, why should that session throw an import

error in this session? Weird. Any help is appreciated. Thanks,

'Cause Python's import statement looks in the current directory

first for files to import. So you're importing your own

error-riddled and mortal glob.py, rather than Python's pristine

and Olympian glob.py.



--

Neil Cerutti

"This room is an illusion and is a trap devisut by Satan. Go

ahead and dauntlessly! Make rapid progres!"

--Ghosts 'n Goblins

OK, lesson learned: Take care not to have module names that conflict with python's built ins. Sorry for being so obtuse.

 

[rusi]

You don't have to apologize.  We've all been bitten by this at least once.

Yes…
When it comes to keywords it is reasonable to expect the programmer to
know all the keywords and if he uses one for a function/variable the
error will be immediate.

When it comes to modules it is less reasonable to expect the
programmer to know all available modules.
To present these kind of errors, Erlang has a concept of sticky
modules -- those that come from the system -- for which special
efforts need to be made to 'unstick' them if one wants them
overridden. This is helpful because the default which is to raise an
error, is in most cases a more sound option than to silently override
a builtin.

 

[rusi]

To present these kind of errors, Erlang has a concept of sticky
modules -- those that come from the system…

??present?? should have been 'prevent'