PEP 318

[Sean Ross]

Re: explicit variable scoping


"David MacQuigg" <dmq@gain.com > wrote in message
news:blbu505vrj 35i52ari8a0uivj a0pp7a9qu@4ax.c om...
[color=blue]
> If we want to set variables in intermediate scopes, I would prefer a
> syntax like:
>
> b = 1
> def f():
> a = 2
> def g():
> global.f.a = 3
> global.b = 4
>
> Of course, this means we also have to allow functions to have
> attributes.
>[/color]

Hi.
I know what you meant but, technically, functions can and do have
attributes, just not the kind you've mentioned (where the locals become
attributes of their function):
[color=blue][color=green][color=darkred]
>>> def f(): pass[/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> f.a = "A"
>>> f.a[/color][/color][/color]
'A'[color=blue][color=green][color=darkred]
>>>[/color][/color][/color]

Just so things are clear for those following along ...

Sean

[JCM]

Re: explicit variable scoping

Sean Ross <sross@connectm ail.carleton.ca > wrote:
[color=blue]
> "David MacQuigg" <dmq@gain.com > wrote in message
> news:blbu505vrj 35i52ari8a0uivj a0pp7a9qu@4ax.c om...[/color]
[color=blue][color=green]
>> If we want to set variables in intermediate scopes, I would prefer a
>> syntax like:
>>
>> b = 1
>> def f():
>> a = 2
>> def g():
>> global.f.a = 3[/color][/color]

Locals inside functions are unique to a function invocation (not the
function object). More than one may be active at any given time,
either through recursion or by creating closures.

[Hung Jung Lu]

Re: PEP 318

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote in message news:<7x1xnlqs7 7.fsf@ruckus.br ouhaha.com>...[color=blue]
>
> "def foo() as staticmethod" certainly looks best to me aesthetically.
> The syntax can be extended, i.e. "def foo() as generator" looks to me
> to be a lot more explicit than "def foo()" followed by having the
> compiler search the function body for a yield statement in order
> to decide if it's a generator.[/color]

True, but if a method were both generator and static, then we would
have:

def foo() as generator staticmethod:
...

Add another keyword for thread behavior:

def foo() as synchronized generator staticmethod:
....

And another keyword for privacy:

def foo() as private synchronized generator staticmethod:
....

And your language become pretty close to... Java! :)

Or, following C#, you can also specify some attributes:

[attr1=2,
attr2=3
attr3="Hello"]
def foo():
....

-----------------------------------------

Of course there must be some reasonable compromise. I am coming from
the other end of the spectrum: meta-programming. In modern software
development, especially for large and complex systems,
meta-programming becomes more and more essential. If your language is
to grow with time, more and more keywords does not seem to be the way
to go. In some message-based languages like Io, even the if-statements
and the for-loops are not keywords: they are methods.

In the old days, when OOP just appeared, you used to see constructors
with long list of parameters. Nowadays it is much more common to see
things like SetAttribute() to change the behavior of an object. That
is, things are becoming more dynamic.

Metaprogramming is an unavoidable trend, in my opinion. In Java/C# you
use code generators. In C++ you use macros and templates. In Python
the staticmethod() can be interpreted also as a small metaprogramming
statement, not as a declaration of method type.

I am not against the "def foo() as staticmethod" syntax. I am just
bringing up a perspective on possible future problems. It is a little
bit like database table design: you could keep adding new columns to
your table for every new attribute, or you could normalize the table
by allowing a column to specify the attribute name/index, and a
different column for the value. In the first approach, you need to
modify the table definition and your programs when you want to add one
more feature. In the second approach, it becomes easy to add more and
more features, without redefining the table or modifying your program.

regards,

Hung Jung

[AdSR]

Re: PEP 318

Skip Montanaro <skip@pobox.com > wrote...[color=blue]
> I will reiterate my comment from before: PEP 318 is about more than just
> static and class methods. Here are a few examples from the python-dev
> discussion.[/color]

You (and Stephen Horne) got your point.

Passing that grep over 3rd party packages might be interesting too...

On other note, regarding the initial subject of this thread: Is there
going to be any voting poll about the syntax in foreseeable future? My
preferred style would be the "standard" one proposed in the PEP.

Cheers,

AdSR

[Skip Montanaro]

Re: PEP 318


Hung Jung> Paul Rubin <http://phr.cx@NOSPAM.i nvalid> wrote in message news:<7x1xnlqs7 7.fsf@ruckus.br ouhaha.com>...
[color=blue][color=green]
>> "def foo() as staticmethod" certainly looks best to me aesthetically.
>> The syntax can be extended, i.e. "def foo() as generator" looks to me
>> to be a lot more explicit than "def foo()" followed by having the
>> compiler search the function body for a yield statement in order to
>> decide if it's a generator.[/color][/color]

Hung Jung> True, but if a method were both generator and static, then we
Hung Jung> would have:

Hung Jung> def foo() as generator staticmethod:
Hung Jung> ...

Hung Jung> Add another keyword for thread behavior:

Gotta stop thinking of decorators as keywords. That would be a complete
non-starter. It would be both inflexible (need to modify the parser every
time a new one was added) and constraining (require everyone to use the same
small set of "approved" decorators). Decorators are variables referencing
objects which are located at function/method/class definition time.

Hung Jung> def foo() as synchronized generator staticmethod:
Hung Jung> ....

Hung Jung> And another keyword for privacy:

Hung Jung> def foo() as private synchronized generator staticmethod:
Hung Jung> ....

Hung Jung> And your language become pretty close to... Java! :)

And gets fairly unreadable because of the lack of punctuation. I think
square brackets and commas improve readability a bit for those nearly
unreadable long sequences of decorators:

def foo() [private, synchronized, generator, staticmethod]:

Skip

[Skip Montanaro]

Re: PEP 318


AdSR> On other note, regarding the initial subject of this thread: Is
AdSR> there going to be any voting poll about the syntax in foreseeable
AdSR> future? My preferred style would be the "standard" one proposed in
AdSR> the PEP.

It will probably be a BDFL pronouncement. After all, that's why he's the
BDFL. I have a modified version of PEP 318 in my mailbox I need to read,
edit and check in. I'll try to get to it later today.

Skip

[Jess Austin]

Re: PEP 318

I'll preface by saying that I haven't fully grokked all the possible
uses of decorators. Also, I can sympathize with the complaints about
seeing a function definition and then seeing a classmethod call on
that function 50 lines later (actually that seems like a case for
refactoring but never mind). b-)

The brackets and the 'as' both seem awkward to me. Also, introducing
a requirement that definition and decoration take place on the same
line seems to limit the the possibilities of decoration. Perhaps my
class wants to offer several faces of the same method:

class foo(object):
def __foo_method(.. .)
....
bar = decorator1(__fo o_method)
baz = decorator2(__fo o_method, arg1, arg2)

I can't imagine the exact use for this, but I can imagine that there
could be a use. If the syntax remains as it is, that is. This PEP
seems to shoot itself in the foot in this respect.

later,
Jess

[DH]

The problem with &quot;as&quo t; [was &quot;Re: PEP 318&quot;]

Paul Rubin wrote:[color=blue]
>"def foo() as staticmethod" certainly looks best to me aesthetically.[/color]

It does look better with simple examples. But think of other potential
uses for an "as" keyword, and it might have problems.
Visual Basic uses "as" in function declarations to declare types, not
for function decorators.
VB example:
Function foo (x as Integer, y as Float) as Integer

Possible future Python example that uses "as" differently:

def foo(x as int, y as float) as int:
"this function returns an integer, and takes an int & float params"

If we use the list syntax for decorators instead of "as", we might be
able to do something like:

def foo(x as int, y as float) [synchronized, classmethod] as int:
...

See this thread:

http://mail.python.org/pipermail/python-dev/2004-February/thread.html#42780

[Paul Rubin]

Re: The problem with &quot;as&quo t; [was &quot;Re: PEP 318&quot;]

DH <no@sp.am> writes:[color=blue]
> Possible future Python example that uses "as" differently:
>
> def foo(x as int, y as float) as int:
> "this function returns an integer, and takes an int & float params"[/color]

I think I'd rather use colons for that, like Pascal does, e.g.

def foo:int (x: int, y: float)

hmm, the foo:int doesn't look too good.
[color=blue]
> If we use the list syntax for decorators instead of "as", we might be
> able to do something like:
>
> def foo(x as int, y as float) [synchronized, classmethod] as int:[/color]

That's sort of nice.

[Isaac To]

Re: PEP 318

>>>>> "Stephen" == Stephen Horne <steve@ninereed s.fsnet.co.uk> writes:
[color=blue][color=green]
>> The syntax can be extended, i.e. "def foo() as generator" looks to me
>> to be a lot more explicit than "def foo()" followed by having the
>> compiler search the function body for a yield statement in order to
>> decide if it's a generator.[/color][/color]

Stephen> Good point. Though to me, it isn't that it's a pain for the
Stephen> compiler to search for the 'yield' - I don't care about the
Stephen> compilers pain. The problem is that *I* have to look for the
Stephen> yield and might not notice it.

I disagree. It's not just the compile which has to search for that yield
keyword, we human being reading other's uncommented code (or mis-commented
code) also has to do the same. It would do much good if the completely
different call convention of generator is made much more explicit in the
definition of the function.

Regards,
Isaac.

[Skip Montanaro]

Re: The problem with &quot;as&quo t; [was &quot;Re: PEP 318&quot;]


DH> Possible future Python example that uses "as" differently:

DH> def foo(x as int, y as float) as int:
DH> "this function returns an integer, and takes an int & float params"

With no extension beyond the current PEP 318 proposal, you might postulate
returns() and accepts() decorators:

def foo(x, y) [accepts(int, float), returns(int)]:
...

which extend foo() with code to enforce input and output types. Further,
function attributes could be added which could be used by tools like
pychecker for intermodule type checking.

Skip

[Ville Vainio]

