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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#67642

On Tue, 04 Mar 2014 00:22:55 +0200, Marko Rauhamaa wrote:

> Jerry Hill <malaclypse2@gmail.com>:
> 
>> except for the fact that there has been 20 years of custom saying that
>> comparing to None with equality is wrong.
> 
> "if foo == None" is not wrong in any manner. It's just that if you are
> comfortable with the "is" operator and its semantics, "if foo is None"
> is slightly more natural.
> 
> You generally use "==" if more than one object could be equal. If you
> know there's only one object of the kind, you convey that knowledge by
> the use of "is" even when functionally, it doesn't matter.

I don't agree that it doesn't matter. Code, even when functionally 
equivalent, should express the intention of the programmer in as simple a 
fashion as is possible given the constraints of the task, performance, 
etc. For example, if you want to add 1 to a number, you would write:

x += 1


not:

x += (127 - 102)//(5**2)

even though you know that the two expressions are exactly equivalent. 
Even if you know that there is a peep-hole optimizer that ensures that 
the code actually compiled is "x += 1". The intention to the reader is 
important.

This is why, unless performance is *really* critical, one should normally 
write x*2 when multiplying x by 2 rather than x >> 1. (And in Python, the 
overhead means that there is no real performance benefit to using bit 
shifts instead of multiplication or division.)

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.



-- 
Steven

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

#67644

On Tue, Mar 4, 2014 at 3:52 PM, Steven D'Aprano <steve@pearwood.info> wrote:
> This is why, unless performance is *really* critical, one should normally
> write x*2 when multiplying x by 2 rather than x >> 1. (And in Python, the
> overhead means that there is no real performance benefit to using bit
> shifts instead of multiplication or division.)

