[Python-Dev] Incorporation of zlib sources into Python subversion
Thomas (Heller) and I have been discussing whether the zlib module should become builtin, atleast on Win32 (i.e. part of python25.dll). This would simplify py2exe, which then could bootstrap extraction from the compressed file just with pythonxy.dll (clearly, zlib.pyd cannot be *in* the compressed file). We currently don't do this, because the pythoncore.vcproj would then not be buildable anymore unless you also have the right version of zlib on disk. To solve this, Thomas has proposed that the Python release could incorporate a copy of zlib, primarily for use on Windows (with the project files appropriately adjusted). I'm in favour of such a change: the library is fairly small, and it would not only simplify py2exe, but also simplify the build process. Whether or not this copy of zlib would be integrated in the Unix build process, in case where the system does not provide a zlib, is a separate question. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ref leak in element tree/pyexpat
Neal Norwitz wrote: > Also, I noticed several places where errors where being ignored. What > is the procedure for the element tree? Are we supposed to modify it > in the python SVN or treat it as read-only? You should add a bug report on sf.net/projects/python, and assign that to Fredrik Lundh. Likewise, if you have a patch. Regards, Martin P.S. In principle, Fredrik agreed that others could also do bug fixes on that tree (but no new features), so checking the fix in would be allowed also. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ref leak in element tree/pyexpat
Neal Norwitz wrote:
> I'm not sure where the problem is, but this code leaks a reference:
>parser = ET.XMLParser() ; parser.feed('text')
>
> You need this to set it up:
> from xmlcore.etree import cElementTree as ET
>
> This isn't a memory leak according to valgrind.
looks like it's stealing more None references than it should. here's a more
isolated test case:
tree = ET.TreeBuilder()
tree.start("x")
tree.data("text")
tree.end("x")
if you remove *either* the data or the end call, the leak goes away. I'll
take a look.
> Also, I noticed several places where errors where being ignored. What
> is the procedure for the element tree? Are we supposed to modify it
> in the python SVN or treat it as read-only?
the overall goal is to be able to say that Python X.Y.Z ships with Element-
Tree A.B.C. to achieve this, the Python SVN should be treated as mostly
read-only -- with the exception of critical errors (crashes seen in the wild,
serious leaks, security issues, etc) and build/portability issues.
> The patch below fixes a few small problems. There were some others I
> noticed, but didn't add to the patch.
thanks. I'll fix these (and a few others) in the next "official" release.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] fresh checkout won't build
$ svn up At revision 41759. $ make ... Python/compile.c: In function `PyNode_Compile': Python/compile.c:301: parse error before `mod' Python/compile.c:302: `mod' undeclared (first use in this function) Python/compile.c:302: (Each undeclared identifier is reported only once Python/compile.c:302: for each function it appears in.) make: *** [Python/compile.o] Error 1 $ make distclean; ./configure; make Python/compile.c: In function `PyNode_Compile': Python/compile.c:301: parse error before `mod' Python/compile.c:302: `mod' undeclared (first use in this function) Python/compile.c:302: (Each undeclared identifier is reported only once Python/compile.c:302: for each function it appears in.) make: *** [Python/compile.o] Error 1 what am I missing ? (old linux, old linux, built just fine yesterday) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] fresh checkout won't build
> $ svn up > At revision 41759. > $ make > ... > Python/compile.c: In function `PyNode_Compile': > Python/compile.c:301: parse error before `mod' > Python/compile.c:302: `mod' undeclared (first use in this function) > Python/compile.c:302: (Each undeclared identifier is reported only once > Python/compile.c:302: for each function it appears in.) > make: *** [Python/compile.o] Error 1 > > $ make distclean; ./configure; make > Python/compile.c: In function `PyNode_Compile': > Python/compile.c:301: parse error before `mod' > Python/compile.c:302: `mod' undeclared (first use in this function) > Python/compile.c:302: (Each undeclared identifier is reported only once > Python/compile.c:302: for each function it appears in.) > make: *** [Python/compile.o] Error 1 > > what am I missing ? a C++ compiler, obviously, the arena code used C++ (C99?) constructs in a couple of places. I've checked in a fix. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
Hi Barry,
On Sat, Dec 17, 2005 at 08:28:17PM -0500, Barry Warsaw wrote:
> Done. r41744.
Doesn't appear to work for me: sys.build_number receives the value from
the buildno. Looking at the Makefile, the reason is that I'm building
CPython in a separate directory (running '/some/path/configure; make').
Running 'svnversion .' by hand is quite fast if the whole tree of files
is in the cache. My guess is that if you do 'svn up; make' then the
tree will indeed be in the cache, so the extra build time shouldn't be
noticeable in this common case (unless you are low on RAM).
Do we have any plan to make sys.build_number meaningful in the releases
as well (generally compiled from an svn export, as Michael pointed out),
or are we happy with a broken number in this case?
Should I propose / check-in a patch to expose sys.build_info instead
("CPython", "41761", "trunk"), as this got positive feedback so far?
It's also less surprizing than the current sys.build_number, which is a
string despite its name.
A bientot,
Armin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
Armin Rigo wrote:
> Should I propose / check-in a patch to expose sys.build_info instead
> ("CPython", "41761", "trunk"), as this got positive feedback so far?
> It's also less surprizing than the current sys.build_number, which is a
> string despite its name.
fwiw, I'm still +1 on that.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
Armin Rigo wrote:
> Do we have any plan to make sys.build_number meaningful in the releases
> as well (generally compiled from an svn export, as Michael pointed out),
> or are we happy with a broken number in this case?
I'm actually a bit confused that Barry changed the meaning of "build
number" for that feature. The build number was meant to count builds,
not revisions (whether this is a useful feature or not).
So I would argue that it is "broken" when it is the result of
svnversion, and "good" when it actually counts builds.
It stopped counting builds on Windows quite some time ago; perhaps it
is best to drop the build number entirely?
> Should I propose / check-in a patch to expose sys.build_info instead
> ("CPython", "41761", "trunk"), as this got positive feedback so far?
> It's also less surprizing than the current sys.build_number, which is a
> string despite its name.
Propose first. I have the feeling that the feature will change forth
and back if everybody gets to say something. I would call it
sys.svnversion (because that's what it is).
What to put in in case of tagged builds is then yet another question.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
Martin v. Löwis wrote: > Propose first. I have the feeling that the feature will change forth > and back if everybody gets to say something. I would call it > sys.svnversion (because that's what it is). Perhaps it could make sense for sys.svnversion to exist only in a debug build. This way people won't use it to test for release versions. Reinhold -- Mail address is perfectly valid! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] fresh checkout won't build
Fredrik Lundh wrote: >>what am I missing ? > > > a C++ compiler, obviously, the arena code used C++ (C99?) constructs > in a couple of places. I've checked in a fix. C99 also allows to declare variables in the middle of a block. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] fixing log messages
just noticed an embarrasing misspelling in one of my recent checkins, only to find that I cannot fix it: $ svn propedit --revprop -r 41759 svn:log svn: Repository has not been enabled to accept revision propchanges; ask the administrator to create a pre-revprop-change hook $ would it be a good idea to ask the administrator to do this ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
"Martin v. Löwis" <[EMAIL PROTECTED]> writes: > It stopped counting builds on Windows quite some time ago; perhaps it > is best to drop the build number entirely? +1. I don't see how the information it contributes is meaningful in any way. Cheers, mwh -- Gullible editorial staff continues to post links to any and all articles that vaguely criticize Linux in any way. -- Reason #4 for quitting slashdot today, from http://www.cs.washington.edu/homes/klee/misc/slashdot.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] fixing log messages
Fredrik Lundh wrote: > just noticed an embarrasing misspelling in one of my recent checkins, only > to find that I cannot fix it: > > $ svn propedit --revprop -r 41759 svn:log > svn: Repository has not been enabled to accept revision propchanges; > ask the administrator to create a pre-revprop-change hook > $ > > would it be a good idea to ask the administrator to do this ? I have now installed this hook to allow editing svn:log; please try again. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] fixing log messages
Martin v. Löwis wrote: > I have now installed this hook to allow editing svn:log; please try > again. $ svn propedit --revprop -r 41759 svn:log Set new value for property 'svn:log' on revision 41759 thanks! /F ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorporation of zlib sources into Python subversion
Martin v. Löwis wrote: > Thomas (Heller) and I have been discussing whether the zlib > module should become builtin, atleast on Win32 (i.e. part > of python25.dll). This would simplify py2exe, which then could > bootstrap extraction from the compressed file just with > pythonxy.dll (clearly, zlib.pyd cannot be *in* the compressed > file). Question: I am trying to enable other compression forms in zipfile, in particular bzip2, but eventually extensible. My primary intent is to extend the useful life of .zips by allowing better compression (and enabling reading and writing zip formats that are starting to be created from other sources). Would it make sense to include bzip2 in here as well (if the zipfile changes go in)? --Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
On Sun, 2005-12-18 at 18:58 +0100, Armin Rigo wrote:
> On Sat, Dec 17, 2005 at 08:28:17PM -0500, Barry Warsaw wrote:
> > Done. r41744.
>
> Doesn't appear to work for me: sys.build_number receives the value from
> the buildno. Looking at the Makefile, the reason is that I'm building
> CPython in a separate directory (running '/some/path/configure; make').
Right. That's easily fixable by prepending $(srcdir) in front of the
test path and for the svnversion command. I'm testing that patch now.
> Do we have any plan to make sys.build_number meaningful in the releases
> as well (generally compiled from an svn export, as Michael pointed out),
> or are we happy with a broken number in this case?
Yes, here's my thought: I have a mod to Makefile.pre.in and
getbuildinfo.c so that when we don't find .svn directory, we don't
define the BUILD macro when we compile getbuildinfo.c. Then, in that
file we have something like:
#ifndef BUILD
#define BUILD "$Revision$"
#endif
Py_GetBuildNumber() grows a bit of logic to yank out the revision number
from that string, but that's all pretty straightforward. I don't think
svn has an equivalent of cvs's -kv switch. I've tested most of this,
but I'll have to commit the new getbuildinfo.c to test the export part.
> Should I propose / check-in a patch to expose sys.build_info instead
> ("CPython", "41761", "trunk"), as this got positive feedback so far?
> It's also less surprizing than the current sys.build_number, which is a
> string despite its name.
I'm still unsure about this, so I won't check this change yet. But I'm
okay with that if people want, though I think the banner should probably
still just contain the revision number.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
On Sun, 2005-12-18 at 19:19 +0100, "Martin v. Löwis" wrote: > It stopped counting builds on Windows quite some time ago; perhaps it > is best to drop the build number entirely? I think so, because it doesn't really convey anything useful. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
Barry Warsaw wrote: > Yes, here's my thought: I have a mod to Makefile.pre.in and > getbuildinfo.c so that when we don't find .svn directory, we don't > define the BUILD macro when we compile getbuildinfo.c. Then, in that > file we have something like: > > #ifndef BUILD > #define BUILD "$Revision$" > #endif What does that achieve? It will give you the latest revision at which getbuildinfo was changed (currently 41744). Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Incorporation of zlib sources into Python subversion
Scott David Daniels wrote: > I am trying to enable other compression forms in zipfile, in > particular bzip2, but eventually extensible. My primary intent > is to extend the useful life of .zips by allowing better > compression (and enabling reading and writing zip formats that > are starting to be created from other sources). That's a good plan; I hope you make it compatible with WinZIP. > Would it make > sense to include bzip2 in here as well (if the zipfile changes > go in)? I don't think so. People relying on the builtin compression support of pythonxy.dll would have to make sure the files are compressed with zlib. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Expose Subversion revision number to Python
On Sun, 2005-12-18 at 23:48 +0100, "Martin v. Löwis" wrote: > What does that achieve? It will give you the latest revision at which > getbuildinfo was changed (currently 41744). Dunno. It's better than nothing I guess. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] DRAFT: python-dev summary for 2005-11-16 to 2005-11-31
Steven Bethard wrote: > Note that because of the way the subversion conversion was done, > by-date revision specifications for dates prior to the switchover > won't work. To work around this, you can use svn diff (find the > changes since some date), svn up (check out revision a some date), and > svn annotate (aka svn blame). It's actually different: you *cannot* use svn diff or svn up with a date, since that is what isn't working. As a work-around, you need a revision /number/ (instead of a date), and you can get them through svn log or svn blame. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
