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

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

Slices time complexity

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

Contents

  Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-18 20:23 +0100
    Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-19 05:36 +1000
      Re: Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-18 20:49 +0100
        Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-19 06:04 +1000
    Re: Slices time complexity Todd <toddrjen@gmail.com> - 2015-05-18 21:42 +0200
    Re: Slices time complexity Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-18 13:49 -0600
      Re: Slices time complexity Fabien <fabien.maussion@gmail.com> - 2015-05-18 21:54 +0200
        Re: Slices time complexity Todd <toddrjen@gmail.com> - 2015-05-18 22:23 +0200
      Re: Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-18 22:04 +0100
        Re: Slices time complexity Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-18 22:38 +0100
        Re: Slices time complexity Terry Reedy <tjreedy@udel.edu> - 2015-05-18 19:04 -0400
      Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-18 19:20 -0700
        Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 15:13 +1000
          Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-18 22:33 -0700
            Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 10:12 +0300
              Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 18:16 +1000
                Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 11:39 +0300
                  Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-19 18:50 +1000
                    Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 12:35 +0300
                      Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 23:44 +1000
                        Re: Slices time complexity Christian Gollwitzer <auriocus@gmx.de> - 2015-05-20 23:54 +0200
                    Re: Slices time complexity Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-19 23:00 +1200
                      Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 11:47 +1000
                        Re: Slices time complexity Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-05-20 08:07 -0400
                    Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 22:42 +1000
                      Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-19 23:24 +1000
                      Re: Slices time complexity Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-20 12:31 +1200
                        Re: Slices time complexity Ben Finney <ben+python@benfinney.id.au> - 2015-05-20 10:42 +1000
                          Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 07:24 +0300
                            Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 21:30 -0700
                              Re: Slices time complexity Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-20 06:06 +0100
                              Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 15:57 +1000
                                Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 09:17 +0300
                                Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 23:23 -0700
                                  Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 09:46 +0300
                                    Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-20 00:03 -0700
                                      Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 10:45 +0300
                                  List semantics [was Re: Slices time complexity] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 17:23 +1000
                                    Re: List semantics [was Re: Slices time complexity] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-20 20:54 +1200
                                      Re: List semantics [was Re: Slices time complexity] Ned Batchelder <ned@nedbatchelder.com> - 2015-05-20 04:08 -0700
                                      Re: List semantics [was Re: Slices time complexity] Terry Reedy <tjreedy@udel.edu> - 2015-05-20 14:42 -0400
                                        Re: List semantics [was Re: Slices time complexity] Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2015-05-21 11:06 +1200
                                      Re: List semantics [was Re: Slices time complexity] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-21 12:10 +1000
                                Re: Slices time complexity "Bartc" <bartc@freeuk.com> - 2015-05-20 10:56 +0100
                                  Re: Slices time complexity Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-05-20 10:16 +0100
                                  Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-21 15:19 +1000
                                    Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-21 09:20 +0300
                                    Re: Slices time complexity bartc <bart4858@gmail.com> - 2015-05-21 06:34 -0700
                                      Re: Slices time complexity MRAB <python@mrabarnett.plus.com> - 2015-05-21 17:50 +0100
                                      Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-22 03:16 +1000
                                        Re: Slices time complexity bart4858@gmail.com - 2015-05-21 12:48 -0700
                        Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 12:26 +1000
                          Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-20 12:36 +1000
                          Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 20:02 -0700
                  Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 21:43 +1000
                    Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 18:59 +0300
                      Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 03:46 +1000
                        Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-20 04:12 +1000
                        Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-19 21:19 +0300
                          Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 10:43 +1000
                            Re: Slices time complexity Marko Rauhamaa <marko@pacujo.net> - 2015-05-20 07:30 +0300
                              Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 15:33 +1000
                                Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 15:58 +1000
                  Re: Slices time complexity Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-05-19 15:18 +0100
              Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 04:46 -0700
                Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 05:14 -0700
            Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 18:19 +1000
              Re: Slices time complexity Rustom Mody <rustompmody@gmail.com> - 2015-05-19 04:41 -0700
    Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-19 19:45 +1000
      Re: Slices time complexity Serhiy Storchaka <storchaka@gmail.com> - 2015-05-19 13:15 +0300
      Re: Slices time complexity Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2015-05-19 12:09 +0100
      Re: Slices time complexity "Bartc" <bartc@freeuk.com> - 2015-05-19 15:52 +0100
        Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-20 03:07 +1000
          Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-20 03:19 +1000
          Re: Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-20 20:51 +0100
            Re: Slices time complexity Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-20 14:33 -0600
            Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-21 06:35 +1000
            Re: Slices time complexity Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-05-20 21:47 +0100
              Re: Slices time complexity Mario Figueiredo <marfig@gmail.com> - 2015-05-20 22:23 +0100
            Re: Slices time complexity Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2015-05-21 17:35 +1000
              Re: Slices time complexity Chris Angelico <rosuav@gmail.com> - 2015-05-21 18:25 +1000
      Re: Slices time complexity Ian Kelly <ian.g.kelly@gmail.com> - 2015-05-19 09:15 -0600
      Re: Slices time complexity Serhiy Storchaka <storchaka@gmail.com> - 2015-05-19 22:51 +0300

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#90987

