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

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

Explaining names vs variables in Python

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

Contents

  Explaining  names  vs variables  in Python Salvatore DI DIO <salvatore.didio@gmail.com> - 2016-03-02 00:32 -0800
    Re: Explaining names vs variables in Python Jesper K Brogaard <jesper@brogAAaard.eu> - 2016-03-02 10:03 +0100
      Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-02 21:32 +1100
        Re: Explaining names vs variables in Python Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 14:34 +0200
          Re: Explaining names vs variables in Python Chris Angelico <rosuav@gmail.com> - 2016-03-02 23:50 +1100
            Re: Explaining names vs variables in Python Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-02 15:11 +0200
            Re: Explaining names vs variables in Python Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 15:39 +0200
              Re: Explaining names vs variables in Python Chris Angelico <rosuav@gmail.com> - 2016-03-03 00:48 +1100
                Re: Explaining names vs variables in Python Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 16:11 +0200
                  Re: Explaining names vs variables in Python Rustom Mody <rustompmody@gmail.com> - 2016-03-02 07:08 -0800
                  Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-03 04:23 +1100
                    Re: Explaining names vs variables in Python Rustom Mody <rustompmody@gmail.com> - 2016-03-02 09:28 -0800
                    Re: Explaining names vs variables in Python Marko Rauhamaa <marko@pacujo.net> - 2016-03-02 20:12 +0200
                      Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-03 12:52 +1100
                        Re: Explaining names vs variables in Python Rustom Mody <rustompmody@gmail.com> - 2016-03-03 09:03 -0800
                          Re: Explaining names vs variables in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-03 12:53 -0700
                    Re: Explaining names vs variables in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-02 21:49 +0000
                      Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-03 13:05 +1100
                        Re: Explaining names vs variables in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-03 16:09 +0000
                    Re: Explaining names vs variables in Python Chris Angelico <rosuav@gmail.com> - 2016-03-03 08:52 +1100
                      Re: Explaining names vs variables in Python Rustom Mody <rustompmody@gmail.com> - 2016-03-02 17:23 -0800
                    Re: Explaining names vs variables in Python Mark Lawrence <breamoreboy@yahoo.co.uk> - 2016-03-02 22:51 +0000
                Re: Explaining names vs variables in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-03 04:10 +1100
    Re: Explaining names vs variables in Python Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2016-03-02 10:08 +0100
    Effects of caching frequently used objects, was Re: Explaining  names  vs variables  in Python Peter Otten <__peter__@web.de> - 2016-03-02 10:12 +0100
    Re: Explaining  names  vs variables  in Python Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-02 11:35 +0200
      Re: Explaining names vs variables in Python Ian Kelly <ian.g.kelly@gmail.com> - 2016-03-02 08:13 -0700
        Re: Explaining names vs variables in Python Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-03-02 17:37 +0200
    Re: Explaining  names  vs variables  in Python Steven D'Aprano <steve@pearwood.info> - 2016-03-02 21:16 +1100
    Re: Explaining  names  vs variables  in Python "ast" <nomail@invalid.com> - 2016-03-02 11:52 +0100
      Re: Explaining  names  vs variables  in Python Salvatore DI DIO <salvatore.didio@gmail.com> - 2016-03-02 02:58 -0800
    Re: Effects of caching frequently used objects, was Re: Explaining  names  vs variables  in Python Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-03-02 09:16 -0500
    Re: Explaining  names  vs variables  in Python Ben Finney <ben+python@benfinney.id.au> - 2016-03-03 04:53 +1100
    RE: Effects of caching frequently used objects, was Re: Explaining names  vs variables  in Python Albert-Jan Roskam <sjeik_appie@hotmail.com> - 2016-03-25 13:03 +0000
    Re: Effects of caching frequently used objects, was Re: Explaining names vs variables in Python Chris Angelico <rosuav@gmail.com> - 2016-03-26 00:22 +1100
    Re: Effects of caching frequently used objects, was Re: Explaining names  vs variables  in Python Ethan Furman <ethan@stoneleaf.us> - 2016-03-25 09:45 -0700

Page 1 of 2  [1] 2  Next page →

#103846 — Explaining names vs variables in Python

