Josh Haberman added the comment:
> Everything is copied by `_FromSpec` after all.
One thing I noticed isn't copied is the string pointed to by tp_name:
https://github.com/python/cpython/blob/0c50b8c0b8274d54d6b71ed7bd21057d3642f138/Objects/typeobject.c#L3427
This isn't an iss
Josh Haberman added the comment:
> Windows/MSVC defines DLLs as separate programs, with their own lifetime and
> entry point (e.g. you can reload a DLL multiple times and it will be
> reinitialised each time).
All of this is true of so's in ELF also. It doesn&#
New submission from Josh Haberman :
I believe the following excerpt from the docs is incorrect
(https://docs.python.org/3/c-api/typeobj.html#c.PyTypeObject.tp_base):
> Slot initialization is subject to the rules of initializing
> globals. C99 requires the initializers to be “a
Josh Haberman added the comment:
This behavior is covered by the standard. The following C translation unit is
valid according to C99:
struct PyTypeObject;
extern struct PyTypeObject Foo_Type;
struct PyTypeObject *ptr = &Foo_Type;
Specifically, &Foo_Type is an "address
Josh Haberman added the comment:
> On ELF/Mach-O...
nvm, I just realized that you were speaking about Windows specifically here. I
believe you that on Windows "static" makes no difference in this case.
The second point stands: if you consider LoadLibrary()/dlopen() to be
Josh Haberman added the comment:
> "static" anything in C is completely irrelevant to how symbols are looked up
> and resolved between modules
That is not true. On ELF/Mach-O the "static" storage-class specifier in C will
prevent a symbol from being added to the d
Josh Haberman added the comment:
> I consider Py_tp_bases to be a mistake: it's an extra way of doing things
> that doesn't add any extra functionality
I think it does add one extra bit of functionality: Py_tp_bases allows the
bases to be retrieved with PyType_GetSlot().
Josh Haberman added the comment:
> It's better to pass the metaclass as a function argument, as with bases. I'd
> prefer adding a new function that using a slot.
Bases are available both as a slot (Py_tp_bases) and as an argument
(PyType_FromSpecWithBases). I don't s
Josh Haberman added the comment:
> Passing the metaclass as a slot seems like the right idea for this API,
> though I recall there being some concern about the API (IIRC, mixing function
> pointers and data pointers doesn't work on some platforms?)
PyType_Slot is defined as
Josh Haberman added the comment:
I found a way to use metaclasses with the limited API.
I found that I can access PyType_Type.tp_new by creating a heap type derived
from PyType_Type:
static PyType_Slot dummy_slots[] = {
{0, NULL}
};
static PyType_Spec dummy_spec
Josh Haberman added the comment:
> You can also call (PyObject_Call*) the metaclass with (name, bases,
> namespace);
But won't that just call my metaclass's tp_new? I'm trying to do this from my
metaclass's tp_new, so I can customize the class creation process. Th
Josh Haberman added the comment:
I know this is quite an old bug that was closed almost 10 years ago. But I am
wishing this had been accepted; it would have been quite useful for my case.
I'm working on a new iteration of the protobuf extension for Python. At
runtime we create
12 matches
Mail list logo
