Re: Puzzled by "is"

[Dick Moores]

At 09:59 AM 8/12/2007, Steve Holden wrote:
>Dick Moores wrote:
> > At 08:23 AM 8/12/2007, Steve Holden wrote:
> >> Dick Moores wrote:
> >>> So would a programmer EVER use "is" in a script?
> >> Sure. For example, the canonical test for None uses
> >>
> >>  x is None
> >>
> >> because there is only ever one instance of type Nonetype, so it's the
> >> fastest test. Generally speaking you use "is" to test for identity (do
> >> these two expressions reference the same object) rather than equality
> >> (do these two expressions evaluate to equivalent objects).
> >
> > Off the top of your head, could you or others give me as many
> > examples as you can think of?
> >
>Occasionally it's necessary to test for a specific type (though in
>Python this is usually bad practice). Since types are also singletons
>the best way to do this is (e.g.):
>
>  type(x) is type([]) # test specifically for a list
>
>If you want to know whether you have been told to write to standard
>output, one possible test is
>
>  if f is not sys.stdout
>
>Similarly, of course, you can test for the other standard IO channels.
>
>The imputil module contains the test
>
>  if importer is not self
>
>to determine whether a reload() should be performed in the context of
>the current package.
>
>When you need to establish a specific sentinel value that can never be
>provided by an outside caller it's normal to create an instance of
>object (the simplest possible thing you can create in a Python program)
>and test for that instance, as in
>
>  sentinel = object()
>  ...
>  if value is sentinel:
>
>You can test whether a class is new-style as opposed to old-style, which
>can help to unify old-style and new-style objects:
>
>class MetaProperty(type):
>  def __new__(cls, name, bases, dct):
>  if bases[0] is object: # allow us to create class Property
>  return type.__new__(cls, name, bases, dct)
>  return property(dct.get('get'), dct.get('set'),
>  dct.get('delete'), dct.get('__doc__'))
>
>  def __init__(cls, name, bases, dct):
>  if bases[0] is object:
>  return type.__init__(cls, name, bases, dct)
>
>
>That gets you started ...

Sure does. Thanks very much, Steve.

Dick


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Steve Holden]

Dick Moores wrote:
> At 08:23 AM 8/12/2007, Steve Holden wrote:
>> Dick Moores wrote:
>>> So would a programmer EVER use "is" in a script?
>> Sure. For example, the canonical test for None uses
>>
>>  x is None
>>
>> because there is only ever one instance of type Nonetype, so it's the
>> fastest test. Generally speaking you use "is" to test for identity (do
>> these two expressions reference the same object) rather than equality
>> (do these two expressions evaluate to equivalent objects).
> 
> Off the top of your head, could you or others give me as many 
> examples as you can think of?
> 
Occasionally it's necessary to test for a specific type (though in 
Python this is usually bad practice). Since types are also singletons 
the best way to do this is (e.g.):

 type(x) is type([]) # test specifically for a list

If you want to know whether you have been told to write to standard 
output, one possible test is

 if f is not sys.stdout

Similarly, of course, you can test for the other standard IO channels.

The imputil module contains the test

 if importer is not self

to determine whether a reload() should be performed in the context of 
the current package.

When you need to establish a specific sentinel value that can never be 
provided by an outside caller it's normal to create an instance of 
object (the simplest possible thing you can create in a Python program) 
and test for that instance, as in

 sentinel = object()
 ...
 if value is sentinel:

You can test whether a class is new-style as opposed to old-style, which 
can help to unify old-style and new-style objects:

class MetaProperty(type):
 def __new__(cls, name, bases, dct):
 if bases[0] is object: # allow us to create class Property
 return type.__new__(cls, name, bases, dct)
 return property(dct.get('get'), dct.get('set'),
 dct.get('delete'), dct.get('__doc__'))

 def __init__(cls, name, bases, dct):
 if bases[0] is object:
 return type.__init__(cls, name, bases, dct)


That gets you started ...

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Dick Moores]