Hello,

I know Python does not have variables, but names.
Multiple names cant then be bound to the same objects.

So this behavior 

>>> b = 234
>>> v = 234
>>> b is v
True

according to the above that is ok



But where is the consistency ? if I try :

>>> v = 890
>>> w = 890
>>> v is w
False

It is a little difficult to explain this behavior to a newcommer in Python

Can someone give me the right argument to expose ?

Regards

[toc] | [next] | [standalone]

#103847 — Re: Explaining names vs variables in Python

Den 02-03-2016 kl. 09:32 skrev Salvatore DI DIO:
> Hello,
>
> I know Python does not have variables, but names.
> Multiple names cant then be bound to the same objects.
>
> So this behavior
>
>>>> b = 234
>>>> v = 234
>>>> b is v
> True
>
> according to the above that is ok
>
>
>
> But where is the consistency ? if I try :
>
>>>> v = 890
>>>> w = 890
>>>> v is w
> False
>
> It is a little difficult to explain this behavior to a newcommer in Python
>
> Can someone give me the right argument to expose ?
>
> Regards
>

You may get an answer to your question here: 
http://stackoverflow.com/questions/2419701/python-object-identity-question

As I understand it, when you use 'is', you are comparing addresses to 
objects, not the values contained in the objects. Use '==' instead.

Take a look here as well: 
https://docs.python.org/3.5/reference/datamodel.html

-- 
Venlig hilsen / Best regards
Jesper K. Brogaard

(remove upper case letters in my e-mail address)

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

#103857 — Re: Explaining names vs variables in Python

On Wed, 2 Mar 2016 08:03 pm, Jesper K Brogaard wrote:

> As I understand it, when you use 'is', you are comparing addresses to
> objects, not the values contained in the objects. Use '==' instead.

You should not think about addresses, because the location of objects is not
part of the language. It is implementation-dependent.

In CPython, objects are fixed to a single location in the heap, and will
never move. But in Jython and IronPython, objects in the python layer are
based on JVM (Java Virtual Machine) and CLR (Common Language Runtime)
objects, which can move around in memory. Both the JVM and the CLR can move
objects, so the location is not constant. Likewise for PyPy, which can
delete and re-create objects behind the scenes, possibly in different
memory locations.

This is why the id() function is NOT documented as returning the address of
an object, but of returning an ID number. Let's look at IDs in IronPython:

>>> a, b, c = [], 10000, "Hello world!"
>>> print id(a), id(b), id(c), id(None)
43 44 45 0


And in Jython:

>>> a, b, c = [], 10000, "Hello world!"
>>> print id(a), id(b), id(c), id(None)
1 2 3 4




-- 
Steven

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

#103864 — Re: Explaining names vs variables in Python

Steven D'Aprano <steve@pearwood.info>:

> On Wed, 2 Mar 2016 08:03 pm, Jesper K Brogaard wrote:
>
>> As I understand it, when you use 'is', you are comparing addresses to
>> objects, not the values contained in the objects. Use '==' instead.
>
> You should not think about addresses, because the location of objects
> is not part of the language. It is implementation-dependent.

The ontological question is, can two *distinct* objects with *identical*
characteristics exist?

The fermionic answer is, no.

The bosonic answer is, sure.

