"R.Wieser"  writes:
>> PWM_init_PWMType sets up the type (someting that doesn't need to
>> know about any module it may end up in), PyModule_AddObject gives
>> the type a name in a module. They're logically quite separate operations.
>
> True.    But somehow I have the strong urge to place both in a single
> function, and place it inside the PWM api sourcefile, py_pwm.c.  The reason
> for that ?    The PyModule_AddObject() function call gets two arguments,
> "PWM" and PWMType, which the main module, py_gpio.c, doesn't need to know
> anything about and should correlate with other data in the py_pwm.c file.
> In short, it looks cleaner to me that way.

You’re welcome to your opinion and your urges, but most programmers
would see your version as wrong due to its mixing of separate concerns.
I would reject it in a PR.

>>> Is there a (technical or otherwise) reason to why the "PyTypeObject
>>> PWMType ={...}" structure (just above the call) does not not just
>>> contain "PyType_GenericNew" as the relevant element ?
>>
>> There's no technical reason.
>
> I thought so too, but have started to doubt myself :
>
> As far as I can (now) tell, the "PWMType.tp_new = PyType_GenericNew;" line
> creates a single instance and stores it, which than is referenced in all
> further access thru the "tp_new" field - instead of creating a new instance
> of it every time that that field is referenced, which is what I think would
> happen if the PyType_GenericNew is placed in the table itself.    Does that
> make any sense ?

It makes no sense at all. Both approaches behave the same, ending up
with the tp_new member set to PyType_GenericNew.

--
https://www.greenend.org.uk/rjk/

--- SoupGate-Win32 v1.05