At 08:23 AM 8/12/2007, Steve Holden wrote:
>Dick Moores wrote:
> > So would a programmer EVER use "is" in a script?
>
>Sure. For example, the canonical test for None uses
>
>  x is None
>
>because there is only ever one instance of type Nonetype, so it's the
>fastest test. Generally speaking you use "is" to test for identity (do
>these two expressions reference the same object) rather than equality
>(do these two expressions evaluate to equivalent objects).

Off the top of your head, could you or others give me as many 
examples as you can think of?

Thanks again,

Dick


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Steve Holden]

Dick Moores wrote:
> On 8/12/07, *Ben Finney* <[EMAIL PROTECTED] 
> > wrote:
> 
> Dick Moores <[EMAIL PROTECTED] > writes:
> 
>  > At 06:13 PM 8/9/2007, Ben Finney wrote:
>  > >it's entirely left to the language implementation which
>  > >optimisation trade-offs to make, and the language user (that's you
>  > >and I) should *not* expect any particular behaviour to hold between
>  > >different implementations.
>  >
>  > I'm not clear on the meaning of "implementations" here.  Would 2.5
>  > for Windows, Mac, Linux all be different implementations? Would Iron
>  > Python be another? ActivePython?
> 
> For the purpose of the above statement, you should consider even the
> same Python on two different machines to be "different
> implementations". As a programmer writing Python code, you should not
> expect any "implementation-dependent" behaviour to operate in any
> particular way.
> 
> 
> So would a programmer EVER use "is" in a script?

Sure. For example, the canonical test for None uses

 x is None

because there is only ever one instance of type Nonetype, so it's the 
fastest test. Generally speaking you use "is" to test for identity (do 
these two expressions reference the same object) rather than equality 
(do these two expressions evaluate to equivalent objects).

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Dick Moores]

On 8/12/07, Ben Finney <[EMAIL PROTECTED]> wrote:
>
> Dick Moores <[EMAIL PROTECTED]> writes:
>
> > At 06:13 PM 8/9/2007, Ben Finney wrote:
> > >it's entirely left to the language implementation which
> > >optimisation trade-offs to make, and the language user (that's you
> > >and I) should *not* expect any particular behaviour to hold between
> > >different implementations.
> >
> > I'm not clear on the meaning of "implementations" here.  Would 2.5
> > for Windows, Mac, Linux all be different implementations? Would Iron
> > Python be another? ActivePython?
>
> For the purpose of the above statement, you should consider even the
> same Python on two different machines to be "different
> implementations". As a programmer writing Python code, you should not
> expect any "implementation-dependent" behaviour to operate in any
> particular way.


So would a programmer EVER use "is" in a script?

Dick
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Ben Finney]

Dick Moores <[EMAIL PROTECTED]> writes:

> At 06:13 PM 8/9/2007, Ben Finney wrote:
> >it's entirely left to the language implementation which
> >optimisation trade-offs to make, and the language user (that's you
> >and I) should *not* expect any particular behaviour to hold between
> >different implementations.
> 
> I'm not clear on the meaning of "implementations" here.  Would 2.5
> for Windows, Mac, Linux all be different implementations? Would Iron
> Python be another? ActivePython?

For the purpose of the above statement, you should consider even the
same Python on two different machines to be "different
implementations". As a programmer writing Python code, you should not
expect any "implementation-dependent" behaviour to operate in any
particular way.

-- 
 \  "The fact that a believer is happier than a skeptic is no more |
  `\   to the point than the fact that a drunken man is happier than a |
_o__) sober one." —George Bernard Shaw |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Trent Mick]

Dick Moores wrote:
> At 06:13 PM 8/9/2007, Ben Finney wrote:
>> It's important to also realise that the language is *deliberately*
>> non-committal on whether any given value will have this behaviour;
>> that is, it's entirely left to the language implementation which
>> optimisation trade-offs to make, and the language user (that's you and
>> I) should *not* expect any particular behaviour to hold between
>> different implementations.
> 
> I'm not clear on the meaning of "implementations" 
> here.  Would 2.5 for Windows, Mac, Linux all be 
> different implementations? Would Iron Python be another? ActivePython?

(Note that I'm jumping into this without having read the thread, so 
apologies if I didn't grasp the question in its proper context.)

Separate Python "implementations" generally refers to a separate source 
code base for that Python build. According to that definition, current 
examples of Python implementations are: CPython (from python.org, 
C-based), Jython (Java-based), Stackless Python (I'm not that familiar 
to how much of the CPython source code, if any, Stackless borrows), 
IronPython (.NET/C#-based), possibly PyPy (Python-based, I'm not that 
familiar with it). Also eventually interesting might be the recently 
announced IronMonkey (http://wiki.mozilla.org/Tamarin:IronMonkey).

Windows, Mac, Linux, etc. installations/builds/installers of a 
particular implementation would be different platform *builds* (my 
language).

ActivePython is a separate (from python.org's) *distribution* of CPython 
-- i.e. the sample implementation as CPython (same source code). This is 
similar, in some respects, to SuSE, Debian, RedHat, Ubuntu, etc. being 
different distributions of Linux.


Trent

-- 
Trent Mick
trentm at activestate.com
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Marc 'BlackJack' Rintsch]

On Fri, 10 Aug 2007 10:57:22 -0700, Dick Moores wrote:

> At 06:13 PM 8/9/2007, Ben Finney wrote:
>>Others have already said that it's an implementation optimisation,
>>which seems to partly answer your question.
>>
>>It's important to also realise that the language is *deliberately*
>>non-committal on whether any given value will have this behaviour;
>>that is, it's entirely left to the language implementation which
>>optimisation trade-offs to make, and the language user (that's you and
>>I) should *not* expect any particular behaviour to hold between
>>different implementations.
> 
> I'm not clear on the meaning of "implementations" 
> here.  Would 2.5 for Windows, Mac, Linux all be 
> different implementations? Would Iron Python be another? ActivePython?

Taken to the extreme you shouldn't rely on implementation details at all,
so even the very same interpreter might cache and reuse the empty tuple in
one run but not in the next.

For me CPython, Iron Python and Jython are different implementations as
they are all written from scratch.

Ciao,
Marc 'BlackJack' Rintsch
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Dick Moores]

At 06:13 PM 8/9/2007, Ben Finney wrote:
>Content-Transfer-Encoding: base64Grzegorz 
>Słodkowicz <[EMAIL PROTECTED]  [EMAIL PROTECTED] 
>theorisation but I'd rather expect the interpreter
> > simply not to create a second tuple while there already is an
> > identical one.
>
>Others have already said that it's an implementation optimisation,
>which seems to partly answer your question.
>
>It's important to also realise that the language is *deliberately*
>non-committal on whether any given value will have this behaviour;
>that is, it's entirely left to the language implementation which
>optimisation trade-offs to make, and the language user (that's you and
>I) should *not* expect any particular behaviour to hold between
>different implementations.

I'm not clear on the meaning of "implementations" 
here.  Would 2.5 for Windows, Mac, Linux all be 
different implementations? Would Iron Python be another? ActivePython?

Thanks,

Dick


-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Paul Rudin]

John K Masters <[EMAIL PROTECTED]> writes:

>
> OK fiddling around with this and reading the docs I tried:-
> a = 'qq' #10 q's
> b = 'qq' #10 q's
> a is b
> true
> c = 'q' * 10
> c
> 'qq' #10 q's
> d = 'q' * 10
> d
> 'qq' #10 q's
> c is d
> false
>
> So from what I've read "==" tests for equivalence, "is" tests for identity but
> that does not explain the behaviour above.
>

There's nothing especially to be explained, other than "that's the way
the compiler does it". Two equal string literals might be the same
object or they might not be. It's a language implementation detail.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Erik Max Francis]

Ben Finney wrote:

> It's important to also realise that the language is *deliberately*
> non-committal on whether any given value will have this behaviour;
> that is, it's entirely left to the language implementation which
> optimisation trade-offs to make, and the language user (that's you and
> I) should *not* expect any particular behaviour to hold between
> different implementations.

Right.  In the terminology of language standards, it is implementation 
defined.

-- 
Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
   Only love is worth the risk
-- Oleta Adams
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Ben Finney]

Grzegorz Słodkowicz <[EMAIL PROTECTED]> writes:

> That's just theorisation but I'd rather expect the interpreter
> simply not to create a second tuple while there already is an
> identical one.

Others have already said that it's an implementation optimisation,
which seems to partly answer your question.

It's important to also realise that the language is *deliberately*
non-committal on whether any given value will have this behaviour;
that is, it's entirely left to the language implementation which
optimisation trade-offs to make, and the language user (that's you and
I) should *not* expect any particular behaviour to hold between
different implementations.

-- 
 \ "Holy priceless collection of Etruscan snoods, Batman!"  -- |
  `\ Robin |
_o__)  |
Ben Finney
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Hrvoje Niksic]

Grzegorz Słodkowicz <[EMAIL PROTECTED]> writes:

>> Seriously, it's just an optimization by the implementers. There is
>> no need for more than one empty tuple, since tuples can never be
>> modified once created.
>>
>> But they decided not to create (1, ) in advance. They probably knew
>> that hardly anybody would want to create that tuple ;-) [Seriously:
>> if you started trying to predict which tuples would be used you
>> would go insane, but the empty tuple is the most likely candidate].
>>
> That's just theorisation but I'd rather expect the interpreter simply
> not to create a second tuple while there already is an identical
> one.

But then tuple creation would be slowed down by searching for whether
an "identical one" already exists.  In the general case, that is quite
unlikely, so it's not done.  (I suspect that only the requirement to
store the list of all tuples somewhere would outweigh any potential
gains of this strategy; and if the search were implemented as a hash
table lookup, even more space would be wasted.)  It's done for the
empty tuple because no search is necessary, only a size test.

> Admittedly the empty tuple is a special case but then 'Special cases
> aren't special enough to break the rules'.

Except no rule is being broken.  As others have pointed out, since
tuples are immutable, caching them is quite safe.
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Steve Holden]

Grzegorz Słodkowicz wrote:
>> Why? Because.
>>
>> Seriously, it's just an optimization by the implementers. There is no 
>> need for more than one empty tuple, since tuples can never be modified 
>> once created.
>>
>> But they decided not to create (1, ) in advance. They probably knew that 
>> hardly anybody would want to create that tuple ;-) [Seriously: if you 
>> started trying to predict which tuples would be used you would go 
>> insane, but the empty tuple is the most likely candidate].
>>   
> That's just theorisation but I'd rather expect the interpreter simply 
> not to create a second tuple while there already is an identical one. 
> This could save some memory if the tuple was large (Although by the same 
> token comparison of large tuples can be expensive). Admittedly the empty 
> tuple is a special case but then 'Special cases aren't special enough to 
> break the rules'.
> 
> A bit odd.
> 
It's a trade-off, preferring to optimize time rather than memory usage. 
If tuples were "interned" like some strings then tuple creation would be 
more expensive due to the need to search the cache when creating them 
which, as you rightly point out, could be very expensive for large tuples.

The integers under 100 are also, IIRC, special-cased:

 >>> x = 12
 >>> y = 32676
 >>> x is 12
True
 >>> y is 32676
False
 >>>

I guess if you *make* the rules you can decide when it's reasonable to 
break them!

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Erik Max Francis]

Grzegorz Słodkowicz wrote:

> That's just theorisation but I'd rather expect the interpreter simply 
> not to create a second tuple while there already is an identical one. 
> This could save some memory if the tuple was large (Although by the same 
> token comparison of large tuples can be expensive). Admittedly the empty 
> tuple is a special case but then 'Special cases aren't special enough to 
> break the rules'.
> 
> A bit odd.

It doesn't save time if you have to check through all the existing 
tuples for matches ...

-- 
Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
   Chance favors the trained mind.
-- Louis Pasteur
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Erik Max Francis]

John K Masters wrote:

> OK fiddling around with this and reading the docs I tried:-
> a = 'qq' #10 q's
> b = 'qq' #10 q's
> a is b
> true
> c = 'q' * 10
> c
> 'qq' #10 q's
> d = 'q' * 10
> d
> 'qq' #10 q's
> c is d
> false
> 
> So from what I've read "==" tests for equivalence, "is" tests for identity but
> that does not explain the behaviour above.

