>> Thank would be nice. It gives me the ability to keep a clean, sane API
>> while
>> at
>> the same time making sure that my most important customer (Barry) gets his
>> needs
>> met.
> I'm having a hard time deciphering whether you're being condescending or
> trying to be funny. I'm going to
Anthony Baxter wrote:
> This came up before (back in October 2004!) but didn't go anywhere
> since, AFAICR. Do we want to consider including pysqlite in Python
> 2.5? It's the only DB adaptor that I'd really consider suitable for
> shipping with the distribution, because it's self-contained.
>
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
Pyth
Greg Ewing wrote:
> 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
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, a
[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
> j
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 c
This came up before (back in October 2004!) but didn't go anywhere
since, AFAICR. Do we want to consider including pysqlite in Python
2.5? It's the only DB adaptor that I'd really consider suitable for
shipping with the distribution, because it's self-contained.
What's people's thoughts?
Antho
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 with
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
===
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
>
[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 b
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 i
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 (o
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
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 functio
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:
>
>
>> 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 ev
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)
>
On Mon, 2006-03-27 at 23:21 +0200, "Martin v. Löwis" wrote:
> 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 hims
On Mon, 2006-03-27 at 10:20 -0500, Raymond Hettinger wrote:
> Why don't we expose _PySet_Next() for Barry and leave it out of the public
> API
> for everyone else.
Just so I understand exactly what you mean by "leave it out of the
public API", let me ask: are you saying you don't want to documen
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()
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
>>
>> Result:
>>
>> [0, 1, 2, 3, 4, 5, 6, 7,
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
>>
>>Result:
>>
>>[0, 1, 2, 3, 4, 5, 6, 7, 8, 9,
At 07:20 PM 3/27/2006 +, Mike Krell wrote:
>Greg Ewing 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 bee
Greg Ewing 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 class
decor
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]
>
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 = N.arange
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 b
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 ite
On 3/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
Folks,When you assign a bug/patch to me, somehow SourceForge doesn't send mean email. (Is this understood behavior? Can it be changed?) Since Idon't monitor my SF personal page regularly any more, that means that
the issue will remain in limbo
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.
Mo
On Tuesday 28 March 2006 06:38, Jeremy Hylton wrote:
> There's a bug day on Friday.
> http://wiki.python.org/moin/PythonBugDay
Whoops! I _thought_ there was some vague reason in the back of my head
to put it off til next week! Ok, this will be rescheduled for next
week (the trunk freeze, not the
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
___
Pyth
Neal Norwitz wrote:
> test_unicode leaked [7, 7, 7] references
And the last one came from
r41531 | neal.norwitz | 2005-11-24 23:09:18 +0100 (Do, 24 Nov 2005) | 1 line
Geänderte Pfade:
M /python/trunk/Python/codecs.c
M /python/trunk/Python/compile.c
M /python/trunk/Python/symtable.c
Fix
At 01:33 PM 3/27/2006 -0800, Guido van Rossum wrote:
>Is the with statement documented yet?
Sort of. I've added stuff to the language reference, but the "What's New"
for it is blank right now. There's nothing in the tutorial, either, and of
course contextlib isn't in the libref yet (which is w
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 you
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
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 e
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 Servic
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
>
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 "ct
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' pro
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 i
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 alp
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 feature freeze o
>> 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 t
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:
http://mail.python.org/mailman
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 ou
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 i
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 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 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
> PyObj
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 P
Hye-Shik Chang wrote:
> We got an inconsistency for __repr__() returning unicode as
> reported in http://python.org/sf/1459029 :
>
> class s1:
> def __repr__(self):
> return '\\n'
>
> class s2:
> def __repr__(self):
> return u'\\n'
>
> print repr(s1()), repr(s2())
>
> Un
55 matches
Mail list logo
