[Python-Dev] Re: Extended Function syntax

[Moore, Paul]

From: Samuele Pedroni [mailto:pedronis@bluewin.ch]
> Can you modify the locals of the surrounding (function) scope in the
> thunk, or its an anonymous closure with the current nested scopes
> rules (no rebinding)?

That's a very good point. I can see arguments both ways. And equally,
I can see arguments *against* either.

> I honestly find that trying to use a single extension to solve
> very different problems is a bad idea, e.g. currently class is
> semantically very different from control flow statements, the idea
> that a single extension can offer extensions for both up to general
> syntax extensibility seems far stretched.

Again, this is a good point.

There are basically two sorts of compound statement in Python, which I
could characterise as "defining" statements (class, def), and "control
flow" statements (if, while, try, ...)

The property() issue is a "defining" problem, whereas the =
acquire/release
issue is a "control flow" one. I think you're right that the two can't
be solved sensibly with a single mechanism.

> Personally I would find the addition of:
>=20
> 1) [] extendend function syntax to def (and possibly class and 2)
> 2) a statement that captures and extends what class does now ("my" =
proposal)
> 3) a 'with' statement for semantics like those of CL with- macros =
(Michael
> Hudson has some ideas on this)
>=20
> more pythonic.

Sounds reasonable. (1) is useful for staticmethod/classmethod. (2) is
useful for properties, and I assume (3) fits in with acquire/release =
(I'm
not completely familiar with what you mean by with-macros, so I'm =
guessing
a bit).

> General syntax extensibility is another level of identity crisis for =
the
> language <wink>.

Aw, can't we have a completely user-definable syntax, like Perl 6 is =
going to?
Please? Pleeeeease? All the other kids do it! I'm gonna look so =
uncool!!!

Sorry, I was getting frustrated by having nothing to disagree with in =
your
message. I'll go and lie down now :-)

Paul.