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
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,
On Wed, May 16, 2012 at 8:40 AM, Mark Shannon m...@hotpy.org 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 general, but in this case,
On Wed, May 16, 2012 at 11:33 AM, Martin v. Löwis mar...@v.loewis.de 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
On Wed, May 16, 2012 at 5:03 PM, Greg Ewing greg.ew...@canterbury.ac.nz 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
