Attack a sacred Python Cow

[s0suk3]

In message






Yes it is, because it has "this".

You mean the keyword "this"? It's just a feature. How does that make a
difference on being or not being OO?

(It's true that C++ has more OO features than Python, like private/
public members, virtual methods, etc. But I don't see how a trivial
feature like an additional keyword makes a difference.)

 

[Terry Reedy]

Russ P. wrote:

The use of <nothing>'.' has been suggested before and rejected.

 

[Terry Reedy]

No more than Python 3.0 breaks.

This proposal would break 3.0 code without sufficient reason.

 

[Terry Reedy]

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?

Because 1 letter is legal now, while no letters (already proposed and
rejected) is a major change and breakage of current simplicity and
consistency for zero functional benefit.

 

[Russ P.]

The use of <nothing>'.' has been suggested before and rejected.

Where and why?

 

[Russ P.]

Because 1 letter is legal now, while no letters (already proposed and
rejected) is a major change and breakage of current simplicity and
consistency for zero functional benefit.

Sorry, but I fail to see how it is a "major change." It only applies
to the first argument of a class member function, and the parser only
needs to look for an empty argument or a period. Furthermore, it would
break no working code.

It may indeed have been "proposed and rejected," but it would be a
nice way to clean up code in many areas, and as long as it cannot
break any working code, I think it should be reconsidered.

 

[Kay Schluehr]

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

Incidentally I knew that I had to overload the negation of __eq__
explicitely and did so writing
an __neq__ method. A few minutes later I found out it's not __neq__
but __ne__. So another few minutes were lost.

 

[Nikolaus Rath]

which means making 'self' a keyword just so it can be omitted. Silly
and pernicious.

Well, I guess that's more a matter of personal preference. I would go
for it immediately (and also try rename it to '@' at the same time).


Best,

-Nikolaus

--
»It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that.«
-J.H. Hardy

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

 

