A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2018-June/153915.html below:

[Python-Dev] PEP 575 (Unifying function/method classes) update

[Python-Dev] PEP 575 (Unifying function/method classes) update [Python-Dev] PEP 575 (Unifying function/method classes) updateRonald Oussoren ronaldoussoren at mac.com
Sun Jun 17 13:52:06 EDT 2018
> On 17 Jun 2018, at 16:31, Stefan Behnel <stefan_ml at behnel.de> wrote:
> 
> Ronald Oussoren schrieb am 17.06.2018 um 14:50:
>> Why did you add a tp_ccalloffset slot to the type with the actual information in instances instead of storing the information in a slot? 
> 
> If the configuration of the callable was in the type, you would need a
> separate type for each kind of callable. That would quickly explode. Think
> of this as a generalised PyCFunction interface to arbitrary callables.
> There is a function pointer and some meta data, and both are specific to an
> instance.

That’s true for PyCFunction, but not necessarily as a general replacement for the tp_call slot.  I my code I’d basically use the same function pointer and metadata for all instances (that is, more like PyFunction than PyCFunction). 

> 
> Also, there are usually only a limited number of callables around, so
> memory doesn't matter. (And memory usage would be a striking reason to have
> something in a type rather than an instance.)

I was mostly surprised that something that seems to be a replacement for tp_call stores the interesting information in instances instead of the type itself. 

Ronald

More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4