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

[Nick Coghlan]

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)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia