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
[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 shot ;-) Which
[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 to
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
code.
It
[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 and
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
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 that
[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
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
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 but will
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
package
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
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. If we aren't going to
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, warn,
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
17 matches
Mail list logo
