error messages unclear

[Paul G.]

> 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.

thanks...

> 
> > > $ 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

	Yep.  That is where it is.

	(absolute reference, relative reference=/usr/src/python-2.2.1/Lib/posixpath.py)

> 
> That is where it should reside in the build directory.

	Ok.

>  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)

	The executable is actually in usr/src/Python-2.2.1.  That is where the make expects it to 
be.

> 
> 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

	This yields the following (Python output):

>>> import sys
>>> print sys.path
['', 'd', '\\msys\\1.0\\src\\Python-2.2.1/Lib/', 'd', '\\msys\\1.0\\src\\Python-
2.2.1/Lib/plat-mingw32_nt-4.01', 'd', '\\msys\\1.0\\src\\Python-2.2.1/Lib/lib-tk
', 'd', '\\msys\\1.0\\src\\Python-2.2.1/Modules']

> 
> 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.

	Not necessarily, but understand your consideration.  Much depends on the actual build 
environment, as you have indicated.

> 
> 
> > > 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 I am with you.  I understand the differences you are talking about.  It is why I 
asked the question, I think, in the first place.  Thanks for the clarification on this.

[snip -- hope that isn't a problem]

> 
> 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).

	Now you are talking about a .pyc file.  How and/or where is this .pyc file determined 
and/or generated?

> 
> 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 using 2.2.1, not that it matters, as we are talking about what happens at build time, 
not necessarily what happens when python is actually running, though there are references 
to that here as well.

	If posixpath.py is located where it is supposed to be located at (and posixpath.py is 
located where it is supposed to be), why is Python not finding it?

	At this point it is sounding like a "pathing" problem, or simply a problem in terms of 
whether posixpath.py is even being used, even though the "pathing" is appropriate (see 
above in terms of where my posixpath.py is located -- bear in mind, posix file system is not 
fully supported within any Windows build environment except possibly Cygwin.

	As I am not using Cygwin, posix file system is useless except in a very limited way.  In 
other words, the environment I am using does not fully support posix file system.  This of 
course means that a different file system needs to be used for most of the Python file 
references as they are defined for a Unix/Linux system.

	Aside from that, however, there is a VS based distribution for Python.

	Unfortunately, that particular Python distribution depends too much on what I refer to as 
an archaic and primitive means and/or method of building executables that can only work if 
they are built with that archaic and primitive build environment that the manufacturer of the 
Windows Operating Systems authorizes and/or promotes.

	That particular build environment does not meet either my needs or my expectations.  
Nor does it meet the needs or expectations of my clients.


> 
> 
> > > > 	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...

	This is what I am thinking...most especially in terms of the autoconfistication portion of 
the Python distribution.  Not that the autoconfistication tools I am using are to blame, as in 
fact, they are not.  The autoconfistication tools I am using are no different than any others 
that might be used in a Gnu development environment with very few exceptions.

> 
> > 	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.

	That too is something I am considering.

> 
> > 	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.

	Thank you.

	It is good to know that is the case.  I was, for a little while afraid that it was not...

> 
> 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")

	I am aware of that, and I thank you for the reminder.

> 
> 
> > 	(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.

	Ok.   A "module" in the "Python World" is something that is "imported".  Before you 
elaborated on what a "module" was within the "World of Python", I was not clear on what you 
were trying to say.

	Thank you.


> 
> 
> > 	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.

	Actually, the default installation paths are not in question, as those are pretty standard 
(usr/local/lib, etc.).

	What I am doing is working within the Python-2.2.1 directory.  The build has progressed, 
but it is only in pre-install mode right now.  The things that need to be fixed are those things 
that are necessary for the initial processes (pre-install) to be completed.  Once the pre-install 
processes are completed, I have no doubt that the install will work just fine.

	

> 
> [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.

	It is part of the learning process.

>  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.

	It is this simple (same path separators):

 $ cd /src/Python-2.2.1 (or usr/src/Python-2.2.1)
 $ ./configure  --with-cxx=g++ --with-wctype-functions --enable-unicode
> $ make
> $ ./python setup.py build
> $ make test
> $ make install

	This is the way it is supposed to be done for this environment as well.
	I am past the "make", and in to the 

	>$/python setup.py build

		 (which is being auto-generated at the end of the "make" and is in fact part of the 
"make" process).

	It is here that the error referenced is ocurring.


>  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.

	See above.
 
> 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,

	Most definitely at the end of the "make" stage (see above).

> 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.)

	You're correct, neither is it a Unix...when I'm done with it though, you will be able to 
cross-compile it on your most favorite Unix if you should desire to do so.

	I am aware of the reported problems known to occur with Cygwin -- Thankfully, the 
environment I am using does not depend on anything "Cygwinish".  It is why I mentioned that 
it is "not cygwin...".  The problem referenced is a product of a conflict in terms of the Cygwin 
shared files and fork().  This particular problem has to do with how the .dll files (shared files) 
are based for Cygwin.  The environment I am working in does not use the same shared 
image base as Cygwin does.

	Thanks though for the reminder.  I have already sent out some questions to verify if the 
Cygwin limitations noted in the Readme file actually apply where this particular build 
environment is concerned.

	Thanks again,

		Paul G.