Ideas for Python 3

[Josiah Carlson]

>>>>>L = [:x:x**2, :x:x+4, :x:x/5, :x:2-x, :x:x*7 ]
>>>>
>>>>Ick.
>>>
>>>Could you be more specific? :>)
>>
>>Sure, the general format of your anonymous function syntax given above 
>>does not offer anything that a new user can search for.
> 
> 
> This is a good point, and one I hadn't thought of.  The counter is
> that function definition syntax is so basic and so prevalent that any
> user of Python will already know it.  Lambdas are seldom used, but by
> making their syntax almost identical to normal functions, we can make
> them self-explanatory.  I would add one very short paragraph at the
> end of an introduction to functions.
> """
> Nameless Functions
> ------------------
> There is a short form of a function definition, which is sometimes
> used in lists or other places where space is tight.  If you can write
> your function as a single expression, you can use the short form by
> just leaving off the function's name and the return keyword.
> .... example above showing long form and short form.
> """
> [snip further discussion on searchability]

After reading the remainder of your post, I have come to the opinion 
that of all your offered syntaxes, there exists only one syntax for 
named and nameless functions that /doesn't/ have severe handicaps of one 
kind or another.

def funct(arg):
     ... #body
     return result

funct = def(arg): result

The above has both a searchable keyword, is easy to describe (you gave a 
sufficient explanation), and doesn't suffer from the "looks like a 
slice" (seq[:x:x**2]),  "looks like a function call in a slice" 
(seq[f(x):x**2]),  due to the existance of the 'def' keyword.

Ultimately it will come down to what people find most intuitive to 
program with.  I think the "lamdba replaced with def adding parenthesis" 
syntax is preferential to the other options (with removing lambdas a far 
second, and all other options not even in the running), and I would 
expect that other current Python users would agree.


I've read the link you posted, and I've previously taken a look at 
Prothon.  Prototype syntax does not suit my taste in programming 
languages.  If Python 3.0 becomes Prothon, I'll fork the most recent 
Python 2.x codebase that I prefer, maintaining it myself if necessary.

Just as my anti-prototype perspective colors my opinions on what is 
reasonable, I would imagine that your pro-prototype perspective colors 
yours.  I would also expect that someone who enjoys using lisp or 
perhaps SML would have their opinion on what is reasonable, colored by 
their preferences.  Considering that Python is not a prototype-based 
language today in 2.3 (or the forthcoming 2.4 in the fall), having it 
become one in Python 3 would be quite a drastic change, quite literally 
like going from Python 2.3 to Prothon.

  - Josiah