[Steven D'Aprano]

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.

You know, there are some programmers who haven't started with C++ or Java.

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.

Would I?

How would I do that here?

# untested
class FunnyNumber(int):
"""Silly class that acts like an integer, only one larger."""
def __add__(self, other):
return int(self)+1+other
def __mul__(self, other):
return (self+1)*other
def __sub__(self, other):
return int(self)+1-other

 

[Steven D'Aprano]

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?

The question isn't "why not", but "why". The status quo works well as it
is, even if it isn't perfect. Prove that implicit self is a good idea --
or at least prove that it is an idea worth considering.

"I don't like typing self" doesn't convince me. The same argument could
be made typing parentheses, colons, commas, etc. We could end up with
something like this:

class Foo base
def method x y z
.args = list x y z


That's not necessarily wrong, but it's not Python.

It's not enough to show that a change "isn't bad" -- you have to show
that it is actively good. Why should Python make any changes to the
current explicit self without a clear and solid reason to change?

You could if Python accepted something like

class Whatever:

def fun( , cat):

.cat = cat

This is even better than the single-character name,

By "better" do you mean "uglier"? If so, I agree with you. If not, then I
disagree that it is better.

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.

"Don't need to look at the method signature" is not an argument in favour
of implicit self. You don't need to look at the method signature when
you're using an explicit self either.

What happens with class-methods? With the cls (or if you prefer klass)
convention, it is simple to tell what object I am referring to. Now I
have to go back to the method signature to see if it is a class method or
instance method, instead of just looking at the explicit name.

For those who don't like the way the empty first argument looks, maybe
something like this could be allowed:

def fun( ., cat):

Even uglier than the first. Convince me there's a benefit.

 

[Steven D'Aprano]

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.

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.

But why do you need the explicit test? What benefit do you get from

if len(alist) != 0

instead of the simpler and faster "if alist" ? If you need to know that
alist is actually a list, isinstance() is the function you want; and if
you want to know that it has a length, hasattr(alist, '__len__') is
better. (Or call len() in a try...except block.) Either way, testing the
length is zero explicitly gains you nothing, and risks failure for any
sequence types that might distinguish between an empty sequence and a
length of zero.

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.

You might find it pretty weak, but I find it a wonderful, powerful
feature.

I recently wrote a method that sequentially calls one function after
another with the same argument, looking for the first function that
claims a match by returning a non-false result. It looked something like
this:

def match(arg, *functions):
for func in functions:
if func(arg):
return func

I wanted the function itself, not the result of calling the function. I
didn't care what the result was, only that it was something (indicates a
match) or nothing (no match). In one application, the functions might
return integers or floats; in another they might return strings. In a
third, they might return re match objects or None. I don't need to care,
because my code doesn't make any assumptions about the type of the result.

 

[alex23]

Where and why?

Google is your friend:
http://mail.python.org/pipermail/python-3000/2006-April/000793.html

 

[Lie]

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

Why not? Because that would make someone new to python scream in
terror.

        .xxx = xxx

        local = .yyy

OTOH, this might come as a handy syntax sugar, this is like With
Statement in VB, although in VB, you have to state explicitly what you
want to call implicitly when using something of the .methods. But I
think implementing this might come with a heavy toll to the parser.

 

[Marc 'BlackJack' Rintsch]

(It's true that C++ has more OO features than Python, like private/
public members, virtual methods, etc.

Oh yeah, again the discussion about `private`/`public` and if that's an
important OOP feature.

Aren't *all* methods in Python "virtual"?

And what's "etc."?

Ciao,
Marc 'BlackJack' Rintsch

 

[Terry Reedy]

You know, there are some programmers who haven't started with C++ or Java.

Like my teenager, who is only 1 of many kids learning Python as a first
algorithm language. If not now, eventually, I expect a majority of
Python programmers to *not* be C++/Java graduates.

tjr

 

[Bruno Desthuilliers]

Torsten Bronger a écrit :

Hallöchen!


(snip)


What does "not rare" mean for you?

More than once a week.

 

[castironpi]

Well, I guess that's more a matter of personal preference. I would go
for it immediately (and also try rename it to '@' at the same time).

Best,

   -Nikolaus

--

 »It is not worth an intelligent man's time to be in the majority.
  By definition, there are already enough people to do that.«
                                                         -J.H. Hardy

Hardy has an interesting claim. OT.

He has omitted a couple of lemmas, which aren't true.

1: There are enough people to be in the majority.
2: It is not worthwhile to be in the majority.
3: There is no majority of worthwhile timespending.
4: There is no majority of intelligent men.
5: Being in the majority takes time.

It is worth some intelligent men's time to be in the majority; the
majority of intelligent men are intelligent men, and are in the
majority of intelligent men. Perhaps it is merely not worth their
time to be.

 

[castironpi]

I think you misunderstood him. What he wants is to write

class foo:
   def bar(arg):
       self.whatever = arg + 1

instead of

class foo:
   def bar(self, arg)
       self.whatever = arg + 1

so 'self' should *automatically* only be inserted in the function
declaration, and *manually* be typed for attributes.

Best,

   -Nikolaus

There's a further advantage:

class A:
def get_auxclass( self, b, c ):
class B:
def auxmeth( self2, d, e ):
#here, ...
return B

Because Python permits you to name 'the current instance' any name you
want, you're able to hold more than one current instance at one time.
In this case, you could write 'return self.val+ self2.val' with no
trouble, while I'm not even sure that anything like that is possible
in C, C++, Java, or anything higher other than Python. (This is a
good point, outside of the usual, by the way.)

 

[Bruno Desthuilliers]

Marcus.CM a écrit :

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.

"member function" is C++. The way Python works is that you defines
functions (inside or outside a class, that doesn't matter) that, when
set as *class* attributes, are used as the *implementation* of the
corresponding method.

I think it's very important to use appropriate terms to understand
what's really going on here. As soon as you understand that what you
"def"ine is a *not* a method, but a *function* (eventually) used as the
*implementation* of a method, the necessary declaration of the target
object (instance or class) in the function's signature just makes sense
- the usual way to make some object accessible to the body of a
function is to pass this object as argument, isn't it ?

(snip)

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.

Usually, 'self' is used for *instance* attributes, you know. "class
attribute" are attributes of the class object itself (that is, shared by
all instances of the class).

This would be similar to how the
"this" keyword is used in C++.

2. Omit self from the parameter.

Now how would it work for functions defined outside a class statement,
but used as the implementation of a method ?

def toto(self):
# dummy exemple code
return self

class Tata(object):
pass

Tata.tutu = toto

class Titi(object):
tutu = toto

(snip)

 

[Bruno Desthuilliers]

Russ P. a écrit :

Sorry, but I fail to see how it is a "major change." It only applies
to the first argument of a class member function,

There's nothing like a "class member function" in Python.