PEP 318

[Marco Bubke]

Hi

I have read some mail on the dev mailing list about PEP 318 and find the new
Syntax really ugly.

def foo[staticmethode](x, y): pass

I call this foo(1, 2), this isn't really intuitive to me!

Also I don't like the brackets.

def foo(x, y)[staticmethode]: pass

are better but still I used to see [] as list or access operator and the
don't? The original Syntax looks much cleaner to me.

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.

regards

Marco

[Skip Montanaro]

Re: PEP 318



Marco> def foo(x, y)[staticmethode]: pass
... vs ...
Marco> def foo(x, y) as staticmethode: pass

Marco> Define foo with arguments x and y as staticmethode.

Marco> Is Python now C++? Mabe I miss something why this syntax is wrong.

I believe the "as wrap1, wrap2, ..." form is one of the alternatives under
consideration, though current sentiment seems to be in favor of the
list-like syntax.

Python has a long history of borrowing good ideas from other languages. I'm
not aware that any of this is being borrowed from C++, no matter that it has
some syntactic similarities to stuff C++ does. Note in particular that the
construct is much more general than applying the currently available
staticmethod and classmethod builtins. The end result need not even be a
function or class (there has been some discussion about applying this
construct to classes, but it's not as obviously valuable). See recent
discussion in the python-dev archives for some other ideas.

Skip

[John Roth]

Re: PEP 318

"Marco Bubke" <marco@bubke.de > wrote in message
news:c3kh9o$th$ 1@graf.cs.uni-magdeburg.de...[color=blue]
> Hi
>
> I have read some mail on the dev mailing list about PEP 318 and find the[/color]
new[color=blue]
> Syntax really ugly.[/color]

There doesn't seem to be a really beautiful
syntax for this. That's the reason it wasn't
in 2.2.

My personal opinion is that I'll take whatever
the core developers decide is best.

John Roth

[Nicolas Fleury]

Re: PEP 318

Marco Bubke wrote:[color=blue]
> 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
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?". So I have to explain it's not
the case, etc.

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:
- Give a warning for all methods with first parameter not named "self"
in next versions of Python.
- 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).

Regards,

Nicolas

[John Roth]

Re: PEP 318

"Nicolas Fleury" <nid_oizo@yahoo .com_removethe_ > wrote in message
news:Xjm7c.3373 $p8.414038@webe r.videotron.net ...[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
> 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?". So I have to explain it's not
> the case, etc.
>
> 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:
> - Give a warning for all methods with first parameter not named "self"
> in next versions of Python.
> - 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).
>
> Regards,
>
> Nicolas[/color]

I personally think that self not only should be a keyword,
it should not be among the parameters at all. However, I
seem to be in a distinct minority about that.

However, I think you've got class methods mixed up with
static methods. Class methods require the first parameter
to be the class (sometimes spelled klas for some reason),
while static methods are the ones that don't have either an
instance or a class as the first parameter.

John Roth

[David M. Wilson]

Re: PEP 318

Nicolas Fleury <nid_oizo@yahoo .com_removethe_ > wrote...
[color=blue]
> 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.[/color]

I'd +1 for the 'as' syntax too, it's more descriptive and feels
'pythonic' (much as the term disgusts me) in its verbosity.

Personally, I think for the meager benefit this new syntax brings, it
appears to be a rather large and incompatible waste of time. With the
exception of syntactic beauty, does this really add anything to
Python? It gives programmers two ways of doing something very basic
indeed. Both proposed syntaxes will inevitably break existing source
analysers, etc.

Even preferring the 'as' syntax, 'def foo(x) as bar' doesn't really
make that much sense to me. staticmethods are wrapper objects and much
better expressed as 'foo = staticmethod(fo o)', where you at least know
some kind of layering or transformation is being applied to foo (if
there isn't, why is this person using the same variable name? etc).
With 'as', it suggests some kind of aliasing is taking place, or some
kind of different type of object creation, which isn't the case.

It's also very specific syntax, I'd have hoped big language changes
like this would be reserved for larger, more fundamental, and general
changes that everyone can find useful. Did I say I didn't think it's
worth it already? :)


David.

[Nicolas Fleury]

Re: PEP 318

John Roth wrote:[color=blue]
> I personally think that self not only should be a keyword,
> it should not be among the parameters at all. However, I
> seem to be in a distinct minority about that.[/color]

But how could that be changed/introduced?
[color=blue]
> However, I think you've got class methods mixed up with
> static methods. Class methods require the first parameter
> to be the class (sometimes spelled klas for some reason),
> while static methods are the ones that don't have either an
> instance or a class as the first parameter.[/color]

Ok, I wrote static method everywhere in my message and changed for class
method after reading the PEP... so my first idea was right;)

Regards,

Nicolas

[Ville Vainio]

Re: PEP 318

