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! -jJ