Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #44284 > unrolled thread

Weird python behavior

Back to article view | Back to comp.lang.python

Contents

  Weird python behavior Forafo San <ppv.grps@gmail.com> - 2013-04-24 12:06 -0700
    Re: Weird python behavior Neil Cerutti <neilc@norwich.edu> - 2013-04-24 19:08 +0000
      Re: Weird python behavior Forafo San <ppv.grps@gmail.com> - 2013-04-24 12:19 -0700
        Re: Weird python behavior Tim Roberts <timr@probo.com> - 2013-04-25 23:04 -0700
          Re: Weird python behavior rusi <rustompmody@gmail.com> - 2013-04-25 23:25 -0700
            Re: Weird python behavior rusi <rustompmody@gmail.com> - 2013-04-26 00:04 -0700

#44284 — Weird python behavior

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.
>>> import glob
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,
-Premal 

[toc] | [next] | [standalone]

#44285

On 2013-04-24, Forafo San <ppv.grps@gmail.com> wrote:
> 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.
>>>> import glob
> 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

[toc] | [prev] | [next] | [standalone]

#44287

On Wednesday, April 24, 2013 3:08:27 PM UTC-4, Neil Cerutti wrote:
> On 2013-04-24, Forafo San <ppv.grps@gmail.com> wrote:
> 
> > 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.
> 
> >>>> import glob
> 
> > 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.

[toc] | [prev] | [next] | [standalone]

#44386

Forafo San <ppv.grps@gmail.com> wrote:
>
>OK, lesson learned: Take care not to have module names that conflict with python's built ins. Sorry for being so obtuse.

You don't have to apologize.  We've all been bitten by this at least once.
-- 
Tim Roberts, timr@probo.com
Providenza & Boekelheide, Inc.

[toc] | [prev] | [next] | [standalone]

#44388

On Apr 26, 11:04 am, Tim Roberts <t...@probo.com> wrote:
> Forafo San <ppv.g...@gmail.com> wrote:
>
> >OK, lesson learned: Take care not to have module names that conflict with python's built ins. Sorry for being so obtuse.
>
> 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.

[toc] | [prev] | [next] | [standalone]

#44394

On Apr 26, 11:25 am, rusi <rustompm...@gmail.com> wrote:
> To present these kind of errors, Erlang has a concept of sticky
> modules -- those that come from the system…

??present?? should have been 'prevent'

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web