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'm
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
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
Marko Rauhamaa ma...@pacujo.net:
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__()
On Feb 16, 2014 1:11 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Marko Rauhamaa ma...@pacujo.net:
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
On Sun, Feb 16, 2014 at 1:28 AM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Feb 16, 2014 1:11 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Case in point, if everything is a reference, how come:
hello.__str__()
'hello'
1.__str__()
SyntaxError: invalid syntax
You need
Marko Rauhamaa ma...@pacujo.net writes:
Marko Rauhamaa ma...@pacujo.net:
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
Marko Rauhamaa ma...@pacujo.net 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
--
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 1. it expects
On Sun, Feb 16, 2014 at 7:40 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
Ian Kelly ian.g.ke...@gmail.com:
(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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
On Sun, Feb 16, 2014 at 9:52 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
(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
On Sun, 16 Feb 2014 12:52:58 +0200, Marko Rauhamaa wrote:
Ian Kelly ian.g.ke...@gmail.com:
(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
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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
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
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 happily
Rustom Mody rustompm...@gmail.com:
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
On 16/02/2014 18:01, Marko Rauhamaa wrote:
Rustom Mody rustompm...@gmail.com:
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
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 assume
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
Chris Angelico wrote:
Because everything in Python is an object, and objects always are
handled by their references.
beginner_thought So, we have objects... and we have
references to objects... but everything is an object...
so does that mean references are objects too?
/beginner_thought
This
On Mon, Feb 17, 2014 at 9:54 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
Chris Angelico wrote:
Because everything in Python is an object, and objects always are
handled by their references.
beginner_thought So, we have objects... and we have
references to objects... but everything
Gregory Ewing greg.ew...@canterbury.ac.nz writes:
Chris Angelico wrote:
Because everything in Python is an object, and objects always are
handled by their references.
beginner_thought So, we have objects... and we have
references to objects... but everything is an object...
so does that
In article mailman.7074.1392591962.18130.python-l...@python.org,
Ben Finney ben+pyt...@benfinney.id.au wrote:
Gregory Ewing greg.ew...@canterbury.ac.nz writes:
Chris Angelico wrote:
Because everything in Python is an object, and objects always are
handled by their references.
In article mailman.7073.1392591754.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Mon, Feb 17, 2014 at 9:54 AM, Gregory Ewing
greg.ew...@canterbury.ac.nz wrote:
Chris Angelico wrote:
Because everything in Python is an object, and objects always are
handled by
Roy Smith r...@panix.com writes:
In article mailman.7074.1392591962.18130.python-l...@python.org,
Ben Finney ben+pyt...@benfinney.id.au wrote:
Gregory Ewing greg.ew...@canterbury.ac.nz writes:
beginner_thought So, we have objects... and we have references
to objects... but everything
On Mon, Feb 17, 2014 at 10:46 AM, Roy Smith r...@panix.com 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?
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.
beginner_thought So, we have objects... and we have
references to objects... but everything is an object...
so does that mean
On Mon, Feb 17, 2014 at 12:43 PM, Ned Batchelder n...@nedbatchelder.com 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
In article mailman.7079.1392602374.18130.python-l...@python.org,
Chris Angelico ros...@gmail.com wrote:
On Mon, Feb 17, 2014 at 12:43 PM, Ned Batchelder n...@nedbatchelder.com
wrote:
The correct statement is all values are objects, or all data is
objects.
When people mistakenly say
Roy Smith r...@panix.com writes:
Chris Angelico ros...@gmail.com 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.
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.
That said, all data
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 URL: http://docs.python.org/3.2/library/constants.html:
None
The sole value of the type NoneType.
Sole, adj. being the only one;
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 copying
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.
beginner_thought So, we have objects... and we have references to
objects... but everything is an object... so does
On Sun, 16 Feb 2014 18:43:15 -0500, Roy Smith wrote:
In article mailman.7074.1392591962.18130.python-l...@python.org,
Ben Finney ben+pyt...@benfinney.id.au wrote:
Gregory Ewing greg.ew...@canterbury.ac.nz writes:
Chris Angelico wrote:
Because everything in Python is an object, and
On Mon, Feb 17, 2014 at 5:21 PM, Steven D'Aprano
steve+comp.lang.pyt...@pearwood.info 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
On Fri, Feb 14, 2014 at 11:07 PM, Rustom Mody rustompm...@gmail.com 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.
Ned Batchelder n...@nedbatchelder.com:
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
Chris Angelico ros...@gmail.com:
On Sat, Feb 15, 2014 at 8:43 AM, Marko Rauhamaa ma...@pacujo.net 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
Ben Finney ben+pyt...@benfinney.id.au:
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
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
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 to
Christian Gollwitzer aurio...@gmx.de:
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
Marko Rauhamaa ma...@pacujo.net:
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
On Sat, 15 Feb 2014 11:10:46 +0200, Marko Rauhamaa wrote:
Chris Angelico ros...@gmail.com:
On Sat, Feb 15, 2014 at 8:43 AM, Marko Rauhamaa ma...@pacujo.net
wrote:
Unfortunately neither the everything is a reference model nor the
small/big model help you predict the value of an is operator
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 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 assume
On Sat, Feb 15, 2014 at 8:31 PM, Marko Rauhamaa ma...@pacujo.net 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
On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
Marko Rauhamaa ma...@pacujo.net:
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
On Sat, Feb 15, 2014 at 8:44 PM, Christian Gollwitzer aurio...@gmx.de 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, 37, 3, 4])
Still
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
On Sat, Feb 15, 2014 at 9:13 PM, Marko Rauhamaa ma...@pacujo.net 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
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 an
On Sat, Feb 15, 2014 at 10:32 PM, Gregory Ewing
greg.ew...@canterbury.ac.nz 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
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 put
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
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
Jussi Piitulainen jpiit...@ling.helsinki.fi 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
On Sat, Feb 15, 2014 at 11:18 PM, Gregory Ewing
greg.ew...@canterbury.ac.nz 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
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
Chris Angelico ros...@gmail.com:
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
Mark Lawrence breamore...@yahoo.co.uk:
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
Marko Rauhamaa ma...@pacujo.net 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
Joshua Landau jos...@landau.ws 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,
On Sun, Feb 16, 2014 at 1:20 AM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Joshua Landau jos...@landau.ws 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
On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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 ma...@pacujo.net:
It is not defined at all:
Every object has an identity, a type and a
On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa
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 an
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. But you
On Sat, Feb 15, 2014 at 10:30 AM, Rustom Mody rustompm...@gmail.com 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.
On Sat, Feb 15, 2014 at 11:37 AM, Ian Kelly ian.g.ke...@gmail.com 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.
On 2014-02-15, Chris Angelico ros...@gmail.com wrote:
On Sat, Feb 15, 2014 at 4:20 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Fri, Feb 14, 2014 at 9:24 PM, Rustom Mody rustompm...@gmail.com wrote:
To start with we say two objects are identical if they have the same
memory address.
This is
On Sat, 15 Feb 2014 12:02:39 -0500, Roy Smith wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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 ma...@pacujo.net:
It is not defined at
On Sat, 15 Feb 2014 18:29:59 +0200, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sat, 15 Feb 2014 14:07:35 +0200, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
On Sat, 15 Feb 2014 12:13:54 +0200, Marko Rauhamaa wrote:
5.
Ian Kelly ian.g.ke...@gmail.com:
On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa ma...@pacujo.net 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
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
On 15 February 2014 14:20, Ben Finney ben+pyt...@benfinney.id.au wrote:
Joshua Landau jos...@landau.ws 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
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
On Sat, Feb 15, 2014 at 1:20 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Ian Kelly ian.g.ke...@gmail.com:
On Sat, Feb 15, 2014 at 9:29 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Thus x and y are identical *means* x is y and nothing else.
This notion of identity sounds useless, and if that is
On Sun, Feb 16, 2014 at 7:44 AM, Joshua Landau jos...@landau.ws wrote:
On 15 February 2014 14:20, Ben Finney ben+pyt...@benfinney.id.au wrote:
Joshua Landau jos...@landau.ws writes:
Here, I give you a pdf. Hopefully this isn't anti
mailing-list-etiquette.
This forum is read in many
On Sat, 15 Feb 2014 23:01:53 +0200, Marko Rauhamaa wrote:
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info:
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
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 be
Hello,
Background: My twelve y/o son and I are still working our way through Invent
Your Own Computer Games with Python, 2nd Edition.
(We finished the Khan Academy Javascript Tutorials is the extent of our
experience)
He is asking a question I am having trouble answering which is how a
dave em writes:
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.
My quite serious answer is: not at all. In particular, a list is a
value.
All those pointers to
On 2/14/14 1:08 PM, dave em wrote:
Hello,
Background: My twelve y/o son and I are still working our way through Invent
Your Own Computer Games with Python, 2nd Edition.
(We finished the Khan Academy Javascript Tutorials is the extent of our
experience)
He is asking a question I am having
On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote:
dave em writes:
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.
My
On 02/14/2014 12:08 PM, dave em wrote:
Hello,
Background: My twelve y/o son and I are still working our way through Invent
Your Own Computer Games with Python, 2nd Edition.
(We finished the Khan Academy Javascript Tutorials is the extent of our
experience)
He is asking a question I am
On Fri, 14 Feb 2014 10:54:29 -0800, dave em wrote:
On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote:
dave em writes:
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
dave em daveandem2...@gmail.com:
Case 1: Example of variable with a specific value from P 170 of IYOCGWP
spam = 42
cheese = spam
spam = 100
spam
100
cheese
42
Case 2: Example of variable with a list reference from p 170
spam = [0, 1, 2, 3, 4, 5]
cheese = spam
cheese[1] = 'Hello!'
On Fri, Feb 14, 2014 at 11:54 AM, dave em daveandem2...@gmail.com wrote:
Thanks for your quick response. I'm still not sure we understand. The code
below illustrates the concept we are trying to understand.
Case 1: Example of variable with a specific value from P 170 of IYOCGWP
spam = 42
On Fri, Feb 14, 2014 at 12:56 PM, Marko Rauhamaa ma...@pacujo.net wrote:
There are two fundamentally different kinds of values in Python: small
values and big values. A variable can only hold a small value. A list
element can only hold a small value. A dictionary entry can only hold a
small
dave em writes:
On Friday, February 14, 2014 11:26:13 AM UTC-7, Jussi Piitulainen wrote:
dave em writes:
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.
On 2/14/14 3:17 PM, Ian Kelly wrote:
On Fri, Feb 14, 2014 at 12:56 PM, Marko Rauhamaa ma...@pacujo.net wrote:
There are two fundamentally different kinds of values in Python: small
values and big values. A variable can only hold a small value. A list
element can only hold a small value. A
Ian Kelly ian.g.ke...@gmail.com:
This is nonsense. Python the language makes no such distinction
between big and small values. *All* objects in CPython are stored
internally on the heap. Other implementations may use different memory
management schemes.
You're right, of course. Conceptually,
On Sat, Feb 15, 2014 at 7:58 AM, Marko Rauhamaa ma...@pacujo.net wrote:
Say you write:
1 + 2
You may not find it most intuitive to follow through the object
instantiation and reference manipulation implicit in the everything is
a reference model when you think you understand numbers but
1 - 100 of 134 matches
Mail list logo
