Message207931
> 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:58 | georg.brandl | set | recipients:
+ georg.brandl, larry |
2014-01-12 07:56:58 | georg.brandl | set | messageid: <1389513418.11.0.106994377574.issue20186@psf.upfronthosting.co.za> |
2014-01-12 07:56:58 | georg.brandl | link | issue20186 messages |
2014-01-12 07:56:57 | georg.brandl | create | |
|