Too many 'self' in python.That's a big flaw in this language.

[hide1713]

HI
I'm currently using Python. I find that a instance variable must
confined with self,
for example:
class a:
def __init__(self):
self.aa=10
def bb(self):
print self.aa # See .if in c++,I could use aa to change that
variable

That's a big inconvenience in coding ,especially when you have lot of
variable
If you method need 10 variables ,you have to type "self" for 10 times
and that also makes your variable longer.

>From My point,I think this only help python interpreter to deside

where to look for.
Is there anyone know's how to make the interpreter find instance name
space first?
Or any way to make programmer's life easier?

[Marc 'BlackJack' Rintsch]

In <11*********************@e9g2000prf.googlegroups.c om>,
hi******@gmail.com wrote:

I'm currently using Python. I find that a instance variable must
confined with self,
for example:
class a:
def __init__(self):
self.aa=10
def bb(self):
print self.aa # See .if in c++,I could use aa to change that
variable

That's a big inconvenience in coding ,especially when you have lot of
variable
If you method need 10 variables ,you have to type "self" for 10 times
and that also makes your variable longer.

>>From My point,I think this only help python interpreter to deside

where to look for.
Is there anyone know's how to make the interpreter find instance name
space first?
Or any way to make programmer's life easier?

Use a shorter name than `self` or an editor with auto completion. If a
name in a function or method is local or global is decided at compile
time, not at run time. So at least every assignment to an instance
attribute must have the ``self.`` in front or the compiler sees the name
as local to the method. Changing this would slow down the interpreter
because every name has to be looked up in the instance dict every time to
decide if it's an attribute or a local name.

Another drawback of your proposed "magic" is that attributes can be
assigned, deleted or delegated dynamically at run time. So your bare `aa`
name can change meaning from instance attribute to local name or vice
versa over the time.

You must have very compelling reasons to ask for changes that spare you
some keystrokes by the way. Pythonistas usually don't like sacrificing
readability for fewer characters. Most source code will be written once
but must be read and understood a couple of times, so it's more important
to have clear than short code. With `self` in place you always know which
names are local and which are attributes.

Ciao,
Marc 'BlackJack' Rintsch

[Neil Cerutti]

On 2007-06-27, hi******@gmail.com <hi******@gmail.comwrote:

HI
I'm currently using Python. I find that a instance variable must
confined with self,
for example:
class a:
def __init__(self):
self.aa=10
def bb(self):
print self.aa # See .if in c++,I could use aa to change that
variable

That's a big inconvenience in coding ,especially when you have
lot of variable If you method need 10 variables ,you have to
type "self" for 10 times and that also makes your variable
longer.

I recommend the discussion of this issue in the Python FAQ.

http://www.python.org/doc/faq/genera...ions-and-calls

From My point,I think this only help python interpreter to
deside where to look for. Is there anyone know's how to make
the interpreter find instance name space first? Or any way to
make programmer's life easier?

Try thinking of "self." as a notation that provides vital
information to you, the programmer.

--
Neil Cerutti

[faulkner]

On Jun 27, 7:02 am, "[e-mail]" <[e-mail]:

HI
I'm currently using Python. I find that a instance variable must
confined with self,
for example:
class a:
def __init__(self):
self.aa=10
def bb(self):
print self.aa # See .if in c++,I could use aa to change that
variable

That's a big inconvenience in coding ,especially when you have lot of
variable
If you method need 10 variables ,you have to type "self" for 10 times
and that also makes your variable longer.

From My point,I think this only help python interpreter to deside

where to look for.
Is there anyone know's how to make the interpreter find instance name
space first?
Or any way to make programmer's life easier?

http://www.voidspace.org.uk/python/w..._16.shtml#e584

[Roy Smith]

faulkner <fa*********@gmail.comwrote:

http://www.voidspace.org.uk/python/w..._16.shtml#e584

I looked the "Selfless Python" idea described there, and I think it's a
REALLY bad idea. It's a clever hack, but not something I would ever want
to see used in production code. Sure, it saves a little typing, but it
invokes a lot of magic and the result is essentially a new language and
everybody who uses this code in the future will have to scratch their heads
and figure out what you did.

Programs get written once. They get read and maintained forever, by
generations of programmers who haven't even been hired by your company yet.
Doing some clever magic to save a few keystrokes for the original
programmer at the cost of sowing confusion for everybody else in the future
is a bad tradeoff.

[Roy Smith]

Marc 'BlackJack' Rintsch <bj****@gmx.netwrote:

Use a shorter name than `self` or an editor with auto completion.

Of the two, I'd strongly vote for the auto completion (assuming you feel
the need to "solve" this problem at all). The name "self" is so ingrained
in most Python programmers minds, that it's almost a keyword. Changing it
to "this" or "s" or "me" will just make your program a little harder for
other people to understand.

Changing it to "this" would be particularly perverse since it's not even
any less typing. In fact, on a standard keyboard, it's harder to type
since it involves moving off the home row more :-)

[Sion Arrowsmith]

Neil Cerutti <ho*****@yahoo.comwrote:

>On 2007-06-27, hi******@gmail.com <hi******@gmail.comwrote:

>From My point,I think this only help python interpreter to
deside where to look for. Is there anyone know's how to make
the interpreter find instance name space first? Or any way to
make programmer's life easier?

Try thinking of "self." as a notation that provides vital
information to you, the programmer.

And it provides even more vital information to *other* programmers
dealing with your code ("other" including "you in six months time").
I've just confused the socks off a cow-orker by writing in a C++
method kill(SIGTERM); -- confusion which would have been avoided if
I'd used an explicit this->kill(SIGTERM); . But amongst C++'s many
flaws, such disambiguation is frowned on as non-idiomatic. Explicit
self *is a good thing*.

--
\S -- si***@chiark.greenend.org.uk -- http://www.chaos.org.uk/~sion/
"Frankly I have no feelings towards penguins one way or the other"
-- Arthur C. Clarke
her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump

[Jorgen Bodde]

I had the same feeling when I started, coming from a C++ background, I
forgot about self a lot, creating local copies of what should be an
assign to a class instance, or methods that could not be found because
I forgot 'self' .

Now I am 'kinda' used to it, as every language has some draw backs
(you can't please all). But, what about something in between like only
using the dot (.) for a shorter notation?

self.some_var = True

Could become:

..some_var = True

Which basically shows about the same thing, but you leave 'self' out
of the syntax. Ofcourse it should not be allowed to break a line
between the dot and the keywords, else Python would never know what to
do;

my_class()
..my_var = True

Should not be parsed the same as;

my_class().my_var = True

Just a suggestion. I am pretty happy with self, but I could settle for
a shorter version if possible.

- Jorgen
On 6/27/07, Roy Smith <ro*@panix.comwrote:

Marc 'BlackJack' Rintsch <bj****@gmx.netwrote:

Use a shorter name than `self` or an editor with auto completion.

Of the two, I'd strongly vote for the auto completion (assuming you feel
the need to "solve" this problem at all). The name "self" is so ingrained
in most Python programmers minds, that it's almost a keyword. Changing it
to "this" or "s" or "me" will just make your program a little harder for
other people to understand.

Changing it to "this" would be particularly perverse since it's not even
any less typing. In fact, on a standard keyboard, it's harder to type
since it involves moving off the home row more :-)
--
http://mail.python.org/mailman/listinfo/python-list

[A.T.Hofkamp]

On 2007-06-27, hi******@gmail.com <hi******@gmail.comwrote:

HI
I'm currently using Python. I find that a instance variable must
confined with self,
for example:
class a:
def __init__(self):
self.aa=10
def bb(self):
print self.aa # See .if in c++,I could use aa to change that
variable

c++ is a much more static language (for example, you cannot create new fields
in your class at run time), so it can decide in advance what you mean.

In other words, it is a cost you pay for the increased flexibility. You may not
be using that flexibility, but it is there, and people use it.

That's a big inconvenience in coding ,especially when you have lot of
variable

I have switched from c++ to Python several years ago, and was surprised about
having to explicitly write 'self' each time. However, I never considered it "a
big inconvenience".
As years went by I have come to like the explicit notation in Python.

Or any way to make programmer's life easier?

