C
Colin J. Williams
Daniel said:
The quoted blogspot is not available.
I like the idea but I don't see how
explicit and implicit can co-exist.
Version 3.0 is the time to introduce the
enhancement.
Colin W.
The quoted blogspot is not available.
I like the idea but I don't see how
explicit and implicit can co-exist.
Version 3.0 is the time to introduce the
enhancement.
Colin W.
J
John Roth
Sigh. If you make --both-- self and cls keywords, then 90% of the
problems that Guido mentions in the blogspot post just vanish because
whether it's an instance method, a class method or a static method can
be inferred from the method body.
In particular, the decorator problem goes away (the decorators are
irrelevant, and can be ignored) and so does the problem with injecting
a method into an object.
It is, of course, harder to implement, and it would not be backwards
compatible because all the internal wrappers vanish as well. That
makes problems for anyone who is looking through __dict__ to find
particular kinds of method.
John Roth
B
Bruno Desthuilliers
Daniel Fetchinson a écrit :
-1
As far as I'm concerned, it doesn't add anything to the language, nor
doesn't save any typing, so I just don't see the point. And having it
co-existing with the normal syntax will only add more confusion.
NB : FWIW, I would eventually have voted -0 if it had been proposed for
Python 3, and as a _replacement_ (not _alternative_) to the current
syntax. But Python 3 is now released, so...
-1
As far as I'm concerned, it doesn't add anything to the language, nor
doesn't save any typing, so I just don't see the point. And having it
co-existing with the normal syntax will only add more confusion.
NB : FWIW, I would eventually have voted -0 if it had been proposed for
Python 3, and as a _replacement_ (not _alternative_) to the current
syntax. But Python 3 is now released, so...
R
Russ P.
It looks "ugly" simply because it is new to you. Once you get used to
it, I'll bet it will look fine. And resemblance to another language is
not a very good reason to reject it.
R
Russ P.
Is "@" a "speaking identifier? How about "#" and "!="? Last I heard,
they were all part of Python.
R
Russ P.
Yes, you can always use "s". But single-letter identifiers are not
usually a good idea, because they are hard to search on. A slightly
better option is "S", which is a little better for searching but not
as good as "$". I have considered using "S" extensively in my code,
but I hesitate because it is not recognized in official Python coding
standards.
S
Steven D'Aprano
If -- and that's a HUGE if -- the compiler is changed to allow $method,
it could certainly be changed to allow $.method.
If a line of code uses too many instance attributes to fit comfortably on
a line, spread it over two lines. There is no newline shortage, they are
a renewable resource.
Yes they are.
@f
is pronounced "at f" or "decorate f".
# comment
is pronounced "hash comment" or even not pronounced at all.
x != y
is pronounced "x not equal to y"
The proposed
def $method(arg):
would be pronounced "def dollar method arg" or "def method self arg". The
first is ugly to my ears, the second confusing.
-2 on this proposal.
it could certainly be changed to allow $.method.
If a line of code uses too many instance attributes to fit comfortably on
a line, spread it over two lines. There is no newline shortage, they are
a renewable resource.
Yes they are.
@f
is pronounced "at f" or "decorate f".
# comment
is pronounced "hash comment" or even not pronounced at all.
x != y
is pronounced "x not equal to y"
The proposed
def $method(arg):
would be pronounced "def dollar method arg" or "def method self arg". The
first is ugly to my ears, the second confusing.
-2 on this proposal.
A
Antoine De Groote
Russ said:
I would not say that "ugly" and "new" (or "unused" for that matter) are
the same. There are going to be a number of things in Python 3 that are
new and to which one is not used, but they certainly are not ugly. Ugly
is of course a matter of taste, I'll give you that, but to me it's still
ugly.
R
Russ P.
Regarding "$" as a stand-in for "self" is less of a stretch than the
examples you gave.
Did you get two votes in the Presidential election too? 8^)
B
bearophileHUGS
Steven D'Aprano:
Splitting lines is generally possible, but sometimes it's not I want,
for example to keep a formula whole.
And splitting lines increases line count. Increasing line count may
reduce the amount of code you can see in a screenshot, and this may
decrease a little the programmer's ability to understand code.
(I am not suggesting to cram everything into one or few lines, like in
K language: regarding code size there's an optimal middle point
between K/APL and Ada/certain Java. Still, typing "self." very often
requires time, and even if you are lucky to have an IDE that helps you
write that faster, the code uses lot of space anyway).
That's why I say that the following code, while looking a little ugly,
may be a little "better" anyway (and maybe even more readable):
class ThisIsAClass:
def $some_method(arg1, arg2):
$value = arg1 + $foo + $bar + $baz * arg2
...
Than the current syntax:
class ThisIsAClass:
def some_method(self, arg1, arg2):
self.value = arg1 + self.foo + self.bar + self.baz * arg2
...
Bye,
bearophile
Splitting lines is generally possible, but sometimes it's not I want,
for example to keep a formula whole.
And splitting lines increases line count. Increasing line count may
reduce the amount of code you can see in a screenshot, and this may
decrease a little the programmer's ability to understand code.
(I am not suggesting to cram everything into one or few lines, like in
K language: regarding code size there's an optimal middle point
between K/APL and Ada/certain Java. Still, typing "self." very often
requires time, and even if you are lucky to have an IDE that helps you
write that faster, the code uses lot of space anyway).
That's why I say that the following code, while looking a little ugly,
may be a little "better" anyway (and maybe even more readable):
class ThisIsAClass:
def $some_method(arg1, arg2):
$value = arg1 + $foo + $bar + $baz * arg2
...
Than the current syntax:
class ThisIsAClass:
def some_method(self, arg1, arg2):
self.value = arg1 + self.foo + self.bar + self.baz * arg2
...
Bye,
bearophile
R
r
Bad idea having two ways to do this. Pick one or the other!
T
Tommy Grav
I think my biggest problem with this is what got me off Perl.
Add $, together with already used @ and maybe some other
identifiers and I start loosing track of what each of the character
means. It is fine when you are used to the language, but
learning it becomes a harder proposition. self.foo is self-explanatory
(no pun intended) to me, $foo is not.
Cheers
Tommy
N
News123
Daniel said:
Hmm,
I'd give the proposal a -1. Perhaps I'm missing something though.
Does this really justify an enhancement?
Whether the implicit parameter is prepended with a dot or whether it's
the first parameter with the parantheses doesn't save me any typing and
the benefit of 'visualizing' how the function should be called seems
minor to me.
What would be interesting would be some syntactical sugar to get rid of
the 'self' (at least in the code body).
example:
class C:
class_elements a,b,c,d
def method(self,arg):
global d
a,b,c = arg[0..3]
d = a + b
self.e = a + d
instead of
class C:
def method(self,arg):
self.a,self.b,self.c,self.d = arg[0..4]
self.e = self.a + self.b
As far as I understood (I never really followed any of these threads),
getting rid of self has already been discussed and rejected many times.
bye
N
C
Carl Banks
I'd be inclined to think that this defines an instancemethod on an
existing object a. In other word, I'd read the following two lines as
more or less equivalent.
def a.add(b): return a+b
a.add = lambda b: a+b
Just as the following are equivalent:
def foo(): return bar
foo = lambda: bar
I had been -0 on this, but now I think I'm -1.
Carl Banks
C
Carl Banks
None of them are identifiers. $, used as proposed, would be.
(Then again, _ is an identifier.)
Carl Banks
C
Carl Banks
Perl is not new to me and I am familiar with the syntax, such as it
is. I find it unspeakably ugly. So, no, you would lose your bet if
it were me.
Carl Banks
C
Carl Banks
-1
I explained why deep in the thread but I'll elaborate more here. When
I see a def statement, I mentally equate that to an assigment to the
thing being def'ed. So for instance, when I see this:
def <something>():
I think of it like this:
<somthing> = <the defined function>
Thus, if I were to see a function definition like this
def foo.bar(): return 1
I would think you were defining a function and assigning it to
foo.bar. IOW, it would be mostly equivalent to this:
foo.bar = lambda: 1
(Analogously, I would expect a definition like this:
def baz[10](): return 1
to be equivalent to this:
baz[10] = lambda: 1 )
So, if, inside a class definition, I were to see this:
def self.method(): return 1
Well, I'd understand that is was a method assigment, of course, but it
would conflict with what I would expect the natural meaning of
something like def a.b() would be. The above statement is not
equivalent to:
self.method = lambda: 1
but I think that's what it ought to be, in general.
Carl Banks
D
Daniel Fetchinson
Hi folks,
It doesn't add anything but makes something that exists a bit clearer
and friendlier to newbies. Saving typing was never the intention.
There will be python 4000 eventually
It doesn't add anything but makes something that exists a bit clearer
and friendlier to newbies. Saving typing was never the intention.
There will be python 4000 eventually
D
Daniel Fetchinson
Bad idea having two ways to do this. Pick one or the other!
Maybe only this alternative syntax for python 4000?
Maybe only this alternative syntax for python 4000?
C
Chris Rebert
Similarly, to those coming from Ruby or those operating under the
frequent misunderstanding that the `def`s are happening in the context
of a class object (which in reality has yet to be created), `self` in
this context might be misconstrued as the class object and thus `def
self.foo` might be misunderstood (through the intuitive equivalence
you mention) as a defining a classmethod rather than an instance
method.
I also strongly echo the TOOWTDI arguments against adding this
duplicative syntax. It's a minor gain but costs much more than it's
worth for violating The Zen.
Cheers,
Chris