On Wed, Sep 16, 2015 at 6:24 PM, Ben Finney wrote:
> Chris Angelico writes:
>
>> On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
>> wrote:
>> > This suggests an alternative model for Python computation. All data
>> > is represented by cats. A variable is a box containing a cat.
>> > Assignment re
Chris Angelico writes:
> On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
> wrote:
> > This suggests an alternative model for Python computation. All data
> > is represented by cats. A variable is a box containing a cat.
> > Assignment replaces one cat with an entangled copy of another cat,
> > so
On Wed, Sep 16, 2015 at 6:14 PM, Gregory Ewing
wrote:
> Emile van Sebille wrote:
>
>> Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs,
>
>
> The real question is, if you kill Schroedinger's cat, does
> Heisenberg's cat die too? If so, then either they're the
> same cat, or they're two entangl
Emile van Sebille wrote:
Shroedingers-cat-was-just-a-cat-in-a-box-too-ly y'rs,
The real question is, if you kill Schroedinger's cat, does
Heisenberg's cat die too? If so, then either they're the
same cat, or they're two entangled cats.
This suggests an alternative model for Python computation
On Tue, 15 Sep 2015 03:34 am, Random832 wrote:
> On Mon, Sep 14, 2015, at 13:03, Steven D'Aprano wrote:
>> On Tue, 15 Sep 2015 01:10 am, Random832 wrote:
>> > That's not true in CPython. In fact, the range object in python
>> > contains *four* reference boxes - one more for length.
>>
>> I really
On Tue, 15 Sep 2015 04:02 am, Random832 wrote:
> The point is that with immutable objects no-one cares if they are three
> objects with the same value, or three references to the same object.
Well, you might care...
a = (1,)*(10**12)
b = (1,)*(10**12)
c = (1,)*(10**12)
Each of those tuples wou
Ned Batchelder writes:
> On Monday, September 14, 2015 at 3:32:46 PM UTC-4, Akira Li wrote:
>> Ned Batchelder writes:
>> ...
>> > What do you feel is missing from Steven's diagram?
>>
>> I don't feel anything missing because I don't expect the model to be
>> more detailed.
>
> Akira, you said,
On Monday, September 14, 2015 at 3:32:46 PM UTC-4, Akira Li wrote:
> Ned Batchelder writes:
> ...
> > What do you feel is missing from Steven's diagram?
>
> I don't feel anything missing because I don't expect the model to be
> more detailed.
Akira, you said, "neither models are detailed enough
Ned Batchelder writes:
...
> What do you feel is missing from Steven's diagram?
I don't feel anything missing because I don't expect the model to be
more detailed.
--
https://mail.python.org/mailman/listinfo/python-list
On Monday, September 14, 2015 at 1:26:39 PM UTC-4, Akira Li wrote:
> My point is that neither models are detailed enough to describe
> meaningfully the behavior of Python code in the general case.
This is of course true, because a model is never detailed enough to
fully describe the real thing.
I
Random832 writes:
> On Mon, Sep 14, 2015, at 13:45, Akira Li wrote:
>>[box + arrow pointing to] + object == parcel tag + object
>
> The problem is that if there are multiple namespaces, or if you've also
> got to include references from within other objects such as list, then
> you've got to
On Mon, Sep 14, 2015, at 13:51, Emile van Sebille wrote:
> Actually, boxes with integers in them isn't the appropriate analogy.
> Consider the naming of cats. My cat is known to me as Paddy. My next
> door neighbor sometimes feeds her and is known to her as Stripes. The
> cat also is known
On Mon, Sep 14, 2015, at 13:45, Akira Li wrote:
>[box + arrow pointing to] + object == parcel tag + object
The problem is that if there are multiple namespaces, or if you've also
got to include references from within other objects such as list, then
you've got to write all that somehow on the
On Tue, Sep 15, 2015 at 3:51 AM, Emile van Sebille wrote:
> Actually, boxes with integers in them isn't the appropriate analogy.
> Consider the naming of cats. My cat is known to me as Paddy. My next door
> neighbor sometimes feeds her and is known to her as Stripes. The cat also
> is known as
On 9/14/2015 10:34 AM, Random832 wrote:
Personally I think it's a bit silly to insist on a diagram model where a
box with an arrow in it pointing at an int object can't be represented
by a box with an integer in it (where 'int' is any immutable type -
string, tuple, even range), but people don't
Random832 writes:
> On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
>> start, stop, step attributes (corresponding Python ints) may not exist
>> ("the objects we've talking about have never been created") until you
>> request them explicitly.
>
> That's not true in CPython. In fact, the range obj
On Mon, Sep 14, 2015, at 13:03, Steven D'Aprano wrote:
> On Tue, 15 Sep 2015 01:10 am, Random832 wrote:
> > That's not true in CPython. In fact, the range object in python contains
> > *four* reference boxes - one more for length.
>
> I really don't see why any of this is relevant to the business
Steven D'Aprano writes:
> On Mon, 14 Sep 2015 01:23 pm, Akira Li wrote:
>
>> Steven D'Aprano writes:
>>
>>> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
Look at the last example:
http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>>>
>>>
>>> I'm afraid that page is
On Mon, 14 Sep 2015 01:23 pm, Akira Li wrote:
> Steven D'Aprano writes:
>
>> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
>>> Look at the last example:
>>> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>>
>>
>> I'm afraid that page is broken in my browser. Can you not su
On Tue, 15 Sep 2015 01:10 am, Random832 wrote:
> On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
>> start, stop, step attributes (corresponding Python ints) may not exist
>> ("the objects we've talking about have never been created") until you
>> request them explicitly.
>
> That's not true in CP
On Mon, Sep 14, 2015, at 10:48, Akira Li wrote:
> start, stop, step attributes (corresponding Python ints) may not exist
> ("the objects we've talking about have never been created") until you
> request them explicitly.
That's not true in CPython. In fact, the range object in python contains
*four
Random832 writes:
...
> Why can't it describe range(1)? A range object in my model would include
> the start, stop, and step; _not_ the contents of what you would get by
> iterating over it; since that's not part of the physical structure of
> the object, but the consequences of calling methods on
On Sun, Sep 13, 2015, at 19:17, Akira Li wrote:
> "do not physically exist" does not make sense. Objects are *never*
> destroyed explicitly in Python (you can only make them
> *unreachable*).
But the objects we've talking about have never been created, because the
__getitem__ method has not been c
On 14/09/2015 02:34, rurpy--- via Python-list wrote:
Goodbye, *plonk*
--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.
Mark Lawrence
--
https://mail.python.org/mailman/listinfo/python-list
Steven D'Aprano writes:
> On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
>> Look at the last example:
>> http://thread.gmane.org/gmane.comp.python.general/782626/focus=782704
>
>
> I'm afraid that page is broken in my browser. Can you not summarise, or link
> to the specific message? I may be able
On Mon, 14 Sep 2015 11:22 am, Akira Li wrote:
> Steven D'Aprano writes:
>
>> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
>>
>>> I don't see why the model that can't describe range(1) in Python 3
>>> pretends to be complete.
>>
>>
>> Please explain.
>>
>> range(1) returns a range instance. What
Chris Angelico writes:
> On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <4kir4...@gmail.com> wrote:
>> Steven D'Aprano writes:
>>
>>> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
>>>
I don't see why the model that can't describe range(1) in Python 3
pretends to be complete.
>>>
>>>
>>> Pl
On 09/13/2015 06:50 AM, Steven D'Aprano wrote:
> On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote:
>> On 09/12/2015 10:32 AM, Steven D'Aprano wrote:
>>> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>>> [...]
>>> Computer science and IT is *dominated* by a single usage for "pointer" --
>>> it's
On Mon, Sep 14, 2015 at 11:22 AM, Akira Li <4kir4...@gmail.com> wrote:
> Steven D'Aprano writes:
>
>> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
>>
>>> I don't see why the model that can't describe range(1) in Python 3
>>> pretends to be complete.
>>
>>
>> Please explain.
>>
>> range(1) returns
Steven D'Aprano writes:
> On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
>
>> I don't see why the model that can't describe range(1) in Python 3
>> pretends to be complete.
>
>
> Please explain.
>
> range(1) returns a range instance. What is hard about that?
Look at the last example:
http://threa
On Sunday, September 13, 2015 at 2:49:13 PM UTC-6, Ben Finney wrote:
> Chris Angelico writes:
>
> > I think Ben's referring to taunting jmf, whom Mark called the "RUE" or
> > "Resident Unicode Expert". There has been a long-standing antagonism
> > between those two (which is completely understand
On Mon, 14 Sep 2015 09:17 am, Akira Li wrote:
> I don't see why the model that can't describe range(1) in Python 3
> pretends to be complete.
Please explain.
range(1) returns a range instance. What is hard about that?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Sep 14, 2015 at 10:30 AM, Akira Li <4kir4...@gmail.com> wrote:
> "Naming and binding" is the title from the Python language reference
> https://docs.python.org/3/reference/executionmodel.html#naming-and-binding
>
> Otherwise, I agree with you ("name" is better here).
Ah, gotcha. That's tal
Chris Angelico writes:
> On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4...@gmail.com> wrote:
>> If you mean this quote from [1]:
>>
>> Although we commonly refer to "variables" even in Python (because it's
>> common terminology), we really mean "names" or "identifiers". In
>> Python, "var
On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4...@gmail.com> wrote:
> If you mean this quote from [1]:
>
> Although we commonly refer to "variables" even in Python (because it's
> common terminology), we really mean "names" or "identifiers". In
> Python, "variables" are nametags for values,
Random832 writes:
> Akira Li <4kir4...@gmail.com> writes:
>> I'm not sure what "parcel tags" model is but if you mean these
>> pictures[1] than it works in this case as well as any other (take *a*,
>> *b* nametags, put them on the corresponding balloons that represents
>> list objects).
>>
>> The
Chris Angelico writes:
> I think Ben's referring to taunting jmf, whom Mark called the "RUE" or
> "Resident Unicode Expert". There has been a long-standing antagonism
> between those two (which is completely understandable), and one which
> often spills over into vitriolic posts (which is less ac
Akira Li <4kir4...@gmail.com> writes:
> I'm not sure what "parcel tags" model is but if you mean these
> pictures[1] than it works in this case as well as any other (take *a*,
> *b* nametags, put them on the corresponding balloons that represents
> list objects).
>
> The only names left are *a* and
On Mon, Sep 14, 2015 at 4:04 AM, Akira Li <4kir4...@gmail.com> wrote:
>> (If I were drawing a picture rather than ASCII I'd add something to make
>> it clear that the pairs shown are list objects Like, it's a circle with
>> the word "list" and two pointer-boxes inside it.)
>
> "correct and complete
Random832 writes:
> Akira Li <4kir4...@gmail.com> writes:
>>Rustom Mody writes:
>>> viz. I have two variables (or names!) say a and b which look the same
>> a
>>> [[1,2],[1,2]]
>> b
>>> [[1,2],[1,2]]
>>> And yet doing
>> a[0][0] = "Oops!"
>>> gives a data structure one "Oops!"
>>> wh
On Mon, Sep 14, 2015 at 1:31 AM, rurpy--- via Python-list
wrote:
> Ben,
>
> If the troll being taunted here is referring to me, I suggest
> you review my posts in this thread, You've said in the past
> that you don't read posts from Google Groups (that's fine,
> your choice) so perhaps you do not
On 09/12/2015 08:42 PM, Ben Finney wrote:
> Michael Torrie writes:
>> On 09/12/2015 08:22 PM, Mark Lawrence wrote:
>>> You appear to have the same level of knowledge of Python internals as
>>> the RUE has of the Python 3.3+ FSR unicode implementation. Let's have
>>> some fun, is Python pass by
On Sun, 13 Sep 2015 10:50 pm, Steven D'Aprano wrote:
> On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote:
... ^
> But as I said to Rurpy,
Er, that would be you.
Editing fail. Sorry about that.
--
Steven
--
https://mail.python.org/mailman/listinfo/python-
On Sun, 13 Sep 2015 04:45 am, ru...@yahoo.com wrote:
> On 09/12/2015 10:32 AM, Steven D'Aprano wrote:
>> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>>[...]
>> Computer science and IT is *dominated* by a single usage for "pointer" --
>> it's an abstract memory address. The fundamental character
Random832 writes:
> Jussi Piitulainen writes:
>> I think the best way is to say that a[0] and a[1] are the same
>> object, while b[0] and b[1] are different objects.
>
> Sure, you can *say* that. But how do you draw it on a diagram with
> sticky notes or parcel tags or whatever?
I prefer to outlin
Michael Torrie writes:
> On 09/12/2015 08:22 PM, Mark Lawrence wrote:
> > You appear to have the same level of knowledge of Python internals as
> > the RUE has of the Python 3.3+ FSR unicode implementation. Let's have
> > some fun, is Python pass by value or pass by reference? It has to be
>
On 09/12/2015 08:22 PM, Mark Lawrence wrote:
> You appear to have the same level of knowledge of Python internals as
> the RUE has of the Python 3.3+ FSR unicode implementation. Let's have
> some fun, is Python pass by value or pass by reference? It has to be
> more interesting debating that t
On Sun, 13 Sep 2015 07:10 am, Random832 wrote:
> Jussi Piitulainen writes:
>> I think the best way is to say that a[0] and a[1] are the same object,
>> while b[0] and b[1] are different objects.
>
> Sure, you can *say* that. But how do you draw it on a diagram with
> sticky notes or parcel tags
On Saturday, September 12, 2015 at 10:23:24 PM UTC-4, Mark Lawrence wrote:
> On 13/09/2015 01:44, rurpy--- via Python-list wrote:
> > On 09/12/2015 06:02 PM, Ned Batchelder wrote:
> >> On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote:
> >> [...]
> >> But in C, pointers mean
On 13/09/2015 01:44, rurpy--- via Python-list wrote:
On 09/12/2015 06:02 PM, Ned Batchelder wrote:
On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote:
[...]
But in C, pointers mean more than that. You can perform arithmetic on
them, to access memory as a linearly addressed
Rustom Mody writes:
> On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote:
> > You've clearly committed to some ontology that just doesn't match
> > the Python data model.
>
> How about lay-English ontology in which "point to" and "refer to" are fairly
> synonymous?
That's
On Saturday, September 12, 2015 at 6:25:39 PM UTC-6, ru...@yahoo.com wrote:
> On 09/12/2015 05:39 PM, Rustom Mody wrote:
> [...]
> > which may be summarized as:
> > 1. Steven (quoting Online dictionary): Pointer = Address
> > 2. Steven: "Python has pointers" is ridiculous
> > 3. Python docs: id ret
On 09/12/2015 06:02 PM, Ned Batchelder wrote:
> On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote:
> [...]
> But in C, pointers mean more than that. You can perform arithmetic on
> them, to access memory as a linearly addressed abstraction. Python has
> nothing like this.
>
On 09/12/2015 05:39 PM, Rustom Mody wrote:
> On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote:
>> On 09/12/2015 04:14 PM, Emile van Sebille wrote:
>>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
>>>
The question is whether what "pointer" means in languages
On Sunday, September 13, 2015 at 5:32:44 AM UTC+5:30, Ned Batchelder wrote:
> In its implementation, CPython uses pointers. But if you say that Python
> has pointers because CPython uses pointers, then you might as well say
> that Python is statically typed because the CPython source has type
> de
On 09/12/2015 05:14 PM, Mark Lawrence wrote:
> On 12/09/2015 23:34, rurpy--- via Python-list wrote:
>> On 09/12/2015 04:14 PM, Emile van Sebille wrote:
>>> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
>>>
The question is whether what "pointer" means in languages that
use the wo
On Sun, Sep 13, 2015 at 9:39 AM, Rustom Mody wrote:
> To which we have Chris saying CPython ≠ Python
> Which reminds me of another definition
> Fig-Leaf: A device for converting poor porn into high art
>
> Even in languages like C with an ISO standard adhering to the standard is
> academic (gcc's
On Saturday, September 12, 2015 at 7:15:18 PM UTC-4, Mark Lawrence wrote:
> On 12/09/2015 23:34, rurpy--- via Python-list wrote:
> > On 09/12/2015 04:14 PM, Emile van Sebille wrote:
> >> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
> >>
> >>> The question is whether what "pointer" means i
On Sunday, September 13, 2015 at 4:05:21 AM UTC+5:30, ru...@yahoo.com wrote:
> On 09/12/2015 04:14 PM, Emile van Sebille wrote:
> > On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
> >
> >> The question is whether what "pointer" means in languages that use the
> >> word is*so* different tha
On 12/09/2015 23:34, rurpy--- via Python-list wrote:
On 09/12/2015 04:14 PM, Emile van Sebille wrote:
On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
The question is whether what "pointer" means in languages that use the
word is*so* different than its meaning in the Python sense
I ca
On 09/12/2015 04:14 PM, Emile van Sebille wrote:
> On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
>
>> The question is whether what "pointer" means in languages that use the
>> word is*so* different than its meaning in the Python sense
>
> I can't find a single reference to pointer in th
On 9/12/2015 12:58 PM, rurpy--- via Python-list wrote:
The question is whether what "pointer" means in languages that use the
word is*so* different than its meaning in the Python sense
I can't find a single reference to pointer in the python docs outside of
ctypes. What is its python sense?
Akira Li <4kir4...@gmail.com> writes:
>Rustom Mody writes:
>> viz. I have two variables (or names!) say a and b which look the same
> a
>> [[1,2],[1,2]]
> b
>> [[1,2],[1,2]]
>> And yet doing
> a[0][0] = "Oops!"
>> gives a data structure one "Oops!"
>> whereas doing it to b mysteriously
Jussi Piitulainen writes:
> I think the best way is to say that a[0] and a[1] are the same object,
> while b[0] and b[1] are different objects.
Sure, you can *say* that. But how do you draw it on a diagram with
sticky notes or parcel tags or whatever?
--
https://mail.python.org/mailman/listinfo
Rustom Mody writes:
> On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote:
>> Rustom Mody writes:
>>
>> > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton
>> > wrote:
>> >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
>> >> >Ho
Rustom Mody writes:
a
> [[1,2],[1,2]]
b
> [[1,2],[1,2]]
> And yet doing
a[0][0] = "Oops!"
> gives a data structure one "Oops!"
> whereas doing it to b mysteriously gives 2
>
> Best I can see you can only explain this
> seemingly-similar-but-structurally-different
> with box-n-arrow
On 09/12/2015 11:48 AM, Steven D'Aprano wrote:
> On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote:
> [...]
>> the model of Python I eventually
>> developed is very much (I think, haven't read the whole thread) like
>> Random832's. I think of boxes (objects) with slots containing "pointers"
>>
On 09/12/2015 10:32 AM, Steven D'Aprano wrote:
> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>[...]
> Computer science and IT is *dominated* by a single usage for "pointer" --
> it's an abstract memory address. The fundamental characteristics of
> pointers are:
Just upthread, you claimed someth
On Saturday, September 12, 2015 at 11:26:18 PM UTC+5:30, Akira Li wrote:
> Rustom Mody writes:
>
> > On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton
> > wrote:
> >> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
> >> >How about lay-English ontology i
On Sun, 13 Sep 2015 03:12 am, Rustom Mody wrote:
> Best I can see, the people frothing at the mouth that python has no
> pointers are basically saying that "non-first-class" == "non-existent"
Not at all. In Python, at least, all values are first-class, but that's not
the case with all languages
Rustom Mody writes:
> On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote:
>> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
>> >How about lay-English ontology in which "point to" and "refer to" are fairly
>> >synonymous?
>>
>> This I have found is
On Sun, 13 Sep 2015 02:17 am, ru...@yahoo.com wrote:
> Having programmed in C in the past,
Well, there's your problem. Like BASIC before it, anyone who has learned C
is mentally crippled for life as a programmer *wink*
> the model of Python I eventually
> developed is very much (I think, have
On Sun, Sep 13, 2015 at 3:24 AM, Steven D'Aprano wrote:
> Note: when I write my own Python implementation, all IDs will be negative
> odd numbers.
When I build my own CPU architecture, all memory addresses will be
negative odd numbers, so people think your Python uses addresses
again.
ChrisA
-
On Saturday, September 12, 2015 at 10:38:46 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote:
>
> > On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote:
>
> >> You've clearly committed to some ontology that just doesn't match the
> >> Pyt
On Sun, 13 Sep 2015 02:54 am, Rustom Mody wrote:
> This is from the docs
> https://docs.python.org/3/library/functions.html#id
Yes, what of it? What point do you think you are making?
> id(object)
>
> Return the "identity" of an object. This is an integer which is
> guaranteed to be un
On Saturday, September 12, 2015 at 9:47:33 PM UTC+5:30, rurpy wrote:
> Frankly, I feel a little insulted by people who presume that having
> learned what a pointer is in C, that my brain is so rigid that I must
> necessarily think that pointer means exactly what pointer means in C
> forever after
On 9/12/2015 9:54 AM, Rustom Mody wrote:
On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote:
On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
from C/C++ pointers - maybe call it a "non-arithmetic"
On Sat, 12 Sep 2015 10:46 pm, Rustom Mody wrote:
> On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote:
>> You've clearly committed to some ontology that just doesn't match the
>> Python data model.
>
> How about lay-English ontology in which "point to" and "refer to" are
>
On Sun, Sep 13, 2015 at 2:54 AM, Rustom Mody wrote:
>> Insisting that Python has pointers is like insisting that you use a text
>> editor by flipping bits. "What happens if I press Ctrl-X?" "Well, these
>> bits on the screen flip from black to white, these bits flip from white to
>> black, and the
On Saturday, September 12, 2015 at 10:21:08 PM UTC+5:30, Steven D'Aprano wrote:
> Python values are not addresses. Python values are objects.
Which means for example...???
Atoms? Stars? People? Countries?
> Addresses, even when they exist, are not accessible in the Python language.
And you claim
On Saturday, September 12, 2015 at 10:02:40 PM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
>
> > Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
> > from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since
> > the key thing
On Sat, 12 Sep 2015 03:03 pm, Random832 wrote:
> Yes I am. You're just making the implicit assumption that a "value" has
> to be a number, and I was ignoring that assumption. The value is the
> address of an object.
The unknown, unknowable, and in fact possibly non-existent address of an
object.
On Sat, 12 Sep 2015 02:42 pm, Random832 wrote:
> Anyway, maybe we do need a term to distinguish Python/C#/Java pointers
> from C/C++ pointers - maybe call it a "non-arithmetic" pointer, since
> the key thing about it is you can't do pointer arithmetic on them to get
> the object "next to" the one
Picking a post to respond to, more or less at random...
On Saturday, September 12, 2015 at 9:14:00 AM UTC-6, Rustom Mody wrote:
> On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote:
> > In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
> > >How about l
On Saturday, September 12, 2015 at 8:11:49 PM UTC+5:30, Laura Creighton wrote:
> In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
> >How about lay-English ontology in which "point to" and "refer to" are fairly
> >synonymous?
>
> This I have found is important in teaching, which
In a message of Sat, 12 Sep 2015 05:46:35 -0700, Rustom Mody writes:
>How about lay-English ontology in which "point to" and "refer to" are fairly
>synonymous?
This I have found is important in teaching, which is why I favour 'bind'
and 'binding' -- rather than pointer, pointer, refer to, referrin
On Saturday, September 12, 2015 at 11:57:01 AM UTC+5:30, Ben Finney wrote:
> Random832 writes:
>
> > Ben Finney writes:
> > > The reference value is inaccessible to the program, it can only be
> > > used to get at the referenced object.
> >
> > What does it mean to access something, if not to do s
On Sat, Sep 12, 2015 at 4:26 PM, Ben Finney wrote:
> If you do agree with those, some corollaries follow:
>
> * Container types do not contain objects.
>
> It is a useful analogy to say the objects are “in” the container; but
> that would imply they are not simultaneously in any other containe
Random832 writes:
> Ben Finney writes:
> > The reference value is inaccessible to the program, it can only be
> > used to get at the referenced object.
>
> What does it mean to access something, if not to do some operation on
> it? Getting the referenced object is the operation you can do with i
Mark Lawrence writes:
> No it isn't. When you make a copy of an object you will end up with
> two names that refer to the same object.
No, when you *make a copy of* an object, you get two objects.
>>> x = [1, 2, 3]
>>> y = copy.copy(x)
>>> x is y
False
What you make a copy of when you do y =
On 12/09/2015 06:42, Random832 wrote:
Ben Finney writes:
The reference value is inaccessible to the program, it can only be used
to get at the referenced object.
That's like saying an integer is inaccessible since it can only be used
to add/subtract/etc (list of all operations you can do with
On Sat, Sep 12, 2015 at 3:03 PM, Random832 wrote:
>> You can't, for example, keep the old reference (there are no references
>> to references in Python), because they're not accessible as values in
>> themselves. Once you assign a different reference, the old one is gone
>> and can't be found agai
Ben Finney writes:
> The reference value is inaccessible to the program, it can only be used
> to get at the referenced object.
That's like saying an integer is inaccessible since it can only be used
to add/subtract/etc (list of all operations you can do with an
integer). What does it mean to acc
Random832 writes:
> Ben Finney writes:
>
> > Random832 writes:
> >
> >> Ben Finney writes:
> >> > With the significant difference that “pointer” implies that it has its
> >> > own value accessible directly by the running program, such as a pointer
> >> > in C.
> >>
> >> Its own value *is* what
Ben Finney writes:
> Random832 writes:
>
>> Ben Finney writes:
>> > With the significant difference that “pointer” implies that it has its
>> > own value accessible directly by the running program, such as a pointer
>> > in C.
>>
>> Its own value *is* what you're accessing when you assign or re
Random832 writes:
> Ben Finney writes:
> > With the significant difference that “pointer” implies that it has its
> > own value accessible directly by the running program, such as a pointer
> > in C.
>
> Its own value *is* what you're accessing when you assign or return it.
You're not describin
Ben Finney writes:
> With the significant difference that “pointer” implies that it has its
> own value accessible directly by the running program, such as a pointer
> in C.
Its own value *is* what you're accessing when you assign or return
it. You just can't do math on it, but there are lots of
Random832 writes:
> Honestly, whether you want to call the thing a pointer or a reference,
> you have to call it *something*, and I think "reference" is a worse
> fit based on its connotations from C++. Whatever you call it, it's an
> arrow on a diagram.
With the significant difference that “poi
98 matches
Mail list logo