Others have already pointed out that leaving out 'self' is more bad than good.
I think they are right. In the past I also thought that Python was badly
designed, and until now, in the end it appeared that I was always in error.
[off-topic:
I think that again now with the default implementation of the object.__eq__ and
object.__hash__ methods. I believe these methods should not exist until the
programmer explicitly defines them with a suitable notion of equivalence.

Anybody have a good argument against that? :-)
]
Another suggestion may be to look at your code again, and check whether all
self's are really needed. In other words, can you improve your code by reducing
use of instance variables?
In Python, The "a=b" statement is extremely cheap, because you don't copy data.
Exploit that feature.

An alternative may be to copy a self variable into a local variable one and use
the local variable in the method. Another option may be to collect results in a
local variable first and then assign it to a self.X variable.

If you really have a lot of variables, are you sure that they should all be
seperate (flat) variables in one class, ie would it be possible to merge some
of them together in another object and have more structure in the variables?
(classes are much cheaper in Python than in c++ w.r.t. amount of code)
Sincerely,
Albert

[Bjoern Schliessmann]

hi******@gmail.com wrote:

I'm currently using Python.

How long have you been using Python?

I find that a instance variable
must confined with self, for example:
class a:
def __init__(self):
self.aa=10
def bb(self):
print self.aa #
See .if in c++,I could use aa to change that variable

Mh, strange, I personally like to use "this.a" in C++, to make clear
I use an instance variable.

That's a big inconvenience in coding ,especially when you have lot
of variable

NACK, see above.

If you method need 10 variables ,you have to type "self" for 10
times and that also makes your variable longer.

Explicit is better than implicit.

From My point,I think this only help python interpreter to deside
where to look for.

IMHO, it's also a great hint for the programmer. With others' C++
code, I'm often confused what kinds of variables (global, instance,
static, ...) they access, it's also badly commented. If C++ forced
the programmer to write "this.var", the code would be
understandable with much less comments.

Regards,
Björn

--
BOFH excuse #13:

we're waiting for [the phone company] to fix that line

[John Roth]

On Jun 27, 5:02 am, "[e-mail]" <[e-mail]:

HI
I'm currently using Python. I find that a instance variable must
confined with self,
for example:
class a:
def __init__(self):
self.aa=10
def bb(self):
print self.aa # See .if in c++,I could use aa to change that
variable

That's a big inconvenience in coding ,especially when you have lot of
variable
If you method need 10 variables ,you have to type "self" for 10 times
and that also makes your variable longer.

From My point,I think this only help python interpreter to deside

where to look for.
Is there anyone know's how to make the interpreter find instance name
space first?
Or any way to make programmer's life easier?

Guido has already said that this will not change in Python 3.0 See PEP
3099.

John Roth

[Bruno Desthuilliers]

Jorgen Bodde a écrit :

I had the same feeling when I started, coming from a C++ background, I
forgot about self a lot, creating local copies of what should be an
assign to a class instance, or methods that could not be found because
I forgot 'self' .

Now I am 'kinda' used to it, as every language has some draw backs
(you can't please all). But, what about something in between like only
using the dot (.) for a shorter notation?

self.some_var = True

Could become:

.some_var = True

Which basically shows about the same thing, but you leave 'self' out
of the syntax. Ofcourse it should not be allowed to break a line
between the dot and the keywords, else Python would never know what to
do;

my_class()
.my_var = True

Should not be parsed the same as;

my_class().my_var = True

Just a suggestion. I am pretty happy with self, but I could settle for
a shorter version if possible.

What is nice with the required, explicit reference to the instance -
which BTW and so far is not required to be *named* 'self' - is that it
avoids the need for distinct rules (and different implementations) for
functions and methods. The different 'method' types are just very thin
wrappers around function objects. Which in turn allow to use 'ordinary'
functions (defined outside a class) as methods - IOW, to dynamically
extend classes (and instances) with plain functions. Uniformity can also
have very practical virtues...

[John Nagle]

Bruno Desthuilliers wrote:

Jorgen Bodde a écrit :

>But, what about something in between like only
using the dot (.) for a shorter notation?

How about "Mavis Beacon Teaches Typing"?

John Nagle

[Andy Freeman]

On Jun 27, 2:54 pm, John Nagle <[e-mail]:

But, what about something in between like only
using the dot (.) for a shorter notation?

How about "Mavis Beacon Teaches Typing"?

How about no "wouldn't it be better" suggestions until at least three
months after the suggester has written at least 1000 lines of working
code.?

[Alex Martelli]

Bjoern Schliessmann <us**************************@spamgourmet.com>
wrote:
...

Mh, strange, I personally like to use "this.a" in C++, to make clear
I use an instance variable.

That would be nice, unfortunately your C++ compiler will refuse that,
and force you to use this->a instead;-).

Many programming shops use naming conventions instead, such as my_a or
a_ (trailing underscore for member-variables) -- I've even seen the
convention this_a which IMHO is silly (at that point you might as well
use this->a and avoid the 'convention'!-).

Anyway, I essentially agree with you (except for the C++ bit: since this
is a pointer, it needs ->). However, full disclosure, Smalltalk/XP
superstar Kent Beck disagrees -- in his good book "Test Driven Design by
Example", in the chapter where he gives the Python example, he DOES
whine against the need to explicitly say self (the one bad bit in the
book:-).

For the curious: the explicit-self idea is essentially taken from
Modula-3, a sadly now forgotten language which still had an impact on
the history of programming.
Alex

[Bjoern Schliessmann]

Alex Martelli wrote:

Bjoern Schliessmann <us**************************@spamgourmet.com>
wrote:

>Mh, strange, I personally like to use "this.a" in C++, to make
clear I use an instance variable.

That would be nice, unfortunately your C++ compiler will refuse
that, and force you to use this->a instead;-).

Sure, thanks. Before I last used C++ I was forced to use Java --
where I would write "this.<member>". ;)

Many programming shops use naming conventions instead, such as
my_a or a_ (trailing underscore for member-variables) -- I've even
seen the convention this_a which IMHO is silly (at that point you
might as well use this->a and avoid the 'convention'!-).

ACK.

For the curious: the explicit-self idea is essentially taken from
Modula-3, a sadly now forgotten language which still had an impact
on the history of programming.

Mh, I'm going to read some about this one.

Regards,
Björn

--
BOFH excuse #4:

static from nylon underwear

[Lou Pecora]

In article <ma**************************************@python.o rg>,
"Jorgen Bodde" <jo*************@gmail.comwrote:

I had the same feeling when I started, coming from a C++ background, I
forgot about self a lot, creating local copies of what should be an
assign to a class instance, or methods that could not be found because
I forgot 'self' .

