Extending Python Syntax with @

[David MacQuigg]

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:

print @(separator = None) x, y, z

@x,y:x*x+y*y -- anonymous function

@f(x,y) -- generator function that can accept new arguments
with each call

@x @y @z -- short for instance variables in a method definition

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?

-- Dave

[Jarek Zgoda]

Re: Extending Python Syntax with @

David MacQuigg <dmq@gain.com > pisze:
[color=blue]
> 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.[/color]

No, we don't. You need it.

--
Jarek Zgoda

http://jpa.berlios.de/

[Ivan Voras]

Re: Extending Python Syntax with @

David MacQuigg wrote:
[color=blue]
> syntax. Seems like we could put the @ symbol to good use in these
> situations. Examples:[/color]

No, don't do that!! I hate perl precisley because of littering the code
with 'special characters'! The beauty of python code as it is, is that
it reads like a book, with punctuation to help the reader, rather than
the typesetter.

[John Roth]

Re: Extending Python Syntax with @

"David MacQuigg" <dmq@gain.com > wrote in message
news:s2vu409dio 5vc9ndl81dcinte agrkpntf5@4ax.c om...[color=blue]
> 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:[/color]

There is indeed a cost to adding new keywords and operators;
it's possible that existing programs will break. It's quite possible
to design a language where this wouldn't happen, but Python is
not that language.

As it turns out, there is one very simple key to a language
with keywords where adding new ones won't break existing
programs: put them in a lexically distinguishable namespace.
It happens that solution is quite unpleasant to work with -
unless it's supported by a syntax aware editor/IDE. Someday
people will get over their attachment with being able to write
programs with any old text editor that happens to be lying
around, and being able to print their programs without
needing a special formatting program, but that day isn't today,
and I doubt if it's tomorrow.

The problem with adding new operators is a quite different
issue. It arises from the language designer trying to be too
nice to the developers. If the lexer simply collected the longest
possible string of special characters *before* checking if that
collection of special characters made a valid token, and declared
a syntax error if it didn't, then there would be no difficulty with
adding new operators.

That solution is also fairly unpleasant: we're a bit too used to
being able to string special character operators together without
separating them with white space. Again, an intelligent editor/IDE
would help here, too.

An intelligent editor/IDE would also make it possible to add
any of the numerous mathematical symbols from the Unicode
set easily: it could adjust for the developer's preferences in
entering them, and would, of course, display them properly.

I am, I suppose, getting old and cynical enough to have quit
expecting anything quite so radical as a language that actually
expectes the editor/IDE to pull its share of the work.

John Roth

[Ben Finney]

Re: Extending Python Syntax with @

On Wed, 10 Mar 2004 16:50:58 -0500, John Roth wrote:[color=blue]
> Someday people will get over their attachment with being able to write
> programs with any old text editor that happens to be lying around, and
> being able to print their programs without needing a special
> formatting program, but that day isn't today, and I doubt if it's
> tomorrow.[/color]

I doubt it's ever, because such a day would have to be preceded by the
day when programs no longer need to be inspected, maintained or
transferred between systems not specifically set up as developer
workstations.

