[Tutor] about an error message

[Danny Yoo]

On Tue, 29 Apr 2003, Abdirizak abdi wrote:

> Hi I was runing an old version of python program for indexing, I tried
> to runthe program but it is giving me an error message which is not
> recognising a certain module, can anyone with experience in previous
> python versions have a look at this code, and give me what is going onit
> gives me an error from this line: os.symlink(file, os.path.join(dir,
> filename))


Hi Abdirizak,


Can you also tell us what the error message says?  You don't have to
paraphrase it; it's actually preferable if you copy and paste the error
lines verbatim.  Giving us the line number is helpful, but it's often not
enough: the error message itself and its traceback often give subtle hints
that give us more details.  Showing us the error message will help us
pinpoint exactly where Python is getting confused.  *grin*


The functions os.symlink() and os.path.join() did exist back in the Python
1.52 days,

    http://www.python.org/doc/1.5.2p2/lib/os-file-dir.html#l2h-892
    http://www.python.org/doc/1.5.2p2/lib/module-os.path.html#l2h-955

So we may not be able to confirm that it's a Python version problem until
we see the literal error message.



> Also the code had an import statement of module called posix and
> apparantly it also doesn't recognise that.

Odd!  Can you show us the error message that occurs if you try 'import
posix'?  This is really weird, as 'posix' is also in 1.5.2:

    http://www.python.org/doc/1.5.2p2/lib/module-posix.html

as well as 1.4,

  http://www.python.org/doc/1.4/lib/node74.html#SECTION00910000000000000000

So as far as we're concerned, posix has been there forever.  *grin* You
need to show us the error message, so that we can limit the number of
hypotheses we need to test to diagnose the problem.

I don't think it's a versioning problem, but it may be an installation or
library problem on your system.  Tell us more about what happens with that
import statement.



Let's take a look at the code a little more.

> jumper = random.Random()
> jumper.seed()
> serial = 0
> def linkfileinto(dir, file):
>     while 1:
>         global serial
>         serial = serial + 1
>         filename = str(serial)
>         try:
>             # XXX assumes symlink() is atomic
>             os.symlink(file, os.path.join(dir, filename)) <--- the problem i

So there are some possibilities here.  If we assume that os.syslink() and
os.path.join() are working if we give them good values, we still have a
few things here to check that we've given them good values.  What values
do 'file', 'dir' and 'filename' contain when the code breaks?



>             return filename
>         except OSError, err:
>             err_errno, msg = err
>             if err_errno == errno.EEXIST:
>                 serial = serial + 10**jumper.randrange(3)
>             else:
>                 raise
                  ^^^^^

That last line looks a little suspicious.  The code here is raising
something, but raising....  what?  *grin* There seems to be something
missing here --- the raise statement needs to raise a specific class or
instance as an exception: we can't just leave it hanging like that:

###
>>> raise ValueError
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
ValueError
>>>
>>>
>>> raise
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
TypeError: exceptions must be strings, classes, or instances, not NoneType
###


... well, we _could_, but the exception that gets raised will mumble about
"exceptions must be strings...", and that obscures the real problem about
the unrecognized OSError.  So the code should probably say something like:

###
         except OSError, err:
             err_errno, msg = err
             if err_errno == errno.EEXIST:
                 serial = serial + 10**jumper.randrange(3)
             else:
                 raise OSError, err  ## raise the error again for
                                     ## outside world to check.
###

so that we get better debugging information.




Good luck to you!