In most C compilers today (C being where x << 1 would be used rather
than x * 2), the expressions would be equivalent, so you can still
express it as x * 2 and let the compiler turn that into a bit shift.
(And it's possible that "x * 5" will become "x << 2 + x", too.)
Definitely go for the expressive version unless you've actually tested
that the obscure version is faster.

(Of course, that doesn't mean the bit-shift operators should never be
used. If you're trying to pack three tiny integers into a single
larger integer, you probably want bit shifts and bitwise or, not
multiplication and addition, even though either would work.)

Code should look like its intent. Warping it around performance is
hardly ever worthwhile.

ChrisA

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

#67772

On Tue, 04 Mar 2014 05:24:03 -0000, Chris Angelico <rosuav@gmail.com>  
wrote:

> Code should look like its intent. Warping it around performance is
> hardly ever worthwhile.

That depends.  In Python, I'd agree with you; if I'm worrying about  
performance in Python, I'm worrying at the level of the algorithms I'm  
using.  In a constrained embedded C environment, which is where I spend  
most of my working life, writing your code so that the compiler chooses  
the right optimisation is critical.  Sometimes it matters a great deal to  
me that something like "x *= 5" compiles to a single ARM instruction, or  
that splitting a loop into two to avoid a conditional test will let an  
DSP's optimiser double the speed of a section of code.

-- 
Rhodri James *-* Wildebeest Herder to the Masses

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

#67774

In article <op.xb75g7ap5079vu@gnudebeest>,
 "Rhodri James" <rhodri@wildebst.org.uk> wrote:

> On Tue, 04 Mar 2014 05:24:03 -0000, Chris Angelico <rosuav@gmail.com>  
> wrote:
> 
> > Code should look like its intent. Warping it around performance is
> > hardly ever worthwhile.
> 
> That depends.  In Python, I'd agree with you; if I'm worrying about  
> performance in Python, I'm worrying at the level of the algorithms I'm  
> using.  In a constrained embedded C environment, which is where I spend  
> most of my working life, writing your code so that the compiler chooses  
> the right optimisation is critical.  Sometimes it matters a great deal to  
> me that something like "x *= 5" compiles to a single ARM instruction, or  
> that splitting a loop into two to avoid a conditional test will let an  
> DSP's optimiser double the speed of a section of code.

Yeah.  BTDT.  I've stolen the bottom three bits of a pointer for my own 
use because I know everything is 64-bit aligned so it's all zeros 
anyway.  I feel like there must be some organization I should be going 
to every month that meets in a church basement and I can get up in front 
of the room and say, "Hi, my name is Roy and I'm a C++ hacker", and have 
everybody be supportive.

I mostly live in the Python world these days, where I'm firmly in the 
camp of, "Stay away from O(n^2) and don't hit the database with 
unindexed queries, and you're probably good".  But, that's because we 
push most of the hard work off onto C and C++ code that is written by 
guys who worry about the bottom three bits.

One of those really awesome tools is haproxy.  It's just amazing how 
fast (and stable) that thing is.  It's all written in C.  Most of the if 
statements are decorated with #pragmas telling the compiler which branch 
is the most likely to be taken, so it can optimize better.  We need 
people like that down in the trenches, so the rest of us can run around 
naked in the park with flowers in our hair and not worry about the 
bottom three bits any more.

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

#67786

On Wednesday, March 5, 2014 7:39:17 AM UTC+5:30, Roy Smith wrote:
>  "Rhodri James" wrote:
> > wrote:
> > > Code should look like its intent. Warping it around performance is
> > > hardly ever worthwhile.
> > That depends.  In Python, I'd agree with you; if I'm worrying about  
> > performance in Python, I'm worrying at the level of the algorithms I'm  
> > using.  In a constrained embedded C environment, which is where I spend  
> > most of my working life, writing your code so that the compiler chooses  
> > the right optimisation is critical.  Sometimes it matters a great deal to  
> > me that something like "x *= 5" compiles to a single ARM instruction, or  
> > that splitting a loop into two to avoid a conditional test will let an  
> > DSP's optimiser double the speed of a section of code.

> Yeah.  BTDT.  I've stolen the bottom three bits of a pointer for my own 
> use because I know everything is 64-bit aligned so it's all zeros 
> anyway.  I feel like there must be some organization I should be going 
> to every month that meets in a church basement and I can get up in front 
> of the room and say, "Hi, my name is Roy and I'm a C++ hacker", and have 
> everybody be supportive.

> I mostly live in the Python world these days, where I'm firmly in the 
> camp of, "Stay away from O(n^2) and don't hit the database with 
> unindexed queries, and you're probably good".  But, that's because we 
> push most of the hard work off onto C and C++ code that is written by 
> guys who worry about the bottom three bits.

> One of those really awesome tools is haproxy.  It's just amazing how 
> fast (and stable) that thing is.  It's all written in C.  Most of the if 
> statements are decorated with #pragmas telling the compiler which branch 
> is the most likely to be taken, so it can optimize better.  We need 
> people like that down in the trenches, so the rest of us can run around 
> naked in the park with flowers in our hair and not worry about the 
> bottom three bits any more.

I agree with most of the sentiment above...
Except the implication that C and C++ are equivalent

I wrote http://www.the-magus.in/Publications/chor.pdf
25 years ago criticising C *in education*.
I was half my age then and used stronger language then than I would now
Ive tried to express some pangs of conscience here
http://blog.languager.org/2013/02/c-in-education-and-software-engineering.html

However my point then as now was:
"C is dangerous to TEACH CS/programming with.
Its sweet if you KNOW what you are up to."

With C++ its horrible all the way

- C++ has pretentious abstractions that invariably leak*
  C is honest in having few abstractions

- C++ syntax is ridiculously brittle. C syntax is mostly straightforward     

- One of C's difficulties is complex binding-times: pre-process, compile, link
  load, run.  Needs work but is master-able. With C++ Ive not got the
  basics after 25 years -- order of static constructors, templates...

- I dont believe its coincidence that most of the rock-solid software
  I use has a C (not C++) under-belly -- python, linux-kernel,
  emacs, gcc, haskell, git, latex
  With apps in C++ its always catching-cook -- will it segfault me before 
  I save my file?
- Some guys with a wee bit more reputation who seem to agree with
  yours truly
  o http://article.gmane.org/gmane.comp.version-control.git/57918
  o http://harmful.cat-v.org/software/c++/rms

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

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

#67792

On Tue, Mar 4, 2014 at 8:36 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> * ... which summarizes my objection in this thread: Python's 'is' leaks the
> machine abstraction. 'id' does it legitimately (somewhat),
> 'is' does it illegitimately

Well, since "if x == None" is buggy as a test for sentinel values,
that means the only legitimate non-buggy way to do it is with "if
id(x) == id(None)", which just seems gross to me.

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

#67798

On Wednesday, March 5, 2014 9:38:58 AM UTC+5:30, Ian wrote:
> On Tue, Mar 4, 2014 at 8:36 PM, Rustom Mody wrote:
> > * ... which summarizes my objection in this thread: Python's 'is' leaks the
> > machine abstraction. 'id' does it legitimately (somewhat),
> > 'is' does it illegitimately

> Well, since "if x == None" is buggy as a test for sentinel values,
> that means the only legitimate non-buggy way to do it is with "if
> id(x) == id(None)", which just seems gross to me.

Ha Ha! -- Fully agreed!
One should not need to leak the machine abstraction for something as basic
as None testing

As I said earlier my current preference which is least disruptive is to have
as builtin

def isNone(x): return x is None

which should obviate most (basic) uses of is

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

#67799

Rustom Mody <rustompmody@gmail.com> writes:

> * ... which summarizes my objection in this thread:

Your long post references many things. Which is the “which” to which you
refer? What is it you're referring to that summarises your position?

> Python's 'is' leaks the machine abstraction.

No, it does not. The ‘is’ operator compares object identity, which is
itself an abstraction. What is leaking?

Note that the “location of the object in memory” is not a guarantee made
by either Python's object identity nor the ‘id’ function. There's no
need to treat “object location in memory” as equal to “object identity”,
and code which makes that assumption is buggy. The documentation doesn't
promise they will be the same.

So, the fact that some Python implementations happen to present
‘id(foo)’ values that coincide with a representation of memory location,
does not constitute a leaky abstraction: there is no need for any Python
programmer to care about what the memory location is. So if that's the
basis of your objection, I don't consider that objection to be
legitimate.

> 'id' does it legitimately (somewhat), 'is' does it illegitimately

What would, in your view, be a legitimate way for Python to present
object identity to the programmer? How would it differ substantially
from Python's existing abstraction of object identity?

-- 
 \          “That's all very good in practice, but how does it work in |
  `\                                             *theory*?” —anonymous |
_o__)                                                                  |
Ben Finney

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

#67801

On Wednesday, March 5, 2014 10:02:16 AM UTC+5:30, Ben Finney wrote:
> Rustom Mody writes:

> > * ... which summarizes my objection in this thread:

> Your long post references many things. Which is the "which" to which you
> refer? What is it you're referring to that summarises your position?

Text : C++ has pretentious abstractions that invariably leak* 

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

Not sure whats not clear: "is" in python leaks machine representations 
into the otherwise clean HLL abstraction in python like <dozens of things> in C++

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

#67803

On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:

> Python's 'is' leaks
> the machine abstraction. 'id' does it legitimately (somewhat), 'is' does
> it illegitimately

and then later in another post:

> "is" in python leaks machine representations
> into the otherwise clean HLL abstraction in python


Rather than respond with incredulity and declare that you have no idea 
what you are talking about, I'll give you the benefit of the doubt, and 
accept the possibility that I am wrong, or possibly misunderstanding you.

Can you explain what machine representations are leaked into Python by 
the is operator?

Do you see this as an accident of implementation, a bug that might be 
fixed, or a misfeature that was deliberately designed?

Can you elaborate on why id() is legitimate and "is" is not?


-- 
Steven

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

#67805

On Wednesday, March 5, 2014 10:36:37 AM UTC+5:30, Steven D'Aprano wrote:
> On Tue, 04 Mar 2014 19:36:38 -0800, Rustom Mody wrote:

> > Python's 'is' leaks
> > the machine abstraction. 'id' does it legitimately (somewhat), 'is' does
> > it illegitimately

> and then later in another post:

> > "is" in python leaks machine representations
> > into the otherwise clean HLL abstraction in python

> Rather than respond with incredulity and declare that you have no idea 
> what you are talking about, I'll give you the benefit of the doubt, and 
> accept the possibility that I am wrong, or possibly misunderstanding you.

Umm...
I guess my language was sloppy (a bit)
A machine is ultimately also an abstraction --
What is firmware/microcode? Is it a virtual machine? etc
Lets leave that however and just take 'machine' as a given.

Using machines as given, we build reprs for our (programmer's) data structures

So data structures are abstractions that have two 'faces' -- 
the machine-facing and the programmer-facing

For clarity of expression (and where you perhaps found me sloppy?? not sure...)
its best to call the machine-face 'a representation' and the programmer-face
'an abstraction'

Clearly this is a programmer-biased viewpoint. A hardware engineer would see
things differently. As would the user of the app the programmer programs.

Which is why to use the locution "is" without appropriate framing is philosopical
is a pretension to a 'God's-eye-view'.
If you are privy to such a viewpoint I'd be interested to know
But for the rest of us who are not, its good to remember there are only
perspectives no absolute truth.

That python is a hll means that machine reprs are intended to be abstracted
away. 'is' fails to do that -- proof of that being the discrepancy between
is and ==

> Can you explain what machine representations are leaked into Python by 
> the is operator?

> Do you see this as an accident of implementation, a bug that might be 
> fixed, or a misfeature that was deliberately designed?

> Can you elaborate on why id() is legitimate and "is" is not?

Let me talk of Lisp which is IMHO more philosophically sane.
Lisp has eq eql equal and a few type-specific others such as = for numbers
string-= for strings etc

eq is roughly python's 'is'
equal is roughl python's ==
The type-specific ones error out rather than returning false for out-of-bounds types.

So much for the technology

Now to the philosophy behind it:
Decide the viewpoint  -- choose the appropriate equivence predicate
No claim even remotely to having a clue to metaphysical being that python's 'is' implies

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

#67806

On 5/03/2014 3:47 PM, Rustom Mody wrote:
> That python is a hll means that machine reprs are intended to be abstracted
> away. 'is' fails to do that -- proof of that being the discrepancy between
> is and ==

The "discrepancy" is because _they're fundamentally different_:

     >>> a = b = [1,2]
     >>> c = [1,2]
     >>> a is b
     True
     >>> a is c
     False
     >>> a == b
     True
     >>> a == c
     True

`is` is used to determine if two names refer to the same object.
`==` is used to determine if they're equivalent in value.

Both have their uses.

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

#67808

On Wednesday, March 5, 2014 11:31:04 AM UTC+5:30, alex23 wrote:
> On 5/03/2014 3:47 PM, Rustom Mody wrote:
> > That python is a hll means that machine reprs are intended to be abstracted
> > away. 'is' fails to do that -- proof of that being the discrepancy between
> > is and ==

> The "discrepancy" is because _they're fundamentally different_:

Yeah I know :D


> Both have their uses.

Yes -- see my lisp example above

>      >>> a = b = [1,2]
>      >>> c = [1,2]
>      >>> a is b
>      True
>      >>> a is c
>      False
>      >>> a == b
>      True
>      >>> a == c
>      True

> `==` is used to determine if they're equivalent in value.

Right

> `is` is used to determine if two names refer to the same object.


'Same' is 'is' in a different guise and is what I object to.

A python programmer who needs/wants to think of same/is in this sense
should probably be using C or assembly

In the exceptional circumstances when 'low-level-machine-equivalence-relation'
is desired, a name carrying some of those connotations would be ok

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

#67811

Rustom Mody <rustompmody@gmail.com> writes:

> A python programmer who needs/wants to think of same/is in this sense
> should probably be using C or assembly

Please back up that bald assertion. How does the usefulness of the
“object identity” abstraction oblige the programmer to not use Python?

-- 
 \      “Software patents provide one more means of controlling access |
  `\      to information. They are the tool of choice for the internet |
_o__)                                     highwayman.” —Anthony Taylor |
Ben Finney

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

#67812

On 5/03/2014 4:10 PM, Rustom Mody wrote:
> A python programmer who needs/wants to think of same/is in this sense
> should probably be using C or assembly

Any programmer who is obsessing about some idea of philosophical purity 
should probably not be using Python.

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

#67838

On 05/03/2014 06:28, alex23 wrote:
> On 5/03/2014 4:10 PM, Rustom Mody wrote:
>> A python programmer who needs/wants to think of same/is in this sense
>> should probably be using C or assembly
>
> Any programmer who is obsessing about some idea of philosophical purity
> should probably not be using Python.
>

The Python philosophy is beautifully put in The Zen.  I particularly 
like "Practicality beats purity" although there's plenty of other pieces 
of the whole to consider.

-- 
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]

#67837

On 05/03/2014 06:10, Rustom Mody wrote:
> On Wednesday, March 5, 2014 11:31:04 AM UTC+5:30, alex23 wrote:
>> On 5/03/2014 3:47 PM, Rustom Mody wrote:
>>> That python is a hll means that machine reprs are intended to be abstracted
>>> away. 'is' fails to do that -- proof of that being the discrepancy between
>>> is and ==
>
>> The "discrepancy" is because _they're fundamentally different_:
>
> Yeah I know :D
>
>
>> Both have their uses.
>
> Yes -- see my lisp example above
>
>>       >>> a = b = [1,2]
>>       >>> c = [1,2]
>>       >>> a is b
>>       True
>>       >>> a is c
>>       False
>>       >>> a == b
>>       True
>>       >>> a == c
>>       True
>
>> `==` is used to determine if they're equivalent in value.
>
> Right
>
>> `is` is used to determine if two names refer to the same object.
>
>
> 'Same' is 'is' in a different guise and is what I object to.
>
> A python programmer who needs/wants to think of same/is in this sense
> should probably be using C or assembly
>
> In the exceptional circumstances when 'low-level-machine-equivalence-relation'
> is desired, a name carrying some of those connotations would be ok
>