Am 19.05.15 um 15:44 schrieb Steven D'Aprano:
> Variables are not first class values in C. (I assume you meant *values*
> rather than "objects", on account of C not being an OOP language.) There is
> no way, for example, to set x to *the variable y* in either C or Python. If
> you could, that would imply something like this:
>
> y = 42  # regular assignment
> x ::= y  # set x to be the variable y, not the value of y
> assert x == y  # naturally, since x and y are now two different
>                 # names for the same variable
> x = 23  # regular assignment
> assert y == 23  # since y is just another name for x

In C++, this is possible:

int y=42;
int &x = y;
assert(x==y);
x=23;
assert(x==y);

.... but, admittedly, you can't reassign x.

	Christian

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

#90839

Chris Angelico wrote:
> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
> not just pointers to their first elements, and subscripting is most
> definitely NOT "add to pointer and dereference".
> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
> best, it happens automatically.
> 3) References actually mean something. Copying a pointer doesn't.
> Whether the Python you're using is refcounted (CPython) or
> mark-and-sweep (uPy, I think) or some other model, an additional
> reference to the same object will prevent it from being disposed of,
> which isn't the case in C.
> 4) A pointer is itself a value. You can pass a
> pointer-to-local-variable to another function and have that function
> change a local variable.
> 5) Furthermore, since a pointer is a value, you can have pointers to
> pointers, etc. Doesn't make any sense in Python.

FWIW, most of those things are peculiar to C, and are not
necessarily shared even with other languages that have
explicit pointers. In Pascal, for example, there is no
pointer arithmetic, and (at least not without nonstandard
extension) you can't make a pointer point into the middle
of a stack frame or array or record, etc. (You *can* have
a pointer to a pointer, but only by heap-allocating a
memory block containing a single pointer, which is not
useful very often).

-- 
Greg

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

#90912

On Tue, 19 May 2015 09:00 pm, Gregory Ewing wrote:

> Chris Angelico wrote:
>> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
>> not just pointers to their first elements, and subscripting is most
>> definitely NOT "add to pointer and dereference".
>> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
>> best, it happens automatically.
>> 3) References actually mean something. Copying a pointer doesn't.
>> Whether the Python you're using is refcounted (CPython) or
>> mark-and-sweep (uPy, I think) or some other model, an additional
>> reference to the same object will prevent it from being disposed of,
>> which isn't the case in C.
>> 4) A pointer is itself a value. You can pass a
>> pointer-to-local-variable to another function and have that function
>> change a local variable.
>> 5) Furthermore, since a pointer is a value, you can have pointers to
>> pointers, etc. Doesn't make any sense in Python.
> 
> FWIW, most of those things are peculiar to C, and are not
> necessarily shared even with other languages that have
> explicit pointers. In Pascal, for example, there is no
> pointer arithmetic, 

That's true in theory, but I don't think that's right in practice. All the
Pascal compilers that I know of which are still in common use support
pointer arithmetic: Turbo Pascal, GNU Pascal, Free Pascal and Delphi. Some
compilers support an "inc" [increment] function to advance the pointer
safely. For those compilers that don't provide either, there's the
possibility of typecasting the pointer to a longint and back. Back in the
1990s, I used Lightspeed Pascal, and it supported typecasting pointers. For
those which don't even support that, you can usually abuse variant records
to get around the type system.

(Niklaus Wirth hated this, and made sure that this hack didn't work in his
later language Oberon.)

And finally, if all else fails, many Pascal compilers support embedding
assembly language, which obviously lets you do arithmetic on pointers.

The larger point is, the failure to allow pointer arithmetic in standard
Pascal is a design choice of the designer, not a fundamental restriction on
the pointer concept. Wirth didn't include pointer arithmetic in standard
Pascal because *he thought it was a bad idea*, not because Pascal pointers
are incapable of having arithmetic done to them. They're just an
abstraction over *numeric* memory addresses, just like in C, and there's
nothing more fundamental to numbers than arithmetic. You can't do
arithmetic on pointers in standard Pascal because the compiler stops you,
not because the operation makes no sense.

Bringing this back to Python, references in Python are *not* abstractions
over memory addresses. There is nothing in the Python model of computation
that requires values to even have such a thing as a memory address, let
alone pointers. The "references are pointers" explanation only gets you so
far, and not very far at that.


> and (at least not without nonstandard 
> extension) you can't make a pointer point into the middle
> of a stack frame or array or record, etc. (You *can* have
> a pointer to a pointer, but only by heap-allocating a
> memory block containing a single pointer, which is not
> useful very often).

Pascal programming on classic Macintosh used pointers-to-pointers
extensively, so much so that they had a name, "handle". Technically though
handles were managed by the Macintosh Toolbox routines, so slightly
different from what you are talking about. But in standard Pascal, you
certainly could create pointers to pointers.



-- 
Steven

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

#90949

On Wed, 20 May 2015 11:47:52 +1000, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following:

>
>Pascal programming on classic Macintosh used pointers-to-pointers
>extensively, so much so that they had a name, "handle". Technically though
>handles were managed by the Macintosh Toolbox routines, so slightly

	Main purpose was so the "user" object (the first level pointer) could
remain at a fixed location while the garbage collector could move the end
objects around to reclaim memory by updating the second level pointer to
refer to the new location.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

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

#90846

On Tue, 19 May 2015 06:50 pm, Chris Angelico wrote:

> On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>> For example, you could explain Python's object references as pointers
>> (memory addresses) if you considered that helpful. (That's how Lisp
>> textbooks often explain cons cells.)
> 
> Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked
> to explain Python's object references, the differences will start to
> be problematic:
> 
> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
> not just pointers to their first elements, and subscripting is most
> definitely NOT "add to pointer and dereference".
> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
> best, it happens automatically.
> 3) References actually mean something. Copying a pointer doesn't.
> Whether the Python you're using is refcounted (CPython) or
> mark-and-sweep (uPy, I think) or some other model, an additional
> reference to the same object will prevent it from being disposed of,
> which isn't the case in C.
> 4) A pointer is itself a value. You can pass a
> pointer-to-local-variable to another function and have that function
> change a local variable.
> 5) Furthermore, since a pointer is a value, you can have pointers to
> pointers, etc. Doesn't make any sense in Python.

Chris, that is one of the best explanations for why "references equals
pointers" is *not* a good explanation for Python's behaviour. I may have to
steal it :-)



-- 
Steven

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

#90849

On Tue, May 19, 2015 at 10:42 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 19 May 2015 06:50 pm, Chris Angelico wrote:
>
>> On Tue, May 19, 2015 at 6:39 PM, Marko Rauhamaa <marko@pacujo.net> wrote:
>>> For example, you could explain Python's object references as pointers
>>> (memory addresses) if you considered that helpful. (That's how Lisp
>>> textbooks often explain cons cells.)
>>
>> Sorta-kinda-maybe, but if a C programmer's idea of pointers is invoked
>> to explain Python's object references, the differences will start to
>> be problematic:
>>
>> 1) Pointer arithmetic simply doesn't exist in Python. Arrays/lists are
>> not just pointers to their first elements, and subscripting is most
>> definitely NOT "add to pointer and dereference".
>> 2) In fact, dereferencing as a whole isn't really a 'thing' either. At
>> best, it happens automatically.
>> 3) References actually mean something. Copying a pointer doesn't.
>> Whether the Python you're using is refcounted (CPython) or
>> mark-and-sweep (uPy, I think) or some other model, an additional
>> reference to the same object will prevent it from being disposed of,
>> which isn't the case in C.
>> 4) A pointer is itself a value. You can pass a
>> pointer-to-local-variable to another function and have that function
>> change a local variable.
>> 5) Furthermore, since a pointer is a value, you can have pointers to
>> pointers, etc. Doesn't make any sense in Python.
>
> Chris, that is one of the best explanations for why "references equals
> pointers" is *not* a good explanation for Python's behaviour. I may have to
> steal it :-)

