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?

[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(thi s)" 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****@america n.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 "counterintuiti ve" 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*******@yaho o.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***@holdenwe b.comwrote:

Just the same there are sound reasons for it, so I'd prefer to see you
using "counterintuiti ve" 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.comw rote:

In article <sl************ ****@se-162.se.wtb.tue. nl>,
"A.T.Hofkam p" <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***@holdenwe b.comwrote:

>Just the same there are sound reasons for it, so I'd prefer to see you
using "counterintuiti ve" 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