Georg Brandl added the comment:

> 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... *:-)

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20186>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to