Greg Ewing wrote:
> Anyone have any ideas how the situation could
> be improved?
As always: on a case-by-case basis. If you find a specific
case where you think the diagnosis should be better, make it
better for this case. Perhaps some generalization arises while
doing so, but if not, atleast this
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.
The metaclass I wrote was for the purpose of
adding a class to a registry, the reason for which
isn't important here. It worked,
[Alex]
> And I'm on the fence regarding the specific issue of PySet_Next.
>
> So, having carefully staked out a position smack in the middle, I
> cheerfully now expect to be fired upon from both sides!-)
Okay, here's the first cheap shot ;-) Which of the following pieces of code is
preferable?
On Sun, Mar 26, 2006, Raymond Hettinger wrote:
> [Alex]
>>
>> And I'm on the fence regarding the specific issue of PySet_Next.
>>
>> So, having carefully staked out a position smack in the middle, I
>> cheerfully now expect to be fired upon from both sides!-)
>
> Okay, here's the first cheap sho
[Aahz]
> Speaking as a person who does relatively little C programming, I don't
> see much difference between them. The first example is more Pythonic --
> for Python. I agree with Barry that it's not much of a virtue for C
> code.
It was a trick question. Everyone is supposed to be attracted t
On Mar 26, 2006, at 8:43 AM, Raymond Hettinger wrote:
> [Aahz]
>> Speaking as a person who does relatively little C programming, I
>> don't
>> see much difference between them. The first example is more
>> Pythonic --
>> for Python. I agree with Barry that it's not much of a virtue for C
>>
[Alex]
> Sure, accidentally mutating underlying iterables is a subtle (but alas
> frequent) bug, but I don't see why it should be any harsher when the loop is
> using a hypothetical PySet_Next than when it is using PyIter_Next --
> whatever
> precautions the latter takes to detect the bug a
Raymond Hettinger wrote:
> The difference is that the PySet_Next returns pointers to the table keys and
> that the mutation occurs AFTER the call to PySet_Next, leaving pointers to
> invalid addresses. IOW, the function cannot detect the mutation.
I'm coming late to the discussion: where did an
>> The difference is that the PySet_Next returns pointers to the table keys and
>> that the mutation occurs AFTER the call to PySet_Next, leaving pointers to
>> invalid addresses. IOW, the function cannot detect the mutation.
>
> I'm coming late to the discussion: where did anybody ever suggest th
Raymond Hettinger wrote:
> Pardon, I bungled the terminology. PySet_Next returns a borrowed
> reference. That is problematic is arbitrary Python code can be run
> afterwards (such as PyObject_Hash in the example).
Not really. It is under the control of the caller of PySet_Next
what (if any) Pytho
[Tim, on PyMem vs PyObject memory mismatches]
> ... Alas, in a release(*) build, Python's test suite segfaulted all over the
> place.
>
> So far I found one smoking gun: in _subprocess.c, ...
And Python's front end was chock full o' these, sometimes even getting
memory via PyMem and releasing it
[Edward Loper]
> Could the debug build's macros for PyMem/PyObject_new/free be modified
> to check for mismatches? Or would storing information about which
> method was used to allocate each pointer be too expensive? Perhaps a
> special build could be used to check for mismatches?
It's partly po
Tim Peters wrote:
> If extension modules in real life prove as sloppy as Python's
> front end, we'll have to revert the objimpl.h + pymem.h part of this
> patch. Note that no problems will show up in a debug build (all
> calls still go thru obmalloc then). Problems will show up on
On Sun, 2006-03-26 at 18:58 -0500, Tim Peters wrote:
> [Edward Loper]
> > Could the debug build's macros for PyMem/PyObject_new/free be modified
> > to check for mismatches? Or would storing information about which
> > method was used to allocate each pointer be too expensive? Perhaps a
> > speci
Now that the buildbot is in place and seems to be running relatively
smoothly, maybe should consider making daily (or periodic) builds and
releasing them. We've got a system in place to build on many
platforms automatically. How much more difficult would it be to
package up the results and make t
http://python.org/sf/1458927 asks if -Q warn option should become the
default in 2.5. PEP 238 (http://www.python.org/dev/peps/pep-0238/)
says:
"""
The -Q command line option takes a string argument that can take four
values: "old", "warn", "warnall", or "new". The default is "old" in
Python 2.2
Neal Norwitz wrote:
> Now that the buildbot is in place and seems to be running relatively
> smoothly, maybe should consider making daily (or periodic) builds and
> releasing them. We've got a system in place to build on many
> platforms automatically. How much more difficult would it be to
> pac
Ok, pending a fix for http://www.python.org/sf/1459029, I'm declaring
a freeze for release24-maint starting at UTC on Wednesday 29th
of March. This is for Python 2.4.3. Please don't checkin after that
time to the branch without checking with me first. I can be reached
via email, or on #pyt
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 only happens once we
hit beta. And we're not going to hit beta
Neal Norwitz <[EMAIL PROTECTED]> wrote:
> """
> The -Q command line option takes a string argument that can take four
> values: "old", "warn", "warnall", or "new". The default is "old" in
> Python 2.2 but will change to "warn" in later 2.x versions.
> """
>
> I'm not sure this is worth in 2.x. I
On Monday 27 March 2006 16:04, Neal Norwitz wrote:
> http://python.org/sf/1458927 asks if -Q warn option should become
> the default in 2.5. PEP 238
> (http://www.python.org/dev/peps/pep-0238/) says:
>
> """
> The -Q command line option takes a string argument that can take
> four values: "old", "
There are 5 tests that leak references that are present in 2.4.3c1,
but not on HEAD. It would be great if someone can diagnose these and
suggest a fix.
test_doctest leaked [1, 1, 1] references
test_pkg leaked [10, 10, 10] references
test_pkgimport leaked [2, 2, 2] references
test_traceback leaked
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())
Until 2.4.2: \n \n
2.4.3: \n \\n
\\n looks bit weir
23 matches
Mail list logo
