[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-capi-sig
Subject:    [capi-sig]Re: Call protocol: tuple/dict subclasses?
From:       Steve Dower <steve.dower () python ! org>
Date:       2019-05-10 14:32:27
Message-ID: 6b6a8f5b-39ec-e839-7caa-3cf167a50202 () python ! org
[Download RAW message or body]

On 09May2019 2120, Hugh Fisher wrote:
> This is related I think to Victor's work on the levels of C API
> compatibility. Is
> there a requirement that a subclass of a builtin type must implement the entire
> C API?

It's not related to the compatibility work, but a subclass of a builtin 
type *is* the builtin type with some Python attributes/methods added. 
Otherwise it won't report as being a subclass (both *_Check and 
*_CheckExact will fail).

What you lose by using the concrete API is the ability to use those 
Python methods. For example, given:

class MyDict(dict):
     def __getitem__(self, key):
         return super()[key.lower()]

Calling this with PyObject_GetItem(...) will resolve the Python 
__getitem__ and call it. However, using PyDict_GetItem(...) will not, as 
it goes directly to the C structure (because it's actually the default 
implementation of dict.__getitem__, so it "should" only be called when 
it has not been overridden, and therefore does not have to check for 
overrides).

So if you have a subclass with the same semantics for core operations, 
it'll be fine. But if the caller is expecting that subclass to behave 
differently based on overrides, it won't.

Cheers,
Steve
_______________________________________________
capi-sig mailing list -- capi-sig@python.org
To unsubscribe send an email to capi-sig-leave@python.org
[prev in list] [next in list] [prev in thread] [next in thread]