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/

Reply via email to