[Python-Dev] About raising NotPortableWarning for CPython specific code

[Guido van Rossum]

On Sat, Mar 12, 2011 at 8:59 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Mar 12, 2011 at 8:33 AM, Laura Creighton <lac at openend.se> 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 they become unreachable.  And then warning about them.
>>
>> We have a real live user who has a large code base that relies on
>> the CPython behaviour that an object's __radd__ method will take precedence
>> over a list's inplace add behaviour.
>>
>> The thread with the whole gory details begins here:
>> http://codespeak.net/pipermail/pypy-dev/2011q1/006958.html
>>
>> My inclination is to declare code that relies on this as broken, rather
>> than patch every wretched container type in PyPy.  Can this become
>> blessed as a 'you shouldn't have done this'?
>
> Given that the meat of the difference in semantics lies in the
> CPython-specific distinction between nb_add and sq_concat, I'm
> inclined to agree with you.
>
> I'm actually tempted to call the current CPython semantics flatout
> *wrong*. When a given operation has multiple C level slots, shouldn't
> we be checking all the LHS slots before checking any of the RHS slots?
> There's nothing in the language spec that I'm aware of that justifies
> us doing otherwise.
>
> (obviously, history now means that changing our behaviour would
> require a deprecation period)

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?

-- 
--Guido van Rossum (python.org/~guido)