--
\ "Those who can make you believe absurdities can make you commit |
`\ atrocities." -- Voltaire |
_o__) |
Ben Finney <http://bignose.squidly .org/>

[Edward K. Ream]

Re: Extending Python Syntax with @

> @x @y @z -- short for instance variables in a method definition

This is completely unnecessary. Leo uses the following convention:

def whatever(self):
v = self
v.whatever

The assignment v = self (or x = self etc.) indicates the expected type of
self and saves keystrokes. This convention has been useful in refactorings
when moving methods from one class to another: all that had to be done is to
change the v = self line to something else.

BTW, it would also be possible to define the function as follows:

def whatever(v):
v.whatever

However, this isn't proper Python style and Pychecker complains.

Edward
--------------------------------------------------------------------
Edward K. Ream email: edreamleo@chart er.net
Leo: Literate Editor with Outlines
Leo: http://webpages.charter.net/edreamleo/front.html
--------------------------------------------------------------------

[John Roth]

Re: Extending Python Syntax with @

"Ben Finney" <bignose-hates-spam@and-benfinney-does-too.id.au> wrote in
message news:slrnc4v696 .lhs.bignose-hates-spam@iris.polar .local...[color=blue]
> On Wed, 10 Mar 2004 16:50:58 -0500, John Roth wrote:[color=green]
> > Someday people will get over their attachment with being able to write
> > programs with any old text editor that happens to be lying around, and
> > being able to print their programs without needing a special
> > formatting program, but that day isn't today, and I doubt if it's
> > tomorrow.[/color]
>
> I doubt it's ever, because such a day would have to be preceded by the
> day when programs no longer need to be inspected, maintained or
> transferred between systems not specifically set up as developer
> workstations.[/color]

How much real development (I don't mean archiving) do we do
today on systems without appropriate tools? Very little. The issue
isn't trying to develop on systems without appropriate tools, it's
developers that won't use tools that help them work.

John Roth

/>

[Wayne Folta]

Re: Extending Python Syntax with @

Personally, I'd much prefer that we get things like

def @del

instead of

def __del__

Save some keystrokes and I think the @ is attention-drawing-enough that
we don't lose anything. Of course, all it's doing is adding @ to the
legal characters in a variable name, which might be a waste instead of
attaching a syntax to it, but...

[Jeff Epler]

Re: Extending Python Syntax with @

I don't like your suggestion. You propose using @ in 4 different
ways, one of which I don't even understand
-- to pass keyword arguments to statements
-- instead of the perfectly good "lambda" keyword
-- mumble generators mumble (this is the example I don't understand)
-- instead of the perfectly good "self." idiom

Jeff

[David MacQuigg]

Re: Extending Python Syntax with @

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
variation.

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.

-- Dave

On Wed, 10 Mar 2004 14:01:00 -0700, David MacQuigg <dmq@gain.com >
wrote:
[color=blue]
>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:[/color]

[ add your own examples here ]
[color=blue]
>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?[/color]

[Erik Max Francis]

Re: Extending Python Syntax with @

Ivan Voras wrote:
[color=blue]
> David MacQuigg wrote:
>[color=green]
> > syntax. Seems like we could put the @ symbol to good use in these
> > situations. Examples:[/color]
>
> No, don't do that!! I hate perl precisley because of littering the
> code
> with 'special characters'! The beauty of python code as it is, is that
> it reads like a book, with punctuation to help the reader, rather than
> the typesetter.[/color]

Further, @ and $ are already used by some Python meta-applications in
order to signal embedding Python code in something else, since these
symbols are not used in Python itself. Templating systems often rely on
such symbols not being in the language and staying out.

But the Perlification of Python is the most relevant objection here.

--
__ Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
/ \ San Jose, CA, USA && 37 20 N 121 53 W && &tSftDotIotE
\__/ An ounce of hypocrisy is worth a pound of ambition.
-- Michael Korda

[Cameron Laird]

Re: Extending Python Syntax with @

In article <fkbv40dh57pk95 27seaf3etjd0k7k ncugc@4ax.com>,
David MacQuigg <dmq@gain.com > wrote:

[DH]

Re: Extending Python Syntax with @


I would prefer "anonymous" or "implicit" things be referred to by
nothing at all instead of @. For example, instead of "self.x", just
have ".x". Instead of lambda, allow for unnamed "def" code blocks with
[] or () to allow for multiple lines.
def (optional params) [optional decorator]: [
some code here...
]

Some things I might like to see in python, in no particular order:
- an "=~" operator
- pychecker bundled with python, since it catches so many errors
beginners and non-beginners make.
- allow for curly braces to specify a multi-line code block so []
and () are not abused.
- use the keyword "function" instead of "def"
- make colons optional after function and class declarations. People
forget to type them anyway.
- be able to refer to variables case-insensitively though they
are still stored case-sensitively. Make keywords like None,
True, and False case insensitive.
- no more "self" parameter required for class methods. If need be,
maybe class instance methods could be specified by
starting the name with "."

Of course, the chances of any of these happening in python = None, so a
better long term idea is to make it easier for people to create custom
scripting languages for a common virtual machine like jvm, parrot, maybe
python in python (pypy), etc.

http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html

http://codespeak.net/pypy/index.cgi?home

http://www.parrotcode.org/

[Steve Lamb]

Re: Extending Python Syntax with @

On 2004-03-10, David MacQuigg <dmq@gain.com > wrote:[color=blue]
> print @(separator = None) x, y, z
>
> @x,y:x*x+y*y -- anonymous function
>
> @f(x,y) -- generator function that can accept new arguments
> with each call
>
> @x @y @z -- short for instance variables in a method definition[/color]
[color=blue]
> Each of these examples is debatable, but my point is that there are[/color]

No, they're not. You want Perl, use Perl. I used it for 5 freakin' years
and have had enough of "and this line noise means THIS but only after that
line noise!" I finally gave up when I read that they were thinking about
making case significant declarations. #$%#$ that.

--
Steve C. Lamb | I'm your priest, I'm your shrink, I'm your
PGP Key: 8B6E99C5 | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------

[Heather Coppersmith]

Re: Extending Python Syntax with @

On Wed, 10 Mar 2004 16:50:58 -0500,
"John Roth" <newsgroups@jhr othjr.com> wrote:
[color=blue]
> ... Someday people will get over their attachment with being
> able to write programs with any old text editor that happens to
> be lying around, and being able to print their programs without
> needing a special formatting program, but that day isn't today,
> and I doubt if it's tomorrow.[/color]

It will be *never*.

At least emacs and vi share a common file format. Even if you
prefer [the wrong one], you are free to use it to edit "our" files
should we ever collaborate.

Not only that, but sed, grep, awk, diff, cvs, tr, m4, perl (gasp),
python (whew!), lex, yacc, uncountable interactive shells, and any
other tool(s) you or I care to write for whatever odd requirement
comes up also share that common format (the occasional OS-imposed
newline convention notwithstanding ).

Is your IDE that flexible/extensible/powerful?

So perhaps you're right, and that IDE that replaces "any old text
editor" is Unix (with all due copyright apologies) and everything
in its $PATH.

IMO, YMMV, etc.

Regards,
Heather

--
Heather Coppersmith
That's not right; that's not even wrong. -- Wolfgang Pauli