Having had some time to let this settle for a bit, I hope it doesn't
get abandoned just because it was to complicated to come to a
conclusion.
I'd like to attempt to summarize the main ideas as follows.
1) Currently the "fast call" optimization is implemented by by
checking explicitly for a set o
This would be really useful for Cython, as well as a nice cleanup in
general (e.g. replacing 4 special cases with one check).
It seems the main concern is the user-visible change in types. If this is
determined to be too backwards incompatible (I would be surprised if many
projects are impacted, b
On Wed, May 16, 2012 at 5:03 PM, Greg Ewing wrote:
> Dag wrote:
>
>> I'm not asking you to consider the details of all that. Just to allow some
>> kind of high-performance extensibility of PyTypeObject, so that we can
>> *stop* bothering python-dev with specific requirements from our parallel
>> u
On Wed, May 16, 2012 at 11:33 AM, "Martin v. Löwis" wrote:
>> Does this use case make sense to everyone?
>>
>> The reason why we are discussing this on python-dev is that we are looking
>> for a general way to expose these C level signatures within the Python
>> ecosystem. And Dag's idea was to ex
On Wed, May 16, 2012 at 8:40 AM, Mark Shannon wrote:
> Dag Sverre Seljebotn wrote:
>>
>> On 05/16/2012 02:47 PM, Mark Shannon wrote:
>>>
>>> Stefan Behnel wrote:
Dag Sverre Seljebotn, 16.05.2012 12:48:
>
> On 05/16/2012 11:50 AM, "Martin v. Löwis" wrote:
>>>
>>> Agreed in
