Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #28456 > unrolled thread

is implemented with id ?

Back to article view | Back to comp.lang.python

Contents

  is implemented with id ? Franck Ditter <franck@ditter.org> - 2012-09-05 08:30 +0200
    Re: is implemented with id ? Benjamin Kaplan <benjamin.kaplan@case.edu> - 2012-09-04 23:40 -0700
      Re: is implemented with id ? Franck Ditter <franck@ditter.org> - 2012-09-05 15:19 +0200
        Re: is implemented with id ? Hans Mulder <hansmu@xs4all.nl> - 2012-09-05 15:48 +0200
          Re: is implemented with id ? aahz@pythoncraft.com (Aahz) - 2012-11-03 12:41 -0700
            Re: is implemented with id ? Hans Mulder <hansmu@xs4all.nl> - 2012-11-03 22:49 +0100
              Re: is implemented with id ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-03 22:18 +0000
                Re: is implemented with id ? Chris Angelico <rosuav@gmail.com> - 2012-11-04 09:50 +1100
                Re: is implemented with id ? Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2012-11-04 01:14 +0000
                  Re: is implemented with id ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-11-04 03:10 +0000
                    Re: is implemented with id ? Chris Angelico <rosuav@gmail.com> - 2012-11-04 14:19 +1100
                      Re: is implemented with id ? aahz@pythoncraft.com (Aahz) - 2012-11-03 22:09 -0700
                        Re: is implemented with id ? Hans Mulder <hansmu@xs4all.nl> - 2012-11-04 11:13 +0100
                Re: is implemented with id ? Chris Angelico <rosuav@gmail.com> - 2012-11-04 12:22 +1100
                Re: is implemented with id ? aahz@pythoncraft.com (Aahz) - 2012-11-03 22:08 -0700
              Re: is implemented with id ? Roy Smith <roy@panix.com> - 2012-11-03 18:41 -0400
              Re: is implemented with id ? aahz@pythoncraft.com (Aahz) - 2012-11-03 22:12 -0700
        Re: is implemented with id ? Dave Angel <d@davea.name> - 2012-09-05 10:00 -0400
          Re: is implemented with id ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-05 14:41 +0000
            Re: is implemented with id ? Dave Angel <d@davea.name> - 2012-09-05 11:09 -0400
              Re: is implemented with id ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-05 15:36 +0000
              Re: is implemented with id ? Hans Mulder <hansmu@xs4all.nl> - 2012-09-05 18:47 +0200
                Re: is implemented with id ? Dave Angel <d@davea.name> - 2012-09-05 13:19 -0400
            Re: is implemented with id ? Terry Reedy <tjreedy@udel.edu> - 2012-09-05 14:31 -0400
            Re: is implemented with id ? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-09-05 22:08 -0400
            Re: is implemented with id ? Duncan Booth <duncan.booth@invalid.invalid> - 2012-09-06 09:34 +0000
              Re: is implemented with id ? Chris Angelico <rosuav@gmail.com> - 2012-09-06 19:50 +1000
            Re: is implemented with id ? 88888 Dihedral <dihedral88888@googlemail.com> - 2012-11-04 01:33 -0700
    Re: is implemented with id ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-05 09:14 +0000
      Re: is implemented with id ? Ramchandra Apte <maniandram01@gmail.com> - 2012-09-05 05:48 -0700
        Re: is implemented with id ? Dave Angel <d@davea.name> - 2012-09-05 09:46 -0400
        Re: is implemented with id ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-05 14:13 +0000
          Re: is implemented with id ? Ian Kelly <ian.g.kelly@gmail.com> - 2012-09-05 11:08 -0600
          Re: is implemented with id ? Chris Angelico <rosuav@gmail.com> - 2012-09-06 19:07 +1000
        Re: is implemented with id ? Terry Reedy <tjreedy@udel.edu> - 2012-09-05 14:27 -0400
          Re: is implemented with id ? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-09-06 06:44 +0000
            Re: is implemented with id ? Ramchandra Apte <maniandram01@gmail.com> - 2012-09-06 01:24 -0700
            Re: is implemented with id ? Roy Smith <roy@panix.com> - 2012-09-06 08:16 -0400
              Re: is implemented with id ? Ramchandra Apte <maniandram01@gmail.com> - 2012-09-06 06:30 -0700
        Re: is implemented with id ? Dave Angel <d@davea.name> - 2012-09-05 14:40 -0400

