Tim Chase writes:
> On 2014-03-04 08:10, Ben Finney wrote:
> > Short answer: Use ‘use’ any time you need to compare object
> > identity. You usually do not need to compare object identity.
Damn it, a snappy response marred by a typo.
> I think there use something wrong with that sentence...unle
On 2014-03-04 08:10, Ben Finney wrote:
> > Long answer:
> > http://www.beyondwilber.ca/healing-thinking/non-identity-korzybski.html
>
> Interesting, but mostly a distraction for the querent here.
>
> Short answer: Use ‘use’ any time you need to compare object
> identity. You usually do not need
Rustom Mody writes:
> Short answer: Avoid using 'is'.
This is bad advice in a Python forum.
The ‘is’ operator is commonly used in Python, so please don't advise
against it in an unqualified “short answer”.
> Long answer:
> http://www.beyondwilber.ca/healing-thinking/non-identity-korzybski.ht
On 3/3/2014 4:42 AM, ast wrote:
Consider following code:
A=7
B=7
A is B
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
On Monday, March 3, 2014 3:12:30 PM UTC+5:30, ast wrote:
> hello
> Consider following code:
> >>> A=7
> >>> B=7
> >>> A is B
> True
> I understand that there is a single object 7 somewhere in memory and
> both variables A and B point toward this object 7
> now do the same with a list:
> >>> l1
On 2014-03-03, ast wrote:
> hello
>
> Consider following code:
>
A=7
B=7
A is B
> True
>
> I understand that there is a single object 7 somewhere in memory
Maybe, maybe not. Integer are immutable, so that's allowed but not
required. In CPython, that's true for small integers, but
On Monday, March 3, 2014 3:42:30 AM UTC-6, ast wrote:
> Consider following code:
>
> >>> A=7
> >>> B=7
> >>> A is B
> True
The names A and B are both bound to the same object (7).
You will discover that this is True for all small ints less
than 257; on CPython3.3.4. I just checked it. :)
I
thanks ben, that's clear
--
https://mail.python.org/mailman/listinfo/python-list
“A” and “B”
are bound to that object.
The distinction is subtle; but it's important to realise that *all*
references in Python do this, and there's no way to talk about an object
in Python without using a reference. The “pointer” model from other
languages doesn't exist in Pyt
hello
Consider following code:
A=7
B=7
A is B
True
I understand that there is a single object 7 somewhere in memory and
both variables A and B point toward this object 7
now do the same with a list:
l1 = [1, 2]
l2 = [1, 2]
l1 is l2
False
It seems this time that there are 2 distincts obje
In <9b80c233-ad31-44c8-8a6e-9002ab11b...@googlegroups.com> Nir
writes:
> >>> k = ['hi','boss']
> >>>
> >>> k
> ['hi', 'boss']
> >>> k= [s.upper for s in k]
> >>> k
> [, method upper of str object at 0x02283F58>]
> Why doesn't the python interpreter just return
> ['HI, 'BOSS'] ?
> This
ell-founded_set_theory
The trouble comes not with self-reference, but with unrestricted
comprehension.
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Feb 17, 2014 at 11:00 AM, Nir wrote:
k = ['hi','boss']
k
> ['hi', 'boss']
k= [s.upper for s in k]
k
> [, method upper of str object at 0x02283F58>]
>
> Why doesn't the python interpreter just return
> ['HI, 'BOSS'] ?
It's just doing exactly what you are t
Nir :
k= [s.upper for s in k]
k
> [, method upper of str object at 0x02283F58>]
>
> Why doesn't the python interpreter just return
> ['HI, 'BOSS'] ?
Try:
k = [ s.upper() for s in k ]
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On 02/17/2014 09:00 AM, Nir wrote:
k = ['hi','boss']
k
['hi', 'boss']
k= [s.upper for s in k]
s.upper is a reference to the method upper of s -- to execute the method
add parens -- s.upper()
Emile
k
[, ]
Why doesn't the python interpre
it does this.
You have to invoke s.upper, with parens:
k = [s.upper() for s in k]
In Python, a function or method is a first-class object, so "s.upper" is
a reference to the method, "s.upper()" is the result of calling the method.
--
Ned Batchelder, http://nedbatchelder.com
--
https://mail.python.org/mailman/listinfo/python-list
On Feb 17, 2014 12:05 PM, "Nir" wrote:
>
> >>> k = ['hi','boss']
> >>>
> >>> k
> ['hi', 'boss']
> >>> k= [s.upper for s in k
S.upper()
> >>> k
> [, ]
>
> Why doesn't the python interpreter just return
> ['HI, 'BOSS'] ?
>
> This isn't a big deal, but I am just curious as to why it does this.
> --
>
>>> k = ['hi','boss']
>>>
>>> k
['hi', 'boss']
>>> k= [s.upper for s in k]
>>> k
[, ]
Why doesn't the python interpreter just return
['HI, 'BOSS'] ?
This isn't a big deal, but I am just curious as to why it does this.
--
https://mail.python.org/mailman/listinfo/python-list
On Monday, February 17, 2014 12:01:18 PM UTC+5:30, Steven D'Aprano wrote:
> I take it that you haven't spent much time around beginners? Perhaps you
> should spend some time on the "tutor" mailing list. If you do, you will
> see very few abstract or philosophical questions such as whether
> refe
On Sun, 16 Feb 2014 22:28:23 -0500, Roy Smith wrote:
>> So when does code become data? When it's represented by an object.
>
> OK, now take somebody who knows lisp and try to explain to him or her
> why Python's eval() doesn't mean data is code. Yeah, I know that's
> pushing things a bit, but I'
In most languages, every l-value is also an r-value,
by definition.)
In C, for instance, any simple variable is an l-value, except for
those that are constants (you can't assign to an array). A
dereferenced pointer is also an l-value, as is a structure element
reference. An expressi
On Sun, 16 Feb 2014 18:43:15 -0500, Roy Smith wrote:
> In article ,
> Ben Finney wrote:
>
>> Gregory Ewing writes:
>>
>> > Chris Angelico wrote:
>> > > Because everything in Python is an object, and objects always are
>> > > handled by their references.
>> >
>> > So, we have objects... and w
n object... so does that mean references
> are objects too?
Every *thing* is an object. References aren't *things*. An analogy: there
is no thing "Greg Ewing" which is independent of you, there is you, the
thing with an independent existence, and then there is the reference (or
On Mon, 17 Feb 2014 11:40:57 +1300, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> And indeed numpy arrays do share state. Why? No idea. Somebody thought
>> that it was a good idea. (Not me though...)
>
> Probably because they're often large and people don't want to incur the
> overhead of copy
On Sun, 16 Feb 2014 20:01:46 +0200, Marko Rauhamaa wrote:
> As far as "x is None" is concerned, a key piece of information is
> presented on http://docs.python.org/3.2/library/constants.html>:
>
> None
> The sole value of the type NoneType.
Sole, adj. "being the only one; si
On Monday, February 17, 2014 8:58:23 AM UTC+5:30, Roy Smith wrote:
> Chris Angelico wrote:
> > > The correct statement is "all values are objects", or "all data is
> > > objects".
> > > When people mistakenly say "everything is an object", they are implicitly
> > > only thinking about data.
> >
Roy Smith writes:
> Chris Angelico wrote:
> > Part of the trouble is that some code is (represented by) objects. A
> > function is an object, ergo it's data; a module is an object (though
> > that's different); a class is an object; but no other block of code
> > is.
>
> Lambda?
The ‘lambda’ s
In article ,
Chris Angelico wrote:
> On Mon, Feb 17, 2014 at 12:43 PM, Ned Batchelder
> wrote:
> > The correct statement is "all values are objects", or "all data is
> > objects".
> > When people mistakenly say "everything is an object", they are implicitly
> > only thinking about data.
> >
>
On Mon, Feb 17, 2014 at 12:43 PM, Ned Batchelder wrote:
> The correct statement is "all values are objects", or "all data is objects".
> When people mistakenly say "everything is an object", they are implicitly
> only thinking about data.
>
> That said, "all data is objects" is really mostly usefu
On 2/16/14 5:54 PM, Gregory Ewing wrote:
Chris Angelico wrote:
Because everything in Python is an object, and objects always are
handled by their references.
So, we have objects... and we have
references to objects... but everything is an object...
so does that mean references are objects too
On Mon, Feb 17, 2014 at 10:46 AM, Roy Smith wrote:
>> References aren't themselves objects. Names, attributes, etc, etc,
>> etc, all refer to objects. Is it clearer to use the verb "refer"
>> rather than the noun "reference"?
>>
>>
Roy Smith writes:
> In article ,
> Ben Finney wrote:
>
> > Gregory Ewing writes:
> > > So, we have objects... and we have references
> > > to objects... but everything is an object... so does that mean
> > > references are objects too?
> >
> > My response: No, because references are not thi
gt; So, we have objects... and we have
> > references to objects... but everything is an object...
> > so does that mean references are objects too?
> >
>
> References aren't themselves objects. Names, attributes, etc, etc,
> etc, all refer to objects. Is i
In article ,
Ben Finney wrote:
> Gregory Ewing writes:
>
> > Chris Angelico wrote:
> > > Because everything in Python is an object, and objects always are
> > > handled by their references.
> >
> > So, we have objects... and we have
> > references to objects... but everything is an object...
Gregory Ewing writes:
> Chris Angelico wrote:
> > Because everything in Python is an object, and objects always are
> > handled by their references.
>
> So, we have objects... and we have
> references to objects... but everything is an object...
> so does that mean references are objects too?
>
ng is an object...
> so does that mean references are objects too?
>
References aren't themselves objects. Names, attributes, etc, etc,
etc, all refer to objects. Is it clearer to use the verb "refer"
rather than the noun "reference"?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Chris Angelico wrote:
Because everything in Python is an object, and objects always are
handled by their references.
So, we have objects... and we have
references to objects... but everything is an object...
so does that mean references are objects too?
This is the kind of trouble you get in
Steven D'Aprano wrote:
And indeed numpy arrays do share state. Why? No idea. Somebody thought
that it was a good idea. (Not me though...)
Probably because they're often large and people don't
want to incur the overhead of copying them any more
than necessary. So slices are defined to return vie
On Sat, 15 Feb 2014 10:44:39 +0100, Christian Gollwitzer wrote:
> Am 15.02.14 01:57, schrieb Chris Angelico:
>> Can you give an example of an ambiguous case? Fundamentally, the 'is'
>> operator tells you whether its two operands are exactly the same
>> object, nothing more and nothing less, so I a
On 16/02/2014 18:01, Marko Rauhamaa wrote:
Rustom Mody :
But for that Ive to use is
And as a teacher Ive to explain is
Might as well use C and get on with pointers
To me 'is' is a can of worms
I'm not against "is," but it must be carefully defined and taught.
As far as "x is None" is concer
Rustom Mody :
> But for that Ive to use is
> And as a teacher Ive to explain is
> Might as well use C and get on with pointers
>
> To me 'is' is a can of worms
I'm not against "is," but it must be carefully defined and taught.
As far as "x is None" is concerned, a key piece of information is
pre
On Sunday, February 16, 2014 9:59:53 PM UTC+5:30, Ned Batchelder wrote:
> On 2/16/14 9:00 AM, Rustom Mody wrote:
> > On Saturday, February 15, 2014 7:14:39 PM UTC+5:30, Marko Rauhamaa wrote:
> >> Mark Lawrence:
> >>> I have no interest in understanding object identity, I can write code
> >>> quite
On 2/16/14 9:00 AM, Rustom Mody wrote:
On Saturday, February 15, 2014 7:14:39 PM UTC+5:30, Marko Rauhamaa wrote:
Mark Lawrence:
I have no interest in understanding object identity, I can write code
quite happily without it.
Luckily, what we are now debating is mostly terminology and points
Steven D'Aprano :
> On Sun, 16 Feb 2014 12:52:58 +0200, Marko Rauhamaa wrote:
>> The syntactic awkwardness, then, explains why numbers don't have an
>> evolved set of methods (unlike strings).
>
> But numbers do have an evolved set of methods.
> [...]
> py> from decimal import Decimal
> py> [name
On Saturday, February 15, 2014 7:14:39 PM UTC+5:30, Marko Rauhamaa wrote:
> Mark Lawrence:
> > I have no interest in understanding object identity, I can write code
> > quite happily without it.
> Luckily, what we are now debating is mostly terminology and points of
> view where the outcomes are
On Sun, 16 Feb 2014 12:52:58 +0200, Marko Rauhamaa wrote:
> Ian Kelly :
>
> (1).__str__()
>> '1'
>
> Fair enough.
>
> The syntactic awkwardness, then, explains why numbers don't have an
> evolved set of methods (unlike strings).
But numbers do have an evolved set of methods.
py> [name fo
On Sun, Feb 16, 2014 at 9:52 PM, Marko Rauhamaa wrote:
> Ian Kelly :
>
> (1).__str__()
>> '1'
>
> Fair enough.
>
> The syntactic awkwardness, then, explains why numbers don't have an
> evolved set of methods (unlike strings).
No; it's more that numbers are more often used with either operator
Steven D'Aprano :
> On Sat, 15 Feb 2014 23:01:53 +0200, Marko Rauhamaa wrote:
> I demonstrated a situation where your claim:
>
> id(x) == id(y) implies x is y
>
> fails.
My from-the-hip formulation can obviously be inaccurate, but I was
hoping the point was clear.
The Python language specifi
Ian Kelly :
(1).__str__()
> '1'
Fair enough.
The syntactic awkwardness, then, explains why numbers don't have an
evolved set of methods (unlike strings).
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Sun, Feb 16, 2014 at 7:40 PM, Steven D'Aprano
wrote:
> There are three simple ways to get the effect that you want:
>
> py> x = 1; x.__str__() # don't use a literal
> '1'
> py> (1).__str__() # parenthesize the literal
> '1'
> py> 1 .__str__() # offset it from the dot with a space
> '1'
Four
On Sun, 16 Feb 2014 10:08:22 +0200, Marko Rauhamaa wrote:
> Case in point, if everything is a reference, how come:
>
>>>> "hello".__str__()
>'hello'
>>>> 1.__str__()
>SyntaxError: invalid syntax
Because it is a syntax erro
Marko Rauhamaa writes:
> Case in point, if everything is a reference, how come:
>
>>>> "hello".__str__()
>'hello'
>>>> 1.__str__()
>SyntaxError: invalid syntax
>>> (1).__str__()
'1'
>>>
Marko Rauhamaa writes:
> Marko Rauhamaa :
>
> > Conceptually, the "everything is a reference" and the "small"/"big"
> > distinction are equivalent (produce the same outcomes). The question
> > is, which model is easier for a beginner to g
On Sun, Feb 16, 2014 at 1:28 AM, Ian Kelly wrote:
>
> On Feb 16, 2014 1:11 AM, "Marko Rauhamaa" wrote:
>> Case in point, if everything is a reference, how come:
>>
>>>>> "hello".__str__()
>>'hello'
>>>&g
On Feb 16, 2014 1:11 AM, "Marko Rauhamaa" wrote:
>
> Marko Rauhamaa :
>
> > Conceptually, the "everything is a reference" and the "small"/"big"
> > distinction are equivalent (produce the same outcomes). The question
> > is, w
Marko Rauhamaa :
> Conceptually, the "everything is a reference" and the "small"/"big"
> distinction are equivalent (produce the same outcomes). The question
> is, which model is easier for a beginner to grasp.
Case in point, if everything is a refer
On Sat, 15 Feb 2014 15:40:54 -0500, Terry Reedy wrote:
> 'Identity' is an abstraction. For immutable objects, it is essentially
> irrelevant. For mutable objects, it is essential in the following sense.
> A and B are the same object if mutating A necessarily mutates B and
> different if they can
On Sat, 15 Feb 2014 23:01:53 +0200, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote:
>>> Nowhere do I see the violating "x is y".
>>
>> Do you truly think that there is even the tiniest, most microscopic
>> chance that the int 23 which h
On Sun, Feb 16, 2014 at 7:44 AM, Joshua Landau wrote:
> On 15 February 2014 14:20, Ben Finney wrote:
>> Joshua Landau writes:
>>
>>> Here, I give you a pdf. Hopefully this isn't anti
>>> mailing-list-etiquette.
>>
>> This forum is read in many different contexts, and attachments aren't
>> approp
On Sat, Feb 15, 2014 at 1:20 PM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa wrote:
>>> Thus "x and y are identical" *means* "x is y" and nothing else.
>>
>> This notion of identity sounds useless, and if that is the way you
>> prefer to understand it
Steven D'Aprano :
> On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote:
>> Nowhere do I see the violating "x is y".
>
> Do you truly think that there is even the tiniest, most microscopic
> chance that the int 23 which has been garbage-collected and no
> longer exists, and the int 42
On 15 February 2014 14:20, Ben Finney wrote:
> Joshua Landau writes:
>
>> Here, I give you a pdf. Hopefully this isn't anti
>> mailing-list-etiquette.
>
> This forum is read in many different contexts, and attachments aren't
> appropriate. You should simply put the text directly into your message
concept of object identity is an
abstraction, not an analogy from physics.
The language reference states, "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."
Oka
Ian Kelly :
> On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa wrote:
>> Thus "x and y are identical" *means* "x is y" and nothing else.
>
> This notion of identity sounds useless, and if that is the way you
> prefer to understand it then you can safely ignore that it exists. I
> think that most u
On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote:
> Steven D'Aprano :
>> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
>>> Steven D'Aprano :
On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>5. id(x) == id(y) iff x is y
# Counter-example
py>
On Sat, 15 Feb 2014 12:02:39 -0500, Roy Smith wrote:
> Steven D'Aprano :
>> > Object identity is simple and well-defined in Python. I don't know
>> > why you are so resistant to this. Read the documentation.
>
> Marko Rauhamaa :
>> It is not defined at all:
>>
>>Every object has an identity,
On 2014-02-15, Chris Angelico wrote:
> On Sat, Feb 15, 2014 at 4:20 PM, Ian Kelly wrote:
>> On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody wrote:
>>> To start with we say two objects are identical if they have the same
>>> memory address.
>>
>> This is false. It happens to hold for CPython, but t
On Sat, Feb 15, 2014 at 11:37 AM, Ian Kelly wrote:
> But what is a set? Cantor offers this definition:
>
> """
> A set is a gathering together into a whole of definite, distinct
> objects of our perception [Anschauung] or of our thought - which are
> called elements of the set.
> """
>
> But what
he problem remains. Youve transfered the identity
> question into the lifetime.
>
> Now define object-lifetime without reference to identity :-)
Fundamentally that's what definitions do. They transfer the question
of "what is X" to "okay, so what is this thing that defines X&
On Saturday, February 15, 2014 9:59:59 PM UTC+5:30, Marko Rauhamaa wrote:
> Steven D'Aprano:
> > Object identity is simple and well-defined in Python. I don't know why
> > you are so resistant to this. Read the documentation.
> It is not defined at all:
In a certain way thats what I am saying. Bu
describe some fun things you can do with it:
Thanks! -- Nice to hear slightly more philosophically astute attempt than
the naivete going around: "Object?! We all know whats an object!
Everyone knows whats an object!!"
However I am betting that the problem remains. Youve transfered the identi
On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa wrote:
> Steven D'Aprano :
>> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
>>> Steven D'Aprano :
On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>5. id(x) == id(y) iff x is y
# Counter-example
py> x
Steven D'Aprano :
> > Object identity is simple and well-defined in Python. I don't know why
> > you are so resistant to this. Read the documentation.
Marko Rauhamaa :
> It is not defined at all:
>
>Every object has an identity, a type and a value. An objectâs
>identity never changes on
Steven D'Aprano :
> On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
>> Steven D'Aprano :
>>> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
5. id(x) == id(y) iff x is y
>>>
>>> # Counter-example
>>> py> x = 23
>>> py> idx = id(x)
>>> py> del x
>>> py> y = 42
>>>
On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
> Steven D'Aprano :
>
>> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>>>0. x is x
>>>1. if x is y then y ix x
>>>2. if x is y and y is z then x is z
>>>3. after x = y, x is y
>>>4. if x is y and x == x, th
On Sun, Feb 16, 2014 at 1:20 AM, Ben Finney wrote:
> Joshua Landau writes:
>
>> Here, I give you a pdf. Hopefully this isn't anti
>> mailing-list-etiquette.
>
> This forum is read in many different contexts, and attachments aren't
> appropriate. You should simply put the text directly into your m
Joshua Landau writes:
> Here, I give you a pdf. Hopefully this isn't anti
> mailing-list-etiquette.
This forum is read in many different contexts, and attachments aren't
appropriate. You should simply put the text directly into your message,
if it's short enough.
If it's long, then put it onlin
Marko Rauhamaa writes:
> Anyway, an object is a fairly advanced and abstract concept.
It is a concept that, in natural language, has the huge advantage of
producing correct inferences most of the time.
You don't need to give a formal definition when first introducing the
term “object”. Just use
Mark Lawrence :
> I have no interest in understanding object identity, I can write code
> quite happily without it.
Luckily, what we are now debating is mostly terminology and points of
view where the outcomes are unaffected.
However, as an example, it is important to know if you should write:
Chris Angelico :
> Because everything in Python is an object, and objects always are
> handled by their references. This wouldn't be true in every language
> (eg it's not true of Java's unboxed types), but it's intrinsic to
> Python's object model.
Well,
On 15/02/2014 06:07, Rustom Mody wrote:
Then you are obliged to provide some other way of understanding object-identity
I have no interest in understanding object identity, I can write code
quite happily without it. If you (plural) are interested in
understanding this subject I hope you enjo
On Sat, Feb 15, 2014 at 11:18 PM, Gregory Ewing
wrote:
> Chris Angelico wrote:
>>
>> But yes, this is an expression, and it evaluates to a reference.
>
>
> Well, *all* expressions in Python evaluate to references,
> so that's not really saying much.
Because everyt
Jussi Piitulainen writes:
> In cheese = spam, cheese is the variable while spam is a variable
> reference and stands for 42.
Oof. This distinction between “variable” and “variable reference” is
bogus and unnecessary, and highlights what is wrong with talking about
“variable” at all.
Chris Angelico wrote:
But yes, this is an expression, and it evaluates to a reference.
Well, *all* expressions in Python evaluate to references,
so that's not really saying much.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano :
> On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
>>0. x is x
>>1. if x is y then y ix x
>>2. if x is y and y is z then x is z
>>3. after x = y, x is y
>>4. if x is y and x == x, then x == y
>>5. id(x) == id(y) iff x is y
>
> # Counter-example
>
Jussi Piitulainen wrote:
Would it help to say that in case 1 the relevant statement acts on the
variable while in case 2 it acts on the value of the variable?
I would try to avoid using words like "value" and "variable",
because they don't have well-defined meanings in Python.
The way I would
On Sat, Feb 15, 2014 at 10:32 PM, Gregory Ewing
wrote:
> Steven D'Aprano wrote:
>>
>> IDs are a proxy for distinct objects. If you live in a country with an ID
>> card of some sort, then the IDs acts as an identifier for each unique
>> individual. But countries without ID cards don't lack unique i
Steven D'Aprano wrote:
IDs are a proxy for distinct objects. If you live in a country with an ID
card of some sort, then the IDs acts as an identifier for each unique
individual. But countries without ID cards don't lack unique individual
people.
"You are Number Six."
"I am not an id()! I am
3443 or not?", regardless of the name you
use to access that object.
> 5. id(x) == id(y) iff x is y
This is the definition of id(). Note that it does depend on something
holding a reference to each of x and y; if it's possible for the
objects' lifetimes to not overlap, it'
Steven D'Aprano wrote:
(1) General relativity tells us that not all observers will agree on the
space-time coordinates of two objects, since not all observers agree on a
single frame of reference.
But that doesn't mean they won't agree about whether
objects are identi
On Sat, Feb 15, 2014 at 8:44 PM, Christian Gollwitzer wrote:
import numpy as np
a=np.array([1, 2, 3, 4])
b=a[:]
id(a)
> 140267900969344
id(b)
> 140267901045920
>
> So, a and b are different things, right?
>
b[1]=37
b
> array([ 1, 37, 3, 4])
a
> array([ 1,
On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
> Marko Rauhamaa :
>
>> 1. if x is y then y ix x
>> 2. if x is y and y is z then x is z
>> 3. after x = y, x is y
>> 4. if x is y, then x == y
>
> A new attempt:
>
>0. x is x
>1. if x is y then y ix x
>2. if x is y an
On Sat, Feb 15, 2014 at 8:31 PM, Marko Rauhamaa wrote:
> Referring to "objects in memory" when defininig "is" leads to circular
> definitions. It think the best way to define the semantics of "is" is
> through constraints:
>
> 1. if x is y then y ix x
>
> 2. if x is y and y is z then x is z
>
On Sat, 15 Feb 2014 10:44:39 +0100, Christian Gollwitzer wrote:
> Am 15.02.14 01:57, schrieb Chris Angelico:
>> Can you give an example of an ambiguous case? Fundamentally, the 'is'
>> operator tells you whether its two operands are exactly the same
>> object, nothing more and nothing less, so I a
On Sat, 15 Feb 2014 11:31:42 +0200, Marko Rauhamaa wrote:
> It think the best way to define the semantics of "is" is
> through constraints:
>
> 1. if x is y then y ix x
>
> 2. if x is y and y is z then x is z
>
> 3. after x = y, x is y
>
> 4. if x is y, then x == y
Incorrect.
py> x
On Sat, 15 Feb 2014 11:10:46 +0200, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> On Sat, Feb 15, 2014 at 8:43 AM, Marko Rauhamaa
>> wrote:
>>> Unfortunately neither the "everything is a reference" model nor the
>>> "small/big" model h
Marko Rauhamaa :
> 1. if x is y then y ix x
> 2. if x is y and y is z then x is z
> 3. after x = y, x is y
> 4. if x is y, then x == y
A new attempt:
0. x is x
1. if x is y then y ix x
2. if x is y and y is z then x is z
3. after x = y, x is y
4. if x is y and x == x, then
Christian Gollwitzer :
> Still they are connected. I can imagin that id() is just a debugging
> tool for extensions. What useful applications does it have outside of
> this?
Calculating hash keys quickly.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Am 15.02.14 01:57, schrieb Chris Angelico:
Can you give an example of an ambiguous case? Fundamentally, the 'is'
operator tells you whether its two operands are exactly the same
object, nothing more and nothing less, so I assume your "ambiguous
cases" are ones where it's possible for two things t
Hi Dave,
Am 14.02.14 19:08, schrieb dave em:
He is asking a question I am having trouble answering which is how a
variable containing a value differs from a variable containing a list
or more specifically a list reference.
as others have explained better and in more detail, there are mutable
401 - 500 of 1823 matches
Mail list logo
