On 3/12/2011 8:23 PM, Neil Schemenauer wrote:
Greg Ewing wrote:
So am I. It seems to result from the hisorical mess
of distinguishing between numeric and sequence operations
at the C level but not the Python level. I think CPython
should be moving in the direction of eliminating that
distinctio
Greg Ewing wrote:
> So am I. It seems to result from the hisorical mess
> of distinguishing between numeric and sequence operations
> at the C level but not the Python level. I think CPython
> should be moving in the direction of eliminating that
> distinction, not expecting all other Python imple
Nick Coghlan wrote:
I'm actually tempted to call the current CPython semantics flatout
*wrong*.
So am I. It seems to result from the hisorical mess
of distinguishing between numeric and sequence operations
at the C level but not the Python level. I think CPython
should be moving in the directi
On 3/12/2011 8:33 AM, Laura Creighton wrote:
The thread with the whole gory details begins here:
http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html
The second, multiplication issue does appears to be the same issue.
Augmenting my previous test:
class C(object):
def __iter__(self):
On 3/12/2011 3:04 PM, Thomas Wouters wrote:
It should be fixed, yes, but breaking existing code is going to piss off
a lot of people (like me) who already have enough worries when upgrading
Python. It is apparent that there *is* code out there that relies on
this behaviour, we shouldn't break it
On Sat, Mar 12, 2011 at 14:52, Terry Reedy wrote:
> On 3/12/2011 8:59 AM, Nick Coghlan wrote:
>
>> (obviously, history now means that changing our behaviour would
>
> require a deprecation period)
>>
>
> I disagree. Behavior that contradicts intent and doc is a bug and should be
> fixed.
It sho
On 3/12/2011 8:59 AM, Nick Coghlan wrote:
On Sat, Mar 12, 2011 at 8:33 AM, Laura Creighton wrote:
For those of you not at the Language Summit at PyCON the day before yesterday,
there was talk of identifying non-portable behaviour, such as relying on
CPython's reference counting garbage collecto
On Sat, Mar 12, 2011 at 1:41 PM, Guido van Rossum wrote:
> Yeah, indeed, on everything you said. The code dispatching based on
> internal slots is horribly ad-hoc and likely wrong in subtle ways. Has
> any of this improved in Python 3?
Not that I know of - I was definitely able to replicate the w
On Sat, Mar 12, 2011 at 8:59 AM, Nick Coghlan wrote:
> On Sat, Mar 12, 2011 at 8:33 AM, Laura Creighton wrote:
>> For those of you not at the Language Summit at PyCON the day before
>> yesterday,
>> there was talk of identifying non-portable behaviour, such as relying on
>> CPython's reference c
On Sat, Mar 12, 2011 at 8:33 AM, Laura Creighton wrote:
> For those of you not at the Language Summit at PyCON the day before yesterday,
> there was talk of identifying non-portable behaviour, such as relying on
> CPython's reference counting garbage collector to close files for you as
> soon as t
For those of you not at the Language Summit at PyCON the day before yesterday,
there was talk of identifying non-portable behaviour, such as relying on
CPython's reference counting garbage collector to close files for you as
soon as they become unreachable. And then warning about them.
We have a
11 matches
Mail list logo
