RetroSearch Browse

Thu Feb 26 14:27:12 EST 2004 · https://mail.python.org/pipermail/python-dev/2004-February/042783.html

Christian Tismer <tismer at stackless.com> writes:

> Thomas Heller wrote:
>
>> The above code looks like as someone forgot to actually initialize the
>> class variable (probably not too likely with the name 'classmethod', but
>> with other names):
>> class klass:
>>    classmethod = 42
>>    def foo():...
>
> Yes I know. I just wanted to encourage people to think
> of simpler alternatives but to spoil the language
> for tiny improvements.
> I didn't just want to say "this is ugly", but to think of
> ways to express "the following is meant to be a... method".
>
> Onw thing I could live with if I must is "class method",
> since it is similar to other languages.
>
> reminds-me-of-ternary-operators -- chris

For me, the advantage of the current

   def foo(cls): ...
   foo = classmethod(foo)

is that it *exactly* describes what's going on.
The difficulty, I would guess, to people coming from other
languages, is that they are more used to (how can I explain it) a mental
model where a compiler parses some syntax and generates code from that.
In python, it *is* simply executable code, and it is executed.

I'm +1 on this proposed syntax

   def foo(cls) [classmethod]:

since is it easy to parse to my own eye.  And I think it is much easier
to learn than list comprehensions have been when they were introduced.

I'm +2 on the cool stuff that would be possible with it.

I'm +0 (maybe even -0) because it moves Python further away from
'executable pseudocode'.

Thomas

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-February/042783.html below:

[Python-Dev] Re: new syntax for wrapping (PEP 318)