Now I am 'kinda' used to it, as every language has some draw backs
(you can't please all). But, what about something in between like only
using the dot (.) for a shorter notation?

self.some_var = True

Could become:

.some_var = True

Which basically shows about the same thing, but you leave 'self' out
of the syntax. Ofcourse it should not be allowed to break a line
between the dot and the keywords, else Python would never know what to
do;

my_class()
.my_var = True

Should not be parsed the same as;

my_class().my_var = True

Just a suggestion. I am pretty happy with self, but I could settle for
a shorter version if possible.

- Jorgen

Hmmm... I like this idea. Would you put a dot in the argument of a
class method?

def afcn(.,x,y):
# stuff here

??

I still like it. self remains a wart on python for me after 5 years of
use despite a deep love of the language and developers' community.

--
-- Lou Pecora

When I was a kid my parents moved a lot, but I always found them.
(R.Dangerfield)

[Alan Isaac]

A.T.Hofkamp wrote:

>>>>a = Car2(123)
b = Car2(123)
a == b

True

>>>>set([a,b])

set([Car2(123), Car2(123)])

I get a set with two equal cars, something that never happens with a set
my math teacher once told me.

Then your math teacher misspoke.
You have two different cars in the set,
just as expected. Use `is`.
http://docs.python.org/ref/comparisons.html

This is good behavior.

Cheers,
Alan Isaac

[A.T.Hofkamp]

On 2007-06-28, Alan Isaac <ai****@american.eduwrote:

A.T.Hofkamp wrote:

>>>>>a = Car2(123)
>b = Car2(123)
>a == b

True

>>>>>set([a,b])

set([Car2(123), Car2(123)])

I get a set with two equal cars, something that never happens with a set
my math teacher once told me.

Then your math teacher misspoke.
You have two different cars in the set,
just as expected. Use `is`.
http://docs.python.org/ref/comparisons.html

This is good behavior.

Hmm, maybe numbers in sets are broken then?

>>a = 12345
b = 12345
a == b

True

>>a is b

False

>>set([a,b])

set([12345])
Numbers and my Car2 objects behave the same w.r.t. '==' and 'is', yet I get a
set with 1 number, and a set with 2 cars.
Something is wrong here imho.

The point I intended to make was that having a default __hash__ method on
objects give weird results that not everybody may be aware of.
In addition, to get useful behavior of objects in sets one should override
__hash__ anyway, so what is the point of having a default object.__hash__ ?

The "one should override __hash__ anyway" argument is being discussed in my
previous post.
Albert

[Roy Smith]

In article <sl****************@se-162.se.wtb.tue.nl>,
"A.T.Hofkamp" <ha*@se-162.se.wtb.tue.nlwrote:

In object oriented programming, objects are representations of values, and the
system shouldn't care about how many instances there are of some value, just
like numbers in math. Every instance with a certain value is the same as every
other instance with the same value.

Whether two things are equal depends on the context. Is one $10 note equal
to another? It depends.

If the context is a bank teller making change, then yes, they are equal.
What's more, there are lots of sets of smaller notes which would be equally
fungible.

If the context is a district attorney showing a specific $10 note to a jury
as evidence in a drug buy-and-bust case, they're not. It's got to be
exactly that note, as proven by a recorded serial number.

In object oriented programming, objects are representations of the real
world. In one case, the $10 note represents some monetary value. In
another, it represents a piece of physical evidence in a criminal trial.
Without knowing the context of how the objects are going to be used, it's
really not possible to know how __eq__() should be defined.

Let me give you a more realistic example. I've been doing a lot of network
programming lately. We've got a class to represent an IP address, and a
class to represent an address-port pair (a "sockaddr"). Should you be able
to compare an address to a sockaddr? Does 192.168.10.1 == 192.168.10.1:0?
You tell me. This is really just the "does 1 == (1 + 0j)" question in
disguise. There's reasonable arguments to be made on both sides, but there
is no one true answer. It depends on what you're doing.

[John Nagle]

Alex Martelli wrote:

Bjoern Schliessmann <us**************************@spamgourmet.com>
wrote:
...

>>Mh, strange, I personally like to use "this.a" in C++, to make clear
I use an instance variable.

That would be nice, unfortunately your C++ compiler will refuse that,
and force you to use this->a instead;-).

Yes, as Strostrup admits, "this" should have been a reference.
Early versions of C++ didn't have references.

One side effect of that mistake was the "delete(this)" idiom,
which does not play well with inheritance. But that's a digression here.

John Nagle

[Steve Holden]

A.T.Hofkamp wrote:

On 2007-06-28, Alan Isaac <ai****@american.eduwrote:

>A.T.Hofkamp wrote:

>>>>>a = Car2(123)
>b = Car2(123)
>a == b
True

>set([a,b])
set([Car2(123), Car2(123)])

I get a set with two equal cars, something that never happens with a set
my math teacher once told me.

Then your math teacher misspoke.
You have two different cars in the set,
just as expected. Use `is`.
http://docs.python.org/ref/comparisons.html

This is good behavior.

Hmm, maybe numbers in sets are broken then?

>>>a = 12345
b = 12345
a == b

True

>>>a is b

False

>>>set([a,b])

set([12345])
Numbers and my Car2 objects behave the same w.r.t. '==' and 'is', yet I get a
set with 1 number, and a set with 2 cars.
Something is wrong here imho.

The point I intended to make was that having a default __hash__ method on
objects give weird results that not everybody may be aware of.
In addition, to get useful behavior of objects in sets one should override
__hash__ anyway, so what is the point of having a default object.__hash__ ?

The "one should override __hash__ anyway" argument is being discussed in my
previous post.

Hmm, I suspect you'll like this even less:

>>set((1.0, 1, 1+0j))

set([1.0])

Just the same there are sound reasons for it, so I'd prefer to see you
using "counterintuitive" or "difficult to fathom" rather than "broken"
and "wrong".

Such language implies you have thought about this more deeply than the
developers (which I frankly doubt) and that they made an inappropriate
decision (which is less unlikely, but which in the case you mention I
also rather doubt).

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

On Fri, 29 Jun 2007 00:47:16 -0300
"Gabriel Genellina" <ga*******@yahoo.com.arwrote:

__hash__ and equality tests are used by the dictionary
implementation, and the default implementation is OK for immutable
objects.

