Home Original page

[Python-Dev] compatibility for C-accelerated types

Eric Snow ericsnowcurrently at gmail.com
Tue Oct 20 11:05:04 EDT 2015 
On Tue, Oct 20, 2015 at 2:38 AM, Maciej Fijalkowski <fijall at gmail.com> wrote:
> For what is worth, that level of differences already exists on pypy
> and it's really hard to get the *exact* same semantics if things are
> implemented in python vs C or the other way around.
>
> Example list of differences (which I think OrderedDict already breaks
> if moved to C):
>
> * do methods like items call special methods like __getitem__ (I think
> it's undecided anyway)
>
> * what happens if you take a method and rebind it to another subclass,
> does it automatically become a method (there are differences between
> built in and pure python)
>
> * atomicity of operations. Some operations used to be non-atomic in
> Python will be atomic now.
>
> I personally think those (and the __class__ issue) are unavoidable

Yeah, I figured as much.  Thanks for pointing those out.  Perhaps it
would be useful to enumerate specific cases like these in PEP 399?
They could go near the part that says "as close to the pure Python
implementation as reasonable".

-eric
More information about the Python-Dev mailing list