Am 09.10.2013 01:33, schrieb Larry Hastings: > > I've contributed a new PEP to humanity. I include the RST for your reading > pleasure below, but you can also read it online here: > > http://www.python.org/dev/peps/pep-0457/
... > * Documentation can clearly, unambiguously, and > consistently express exactly how the arguments > for a function will be interpreted. I don't really like it from the docs perspective. We have quite a large amount of C functions with positional-only parameters. Adding a "/" to each of those is a) a tedious task and b) probably not helpful for a lot of people: For each user who tries to call a C function with keyword args and is confused, there will be ten or twenty who are confused by the strange "/" in the first place. (We get quite a few questions about the *args and **kwargs syntax already that is infrequently used, which is otherwise _part of the language_.) Rather, I would try to make as many C functions as possible "regular", i.e. use PyArgs_ParseTupleAndKeywords or the Argument Clinic equivalent. For the few that should be blazingly fast or have irregular signatures, the documentation can be amended by a single sentence "This function does not support passing keyword arguments." and that's the end of it. > * The syntax is reserved for future use, in case > the community decides someday to add positional-only > parameters to the language. For this purpose I'm also -1. Function definition has become almost too complex already with keyword-only arguments, although they at least have usefulness other than mimicking the deficiencies of an implementation detail... and the "undefined" singleton just smells wrong. Another way to spell "None" is just asking for trouble. > * Argument Clinic can use a variant of the syntax > as part of its input when defining > the arguments for built-in functions. For AC it's good enough I guess :) but that doesn't require a separate PEP. Also, the AC DSL can be changed much, much easier than the language can be if this syntax is accepted. cheers, Georg _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
