Julien Palard added the comment: > for just one use case
I don't think that using None in a default argument is "one use case", nor a "special case" it's more like a "widly used pattern" that I'd like to make simple to implement (also see http://bugs.python.org/issue28754#msg282891). I'm not sure you're against my idea of accepting None like: something: Py_ssize_t(c_default="-1") = None Or you're against my implementation, which I can understand, I'm not a fan of modifying getargs.c for this, it may be doable by implementing a new converter in clinic.py like "Py_ssize_t_optional", and it may not require more work than modifying getargs.c. But AC is already defining 4 different "default values", counting the "= value" from the AC DSL, I'm not sure that adding the "optional" string somewhere make any of this clearer, typically what about the semantic difference between: something: Py_ssize_t_optional() and something: Py_ssize_t() = None So my original idea was to accept "= None" indistinctly of the used type, I mean allowing: something: Py_ssize_t(c_default=…) = None something: float(c_default=…) = None something: double(c_default=…) = None … … Which is, I think, one of the clearest way to express "It's an optional parameter, on the Python side the default value is None, but c-side the default value is of the right type an is …". In other words, I'm proposing to optionally extend the "c_default" usage from "not given" to "not given or given None". I failed to implement if for any types, mainly because AC is delegating to getargs for Py_ssize_t, so I though starting with my specific need (Py_ssize_t for issue28754) was a good start and POC. Another solution may be to change the Py_ssize_t_converter to drop the format_unit, allowing us to implement the converter in clinic instead of getargs.c. It's opening a long term door of completly dropping non-"O" format units. I mean, if we drop every non-"O" format units in clinic we'll be able to use a faster implementation of _PyArg_ParseStack, one not parsing a mini-arg-definition-language at runtime (the "OO|nO&:"). I'm willing to implement something clean for this but please be more precise in your feedback. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28933> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
