On 12/03/2012 03:42 PM, Gregory P. Smith wrote: > On Mon, Dec 3, 2012 at 2:29 PM, Larry Hastings <larry at hastings.org > <mailto:larry at hastings.org>> wrote: > > Default > values for arguments are represented in C as strings; the conversion > process attempts eval() on the string, and if that works it uses the > result, otherwise it simply passes through the string. > > > I think passing on the string if that doesn't work is wrong. It could > lead to a behavior change not realized until runtime due to some other > possibly unrelated thing causing the eval to fail. Good point. I amend my proposal to say: we make this explicit rather than implicit. We declare an additional per-parameter flag that says "don't eval this, just pass through the string". In absence of this flag, the struct-to-Signature-izer runs eval on the string and complains noisily if it fails. > * Right now Clinic paves over the PyArg_ParseTuple API for you. > If we convert CPython to use Clinic everywhere, theoretically we > could replace the parsing API with something cleaner and/or faster. > Does anyone have good ideas (and time, and energy) here? > > > By "paves over" do you mean that Clinic is currently using the > ParseTuple API in its generated code? Yes. Specifically, it uses ParseTuple for "positional-only" argument processing, and ParseTupleAndKeywords for all others. You can see the latter in the sample output in my original email. > Yes, we should do better. But don't hold Clinic up on that. As I have not! > But the biggest unresolved question... is this all actually a terrible > idea? > > > No it is not. I like it. \o/ //arry/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4