Quite frankly I haven't got the faintest idea what you're going on 
about, so I'll just stick with writing plain, boring, working Python code.

-- 
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]

#67809

Rustom Mody <rustompmody@gmail.com> writes:

> That python is a hll means that machine reprs are intended to be abstracted
> away. 'is' fails to do that -- proof of that being the discrepancy between
> is and ==

That's your proof? That is a non sequitur. Those two operators are
*designed to be* different, to compare different things.

How does the difference between ‘==’ versus ‘is’, which are designed and
documented to have different behaviour, lead to your assertion of a
“leaky abstraction”?

You have yet to respond to this question asked several times:

> > Can you explain what machine representations are leaked into Python
> > by the is operator?

So, what machine represenatation is leaked?

I'll re-iterate that “memory location of the object” isn't a valid
response. There is no necessary relation between the memory location of
the object referenced by “foo” and the return value of ‘id(foo)’. The
latter is useable with utter ignorance of the concept of memory
location, so it is not a leaky abstraction.

Note that for an abstraction to be leaky, the programmer must *be
required* to have an understanding of what lies beneath the abstraction.
If the values that the programmer deals with can be dealt with entirely
at the level of the abstraction, and no knowledge of what's under the
hood is needed, then the abstraction does not leak.

> No claim even remotely to having a clue to metaphysical being that
> python's 'is' implies

