Is 'everything' a refrence or isn't it?

[KraftDiner]

I was under the assumption that everything in python was a refrence...

so if I code this:
lst = [1,2,3]
for i in lst:
if i==2:
i = 4
print lst

I though the contents of lst would be modified.. (After reading that
'everything' is a refrence.)
so it seems that in order to do this I need to code it like:

lst = [1,2,3]
for i in range(len(lst)):
if lst[i] == 2:
lst[i]=4
print lst

Have I misunderstood something?

[Antoon Pardon]

Op 2006-01-14, Mike Meyer schreef <mw*@mired.org>:

Paul Rubin <http://ph****@NOSPAM.invalid> writes:

Mike Meyer <mw*@mired.org> writes:

> Whether the '==' operation conforms to your idea of what equality
> means is unclear.
Care to say what it does mean, then?

I'd say a==b doesn't necessarily mean a and b have the same value.

Care to say what it does mean (as opposed to what it doesn't mean), then?

I would say: "is equivallent with".

--
Antoon Pardon

[Antoon Pardon]

Op 2006-01-14, Mike Meyer schreef <mw*@mired.org>:

"Donn Cave" <do**@drizzle.com> writes:

|> 3. If two objects are equal with "==", does that
|> mean their values are the same?
Yes.
| >>> 3.0 == 3
| True
Evidently the value of 3.0 is the same as the value of 3.

And they do. They are two different representations of the same
value. More in another thread.

I would say they are two different values that are equivallent
in a lot of ways.

--
Antoon Pardon

[Boris Borcic]

Mike Meyer wrote :

For even more fun, consider 1.0 == 1 == decimal.Decimal('1.0').

Python 2.4.2 (#67, Sep 28 2005, 12:41:11) [MSC v.1310 32 bit (Intel)] on
win32
Type "copyright", "credits" or "license()" for more information.

import decimal
1 == 1.0 == decimal.Decimal('1.0') False decimal.Decimal('1.0') == 1 == 1.0

True

MMhhhh, painful

[Bengt Richter]

On 15 Jan 2006 13:50:14 -0800, Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

Mike Meyer <mw*@mired.org> writes:

> I'd say a==b doesn't necessarily mean a and b have the same value.

Care to say what it does mean (as opposed to what it doesn't mean), then?

a==b simply means that a.__eq__(b) returns True.

That's one possibility, but I guess __eq__ might not necessarily
even have to be defined (too lazy to set up the new-style class test ;-):

class A: ... def __getattr__(self, attr): print 'A().%s'%attr; raise AttributeError
... class B: ... def __getattr__(self, attr): print 'B().%s'%attr; raise AttributeError
... A()==B()

A().__eq__
B().__eq__
B().__eq__
A().__eq__
A().__coerce__
B().__coerce__
A().__cmp__
B().__cmp__
False

Regards,
Bengt Richter

[Steven D'Aprano]

On Mon, 16 Jan 2006 10:34:40 +0000, Bengt Richter wrote:

>>> class A: ... def __getattr__(self, attr): print 'A().%s'%attr; raise AttributeError
... >>> class B: ... def __getattr__(self, attr): print 'B().%s'%attr; raise AttributeError
... >>> A()==B()

A().__eq__
B().__eq__
B().__eq__
A().__eq__
A().__coerce__
B().__coerce__
A().__cmp__
B().__cmp__
False

Why are A().__eq__ and B().__eq__ both being called twice?
--
Steven.

[Boris Borcic]

Tim Peters a écrit :

[Alex Martelli]
...

In mathematics, 1 is not "the same" as 1.0 -- there exists a natural
morphism of integers into reals that _maps_ 1 to 1.0, but they're still
NOT "the same" thing. And similarly for the real-vs-complex case.
- but does there exists any sense of "mathematics object identity"
that's not built out of similar maps ? IOW, if - abstracting from your
example - I admit as a rule that is sufficient to deny identity, to
point out that two objects are "merely" related by a natural map, isn't
it then the case that I can display an infinite quantity of *distinct*
clones of any mathematical object or structure that I can think of ?

Smallscale python illustration :
2<<100 2535301200456458802993406410752L 2<<100 is 2<<100

False

[Xavier Morel]

I disagree here, 1 and 1.0 are the same mathematical object e.g. 1 (and
the same as "1+0i"), the difference due to notation only makes sense in
computer science where integers, real and complex ensembles are disjoin.
In mathematics, Z is included in IR which is included in C (note: this
is not mathspeak, but I have no idea how to say it in english), and this
notation -- at best -- merely determines the ensemble you're currently
considering.

There is no "natural morphism" of integers into reals because there is
no mathematical difference between integers and reals, the real ensemble
is merely a superset of the integers one.

Well, how do you know there should be a difference between
(a) "(there exists) a natural morphism from A to B"
(b) "A is a subset of B"
? To paraphrase you : "the 'natural morphism' ensemble is merely a
superset of the 'subset/superset' one"

More to the point, where you view really breaks is when two incompatible
extensions of the number tower are possible, like what happens with
complex numbers and surreal numbers, which are both rich extensions of
real numbers. Or real numbers and transfinite cardinals, viewed both as
extending natural numbers.

Or so it was last time i got a math course.

This all depends on which math course you last took ;-)

I often wonder whether young and adventurous minds could be more
efficiently seduced to mathematics by enlisting them to interstellar travel.

The idea goes thus. First note that by adjusting (natural) language
courses one may end up with home-grown pupils equivalent to pupils taken
from another continent; for instance you may teach arab to young
americans and obtain something more in the likeness of an arab.

Then argue that by adjusting the mathematics curriculum, one may obtain
similar effects, but with displacements on the scale of interstellar
travel rather than intercontinental travel !

[Tim Peters] You have more a physicist's view here. The simplest case is real versus complex,
where even a physicist <wink> can accept that a complex number,
formally, is an ordered pair of real numbers.
Well, I suppose you've heard of Paul Erdoes's notion of a "Supreme
Fascist" dictator of mathematics who owns a Book of All the Best Proofs ?

It's easy to extend Him with a -WarpDrive- method of the form "Any
teacher teaching A before B shall be sentenced to death".

The spacedrive effect would be obtained by an appropriate choices of A
and B divergent from our current habits. Of course one could expect many
choices to lead nowhere - or at least to rough rides. But, I surmise
that a promising and most fascinating pick would be A=real, B=complex.

.... in a computer all numerics suck,

Sets suck.

Cheers, BB
--
666 ?? -- 666 ~ .666 ~ 2/3 ~ 1 - 1/3 ~ tertium non datur
~ the excluded middle
~ "either with us, or against us" !

[Mikael Olofsson]

Fredrik Lundh wrote:

*what* the value is is defined by the operations that the object supports (via its
type).

*how* the value is represented inside the object is completely irrelevant; a Python
implementation may use electric charges in small capacitors, piles of rocks, diapers,
or an endless supply of small guys in odd costumes to encode the value inside an
object. Changes to the value may be carried out by CPU instructions, caterpillars,
toddlers with gasmasks, or an endless supply of small guys in odd costumes. The
only thing that's important is that you can, in your Python program, access an ob-
jects value via its type, and get other objects back when you do.

+1 QOTW

[Bengt Richter]

On Mon, 16 Jan 2006 21:58:26 +1100, Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

On Mon, 16 Jan 2006 10:34:40 +0000, Bengt Richter wrote:

>>> class A:

... def __getattr__(self, attr): print 'A().%s'%attr; raise AttributeError
...

>>> class B:

... def __getattr__(self, attr): print 'B().%s'%attr; raise AttributeError
...

>>> A()==B()

A().__eq__
B().__eq__
B().__eq__
A().__eq__
A().__coerce__
B().__coerce__
A().__cmp__
B().__cmp__
False

Why are A().__eq__ and B().__eq__ both being called twice?

I imagine it's trying the calls with args swapped or something like that.
Want to write a test and see? (Don't hold your breath if you're waiting for me to do it ;-)

Regards,
Bengt Richter

[Steven D'Aprano]

On Mon, 16 Jan 2006 21:18:35 +0000, Bengt Richter wrote:

On Mon, 16 Jan 2006 21:58:26 +1100, Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

On Mon, 16 Jan 2006 10:34:40 +0000, Bengt Richter wrote:

>>> class A:
... def __getattr__(self, attr): print 'A().%s'%attr; raise AttributeError
...
>>> class B:
... def __getattr__(self, attr): print 'B().%s'%attr; raise AttributeError
...
>>> A()==B()
A().__eq__
B().__eq__
B().__eq__
A().__eq__
A().__coerce__
B().__coerce__
A().__cmp__
B().__cmp__
False

Why are A().__eq__ and B().__eq__ both being called twice?

I imagine it's trying the calls with args swapped or something like that.
Want to write a test and see? (Don't hold your breath if you're waiting for me to do it ;-)

You already wrote a test. I can't think of any test I can write which
would give more information than yours. I'd like a test where I can see
the arguments which Python would apply to each method call, but I can't
think of any way to get those arguments inside the __getattr__ method.
Perhaps I'm not thinking hard enough.

(Actually writing __eq__ methods would defeat the purpose.)

There aren't that many possibilities. We can predict the other argument
from each call: if you call a method of A, the argument must be B and vice
versa. So it looks like Python is making the following calls:

A().__eq__(B)
B().__eq__(A)
B().__eq__(A)
A().__eq__(B)

followed by the unproblematic calls to __coerce__ and __cmp__.

What puzzles me is that after trying B.__eq__(A), it tries it again
immediately. It only calls coerce and cmp once with each set of args. What
am I missing?

--
Steven.

[Bengt Richter]

On Mon, 16 Jan 2006 21:58:26 +1100, Steven D'Aprano <st***@REMOVETHIScyber.com.au> wrote:

On Mon, 16 Jan 2006 10:34:40 +0000, Bengt Richter wrote:

>>> class A:

... def __getattr__(self, attr): print 'A().%s'%attr; raise AttributeError
...

>>> class B:

... def __getattr__(self, attr): print 'B().%s'%attr; raise AttributeError
...

>>> A()==B()

A().__eq__
B().__eq__
B().__eq__
A().__eq__
A().__coerce__
B().__coerce__
A().__cmp__
B().__cmp__
False

Why are A().__eq__ and B().__eq__ both being called twice?

Looks like it has to do with trying stuff with arguments switched?
This shows call and argumenst to method for whichever attribute access
is allowed to succeed after a count of failures...

def test(): ... global trial, which
... for which in xrange(9):
... print '\nwhich: %s'%which
... trial = 0
... A()==B()
... def nameof(x):return type(x).__getattribute__(x, '__class__').__name__ ... def __eq__(x, y): ... print '__eq__(%s(), %s())'%(nameof(x), nameof(y)); return False
... def __cmp__(x, y): ... print '__cmp__(%s(), %s())'%(nameof(x), nameof(y)); return 0
... def __coerce__(x, y): ... print '__coerce__(%s(), %s())'%(nameof(x), nameof(y)); return None
... class A: ... def __getattr__(self, attr):
... global trial
... print '%s: A().%s'%(trial, attr)
... if trial!=which: trial+=1; raise AttributeError
... return globals()[attr].__get__(self, type(self))
... class B: ... def __getattr__(self, attr):
... global trial
... print '%s: B().%s'%(trial, attr)
... if trial!=which: trial+=1; raise AttributeError
... return globals()[attr].__get__(self, type(self))
... test()
which: 0
0: A().__eq__
__eq__(A(), B())

which: 1
0: A().__eq__
1: B().__eq__
__eq__(B(), A())

which: 2
0: A().__eq__
1: B().__eq__
2: B().__eq__
__eq__(B(), A())

which: 3
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
__eq__(A(), B())

which: 4
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
__coerce__(A(), B())
4: B().__coerce__
__coerce__(B(), A())
4: A().__cmp__
__cmp__(A(), B())

which: 5
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
5: B().__coerce__
__coerce__(B(), A())
5: A().__cmp__
__cmp__(A(), B())

which: 6
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
5: B().__coerce__
6: A().__cmp__
__cmp__(A(), B())

which: 7
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
5: B().__coerce__
6: A().__cmp__
7: B().__cmp__
__cmp__(B(), A())

which: 8
0: A().__eq__
1: B().__eq__
2: B().__eq__
3: A().__eq__
4: A().__coerce__
5: B().__coerce__
6: A().__cmp__
7: B().__cmp__

Regards,
Bengt Richter

[Max]

Terry Hancock wrote:

On Sat, 07 Jan 2006 01:29:46 -0500
Mike Meyer <mw*@mired.org> wrote:

From what I can tell, Liskov proposed *three* different
names for
passing references to objects: call-by-sharing,
call-by-object, and call-by-object-reference.

"Call by object reference" makes the most sense to me. Names
in Python are object references: they refer to objects. You
might almost say "call by name" but that sort of implies
that you are passing the strings around (which is generally
untrue), and it doesn't convey what happens when the name is
something complex like "ham['spam'][0].eggs()[42]" (i.e.
"name" carries the conotation of being a simple string,
although you could argue that it doesn't have to mean that).

Except that what is passed is not "ham['spam'][0].eggs()[42]" -
that's the *name of where one copy of the objects name is*. The
name is ham['spam'][0].eggs()[42].id() - usually something like
0xBEEFBABE.

When I fill in a form (say if I applied for a visa) - three
things could happen:

a) Pass by object reference/name: I write "8x0323xxxxxx081" (my
ID number) or "Max Xxxxx Rabkin" (my name) on the form, so they
know who I am.

b) Your method (pass by container reference?): I write
"The youngest male living at:
32 Xyz Road
Rondebosch
Cape Town".
They know who I am, until I move house or I get a baby brother.

c) Pass by value: I staple myself to the form. Painful, but
it works. Unless I need a vaccination for the visa. Then I have
to make a copy of myself; one copy gets vaccinated while the
other is getting the visa. Unfortunately, I still can't get
into Italy, because the guy with the visa doesn't have a
vaccination and vice versa.

--Max

[rurpy]

Steve Holden wrote:
[...snipped a long and very helpful post addressing some
questions I had regarding the nature of an object's value
in python...]

Sorry for the belated reply Steve (I had some access
problems) but did want to let you know I found that post
very informative, and wanted to thank you for it.