On 17/02/2014 06:21, Steven D'Aprano wrote:
On Mon, 17 Feb 2014 11:54:45 +1300, Gregory Ewing wrote:
[...]
[1] Mathematicians tried this. "Everything is a set!" Yeah, right...
No, that's okay. You only get into trouble when you have self-referential
sets, like "the set of all sets that don't
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'
On Mon, Feb 17, 2014 at 5:21 PM, Steven D'Aprano
wrote:
> So before you ask: for-loops aren't things (values). Neither are while-
> loops, try...except blocks, pass statements, del statements, etc. Nor are
> names and other references -- I believe that there is a practice in
> certain areas of com
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
On Mon, 17 Feb 2014 11:54:45 +1300, 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
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"?
>>
>> ChrisA
>
> I know functions are objects, but what about statements
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
In article ,
Chris Angelico wrote:
> On Mon, Feb 17, 2014 at 9:54 AM, 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
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?
>
On Mon, Feb 17, 2014 at 9:54 AM, 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 m
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 error, just like the parser tells you. When the
parser sees "
Marko Rauhamaa writes:
> Case in point, if everything is a reference, how come:
>
>>>> "hello".__str__()
>'hello'
>>>> 1.__str__()
>SyntaxError: invalid syntax
>>> (1).__str__()
'1'
>>> 1..__str__()
'1.0'
--
Alan Bawden
--
https://mail.python.org/mailman/listinfo/
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 grasp.
>
> Case in point, if everything is a reference, ho
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'
>>>>> 1.__str__()
>>SyntaxError: invalid syntax
>
> You need parentheses around the
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, which model is easier for a beginner to grasp.
>
> Case in point, if ever
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 reference, how come:
>>> "hello".__str__()
'h
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
On 2/15/2014 1:07 AM, Rustom Mody wrote:
On Saturday, February 15, 2014 10:50:35 AM UTC+5:30, Ian wrote:
On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody wrote:
In the case of physical objects like dice there is a fairly
unquestionable framing that makes identity straightforward --
4-dimensional s
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
On Sat, Feb 15, 2014 at 10:30 AM, Rustom Mody wrote:
> 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 transfere
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
On Saturday, February 15, 2014 10:32:39 PM UTC+5:30, 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
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, it's part of Python's reference model. Any
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 everything in Python is an object, and
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.
In the Pyth
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
On Sat, Feb 15, 2014 at 9:13 PM, Marko Rauhamaa wrote:
> A new attempt:
Sorry, hadn't seen this when I posted.
>0. x is x
This is the definition of identity.
>1. if x is y then y ix x
Yes, because if x is y, there is absolutely no difference between
using one of those names or the oth
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 identical or not! The coordinate
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 help you predict the value of an "is" operator in
>>> the ambi
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
Ben Finney :
> You should never need to predict the result of an ‘is’ operation.
> (More precisely, for *some* cases you can predict it, but for other
> cases you can't.)
No problem there. You have to understand "is" well to use it.
Referring to "objects in memory" when defininig "is" leads to ci
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 help you predict the value of an "is" operator in
>> the ambiguous cases.
>
> Can you give an example of an ambiguous case?
The "x
Ned Batchelder :
> On 2/14/14 4:43 PM, Marko Rauhamaa wrote:
> Yes, sometimes for teaching reasons, you have to over-simplify or even
> introduce artificial constructs. I'd recommend acknowledging them as
> such.
>
> When you say, "There are two fundamentally different kinds of values
> in Python
On Fri, Feb 14, 2014 at 11:07 PM, Rustom Mody wrote:
> On Saturday, February 15, 2014 10:50:35 AM UTC+5:30, Ian wrote:
>> This is false. It happens to hold for CPython, but that's an
>> implementation detail. The definition of object identity does not
>> depend on memory address. It also doesn'
On Sat, Feb 15, 2014 at 5:54 PM, Steven D'Aprano
wrote:
> On Sat, 15 Feb 2014 15:37:20 +1100, Chris Angelico wrote:
>
> [...]
>> This is why dice exist in a variety of colors [1]. Indistinguishable yet
>> distinct dice...
>
> Since they have different colours, they can be distinguished and aren't
On Sat, Feb 15, 2014 at 5:44 PM, Steven D'Aprano
wrote:
> You just need to recognise that
> objects can contain themselves:
>
> py> L = []
> py> L.append(L)
> py> L in L
> True
>
>
> Of course, if you are a fan of the Doctor Who television show, you won't
> be concerned by this. If the TARDIS can
On Fri, 14 Feb 2014 22:20:35 -0700, Ian Kelly wrote:
> On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody
> wrote:
>> In the case of physical objects like dice there is a fairly
>> unquestionable framing that makes identity straightforward --
>> 4-dimensional space-time coordiantes. If the space-time c
On Sat, Feb 15, 2014 at 5:48 PM, Steven D'Aprano
wrote:
> On Sat, 15 Feb 2014 17:07:17 +1100, Chris Angelico wrote:
>
>> On Sat, Feb 15, 2014 at 4:36 PM, Steven D'Aprano
>> wrote:
>>> References can be names like `mystring`, or list items `mylist[0]`, or
>>> items in mappings `mydict["key"]`, or
On Sat, 15 Feb 2014 15:37:20 +1100, Chris Angelico wrote:
[...]
> This is why dice exist in a variety of colors [1]. Indistinguishable yet
> distinct dice...
Since they have different colours, they can be distinguished and aren't
indistinguishable.
One might also distinguish three dice by posit
On Sat, 15 Feb 2014 17:07:17 +1100, Chris Angelico wrote:
> On Sat, Feb 15, 2014 at 4:36 PM, Steven D'Aprano
> wrote:
>> References can be names like `mystring`, or list items `mylist[0]`, or
>> items in mappings `mydict["key"]`, or attributes `myobject.attr`, or
>> even expressions `x+y*(1-z)`.
On Fri, 14 Feb 2014 20:24:20 -0800, Rustom Mody wrote:
> In the case of physical objects like dice there is a fairly
> unquestionable framing that makes identity straightforward --
> 4-dimensional space-time coordiantes. If the space-time coordinates of 2
> objects are all equal then the objects a
On Saturday, February 15, 2014 11:49:38 AM UTC+5:30, Ben Finney wrote:
> Rustom Mody writes:
> > Then you are obliged to provide some other way of understanding
> > object-identity
> How about: Every object has an identity, which is unique among all
> concurrently-existing objects. The 'is' oper
On Saturday, February 15, 2014 11:45:00 AM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 14 Feb 2014 17:55:52 -0800, Rustom Mody wrote:
> > My own preference: No is operator; only id when we deliberately need to
> > poke into the implementation.
> > Of course I am in a miniscule minority I guess on t
On Sat, Feb 15, 2014 at 5:07 PM, Rustom Mody wrote:
> Nice point!
> I earlier talked of the macro problems of identity, viz across machines.
> You are bringing up a more 'micro' angle, viz gc.
> An even more micro (or lower level) example would be the mismatch between
> physical and virtual memory
On Fri, 14 Feb 2014 17:55:52 -0800, Rustom Mody wrote:
> My own preference: No is operator; only id when we deliberately need to
> poke into the implementation.
>
> Of course I am in a miniscule minority I guess on that :-)
If I have understood you, I think that's a poor way of looking at it. We
Rustom Mody writes:
> Then you are obliged to provide some other way of understanding
> object-identity
How about: Every object has an identity, which is unique among all
concurrently-existing objects. The ‘is’ operator queries whether two
references are referring to objects with the same identi
On Fri, 14 Feb 2014 19:00:36 -0500, Ned Batchelder wrote:
> On 2/14/14 4:43 PM, Marko Rauhamaa wrote:
>> Chris Angelico:
>>
>>> >be careful of simplifications that will cause problems down the line.
>> Sure. Let it be said, though, that sometimes you learn through
>> inaccuracies, a technique used
1 - 100 of 133 matches
Mail list logo
