Extending Python Syntax with @

[Isaac To]

Re: Extending Python Syntax with @

>>>>> "David" == David MacQuigg <dmq@gain.com > writes:

David> Wouldn't it be nice, for example, if instead of special keywords
David> like 'lambda' and 'yield', we had used '@(args)' and '@return'.
David> ( No, I'm not advocating we go back and change what has been
David> done.) In both these cases, we had a well-established syntax
David> that needed a slight variation.

I don't think it is an improvement. If you get puzzled reading a program
with lambda expressions, you remember that you conveniently skipped reading
"lambda" in the docs. If you read a program with generator, you know the
"yield" section at the new Python docs will help. Both is very clear
mentally: you can easily recall what you've learnt. If you read a program
containing silly @, where should you look? And will you still remember it
after 2 years of programming solely in Perl? I think everybody trying to
add language construct should remember "explicit is better than implicit".

David> The 'lambda function' for example, was needed to cram a small
David> block of code into a tight space. By saying '@x,y:' instead of
David> 'lambda x,y:', we not only avoid the need for a new keyword, but
David> we better serve the purpose of tightly packing some code. We
David> would also avoid mystifying beginners. "It has no magic meaning.
David> It's just a way to write a function without a name."

There is no real need to "cram a small block of code into a tight space":
your space is unlimited when writing programs. There are times when you
should want using less space: when you are expressing a sequence of really
simple things. If you are writing something as complicated as a "lambda x,
y: ..." and that "..." can't be put into your program conveniently, the odds
are that it really takes effort to understand that part. Then I don't think
that one really should try to put it into less space.

Regards,
Isaac.

[David MacQuigg]

Re: Extending Python Syntax with @

On Thu, 11 Mar 2004 01:28:47 -0000, claird@lairds.c om (Cameron Laird)
wrote:
[color=blue]
>In article <fkbv40dh57pk95 27seaf3etjd0k7k ncugc@4ax.com>,
>David MacQuigg <dmq@gain.com > wrote:
> .
> .
> .[color=green]
>>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."[/color]
> .
> .
> .
>No, for me it would be so far from nice I first suspected you
>of jesting, because, from my background, "lambda" *does* have
>a magic meaning, one that long precedes its (entirely apt) use
>in Python. For you, '@(args)' might indeed be more evocative;
>for me, not calling a lambda "lambda" would be a big loss.
>
>I think APL and J (and Perl) are plenty meritorious. I prefer
>Python--much.[/color]

I guess this reflects our different backgrounds. I've been an
electronic design engineer for many years. I never heard of lambda's
or lambda calculus until learning Python, and the name still doesn't
evoke much meaning for me. I've never used APL, J, or Perl. I wonder
how many technical professionals who are *not* programmers would know
what a lambda is? I wonder if Python is becoming more a language for
programmers, and less for "everyone".

My initial impression in learning Python was that 'lambda' was
something tricky. Then it became clear it was just a way to cram a
function into a small space like an argument list, except that there
were some strange restrictions on what could be put in the function.
Even now, it seems like 'lambda x,y:' is awkward if you are trying to
save space. It seems like we have paid a price for the dubious
assumption that most users will benefit from the magic meaning of
'lambda'.

Ruby uses a notation like |x,y|, which is compact, but I don't like
adding special punctuation for every little task. (The Perl problem.)
If the goal is to cram a function into a tight space, we could do it
compactly, and have the extra burden of the new syntax be shared by
many other features. They key characteristic is that they are small
departures from existing features and syntax, so the symantic burden
is not carried by the @ symbol. It's just a flag to modify something
already well understood. All @X says is "I'm like X, but different."
You still need to learn about X.

Again, my intention is not to change lambda functions, but to propose
a better way of introducing new syntax to a language that already has
all the basics worked out. I would rather have one special symbol
than a bunch of new keywords that mean nothing to me.

-- Dave

[Roger Binns]

Re: Extending Python Syntax with @

David MacQuigg wrote:[color=blue]
> @x @y @z -- short for instance variables in a method definition[/color]

The explicit self in front of accesses is what bugged me the most when
I first started with Python. (I liked the indentation. All my
C/C++/Java code is appropriately indented anyway, so the Python
rules didn't change my indentation style, and only removed now
superfluous punctuation).

But now when I go back to C++ code, the lack of self/this bugs
me. I often expect to not compile since I am not to sure where
it is resolving a name to. (Try writing MFC code on PocketPC
sometime - the layers of abstractions and inheritance get to be
fun).

Of course I could use this->x in the code, but that is non-standard
and not something I would want to inflict on someone who has to
maintain the code.

explicit is better than implicit!

Roger

[Pierre Rouleau]

Re: Extending Python Syntax with @

> Wouldn't it be nice, for example, if instead of special keywords like[color=blue]
> '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.
>[/color]

It would not be nice for me either. I *much* prefer the explicit way of
Python using explicit keywords than cryptic one. And besides, if typing
is an issue, then an editor can be programmed to extend the words as you
type or insert the keywords.

I really don't see what benefit it would do to Python which is easy to
learn as it is.

IMHO, I'd stay away from these 'nice' (?) tricks.

Sorry... I do like the zen of the current Python.

Pierre Rouleau

[Paul McGuire]

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:
>
> 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
>[/color]
Pet peeve: gratuitous inclusion of magic symbols into an otherwise
easy-to-understand language syntax.

-- Paul

[Pierre Rouleau]

Re: Extending Python Syntax with @

David MacQuigg wrote:[color=blue]
> On Thu, 11 Mar 2004 01:28:47 -0000, claird@lairds.c om (Cameron Laird)
> wrote:
>
>[/color]
<snip>

[color=blue]
>
> I guess this reflects our different backgrounds. I've been an
> electronic design engineer for many years. I never heard of lambda's
> or lambda calculus until learning Python, and the name still doesn't
> evoke much meaning for me. I've never used APL, J, or Perl. I wonder
> how many technical professionals who are *not* programmers would know
> what a lambda is? I wonder if Python is becoming more a language for
> programmers, and less for "everyone".
>[/color]

I was trained as an EE myself and started programming in assembler on
microprocessors , then in C , then in C++, reading, reading, reading,....

Just the mere fact that you are talking about lambda shows that you know
what it is, as I do now and as people learning Python will know when
they use it. They'll learn, that why they are technical professionals, no?

I have no problem with the way Python uses lambda and I like the fact
that it does not have cryptic keywords. I don't need to think about the
way things have to be written when I write Python programs, I think
about system design. I would think that a technical person that is not
a programmer would like that too.

Regards,

Pierre Rouleau

[Gustavo Niemeyer]

Re: Extending Python Syntax with @

[...][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]

That's great!! All of our problems are gone! I'm really excited
wondering about what we could do with $!! :-)

--
Gustavo Niemeyer

http://niemeyer.net

[Cameron Laird]

Re: Extending Python Syntax with @

In article <tPQ3c.37431$6y 1.1205127@news2 0.bellglobal.co m>,
Pierre Rouleau <prouleau@impat hnetworks.com> wrote:[color=blue]
>David MacQuigg wrote:[color=green]
>> On Thu, 11 Mar 2004 01:28:47 -0000, claird@lairds.c om (Cameron Laird)
>> wrote:
>>
>>[/color]
><snip>
>
>[color=green]
>>
>> I guess this reflects our different backgrounds. I've been an
>> electronic design engineer for many years. I never heard of lambda's
>> or lambda calculus until learning Python, and the name still doesn't
>> evoke much meaning for me. I've never used APL, J, or Perl. I wonder
>> how many technical professionals who are *not* programmers would know
>> what a lambda is? I wonder if Python is becoming more a language for[/color][/color]

[Roger Binns]

Re: Extending Python Syntax with @

DH wrote:[color=blue]
> - pychecker bundled with python, since it catches so many errors
> beginners and non-beginners make.[/color]

I would LOVE to see that, or even a special "checking" mode for the
interpretter even if it ran ten times slower. Pychecker has been
become increasingly useless to me. Part of that is due to bugs
(SF #844960, #708546), part due it being incomplete, and part
due to wxWidgets defining every function as (*args, **kwargs)
and indirecting through a layer of Swig. I get a huge list
of false positives.
[color=blue]
> - make colons optional after function and class declarations. People
> forget to type them anyway.[/color]

I don't agree with that. With the current scheme, it is trivial for
editors to auto-indent. They just have to do so after any line
ending in a colon, with no exceptions to that rule.

The case suggestion makes things appear better in the short term,
but do lots more harm in the long term, making maintenance and
performance significantly harder. If you would like to understand
some of the issues, I would recommend writing a translator between
the "relaxed" Python you describe and the standard Python.

Roger

[David MacQuigg]

Re: Extending Python Syntax with @

On Thu, 11 Mar 2004 05:13:25 -0000, claird@lairds.c om (Cameron Laird)
wrote:
[color=blue]
>Pierre Rouleau <prouleau@impat hnetworks.com> wrote: .[color=green]
>>I was trained as an EE myself and started programming in assembler on
>>microprocesso rs, then in C , then in C++, reading, reading, reading,....
>>Just the mere fact that you are talking about lambda shows that you know
>>what it is, as I do now and as people learning Python will know when
>>they use it. They'll learn, that why they are technical professionals, no?[/color][/color]

I agree. Lamdas are no big deal once you get past some obfuscation
and understand they perform a very simple function. Of course, both
of us could be missing something important. There is a lot of deep
theory behind the lambda calculus. While drawing a tentative
conclusion, we have to always keep an open mind to something new.

On Thu, 11 Mar 2004 05:13:25 -0000, claird@lairds.c om (Cameron Laird)
wrote:[color=blue]
> For more on what lambda means to me, and others, see
> <URL: http://www.csse.monash.edu.au/~lloyd.../00.Intro.html >
> or
> <URL: http://www.mactech.com/articles/mact...ambdaCalculus/ >
> or
> <URL: http://www.alcyone.com/software/church/ > or ...[/color]

This is an impressive body of knowledge, but unless I see how it is
going to help me write some code, I won't have time to study it. My
understanding of lambda functions is simply that they are a way to
squeeze functions into a tight space:

list_of_funcs = [(lambda x: 2**x), (lambda x: 3**x), (lambda x: 4**x)]

If you are not concerned about space, simply use normal defs:

def f2(x): return 2**x
def f3(x): return 3**x
def f4(x): return 4**x
list_of_funcs = [f2, f3, f4]

Is there any other reason in Python to use lambdas?

-- Dave

[Christopher Koppler]

Re: Extending Python Syntax with @

David MacQuigg wrote, amongst other things:[color=blue]
>
> If you believe as I do that Python is not yet the ultimate language,[/color]

If Python were the ultimate language, it would be a Lisp ;-)
[color=blue]
> 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[/color]

Perhaps, but as it stands, Python syntax is the best compromise in
readability I have seen in any programming language, and I for one am
very comfortable with less cryptic symbols - another case for explicit
is better than implicit.

--
Christopher

[Christopher Koppler]

Re: Extending Python Syntax with @

David MacQuigg wrote, amongst other things:
[color=blue]
> electronic design engineer for many years. I never heard of lambda's
> or lambda calculus until learning Python, and the name still doesn't
> evoke much meaning for me. I've never used APL, J, or Perl. I wonder
> how many technical professionals who are *not* programmers would know
> what a lambda is? I wonder if Python is becoming more a language for
> programmers, and less for "everyone".[/color]

To program, everyone eventually will have to be a programmer. Powerful
programming languages offer concepts that aren't always easy to grasp,
but in order to use them, some kind of understanding will have to
happen. Mostly it's easier if you learn them using Python, or after
your 3rd or 4th not too similar language...

--
Christopher

[David MacQuigg]

Re: Extending Python Syntax with @

On Wed, 10 Mar 2004 15:31:12 -0600, Jeff Epler <jepler@unpytho nic.net>
wrote:[color=blue]
>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[/color]

The details of these suggestions don't matter. The key concept, which
nobody seems to appreciate, is that we can *avoid* different and
confusing ways of extending an existing syntax. Perhaps a better
example will help.

Paul Prescod in a recent thread proposed deprecating the print
statement in favor of a "show()" function. The new function would
provide the same defaults as our current print statement, but would
also allow changing those defaults via keyword arguments. As you
might expect there were lots of objections to deprecating the existing
syntax. The arguments in favor were good, however, and I could see
this being done in some future version of Python.

There are lots of other examples where it would be nice to extend the
current syntax without changing the old. So how would we do that with
the print statement? We could do it by adding keywords, like was done
did with 'lambda' and 'yield'. That seems to be the implication of
the arguments in this thread against using a special symbol.

What I'm saying is, rather than add new keywords, it would be better
to have a standard symbol that has no specific meaning other than
"modify this statement". Beginners will learn the basic statements,
and ignore the modifications. Later they will see an @ symbol on some
otherwise familiar statement, and they will go to the docs for that
statement to figure out what it means. This is quite different than
Perl, where symbols themselves convey many complex meanings.

Maybe there will be no more changes in Python. I think that would be a
mistake as bad as adding more unnecessary keywords for seldom-used
statements.

-- Dave

[Peter Maas]

Re: Extending Python Syntax with @

David MacQuigg schrieb:[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,[/color]
[...][color=blue]
> @x,y:x*x+y*y -- anonymous function[/color]

Advantage of your proposal:

- easy to extend the language without breaking existing code.

Disadvantages of your proposal:

- The advantage is also a disadvantage: a lowered barrier for
new semantics could bloat the language definition. Python's
strength is that it has *few* concepts that are usable in *many*
places. This could be compromised by your proposal.

- Python is a readable language. lambda says "function literal",
yield says "generator" , @ just says "different" . Python would
be less readable if this notation would be adopted.

Therefore I vote against it.

Mit freundlichen Gruessen,

Peter Maas

--
-------------------------------------------------------------------
Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
Tel +49-241-93878-0 Fax +49-241-93878-20 eMail peter.maas@mplu sr.de
-------------------------------------------------------------------

[Cameron Laird]

Re: Extending Python Syntax with @

In article <2f9050pq22u53o 7aqo9i8ebqj11vo 9kilg@4ax.com>,
David MacQuigg <dmq@gain.com > wrote: