Not to add to the work ( Hey - I'll even volunteer to do some of
it as long as we can agree on HOW it should be done! ) but
reorganizing the python library to separate some of the system
dependent stuff might also be a good "clean up" idea. Several
times I have moved the whole tree onto DOS or Mac and started
trying to throw out SGI specific code.
I haven't tried to do it in any organized fashion, since I
didn't think it would be worth the effort if I was just going to
load a NEW distribution on top of it soon. But if you are at
all interested in changing the distribution of the library,
then I'ld be happy enough to only have to do it ONCE, that I'ld
volunteer to try to do the job right.
Right now, SGI specific stuff is the only large amount of
machine specific modules in lib. There are a bunch of stuff
that are currently unix specific, but won't necessarily be
so if we add sockets to Mac and DOS python. But I expect that
we will start accumulating X specific code soon.
That is one of the question - what to do with *contingently*
machine specific code. For another example, I have managed
to build the GL modules for SGI on IBM's AIX, which also
has GL support - but NOT (I *think*) SGI's forms and fonts.
There are rumors that MS-Windows-NT may include GL. So maybe
GL shouldn't be considered SGI specific (?)
We could just split it up as "python/lib" containing generic
modules and below it:
python/lib/sgi
python/lib/X11
python/lib/DOS
python/lib/Mac
etc...
Or is there a better way ? As the library grows we may run into
namespace collisions with modules. Is there some other way -
possibly combined with a modification of the way import works -
to organize it ?
I have already run into a problem where I was trying to make
a "plug replacable" ftplib to fix some problems with the fact
that some Mac ( and probably DOS ) clients don't recognize
the CDUP command, but they DO translate posix like pathnames
into native pathnames ( or at least they do it for the case ".." ).
Rather than patch ftplib, I made a class with ftplib as the
base class. It worked fine when filed and imported as 'myftplib' ,
but I tried, with no success, to figure out how to coerce it
to be imported *as* ftplib ( while still using ftplib from
python/lib ). The point being, that I don't want to make
changes to code in the standard library unless it's going to
be incorporated into the distribution, but I wanted to test
all of the code that imports ftplib using MY ftplib. I can
change PYTHONPATH so it looks in MY directory first, but
what didn't work was to try to then change sys.path so that
MY ftplib could import the OTHER ftplib. ( without changing
the name or copying the original. ) I suppose the easiest
fix that would do more-or-less what I want, would be to put
a symbolic link to python/lib/ftplib in my directory and
import it under THAT name.
Sorry that description is so rambling - "I didn't have time
to make it shorter!" (which is why I didn't mention the problem
when I first ran into it!) There may be another work around -
I once tried playing around with copying and renaming
module.__dict__'s ( just keep an empty .py file around that
you can import to create an empty module to be renamed
and modified! ) and just this sort of trick may be what's
called for here.
But a less kludgey methods would sure be nice.
I don't think namespace collisions are a problem NOW, but
I think it might become one in a year or two, and I think
it might be easier to anticipate and fix the problem NOW
than to wait till the library has grown.
- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics