Changes by ppperry maprea...@olum.org:
--
title: Concrete object C API considered harmful to subclasses of builtin
typesje - Concrete object C API considered harmful to subclasses of builtin
types
___
Python tracker rep...@bugs.python.org
Changes by Stefan Krah stefan-use...@bytereef.org:
--
nosy: -skrah
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
___
___
Python-bugs-list
Changes by Josh Rosenberg shadowran...@gmail.com:
--
nosy: +ShadowRanger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
___
___
Nick Coghlan added the comment:
The problem we're trying to solve is CPython *silently* breaking subclass
invariants, which is what the concrete APIs currently do. At the moment,
trying to swap out dicts with ordered dicts in various places will corrupt
the ordered dict instead of calling the
Antoine Pitrou added the comment:
The problem we're trying to solve is CPython *silently* breaking subclass
invariants, which is what the concrete APIs currently do.
To be clear: the problem is with CPython calling the concrete APIs when
it shouldn't, rather than with the concrete APIs not
Nick Coghlan added the comment:
On 26 Oct 2013 02:18, Antoine Pitrou rep...@bugs.python.org wrote:
Antoine Pitrou added the comment:
The problem we're trying to solve is CPython *silently* breaking
subclass
invariants, which is what the concrete APIs currently do.
To be clear: the
Antoine Pitrou added the comment:
To be clear: the problem is with CPython calling the concrete APIs when
it shouldn't, rather than with the concrete APIs not behaving properly.
The boilerplate required to use them correctly renders them broken in my
view, particularly when they silently
Stefan Behnel added the comment:
Nick Coghlan added the comment:
Antoine Pitrou added the comment:
To be clear: the problem is with CPython calling the concrete APIs when
it shouldn't, rather than with the concrete APIs not behaving properly.
The boilerplate required to use them correctly
Nick Coghlan added the comment:
Keep in mind that part of the problem here is finding stdlib code that
needs to be fixed to handle subclasses correctly. The existing APIs have
permitted use with subclasses for years but are, in fact, the wrong tool
for that in many cases.
The problem to be
Stefan Behnel added the comment:
-1 on any changes that make the specific C-API functions less specific. They
are perfectly adequate for gaining speed in well defined situations.
+0 on any changes that special case concrete types in abstract calls if they
prove to be worth the hassle.
+1 for
Stefan Krah added the comment:
I'm also in favor of a clean separation between the concrete and abstract
APIs (see also #12965). Why can't the concrete functions be locked down
with *CheckExact()? If there's any breakage in third party modules,
it's easy to fix (probably much easier than the
Nick Coghlan added the comment:
Because calling them *from* method implementations in concrete subclasses
is often a perfectly reasonable thing to do.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
Eric Snow added the comment:
Because calling them *from* method implementations in concrete subclasses...
We do the same thing from Python all the time (though less so with the
availability of super).
E.G. dict.__init__(self, ...) and dict.__set item__(self, key, value).
Now, if the C-API
Nick Coghlan added the comment:
I haven't fully thought this one through, but perhaps we could:
- deprecate calling the current concrete APIs with subclasses (since doing
so may break subclass invariants)
- add PyBaseDict_* APIs (etc) that subclass implementations can call.
- offer a
Eric Snow added the comment:
I had roughly the same idea, Nick, though my approach to address backward
compatibility was more complicated. Definitely worth at least looking into for
3.5.
--
___
Python tracker rep...@bugs.python.org
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
___
Changes by Eric Snow ericsnowcurren...@gmail.com:
--
nosy: +eric.snow
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
___
___
Python-bugs-list
Changes by Meador Inge mead...@gmail.com:
--
nosy: +meador.inge
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue10977
___
___
Python-bugs-list
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
title: Concrete object C API needs abstract path for subclasses of builtin
types - Concrete object C API considered harmful to subclasses of builtin types
___
Python tracker
19 matches
Mail list logo
