On 8/16/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
Guido van Rossum schrieb:> I think the test isn't hardly focused enough on int allocation. I> wonder if you could come up with a benchmark that repeatedly allocates> 100s of 1000s of ints and then deletes them?
The question is: where to store
John J Lee wrote:
> If nobody has time to fix this, perhaps rev 47154 should be reverted?
yes please.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman
On Thursday 17 August 2006 12:13, John J Lee wrote:
> On Thu, 17 Aug 2006, John J Lee wrote:
> [...]
>
> > If nobody has time to fix this, perhaps rev 47154 should be reverted?
>
> I should have put it more strongly: I think it *should* in fact be
> reverted if nobody has time to fix it before the
John J Lee wrote:
> Looks like revision 47154 introduced a regexp that hangs Python
Revision 47155 was a similar change to the 2.4 branch.
--
Benji York
Senior Software Engineer
Zope Corporation
___
Python-Dev mailing list
Python-Dev@python.org
http://m
The release candidate is done - we creep ever closer to 2.5 final. Hoooray!
All future 2.5 releases (including 2.5 final!) will now be done from the new
release25-maint trunk
(svn+ssh://[EMAIL PROTECTED]/python/branches/release25-maint) - so any
changes you want to see after 2.5c1 and before 2.
On behalf of the Python development team and the Python
community, I'm happy to announce the first RELEASE CANDIDATE
of Python 2.5.
This is not yet the final release - it is not suitable for
production use. It is being released to solicit feedback
and hopefully expose bugs, as well as allowing you
Anthony Baxter schrieb:
> Right now, I don't really care about the trunk - although if you break the
> buildbot [...]
Thanks for reminding me. I just added a buildbot builder for the 2.5
branch (actually, the builder was already there, but I connected it
with the web server), so you can now see t
On Friday 18 August 2006 00:47, Martin v. Löwis wrote:
> Anthony Baxter schrieb:
> > Right now, I don't really care about the trunk - although if you break
> > the buildbot [...]
>
> Thanks for reminding me. I just added a buildbot builder for the 2.5
> branch (actually, the builder was already the
I'd like to fix the two build failures that the Windows buildbots
show for the 2.5 trunk. I'm not quite sure what the OpenSSL failure
is, yet, but the sqlite error should be fixable with the patch
below. Ok to work on this?
Martin
Index: Tools/buildbot/external.bat
===
On 8/17/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> I'd like to fix the two build failures that the Windows buildbots
> show for the 2.5 trunk. I'm not quite sure what the OpenSSL failure
> is, yet, but the sqlite error should be fixable with the patch
> below. Ok to work on this?
Please do
test_uuid1 and test_uuid4 fail consistently on Windows; apparently,
the generated universally-unique identifiers aren't even unique within
a set of 1000 identifiers.
Can somebody please fix that? If not, should we remove the uuid module
as being immature?
Regards,
Martin
_
Martin v. Löwis wrote:
> test_uuid1 and test_uuid4 fail consistently on Windows; apparently,
> the generated universally-unique identifiers aren't even unique within
> a set of 1000 identifiers.
>
> Can somebody please fix that? If not, should we remove the uuid module
> as being immature?
Patch
On Thu, Aug 17, 2006 at 09:07:53PM +0200, Georg Brandl wrote:
> Jack Diederich wrote:
>
> > Looks good to me. While you are on that page do you want to change
> >
> > l = PyList_New(3);
> > x = PyInt_FromLong(1L);
> > PySequence_SetItem(l, 0, x); Py_DECREF(x);
> > x = PyInt_FromLong(2L);
> > PyS
Georg Brandl schrieb:
>> Can somebody please fix that? If not, should we remove the uuid module
>> as being immature?
>
> Patch #1541863 supposedly solves this.
Ah, good. I think it should go in.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@p
On Thu, 17 Aug 2006 22:06:24 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>Georg Brandl schrieb:
>>> Can somebody please fix that? If not, should we remove the uuid module
>>> as being immature?
>>
>> Patch #1541863 supposedly solves this.
>
>Ah, good. I think it should go in.
Uh, I ma
Georg Brandl wrote:
>> The example code causes segfaults and probably always has (at last to 2.2)
>
> Interesting! From a naive POV, the docs' example is quite right.
except that it doesn't work?
the problem is that it's using a *high-level* API to manipulate objects
that are not properly init
Georg Brandl wrote:
> Okay, now that I stumbled over and read the c.l.py thread, I think that we
> should
>
> * remove the faulty example (the correct one is already in there)
> * add a note to PyList_New that the new list must be filled with items
>before handing it to Python code or using
This is a reminder (I don't think anyone else sent one, I sure hope not).
We are holding 4 days of sprints next week at Google offices in NY
city and Mt View, CA. These are open if you'd like to attend. It
would be very helpful to pre-register on the wiki as we can notify
security and generally
Fredrik Lundh wrote:
> Georg Brandl wrote:
>
>>> The example code causes segfaults and probably always has (at last to 2.2)
>>
>> Interesting! From a naive POV, the docs' example is quite right.
>
> except that it doesn't work?
I wanted to say: From looking at the docs only, it should be alrigh
[EMAIL PROTECTED] schrieb:
>>> Patch #1541863 supposedly solves this.
>> Ah, good. I think it should go in.
>
> Uh, I may be misunderstanding here, but that patch looks like it
> changes that part of the test for test_uuid4 to stop calling uuid4
> and call uuid1 instead?
You misunderstand indeed:
On Thu, 17 Aug 2006 23:58:27 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>You misunderstand indeed: the chunk reads (...)
>it currently calls uuid1, and will call uuid4 when patched.
>test_uuid4 should have never failed, except that it uses uuid1
>as the uniqueness test.
Whooops. I
Hi Neal,
On Wed, Aug 16, 2006 at 10:26:09PM -0700, Neal Norwitz wrote:
> @@ -2367,7 +2374,9 @@
> compiler_use_next_block(c, end);
> if (!compiler_push_fblock(c, FINALLY_END, end))
> return 0;
> + c->c_in_finally = 1;
> VISIT_SEQ(c, stmt, s->v.TryFinally.finalbod
High-level remark: this seems to need more unit tests. Perhaps TDD
(test-driven design) would be the best approach to obtaining a correct
patch?
--Guido
On 8/17/06, Armin Rigo <[EMAIL PROTECTED]> wrote:
> Hi Neal,
>
> On Wed, Aug 16, 2006 at 10:26:09PM -0700, Neal Norwitz wrote:
> > @@ -2367,7 +2
On Fri, Aug 18, 2006 at 12:26:33AM +0200, Armin Rigo wrote:
> Without more inspection, I'd say that this looks like it won't do the
> right thing about nested finally's, as in:
I guess it'll have to loop back up through the block stack:
for (j=i- 1; j>=0; j--) {
switch (c->u->u_fblock[j].fb_ty
Fixing docs is fine - please checkin.
___
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-archive.com
On Friday 18 August 2006 06:06, Martin v. Löwis wrote:
> Georg Brandl schrieb:
> >> Can somebody please fix that? If not, should we remove the uuid module
> >> as being immature?
> >
> > Patch #1541863 supposedly solves this.
>
> Ah, good. I think it should go in.
Sounds fine to me. Making buildbo
26 matches
Mail list logo
