Phillip J. Eby wrote:
I don't know. I can see that the split makes sense for prefix/exec-prefix
distinctions, but then again, the disutils will install an entire
distribution in exec-prefix if it contains impure parts, so that's
certainly an option here.
On the other hand, it's not
[Fredrik Lundh wrote]
can anyone with a working windows setup look at building the
_elementtree module for windows ?
(see the setup.py file for build options; it wants the same defines
as pyexpat, plus one extra define.).
C:\trentm\src\python\python\PCbuildpython
Python 2.5a0 (#60,
Trent Mick wrote:
C:\trentm\src\python\python\PCbuildsvn st
A _elementtree.vcproj
M pcbuild.sln
Shall I checkin the build changes?
Go ahead. A change to Tools/msi/msi.py is also in order.
Regards,
Martin
___
Python-Dev
At 09:30 PM 12/15/2005 +0100, Martin v. Löwis wrote:
Phillip J. Eby wrote:
I don't know. I can see that the split makes sense for prefix/exec-prefix
distinctions, but then again, the disutils will install an entire
distribution in exec-prefix if it contains impure parts, so that's
[Martin v. Loewis wrote]
Trent Mick wrote:
C:\trentm\src\python\python\PCbuildsvn st
A _elementtree.vcproj
M pcbuild.sln
Shall I checkin the build changes?
Go ahead. A change to Tools/msi/msi.py is also in order.
Okay, done. I naively added _elementtree to the
Trent Mick wrote:
Okay, done. I naively added _elementtree to the extensions list in
msi.py. I'm guessing that that was all that was necessary.
Right. Thanks!
Martin
___
Python-Dev mailing list
Python-Dev@python.org
Michael McLay wrote:
On Wednesday 14 December 2005 01:05, Fredrik Lundh wrote:
Michael McLay wrote:
Avoiding imaginaary name collisions and putting cElementTree into the xml
package
there's nothing imaginary here -- cElementTree is an existing and quite
popular module, and will remain
Phillip J. Eby wrote.
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
does anyone have a better idea ?
I was under the impression that simply
Fredrik Lundh wrote:
Phillip J. Eby wrote.
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
does anyone have a better idea ?
I was under the
On Wed, 2005-12-14 at 09:56 -0800, Scott David Daniels wrote:
One good reason for this is that the .pyd's or .so's cannot necessarily
be used from zip files
When you say cannot necessarily, are the situations where they can be
imported from zip files? I thought the answer to that was always
Scott David Daniels wrote:
One good reason for this is that the .pyd's or .so's cannot necessarily
be used from zip files
When you say cannot necessarily, are the situations where they can be
imported from zip files? I thought the answer to that was always no.
I thought so too, but
On Wed, 2005-12-14 at 20:21 +0100, Fredrik Lundh wrote:
you could of course add them to the zip file, and automagically extract
them before you start importing things.
Sure (although we don't). I wonder if this is useful functionality for
the core.
-Barry
signature.asc
Description: This
At 08:21 PM 12/14/2005 +0100, Fredrik Lundh wrote:
Scott David Daniels wrote:
One good reason for this is that the .pyd's or .so's cannot necessarily
be used from zip files
When you say cannot necessarily, are the situations where they can be
imported from zip files? I thought
At 09:56 AM 12/14/2005 -0800, Scott David Daniels wrote:
My (admittedly weak) understanding of how packages work is that all
parts of a package should lie off the same node of the PYTHONPATH.
This isn't a requirement; packages have a __path__ attribute which can
include more than one directory.
At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote:
Phillip J. Eby wrote.
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
does anyone
Phillip J. Eby wrote:
At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote:
Phillip J. Eby wrote.
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
does
Py2exe manages to load .pyd files and dlls from zip. Apparently they have
written an alternate dll loader that does not need the file to be on the file
system. This is used for single file apps.
I don't know if it is possible to write a portable Unix equivalent for .so
files.
-Chris
P.S. I
On 12/14/05, Chris Lambacher [EMAIL PROTECTED] wrote:
Py2exe manages to load .pyd files and dlls from zip. Apparently they have
written an alternate dll loader that does not need the file to be on the file
system. This is used for single file apps.
I don't know if it is possible to write a
On Dec 14, 2005, at 5:31 PM, Alex Martelli wrote:
On 12/14/05, Chris Lambacher [EMAIL PROTECTED] wrote:
Py2exe manages to load .pyd files and dlls from zip. Apparently
they have
written an alternate dll loader that does not need the file to be
on the file
system. This is used for
Scott David Daniels wrote:
Phillip J. Eby wrote:
At 05:51 PM 12/14/2005 +0100, Fredrik Lundh wrote:
Phillip J. Eby wrote.
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from
I wrote:
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
I've implemented this, for now.
can anyone with a working windows setup look at building the
I wrote:
1. add an Include/pyexpat.h header file which contains a structure
similar to the following:
2. during pyexpat initialization, initialize all members of this structure,
and
make it available as a PyCObject:
3. in cElementTree (or _elementtree, or whatever the python version will
At 11:17 PM 12/13/2005 +0100, Fredrik Lundh wrote:
my current idea is to
1. include it under a different name (_elementtree.so)
2. add a cElementTree.py under xml.etree, which simply does
from _elementtree import *
does anyone have a better idea ?
I was under the
On Tuesday 13 December 2005 17:17, Fredrik Lundh wrote:
the remaining issue is how to include cElementTree. the current stand-
alone distribution consists of a single cElementTree module, which is in-
stalled under site-packages, as usual.
to avoid collisions, it's probably best to install
Michael McLay wrote:
Avoiding imaginaary name collisions and putting cElementTree into the xml
package
there's nothing imaginary here -- cElementTree is an existing and quite popular
module, and will remain available as a separate distribution.
it would be nice if people could install that
25 matches
Mail list logo
