Pythonic way for missing dict keys
Bruno Desthuilliers
bruno.42.desthuilliers at wtf.websiteburo.oops.com
Thu Aug 2 12:10:30 EDT 2007
Alex Martelli a écrit :
> Bruno Desthuilliers <bruno.42.desthuilliers at wtf.websiteburo.oops.com>
> wrote:
>
>> Alex Popescu a écrit :
>>> Bruno Desthuilliers <bdesth.quelquechose at free.quelquepart.fr> wrote in
>>> news:46b0ed0b$0$2257$426a74cc at news.free.fr:
>> (snip)
>>>> if hasattr(obj, '__call__'):
>>>> # it's a callable
>>>>
>>>> but I don't find it so Pythonic to have to check for a __magic__
>>>> method.
>>> It looks like Python devs have decided it is Pythonic, because it is
>>> already in the PEP.
>> I do know, and I disagree with this decision.
>>
>> FWIW, repr(obj) is mostly syntactic sugar for obj.__repr__(),
>> getattr(obj, name) for obj.__getattr__(name), type(obj) for
>> obj.__class__ etc... IOW, we do have a lot of builtin functions that
>> mostly encapsulate calls to __magic__ methods, and I definitively don't
>> understand why this specific one (=> callable(obj)) should disappear. I
>
> Maybe because it DOESN'T "encapsulate a call" to a magic method, but
> rather the mere check for the presence of one?
Yes, true. But it doesn't make such a big difference IMHO : it's about
decoupling API (the builtin funcs) from implementation (accessing |
calling | checking for the presence of a given implementation attribute).
>> usually have lot of respect for Guido's talent as a language designer
>> (obviously since Python is still MFL), but I have to say I find this
>> particular decision just plain stupid. Sorry.
>
> The mere check of whether an object possesses some important special
> method is best accomplished through the abstract-base-classes machinery
> (new in Python 3.0: see <http://www.python.org/dev/peps/pep-3119/>). At
> this time there is no Callable ABC, but you're welcome to argue for it
> on the python-3000 mailing list (please do check the archives and/or
> check privately with the PEP owner first to avoid duplication).
I'll have a look. Thanks for the pointers.
More information about the Python-list
mailing list