On 27 May 2012 23:12, Nathaniel Smith <n...@pobox.com> wrote: > On Sun, May 27, 2012 at 10:24 PM, Dag Sverre Seljebotn > <d.s.seljeb...@astro.uio.no> wrote: >> On 05/18/2012 10:30 AM, Dag Sverre Seljebotn wrote: >>> >>> On 05/18/2012 12:57 AM, Nick Coghlan wrote: >>>> >>>> I think the main things we'd be looking for would be: >>>> - a clear explanation of why a new metaclass is considered too complex a >>>> solution >>>> - what the implications are for classes that have nothing to do with the >>>> SciPy/NumPy ecosystem >>>> - how subclassing would behave (both at the class and metaclass level) >>>> >>>> Yes, defining a new metaclass for fast signature exchange has its >>>> challenges - but it means that *our* concerns about maintaining >>>> consistent behaviour in the default object model and avoiding adverse >>>> effects on code that doesn't need the new behaviour are addressed >>>> automatically. >>>> >>>> Also, I'd consider a functioning reference implementation using a custom >>>> metaclass a requirement before we considered modifying type anyway, so I >>>> think that's the best thing to pursue next rather than a PEP. It also >>>> has the virtue of letting you choose which Python versions to target and >>>> iterating at a faster rate than CPython. >>> >>> >>> This seems right on target. I could make a utility code C header for >>> such a metaclass, and then the different libraries can all include it >>> and handshake on which implementation becomes the real one through >>> sys.modules during module initialization. That way an eventual PEP will >>> only be a natural incremental step to make things more polished, whether >>> that happens by making such a metaclass part of the standard library or >>> by extending PyTypeObject. >> >> >> So I finally got around to implementing this: >> >> https://github.com/dagss/pyextensibletype >> >> Documentation now in a draft in the NumFOCUS SEP repo, which I believe is a >> better place to store cross-project standards like this. (The NumPy >> docstring standard will be SEP 100). >> >> https://github.com/numfocus/sep/blob/master/sep200.rst >> >> Summary: >> >> - No common runtime dependency >> >> - 1 ns overhead per lookup (that's for the custom slot *alone*, no >> fast-callable signature matching or similar) >> >> - Slight annoyance: Types that want to use the metaclass must be a >> PyHeapExtensibleType, to make the binary layout work with how CPython makes >> subclasses from Python scripts >> >> My conclusion: I think the metaclass approach should work really well. > > Few quick comments on skimming the code: > > The complicated nested #ifdef for __builtin_expect could be simplified to > #if defined(__GNUC__) && (__GNUC__ > 2 || __GNUC_MINOR__ > 95) > > PyCustomSlots_Check should be called PyCustomSlots_CheckExact, surely? > And given that, how can this code work if someone does subclass this > metaclass?
I think we should provide a wrapper for PyType_Ready, which just copies the pointer to the table and the count directly into the subclass. If a user then wishes to add stuff, the user can allocate a new memory region dynamically, memcpy the base class' stuff in there, and append some entries. > Stealing a flag bit (but now to indicate this metaclass) would allow > us to make a real PyCustomSlots_Check function that was still fast. It > would also mean that different implementations didn't have to > rendezvous on a single PyExtensibleType_Type, so long as they all used > the same flag bit. That would let us skip monkeying around with > sys.modules. > > Speaking of which, surely we should not be using sys.modules for this? > Stashing it in sys itself or something would make more sense, if we're > going to do it at all. I think a module makes sense, if mangled appropriately. A module really means shared state (even if the only state are the functions and classes). > - N > _______________________________________________ > cython-devel mailing list > cython-devel@python.org > http://mail.python.org/mailman/listinfo/cython-devel _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel
