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

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

Reference

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

Contents

  Reference "ast" <nomail@invalid.com> - 2014-03-03 10:42 +0100
    Object identity (was: Reference) Ben Finney <ben+python@benfinney.id.au> - 2014-03-03 21:00 +1100
      Re: Object identity (was: Reference) "ast" <nomail@invalid.com> - 2014-03-03 11:21 +0100
    Re: Reference "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-03 05:09 -0800
    Re: Reference Grant Edwards <invalid@invalid.invalid> - 2014-03-03 14:29 +0000
    Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-03 07:52 -0800
      Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 08:10 +1100
      Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-03 15:24 -0600
      Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 08:31 +1100
      Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-03 21:35 +0000
        Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 00:07 +0200
          Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 09:18 +1100
            Re: Reference Alister <alister.ware@ntlworld.com> - 2014-03-04 11:10 +0000
              Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 11:48 +0000
                Re: Reference "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-05 00:25 +0000
      Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-03 15:51 -0600
      Re: Reference Jerry Hill <malaclypse2@gmail.com> - 2014-03-03 17:02 -0500
        Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-04 00:22 +0200
          Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-04 09:27 +1100
          Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 09:33 +1100
          Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-04 04:52 +0000
            Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-04 16:24 +1100
              Re: Reference "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-05 01:08 +0000
                Re: Reference Roy Smith <roy@panix.com> - 2014-03-04 21:09 -0500
                  Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 19:36 -0800
                    Re: Reference Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-04 21:08 -0700
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 20:31 -0800
                    Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 15:32 +1100
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 20:47 -0800
                    Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-05 05:06 +0000
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 21:47 -0800
                        Re: Reference alex23 <wuwei23@gmail.com> - 2014-03-05 16:01 +1000
                          Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 22:10 -0800
                            Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 17:22 +1100
                            Re: Reference alex23 <wuwei23@gmail.com> - 2014-03-05 16:28 +1000
                              Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 12:24 +0000
                            Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 12:21 +0000
                        Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 17:20 +1100
                          Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-05 09:40 -0800
                            Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-05 12:12 -0600
                            Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 05:33 +1100
                        Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-05 18:19 +0000
                          Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 22:23 +0200
                            Re: Reference Grant Edwards <invalid@invalid.invalid> - 2014-03-05 20:31 +0000
                              Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 22:46 +0200
                                Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 08:07 +1100
                                Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 08:10 +1100
                                Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 21:34 +0000
                                Re: Reference Terry Reedy <tjreedy@udel.edu> - 2014-03-05 18:00 -0500
                            Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-06 03:01 +0000
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 22:03 -0800
                        Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 17:26 +1100
                        Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 17:32 +1100
                        Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-05 08:24 -0600
                        Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-05 18:29 +0000
                          Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 22:34 +0200
                            Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 08:01 +1100
                              Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 23:14 +0200
                                Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-06 08:26 +1100
                                  Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 23:50 +0200
                                  Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-06 00:35 +0000
                                    Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-06 11:50 +1100
                                    Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-06 17:46 +0000
                                Re: Reference Tim Chase <python.list@tim.thechases.com> - 2014-03-05 15:33 -0600
                                Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 08:37 +1100
                                  Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-06 02:52 +0200
                                    Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-06 12:05 +1100
                                    Re: Reference alex23 <wuwei23@gmail.com> - 2014-03-06 12:12 +1000
                                Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 21:46 +0000
                    Re: Reference Marko Rauhamaa <marko@pacujo.net> - 2014-03-05 08:23 +0200
                      Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 22:33 -0800
                        Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-05 17:40 +1100
                      Re: Reference Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-05 12:35 +0000
                      Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 23:45 +1100
            Re: Reference Jerry Hill <malaclypse2@gmail.com> - 2014-03-04 10:19 -0500
              Re: Reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-04 15:42 +0000
                Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 03:02 +1100
                  Re: Reference Roy Smith <roy@panix.com> - 2014-03-04 11:14 -0500
                Re: Reference MRAB <python@mrabarnett.plus.com> - 2014-03-04 17:12 +0000
              Re: Reference Rustom Mody <rustompmody@gmail.com> - 2014-03-04 08:24 -0800
            Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 02:25 +1100
            Re: Reference Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-05 14:37 +0100
        Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-04 03:59 +0000
      Re: Reference Ben Finney <ben+python@benfinney.id.au> - 2014-03-04 09:17 +1100
        Re: Reference Roy Smith <roy@panix.com> - 2014-03-03 18:02 -0500
          Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-04 10:09 +1100
          Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-04 04:38 +0000
    Re: Reference Terry Reedy <tjreedy@udel.edu> - 2014-03-03 13:48 -0500
      Re: Reference Steven D'Aprano <steve@pearwood.info> - 2014-03-04 03:45 +0000
      Re: Reference Alexander Blinne <news@blinne.net> - 2014-03-04 13:55 +0100
        Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 01:06 +1100
          Re: Reference Alexander Blinne <news@blinne.net> - 2014-03-04 22:53 +0100
            Re: Reference Chris Angelico <rosuav@gmail.com> - 2014-03-05 09:01 +1100

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#67899