That is probably why inf == inf yields True.
In this unique case, I do not like the default implementation.

Martin

[A.T.Hofkamp]

On 2007-06-29, Steve Holden <st***@holdenweb.comwrote:

Just the same there are sound reasons for it, so I'd prefer to see you
using "counterintuitive" or "difficult to fathom" rather than "broken"
and "wrong".

You are quite correct, in the heat of typing an answer, my wording was too
strong, I am sorry.
Albert

[A.T.Hofkamp]

On 2007-06-28, Roy Smith <ro*@panix.comwrote:

In article <sl****************@se-162.se.wtb.tue.nl>,
"A.T.Hofkamp" <ha*@se-162.se.wtb.tue.nlwrote:

>In object oriented programming, objects are representations of values, and the
system shouldn't care about how many instances there are of some value, just
like numbers in math. Every instance with a certain value is the same as every
other instance with the same value.

Whether two things are equal depends on the context. Is one $10 note equal
to another? It depends.

If the context is a bank teller making change, then yes, they are equal.
What's more, there are lots of sets of smaller notes which would be equally
fungible.

If the context is a district attorney showing a specific $10 note to a jury
as evidence in a drug buy-and-bust case, they're not. It's got to be
exactly that note, as proven by a recorded serial number.

In object oriented programming, objects are representations of the real
world. In one case, the $10 note represents some monetary value. In
another, it represents a piece of physical evidence in a criminal trial.
Without knowing the context of how the objects are going to be used, it's
really not possible to know how __eq__() should be defined.

I can see your point, but am not sure I agree. The problem is that OO uses
models tailored to an application, ie the model changes with each application.

In a bank teller application, one would probably not model the serial number,
just the notion of $10 notes would be enough, as in "Note(value)". The contents
of a cash register would then for example be a dictionary of Note() objects to
a count. You can merge two of such dictionaries, where the 'value' data of the
Note objects would be the equivalence notion.

In an evidence application one **would** record the serial number, since it is
a relevant distinguishing feature between notes, ie one would model Note(value,
serialnumber).
In this application the combination of value and serial number together defines
equivalence.

However, also in this situation we use values of the model for equivalence. If
we have a data base that relates evidence to storage location, and we would
like to know where a particular note was stored, we would compare Note objects
with each other based in the combination of value and serial number, not on
their id()'s.

You tell me. This is really just the "does 1 == (1 + 0j)" question in
disguise. There's reasonable arguments to be made on both sides, but there
is no one true answer. It depends on what you're doing.

While we don't agree on how OO programming handles equality (and it may well be
that there are multiple interpretations possible), wouldn't your argument also
not lead to the conclusion that it is better not to have a pre-defined __eq__
method?
Albert

[Steve Holden]

A.T.Hofkamp wrote:

On 2007-06-29, Steve Holden <st***@holdenweb.comwrote:

>Just the same there are sound reasons for it, so I'd prefer to see you
using "counterintuitive" or "difficult to fathom" rather than "broken"
and "wrong".

You are quite correct, in the heat of typing an answer, my wording was too
strong, I am sorry.

No problem, I do the same thing myself ...

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------

[Alan Isaac]

A.T.Hofkamp wrote:

Hmm, maybe numbers in sets are broken then?

>>>>a = 12345
b = 12345
a == b

True

>>>>a is b

False

>>>>set([a,b])

set([12345])

Numbers and my Car2 objects behave the same w.r.t. '==' and 'is', yet I get a
set with 1 number, and a set with 2 cars.
Something is wrong here imho.

The point I intended to make was that having a default __hash__ method on
objects give weird results that not everybody may be aware of.
In addition, to get useful behavior of objects in sets one should override
__hash__ anyway, so what is the point of having a default object.__hash__ ?

The point is: let us have good default behavior.
Generally, two equal numbers are two conceptual
references to the same "thing". (Say, the Platonic
form of the number.) So it is good that the hash value
is determined by the number. Similarly for strings.
Two equal numbers or strings are **also** identical,
in the sense of having the same conceptual reference.
In contrast, two "equal" cars are generally not identical
in this sense. Of course you can make them so if you wish,
but it is odd. So *nothing* is wrong here, imo.

Btw:

>>a = 12
b = 12
a == b

True

>>a is b

True

Cheers,
Alan Isaac