This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author skrah
Recipients brian.curtin, eric.araujo, loewis, mhammond, skrah, tarek
Date 2010-11-28.11:52:30
SpamBayes Score 2.1009e-06
Marked as misclassified No
Message-id <1290945153.12.0.207408298863.issue9709@psf.upfronthosting.co.za>
In-reply-to
Content
Thinking about it, declaring PyMODINIT_FUNC as void would be a huge
step backwards. Using PyMODINIT_FUNC is the correct way of doing things.
The current situation punishes developers who actually read the docs.

If a C module stops working because of the change, _all_ the maintainer
has to do is change a single line in the sources. PyMODINIT_FUNC is
nearly 10 years old, so I think this is not too much to ask.


May I suggest deprecating get_export_symbols() for these reasons:

  1) The docstring is incorrect: The function does not 'either
     use export_symbols or "PyInit_" + module_name'. It forcibly
     adds PyInit_" + module_name', if it isn't already present in
     export_symbols.

  2) PyMODINIT_FUNC - which is nearly 10 years old - has obsoleted
     this function.

  3) Developers who do the right thing are punished, since they have
     to investigate the warning.



It is also possible to leave the function (see initfunc2.patch). Then
again, on its own get_export_symbols() is practically useless.
History
Date User Action Args
2010-11-28 11:52:33skrahsetrecipients: + skrah, loewis, mhammond, tarek, eric.araujo, brian.curtin
2010-11-28 11:52:33skrahsetmessageid: <1290945153.12.0.207408298863.issue9709@psf.upfronthosting.co.za>
2010-11-28 11:52:30skrahlinkissue9709 messages
2010-11-28 11:52:30skrahcreate