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
http://mail.python.org/mailman/
[Martin v. Loewis wrote]
> Trent Mick wrote:
> > C:\trentm\src\python\python\PCbuild>svn 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 "_elem
Trent Mick wrote:
> [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\
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
>
Trent Mick wrote:
> C:\trentm\src\python\python\PCbuild>svn 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
[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\PCbuild>python
Python 2.5a0
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 n
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 buildin
At 02:19 AM 12/15/2005 +, Steve Holden wrote:
>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 (_elem
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,
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
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 wr
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 th
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
fr
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 impor
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 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
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
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 th
Barry Warsaw wrote:
> 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 th
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 alway
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
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 imp
On Wednesday 14 December 2005 09:51, Steve Holden wrote:
> Which reminds me, what about the idea of reducing certain packages
> (Carbon, dostutils and email come to mind) to just a single entry in the
> global module index and adding a first-level TOC at the beginning of
> that section of conte
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 wi
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 available as a sep
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 k
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 insta
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
On 12/13/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> 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:
>
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
On Tuesday 13 December 2005 14:52, Fredrik Lundh wrote:
> I take that as a "go ahead" ;-)
Good call! :-)
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscri
Fredrik Lundh wrote:
> comments ?
As Fred says: go ahead.
regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail
Fred L. Drake, Jr. wrote:
> > 1. add an Include/pyexpat.h header file which contains a structure
> > similar to the following:
> ...
> > comments ?
>
> +1
I take that as a "go ahead" ;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://m
On Tuesday 13 December 2005 11:22, Fredrik Lundh wrote:
> here's a plan:
>
> 1. add an Include/pyexpat.h header file which contains a structure
> similar to the following:
...
> comments ?
+1
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev maili
Martin v. Löwis wrote:
> > - sort out expat bundling issues, and include cElementTree as well
> > (using the same approach as above).
...
> > (one way to do this would be to add an "function pointer table" to pyexpat
> > that contains pointers to selected portions of the expat API, and the
36 matches
Mail list logo
