Hey guys, let's not go in four different directions and waste all this
bandwidth on debating the four examples I gave. Everyone has
different ideas on enhancing the language. If you believe this is a
bad idea, regardless of the particular examples, let's talk.
If you believe as I do that Python is not yet the ultimate language,
and some syntactical changes are still to come, then it seems like
using a very distinct symbol like @ may have some merits. This is not
a suggestion to make the language "perlesque". The difference is that
@ not a menagerie of symbols with various tricky meanings, but one
very noticable and unique symbol that says "Pay attention, I am
different." It has no other meaning.
Wouldn't it be nice, for example, if instead of special keywords like
'lambda' and 'yield', we had used '@(args)' and '...@return'. ( No, I'm
not advocating we go back and change what has been done.) In both
these cases, we had a well-established syntax that needed a slight
The 'lambda function' for example, was needed to cram a small block of
code into a tight space. By saying '@x,y:' instead of 'lambda x,y:',
we not only avoid the need for a new keyword, but we better serve the
purpose of tightly packing some code. We would also avoid mystifying
beginners. "It has no magic meaning. It's just a way to write a
function without a name."
Sorry if my intentions weren't clear in my original post.
On Wed, 10 Mar 2004 14:01:00 -0700, David MacQuigg <dmq at gain.com>
>Seems like we need a simple way to extend Python syntax that doesn't>break existing syntax or clash with any other syntax in Python, is>easy to type, easy to read, and is clearly distinct from the "base">syntax. Seems like we could put the @ symbol to good use in these>situations. Examples:
[ add your own examples here ]
>Each of these examples is debatable, but my point is that there are>many enhancement requests like this, and some may be worthy of>inclusion in the core language. It would be nice if there was a>consistent way to add stuff like this. It certainly beats adding ugly>statements like 'lambda'.>>It might even be possible to allow limited extension of the language>by users, provided the extensions are introduced by the special>symbol. This would allow the flexibility of Ruby or Lisp without the>cost of forking the language into many dialects.>>Maybe we should collect a bunch of little enhancements like the above,>and put them all into one PEP. Any suggestions? Pet peeves? Stuff>you would like to see, but not worthy of a PEP by itself?