On Sat, Jul 4, 2020, at 12:48, William Pickard wrote: > For backwards compatibility, PyTypeObject will eventually have the > flag: Py_TPFLAG_OMIT_PYOBJECT_SIZE, but from what I can tell, > eventually all extensions should be using PyType_FromSpec/it's variants.
Er... I don't mean how do they create the PyType. I mean how do they create the actual data type they use? https://docs.python.org/3/extending/newtypes_tutorial.html#adding-data-and-methods-to-the-basic-example What does the definition of CustomObject look like? How do I access the "number" member, given a PyObject *? Can I still cast the PyObject * to CustomObject *, or do I have to go through some conversion function? > I'm now leaning towards replacing the Static Library with a precompiled > header (Those will not users from building DLLs as they're just a plain > headers compiled to machine code used differently from obj files, I > BELIEVE at least, haven't tested inlinability yet). My understanding is that you can't combine the precompiled header with a dll or even obj file, you have to combine it with source code, which means requiring a precompiled header prevents extension libraries from being shipped as binaries. Requiring modules to be rebuilt from source code to support any changed definition of PyObject, as far as I can tell, defeats the entire purpose of making it opaque. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/LDJEKJ2F4W6GLT623R27NIPGI5AZYQNL/ Code of Conduct: http://python.org/psf/codeofconduct/