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 georg.brandl
Recipients georg.brandl, larry
Date 2014-01-12.07:56:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> Wow.  I never knew about PyArg_UnpackTuple.  You're right, those 
> should be converted too.  Hooray, more entry points to convert.
> I'll write something up for the howto about UnpackTuple.

One thing to note is that (at least in math) many instances of UnpackTuple could have been replaced by ParseTuple.  See for example math_hypot: it uses UnpackTuple to get two objects, and then immediately calls PyFloat_AsDouble on them.  I've converted these using 'd' and not 'O' specifiers.

> I just did a quick check, and there are 96 entry points (by my count) 
> that use PyArg_UnpackTuple().  Shall I create Derby issues #19 and 
> #20, or do you have a better idea?

Probably better to add them to the issues that cover their modules, otherwise people might get confused.

> 2) For FUNC1 / 1A / 2 macros: right now you'd have to just copy and 
> paste over and over.  There might be something you could do with a 
> [python] block where you automatedly reuse the existing sigantures.  
> I was thinking about having Clinic support it directly, maybe with 
> the syntax:

> /*[clinic input]
> func_name = existing_func_name
> docstring goes here
> [...]*/
> You'd skip the parameters and the return annotation.  You could only 
> reuse functions from the current file.  Would that be a big boon to you?

That sounds good.

On the other hand, if clinic expanded cpp macros we could... *:-)
Date User Action Args
2014-01-12 07:56:58georg.brandlsetrecipients: + georg.brandl, larry
2014-01-12 07:56:58georg.brandlsetmessageid: <>
2014-01-12 07:56:58georg.brandllinkissue20186 messages
2014-01-12 07:56:57georg.brandlcreate