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 ncoghlan
Recipients BreamoreBoy, Trundle, georg.brandl, hawkerm, michael.foord, ncoghlan
Date 2011-05-16.12:05:40
SpamBayes Score 3.3649177e-09
Marked as misclassified No
Message-id <1305547541.6.0.481660670425.issue1748064@psf.upfronthosting.co.za>
In-reply-to
Content
The challenge with C functions is that this becomes *additional* metadata that somehow needs to be provided to the method and function creation process. None of our APIs are set up to accept that information (and obviously no code is set up to provide it, either).

What might be nice is a way to graft the signature information from a Python implementation onto a C implementation (which would be quite straightforward given PEP 362 and a writable __signature__ slot in the C objects).

The other virtue of this approach is that the Python metadata will be testable, so it doesn't run the same risk of getting out of date that manually maintained metadata at the C level does. It would work naturally for C acceleration modules, and wouldn't be any more effort to add for pure C code than direct annotations at the C level would be.
History
Date User Action Args
2011-05-16 12:05:41ncoghlansetrecipients: + ncoghlan, georg.brandl, hawkerm, michael.foord, Trundle, BreamoreBoy
2011-05-16 12:05:41ncoghlansetmessageid: <1305547541.6.0.481660670425.issue1748064@psf.upfronthosting.co.za>
2011-05-16 12:05:41ncoghlanlinkissue1748064 messages
2011-05-16 12:05:40ncoghlancreate