:) They say that turnabout is fair play. I stole your "Python vs
MATLAB" python-tutor post about call-by-value vs call-by-reference vs
object semantics for years (until some other pages picked up the same
content). Go for it!

That said, though, I was specifically referring to C's pointer
semantics. As Gregory pointed out, Pascal has rather different pointer
semantics; but if you're talking about Python references and
considering using any concept of object addressing and pointers, it's
most likely going to be something similar to C/assembly, where a
pointer is a dereferenceable integer storing an offset into memory.

(But don't even get *started* on near vs far pointers, code vs data
segments and the thunks required to transform between them,
memory-mapped disk, virtual segments, overlapping segments, shared
memory, memory-mapped I/O, and all those other things that C
programmers sometimes contend with. Fun, but hardly anything to do
with Python objects. :) )

ChrisA

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

#90903

Steven D'Aprano wrote:
> Chris, that is one of the best explanations for why "references equals
> pointers" is *not* a good explanation for Python's behaviour.

Many people here seem to have lost sight of the
fact that the word "pointer" existed in the English
language long before C, and even long before computers.

If I draw two boxes on a blackboard with an arrow
between them, I think it's perfectly reasonable to
call that arrow a pointer.

-- 
Greg

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

#90905

Gregory Ewing <greg.ewing@canterbury.ac.nz> writes:

> If I draw two boxes on a blackboard with an arrow between them, I
> think it's perfectly reasonable to call that arrow a pointer.

Right. So the box with an arrow coming out of it is a good metaphor for
pointers — *in languages that have pointers*, which Python does not.

A box with an arrow coming out of it is a poor metaphor for Python's
references, since a Python reference doesn't contain anything accessible
to the programmer.

Instead, to avoid giving the false impression that Python's references
are boxes containing things, write a bare name (or other reference) on
the blackboard, referring to the box that *does* contain a value
accessible to the programmer.

