Michael> The "def name [modifiers]:" is unpythonic because: Michael> * It re-uses the "" for a completely new purpose, Michael> unrelated to lists or indexing.
Skip> Not necessarily. It names a list of functions to be applied Skip> to this function to get the final definition ...
Skip> def func1(a,b,c) [m for m in modifiers if is_enabled(m, "func1")]:
Skip> If you are going to add [...] as a function modifier syntax, Skip> I would argue that it should allow the full power of list Skip> (or generator) comprehensions.
Agreed. And why limit it to lists - why not any expression that evaluates to a list? Or maybe any sequence? Which is one reason that a bare "[...]" doesn't seem sufficient.
Michael> * It relies heavily on punctuation (the placement Michael> of the ":").
Skip> The placement of the ":" hasn't changed. It's still at Skip> the end. A list constructor was just stuffed in between Skip> the argument list and the colon.
def f(arg) [x] : # wrap f in x def f(arg) : [x] # start f's def with a list of x f(arg) [x] # call f, then select the x'th return value
and maybe: def f(arg) x : # wrap f in each element of x def f(arg) g(): # wrap f in each element returned by g() def f(arg) g()[x]: # wrap f in the x'th element returned by g()
These are all well-defined for parsing, but I don't think the distinctions are obvious to a human who doesn't already know the syntax.
Michael> * There's no good way for a newbie to look it up.
Skip> How do people learn about function names with leading underscores Skip> or leading and trailing double underscores?
They don't need to, in general. The specific functions that they do need (like __init__) are in the index. Though to be honest, this was a concern at first, when I thought that creating a class would require me to define a large number of methods. If I had been more deeply object-oriented, that might have put me off. Instead, I just started with functions instead of classes.
Skip> even though non-programmers will probably never have seen the Skip> "**" operator, they still manage to figure it out.
It took me several tries to get it working, though, and even then I was missing some points, so I had more confusing problems later. That isn't a desirable trait in new features.
Michael> All of these would be addressed by using a keyword. The only Michael> objection seems to be "we couldn't find a word we all Michael> liked". But that's hardly a good reason to go with pure Michael> punctuation.
Skip> Function modifiers would be a fairly advanced feature anyway
And so they are a good candidate for:
Explicit is better than implicit. Sparse is better than dense. Readability counts. In the face of ambiguity, refuse the temptation to guess. Namespaces are one honking great idea -- let's do more of those!
Skip> even though non-programmers will probably never have seen the "**" Skip> operator, they still manage to figure it out. Jim> It took me several tries to get it working, though, and even then I Jim> was missing some points, so I had more confusing problems later. Jim> That isn't a desirable trait in new features.
Sorry, I didn't mean
func(a1, a2, *args, **kwds)
a = b ** 2 Skip> Function modifiers would be a fairly advanced feature anyway Jim> And so they are a good candidate for: ... [ zen bits clipped ] ...
I don't follow your reasoning. If anything, features which are expected to be used by more advanced users should require less "COBOL" to be useful. I'm not arguing that the zen of Python shouldn't apply, just that advanced features (which will probably be used a lot less than more basic features) don't necessarily need quite the English-like structure supporting them in the language syntax.