Set theory has fermionic ontology (it's called extensionality).

Python sits on the fence on that one, allowing either ontology.

> This is why the id() function is NOT documented as returning the
> address of an object, but of returning an ID number. Let's look at IDs
> in IronPython:
>
>>>> a, b, c = [], 10000, "Hello world!"
>>>> print id(a), id(b), id(c), id(None)
> 43 44 45 0
>
>
> And in Jython:
>
>>>> a, b, c = [], 10000, "Hello world!"
>>>> print id(a), id(b), id(c), id(None)
> 1 2 3 4

Python doesn't define or use the concept of an "address."


Marko

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

#103865 — Re: Explaining names vs variables in Python

On Wed, Mar 2, 2016 at 11:34 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
> The ontological question is, can two *distinct* objects with *identical*
> characteristics exist?
>
> The fermionic answer is, no.
>
> The bosonic answer is, sure.
>
> Set theory has fermionic ontology (it's called extensionality).
>
> Python sits on the fence on that one, allowing either ontology.

Python defines that every object has an identity, which can be
represented as an integer. Since this is an intrinsic part of the
object, no two distinct objects can truly have identical
characteristics. Python's objects are like rifles - there are many
like it, but this one is mine.

ChrisA

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

#103866 — Re: Explaining names vs variables in Python

Chris Angelico <rosuav@gmail.com> writes:

> Python defines that every object has an identity, which can be
> represented as an integer. Since this is an intrinsic part of the
> object, no two distinct objects can truly have identical
> characteristics. Python's objects are like rifles - there are many
> like it, but this one is mine.

Rifles are not mines. A rifle hurts you from a distance. A mine hurts
you when you step on it.

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

#103867 — Re: Explaining names vs variables in Python

Chris Angelico <rosuav@gmail.com>:

> Python defines that every object has an identity, which can be
> represented as an integer. Since this is an intrinsic part of the
> object, no two distinct objects can truly have identical
> characteristics. Python's objects are like rifles - there are many
> like it, but this one is mine.

How can you be sure Python isn't returning the same id value for two
distinct objects?


Marko

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

#103868 — Re: Explaining names vs variables in Python

On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
> Chris Angelico <rosuav@gmail.com>:
>
>> Python defines that every object has an identity, which can be
>> represented as an integer. Since this is an intrinsic part of the
>> object, no two distinct objects can truly have identical
>> characteristics. Python's objects are like rifles - there are many
>> like it, but this one is mine.
>
> How can you be sure Python isn't returning the same id value for two
> distinct objects?

The same way I can be sure about anything else in Python. It's a
language guarantee. If you're bothered by that, you should also be
concerned that str(x) might not actually call x.__str__(), or that
a+b*c might evaluate the addition before the multiplication.

ChrisA

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

#103870 — Re: Explaining names vs variables in Python

Chris Angelico <rosuav@gmail.com>:

> On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> Chris Angelico <rosuav@gmail.com>:
>>
>>> Python defines that every object has an identity, which can be
>>> represented as an integer. Since this is an intrinsic part of the
>>> object, no two distinct objects can truly have identical
>>> characteristics. Python's objects are like rifles - there are many
>>> like it, but this one is mine.
>>
>> How can you be sure Python isn't returning the same id value for two
>> distinct objects?
>
> The same way I can be sure about anything else in Python. It's a
> language guarantee.

Actually, my question is (intentionally) nonsensical.

The sameness or distinctness of two objects is not directly defined in
Python. The definition is simply:

   Two objects X and Y are called identical if

       X is Y

   evaluates to a true value.

Additionally, we have:

   If objects X and Y are identical, it is guaranteed that

      id(X) == id(Y)

   evaluates to a true value.

Even more strongly, we have:

   For any objects X and Y,

      id(X) == id(Y) if X is Y else id(X) != id(Y)

   evaluates to a true value.

What is missing is the rules that are obeyed by the "is" operator.


Marko

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

#103874 — Re: Explaining names vs variables in Python

On Wednesday, March 2, 2016 at 7:42:09 PM UTC+5:30, Marko Rauhamaa wrote:
> Chris Angelico :
> 
> > On Thu, Mar 3, 2016 at 12:39 AM, Marko Rauhamaa  wrote:
> >> Chris Angelico :
> >>
> >>> Python defines that every object has an identity, which can be
> >>> represented as an integer. Since this is an intrinsic part of the
> >>> object, no two distinct objects can truly have identical
> >>> characteristics. Python's objects are like rifles - there are many
> >>> like it, but this one is mine.
> >>
> >> How can you be sure Python isn't returning the same id value for two
> >> distinct objects?
> >
> > The same way I can be sure about anything else in Python. It's a
> > language guarantee.
> 
> Actually, my question is (intentionally) nonsensical.
> 
> The sameness or distinctness of two objects is not directly defined in
> Python. The definition is simply:
> 
>    Two objects X and Y are called identical if
> 
>        X is Y
> 
>    evaluates to a true value.
> 
> Additionally, we have:
> 
>    If objects X and Y are identical, it is guaranteed that
> 
>       id(X) == id(Y)
> 
>    evaluates to a true value.
> 
> Even more strongly, we have:
> 
>    For any objects X and Y,
> 
>       id(X) == id(Y) if X is Y else id(X) != id(Y)
> 
>    evaluates to a true value.
> 
> What is missing is the rules that are obeyed by the "is" operator.

is is not is
is is was
[fermionic or bosonic?]

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

#103885 — Re: Explaining names vs variables in Python

On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:

> What is missing is the rules that are obeyed by the "is" operator.

I think what is actually missing is some common bloody sense. The Python
docs are written in English, and don't define *hundreds*, possible
*thousands* of words because they are using their normal English meaning.

The docs for `is` say:

6.10.3. Identity comparisons

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.

https://docs.python.org/3/reference/expressions.html#is-not


In this case, "same object" carries the normal English meaning of "same" and
the normal computer science meaning of "object" in the sense of "Object
Oriented Programming". There's no mystery here, no circular definition.



-- 
Steven

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

#103886 — Re: Explaining names vs variables in Python

On Wednesday, March 2, 2016 at 10:53:40 PM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:
> 
> > What is missing is the rules that are obeyed by the "is" operator.
> 
> I think what is actually missing is some common bloody sense. The Python
> docs are written in English, and don't define *hundreds*, possible
> *thousands* of words because they are using their normal English meaning.
> 
> The docs for `is` say:
> 
> 6.10.3. Identity comparisons
> 
> 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.
> 
> https://docs.python.org/3/reference/expressions.html#is-not
> 
> 
> In this case, "same object" carries the normal English meaning of "same" and
> the normal computer science meaning of "object" in the sense of "Object
> Oriented Programming". There's no mystery here, no circular definition.
> 

http://plato.stanford.edu/entries/identity/

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

#103891 — Re: Explaining names vs variables in Python

Steven D'Aprano <steve@pearwood.info>:

> In this case, "same object" carries the normal English meaning of
> "same" and the normal computer science meaning of "object" in the
> sense of "Object Oriented Programming". There's no mystery here, no
> circular definition.

I see three possible ways of defining "is" / object identity (and other
concepts):

   1. hand waving ("normal English")

   2. reduction to an underlying model (a real / conceptual computer)

   3. formal semantics

All methods are in use. Experienced programmers have #2 in mind but are
embarrassed to admit they understand Python through C. Thus, they offer
explanation #1 to newbies, who are too embarrassed to admit they don't
get the explanation.

I think #3 could be tried more often. It is analogous to providing the
BNF of Python's syntax (which *is* done: <URL:
https://docs.python.org/3/reference/grammar.html>).


Marko

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

#103922 — Re: Explaining names vs variables in Python

On Thu, 3 Mar 2016 05:12 am, Marko Rauhamaa wrote:

> Steven D'Aprano <steve@pearwood.info>:
> 
>> In this case, "same object" carries the normal English meaning of
>> "same" and the normal computer science meaning of "object" in the
>> sense of "Object Oriented Programming". There's no mystery here, no
>> circular definition.
> 
> I see three possible ways of defining "is" / object identity (and other
> concepts):
> 
>    1. hand waving ("normal English")
> 
>    2. reduction to an underlying model (a real / conceptual computer)
> 
>    3. formal semantics
> 
> All methods are in use. Experienced programmers have #2 in mind but are
> embarrassed to admit they understand Python through C. Thus, they offer
> explanation #1 to newbies, who are too embarrassed to admit they don't
> get the explanation.

There is no evidence that newbies "don't get the explanation". Completely
the opposite: newbies frequently find the behaviour of `is` mysterious[1]
*until* it is explained to them in terms of "same object", after which it
becomes clear. (At least for those who understand what "object" means in
OOP terms.)

And then the same two people, you and Rustom, come along and insist that the
docs don't define `is` correctly and raising irrelevant philosophical
objections. But there's no evidence that these issues are the least bit
relevant to the newbies who asked the questions in the first place.


> I think #3 could be tried more often. 

I completely agree! It could be tried more often!

Other things that could be tried more often include:

- defining `is` through the medium of interpretive dance;

- defining `is` by wafting information-rich pheromones through the air;

- defining `is` by taking copious amounts of hallucinogens until your mind
becomes one with the universe and you intuitively understand everything.

But I think that in the case of Python, a combination of #1 and #2 are
needed.

(I think that nearly all people need to have some sort of concrete picture
in their heads for an object, even if they then go on to consciously reject
that picture as "just an implementation detail". Objects are not
necessarily C structs with a pointer back to a struct which represents the
object's class, but that's a common implementation.)



> It is analogous to providing the 
> BNF of Python's syntax (which *is* done: <URL:
> https://docs.python.org/3/reference/grammar.html>).

BNF is for describing syntax, not semantics. Nobody has trouble with the
syntax of `is`, it is a simple binary operator. There is no analogous
BNF-equivalent for semantics.





[1] Usually because they are either interpreting it as a synonym for
equality, or because they are confused by Python's caching of small ints
and some strings.


-- 
Steven

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

#103979 — Re: Explaining names vs variables in Python

On Thursday, March 3, 2016 at 7:22:43 AM UTC+5:30, Steven D'Aprano wrote:
> On Thu, 3 Mar 2016 05:12 am, Marko Rauhamaa wrote:
> 
> > Steven D'Aprano :
> > 
> >> In this case, "same object" carries the normal English meaning of
> >> "same" and the normal computer science meaning of "object" in the
> >> sense of "Object Oriented Programming". There's no mystery here, no
> >> circular definition.
> > 
> > I see three possible ways of defining "is" / object identity (and other
> > concepts):
> > 
> >    1. hand waving ("normal English")
> > 
> >    2. reduction to an underlying model (a real / conceptual computer)
> > 
> >    3. formal semantics
> > 
> > All methods are in use. Experienced programmers have #2 in mind but are
> > embarrassed to admit they understand Python through C. Thus, they offer
> > explanation #1 to newbies, who are too embarrassed to admit they don't
> > get the explanation.
> 
> There is no evidence that newbies "don't get the explanation". Completely
> the opposite: newbies frequently find the behaviour of `is` mysterious[1]
> *until* it is explained to them in terms of "same object", after which it
> becomes clear. (At least for those who understand what "object" means in
> OOP terms.)
> 
> And then the same two people, you and Rustom, come along and insist that the
> docs don't define `is` correctly and raising irrelevant philosophical
> objections. But there's no evidence that these issues are the least bit
> relevant to the newbies who asked the questions in the first place.

And now your English use of "same" in "same two people" is getting mysterious.
If you are suggesting that Marko are Rustom are the same person... that's mystical. [Maybe we should calculate their weight <wink>? ]

If I try to find a less far out meaning, I need to find some other something
by Marko and/or Rustom...  What??

And then there's Terry:

| The 'is' operator has three uses, two intended and one not. In 
| production code, 'is' tests that an object *is* a particular singular 
| object, such as None or a sentinel instance of class object. In test 
| code, 'is' can also be used to test details of a particular 
| implementation, such as pre-allocation of small ints. New python 
| programmers also use it to confuse themselves.

From https://mail.python.org/pipermail/python-list/2014-March/668136.html

And Peter Otten further up this same thread:
> You should not bother with object identity for objects other than None.

which, sotto voce, is saying much the same as Terry.

Is it so damn hard to be a bit honest and when asked about is in python to reply:

If you dont know what you are doing, dont use 'is' (None excepted)
If you know why are you asking?

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

#103986 — Re: Explaining names vs variables in Python

On Thu, Mar 3, 2016 at 10:03 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Is it so damn hard to be a bit honest and when asked about is in python to reply:
>
> If you dont know what you are doing, dont use 'is' (None excepted)
> If you know why are you asking?

That seems like a rather unhelpful response.

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

#103900 — Re: Explaining names vs variables in Python

On 02/03/2016 17:23, Steven D'Aprano wrote:
> On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:
>
>> What is missing is the rules that are obeyed by the "is" operator.
>
> I think what is actually missing is some common bloody sense. The Python
> docs are written in English, and don't define *hundreds*, possible
> *thousands* of words because they are using their normal English meaning.
>
> The docs for `is` say:
>
> 6.10.3. Identity comparisons
>
> 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.
>
> https://docs.python.org/3/reference/expressions.html#is-not
>
> In this case, "same object" carries the normal English meaning of "same" and
> the normal computer science meaning of "object" in the sense of "Object
> Oriented Programming". There's no mystery here, no circular definition.
>

Are we discussing UK (highly generalised), Geordie, Glaswegian, US, 
Canadian, South African, Australian, New Zealand, or some other form of 
English?

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

Mark Lawrence

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

#103923 — Re: Explaining names vs variables in Python

On Thu, 3 Mar 2016 08:49 am, Mark Lawrence wrote:

> On 02/03/2016 17:23, Steven D'Aprano wrote:
>> On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:
>>
>>> What is missing is the rules that are obeyed by the "is" operator.
>>
>> I think what is actually missing is some common bloody sense. The Python
>> docs are written in English, and don't define *hundreds*, possible
>> *thousands* of words because they are using their normal English meaning.
>>
>> The docs for `is` say:
>>
>> 6.10.3. Identity comparisons
>>
>> 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.
>>
>> https://docs.python.org/3/reference/expressions.html#is-not
>>
>> In this case, "same object" carries the normal English meaning of "same"
>> and the normal computer science meaning of "object" in the sense of
>> "Object Oriented Programming". There's no mystery here, no circular
>> definition.
>>
> 
> Are we discussing UK (highly generalised), Geordie, Glaswegian, US,
> Canadian, South African, Australian, New Zealand, or some other form of
> English?

To the best of my knowledge, `is` has the same meaning in all variants of
English (although there are sometimes differences in grammatical form,
e.g. "this be that" versus "this is that"). It is a very old word, and such
old words tend to have astonishingly stable semantics and irregular
spelling.

https://en.wiktionary.org/wiki/is#English
https://en.wiktionary.org/wiki/be#English



-- 
Steven

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

#103971 — Re: Explaining names vs variables in Python

On 03/03/2016 02:05, Steven D'Aprano wrote:
> On Thu, 3 Mar 2016 08:49 am, Mark Lawrence wrote:
>
>> On 02/03/2016 17:23, Steven D'Aprano wrote:
>>> On Thu, 3 Mar 2016 01:11 am, Marko Rauhamaa wrote:
>>>
>>>> What is missing is the rules that are obeyed by the "is" operator.
>>>
>>> I think what is actually missing is some common bloody sense. The Python
>>> docs are written in English, and don't define *hundreds*, possible
>>> *thousands* of words because they are using their normal English meaning.
>>>
>>> The docs for `is` say:
>>>
>>> 6.10.3. Identity comparisons
>>>
>>> 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.
>>>
>>> https://docs.python.org/3/reference/expressions.html#is-not
>>>
>>> In this case, "same object" carries the normal English meaning of "same"
>>> and the normal computer science meaning of "object" in the sense of
>>> "Object Oriented Programming". There's no mystery here, no circular
>>> definition.
>>>
>>
>> Are we discussing UK (highly generalised), Geordie, Glaswegian, US,
>> Canadian, South African, Australian, New Zealand, or some other form of
>> English?
>
> To the best of my knowledge, `is` has the same meaning in all variants of
> English (although there are sometimes differences in grammatical form,
> e.g. "this be that" versus "this is that"). It is a very old word, and such
> old words tend to have astonishingly stable semantics and irregular
> spelling.
>
> https://en.wiktionary.org/wiki/is#English
> https://en.wiktionary.org/wiki/be#English
>

That's all right then.

Perhaps we can now get back to the OP's question and not some bloody 
stupid philosophical discussion.

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

Mark Lawrence

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

#103901 — Re: Explaining names vs variables in Python

On Thu, Mar 3, 2016 at 8:49 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> Are we discussing UK (highly generalised), Geordie, Glaswegian, US,
> Canadian, South African, Australian, New Zealand, or some other form of
> English?

Is there any disagreement among them about the word "same"?

ChrisA

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web