Nick Coghlan <ncogh...@gmail.com> added the comment:

1. It's an external API. We *don't control* most of the potentially broken 
code, so saying "just fix the call sites" effectively solves nothing and leaves 
classes like OrderedDict at risk of subtle silent corruption whenever they are 
passed to a 3rd party C extension.

2. The alternate "fix" is to tighten up the Py<X>_Check calls to 
Py<X>_CheckExact in order to reject subclasses. That would be a huge pain from 
a backwards compatibility point of view, so it isn't a realistic option.

3. Another alternate "fix" would be to exclude the concrete API from the stable 
ABI. That was already done for the macro interfaces, but it's too late for the 
functions - they were included in the stable interface for the 3.2 release.

4. The fact that the macros are irredeemably broken when used without ensuring 
that the supplied object is exactly the expected type is a very poor excuse for 
not fixing the function calls. It sounds like "The taillight is busted too, so 
let's not bother fixing the brakes".

5. There's a reason I put the "fast path" point second - that benefit is just 
an added bonus that comes from fixing the real design flaw that Raymond pointed 
out.

All that said, there really is one specific case where fixing this problem 
could cause a serious backwards compatibility issue: subclasses of builtin 
types that are *themselves* written in C. In such cases, the method 
implementations would quite likely use the concrete API to handle the base 
class state, then do their own thing to handle the rest of the update. Adding 
an implicit fallback to the concrete API implementations would cause such cases 
to trigger infinite recursion at the C level.

----------

_______________________________________
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

Reply via email to