error messages unclear

[Chad Netzer]

On Thursday 05 December 2002 18:47, Paul G. wrote:
> > On Tuesday 03 December 2002 17:05, Paul G. wrote:

   Actually, you clipped out the attribution of my reply, which is 
irksome to me, but I'll forgive you.

> > $ python
> > Python 2.2.2 (#1, Nov 21 2002, 08:18:14)
> > >>> import sys
> > >>> import os
> > >>> os.path
> > <module 'posixpath' from '/usr/lib/python2.2/posixpath.pyc'>
>
> Ok.  So where is your 'posixpath' defined?  How is it defined? 
> Why is it defined the way that it is?  Is it defined based on
> uname, pyconfig.in.h, pyconfig.h or something else entirely?

You should have a file called "posixpath.py".  On my unix system, 
it is in "/usr/lib/python2.2/posixpath.py".  Judging by the output 
you provided, on your system it should probably at least be in:

\msys\1.0\src\python-2.2.1/Lib/posixpath.py

That is where it should reside in the build directory.  That 
doesn't mean that the python executable itself can find it there 
(Because the executable looks for things in the installation path, 
and my guess is that the build process isn't setting that up 
correctly)

You should run python.exe manually, and type in the following, 
which will tell you where python is looking for it's default 
library files:

import sys
print sys.path

For example, on Linux, mine is:

[$ python
Python 2.2.2 (#1, Nov 21 2002, 08:18:14) 
>>> import sys
>>> print sys.path
['', '/usr/lib/python2.2', '/usr/lib/python2.2/plat-linux2', 
'/usr/lib/python2.2/lib-tk', '/usr/lib/python2.2/lib-dynload', 
'/usr/local/lib/python2.2/site-packages', 
'/usr/local/lib/python2.2/site-packages/SpecialFuncs', 
'/usr/local/lib/site-python', '/usr/lib/python2.2/site-packages', 
'/usr/lib/python2.2/site-packages/Numeric']

It'll be different for windows, but the idea is that same.  
posixpath.py needs to be in one of those directories for things to 
work.


> > If I delete os.path, I will get the error you saw:
>
> 	Still is not clear as to what you define as os.path.
>
> 	os.path=?.  Why, where, how?

"os" is a module, which is the result of the "import os" command in 
python.  "os" is then an object which provides services.

Similarly, os.path is also a module, and is automatically set up 
when you import os.  By this, I mean that os.path is ALSO an 
object, and it also provides services:

[chad at sayge:~]$ python      
Python 2.2.2 (#1, Nov 21 2002, 08:18:14) 
>>> import os
>>> type( os )
<type 'module'>
>>> type( os.path )
<type 'module'>
>>> dir( os.path )
['__all__', '__builtins__', '__doc__', '__file__', '__name__', 
'_varprog', 'abspath', 'basename', 'commonprefix', 'dirname', 
'exists', 'expanduser', 'expandvars', 'getatime', 'getmtime', 
'getsize', 'isabs', 'isdir', 'isfile', 'islink', 'ismount', 'join', 
'normcase', 'normpath', 'os', 'realpath', 'samefile', 
'sameopenfile', 'samestat', 'split', 'splitdrive', 'splitext', 
'stat', 'walk']

The source code (written in Python itself) for the os.path module 
in is posixpath.py file.  (It is NOT a C language file, it is 
implemented in Python itself, so it only needs to be findable by 
the python executable)

At this point, if you don't understand what I'm saying, I can only 
suggest that you go back to the python tutorial to learn more about 
how the Python language itself works.

Not that if I were to delete the the posixpath.py file in my 
installed Python enviroment (and the byte-compiled versions of it), 
then I would probably also get the error you are getting, since 
python cannot use that module if it can't locate the source code 
for it (or the compiled .pyc file).

Heck, I'll even do it for you:  (deleting 
/usr/lib/Python2.2/posixpath.py and related files)

[chad at sayge:~]$ python
'import site' failed; use -v for traceback
>>> import os
>>> os.path
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
AttributeError: 'module' object has no attribute 'path'

So, when python can't find posixpath.py, I get the same exact error 
message you are getting, when I try to use it (note- ignore the 
fact I'm using version 2.2; it is the same for the version you are 
using)


> > > 	I am not using Cygwin.
> 	Specifically it is a gcc and it is a variation/fork on Cygwin. 

Okay, it isn't the compiler or OS, per se.  But, it may be related 
to the execution environment (shell, unix commands, etc.) if the 
python library files aren't being installed in the right place.  
But, I'll leave that be for now...

> 	That mixed separator stuff may be causing it.  I am asking if it
> is or it is not, amongst other things.

Well, python itself is pretty smart about dealing with mixed 
separators, but the install environment may not be.

> 	Ok.  So, in fact, you don't know what is going on with it
> either.  That would indicate to me that the AttributeError: is
> really quite meaningless aside from the assumption you made in
> terms of a particular 'path' value.

Forget about AttributeError; it is, as you say, a "red herring".  
It is the installation of the python executable's library files 
that is causing the problem.  The AttributeError is simply a 
symptom of a non-working install.

Perhaps you need to do a "make installation" or "make install", to 
get all the files in the right place, before you run the tests.  
Also, you may need to provide appropriate options to the 
"configure" command before building (such as "--prefix")


> 	(term "module', below, is not clear to me within the context of
> python.  There are modules and there are 'modules'.  Which module
> are we talking about here?  A python module or something else
> entirely?

Now you lost me.  A module is what is imported with the "import" 
statement.  They can be implemented in C, they can be implemented 
in Python.  They can be built as shared libraries, they can be 
compiled into the executable (for C implementations).  The 
posixpath.py file that provides the "os.path" module is the 
particular problem here.  The fix is likely in how you configure 
the setup before it is built.


> 	I have built python.  The working version of python that I have
> is one I have already built from cvs source.

Okay, then you need to change something about the configuration 
before you build, probably the default path where library files are 
installed.

[snip]

Well, that is enough for now.  I'm know not why you are building 
python from scratch before you have experience with it, but the 
reasons are your own.  I can only suggest you try to become a bit 
more knowledgable about Python, and the build tools.  Doing the 
build is a great way to learn these things, but you must give the 
details from ground one.  For example, here are the (very basic) 
steps I just used to build Python on my Unix box:

$ cd Python-2.1.3
$ ./configure
$ make
$ ./python setup.py build
$ make test
$ make install

Now, under windows, depending on what shell and tools you are 
using, it may be this simple, or it may take some tweaking.  If you 
posted the PRECISE steps you took to build python (sans output, 
just the commands you used), we might be able to help you further.  
Otherwise, my best advice is to experiment with the basic build 
directions just above (especially "configure").  Also, is it really 
failing in the "make" stage, or the "make test" stage?  If the 
latter, you need to look at the Cygwin section of the README file 
(yes, yes, it isn't Cygwin...  But it isn't Unix either, is it.)

-- 
Bay Area Python Interest Group - http://www.baypiggies.net/

Chad Netzer
cnetzer at mail.arc.nasa.gov