[issue10977] Concrete object C API considered harmful to subclasses of builtin types
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 http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API considered harmful to subclasses of builtin types
Changes by Stefan Krah stefan-use...@bytereef.org: -- nosy: -skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API considered harmful to subclasses of builtin types
Changes by Josh Rosenberg shadowran...@gmail.com: -- nosy: +ShadowRanger ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 appropriate subclass methods or throwing a type error. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 behaving properly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 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 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 corrupt internal subclass state when misused instead of throwing an exception. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 silently corrupt internal subclass state when misused instead of throwing an exception. IMO the boilerplate should actually be included inside the abstract APIs, so as to automatically enable optimized shortcuts when possible. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 correctly renders them broken in my view I think we disagree here. There is no boilerplate at all involved, as long as its guaranteed that they are being called on the correct type of object. User code may provide that guarantee either implicitly or explicitly, and only the explicit way involves additional code (such as a type check). The implicit way (that simply knows the exact type) would suffer from any code additions to the fast paths in the specific C-API functions. particularly when they silently corrupt internal subclass state when misused instead of throwing an exception. It has bothered me more than once that even the fast paths in those functions usually contain type checks, which often means that the type check is being executed twice: once as a special casing check before calling the function and once as a safety check after entering it. As long as the functions are being used correctly, the second check is just useless code that unnecessarily takes time. IMHO, it would be nice to have those internal type checks enabled *only* for debug builds, although even then, there may be legitimate usages that call these functions on subtypes (such as when called from within a well defined subtype implementation, as you mentioned). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 solved isn't this code should handle ducktyping but, this code should either reject subclasses or else handle them without corrupting them. Using the same API for both external invocation and for subclasses calling up to the parent is a problem. For code in critical paths, doing the same type check twice is also a problem. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 making sure CPython does not accidentally exclude subclasses internally for anything that's provided by users. +1 on CPython being the wrong place to work around this for external code. If extensions use the wrong function, *they* must be fixed. At most, there might be a documentation issue hidden here. Also, we should be careful with adding yet another substantial set of C-API functions. It's not clear to me that they are really needed in practice. -- nosy: +scoder ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Unicode changes in 3.3). -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 had some equivalent to super... -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 compatibility header for earlier versions that #defines the new APIs back to the old ones This would be 3.5 PEP territory, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API considered harmful to subclasses of builtin types
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- nosy: +Arfrever ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API considered harmful to subclasses of builtin types
Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +eric.snow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API considered harmful to subclasses of builtin types
Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10977] Concrete object C API considered harmful to subclasses of builtin types
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 rep...@bugs.python.org http://bugs.python.org/issue10977 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
