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