On Thu, 06 Mar 2014 08:26:22 +1100, Chris Angelico wrote:

> On Thu, Mar 6, 2014 at 8:14 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> When I talk about an object's memory address, I'm not referring to what
>> might be revealed by gdb, for example. That is, I'm not talking about
>> the process's virtual address space, nor am I talking about the
>> physical address on the address bus. I can simply define that the
>> object's memory address is whatever id() returns.
> 
> Where's the complaints about circularity now? You're saying "But of
> course id() returns the address, as long as we define the address as
> 'whatever id() returns'.". Unimpeachably logical and utterly unhelpful.

That last sentence is wrong. There is nothing logical about just making 
up arbitrary definitions in this way. He could invent *any* definition, 
each more ridiculous than the last:

- it's the object's memory address;

- it's the object's phone number;

- it's the number of baby elephants killed by the object;

- it's the number of intergalactic empires that are, even as we 
  speak, rushing to Earth to invade to gain possession of that
  object;

- it's the weight in metric tonnes of the electrons in the object;

  (Not *actual* electrons of course, just these arbitrary inventions 
  of Marko's definition.)

- it's the length measured in seconds of the bitterness of the 
  object's kidney;


and of course:

- the number of angels that can dance on the object.




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#67901

On Thu, Mar 6, 2014 at 11:35 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 06 Mar 2014 08:26:22 +1100, Chris Angelico wrote:
>
>> Where's the complaints about circularity now? You're saying "But of
>> course id() returns the address, as long as we define the address as
>> 'whatever id() returns'.". Unimpeachably logical and utterly unhelpful.
>
> That last sentence is wrong. There is nothing logical about just making
> up arbitrary definitions in this way. He could invent *any* definition,
> each more ridiculous than the last:

I mean logical in the sense of pure logic.

If all spam is edible-food
And if this-can is spam
Then this-can is edible-food

The opening premise is false (I wouldn't want to eat a punctured can
that's been sitting around for a few months), but it's still perfectly
logical. The conclusion is guaranteed to be true as long as the
premises are.

In that sense of the word, the statement is indeed logical. That
doesn't stop it from being wrong, but it is logical.

If the 'is' comparison is reflexive,
And if three is four,
Then four is three.

Perfectly logical.

He's saying that the address of an object is simply "whatever id()
returns for that object". Since Python doesn't currently have any
other concept of object addresses, that definition isn't in conflict
with anything. Then he says, look! the id() function returns the
object's address. Well, duh, that's how you defined the address. It's
logical. Of course it returns "the address", since "the address" has
been defined as what it returns. But it doesn't achieve anything to
prove that.

ChrisA

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

#67946

On 06/03/2014 00:35, Steven D'Aprano wrote:
> On Thu, 06 Mar 2014 08:26:22 +1100, Chris Angelico wrote:
>
>> On Thu, Mar 6, 2014 at 8:14 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> When I talk about an object's memory address, I'm not referring to what
>>> might be revealed by gdb, for example. That is, I'm not talking about
>>> the process's virtual address space, nor am I talking about the
>>> physical address on the address bus. I can simply define that the
>>> object's memory address is whatever id() returns.
>>
>> Where's the complaints about circularity now? You're saying "But of
>> course id() returns the address, as long as we define the address as
>> 'whatever id() returns'.". Unimpeachably logical and utterly unhelpful.
>
> That last sentence is wrong. There is nothing logical about just making
> up arbitrary definitions in this way. He could invent *any* definition,
> each more ridiculous than the last:
>
> - it's the object's memory address;
>
> - it's the object's phone number;
>
> - it's the number of baby elephants killed by the object;
>
> - it's the number of intergalactic empires that are, even as we
>    speak, rushing to Earth to invade to gain possession of that
>    object;
>
> - it's the weight in metric tonnes of the electrons in the object;
>
>    (Not *actual* electrons of course, just these arbitrary inventions
>    of Marko's definition.)
>
> - it's the length measured in seconds of the bitterness of the
>    object's kidney;
>
>
> and of course:
>
> - the number of angels that can dance on the object.
>

You've missed the most obvious one, the number of words written on this 
mailing list about Python that are completely wrong.  That number is far 
larger than the sum of all your definitions given above, where sum has 
the usual maths definition and not Marko's.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#67883

On 2014-03-05 23:14, Marko Rauhamaa wrote:
> When I talk about an object's memory address, I'm not referring to
> what might be revealed by gdb, for example. That is, I'm not
> talking about the process's virtual address space, nor am I talking
> about the physical address on the address bus. I can simply define
> that the object's memory address is whatever id() returns.

Let me translate what the rest of the group hears:

"""
When I talk about an object's memory address, I'm not referring to
*what every other computer scientist/professional means by "memory
address" rather I can simply make up my own definition for "memory
address" so that it means something that proves my point.*
"""

It's perfectly valid for the definition of id() to return negative
numbers, yet in just about every situation (both hypothetical CS
worlds and out in the real world), a memory-address is defined as an
unsigned number.

-tkc

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

#67885

Marko Rauhamaa <marko@pacujo.net> writes:

> Ben Finney <ben+python@benfinney.id.au>:
>
> > A reference-compliant implementation can contradict your inference (by
> > returning an object identity that is *not* the object's memory
> > address). Any code you've written based on that false inference will
> > break.
> >
> > The fault will be yours, for inferring an assertion that isn't implied
> > by the definition.
>
> Show me a few lines of Python that demonstrate the error of the false
> inference, please.

It need not be Python; it could be an extension library to which you
pass the ‘id(foo)’ result, on the false assumption that it must be a
memory location.

Besides which, it is *you* that declares this abstraction to be leaky.
If you're unable to show how that's the case, I rest on the null
hypothesis: your assertion is untrue.

> When I talk about an object's memory address, I'm not referring to
> what might be revealed by gdb, for example. That is, I'm not talking
> about the process's virtual address space, nor am I talking about the
> physical address on the address bus. I can simply define that the
> object's memory address is whatever id() returns.

Then this does not count as a leaky abstraction. All you're saying is
that the ‘id(foo)’ result is a representation of the object identity,
which is entirely at the level of the abstraction. Nothing is leaked.

-- 
 \      “God forbid that any book should be banned. The practice is as |
  `\                  indefensible as infanticide.” —Dame Rebecca West |
_o__)                                                                  |
Ben Finney

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

#67902

Ben Finney <ben+python@benfinney.id.au>:

> Marko Rauhamaa <marko@pacujo.net> writes:
>> When I talk about an object's memory address, I'm not referring to
>> what might be revealed by gdb, for example. That is, I'm not talking
>> about the process's virtual address space, nor am I talking about the
>> physical address on the address bus. I can simply define that the
>> object's memory address is whatever id() returns.
>
> Then this does not count as a leaky abstraction. All you're saying is
> that the ‘id(foo)’ result is a representation of the object identity,
> which is entirely at the level of the abstraction. Nothing is leaked.

I wasn't making a point about a leaky abstraction.

I was just saying talking about id() as a memory address isn't all that
bad. It's a bit like rolling down your power windows or turning up the
volume, when there's nothing to roll or turn. There's no risk of getting
your program wrong.


Marko

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

#67903

Marko Rauhamaa <marko@pacujo.net> writes:

> Ben Finney <ben+python@benfinney.id.au>:
>
> > Then this does not count as a leaky abstraction. All you're saying is
> > that the ‘id(foo)’ result is a representation of the object identity,
> > which is entirely at the level of the abstraction. Nothing is leaked.
>
> I wasn't making a point about a leaky abstraction.

Can we conclude that you've changed your position on this, then? You now
accept that Python's object identity abstraction is not leaky?

In the absence of you demonstrating a leak in that abstraction, we can
ignore the assertion.

-- 
 \     “For myself, I am an optimist — it does not seem to be much use |
  `\              being anything else.” —Winston Churchill, 1954-11-09 |
_o__)                                                                  |
Ben Finney

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

#67909

On 6/03/2014 10:52 AM, Marko Rauhamaa wrote:
> I was just saying talking about id() as a memory address isn't all that
> bad. It's a bit like rolling down your power windows or turning up the
> volume, when there's nothing to roll or turn. There's no risk of getting
> your program wrong.

Unless you're talking about, say, the PyPy implementation, for which id 
is _not_ a memory address at all.

Why insist on using "memory address" rather than "unique identifier", 
when the latter is fundamentally more correct?

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

#67887

On 05/03/2014 21:33, Tim Chase wrote:
> On 2014-03-05 23:14, Marko Rauhamaa wrote:
>> When I talk about an object's memory address, I'm not referring to
>> what might be revealed by gdb, for example. That is, I'm not
>> talking about the process's virtual address space, nor am I talking
>> about the physical address on the address bus. I can simply define
>> that the object's memory address is whatever id() returns.
>
> Let me translate what the rest of the group hears:
>
> """
> When I talk about an object's memory address, I'm not referring to
> *what every other computer scientist/professional means by "memory
> address" rather I can simply make up my own definition for "memory
> address" so that it means something that proves my point.*
> """
>
> It's perfectly valid for the definition of id() to return negative
> numbers, yet in just about every situation (both hypothetical CS
> worlds and out in the real world), a memory-address is defined as an
> unsigned number.
>
> -tkc
>
>

I actually hear the spam song, except s/spam/troll/

Didn't we learn anything from the sadly still ongoing saga of our 
resident unicode expert? :(
-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#67810

Rustom Mody <rustompmody@gmail.com>:

> * ... which summarizes my objection in this thread: Python's 'is'
> leaks the machine abstraction. 'id' does it legitimately (somewhat),
> 'is' does it illegitimately

I agree that the Python data model can be exceedingly challenging to a
beginner. However, I wouldn't throw the baby away with the bathwater,
but look for ingenious ways to teach it.

The Spanish say, "Mal de muchos, consuelo de tontos." Python is hardly
alone in this mess. For example, Java's '==' operator corresponds to
Python's "is". Nobody would consider throwing Java's "==" away. Instead,
we are offered esoteric rules like:

   If the value p being boxed is true, false, a byte, a char in the
   range \u0000 to \u007f, or an int or short number between -128 and
   127, then let r1 and r2 be the results of any two boxing conversions
   of p. It is always the case that r1 == r2. <URL: http://docs.ora
   cle.com/javase/specs/jls/se5.0/html/conversions.html#5.1.7>

For Python's "==", Java offers the "equals()" method. So is it wrong in
Java to check:

   if (list.equals(null)) {

The spec says:

   For any non-null reference value x, x.equals(null) should return
   false. <URL: http://docs.oracle.com/javase/7/docs/api/java/lang/O
   bject.html#equals%28java.lang.Object%29>

So it *should* work, but why would you avoid the more natural test:

   if (list == null) {


Similarly, in Python:

   if the_list == None:

*should* work (even if there's no such stipulation in Python's reference
 material), but why wouldn't you use the more natural:

   if the_list is None:


Marko

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

#67815

On Wednesday, March 5, 2014 11:53:21 AM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :

> > * ... which summarizes my objection in this thread: Python's 'is'
> > leaks the machine abstraction. 'id' does it legitimately (somewhat),
> > 'is' does it illegitimately

> I agree that the Python data model can be exceedingly challenging to a
> beginner. However, I wouldn't throw the baby away with the bathwater,
> but look for ingenious ways to teach it.

I'm curious how you understand my position on this
You hear me as saying 'is' should go??

No I am not saying that

All I am saying is that 'is' should have (be!) a name that is not
philosophically grandiloquent bullshit but rather a name that more
accurately conveys 'machine-representation-equivalence'

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

#67817

Rustom Mody <rustompmody@gmail.com> writes:

> All I am saying is that 'is' should have (be!) a name that is not
> philosophically grandiloquent bullshit but rather a name that more
> accurately conveys 'machine-representation-equivalence'

You haven't made either case.

How is the simple abstraction of object identity characterised as
“philosophically grandiloquent bullshit”?

Why should we discard the useful abstraction of object identity as it
currently is in Python, for some different concept that you prefer
(“machine representation equivalence”, whatever that's supposed to be —
I don't care right now, only that you want something different from what
is now) and have not justified why?

-- 
 \      “The opposite of a correct statement is a false statement. But |
  `\     the opposite of a profound truth may well be another profound |
_o__)                                              truth.” —Niels Bohr |
Ben Finney

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

#67840

On 05/03/2014 06:23, Marko Rauhamaa wrote:
> Rustom Mody <rustompmody@gmail.com>:
>
>> * ... which summarizes my objection in this thread: Python's 'is'
>> leaks the machine abstraction. 'id' does it legitimately (somewhat),
>> 'is' does it illegitimately
>
> I agree that the Python data model can be exceedingly challenging to a
> beginner. However, I wouldn't throw the baby away with the bathwater,
> but look for ingenious ways to teach it.

[snip Java]

>
> Similarly, in Python:
>
>     if the_list == None:
>
> *should* work (even if there's no such stipulation in Python's reference
>   material), but why wouldn't you use the more natural:
>
>     if the_list is None:
>
>
> Marko
>

Really great thinking, test the name the_list, which strangely enough 
tells me that this beast is a list, in the same way that 
THIS_IS_A_CONSTANT is a constant, to see if it's None.  Congratulations, 
you've been promoted to captain of my dream team.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com

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

#67842

On Wed, Mar 5, 2014 at 11:35 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
>>     if the_list is None:
>>
>>
>> Marko
>>
>
> Really great thinking, test the name the_list, which strangely enough tells
> me that this beast is a list, in the same way that THIS_IS_A_CONSTANT is a
> constant, to see if it's None.  Congratulations, you've been promoted to
> captain of my dream team.

Uhh... why? What's wrong with something either being a list or being
None to indicate no list?

def foo(x, target_list=None):
    if target_list is not None: target_list = default_targets

You can't use "if target_list:" here, because that would also catch an
empty list. You need some kind of sentinel that says "there isn't a
list here".

ChrisA

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

#67688

On Mon, Mar 3, 2014 at 11:52 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> If your intention is to treat None as a singleton sentinel, not as a
> value, then you ought to use "is" to signal that intention, rather than
> using == even if you know that there won't be any false positives.

In all of the years I've been on this list, I don't think I've seen
more than one or two cases of someone deliberately treating None as a
singleton sentinel.  In most cases, they're either checking the return
value from a function or using it as a default argument to a function
to force some default behavior when no parameter is passed.  I'm
pretty sure you're going to say that the latter use is exactly where
you should us 'is' instead of '=='.  Respectfully, I disagree.

For a beginning python user, identity checking is an attractive
nuisance. The only time most beginners should use it is when comparing
to None.  But, as soon as they are taught that there are two
comparison operators, I start to see 'is' cropping up in more and more
places where they ought to use '=='.  And the problem is that
sometimes it works for them, and sometimes it doesn't.  Sure, students
eventually need to understand the difference between identity and
equality.  My problem is that by enshrining in python custom that the
only correct way to compare to None is with 'is', we have to explain
that concept way early in the teaching process.  I can't count the
number of times that a thread has completely derailed into identity vs
equality, then into interning of strings and small integers, and
suddenly the thread is 40 messages long, and no one has actually
talked about the code that was originally posted beyond that issue.
In approximately zero cases, have I seen code where 'is' versus '=='
actually made any difference, except where the 'is' is wrong.  I've
also never seen the supposedly ever-present boogie man of an object
that mistakenly compares equal to None, much less seen that object
passed to functions with None-based sentinels.

I feel like 'is' is an operator that ought to be saved for an advanced course.

Out of curiosity, do you think we should be doing truth checking with
'is'?  True and False are singletons, and it seems to me that the
justification for idenity versus equality should be just as strong
there, but I don't think I've ever seen anyone even suggest that.

-- 
Jerry

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

#67695

On Tue, 04 Mar 2014 10:19:22 -0500, Jerry Hill wrote:

> On Mon, Mar 3, 2014 at 11:52 PM, Steven D'Aprano <steve@pearwood.info>
> wrote:
>> If your intention is to treat None as a singleton sentinel, not as a
>> value, then you ought to use "is" to signal that intention, rather than
>> using == even if you know that there won't be any false positives.
> 
> In all of the years I've been on this list, I don't think I've seen more
> than one or two cases of someone deliberately treating None as a
> singleton sentinel.  In most cases, they're either checking the return
> value from a function 

Okay, that's not *precisely* a sentinel, but it's related. I don't know 
what to call that, but it's a sentinel applied to the return result 
rather than to an input parameter.


> or using it as a default argument to a function to
> force some default behavior when no parameter is passed.

I call that a sentinel. It doesn't match the Wikipedia definition of a 
sentinel, but I think that's wrong. What Wikipedia calls a sentinel, I 
would call a guard.

http://en.wikipedia.org/wiki/Sentinel_value



> I'm pretty
> sure you're going to say that the latter use is exactly where you should
> us 'is' instead of '=='.  

Yes.


> Respectfully, I disagree.
> 
> For a beginning python user, identity checking is an attractive
> nuisance. 

True. In Hypertalk, which was designed for non-coders, the "is" operator 
was a synonym for "==". Even after nearly 20 years of using Python, I 
still sometimes instinctively write "x is y" when I mean equality, 
especially the "if __name__ is __main__" idiom.


> The only time most beginners should use it is when comparing
> to None.

We're agreed on that.


> But, as soon as they are taught that there are two comparison
> operators, I start to see 'is' cropping up in more and more places where
> they ought to use '=='.  And the problem is that sometimes it works for
> them, and sometimes it doesn't.  Sure, students eventually need to
> understand the difference between identity and equality.  My problem is
> that by enshrining in python custom that the only correct way to compare
> to None is with 'is', we have to explain that concept way early in the
> teaching process.  I can't count the number of times that a thread has
> completely derailed into identity vs equality, then into interning of
> strings and small integers, and suddenly the thread is 40 messages long,
> and no one has actually talked about the code that was originally posted
> beyond that issue. 

Heh heh, welcome to the Internet.


> In approximately zero cases, have I seen code where
> 'is' versus '==' actually made any difference, except where the 'is' is
> wrong.  I've also never seen the supposedly ever-present boogie man of
> an object that mistakenly compares equal to None, much less seen that
> object passed to functions with None-based sentinels.
> 
> I feel like 'is' is an operator that ought to be saved for an advanced
> course.
> 
> Out of curiosity, do you think we should be doing truth checking with
> 'is'?  True and False are singletons, and it seems to me that the
> justification for idenity versus equality should be just as strong
> there, but I don't think I've ever seen anyone even suggest that.

Normally you shouldn't compare to True or False at all. Python duck-types 
truth-values, or to put it another way, you should normally only care 
about truthy and falsey values:

# Duck-typing is your friend
if flag: ...

# These are buggy unless you know flag is an actual bool
if flag == True: ...
if flag is True: ...

# Why convert to a canonical bool flag just to do a comparison?
if bool(flag): ...

# Not this
if bool(flag) is True:

# I never know when to stop
if bool(flag) is True is True is True is True is True is True: ...




-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#67697

On Wed, Mar 5, 2014 at 2:42 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> # I never know when to stop
> if bool(flag) is True is True is True is True is True is True: ...

The banana problem.

ChrisA

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

#67700

In article <mailman.7726.1393948954.18130.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Wed, Mar 5, 2014 at 2:42 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
> > # I never know when to stop
> > if bool(flag) is True is True is True is True is True is True: ...
> 
> The banana problem.
> 
> ChrisA

You can refactor that as:

eval(" is ".join(itertools.chain(["if bool(flag)"], [str(t) for t in 
itertools.repeat(True)])))

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

#67708

On 2014-03-04 16:02, Chris Angelico wrote:
> On Wed, Mar 5, 2014 at 2:42 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> # I never know when to stop
>> if bool(flag) is True is True is True is True is True is True: ...
>
> The banana problem.
>
Speaking of which:

The 'right' way to peel a banana
http://www.telegraph.co.uk/news/good-to-share/10664935/The-right-way-to-peel-a-banana.html

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

#67702

On Tuesday, March 4, 2014 8:49:22 PM UTC+5:30, Jerry Hill wrote:
> On Mon, Mar 3, 2014 at 11:52 PM, Steven D'Aprano wrote:
> > If your intention is to treat None as a singleton sentinel, not as a
> > value, then you ought to use "is" to signal that intention, rather than
> > using == even if you know that there won't be any false positives.

> In all of the years I've been on this list, I don't think I've seen
> more than one or two cases of someone deliberately treating None as a
> singleton sentinel.  In most cases, they're either checking the return
> value from a function or using it as a default argument to a function
> to force some default behavior when no parameter is passed.  I'm
> pretty sure you're going to say that the latter use is exactly where
> you should us 'is' instead of '=='.  Respectfully, I disagree.

> For a beginning python user, identity checking is an attractive
> nuisance. The only time most beginners should use it is when comparing
> to None.  But, as soon as they are taught that there are two
> comparison operators, I start to see 'is' cropping up in more and more
> places where they ought to use '=='.  And the problem is that
> sometimes it works for them, and sometimes it doesn't.  Sure, students
> eventually need to understand the difference between identity and
> equality.  My problem is that by enshrining in python custom that the
> only correct way to compare to None is with 'is', we have to explain
> that concept way early in the teaching process.  I can't count the
> number of times that a thread has completely derailed into identity vs
> equality, then into interning of strings and small integers, and
> suddenly the thread is 40 messages long, and no one has actually
> talked about the code that was originally posted beyond that issue.
> In approximately zero cases, have I seen code where 'is' versus '=='
> actually made any difference, except where the 'is' is wrong.  I've
> also never seen the supposedly ever-present boogie man of an object
> that mistakenly compares equal to None, much less seen that object
> passed to functions with None-based sentinels.

Beautifully put -- thanks Jerry!

> I feel like 'is' is an operator that ought to be saved for an advanced course.

+100

My choice: have an isNone function which should take care of 90%
of the cases of valid 'is' (if I got Chris' statistics right) and avoid
most of the metaphysical BS about identity

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web