Voting (was Re: PEP 318

>>>>> "Skip" == Skip Montanaro <skip@pobox.com > writes:

Skip> It will probably be a BDFL pronouncement. After all, that's
Skip> why he's the

Of course it will - still, that didn't stop us from voting before :-).

There should be a kind of "standard voting system" for PEPs, w/o
administration overhead of occasional seperate vote. It would be a
data point, if nothing else. The result of the vote could be stored
together w/ the accepted/approved pep.

Actually, any third party could whip out the voting system, but the
illusion of authority would be more convincing if PSF was involved.
It would be fun, esp. if it was easier than the conditional expression
vote of yore :-).

FWIW, I prefer

def f(x,y) [wrapper,wrapper ...]:
pass

or

def f(x,y) as iterable:
pass

and would oppose

def f [wrapper, wrapper...] (x,y):
pass

Like others, I want to see the param list right next to the function
name.

--
Ville Vainio http://tinyurl.com/2prnb

[David MacQuigg]

Re: explicit variable scoping

On Mon, 22 Mar 2004 20:48:18 +0000 (UTC), JCM
<joshway_withou t_spam@myway.co m> wrote:
[color=blue]
>Sean Ross <sross@connectm ail.carleton.ca > wrote:
>[color=green]
>> "David MacQuigg" <dmq@gain.com > wrote in message
>> news:blbu505vrj 35i52ari8a0uivj a0pp7a9qu@4ax.c om...[/color]
>[color=green][color=darkred]
>>> If we want to set variables in intermediate scopes, I would prefer a
>>> syntax like:
>>>
>>> b = 1
>>> def f():
>>> a = 2
>>> def g():
>>> global.f.a = 3[/color][/color]
>
>Locals inside functions are unique to a function invocation (not the
>function object). More than one may be active at any given time,
>either through recursion or by creating closures.[/color]

Oops. This could get messy. Let's not worry about *how* to do
intermediate scopes until we see a good use case for *why* we want to
do it.

-- Dave

[Michele Simionato]

Re: PEP 318

Skip Montanaro <skip@pobox.com > wrote in message news:<mailman.2 47.1079985383.7 42.python-list@python.org >...[color=blue]
> I will reiterate my comment from before: PEP 318 is about more than just
> static and class methods. Here are a few examples from the python-dev
> discussion.
>
> 1. From Fred Drake:
>
> As an (admittedly trivial) example, I'd be quite happy for:
>
> class Color [valuemap]:
> red = rgb(255, 0, 0)
> blue = rgb(0, 255, 0)
> green = rgb(0, 0, 255)
>
> to cause the name Color to be bound to a non-callable object. Why must
> the decorators be required to return callables? It will not make sense
> in all circumstances when a decorator is being used.[/color]

Ok.
[color=blue]
> 2. From Anders Munch:
>
> Given that the decorator expression can be an arbitrary Python
> expression, it _will_ be used as such. For example:
>
> def foo(arg1, arg2) as release(
> version="1.0",
> author="me",
> status="Well I wrote it so it works, m'kay?",
> warning="You might want to use the Foo class instead"):[/color]

Nice,
[color=blue]
> 3. From Shane Hathaway:
>
> Ooh, what about this:
>
> def singleton(klass ):
> return klass()
>
> class MyThing [singleton]:
> ...
>
> That would be splendid IMHO.[/color]

This one I don't like (not the syntax, the implementation) .
I want my singleton to be a class I can derive from.
This can be done by using a metaclass as decorator
(I posted an example months ago).
[color=blue]
> There are plenty of other examples. Browse the archives.
>
> think-outside-the-bun-(tm)-ly, y'rs,
>
> Skip[/color]
And don't forget Ville Vanio's idea of using the new syntax to
implement multimethods:

def __mul__(self,ot her) as multimethod(Mat rix,Matrix):
...

def __mul__(self,ot her) as multimethod(Mat rix,Vector):
...

def __mul__(self,ot her) as multimethod(Mat rix,Scalar):
...

def __mul__(self,ot her) as multimethod(Vec tor,Vector):
...

def __mul__(self,ot her) as multimethod(Vec tor,Scalar):
...

etc.

Way cool, actually :)


Michele Simionato

[Ronald Oussoren]

Re: PEP 318


On 23-mrt-04, at 1:15, Jess Austin wrote:
[color=blue]
> I'll preface by saying that I haven't fully grokked all the possible
> uses of decorators. Also, I can sympathize with the complaints about
> seeing a function definition and then seeing a classmethod call on
> that function 50 lines later (actually that seems like a case for
> refactoring but never mind). b-)
>
> The brackets and the 'as' both seem awkward to me. Also, introducing
> a requirement that definition and decoration take place on the same
> line seems to limit the the possibilities of decoration. Perhaps my
> class wants to offer several faces of the same method:
>
> class foo(object):
> def __foo_method(.. .)
> ....
> bar = decorator1(__fo o_method)
> baz = decorator2(__fo o_method, arg1, arg2)
>
> I can't imagine the exact use for this, but I can imagine that there
> could be a use. If the syntax remains as it is, that is. This PEP
> seems to shoot itself in the foot in this respect.[/color]

The syntax in PEP318 is syntactic sugar for the most common use of
function decorators, the current syntax would still be supported.

Ronald