>>>>> "David" == David M Wilson <dw-google.com@bota nicus.net> writes:

David> Personally, I think for the meager benefit this new syntax
David> brings, it appears to be a rather large and incompatible
David> waste of time. With the exception of syntactic beauty, does
David> this really add anything to

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. It certainly discourages people from using the
feature in the first place.

And when did syntactic beauty stop mattering?

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

[Paul Rubin]

Re: PEP 318

Ville Vainio <ville@spammers .com> writes:[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. It certainly discourages people from using the
> feature in the first place.
>
> And when did syntactic beauty stop mattering?[/color]

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

[Jacek Generowicz]

Re: PEP 318

"John Roth" <newsgroups@jhr othjr.com> writes:
[color=blue]
> I personally think that self not only should be a keyword,
> it should not be among the parameters at all. However, I
> seem to be in a distinct minority about that.[/color]

The existence of C++ or Java coding guidelines which advocate the
universal use of this->member or the use of m_member for all member
data and function names, is (to me) evidence of the necessity of self.

Also, ask an average[*] C++ programmer whether the following functions
have the same type:

void A::foo(void);
void B::foo(void);

(where A and B are both classes).

In my experience[+], they will, typically, be adamant that the types
are identical. If they have been exposed to Python, then you have more
than a fair chance that they will understand that the types are, in
fact, different.

Python's explicit passing of self makes people understand what is
going on, much better ... and I think that is a very valuable thing.

[*] And we all know just how dangerous "average" C++ programmers are.

[+] You probably don't want to know why I have had ample opportunity
to ask this question, in real life.

[Jacek Generowicz]

Re: PEP 318

Nicolas Fleury <nid_oizo@yahoo .com_removethe_ > writes:
[color=blue]
> 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=blue]
> 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=blue]
> - Give a warning for all methods with first parameter not named "self"
> in next versions of Python.[/color]

That would be acceptable ...
[color=blue]
> - 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.

[Jacek Generowicz]

Re: PEP 318

Paul Rubin <http://phr.cx@NOSPAM.i nvalid> writes:
[color=blue]
> Ville Vainio <ville@spammers .com> writes:[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. It certainly discourages people from using the
> > feature in the first place.
> >
> > And when did syntactic beauty stop mattering?[/color][/color]

Most importantly, the current style separates the unambiguous
information that the method is a static or class method from the "def"
which starts the method's definition, by far too much.
[color=blue]
> "def foo() as staticmethod" certainly looks best to me aesthetically.[/color]

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.

[Stephen Horne]

Re: PEP 318

On Sun, 21 Mar 2004 17:53:11 +0100, Marco Bubke <marco@bubke.de >
wrote:
[color=blue]
>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.

To me, the 'as' syntax is misleading. It implies that the syntax is
asserting a type, style or similar attribute of the function. That may
be the expected normal use, with 'staticmethod' etc, but my
understanding is that it is meant to be more general than that. You
can apply any translation or any sequence of translations that you
choose.

Not that I care either way, just being pointlessly pedantic really.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk

[Paul Rubin]

Re: PEP 318

Jacek Generowicz <jacek.generowi cz@cern.ch> writes:[color=blue][color=green][color=darkred]
> > > And when did syntactic beauty stop mattering?[/color][/color]
>
> Most importantly, the current style separates the unambiguous
> information that the method is a static or class method from the "def"
> which starts the method's definition, by far too much.[/color]

Oh, it's not that big a deal. Anyway, look at the situation with
generator functions. ;-)

[Stephen Horne]

Re: PEP 318

On Sun, 21 Mar 2004 14:45:39 -0500, Nicolas Fleury
<nid_oizo@yahoo .com_removethe_ > wrote:
[color=blue]
>- Give a warning for all methods with first parameter not named "self"
>in next versions of Python.
>- 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]

The main problem I have with that is that some people find typing
'self.' over and over in member functions pretty annoying. I have
quite recently voiced the opinion that because 'self' is just a
convention, that it can reasonably be abbreviated to become something
like 's' or 'm', so that 'm.' in Python code plays much the same role
as 'm_' in common use as a prefix for member variable names in C++.

As I said then, I'm not that bothered about 'self.' - keeping to the
well-known convention and the principle of least surprise is to me
well worth pressing a few more keys. But I may have to deal with a few
grumpy people if that suggestion turns out bad :-(

If a more radical change is needed, then I would say we need an
alternative to the 'def' keyword. It could be justified as 'def just
defines normal functions - we can define them as class members and we
have a convenient system for using them as if they were methods but
that doesn't mean they really are methods'. 'True' methods would then
be defined using a 'method' keyword, and within a method 'self' might
be a pseudo-keyword.

In Python 3000, 'def' for member functions might then be deprecated.

Very unlikely, though.


--
Steve Horne

steve at ninereeds dot fsnet dot co dot uk