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.
Also, I noticed several places where errors where being
On 11/21/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
>
> > I just checked in the modification below. I'm not sure if this
> > behaviour is on purpose or by accident.
[ /f shows diff on linux and windows ]
I checked in a fix for this so float('0x3') should not work on any p
On Sat, 2005-12-17 at 23:48 +0100, "Martin v. Löwis" wrote:
> Barry Warsaw wrote:
> > AFAICT, the reason to use -c is so that changes outside the Python
> > source tree (i.e. in the sandbox) won't show up in Python's build
> > number. That's fine although I wouldn't mind leaving off the -c since
>
Here's the summary for the first half of November -- sorry for the bit
of a delay. As always, let me or Tony know if you have any
corrections!
=
Summary Announcements
=
--
Reminder: Python is now on Subversion!
Barry Warsaw wrote:
> AFAICT, the reason to use -c is so that changes outside the Python
> source tree (i.e. in the sandbox) won't show up in Python's build
> number. That's fine although I wouldn't mind leaving off the -c since
> you'll still get the same snapshot of code from a revisioned checko
On Fri, 2005-12-16 at 17:11 -0500, Phillip J. Eby wrote:
> It looks like using 'svnversion -c . | cut -f2 -d":"' would get the
> most-recent committed version, plus the letter "M" if there are local
> changes. That sounds like what we should be using.
>
> That way, a build with local revisions
Michael Hudson wrote:
> For a different approach, would it be possible to have
> a subversion trigger put the revision number into some file in the
> repository?
Not easily, to my knowledge. Assuming that the export will be made
from a tag, the revision at which the tag was created (along with
the
Armin Rigo wrote:
> No, I know about this. I meant -- obviously, I'd have expected... --
> precisely the sequence of commands that my example shows:
I still managed to miss that point :-( My fault, you are right.
Regards,
Martin
___
Python-Dev mailing
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> that *still* won't tell you what precise sources had been used
> to build the binary, as different files simply can be on different
> revisions, and no single number, in whatever way computed, can
> give you full information.
A tangential point is t
I just created a branch for the ssize_t changes I had been working on
for a while. I hope to follow up with a PEP quickly.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscrib
Hi Martin,
On Sat, Dec 17, 2005 at 11:32:54AM +0100, "Martin v. L?wis" wrote:
> > trunk$ svn up
> > At revision xxx.
> > trunk$ svn info
> > Last Changed Rev: 1
> > trunk$ cd Python
> > trunk/python$ svn info
> > Last Changed Rev: 10001
>
> It is possible:
> sv
Armin Rigo wrote:
> If you meant that the following situation is possible:
>
> trunk$ svn up
> At revision xxx.
> trunk$ svn info
> Last Changed Rev: 1
> trunk$ cd Python
> trunk/python$ svn info
> Last Changed Rev: 10001
>
> then I object. As far as I can tel
Phillip J. Eby wrote:
> Only if you do an "svn update" immediately after *every* "svn commit".
> Otherwise, the code base reflected will be a version *before* your
> changes. This is fragile, since not everyone will know (or remember!)
> to do this.
That's true. It would be fairly reliable only
13 matches
Mail list logo
