A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2015-October/141981.html below:

[Python-Dev] compatibility for C-accelerated types

[Python-Dev] compatibility for C-accelerated types [Python-Dev] compatibility for C-accelerated typesEric 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

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4