[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Changes by ppperry : -- 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 _

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Changes by Stefan Krah : -- nosy: -skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.o

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Changes by Josh Rosenberg : -- nosy: +ShadowRanger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 solve

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 corr

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 si

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Nick Coghlan added the comment: On 26 Oct 2013 02:18, "Antoine Pitrou" 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 problem is with

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 b

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 app

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 __

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 compatibil

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 ha

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Nick Coghlan added the comment: Because calling them *from* method implementations in concrete subclasses is often a perfectly reasonable thing to do. -- ___ Python tracker ___ _

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

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 Un

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Changes by Meador Inge : -- nosy: +meador.inge ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Changes by Eric Snow : -- nosy: +eric.snow ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue10977] Concrete object C API considered harmful to subclasses of builtin types

Changes by Raymond Hettinger : -- 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