Larry, Nick, On January 20, 2014 at 8:00:35 AM, Nick Coghlan (ncoghlan at gmail.com) wrote: > > Your proposal gets a "no, absolutely not" vote from me. > > 1. We already have a notion of "optional parameters". Parameters > with default values are optional. > 2. Your proposed syntax doesn't mention how we'd actually establish > default values for parameters. So it's insufficient to handle > existing code. > 3. Your syntax/semantics, as described, can't convey the concept > of optional groups. So it's insufficient to solve the problem > it sets out to solve. > 4. Your proposed syntax changes 80% of existing code--any parameter > with a default value. I don't know how you concluded this was "simpler". I withdraw my proposal in its current form. Turns out I’ve missed groups definition in PEP 436. But, just want to add a few things. My proposal is still good for the other problem — having support for optional parameters (where “optional” is in a sense of itertools.repeat last parameter). Again, my example from the first email in this thread. Suppose you want to write itertools.repeat in python (where “n” can not be None, what matters is *was is passed or not*): _marker = object() def repeat(elem, n=_marker): pass Now, if you do 'str(inspect.signature(repeat))’ you’ll have something like: '(elem, n=<object object at 0x108650080>)’ However, if we choose to have a special marker object defined in the stdlib, you’d write: def repeat(elem, n=functools.optional): if n is functools.optional: # no param was passed and str of signature would look like ‘(elem[, n])’. Yury
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