Yes, exactly. You have no need to know what is under the hood: it is the
object's identity, which is simply a property which is unique to that
object among all other concurrently-existing objects.

The value returned by ‘id(foo)’ and compared by ‘is’ means nothing else
other than the abstraction of “object identity”. The value has to be
*something*, so it may resemble other things – such as the object's
memory location, or not – but that resemblance is not promised by
anything, and is irrelevant to the user of the abstraction.

-- 
 \       “As far as the laws of mathematics refer to reality, they are |
  `\    not certain, and as far as they are certain, they do not refer |
_o__)                              to reality.” —Albert Einstein, 1983 |
Ben Finney

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

#67859

On Wednesday, March 5, 2014 11:50:46 AM UTC+5:30, Ben Finney wrote:
> Rustom Mody writes:

> > That python is a hll means that machine reprs are intended to be abstracted
> > away. 'is' fails to do that -- proof of that being the discrepancy between
> > is and ==

> That's your proof? That is a non sequitur. Those two operators are
> *designed to be* different, to compare different things.

> How does the difference between '==' versus 'is', which are designed and
> documented to have different behaviour, lead to your assertion of a
> "leaky abstraction"?

> You have yet to respond to this question asked several times:


If you wish to disagree with me, you are welcome to do so
and I am obliged (up to a point I guess) to assume the disagreement is in 
good faith towards better understanding/usage etc of python.  However...


> > > Can you explain what machine representations are leaked into Python
> > > by the is operator?

> So, what machine represenatation is leaked?

> I'll re-iterate that "memory location of the object" isn't a valid
> response. There is no necessary relation between the memory location of
> the object referenced by "foo" and the return value of 'id(foo)'.

... however you are both disagreeing with me and also saying Ive not given
the answer and further disagreeing with the python standard, which I quote:

Every object has an identity, a type and a value. An object's identity
never changes once it has been created; you may think of it as the
object's address in memory. The 'is' operator compares the identity of
two objects; the id() function returns an integer representing its
identity (currently implemented as its address).

from http://docs.python.org/2/reference/datamodel.html

So when you say
> I'll re-iterate that "memory location of the object" isn't a valid
> response. 

well... all I can say is I dont know what to say :-)

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

#67865

On 2014-03-05 09:40, Rustom Mody wrote:
> Every object has an identity, a type and a value. An object's
> identity never changes once it has been created; you may think of
> it as the object's address in memory. The 'is' operator compares
> the identity of two objects; the id() function returns an integer
> representing its identity (currently implemented as its address).
> 
> from http://docs.python.org/2/reference/datamodel.html

Note the "currently", which does not mean "now, always, and forever
for every implementation".

From http://docs.python.org/3/library/functions.html#id

"""
    Return the “identity” of an object. This is an integer which is
    guaranteed to be unique and constant for this object during its
    lifetime. Two objects with non-overlapping lifetimes may have the
    same id() value.

    CPython implementation detail: This is the address of the object
    in memory.
"""

This is clearly documented as a *CPython implementation detail*.  The
id() function is free to return sequential integers, arbitrary
integers, memory addresses, GUIDs-as-integers, or hashes-as-integers
for some internal representation.

The only thing that matters is (1) that id() returns *some* integer
identifying the object, and (2) the ability to compare id(thing1) with
id(thing2) and see if they are the same or different (assuming thing1
and thing2 share lifetimes during their id() calls), regardless of
what is actually returned.

> So when you say
> > I'll re-iterate that "memory location of the object" isn't a valid
> > response. 
> 
> well... all I can say is I dont know what to say :-)

That you live in a CPython world, unencumbered by experience in other
flavors of language-spec-compliant Python interpreters where id()
returns integers that *aren't* memory addresses?

-tkc

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

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

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

csiph-web