PEP 318

[Stephen Horne]

Re: PEP 318

On 21 Mar 2004 23:03:24 -0800, Paul Rubin
<http://phr.cx@NOSPAM.i nvalid> wrote:
[color=blue]
>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]

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


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Paul Rubin]

Re: PEP 318

Stephen Horne <steve@ninereed s.fsnet.co.uk> writes:[color=blue]
> Good point. Though to me, it isn't that it's a pain for the compiler
> to search for the 'yield' - I don't care about the compilers pain. The
> problem is that *I* have to look for the yield and might not notice it.[/color]

Well, yes. It wouldn't have occurred to me to care about the
compiler's pain ;-).

[Stephen Horne]

Re: PEP 318

On 22 Mar 2004 11:11:26 +0100, Jacek Generowicz
<jacek.generowi cz@cern.ch> wrote:
[color=blue]
>My only slight reservation is the increased "keyword overloading". For
>example ... "static" has something like 7 distinct meanings in C++ (at
>last count), and I find that this has a detremental effect on
>discussions with colleagues. I hope that Python will be able to avoid
>such problems.[/color]

Which is worse? Keyword overloading, or wierd pattern-of-symbols
overloading?

Personally, I'd hate to see nouns or verbs 'overloaded'. But why
shouldn't prepositions be used in a wide variety of contexts in
Python? They are in spoken languages, after all.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Stephen Horne]

Re: PEP 318

On 22 Mar 2004 03:02:49 -0800, Paul Rubin
<http://phr.cx@NOSPAM.i nvalid> wrote:
[color=blue]
>Stephen Horne <steve@ninereed s.fsnet.co.uk> writes:[color=green]
>> Good point. Though to me, it isn't that it's a pain for the compiler
>> to search for the 'yield' - I don't care about the compilers pain. The
>> problem is that *I* have to look for the yield and might not notice it.[/color]
>
>Well, yes. It wouldn't have occurred to me to care about the
>compiler's pain ;-).[/color]

We're such an unfeeling bunch, aren't we ;-)


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Peter Hansen]

Re: PEP 318

Stephen Horne wrote:
[color=blue]
> On Sun, 21 Mar 2004 17:53:11 +0100, Marco Bubke <marco@bubke.de >
> wrote:
>[color=green]
>>are better but still I used to see [] as list[/color]
>
> Surely it *is* a list - a list of modifier functions to apply to the
> original function.[/color]

If it's a list, then just as surely a tuple should be allowed in its
place, as in every (?) other such case in Python that I can think of.
Would that be part of the proposal? (I haven't read the full PEP, sorry.)

(I know, "foolish consistency is the hobgoblin blah blah..." :-)

-Peter

[David M. Wilson]

Re: PEP 318

Ville Vainio <ville@spammers .com> wrote...
[color=blue]
> The current foo=staticmetho d(foo) makes the Python 'staticmethod' seem
> like a hack. Many users of staticmethod won't even need to know that
> wrapping takes place.[/color]

I find myself in diametric opposition here. :)

Users (read: developers) /should/ know how staticmethod is working
under it's skin, that's (and hopefully no-one here disagrees) a bloody
good thing. The fact that defining a static method is a simple
assignment tells the developer a lot more about Python's internal
workings than extra syntax does. It's far more general, it's explicit,
and it's readable.

I can't see at all how it can be considered a hack.

If at some future date, staticmethod becomes intrinsicly linked to the
Python core in some magical way, then I can see an argument for extra
syntax, but as it stands, staticmethod is a wrapper, defining a
staticmethod is equivalent to "foo = staticmethod(fo o)", and "def foo
as staticmethod" is in my books rather ambiguous.

[color=blue]
> It certainly discourages people from using the
> feature in the first place.[/color]

Again, I can't see how.

[color=blue]
> And when did syntactic beauty stop mattering?[/color]

Don't get me wrong, I love lovely looking code, but I don't like code
that wears makeup, which is what this is. We can already do this via
another, simple, more descriptive means.


David.

[John Roth]

Re: PEP 318

"Jacek Generowicz" <jacek.generowi cz@cern.ch> wrote in message
news:tyfisgx6wf o.fsf@pcepsft00 1.cern.ch...[color=blue]
> Nicolas Fleury <nid_oizo@yahoo .com_removethe_ > writes:
>[color=green]
> > I've given some Python courses, and the first reaction when showing
> > a class with some methods is something like "so I guess when the
> > first parameter is not named 'self' it makes a class method?".[/color]
>
> Just as a point of information:
>
> I teach Python courses ... hands-on interactive style ... class size =
> 12 ... I've given 8 of these so far ... I have _never_ had this
> reaction. (80% of the students have previous C++ and/or Java
> experience, and usually someone asks "How do I do class/static
> methods?".)
>
> Maybe the reason nobody believes this is because, fairly early on in
> the treatment of classes, I point out that there is nothing special
> about the name "self", but I usually ask the students what they make
> of it, before offering any of my own comments.[/color]

Excellent class design! When I was doing classes, I found
one of the most important questions I could ask myself in
the after-the-class analysis was "what could I have said
earlier that would have dealt with this question / confusion?"
[color=blue][color=green]
> > If easing the creation of class methods is so important, I would
> > prefer a more radical approach with a end result that would be more
> > intuitive to newcomers:[/color]
>
> While I agree that there is a lot to be said for Python being guided
> by the principle of least surprise, I would argue against letting
> Python be shaped by the expectations of people whose expectations have
> been moulded by Java and C++, as those expectations are typically
> fundamentally flawed, and certainly inappropriate to Python. (For
> example, most (Java and C++ people, and hence generally most) people
> expect there to be access control, and hundreds of getters and setters
> all over the place. We do _not_ want this in Python. Etc., etc..
>[color=green]
> > - Give a warning for all methods with first parameter not named "self"
> > in next versions of Python.[/color]
>
> That would be acceptable ...[/color]

Only if the intention is to move to making it a built-in. Otherwise there
really are people who use some other name than self (usually to save
keystrokes.)
[color=blue][color=green]
> > - In a future major version of Python, 3 or 4, self becomes a keyword
> > and a first parameter named otherwise implies a class method (I
> > understand it could mean a lot of changes in code not using self).[/color]
>
> ... that would (IMHO) not.[/color]

John Roth

[Ronald Oussoren]

Re: PEP 318


On 22-mrt-04, at 13:51, David M. Wilson wrote:
[color=blue]
> Ville Vainio <ville@spammers .com> wrote...
>[color=green]
>> The current foo=staticmetho d(foo) makes the Python 'staticmethod' seem
>> like a hack. Many users of staticmethod won't even need to know that
>> wrapping takes place.[/color]
>
> I find myself in diametric opposition here. :)
>
> Users (read: developers) /should/ know how staticmethod is working
> under it's skin, that's (and hopefully no-one here disagrees) a bloody
> good thing. The fact that defining a static method is a simple
> assignment tells the developer a lot more about Python's internal
> workings than extra syntax does. It's far more general, it's explicit,
> and it's readable.[/color]

It's only readable in very small examples, if you have functions that
are longer than 10 lines it is no longer obvious that the assigment has
anything to do with the function above.

To play devil's advocate, 'class Foo: pass' is also syntactic sugar,
having explicit calls to type also tells a developer more about the
inner workings of Python but that is not necessarily a good idea.

Ronald
--
X|support bv http://www.xsupport.nl/
T: +31 610271479 F: +31 204416173

[Jacek Generowicz]

Re: PEP 318

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> "Jacek Generowicz" <jacek.generowi cz@cern.ch> wrote in message
> news:tyfisgx6wf o.fsf@pcepsft00 1.cern.ch...[color=green]
> > Nicolas Fleury <nid_oizo@yahoo .com_removethe_ > writes:
> >[/color][/color]
[color=blue][color=green]
> > I teach Python courses ...[/color][/color]

[...]
[color=blue][color=green]
> > fairly early on in the treatment of classes, I point out that
> > there is nothing special about the name "self", but I usually ask
> > the students what they make of it, before offering any of my own
> > comments.[/color]
>
> Excellent class design! When I was doing classes, I found
> one of the most important questions I could ask myself in
> the after-the-class analysis was "what could I have said
> earlier that would have dealt with this question / confusion?"[/color]

[...]
[color=blue][color=green][color=darkred]
> > > - Give a warning for all methods with first parameter not named "self"
> > > in next versions of Python.[/color]
> >
> > That would be acceptable ...[/color]
>
> Only if the intention is to move to making it a built-in. Otherwise there
> really are people who use some other name than self (usually to save
> keystrokes.)[/color]

.... just after I say that there is nothing special about "self" (in my
Python courses), I plead that, even though you are allowed to use any
name you like, you should use "self", and nothing but "self", on the
grounds that this will ensure that other Python programmers (which
includes yourself at a later date) will immediately understand what
you are doing; while you are likely to cause lots of confusion if you
use anything other than "self". At this point I usually re-iterate
that clearly showing your intentions, is very much good Python
style. (If I'm feeling in "that sort of mood" I might even point out
that if you want to save keystrokes, then you know where you can find
Perl.)

If a warning such as Nicolas proposes were introduced, I hope that it
would be suppressable. If so, I suspect that it would be a very useful
feature. I think that making the name "self" obligatory would run very
much against some of the basic Python philosophies.

[Skip Montanaro]

Re: PEP 318

[color=blue][color=green]
>> - Give a warning for all methods with first parameter not named "self"
>> in next versions of Python.[/color][/color]

Jacek> That would be acceptable ...

I suggest you see if PyChecker already does this.
[color=blue][color=green]
>> - In a future major version of Python, 3 or 4, self becomes a keyword
>> and a first parameter named otherwise implies a class method (I
>> understand it could mean a lot of changes in code not using self).[/color][/color]

Jacek> ... that would (IMHO) not.

(I'm not picking on Jacek here. I just chose to reply to his post.)

Everybody seems to be fixated on how best to spell "make this function a
class or static method". If that was all we were interested in, something
more syntacically restrictive would be fine. That's not all PEP 318 allows
though. It proposes syntax (and eventually semantics) for a general
function decorator capability.

I almost wish Python didn't already have staticmethod() and classmethod()
builtins so people wouldn't get so hung up on the most economical way to
spell them.

I suggest people google for

site:mail.pytho n.org python-dev PEP 318

and look at some of the other ideas people have had or examples proposed of
how to (ab)use this feature. It's applicability is much broader than just
declaring methods to be "static" or "class".

Skip

[David MacQuigg]

Re: explicit variable scoping

On Mon, 22 Mar 2004 03:19:46 -0800 (PST), Eyal Lotem
<gnupeaker@yaho o.com> wrote:

[snip motivation for changing the scope rules]
[color=blue]
>A) Only get rid of the assignment-makes-local
>heuristic, by changing the meaning of the "global"
>keyword:
>
>def f():
> global.a = 1 # Assigns to the module.a
> a = 2 # Assigns to a local variable
>
>This allows accessing globals, and IMO serves for
>better explicitness about variables which is very
>desirable and consistent with instance variable
>access.[/color]

I'm not seeing much advantage over:
global a; a = 1
When you say "accessing" globals, we need to distinguish between
"referencin g" and "setting". Referencing globals is already
automatic. Setting globals needs special syntax. For the few times I
need to set global variables, I'm not feeling much need for
streamlining the existing syntax. Most of my use of global variables
is global within a named module. In this case, I refer explicitly to
the module name. e.g. M1.a = 1 So the improvement above would apply
only to the case where you need to set global variables in the main
module.

[snip how to migrate old code]
[color=blue]
>B) Create a hierarchy of "locals" for nested scopes,
>which are accessible via an overloaded or new keyword
>thus:
>
>I)
> b = 1
> def f():
> a = 2
> def g():
> global.a = 3
> global.global.b = 4[/color]

Ugh!!
[color=blue]
>II)
> b = 1
> def f():
> a = 2
> def g():
> parent.a = 3
> global.b = 4
>[/color]

What about aunts and uncles? :>)

I'm not feeling much need to set variables other than local or global,
but I can see where this might be useful to someone. The tradeoff is
convenience for a few vs a mess from lots of users who will abuse the
flexibility. (The same kind of tradeoff as with the GOTO statement.)
I would not give up *essential* flexibility for this reason, but we
are talking here of just a convenience.

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.

If we are going to make one more change in the scope rules, I would
like to see a grand simplification -- the current rules are good, just
extend them to *any* nested scopes. If I set up a hierarchy of 7
nested classes, I should be able to reference variables at a higher
level without fully qualified names. Again, this is just a
convenience. Mainly, it would make teaching Python simpler.

-- Dave

[Stephen Horne]

Re: PEP 318

On Mon, 22 Mar 2004 07:33:08 -0500, Peter Hansen <peter@engcorp. com>
wrote:
[color=blue][color=green]
>> Surely it *is* a list - a list of modifier functions to apply to the
>> original function.[/color]
>
>If it's a list, then just as surely a tuple should be allowed in its
>place, as in every (?) other such case in Python that I can think of.
>Would that be part of the proposal? (I haven't read the full PEP, sorry.)[/color]

I don't think tuples were mentioned in the PEP, though I only skimmed
through it quickly. But, well...
[color=blue]
>(I know, "foolish consistency is the hobgoblin blah blah..." :-)[/color]

Yes, I have to agree.

The list-like syntax isn't too confusing in this context. A
tuple-based context would be. With parens, it would look a lot like
having too lists of arguments. Without, well, IMO it'd be even worse.

Which still shouldn't be read as me expressing a preference - the 'as'
syntax is roughly equally good IMO.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[AdSR]

Re: PEP 318

Nicolas Fleury <nid_oizo@yahoo .com_removethe_ > wrote...[color=blue]
> Marco Bubke wrote:[color=green]
> > def foo(x, y) as staticmethode: pass
> >
> > Define foo with arguments x and y as staticmethode.
> >
> > Is Python now C++? Mabe I miss something why this syntax is wrong.[/color]
>
> Personnally, I prefer the "as" syntax to the other proposed (and by a
> large margin). However, I feel that it is making the language more
> complex and I'm far from sure it's worth the effort. I've given some
> [snip
> If easing the creation of class methods is so important, I would prefer[/color]

Just done a quick check:

$ find /lib/python2.3/ -name "*.py" -exec egrep
"(class|static) method\W" {} ';' | wc --lines
49

Not all of them are calls, and all this in 773 *.py files. I guess
this says something about importance...

Cheers,

AdSR

[Stephen Horne]

Re: PEP 318

On 22 Mar 2004 11:25:01 -0800, artur_spruce@ya hoo.com (AdSR) wrote:
[color=blue]
>Just done a quick check:
>
>$ find /lib/python2.3/ -name "*.py" -exec egrep
>"(class|static )method\W" {} ';' | wc --lines
> 49
>
>Not all of them are calls, and all this in 773 *.py files. I guess
>this says something about importance...[/color]

Actually, given that support for staticmethod and classmethod is very
recent, it is rather surprising that it appears in that many places.

I wouldn't expect existing libraries to be updated just to make use of
'staticmethod' or whatever. New features mainly get used in new code,
and even then there is the drag factor as people take time to adopt
them.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Skip Montanaro]

Re: PEP 318

[color=blue][color=green]
>> If easing the creation of class methods is so important, I would prefer[/color][/color]

AdSR> Just done a quick check:

AdSR> $ find /lib/python2.3/ -name "*.py" -exec egrep
AdSR> "(class|static) method\W" {} ';' | wc --lines
AdSR> 49

AdSR> Not all of them are calls, and all this in 773 *.py files. I guess
AdSR> this says something about importance...

Not necessarily. Certainly there's the fact that class and static methods
will be less frequently used than normal methods. However, there are also
another mitigating factors as I see it, neither classmethod() nor
staticmethod() have been around all that long (2.2 timeframe).

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.

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"):

3. From Shane Hathaway:

Ooh, what about this:

def singleton(klass ):
return klass()

class MyThing [singleton]:
...

That would be splendid IMHO.

There are plenty of other examples. Browse the archives.

think-outside-the-bun-(tm)-ly, y'rs,

Skip