Page 2 of 2 — ← Prev page 1 [2]

#28509

On Wed, 05 Sep 2012 11:09:30 -0400, Dave Angel wrote:

> On 09/05/2012 10:41 AM, Steven D'Aprano wrote:
[...]
>> So, for current day computers at least, it is reasonable to say that "a
>> is b" implies that a and b are the same object at a single location.
> 
> You're arguing against something i didn't say. I only said that id()
> doesn't promise to be a memory address.  i said nothing about what it
> might mean if the "is" operator considers them the same.

I'm not arguing at all. I'm agreeing with you, but going into more detail.


>> The second half of the question is more complex:
>>
>> "id(a) == id(b)" *only* implies that a and b are the same object at the
>> same location if they exist at the same time. If they don't exist at
>> the same time, then you can't conclude anything.
>>
>>
> But by claiming that id() really means address,

I didn't actually say that. If you re-read Franck Ditter's previous post, 
he doesn't actually say that either.


> and that those addresses
> might move during the lifetime of an object, then the fact that the id()
> functions are not called simultaneously implies that one object might
> move to where the other one used to be before the "move."

Well, yes, but I expect that implementations where objects can move will 
not use memory addresses as IDs. They will do what Jython and IronPython 
do and use arbitrary numbers as IDs.

(Oh how I wish CPython hadn't used memory addresses as IDs.)


> I don't claim to know the jython implementation.  But you're claiming
> that id() means the address of the object, even in jython.

Good god no! I'm saying that, *if* a and b exist at the same time, *and* 
if id(a) == id(b), *then* a and b must be the same object and therefore 
at the same address. That doesn't mean that the ID is the address!


> I think it much more likely that jython uses integer values for the id()
> function, and not physical addresses.

That's exactly what it does. It appears to be a simple counter: each time 
you ask for an object's ID, it gets allocated the next value starting 
from 1, and values are never re-used.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#28525

On 5/09/12 17:09:30, Dave Angel wrote:
> But by claiming that id() really means address, and that those addresses
> might move during the lifetime of an object, then the fact that the id()
> functions are not called simultaneously implies that one object might
> move to where the other one used to be before the "move."

Whoa!  Not so fast!  The id() of an object is guaranteed to not
change during the object's lifetime.  So if an implementation
moves objects around (e.g. Jython), then it cannot use memory
addresses for the id() function.

> I think it much more likely that jython uses integer values for
> the id() function, and not physical addresses.

The id() function is guaranteed to return some flavour of integer.

In Jython, the return values are 1, 2, 3, 4, etc., except, of course,
if you invoke id() on an object you've id'd before, you get the same
number as before.

In current versions of CPython, you do get the (virtual) memory
address, converted to an int (or a long).  But then, CPython does
not move objects.

Maybe the next version of CPython should shift id values two or three
bits to the right, just to make sure people don't misinterpret ids as
memory addresses.


Hope this helps,

-- HansM

[toc] | [prev] | [next] | [standalone]

#28528

On 09/05/2012 12:47 PM, Hans Mulder wrote:
> On 5/09/12 17:09:30, Dave Angel wrote:
>> But by claiming that id() really means address, and that those addresses
>> might move during the lifetime of an object, then the fact that the id()
>> functions are not called simultaneously implies that one object might
>> move to where the other one used to be before the "move."
> Whoa!  Not so fast!  The id() of an object is guaranteed to not
> change during the object's lifetime.  So if an implementation
> moves objects around (e.g. Jython), then it cannot use memory
> addresses for the id() function.
Which is equivalent to my point.  I had mistakenly thought that Steven
was claiming it was always an address, and disproving that claim by what
amounts to reductio ad absurdem.

>> I think it much more likely that jython uses integer values for
>> the id() function, and not physical addresses.
> The id() function is guaranteed to return some flavour of integer.
>
> In Jython, the return values are 1, 2, 3, 4, etc., except, of course,
> if you invoke id() on an object you've id'd before, you get the same
> number as before.
>
> In current versions of CPython, you do get the (virtual) memory
> address, converted to an int (or a long).  But then, CPython does
> not move objects.
>
> Maybe the next version of CPython should shift id values two or three
> bits to the right, just to make sure people don't misinterpret ids as
> memory addresses.
>
>

I think i'd prefer if it would put it through one step of a CRC32.

-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#28536

On 9/5/2012 10:41 AM, Steven D'Aprano wrote:

> True. In principle, some day there might be a version of Python that runs
> on some exotic quantum computer where the very concept of "physical
> address" is meaningless.

You mean like the human brain? When people execute Python code, does 0 
have an address?

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#28547

On Wed, 05 Sep 2012 14:31:08 -0400, Terry Reedy <tjreedy@udel.edu>
declaimed the following in gmane.comp.python.general:

> On 9/5/2012 10:41 AM, Steven D'Aprano wrote:
> 
> > True. In principle, some day there might be a version of Python that runs
> > on some exotic quantum computer where the very concept of "physical
> > address" is meaningless.
> 
> You mean like the human brain? When people execute Python code, does 0 
> have an address?

	I suspect some day in the future various CAT and similar scanners
will be able to capture the entire brain (3D) in real-time, at which
point a statistical analysis of many people will be able to assign a 3D
Cartesian coordinate to the main activity associated with the concept of
0 (of course, we'll have to differentiate the concept of the glyph 0
from the concept of the quantity/number zero from the word zero...)
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#28564

Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> But less exotically, Frank isn't entirely wrong. With current day 
> computers, it is reasonable to say that any object has exactly one 
> physical location at any time. In Jython, objects can move around; in 
> CPython, they can't. But at any moment, any object has a specific 
> location, and no other object can have that same location. Two objects 
> cannot both be at the same memory address at the same time.
> 

It is however perfectly possible for one object to be at two or more memory 
addresses at the same time.

In fact some work being done in PyPy right now is doing exactly that as 
part of Armin Rigo's software transactional memory implementation: when a 
global object is mutated a new copy is made and some threads may see the 
new version while other threads continue to see the old version until their 
transactions are comitted (or aborted). This means that global objects can 
be safely read from multiple threads without any semaphore locking.

See http://mail.python.org/pipermail/pypy-dev/2012-September/010513.html

-- 
Duncan Booth http://kupuguy.blogspot.com

[toc] | [prev] | [next] | [standalone]

#28565

On Thu, Sep 6, 2012 at 7:34 PM, Duncan Booth
<duncan.booth@invalid.invalid> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
>
>> But at any moment, any object has a specific
>> location, and no other object can have that same location. Two objects
>> cannot both be at the same memory address at the same time.
>>
>
> It is however perfectly possible for one object to be at two or more memory
> addresses at the same time.

And of course, memory addresses have to be taken as per-process, since
it's entirely possible for two processes to reuse addresses. But I
think all these considerations of object identity are made with the
assumption that we're working within a single Python process.

ChrisA

[toc] | [prev] | [next] | [standalone]

#32723

On Wednesday, September 5, 2012 10:41:19 PM UTC+8, Steven D'Aprano wrote:
> On Wed, 05 Sep 2012 10:00:09 -0400, Dave Angel wrote:
> 
> 
> 
> > On 09/05/2012 09:19 AM, Franck Ditter wrote:
> 
> >> Thanks to all, but :
> 
> >> - I should have said that I work with Python 3. Does that matter ? -
> 
> >> May I reformulate the queston : "a is b" and "id(a) == id(b)"
> 
> >>   both mean : "a et b share the same physical address". Is that True ?
> 
> >> Thanks,
> 
> > 
> 
> > No, id() has nothing to do with physical address.  The Python language
> 
> > does not specify anything about physical addresses.  Some
> 
> > implementations may happen to use physical addresses, others arbitrary
> 
> > integers.  And they may reuse such integers, or not.  Up to the
> 
> > implementation.
> 
> 
> 
> True. In principle, some day there might be a version of Python that runs 
> 
> on some exotic quantum computer where the very concept of "physical 
> 
> address" is meaningless. Or some sort of peptide or DNA computer, where 
> 
> the calculations are performed via molecular interactions rather than by 
> 
> flipping bits in fixed memory locations.
> 
> 
> 
> But less exotically, Frank isn't entirely wrong. With current day 
> 
> computers, it is reasonable to say that any object has exactly one 
> 
> physical location at any time. In Jython, objects can move around; in 
> 
> CPython, they can't. But at any moment, any object has a specific 
> 
> location, and no other object can have that same location. Two objects 
> 
> cannot both be at the same memory address at the same time.
> 
> 
> 
> So, for current day computers at least, it is reasonable to say that 
> 
> "a is b" implies that a and b are the same object at a single location.
> 
> 
> 
> The second half of the question is more complex:
> 
> 
> 
> "id(a) == id(b)" *only* implies that a and b are the same object at the 
> 
> same location if they exist at the same time. If they don't exist at the 
> 
> same time, then you can't conclude anything.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven
The function id(x) might not be implemented 
as an address in the user space. 

Do we need to distinguish archived objets and 
objects in the memory?

[toc] | [prev] | [next] | [standalone]

#28470

On Wed, 05 Sep 2012 08:30:31 +0200, Franck Ditter wrote:

> Hi !
> a is b <==> id(a) == id(b) in builtin classes. Is that true ?

Not just for builtin classes, for any objects, provided that they are 
alive at the same time.

There is no guarantee whether IDs will be re-used. Some versions of 
Python do re-use IDs, e.g. CPython:

steve@runes:~$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> a = ["some", "object"]
>>> id(a)
3074285228L
>>> del a
>>> b = [100, 200]
>>> id(b)
3074285228L

but others do not, e.g. Jython and IronPython:

steve@runes:~$ jython
Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19) 
[OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
Type "help", "copyright", "credits" or "license" for more information.
>>> a = ["some", "object"]
>>> id(a)
1
>>> del a
>>> b = [100, 200]
>>> id(b)
2


steve@runes:~$ ipy
IronPython 2.6 Beta 2 DEBUG (2.6.0.20) on .NET 2.0.50727.1433
Type "help", "copyright", "credits" or "license" for more information.
>>> a = ["some", "object"]
>>> id(a)
43
>>> del a
>>> b = [100, 200]
>>> id(b)
44


CPython especially has the most complicated behaviour with IDs and object 
identity: 

>>> a = 99.99
>>> b = 99.99
>>> a is b
False
>>> a = 99.99; b = 99.99; a is b 
True


In general, you almost never need to care about IDs and object identity. 
The main exception is testing for None, which should always be written as:

    if x is None


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#28480

On Wednesday, 5 September 2012 14:44:23 UTC+5:30, Steven D'Aprano  wrote:
> On Wed, 05 Sep 2012 08:30:31 +0200, Franck Ditter wrote:
> 
> 
> 
> > Hi !
> 
> > a is b <==> id(a) == id(b) in builtin classes. Is that true ?
> 
> 
> 
> Not just for builtin classes, for any objects, provided that they are 
> 

Seeing this thread, I think the is statment should be removed.
It has a replacement syntax of id(x) == id(y) and "a==True" should be automatically changed into memory comparison.
> alive at the same time.
> 
> 
> 
> There is no guarantee whether IDs will be re-used. Some versions of 
> 
> Python do re-use IDs, e.g. CPython:
> 
> 
> 
> steve@runes:~$ python
> 
> Python 2.6.6 (r266:84292, Dec 27 2010, 00:02:40) 
> 
> [GCC 4.4.5] on linux2
> 
> Type "help", "copyright", "credits" or "license" for more information.
> 
> >>> a = ["some", "object"]
> 
> >>> id(a)
> 
> 3074285228L
> 
> >>> del a
> 
> >>> b = [100, 200]
> 
> >>> id(b)
> 
> 3074285228L
> 
> 
> 
> but others do not, e.g. Jython and IronPython:
> 
> 
> 
> steve@runes:~$ jython
> 
> Jython 2.5.1+ (Release_2_5_1, Aug 4 2010, 07:18:19) 
> 
> [OpenJDK Client VM (Sun Microsystems Inc.)] on java1.6.0_18
> 
> Type "help", "copyright", "credits" or "license" for more information.
> 
> >>> a = ["some", "object"]
> 
> >>> id(a)
> 
> 1
> 
> >>> del a
> 
> >>> b = [100, 200]
> 
> >>> id(b)
> 
> 2
> 
> 
> 
> 
> 
> steve@runes:~$ ipy
> 
> IronPython 2.6 Beta 2 DEBUG (2.6.0.20) on .NET 2.0.50727.1433
> 
> Type "help", "copyright", "credits" or "license" for more information.
> 
> >>> a = ["some", "object"]
> 
> >>> id(a)
> 
> 43
> 
> >>> del a
> 
> >>> b = [100, 200]
> 
> >>> id(b)
> 
> 44
> 
> 
> 
> 
> 
> CPython especially has the most complicated behaviour with IDs and object 
> 
> identity: 
> 
> 
> 
> >>> a = 99.99
> 
> >>> b = 99.99
> 
> >>> a is b
> 
> False
> 
> >>> a = 99.99; b = 99.99; a is b 
> 
> True
> 
> 
> 
> 
> 
> In general, you almost never need to care about IDs and object identity. 
> 
> The main exception is testing for None, which should always be written as:
> 
> 
> 
>     if x is None
> 
> 
> 
> 
> 
> -- 
> 
> Steven

[toc] | [prev] | [next] | [standalone]

#28494

On 09/05/2012 08:48 AM, Ramchandra Apte wrote:
> On Wednesday, 5 September 2012 14:44:23 UTC+5:30, Steven D'Aprano  wrote:
>> <snip> 
>>
> Seeing this thread, I think the is statment should be removed.
> It has a replacement syntax of id(x) == id(y) and "a==True" should be automatically changed into memory comparison.

You didn't read the whole message carefully enough.  Id's can be reused,
so there are many ways to mess up comparing id's.  One is if the two
items x and y are expressions (eg. function calls).  You call a
function, and say it returns a new object, you call id() on that object,
and then the object gets discarded.  You now have a stale id, and you
haven't even evaluated the second expression yet.

It's id() which is superfluous.  But it's useful for debugging, and for
understanding.



-- 

DaveA

[toc] | [prev] | [next] | [standalone]

#28498

On Wed, 05 Sep 2012 05:48:26 -0700, Ramchandra Apte wrote:

> Seeing this thread, I think the is statment should be removed. It has a
> replacement syntax of id(x) == id(y)

A terrible idea.

Because "is" is a keyword, it is implemented as a fast object comparison 
directly in C (for CPython) or Java (for Jython). In the C implementation 
"x is y" is *extremely* fast because it is just a pointer comparison 
performed directly by the interpreter.

Because id() is a function, it is much slower. And because it is not a 
keyword, Python needs to do a name look-up for it, then push the argument 
on the stack, call the function (which may not even be the built-in id() 
any more!) and then pop back to the caller.

And worst, *it doesn't even do what you think it does*. In some Python 
implementations, IDs can be reused. That leads to code like this, from 
CPython 2.7:

py> id("spam ham"[1:]) == id("foo bar"[1:])
True

You *cannot* replace is with id() except when the objects are guaranteed 
to both be alive at the same time, and even then you *shouldn't* replace 
is with id() because that is a pessimation (the opposite of an 
optimization -- something that makes code run slower, not faster).


> and "a==True" should be automatically changed into memory comparison.

Absolutely not. That would be a backward-incompatible change that would 
break existing programs:

py> 1.0 == True
True
py> from decimal import Decimal
py> Decimal("1.0000") == True
True



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#28526

On Wed, Sep 5, 2012 at 8:13 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> You *cannot* replace is with id() except when the objects are guaranteed
> to both be alive at the same time, and even then you *shouldn't* replace
> is with id() because that is a pessimation (the opposite of an
> optimization -- something that makes code run slower, not faster).

Shouldn't that be "pessimization" for symmetry?

[toc] | [prev] | [next] | [standalone]

#28561

On Thu, Sep 6, 2012 at 6:26 PM, Ramchandra Apte <maniandram01@gmail.com> wrote:
> the is statement could be made into a function

It's not a statement, it's an operator; and functions have far more
overhead than direct operators. There's little benefit in making 'is'
into a function, and high cost; unlike 'print', whose cost is
dominated by the cost of producing output to a console or similar
device, 'is' would be dominated by the cost of name lookups and
function call overhead.

ChrisA

[toc] | [prev] | [next] | [standalone]

#28535

On 9/5/2012 8:48 AM, Ramchandra Apte wrote:

> Seeing this thread, I think the is statment should be removed.
> It has a replacement syntax of id(x) == id(y)

The thread is wrong then.

If the implementation reuses ids, which CPython does,
<expression-1> is <expression-2>
must be implemented as

internal-tem1 = <expression-1>
internal-tem2 = <expression-2>
id(internal-tem1) == id(internal-tem2)

in order to ensure that the two objects exist simultaneously,
so that the id comparison is valid.

 > and "a==True" should be automatically changed into memory comparison.

I have no idea what that means.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#28554

On Wed, 05 Sep 2012 14:27:44 -0400, Terry Reedy wrote:

> On 9/5/2012 8:48 AM, Ramchandra Apte wrote:
> 
>  > and "a==True" should be automatically changed into memory comparison.
> 
> I have no idea what that means.

I interpret this as meaning that "a == True" should be special-cased by 
the interpreter as "a is True" instead of calling a.__eq__.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#28555

On Thursday, 6 September 2012 12:14:19 UTC+5:30, Steven D'Aprano  wrote:
> On Wed, 05 Sep 2012 14:27:44 -0400, Terry Reedy wrote:
> 
> 
> 
> > On 9/5/2012 8:48 AM, Ramchandra Apte wrote:
> 
> > 
> 
> >  > and "a==True" should be automatically changed into memory comparison.
> 
> > 
> 
> > I have no idea what that means.
> 
> 
> 
> I interpret this as meaning that "a == True" should be special-cased by 
> 
> the interpreter as "a is True" instead of calling a.__eq__.
> 
> 
> 
> 
> 
> 
> 
> -- 
> 
> Steven

Steven you are right.

[toc] | [prev] | [next] | [standalone]

#28583

In article <50484643$0$29977$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Wed, 05 Sep 2012 14:27:44 -0400, Terry Reedy wrote:
> 
> > On 9/5/2012 8:48 AM, Ramchandra Apte wrote:
> > 
> >  > and "a==True" should be automatically changed into memory comparison.
> > 
> > I have no idea what that means.
> 
> I interpret this as meaning that "a == True" should be special-cased by 
> the interpreter as "a is True" instead of calling a.__eq__.

That would break classes which provide their own __eq__() method.

[toc] | [prev] | [next] | [standalone]

#28588

On Thursday, 6 September 2012 17:46:38 UTC+5:30, Roy Smith  wrote:
> In article <50484643$0$29977$c3e8da3$5496439d@news.astraweb.com>,
> 
>  Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> 
> 
> 
> > On Wed, 05 Sep 2012 14:27:44 -0400, Terry Reedy wrote:
> 
> > 
> 
> > > On 9/5/2012 8:48 AM, Ramchandra Apte wrote:
> 
> > > 
> 
> > >  > and "a==True" should be automatically changed into memory comparison.
> 
> > > 
> 
> > > I have no idea what that means.
> 
> > 
> 
> > I interpret this as meaning that "a == True" should be special-cased by 
> 
> > the interpreter as "a is True" instead of calling a.__eq__.
> 
> 
> 
> That would break classes which provide their own __eq__() method.

There is a way of doing this: make True.__req__ = lambda other: self is other

[toc] | [prev] | [next] | [standalone]

#28537

On 09/05/2012 02:27 PM, Terry Reedy wrote:
> On 9/5/2012 8:48 AM, Ramchandra Apte wrote:
>
>> Seeing this thread, I think the is statment should be removed.
>> It has a replacement syntax of id(x) == id(y)
>
> The thread is wrong then.
>
> If the implementation reuses ids, which CPython does,
> <expression-1> is <expression-2>
> must be implemented as
>
> internal-tem1 = <expression-1>
> internal-tem2 = <expression-2>
> id(internal-tem1) == id(internal-tem2)
>
> in order to ensure that the two objects exist simultaneously,
> so that the id comparison is valid.
>
> > and "a==True" should be automatically changed into memory comparison.
>
> I have no idea what that means.
>

It's probably a response to Steve's comment

"""

In general, you almost never need to care about IDs and object identity. 
The main exception is testing for None, which should always be written as:

    if x is None
"""

 Somehow he substituted True for None.  Anyway, if one eliminates "is"
then Steve's comment wouldn't apply.

-- 

DaveA

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web