[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-distutils-sig
Subject:    [XML-SIG] Re: [Distutils] Disposition of C extensions and packages
From:       akuchlin () mems-exchange ! org (Andrew M !  Kuchling)
Date:       1999-12-19 23:51:15
Message-ID: 14429.28531.133654.92967 () amarok ! cnri ! reston ! va ! us
[Download RAW message or body]

M.-A. Lemburg writes:
>If you maintain packages with C extensions for several
>platforms, you can simply install the packages under
>the platform subdirs in /usr/local/lib/python1.5 -- one
>copy for every platform. Disk space is no argument anymore
>nowadays.

Hmmm... disk space is no longer a problem, but maintaining those
parallel trees might be a problem; if a bugfix is released as a patch
to Python code, you'd have to apply it to several trees.  On the other
hand, this isn't a very common way of fixing bugs in the Python
community; a .1 release is more common.  So your point is a good one;
this would argue that the Distutils should make it easier to build
things in one tree, and then install things under the right plat-
directory.

-- 
A.M. Kuchling			http://starship.python.net/crew/amk/
He felt that his whole life was some kind of dream and he sometimes wondered
whose it was and whether they were enjoying it.
    -- Douglas Adams, _The Hitch-Hiker's Guide to the Galaxy_






>  >> 2) Another general question, this time o: how should this be >>
> handled?  Should C extensions always be effectively >> top-level,
> and therefore go into site-packages?  Should >> there be an xml
> package holding .py files, and an X package >> holding all the C
> extensions? (X = 'plat_xml', >> 'xml_binary', or something like
> that) > >Just leave them in the package. I use a separate subpackage
> >for the C extension which the packages modules then import.  >This
> makes mixed Python + C extensions and prototyping of >C APIs in
> Python very simple and straight forward.  >> 4) Distutils question:
> is this a problem with the Distutils >> code that needs fixing?  I
> suspect not; if the tools make >> it difficult to do stupid things
> like mix .py and .so >> files, that's a good thing.  > >I wouldn't
> like this; for a very simple reason: if someone >wants to provide a
> Python rewrite of a C module which works >as dropin replacement, the
> only way to handle this is by >having a .so file and a .py file with
> the same name in the >same directory. mxDateTime uses such a setup,
> for example.  > >Note that .so files are found before .py files,
> thus if >someone does have the .so file, Python will use the >C
> module and not the Python one.  > >-- >Marc-Andre Lemburg
> >______________________________________________________________________
> >Y2000: 13 days left >Business: http://www.lemburg.com/ >Python
> Pages: http://www.lemburg.com/python/ > >
> >_______________________________________________ >XML-SIG maillist -
> XML-SIG@python.org >http://www.python.org/mailman/listinfo/xml-sig >


[prev in list] [next in list] [prev in thread] [next in thread]