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

[Jewett, Jim J]

    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