RE: Bizarre error from help()

Discussion in 'Python' started by Delaney, Timothy (Tim), Aug 10, 2005.

  1. Roy Smith wrote:

    > Traceback (most recent call last):
    > File "<stdin>", line 1, in ?
    > File "/usr/local/lib/python2.3/site.py", line 307, in __call__
    > import pydoc
    > File "/usr/local/lib/python2.3/pydoc.py", line 49, in ?
    > from string import expandtabs, find, join, lower, split, strip,
    > rfind, rstrip
    > ImportError: cannot import name expandtabs


    Looks most likely that there something messed up with your python
    install. What happens if you do:

    >>> from string import expandtabs


    ? Do you get a similar error?

    The lines:

    foos bars bazes
    Foo

    look very suspicious - you should instead get:

    Help on built-in function isinstance in module __builtin__:

    isinstance(...)

    You may want to see if there's something strange in sitecustomize.py.

    Alternatively, since this is in the interactive interpreter, is it
    possible that something you'd done before could have caused this?

    Tim Delaney
     
    Delaney, Timothy (Tim), Aug 10, 2005
    #1
    1. Advertising

  2. Delaney, Timothy (Tim)

    Roy Smith Guest

    In article <>,
    "Delaney, Timothy (Tim)" <> wrote:

    > Roy Smith wrote:
    >
    > > Traceback (most recent call last):
    > > File "<stdin>", line 1, in ?
    > > File "/usr/local/lib/python2.3/site.py", line 307, in call
    > > import pydoc
    > > File "/usr/local/lib/python2.3/pydoc.py", line 49, in ?
    > > from string import expandtabs, find, join, lower, split, strip,
    > > rfind, rstrip
    > > ImportError: cannot import name expandtabs

    >
    > Looks most likely that there something messed up with your python
    > install. What happens if you do:
    >
    > >>> from string import expandtabs

    >
    > ? Do you get a similar error?


    No, that works fine. But, now I can't even reproduce the error I reported
    earlier (when I try, I get the help message as expected). And, yes, that
    was with a brand new interpreter session. Strange.
     
    Roy Smith, Aug 10, 2005
    #2
    1. Advertising

  3. Delaney, Timothy (Tim)

    Roy Smith Guest

    Roy Smith <> wrote:
    > No, that works fine. But, now I can't even reproduce the error I reported
    > earlier (when I try, I get the help message as expected). And, yes, that
    > was with a brand new interpreter session. Strange.


    I got it now! Oh, this is funny.

    I've got a directory where I keep all sorts of little snippets of python
    code for testing. When I start up python in that directory, I get the
    error I reported. It turns out, I've got a file called "string.py" in it,
    with the contents:

    ----------------------------
    Roy-Smiths-Computer:play$ cat string.py
    #!/usr/bin/env python

    class myString (str):
    def __init__ (self, value):
    self.value = value

    def plural (self):
    if self.value[-1] in "sz":
    return self.value + "es";
    else:
    return self.value + "s";

    foo = myString("foo")
    bar = myString("bar")
    baz = myString("baz")

    print foo.plural(), bar.plural(), baz.plural()
    print foo.capitalize()
    ----------------------------

    something in the help system must be doing an "import string".
     
    Roy Smith, Aug 10, 2005
    #3
  4. Roy Smith wrote:
    > No, that works fine. But, now I can't even reproduce the error I reported
    > earlier (when I try, I get the help message as expected). And, yes, that
    > was with a brand new interpreter session. Strange.


    Perhaps you were running Python from a directory with a file called
    string.py?
     
    Leif K-Brooks, Aug 10, 2005
    #4
  5. Delaney, Timothy (Tim)

    Ben Finney Guest

    Roy Smith <> wrote:
    > I've got a directory where I keep all sorts of little snippets of
    > python code for testing. When I start up python in that directory,
    > I get the error I reported. It turns out, I've got a file called
    > "string.py" in it [...]
    >
    > something in the help system must be doing an "import string".


    All hail the coming of PEP 328:

    <URL:http://www.python.org/peps/pep-0328.html>

    --
    \ "The best ad-libs are rehearsed." -- Graham Kennedy |
    `\ |
    _o__) |
    Ben Finney
     
    Ben Finney, Aug 10, 2005
    #5
  6. Delaney, Timothy (Tim)

    Peter Hansen Guest

    Ben Finney wrote:
    > Roy Smith <> wrote:
    >
    >>I've got a directory where I keep all sorts of little snippets of
    >>python code for testing. When I start up python in that directory,
    >>I get the error I reported. It turns out, I've got a file called
    >>"string.py" in it [...]
    >>
    >>something in the help system must be doing an "import string".

    >
    > All hail the coming of PEP 328:
    >
    > <URL:http://www.python.org/peps/pep-0328.html>


    Which, unless I misunderstand, would do nothing to change the behaviour
    of the OP's situation unless the mistakingly named "string.py" module
    was actually inside a package. If it was just in the current directory
    at the time, I don't think the PEP328 would have affected the situation.

    -Peter
     
    Peter Hansen, Aug 10, 2005
    #6
  7. Delaney, Timothy (Tim)

    Ben Finney Guest

    PEP 328, absolute/relative import (was: Re: Bizarre error from help())

    Peter Hansen <> wrote:
    > Ben Finney wrote:
    > > Roy Smith <> wrote:
    > >>[current-directory module shadowing a system module]

    > >
    > > All hail the coming of PEP 328:
    > > <URL:http://www.python.org/peps/pep-0328.html>

    >
    > Which, unless I misunderstand, would do nothing to change the
    > behaviour of the OP's situation unless the mistakingly named
    > "string.py" module was actually inside a package. If it was just in
    > the current directory at the time, I don't think the PEP328 would
    > have affected the situation.


    Once PEP 328 is fully implemented, all bare 'import foo' statements
    specify absolute imports (i.e. from sys.path only). To perform a
    relative import (e.g. from current directory) will require different
    syntax.

    "[...] relative imports will use leading dots. A single leading
    dot indicates a relative import, starting with the current
    package. Two or more leading dots give a relative import to the
    parent(s) of the current package [...]"

    <URL:http://www.python.org/peps/pep-0328.html#guido-s-decision>

    So, under PEP 328 rules, the original poster's current-directory
    module could only be imported (a) if the current directory was in
    sys.path, or (b) if the code specified a relative import. The
    accidental shadowing of the stdlib module could not happen.

    --
    \ "You know what would make a good story? Something about a clown |
    `\ who makes people happy, but inside he's real sad. Also, he has |
    _o__) severe diarrhea." -- Jack Handey |
    Ben Finney <http://www.benfinney.id.au/>
     
    Ben Finney, Aug 11, 2005
    #7
  8. Re: PEP 328, absolute/relative import

    Ben Finney wrote:
    > Once PEP 328 is fully implemented, all bare 'import foo' statements
    > specify absolute imports (i.e. from sys.path only). To perform a
    > relative import (e.g. from current directory) will require different
    > syntax.


    I'm not completely familiar with either, but how will that influence the
    __import__ function?
     
    Christopher Subich, Aug 11, 2005
    #8
  9. Delaney, Timothy (Tim)

    Roy Smith Guest

    Re: PEP 328, absolute/relative import (was: Re: Bizarre error from help())

    Ben Finney <> wrote:
    > Once PEP 328 is fully implemented, all bare 'import foo' statements
    > specify absolute imports (i.e. from sys.path only). To perform a
    > relative import (e.g. from current directory) will require different
    > syntax.


    It seems like this will break lots of existing code.
     
    Roy Smith, Aug 11, 2005
    #9
  10. Delaney, Timothy (Tim)

    Aahz Guest

    Re: PEP 328, absolute/relative import (was: Re: Bizarre error from help())

    In article <dde6vi$na4$>,
    Ben Finney <> wrote:
    >
    >So, under PEP 328 rules, the original poster's current-directory
    >module could only be imported (a) if the current directory was in
    >sys.path, or (b) if the code specified a relative import. The
    >accidental shadowing of the stdlib module could not happen.


    Normally the current directory *is* on sys.path, and the first thing,
    too:

    >>> sys.path

    ['', '/usr/local/lib/python24.zip', '/usr/local/lib/python2.4', '/usr/local/lib/python2.4/plat-netbsd2', '/usr/local/lib/python2.4/lib-tk', '/usr/local/lib/python2.4/lib-dynload', '/usr/local/lib/python2.4/site-packages']
    --
    Aahz () <*> http://www.pythoncraft.com/

    The way to build large Python applications is to componentize and
    loosely-couple the hell out of everything.
     
    Aahz, Aug 11, 2005
    #10
  11. Delaney, Timothy (Tim)

    Ben Finney Guest

    Re: PEP 328, absolute/relative import

    Aahz <> wrote:
    > Ben Finney <> wrote:
    > >So, under PEP 328 rules, the original poster's current-directory
    > >module could only be imported (a) if the current directory was in
    > >sys.path, or (b) if the code specified a relative import. The
    > >accidental shadowing of the stdlib module could not happen.

    >
    > Normally the current directory *is* on sys.path, and the first
    > thing, too:


    Ah. I'd forgotten that, my bad.

    So, modules in the current directory will continue to be imported as
    before, because they *are* absolute imports by PEP328 definitions.

    --
    \ "If it ain't bust don't fix it is a very sound principle and |
    `\ remains so despite the fact that I have slavishly ignored it |
    _o__) all my life." -- Douglas Adams |
    Ben Finney <http://www.benfinney.id.au/>
     
    Ben Finney, Aug 11, 2005
    #11
  12. Delaney, Timothy (Tim)

    Peter Hansen Guest

    Re: PEP 328, absolute/relative import

    Ben Finney wrote:
    > Aahz <> wrote:
    >>Ben Finney <> wrote:
    >>>So, under PEP 328 rules, the original poster's current-directory
    >>>module could only be imported (a) if the current directory was in
    >>>sys.path, or (b) if the code specified a relative import. The
    >>>accidental shadowing of the stdlib module could not happen.

    >>
    >>Normally the current directory *is* on sys.path, and the first
    >>thing, too:

    >
    > So, modules in the current directory will continue to be imported as
    > before, because they *are* absolute imports by PEP328 definitions.


    Correct. We'll still be seeing newbies (and the odd experienced
    Pythonista) mistakenly shadowing standard library modules with
    name-colliding local ones well after PEP 328 is fully implemented.
    Gotta keep people on their feet! :)

    -Peter
     
    Peter Hansen, Aug 11, 2005
    #12
  13. Re: PEP 328, absolute/relative import

    On Thu, 11 Aug 2005 08:25:26 -0400, Peter Hansen <> wrote:

    >Ben Finney wrote:
    >> Aahz <> wrote:
    >>>Ben Finney <> wrote:
    >>>>So, under PEP 328 rules, the original poster's current-directory
    >>>>module could only be imported (a) if the current directory was in
    >>>>sys.path, or (b) if the code specified a relative import. The
    >>>>accidental shadowing of the stdlib module could not happen.
    >>>
    >>>Normally the current directory *is* on sys.path, and the first
    >>>thing, too:

    >>
    >> So, modules in the current directory will continue to be imported as
    >> before, because they *are* absolute imports by PEP328 definitions.

    >
    >Correct. We'll still be seeing newbies (and the odd experienced
    >Pythonista) mistakenly shadowing standard library modules with
    >name-colliding local ones well after PEP 328 is fully implemented.
    >Gotta keep people on their feet! :)
    >

    Will/should an __init__.py in the current directory be required,
    to control what happens (and lessen the probability of accidental
    collision from a random working directory)?

    Regards,
    Bengt Richter
     
    Bengt Richter, Aug 11, 2005
    #13
  14. Delaney, Timothy (Tim)

    Peter Hansen Guest

    Re: PEP 328, absolute/relative import

    Bengt Richter wrote:
    > Will/should an __init__.py in the current directory be required,
    > to control what happens (and lessen the probability of accidental
    > collision from a random working directory)?


    I don't think so. That would simply shift the possibility of mysterious
    behaviour from the issue of colliding file names to the issue of whether
    an __init__.py exists somewhere. Shouldn't one be allowed to treat
    files in the current directory as regular Python scripts even if the
    that directory contains an __init__.py so that it can be found as a
    Python package *in other contexts*?

    -Peter
     
    Peter Hansen, Aug 11, 2005
    #14
  15. Re: PEP 328, absolute/relative import

    On Thu, 11 Aug 2005 14:55:57 -0400, Peter Hansen <> wrote:

    >Bengt Richter wrote:
    >> Will/should an __init__.py in the current directory be required,
    >> to control what happens (and lessen the probability of accidental
    >> collision from a random working directory)?

    >
    >I don't think so. That would simply shift the possibility of mysterious
    >behaviour from the issue of colliding file names to the issue of whether
    >an __init__.py exists somewhere. Shouldn't one be allowed to treat
    >files in the current directory as regular Python scripts even if the
    >that directory contains an __init__.py so that it can be found as a
    >Python package *in other contexts*?
    >

    Hm. When you say "regular scripts," do you mean as in

    some_shell_prompt> python script.py

    or do you mean in an interactive session, as in

    >>> import script


    ?
    I think the first should be unaffected by __init__.py, but
    the second is slated to become an absolute import (IIUC) that
    will search the python path. Packages have to have __init__.py
    in order to be searched in dotted paths, so why shouldn't the
    current-working-directory-as-package-on-the-path also?

    IOW, the mysterious shadowing could only happen if you
    were mucking around in one of your path directories as cwd.
    An ordinary directory as cwd would not be searched first
    unless you gave it that priority with an __init__.py AND
    being there as cwd. You could do that for convenience
    without making it part of your normal path (except by
    being there as cwd, which you would only do for that project
    and desired shadowing effect).

    Then if you really wanted a one-shot override, in an
    un-marked-with-__init__.py directory, maybe

    >>> from . import script


    could possibly allow the cwd import without __init__.py
    since the cwd at interpreter startup is probably a reasonable
    interpretation of '.' in that case.

    .... just thinking out loud ;-)

    Regards,
    Bengt Richter
     
    Bengt Richter, Aug 11, 2005
    #15
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    0
    Views:
    404
  2. omission9
    Replies:
    3
    Views:
    352
    Ziaran
    Feb 23, 2004
  3. Roy Smith

    Bizarre error from help()

    Roy Smith, Aug 10, 2005, in forum: Python
    Replies:
    0
    Views:
    268
    Roy Smith
    Aug 10, 2005
  4. Neo Geshel

    Bizarre literal.text error

    Neo Geshel, Feb 25, 2007, in forum: ASP .Net
    Replies:
    4
    Views:
    424
    Tim Clark
    Feb 26, 2007
  5. Replies:
    11
    Views:
    632
    bhadorn
    Aug 12, 2007
Loading...

Share This Page