-- 
 \       “The Vatican is not a state.… a state must have people. There |
  `\    are no Vaticanians.… No-one gets born in the Vatican except by |
_o__)        an unfortunate accident.” —Geoffrey Robertson, 2010-09-18 |
Ben Finney

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

#90922

Ben Finney <ben+python@benfinney.id.au>:

> Right. So the box with an arrow coming out of it is a good metaphor for
> pointers — *in languages that have pointers*, which Python does not.
>
> A box with an arrow coming out of it is a poor metaphor for Python's
> references, since a Python reference doesn't contain anything accessible
> to the programmer.

Lisp doesn't have pointers. However:

  <URL: http://upload.wikimedia.org/wikipedia/commons/1/1b/Cons-cells.svg>

  <URL: http://cs.gmu.edu/~sean/lisp/cons/>

  <URL: http://www.csee.umbc.edu/courses/331/fall11/notes/scheme/scheme2.ppt>


Marko

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

#90924

On Wednesday, May 20, 2015 at 9:54:57 AM UTC+5:30, Marko Rauhamaa wrote:
> Ben Finney :
> 
> > Right. So the box with an arrow coming out of it is a good metaphor for
> > pointers -- *in languages that have pointers*, which Python does not.
> >
> > A box with an arrow coming out of it is a poor metaphor for Python's
> > references, since a Python reference doesn't contain anything accessible
> > to the programmer.
> 
> Lisp doesn't have pointers. However:
> 
>   <URL: http://upload.wikimedia.org/wikipedia/commons/1/1b/Cons-cells.svg>
> 
>   <URL: http://cs.gmu.edu/~sean/lisp/cons/>
> 
>   <URL: http://www.csee.umbc.edu/courses/331/fall11/notes/scheme/scheme2.ppt>
> 

And what about Java?
http://stackoverflow.com/questions/166033/value-semantics-and-pointer-semantics

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

#90925

On 20/05/2015 05:30, Rustom Mody wrote:
> On Wednesday, May 20, 2015 at 9:54:57 AM UTC+5:30, Marko Rauhamaa wrote:
>> Ben Finney :
>>
>>> Right. So the box with an arrow coming out of it is a good metaphor for
>>> pointers -- *in languages that have pointers*, which Python does not.
>>>
>>> A box with an arrow coming out of it is a poor metaphor for Python's
>>> references, since a Python reference doesn't contain anything accessible
>>> to the programmer.
>>
>> Lisp doesn't have pointers. However:
>>
>>    <URL: http://upload.wikimedia.org/wikipedia/commons/1/1b/Cons-cells.svg>
>>
>>    <URL: http://cs.gmu.edu/~sean/lisp/cons/>
>>
>>    <URL: http://www.csee.umbc.edu/courses/331/fall11/notes/scheme/scheme2.ppt>
>>
>
> And what about Java?
> http://stackoverflow.com/questions/166033/value-semantics-and-pointer-semantics
>

And what about CORAL66/250?  How do you explain Python in terms of the 
original 66 and the 250 derivative?  What is the unladen air speed 
velocity of a swallow in flight?  Who actually gives a stuff?

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

Mark Lawrence

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

#90930

On Wednesday 20 May 2015 14:30, Rustom Mody wrote:

> And what about Java?
> http://stackoverflow.com/questions/166033/value-semantics-and-pointer-
semantics

Congratulations, you have found yet another example of the Java community's 
collective delusion and insistence on misusing terms for the maximum 
confusion possible.

The mental gymnastics they go through to force the round peg of pass-by-
sharing object semantics into the false dichotomy "pass-by-value versus 
pass-by-reference" is just crazy.

One consequence of this is that the meaning of "call by value" depends on 
whether the value you are talking about is a boxed or unboxed value. Unboxed 
values are copied. Boxed values are not. Except that they are, if you 
understand that "the value" doesn't refer to the actual value, but to some 
hidden and implementation-dependent reference to the value.

To quote Fredrik Lundh:

    well, I guess you can, in theory, value an artificial number 
    assigned to an object as much as the object itself.

    "Joe, I think our son might be lost in the woods"
    "Don't worry, I have his social security number"


http://effbot.org/zone/call-by-object.htm


Rustom, if you are serious about this approach, then the implication is that 
if I execute "x = 23" in Python, and I ask you what the value of x is, you 
should answer something like "146588120" (that's the implementation 
dependent "value", i.e. the address of the int 23).

It's just *nuts*, and all because the Java folks are unwilling or unable to 
distinguish between the language semantics and the implementation of the 
language. And you're falling into the same hole.



-- 
Steve

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

#90932

Steven D'Aprano <steve+comp.lang.python@pearwood.info>:

> Rustom, if you are serious about this approach, then the implication
> is that if I execute "x = 23" in Python, and I ask you what the value
> of x is, you should answer something like "146588120" (that's the
> implementation dependent "value", i.e. the address of the int 23).

Steven, you are trying to be facetious but end up making good points.

The "canonical" Python semantics actually states that

   x = 23

means:

   An int object with the numeric value 23 is constructed or fetched
   from a cache. A reference to the object is assigned to a variable
   whose name is "x".

> it's just *nuts*, and all because the Java folks are unwilling or
> unable to distinguish between the language semantics and the
> implementation of the language. And you're falling into the same hole.

I have yet to see a high-level language that has defined its data model
without resorting to "locations", "slots" and pointers of sorts. It
certainly is possible (lambda calculus doesn't make any reference to
objects or pointers) but hardly any alternative explanation is more
appealing to programmers' tastes and imagination than the concrete image
of boxes and arrows.


Marko

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

#90933

On Wednesday, May 20, 2015 at 11:27:56 AM UTC+5:30, Steven D'Aprano wrote:
> On Wednesday 20 May 2015 14:30, Rustom Mody wrote:
> 
> > And what about Java?
> > http://stackoverflow.com/questions/166033/value-semantics-and-pointer-
> semantics
> 
> Congratulations, you have found yet another example of the Java community's 
> collective delusion and insistence on misusing terms for the maximum 
> confusion possible.
> 
> The mental gymnastics they go through to force the round peg of pass-by-
> sharing object semantics into the false dichotomy "pass-by-value versus 
> pass-by-reference" is just crazy.
> 
> One consequence of this is that the meaning of "call by value" depends on 
> whether the value you are talking about is a boxed or unboxed value. Unboxed 
> values are copied. Boxed values are not. Except that they are, if you 
> understand that "the value" doesn't refer to the actual value, but to some 
> hidden and implementation-dependent reference to the value.
> 
> To quote Fredrik Lundh:
> 
>     well, I guess you can, in theory, value an artificial number 
>     assigned to an object as much as the object itself.
> 
>     "Joe, I think our son might be lost in the woods"
>     "Don't worry, I have his social security number"
> 
> 
> http://effbot.org/zone/call-by-object.htm
> 
> 
> Rustom, if you are serious about this approach, then the implication is that 
> if I execute "x = 23" in Python, and I ask you what the value of x is, you 
> should answer something like "146588120" (that's the implementation 
> dependent "value", i.e. the address of the int 23).
> 
> It's just *nuts*, and all because the Java folks are unwilling or unable to 
> distinguish between the language semantics and the implementation of the 
> language. And you're falling into the same hole.

I am not arguing for the java-folks terminology or outlook.
I am arguing that for languages that execute on von Neumann machines memory
is not an optional negotiable concept.

And pointer is just first-classed memory as lambda is first-classed function.
Some languages firstclass it -- most notably C, also C# which increasingly fascinates me in its choices.
Others try to to unfirstclass , ie hide it in various half-assed ways -- Python, Java, Lisp.
Others try to hide it in the most heavy-handed way possible -- haskell

But you can never really hide it [law of leaky abstractions]

eg in haskell one makes an infinite list of ones thus

ones = 1 : ones

Now if you generalize this to

repeat x = x : repeat x
and then do
ones = repeat 1
you get poorer performance because the ones makes a box-n-arrow loop which the 
repeat does not achieve.

To get round that we do
repeat x = repeatx 
  where repeatx = x : repeatx

In short any language that is implemented on von Neumann hw will need to address
memory. The language-designer may believe that there is a choice to 'unfirstclass' it. However people discussing language have no such choice:
If you dont have it in the formal implemented language, you must have it in the
informal discussion-language
[With a large amount of wild waving of hands] 

<Admission>
I dont like teaching this. viz that in python
x = [[1,2],[1,2]]
is equal to y defined as
z = [1,2]
y = [z,z]
And although they are equal as in '==' they are not equal as in behavior, memory usage etc, a fact that can only be elucidated by box-n-arrow diagrams.

So as far as I can I teach by tabooing extend,append and all such mutablers

In the end though this is cheating
</Admission>

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

#90935

Rustom Mody <rustompmody@gmail.com>:

> In short any language that is implemented on von Neumann hw will need
> to address memory.

I don't think von Neumann hardware plays a role here. I think the data
model is inherent in Python/Java/Lisp regardless of the underlying
formalism (which could be SKI combinatory calculus or any other
Turing-complete formalism).

> And although they are equal as in '==' they are not equal as in
> behavior, memory usage etc, a fact that can only be elucidated by
> box-n-arrow diagrams.

That's what I meant when I asked if you can get Python without getting
something like C first. It seems the answer is, you probably can't.


Marko

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

#90937

On Wednesday, May 20, 2015 at 12:16:49 PM UTC+5:30, Marko Rauhamaa wrote:
> Rustom Mody :
> 
> > In short any language that is implemented on von Neumann hw will need
> > to address memory.
> 
> I don't think von Neumann hardware plays a role here. I think the data
> model is inherent in Python/Java/Lisp regardless of the underlying
> formalism (which could be SKI combinatory calculus or any other
> Turing-complete formalism).

That's backwards

Python/C/Java/Lisp/Fortran (and 700 more) are made the way they are out of
aiming for some fidelity with von Neumann architecture
They all of course make different choice from choosing different weights in
the various tradeoffs.
However they all commonly share that they are implemented reasonably satisfactorily.
'Reasonable' and 'satisfactory' have unspecified semantics!!

> 
> > And although they are equal as in '==' they are not equal as in
> > behavior, memory usage etc, a fact that can only be elucidated by
> > box-n-arrow diagrams.
> 
> That's what I meant when I asked if you can get Python without getting
> something like C first. It seems the answer is, you probably can't.

I think we agree except for the 'probably'. Consider:

Q1: Is a computer (of any sort and generation of your choice) finite or infinite?
Q2: Is a Turing machine finite or infinite?
Its ironical that a Turing machine is 'more' infinite and therefore more a math
abstraction than lambda-calculus!

IOW I regard memory questions as more fundamental than you seem to

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

#90942

Rustom Mody <rustompmody@gmail.com>:

> On Wednesday, May 20, 2015 at 12:16:49 PM UTC+5:30, Marko Rauhamaa wrote:
>> Rustom Mody :
>> 
>> > In short any language that is implemented on von Neumann hw will
>> > need to address memory.
>> 
>> I don't think von Neumann hardware plays a role here. I think the
>> data model is inherent in Python/Java/Lisp regardless of the
>> underlying formalism (which could be SKI combinatory calculus or any
>> other Turing-complete formalism).
>
> That's backwards
>
> Python/C/Java/Lisp/Fortran (and 700 more) are made the way they are
> out of aiming for some fidelity with von Neumann architecture

Funny enough, von Neumann is summoned even by the Python Language Spec:

   Objects are Python’s abstraction for data. All data in a Python
   program is represented by objects or by relations between objects.
   (In a sense, and in conformance to Von Neumann’s model of a “stored
   program computer,” code is also represented by objects.)

   <URL: https://docs.python.org/3/reference/datamodel.html>

As can be expected, the specification fails to define an object and
resorts to handwaving. However, there's a nod to pointer semantics:

   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. The ‘is‘ operator compares the
   identity of two objects; the id() function returns an integer
   representing its identity.


Marko

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

#90940 — List semantics [was Re: Slices time complexity]

On Wednesday 20 May 2015 16:23, Rustom Mody wrote:

> I dont like teaching this. viz that in python
> x = [[1,2],[1,2]]
> is equal to y defined as
> z = [1,2]
> y = [z,z]
> And although they are equal as in '==' they are not equal as in behavior,
> memory usage etc, a fact that can only be elucidated by box-n-arrow
> diagrams.

"Only"? 

You don't need diagrams to explain the differences between the two.


Code snippet 1:

    x = [[1,2],[1,2]]

creates a list bound to the name "x", containing a list containing ints 1 
and 2, and a second independent list also containing ints 1 and 2. Here 
there are three lists in total, and one named variable.

Code snippet 2:

    z = [1,2]
    y = [z, z]

creates a list bound to the name "z", ints 1 and 2; then it creates a second 
list, bound to name "y", containing the first list "z" twice. Here there are 
two distinct lists in total, and two named variables. The two items inside y 
are the same list, namely z, not distinct lists.


A diagram may help, especially for more complicated situations, or for the 
slow of thinking, but it's not essential. There's no need to talk about the 
implementation, pointers or memory addresses so long as you stick to 
Python's object-based language model.


-- 
Steve

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

#90945 — Re: List semantics [was Re: Slices time complexity]

Steven D'Aprano wrote:

> Code snippet 1:
> 
>     x = [[1,2],[1,2]]
> 
> creates a list bound to the name "x", containing a list containing ints 1 
> and 2, and a second independent list also containing ints 1 and 2.

Using the word "contains" here is misleading, because
it conjures a mental picture of physical containment,
which is exactly what you *don't* want to suggest.

>     z = [1,2]
>     y = [z, z]
> 
> creates a list bound to the name "z", ints 1 and 2; then it creates a second 
> list, bound to name "y", containing the first list "z" twice.

At this point the student thinks, "Um... what? How
can an object contain another object *twice*?"
If he's still thinking in physical terms, this
sentence is nonsensical.

It gets even worse with:

x = [1, 2]
x[1] = x

Now you have to say that the list contains *itself*
in some weird Tardis-like fashion!

I can't think of any way to dispel the confusion
verbally without using some word like "reference"
or "pointer" or something with an equivalent meaning.
Something that suggests a level of indirectness.

> A diagram may help, especially for more complicated situations,

Seems to me that a diagram is far and away the
easiest and most effective way to convey what's
really going on. It's difficult to do that with
words alone, because English isn't really equipped
to talk about it precisely enough.

-- 
Greg

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

#90948 — Re: List semantics [was Re: Slices time complexity]

On Wednesday, May 20, 2015 at 4:54:13 AM UTC-4, Gregory Ewing wrote:
> Steven D'Aprano wrote:
> > A diagram may help, especially for more complicated situations,
> 
> Seems to me that a diagram is far and away the
> easiest and most effective way to convey what's
> really going on. It's difficult to do that with
> words alone, because English isn't really equipped
> to talk about it precisely enough.

FWIW, this was my attempt at explaining names and values:
http://nedbatchelder.com/text/names.html, which I turned
into a PyCon talk this year: http://nedbatchelder.com/text/names1.html

It doesn't get quite as far as slice semantics, but deals with
"refers to" and "change", both of which are tricky to nail down
well.  Not sure I did... :)

--Ned.

> 
> -- 
> Greg

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

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

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

csiph-web