Using the `is` test between non-sentinel immutable objects (e.g., 
integers, floats, strings) is _completely pointless_.  Since immutable 
objects cannot be changed, it is up to the interpreter (and thus can 
vary from version to version and implementation to implementation) 
whether or not to "cache" the objects and reuse them, or whether or not 
to create new ones.  You should never be testing such objects for 
identity (`is`); you should only be testing them for equality (`==`).

The only time it makes sense to use the `is` operator with immutable 
objects is when you're dealing with a sentinel object, e.g., `None`, or 
a custom sentinel object (e.g., `mySentinel = object()`), because that 
is the only time you actually _are_ interested in identity.  All other 
times you are not really interested in identity.

Sample code as above is essentially showing unimportant implementation 
details that should never concern you.  Don't use `is`, use `==`.

-- 
Erik Max Francis && [EMAIL PROTECTED] && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
   Chance favors the trained mind.
-- Louis Pasteur
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Grzegorz Słodkowicz]

>
> Why? Because.
>
> Seriously, it's just an optimization by the implementers. There is no 
> need for more than one empty tuple, since tuples can never be modified 
> once created.
>
> But they decided not to create (1, ) in advance. They probably knew that 
> hardly anybody would want to create that tuple ;-) [Seriously: if you 
> started trying to predict which tuples would be used you would go 
> insane, but the empty tuple is the most likely candidate].
>   
That's just theorisation but I'd rather expect the interpreter simply 
not to create a second tuple while there already is an identical one. 
This could save some memory if the tuple was large (Although by the same 
token comparison of large tuples can be expensive). Admittedly the empty 
tuple is a special case but then 'Special cases aren't special enough to 
break the rules'.

A bit odd.

Best regards,
Greg
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Steve Holden]

[EMAIL PROTECTED] wrote:
[...]
> 
> Steve,
> 
> I thought you'd probably weigh in on this esoteric matter. Very
> illuminating, as usual.
> 
Thank you!

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Neil Cerutti]

On 2007-08-09, John K Masters <[EMAIL PROTECTED]> wrote:
> On 15:53 Thu 09 Aug , Steve Holden wrote:
>> Dick Moores wrote:
>> > At 10:46 AM 8/9/2007, Bill Scherer wrote:
>> >> Dick Moores wrote:
>> [...]
>> >> There is only one empty tuple.
>> >> Does that clear it up for you?
>> > 
>> > But isn't that the same as saying, "That's just the reality of 
>> > Python; it is what it is."? I want to know why there is only one 
>> > empty tuple, but more than one (1,).
>> > 
>> Why? Because.
>> 
>> Seriously, it's just an optimization by the implementers. There is no 
>> need for more than one empty tuple, since tuples can never be modified 
>> once created.
>> 
>> But they decided not to create (1, ) in advance. They probably knew that 
>> hardly anybody would want to create that tuple ;-) [Seriously: if you 
>> started trying to predict which tuples would be used you would go 
>> insane, but the empty tuple is the most likely candidate].
>> 
>> > Also,
>> >  >>> [] is []
>> > False
>> > 
>> In that case it would definitely NOT make sense to have them the same 
>> list. Python always ensures that the [] constructor creates a new list, 
>> since that list may be bound to one or more variables and mutated. You 
>> wouldn't want
>> 
>>a = []
>>b = []
>>a.append("boo!")
>> 
>> to change b so it was no longer an empty list. If you wanted a and b to 
>> reference the same list you would change the second statement to
>> 
>>b = a
>> 
>> regards
>>   Steve
>
> OK fiddling around with this and reading the docs I tried:-
> a = 'qq' #10 q's
> b = 'qq' #10 q's

CPython is full of cute little optimizations, and one of them is
that literal strings less than a certain length are 'interned'.
This makes them very fast to compare for equality, and cheaper to
store (maybe?).

> a is b
> true
> c = 'q' * 10
> c
> 'qq' #10 q's
> d = 'q' * 10
> d
> 'qq' #10 q's
> c is d
> false
>
> So from what I've read "==" tests for equivalence, "is" tests
> for identity but that does not explain the behaviour above.

The 10 q's constructed with string arithmetic were not interned,
because they were not literals.

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[kyosohma]

On Aug 9, 2:53 pm, Steve Holden <[EMAIL PROTECTED]> wrote:
> Dick Moores wrote:
> > At 10:46 AM 8/9/2007, Bill Scherer wrote:
> >> Dick Moores wrote:
> [...]
> >> There is only one empty tuple.
> >> Does that clear it up for you?
>
> > But isn't that the same as saying, "That's just the reality of
> > Python; it is what it is."? I want to know why there is only one
> > empty tuple, but more than one (1,).
>
> Why? Because.
>
> Seriously, it's just an optimization by the implementers. There is no
> need for more than one empty tuple, since tuples can never be modified
> once created.
>
> But they decided not to create (1, ) in advance. They probably knew that
> hardly anybody would want to create that tuple ;-) [Seriously: if you
> started trying to predict which tuples would be used you would go
> insane, but the empty tuple is the most likely candidate].
>
> > Also,
> >  >>> [] is []
> > False
>
> In that case it would definitely NOT make sense to have them the same
> list. Python always ensures that the [] constructor creates a new list,
> since that list may be bound to one or more variables and mutated. You
> wouldn't want
>
>a = []
>b = []
>a.append("boo!")
>
> to change b so it was no longer an empty list. If you wanted a and b to
> reference the same list you would change the second statement to
>
>b = a
>
> regards
>   Steve
> --
> Steve Holden+1 571 484 6266   +1 800 494 3119
> Holden Web LLC/Ltd  http://www.holdenweb.com
> Skype: holdenweb  http://del.icio.us/steve.holden
> --- Asciimercial --
> Get on the web: Blog, lens and tag the Internet
> Many services currently offer free registration
> --- Thank You for Reading -

Steve,

I thought you'd probably weigh in on this esoteric matter. Very
illuminating, as usual.

Mike

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[John K Masters]

On 15:53 Thu 09 Aug , Steve Holden wrote:
> Dick Moores wrote:
> > At 10:46 AM 8/9/2007, Bill Scherer wrote:
> >> Dick Moores wrote:
> [...]
> >> There is only one empty tuple.
> >> Does that clear it up for you?
> > 
> > But isn't that the same as saying, "That's just the reality of 
> > Python; it is what it is."? I want to know why there is only one 
> > empty tuple, but more than one (1,).
> > 
> Why? Because.
> 
> Seriously, it's just an optimization by the implementers. There is no 
> need for more than one empty tuple, since tuples can never be modified 
> once created.
> 
> But they decided not to create (1, ) in advance. They probably knew that 
> hardly anybody would want to create that tuple ;-) [Seriously: if you 
> started trying to predict which tuples would be used you would go 
> insane, but the empty tuple is the most likely candidate].
> 
> > Also,
> >  >>> [] is []
> > False
> > 
> In that case it would definitely NOT make sense to have them the same 
> list. Python always ensures that the [] constructor creates a new list, 
> since that list may be bound to one or more variables and mutated. You 
> wouldn't want
> 
>a = []
>b = []
>a.append("boo!")
> 
> to change b so it was no longer an empty list. If you wanted a and b to 
> reference the same list you would change the second statement to
> 
>b = a
> 
> regards
>   Steve

OK fiddling around with this and reading the docs I tried:-
a = 'qq' #10 q's
b = 'qq' #10 q's
a is b
true
c = 'q' * 10
c
'qq' #10 q's
d = 'q' * 10
d
'qq' #10 q's
c is d
false

So from what I've read "==" tests for equivalence, "is" tests for identity but
that does not explain the behaviour above.

Regards, John
-- 
War is God's way of teaching Americans geography
Ambrose Bierce (1842 - 1914)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Steve Holden]

Dick Moores wrote:
> At 10:46 AM 8/9/2007, Bill Scherer wrote:
>> Dick Moores wrote:
[...]
>> There is only one empty tuple.
>> Does that clear it up for you?
> 
> But isn't that the same as saying, "That's just the reality of 
> Python; it is what it is."? I want to know why there is only one 
> empty tuple, but more than one (1,).
> 
Why? Because.

Seriously, it's just an optimization by the implementers. There is no 
need for more than one empty tuple, since tuples can never be modified 
once created.

But they decided not to create (1, ) in advance. They probably knew that 
hardly anybody would want to create that tuple ;-) [Seriously: if you 
started trying to predict which tuples would be used you would go 
insane, but the empty tuple is the most likely candidate].

> Also,
>  >>> [] is []
> False
> 
In that case it would definitely NOT make sense to have them the same 
list. Python always ensures that the [] constructor creates a new list, 
since that list may be bound to one or more variables and mutated. You 
wouldn't want

   a = []
   b = []
   a.append("boo!")

to change b so it was no longer an empty list. If you wanted a and b to 
reference the same list you would change the second statement to

   b = a

regards
  Steve
-- 
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd   http://www.holdenweb.com
Skype: holdenweb  http://del.icio.us/steve.holden
--- Asciimercial --
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
--- Thank You for Reading -

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Dick Moores]

At 10:46 AM 8/9/2007, Bill Scherer wrote:
>Dick Moores wrote:
> >  >>> () is ()
> > True
> >  >>> (1,) is (1,)
> > False
> >
> > Why?
> >
>
> >>> a = ()
> >>> b = ()
> >>> c = (1,)
> >>> d = (1,)
> >>> a is b
>True
> >>> c is d
>False
> >>> id(a)
>3086553132
> >>> id(b)
>3086553132
> >>> id(c)
>3086411340
> >>> id(d)
>3086390892
>
>
>There is only one empty tuple.
>Does that clear it up for you?

But isn't that the same as saying, "That's just the reality of 
Python; it is what it is."? I want to know why there is only one 
empty tuple, but more than one (1,).

Also,
 >>> [] is []
False

Dick  

-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Jay Loden]

Jay Loden wrote:
> Dick Moores wrote:
>>  >>> () is ()
>> True
>>  >>> (1,) is (1,)
>> False
>>
>> Why?
>>
>> Thanks,
>>
>> Dick Moores
> 


>From the docs for 'is':

  The operators is and is not test for object identity: x is y is true if
  and only if x and y are the same object. x is not y yields the inverse
  truth value.



So you're actually testing whether or not the identity of the object is the
same, not whether (1,) == (1,):

>>> (1,) == (1,)
True
>>> id((0,)) == id((0,))
False

-Jay
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Neil Cerutti]

On 2007-08-09, Dick Moores <[EMAIL PROTECTED]> wrote:
> >>> () is ()
> True
> >>> (1,) is (1,)
> False
>
> Why?

>From _Python Reference Manual_: 5.2.4 List displays:

  An empty pair of parentheses yields an empty tuple object.
  Since tuples are immutable, the rules for literals apply (i.e.,
  two occurrences of the empty tuple may or may not yield the
  same object). 

-- 
Neil Cerutti
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Bill Scherer]

Dick Moores wrote:
>  >>> () is ()
> True
>  >>> (1,) is (1,)
> False
>
> Why?
>   

>>> a = ()
>>> b = ()
>>> c = (1,)
>>> d = (1,)
>>> a is b
True
>>> c is d
False
>>> id(a)
3086553132
>>> id(b)
3086553132
>>> id(c)
3086411340
>>> id(d)
3086390892


There is only one empty tuple.
Does that clear it up for you?

> Thanks,
>
> Dick Moores
>
>   
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: Puzzled by "is"

[Jay Loden]

Dick Moores wrote:
>  >>> () is ()
> True
>  >>> (1,) is (1,)
> False
> 
> Why?
> 
> Thanks,
> 
> Dick Moores

>From the docs for 'is':

-- 
http://mail.python.org/mailman/listinfo/python-list

Puzzled by "is"

[Dick Moores]

 >>> () is ()
True
 >>> (1,) is (1,)
False

Why?

Thanks,

Dick Moores

-- 
http://mail.python.org/mailman/listinfo/python-list