Author skrah
Recipients rhettinger, serhiy.storchaka, skrah, vstinner
Date 2017-01-27.16:01:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <20170127160107.GA4128@bytereef.org>
In-reply-to <CAMpsgwbR1bTRzxfpGySG6ckXACaU+=nCMUAFOwODSwLH7i17iQ@mail.gmail.com>
Content
> STINNER Victor added the comment:
> > AC will not happen: It makes the module too large and unreadable.
> 
> Ah you dislike the additional [clinic input] sections?

Yes, they tear apart the code.  I stopped reading many C files because
of this.  Brett asked why several people don't review, this is actually
*one* of the reasons for me.

> It's kind of strange when you have to convert existing code, when once
> the code uses AC, I prefer AC to separated documentation variables. It
> helps to keep docstrings more up to date, and it helps to enhance the
> API (ex: allow keywords, rename parameters to better names, etc.). It
> also helps to make the documentation closer to the code, which is IMHO
> a good thing :-)

Apparently it works for several people, but not me.

> IMHO the PyArg_ParseXXX() calls and their "kwlist" static variable are
> "unreadable", and I'm happy to be able to hide them!
> 
> FYI decimal-2.patch replaces PyArg_ParseTupleAndKeywords() with
> _PyArg_ParseStackAndKeywords() with static _PyArg_Parser object. This
> object only decides keyword names once and is more efficient to parse
> arguments. It explains partially the speedup. Only partially because
> bm_telco only calls the .quantize() method, and it only uses
> positional arguments (no keyword arguments) ;-)

Okay, thanks!
History
Date User Action Args
2017-01-27 16:01:24skrahsetrecipients: + skrah, rhettinger, vstinner, serhiy.storchaka
2017-01-27 16:01:24skrahlinkissue29301 messages
2017-01-27 16:01:24skrahcreate