Larry Hastings <larry at hastings.org> wrote: > * The DSL currently makes no provision for specifying per-parameter > type annotations. This is something explicitly supported in Python; > it should be supported for builtins too, once we have reflection support. > > It seems to me that the syntax for parameter lines--dictated by > Guido--suggests conversion functions are themselves type annotations. > This makes intuitive sense. Really, did you read PEP 437? It's all in there. > But my thought experiments in how to convert the conversion function > specification into a per-parameter type annotation ranged from obnoxious > to toxic; I don't think that > line of thinking will bear fruit. Did you look at the patch that I posted in issue #16612? It's already implemented: $ ./printsemant Tools/preprocess/testcases/posix_stat.c PROGRAM[ SOURCE[...], DEFINE[ CNAME posix_stat, SPEC[ DECLARATION { fun_fqname = os.stat, fun_name = stat, fun_cname = posix_stat, fun_kind = Keywords, fun_params = [ { param_name = path, param_type = [bytes, int, str], <== here it is param_default = NONE, param_kind = (PosOrKwd, Required), param_conv = path_converter, param_parseargs = [ ConvArg { arg_name = path_converter, arg_type = int (*converter)(PyObject *, void *) arg_use_ptr = false }, MainArg { arg_name = path, arg_type = path_t, arg_use_ptr = true }]}, [...] Stefan Krah
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