Tokyo PyPy Sprint: 23rd - 29th April 2006
The next PyPy sprint is scheduled to take place 23rd- 29th April 2006
(Sunday-Saturday) in Akihabara, Tokyo, Japan. We will together with
FSIJ (Free Software Initiative of Japan) aim to promote
On Sun, 2006-03-26 at 11:43 -0500, Raymond Hettinger wrote:
It was a trick question. Everyone is supposed to be attracted to the _next
version because it is shorter, faster, and takes less ref counting
management.
However, the _next version has a hard-to-find bug. The call to
On Sun, 2006-03-26 at 19:59 +0200, Martin v. Löwis wrote:
If it is similar to PyDict_Next, it will have PyObject** /input/
variables, which are really meant as PyObject* /output/ variables.
Yep, that's exactly what my posted patch does.
For the caller, a clear usage strategy follows from
On Sun, 2006-03-26 at 13:24 -0500, Raymond Hettinger wrote:
We have a perfectly good way to iterate with PyIter_Next(). It may take a
couple of extra lines, but it is easy to get correct and has no surprises.
It
seems that the only issue is that Barry says that he refuses to use the
On Sun, 2006-03-26 at 21:50 +0200, Martin v. Löwis wrote:
I don't know what specific application Barry has in mind, but I'm
sure he can get it right (although it might be an interesting experiment
to test that theory :-) In general, I would expect that people find
it easier to get code
Hi Neal,
On Sun, Mar 26, 2006 at 11:39:50PM -0800, Neal Norwitz wrote:
test_pkg leaked [10, 10, 10] references
This one at least appears to be caused by dummy (deleted) entries in the
dictionary of interned strings. So it is not really a leak. It is a
pain that it is so hard to figure this
Why don't we expose _PySet_Next() for Barry and leave it out of the public API
for everyone else.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Why don't we expose _PySet_Next() for Barry and leave it out of the public
API
for everyone else.
[Alex]
There are precedents for adding some functionality to the C API but not
documenting it to ensure non advanced users don't get hurt -- that's how
we
added the ability to raise
Jeremy Hylton wrote:
On 3/27/06, Anthony Baxter [EMAIL PROTECTED] wrote:
Ok, it's time to rock and roll.
The SVN trunk is FROZEN for 2.5a1 from 00:00 UTC on
Thursday 30th of March.
I'll post again once it's open. Note that new features can keep going
in during the alpha cycle, the
Raymond Hettinger wrote:
Why don't we expose _PySet_Next() for Barry and leave it out of the public
API
for everyone else.
That is stupid. If Barry wants a private PySet_Next function, he can
just implement it himself, no need to include it in the release. It
should be included only if it is
On 3/27/06, Raymond Hettinger [EMAIL PROTECTED] wrote:
Modified: python/trunk/Modules/itertoolsmodule.c Log: Make itertools.tee and its internal teedataobject participate in GC. This alone does not solve the leak in test_generators, unfortunately, but it is
part of test_generators' problem and
Any thoughts on where documentation for the new contextlib module should
go in the library reference?
Some candidates:
* Program Frameworks (???)
* Development Tools (??)
* Python Runtime Services (?)
* Python Language Services (??)
* Miscellaneous Services (??)
A similar issue exists for
On 3/27/06, Thomas Wouters [EMAIL PROTECTED] wrote:
The teeobject has GC (hence the word 'and' in 'itertools.tee and its
internal teedataobject' ;-) The problem with test_generators is that this
also leaks:
def leak():
def gen():
while True:
yield g
g = gen()
On 3/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
Any thoughts on where documentation for the new contextlib module should
go in the library reference?
Some candidates:
* Program Frameworks (???)
* Development Tools (??)
* Python Runtime Services (?)
* Python Language Services (??)
*
On Monday 27 March 2006 16:26, Phillip J. Eby wrote:
Any thoughts on where documentation for the new contextlib module should
go in the library reference?
Most definately in Python Runtime Services.
A similar issue exists for ctypes module, although I imagine an argument
could easily be
Neal Norwitz wrote:
test_unicode leaked [7, 7, 7] references
This one is lacking this checkin:
r41530 | neal.norwitz | 2005-11-24 23:00:56 +0100 (Do, 24 Nov 2005) | 6
lines
Geänderte Pfade:
M /python/trunk/Lib/test/test_unicode.py
Move registration of the codec search function to the module
Folks,
When you assign a bug/patch to me, somehow SourceForge doesn't send me
an email. (Is this understood behavior? Can it be changed?) Since I
don't monitor my SF personal page regularly any more, that means that
the issue will remain in limbo forever or until someone points me to
it. So if
Guido van Rossum wrote:
When you assign a bug/patch to me, somehow SourceForge doesn't send me
an email. (Is this understood behavior? Can it be changed?)
I believe it broke at some point, I'm pretty certain it used to work.
Regards,
Martin
___
On 3/27/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
When you assign a bug/patch to me, somehow SourceForge doesn't send me
an email. (Is this understood behavior? Can it be changed?)
I believe it broke at some point, I'm pretty certain it used to work.
More reason
Barry Warsaw wrote:
We're clearly going in circles here, and it's obvious we're not going to
agree.
Would it perhaps help if there were a better API for
using the iterator protocol from C code? Something
that's as easy to use as the proposed set iterating
API, but which uses the general
Chris Barker wrote:
Can we have both? A defined interface, that existing code can be adapted
to provide, and a new C-Object, that future code can just use. If the
goal is to have as many extension types as possible use the same base
object, the sooner a standard object is provided the
If you have Numeric or numpy installed try this:
#import Numeric as N
import numpy as N
a = range(10)
b = N.arange(10)
a.__iadd__(b)
print a
Result:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Contrast the returned output with
import numpy as N
a = range(10)
b =
On 3/27/06, Travis Oliphant [EMAIL PROTECTED] wrote:
If you have Numeric or numpy installed try this:
#import Numeric as N
import numpy as N
a = range(10)
b = N.arange(10)
a.__iadd__(b)
print a
Result:
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
Contrast the
Greg Ewing greg.ewing at canterbury.ac.nz writes:
I've just been playing around with metaclasses, and
I think I've stumbled across a reason for having
class decorators as an alternative to metaclasses
for some purposes.
There has also been discussion on the IronPython mailing list that
At 07:20 PM 3/27/2006 +, Mike Krell wrote:
Greg Ewing greg.ewing at canterbury.ac.nz writes:
I've just been playing around with metaclasses, and
I think I've stumbled across a reason for having
class decorators as an alternative to metaclasses
for some purposes.
There has also been
On Sat, 2006-03-25 at 22:05 -0500, Raymond Hettinger wrote:
Still, PyObject_Clear(s) would be better.
Although not ideal, in the interest of compromise, I could support this
option. There's a problem with this though: I don't think you want to
be able to clear a frozen set. My PySet_Clear()
On 3/27/06, Travis E. Oliphant [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
On 3/27/06, Travis Oliphant [EMAIL PROTECTED] wrote:
If you have Numeric or numpy installed try this:
#import Numeric as N
import numpy as N
a = range(10)
b = N.arange(10)
a.__iadd__(b)
print a
When you assign a bug/patch to me, somehow SourceForge doesn't send
me an email. (Is this understood behavior? Can it be changed?)
Martin I believe it broke at some point, I'm pretty certain it used to
Martin work.
I would expect that if it broke for Guido it broke for
On 3/27/06, Phillip J. Eby [EMAIL PROTECTED] wrote:
PyProtocols and the zope.interface package both support inline class
decorators called class advisors. They don't require any special syntax,
and aren't much more complex than regular decorators. By defining an
advisor like this:
from
At 08:02 PM 3/27/2006 -0800, Guido van Rossum wrote:
Just curious (and lazy): what magic is the implementation using that
makes this work without a custom metaclass?
It registers a function as the __metaclass__ by poking it into the f_locals
of the frame that's defining the class. This function
Travis E. Oliphant wrote:
I think this can be fixed easily by first checking the sequence slot for
a sq_concat function before calling PyNumber_InPlaceAdd.
However, if this *is* fixed, it looks like it's going to
break NumPy, in the sense that it will no longer be able
to force an arithmetic
Barry Warsaw wrote:
My PySet_Clear() raises a SystemError
and returns -1 when the object is a frozen set.
Isn't SystemError a bit drastic? TypeError would be
sufficient here, surely.
If PyObject_Clear() is implemented something like
int PyObject_Clear(PyObject *o)
{
return
Phillip J. Eby wrote:
It registers a function as the __metaclass__ by poking it into the f_locals
of the frame that's defining the class.
That is stunningly brilliant! I'd nominate it for
Hack of the Year if there were such an award.
It's far too magical for me to feel like actually
using
[EMAIL PROTECTED] wrote:
Martin I believe it broke at some point, I'm pretty certain it used to
Martin work.
I would expect that if it broke for Guido it broke for everybody. While we
consider him to be the BDFL I suspect the accolades are lost on the SF
folks.
Indeed, it broke
Greg Ewing wrote:
Hmmm, the problem here, I think, is that tp_clear is
really only designed for use by the garbage collector.
Giving anything else access to it is probably wrong.
Clearability is not a general feature in Python land --
a few types have a clear() method, but this is an
ad
On Monday 27 March 2006 21:14, M.-A. Lemburg wrote:
Change PyObject_Repr() to use the default encoding (again)
which is also consistent with how PyObject_Str() works.
For 2.4.3, I plan to just revert the following patch (and supply a
test case)
Index: Objects/object.c
We've made a lot of improvement with testing over the years.
Recently, we've gotten even more serious with the buildbot, Coverity,
and coverage (http://coverage.livinglogic.de). However, in order to
improve quality even further, we need to do a little more work. This
is especially important
On Tuesday 28 March 2006 17:53, Neal Norwitz wrote:
In order to do the best possible job and avoid silly errors, there
shouldn't be any checkins which could change behaviour that do not
include a test. I'm not talking about updating comments or string
constants. But even trivial changes can
[Neal Norwitz]
...
If you really can't figure out any way to test the change, please
describe why in your checkin message. Just make sure it's true. It
would be quite embarrassing to have your whole theory trashed when
Uncle Timmy comes along 5 minutes later and checks in the test you
just
Fred L. Drake, Jr. wrote:
On Monday 27 March 2006 16:26, Phillip J. Eby wrote:
Any thoughts on where documentation for the new contextlib module should
go in the library reference?
Most definately in Python Runtime Services.
A similar issue exists for ctypes module, although I
Never mind. For 2.4.3, I reverted perky's patch for the
unicode-escape, and reverted the old patch for PyObject_Repr on the
trunk. After talking to perky and Neal, this seemed like the safest
option for 2.4.3.
Anthony
___
Python-Dev mailing list
41 matches
Mail list logo
