[Python-ideas] Marking keyword arguments (was: f-string, for dictionaries)
Stephen J. Turnbull
turnbull.stephen.fw at u.tsukuba.ac.jp
Fri Oct 28 23:00:17 EDT 2016
Sven R. Kunze writes:
> So, instead providing this kind of syntax for dicts only, why not also
> providing them for kwargs? Basically marking arguments as keyword arguments:
>
> my_func(:param1, :param2)
Please don't. I need to write Lisp, where that syntax has a
completely different meaning: "this symbol has itself as a value".
Ie, (eval :key) always evaluates to :key itself.
Syntax based on single characters is very hard to get right once you
get past the 4-function calculator level. C's ternary operator was
inspired design IMO (YMMV), but far too many others just fall flat.
One aspect of Python that is important to me is that it is executable
pseudo-code, as they say. A litmus test for that is that a reasonably
bright English-speaking 12-year-old without previous exposure to
Python should be able to tell you what a statement does. There are a
few cases where that principle is violated (said 12-year-old won't
know the difference between "=" and '==' though context will probably
teach her, nor the meaning of the attribute operator period), but
mostly it works. Infix operators "in", "or", and "and" help a lot.
As English, the ternary operator "it's-this if test else it's-that" is
stilted but the 12-year-old can parse it.
This test also applies to the null-coalescing operators and '@'. The
fact that '@' got in means the principle is hardly inviolable, of
course. At least in the case of '@' you can tell it's a binary
operator, but the "implicit-assignment" colon and "null-coalescing"
question mark operator-mode-modifying operator[1] could do anything.
Null-coalescing is plausible -- I've never needed it, nor do I expect
to need it any time soon, but the examples of where it would be used
seem reasonable to me, and where needed the existing WTDIs quickly
lead to an unreadable morass of nested ternaries with extremely
redundant operands. I'll leave the judgment about whether it clears
the bar to those who have broader experience than I.
But this colon notation is horrible. foo=foo and 'foo':foo are
already the respective TOOWTDIs, and quite readable. These operations
don't nest, so I can't see how they would become either unreadable or
exponentially redundant. Rather than change Python, improve your
editor[2], and your fingers will thank you for the rest of your life,
even when you're not editing Python.
Footnotes:
[1] If that doesn't scare you, what will?<wink/>
[2] In Emacs with "dynabbrev" enabled the keystrokes are respectively
"f o o = meta-/" and "' f o o ' : meta-/". A good editor can -- and
IMO should -- make this operation efficient, as a by-product of
providing context-dependent prefix expansion.
More information about the Python-ideas
mailing list