D
D'Arcy J.M. Cain
Isn't this a showstopper all by itself?
Yes, this is why good languages try to limit the number of reserved
words as much as possible.
Isn't this a showstopper all by itself?
Yes, this is why good languages try to limit the number of reserved
words as much as possible.
D
D'Arcy J.M. Cain
Well, if we are arguing over which reason to not change it is more
important than I would say that we are in "violent agreement."
K
Kay Schluehr
??
This is an extra requirement. Why do you want to make 'self' a keyword?
A
Aahz
The point I was trying to make originally was that applying any mantra
dogmatically, including Explicit is better than implicit, can lead to
bad results. Perhaps having Practicality beats purity is enough of a
reminder of that fact for the Python community
IMO, you made a big mistake in combining your point with two other meaty
issues (whether method definitions should include self and whether !=
should use __eq__() as a fallback). Moreover, your point is IMO not
sufficiently proven (that is, I see little evidence that Python
development follows any one point of the Zen of Python dogmatically).
You should therefore not be particularly surprised that the discussion
has gone sideways to your intentions -- especially when you start with a
flamebait Subject: line of "attacking sacred cows"! If solid discussion
is your goal, I suggest that you wait a couple of weeks and start over
with a brand-new thread.
M
Michele Simionato
I fully subscribe this. The point about __eq__ is legitimate and could
be discussed with quite tones.
I was bitten by this surprising behavior just a few
days ago, I had defined __eq__ and I expected __neq__
to be defined in the obvious way. I saw that it was
not the case and I figured out immediately that
I had to override __neq__ explicitely (I have
the "explicit is better than implicit" mantra
ingrained in my mind too), I did so and everything
worked out as a charm. Total time loss: five minutes.
So, it is not a big point. Still I think
that it would make sense to automatically
define __neq__ as the negation of __eq__.
I suppose the developers did not want to make a special
case in the implementation and this is also a legitimate
concern.
Michele Simionato
P
Paul Boddie
Here, I presume that the author meant "at the start of every method
signature".
But Jordan apparently wanted to omit that parameter. The omission of
all mentions of "self" could be regarded as a bonus, but it's a non-
trivial goal.
If, as I wrote, you permit the omission of "self" in method signatures
defined within class definitions, then you could still insist on
instance attribute qualification using "self" - exactly as one would
when writing Java according to certain style guidelines.
Paul
signature".
But Jordan apparently wanted to omit that parameter. The omission of
all mentions of "self" could be regarded as a bonus, but it's a non-
trivial goal.
If, as I wrote, you permit the omission of "self" in method signatures
defined within class definitions, then you could still insist on
instance attribute qualification using "self" - exactly as one would
when writing Java according to certain style guidelines.
Paul
R
Russ P.
I'm not sure exactly what people mean here by allowing "self" to be
"omitted" in method signatures. If it is omitted, then it seems to me
that a place holder would be needed to the interpreter that the first
argument is not just another name for "self."
In an earlier post on this thread (don't feel like looking it up at
the moment), someone suggested that member data could be accessed
using simply ".member". I think he might be on to something. The dot
is a minimal indicator that the data is a class member rather than
just local. However, a placeholder is still needed in the signature.
So why not allow something like this?:
class MyClass:
def func( , xxx, yyy):
.xxx = xxx
local = .yyy
The "self" argument is replaced with nothing, but a comma is used as a
placeholder.
C
Colin J. Williams
(+1) but why retain the leading comma inRuss said:
the argument list?
Colin W.
T
Terry Reedy
Carl said:
Whether or not one should write 'if x' or 'if x != 0' [typo corrected]
depends on whether one means the general 'if x is any non-null object
for which bool(x) == True' or the specific 'if x is anything other than
numeric zero'. The two are not equivalent. Ditto for the length example.
What people do properly advise against is the strictly redundant 'if x
is True' or 'if x == True'. Both imply a misunderstanding of how 'if'
works in Python.
As a side note, the usefulness of specific comparisons is greater in 3.0
where spurious comparisons raise exceptions. In 3.0, 'if x >= 0'
specifically means 'if x is a number comparable to ints that is greater
than or equal to 0'. In 3.0, [] ==/!= 0 are still False/True, but one
could exclude incomparables with 'if 0 <= x >= 0' (==0) or 'if x > 0 or
x < 0' (!=0). Any such specific comparisons could be used with this
pattern.
try:
x = []
if x >= 0:
print('should not get here')
except TypeError as m:
if m.args[0].startswith('unorderable types:'):
print('Here because of bad comparison')
Terry Jan Reedy
R
Russ P.
As I said, the leading comma is a place holder. Without it, the
interpreter would have no way of knowing that the first argument is
not just another name for "self."
We need to maintain compatibility with existing Python rules. If we
were designing a new language, we could omit the "self" argument in
the signature, and allow either ".xxx" or "self.xxx," at the
programmers discretion (i.e., let "self" be the standard name, like
"this" in C++).
T
Terry Reedy
Torsten said:
Will break.
But you can write 'for ubermenchen in range(10):' and in 3.0, with
diacritics added. Would you really feel no loss of freedom if Guido
make i0, i1, ... into keywords, which means they could not be used
elsewhere, and mandated them as for loop index variables?
T
Terry Reedy
Nikolaus said:
I did, but addressed the below in another post.
which means making 'self' a keyword just so it can be omitted. Silly
and pernicious.
tjr
T
Terry Reedy
Torsten said:
There is a lot of code you have not seen. Really. In informal code I
use 's' and 'o' for 'self' and 'other'. I don't usually post such
because it is not considered polite. So you have seen a biased sample
of the universe.
T
Terry Reedy
Paul said:
Reword. There is no requirement to name the instance anything in
particular. Thus there is no requirement at present that the first
parameter, which gives the name of the instance, be anything in
particular.
Which is what I said in the first sentence of my next paragraph, which
you clipped.
"Or the proposal would have to be that 'self' is mandatory for all
programmers in all languages." To clarify " ... that 'self' be the
mandatory instance name for all Python programmers regardless of
inclination or the natural language they otherwise use as a basis for
identifiers."
In sum, if the instance name is omitted from the parameter list, it must
either be discovered or mandated, and def statements in direct class
scope have to be treated differently from def statements elsewhere.
Terry Jan Reedy
C
Carl Banks
Can you think of any use cases for the former? And I mean something
where it can't be boiled down to a simple explicit test for the sorts
of arguments you're expecting; something that really takes advantage
of the "all objects are either true or false" paradigm.
The best thing I can come up with out of my mind is cases where you
want to check for zero or an empty sequence, and you want to accept
None as an alternative negative as well. But that's pretty weak.
The use case of simply passing something to a function that accepts
any boolean doesn't count. For instance, I could write:
def nand(a,b):
return not (a and b)
And then I could use it like this, even if x is an interger and y a
string:
if nand(x,y):
But that doesn't buy much since I could just pass in the explicit
tests like this:
if nand(x!=0,y!=""):
Carl Banks
L
Lawrence D'Oliveiro
In message
Yes it is, because it has "this".
Yes it is, because it has "this".
L
Lawrence D'Oliveiro
In message
Change "distribution" to "program" and you're on the right track.
Change "distribution" to "program" and you're on the right track.
R
Russ P.
On Jul 26, 2:25 pm, Terry Reedy
You take the name down to a single letter. As I suggested in an
earlier post on this thread, why not take it down to zero letters? You
could if Python accepted something like
class Whatever:
def fun( , cat):
.cat = cat
This is even better than the single-character name, not only because
it is shorter, but also because there is no question that you are
referring to "self." No need to look back at the method signature to
verify that.
For those who don't like the way the empty first argument looks, maybe
something like this could be allowed:
def fun( ., cat):
You take the name down to a single letter. As I suggested in an
earlier post on this thread, why not take it down to zero letters? You
could if Python accepted something like
class Whatever:
def fun( , cat):
.cat = cat
This is even better than the single-character name, not only because
it is shorter, but also because there is no question that you are
referring to "self." No need to look back at the method signature to
verify that.
For those who don't like the way the empty first argument looks, maybe
something like this could be allowed:
def fun( ., cat):
M
Marcus.CM
Well after reading some of these posts on "sacred python cow" on the
"self" , i would generally feel that most programmers
who started with C++/Java would find it odd. And its true, i agree
completely there should not be a need to put "self" into every single
member function. If you were writing an application and one of your
classes adds the same variable to each of its member function you would
do away with it too.
What could be done instead is :-
1. python should hardcode the keyword "self". So whenever this keyword
is used, it would automatically implied that it is
referring to a class scope variable. This would be similar to how the
"this" keyword is used in C++.
2. Omit self from the parameter.
class Abc :
def DoSomething (a,b,c) :
# class variable
self.somevar = a
self.someblar = b
self.somec = c
somevar = a * b # local variable
"self" , i would generally feel that most programmers
who started with C++/Java would find it odd. And its true, i agree
completely there should not be a need to put "self" into every single
member function. If you were writing an application and one of your
classes adds the same variable to each of its member function you would
do away with it too.
What could be done instead is :-
1. python should hardcode the keyword "self". So whenever this keyword
is used, it would automatically implied that it is
referring to a class scope variable. This would be similar to how the
"this" keyword is used in C++.
2. Omit self from the parameter.
class Abc :
def DoSomething (a,b,c) :
# class variable
self.somevar = a
self.someblar = b
self.somec = c
somevar = a * b # local variable
R
Russ P.
On Jul 26, 7:23 pm, "Marcus.CM"
That might make sense if you're starting from scratch on a new
language, but it is not compatible with Python as it is currently
stands. Yes, it could have been put into 3.0, but it's way too late
now for a change that drastic.
Beyond that, I don't like the idea of being forced to use "self" in
every case. Yes, C++ and Java standardized on "this," but it is
implied and is usually not explicitly needed.
That might make sense if you're starting from scratch on a new
language, but it is not compatible with Python as it is currently
stands. Yes, it could have been put into 3.0, but it's way too late
now for a change that drastic.
Beyond that, I don't like the idea of being forced to use "self" in
every case. Yes, C++ and Java standardized on "this," but it is
implied and is usually not explicitly needed.