[Python-Dev] Re: new syntax for wrapping (PEP 318) (original) (raw)

Jewett, Jim J jim.jewett at eds.com
Wed Feb 25 16:43:14 EST 2004 

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

More information about the Python-Dev mailing list