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

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

Re: The “does Python have variables?” debate

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: The “does Python have variables?” debate Ned Batchelder <ned@nedbatchelder.com> - 2014-05-06 21:19 -0400
    Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-07 09:18 +0300
      Re: The “does Python have variables?” debate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-07 09:51 +0100
      Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-07 06:00 -0700
        Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-07 17:17 +0300
          Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 00:30 +1000
      Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 00:14 +1000
        Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-07 17:20 +0300
      Re: The “does Python have variables?” debate Jerry Hill <malaclypse2@gmail.com> - 2014-05-07 11:48 -0400
        Re: The “does Python have variables?” debate Mark H Harris <harrismh777@gmail.com> - 2014-05-07 14:31 -0500
          Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 05:57 +1000
            Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 00:15 +0300
              Re: The “does Python have variables?” debate Mark H Harris <harrismh777@gmail.com> - 2014-05-07 16:35 -0500
                Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 01:27 +0000
                  Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 12:09 +1000
                    Re: The “does Python have variables?” debate Steven D'Aprano <steve@pearwood.info> - 2014-05-08 03:41 +0000
                  Re: The “does Python have variables?” debate Dan Sommers <dan@tombstonezero.net> - 2014-05-08 03:43 +0000
                  Re: The “does Python have variables?” debate Mark H Harris <harrismh777@gmail.com> - 2014-05-09 17:34 -0500
                    Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 01:11 +0000
                      Re: The “does Python have variables?” debate Larry Hudson <orgnut@yahoo.com> - 2014-05-10 00:46 -0700
              Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 10:35 +1000
                Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 01:32 +0000
                Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 09:19 +0300
                  Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 16:40 +1000
                    Re: The "does Python have variables?" debate Rustom Mody <rustompmody@gmail.com> - 2014-05-07 23:50 -0700
                      Re: The "does Python have variables?" debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 10:03 +0300
              Re: The “does Python have variables?” debate Ned Batchelder <ned@nedbatchelder.com> - 2014-05-07 21:33 -0400
              Re: The “does Python have variables?” debate Johannes Schneider <johannes.schneider@galileo-press.de> - 2014-05-08 09:26 +0200
                Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-09 00:54 +0000
              Re: The “does Python have variables?” debate Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org> - 2014-05-08 10:07 +0200
              Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 18:14 +1000
                Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 13:22 +0000
              Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 18:34 +1000
                Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 12:43 +0300
                  Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-08 21:14 +1000
                    Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 15:01 +0300
                      Re: The “does Python have variables?” debate Ben Finney <ben@benfinney.id.au> - 2014-05-09 05:14 +1000
                      Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 14:50 -0700
                        Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-09 00:02 +0000
                          Re: The �  debate Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-05-09 13:10 +1200
                            Re: The �  debate Ben Finney <ben@benfinney.id.au> - 2014-05-09 13:13 +1000
                            Re: The �  debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 01:34 +0000
                              Re: The �  debate Mark H Harris <harrismh777@gmail.com> - 2014-05-09 21:34 -0500
                              Re: The �  debate Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-05-10 17:58 +1200
                                Re: The � debate Chris Angelico <rosuav@gmail.com> - 2014-05-10 17:10 +1000
                                  Re: The � debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 07:48 +0000
                                    Re: The � debate Chris Angelico <rosuav@gmail.com> - 2014-05-10 18:01 +1000
                                      Re: The � debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-10 11:21 +0300
                                    Re: The � debate Rustom Mody <rustompmody@gmail.com> - 2014-05-10 02:05 -0700
                                      Re: The � debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-10 12:30 -0700
                                  Re: The � debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-10 11:18 +0300
                                    Re: The � debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 09:31 +0000
                  Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 13:18 +0000
                    Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 23:46 +1000
                      Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 14:22 +0000
                        Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 00:51 +1000
                          Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 16:04 +0000
                            Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 02:10 +1000
                            Re: The “does Python have variables?” debate Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-08 21:02 -0400
                              Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-09 01:32 +0000
                                Re: The “does Python have variables?” debate Roy Smith <roy@panix.com> - 2014-05-08 22:21 -0400
                                  Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 12:31 +1000
                                    Re: The "does Python have variables?" debate Rustom Mody <rustompmody@gmail.com> - 2014-05-08 22:40 -0700
                                      Re: The "does Python have variables?" debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 15:51 +1000
                                        Re: The "does Python have variables?" debate Rustom Mody <rustompmody@gmail.com> - 2014-05-09 07:09 -0700
                                          Re: The "does Python have variables?" debate Chris Angelico <rosuav@gmail.com> - 2014-05-10 00:29 +1000
                                            Re: The "does Python have variables?" debate Rustom Mody <rustompmody@gmail.com> - 2014-05-09 09:07 -0700
                                  Re: The “does Python have variables?â€瑩 debate Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-09 19:51 -0400
                                  Re: The “does Python have variables?â€瑩 debate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-10 01:03 +0100
                              Fortran (Was: The "does Python have variables?" debate) Roy Smith <roy@panix.com> - 2014-05-10 09:42 -0400
                                Re: Fortran (Was: The "does Python have variables?" debate) Terry Reedy <tjreedy@udel.edu> - 2014-05-10 14:31 -0400
                                Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 01:17 -0500
                                  Re: Fortran (Was: The "does Python have variables?" debate) Rustom Mody <rustompmody@gmail.com> - 2014-05-11 00:01 -0700
                                  Re: Fortran (Was: The "does Python have variables?" debate) Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 07:09 +0000
                                    Re: Fortran (Was: The "does Python have variables?" debate) Tomasz Rola <rtomek@ceti.pl> - 2014-05-11 18:09 +0200
                                      Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-11 19:27 +0300
                                        Re: Fortran Roy Smith <roy@panix.com> - 2014-05-11 13:51 -0400
                                          Re: Fortran Chris Angelico <rosuav@gmail.com> - 2014-05-12 04:08 +1000
                                            Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 23:51 +0000
                                              Re: Fortran Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-12 01:27 +0100
                                                Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-12 02:28 +0000
                                                  Re: Fortran Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-12 10:05 +0100
                                                  Re: Fortran Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-12 20:52 -0400
                                          Re: Fortran Ethan Furman <ethan@stoneleaf.us> - 2014-05-11 11:05 -0700
                                          Re: Fortran Chris Angelico <rosuav@gmail.com> - 2014-05-12 04:33 +1000
                                            Re: Fortran Roy Smith <roy@panix.com> - 2014-05-11 14:43 -0400
                                              Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 23:15 +0000
                                                Re: Fortran MRAB <python@mrabarnett.plus.com> - 2014-05-12 00:51 +0100
                                                  Re: Fortran Roy Smith <roy@panix.com> - 2014-05-11 20:14 -0400
                                                    Re: Fortran alister <alister.nospam.ware@ntlworld.com> - 2014-05-12 14:14 +0000
                                                  Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-12 01:11 +0000
                                                    Re: Fortran Dave Angel <d@davea.name> - 2014-05-11 23:27 -0400
                                                    Re: Fortran Grant Edwards <invalid@invalid.invalid> - 2014-05-12 14:07 +0000
                                              Re: Fortran Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-11 21:12 -0400
                                    Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-12 02:42 +1000
                                    Re: Fortran Tomasz Rola <rtomek@ceti.pl> - 2014-05-11 20:04 +0200
                                    Re: Fortran Chris Angelico <rosuav@gmail.com> - 2014-05-12 04:12 +1000
                                  Re: Fortran (Was: The "does Python have variables?" debate) Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-05-11 19:05 +0200
                                    Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 13:54 -0500
                                      Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-12 04:59 +1000
                                        Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 14:14 -0500
                                          Re: Fortran (Was: The "does Python have variables?" debate) albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-29 14:06 +0000
                                            Re: Fortran (Was: The "does Python have variables?" debate) Peter Pearson <ppearson@nowhere.invalid> - 2014-05-29 17:53 +0000
                                      Re: Fortran (Was: The "does Python have variables?" debate) Dave Angel <davea@davea.name> - 2014-05-11 23:10 -0400
                                        Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 23:10 -0500
                                          Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-11 23:26 -0500
                                            Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-12 14:53 +1000
                                      Re: Fortran (Was: The "does Python have variables?" debate) Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-05-12 10:44 +0200
                                        Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-13 00:33 -0500
                                          Re: Fortran (Was: The "does Python have variables?" debate) Steven D'Aprano <steve@pearwood.info> - 2014-05-13 05:48 +0000
                                            Re: Fortran (Was: The "does Python have variables?" debate) Mark H Harris <harrismh777@gmail.com> - 2014-05-13 00:55 -0500
                                            Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-13 15:56 +1000
                                              Re: Fortran (Was: The "does Python have variables?" debate) Steven D'Aprano <steve@pearwood.info> - 2014-05-13 09:34 +0000
                                                Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-13 20:00 +1000
                                                  Re: Fortran (Was: The "does Python have variables?" debate) Rustom Mody <rustompmody@gmail.com> - 2014-05-13 03:44 -0700
                                                    Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-13 20:50 +1000
                                            Re: Fortran (Was: The "does Python have variables?" debate) Gene Heskett <gheskett@wdtv.com> - 2014-05-13 02:31 -0400
                                              Re: Fortran (Was: The "does Python have variables?" debate) Steven D'Aprano <steve@pearwood.info> - 2014-05-13 07:22 +0000
                                                Re: Fortran (Was: The "does Python have variables?" debate) Roy Smith <roy@panix.com> - 2014-05-13 07:16 -0400
                                                  Re: Fortran (Was: The "does Python have variables?" debate) Chris Angelico <rosuav@gmail.com> - 2014-05-13 21:21 +1000
                                                  Re: Fortran (Was: The "does Python have variables?" debate) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-13 14:42 +0100
                                                Re: Fortran (Was: The "does Python have variables?" debate) Gene Heskett <gheskett@wdtv.com> - 2014-05-13 07:42 -0400
                                          Re: Fortran Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-05-13 19:33 +0200
                                            Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-13 22:57 +0300
                                              Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-14 00:10 +0000
                                                Re: Fortran Ian Kelly <ian.g.kelly@gmail.com> - 2014-05-13 21:43 -0600
                                                Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-14 07:35 +0300
                                                  Re: Fortran Steven D'Aprano <steve@pearwood.info> - 2014-05-14 06:58 +0000
                                                    Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-14 11:46 +0300
                                                Re: Fortran Sturla Molden <sturla.molden@gmail.com> - 2014-05-14 23:05 +0000
                                                struct.unpack: why 's' fmt char convert to bytestring GuoChao <cx63@outlook.com> - 2014-05-15 20:34 +0800
                                                Re: struct.unpack: why 's' fmt char convert to bytestring Dave Angel <davea@davea.name> - 2014-05-15 09:49 -0400
                                                Re: struct.unpack: why 's' fmt char convert to bytestring MRAB <python@mrabarnett.plus.com> - 2014-05-15 15:47 +0100
                                              Re: Fortran Alain Ketterlin <alain@dpt-info.u-strasbg.fr> - 2014-05-14 15:13 +0200
                                              Re: Fortran albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-29 14:26 +0000
                                                Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-29 17:50 +0300
                                                  Re: Fortran Chris Angelico <rosuav@gmail.com> - 2014-05-30 00:58 +1000
                                                    Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-29 18:09 +0300
                                                  Re: Fortran Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-29 17:57 +0000
                                                    Re: Fortran Marko Rauhamaa <marko@pacujo.net> - 2014-05-29 21:55 +0300
                            Re: The “does Python have variables?” debate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-09 09:13 +0100
                    Re: The “does Python have variables?” debate Michael Torrie <torriem@gmail.com> - 2014-05-08 08:06 -0600
                    Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-09 00:13 +1000
              Re: The “does Python have variables?” debate Terry Reedy <tjreedy@udel.edu> - 2014-05-08 15:21 -0400
                Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 23:06 +0300
                  Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 15:36 -0700
              Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 17:05 -0700
              Re: The “does Python have variables?” debate Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-05-09 01:47 +0100
        Re: The “does Python have variables?” debate Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 00:57 +0000
        Re: The “does Python have variables?” debate Roy Smith <roy@panix.com> - 2014-05-08 08:41 -0400
          Re: The “does Python have variables?” debate Chris Angelico <rosuav@gmail.com> - 2014-05-08 22:54 +1000
          Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 06:18 -0700
            Re: The “does Python have variables?” debate Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 17:03 +0300
              Re: The “does Python have variables?” debate Ethan Furman <ethan@stoneleaf.us> - 2014-05-08 16:09 -0700
          Re: The “does Python have variables?” debate "Neil D. Cerutti" <neilc@norwich.edu> - 2014-05-08 10:47 -0400

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

#71062

Marko Rauhamaa <marko@pacujo.net> writes:

> Ben Finney <ben@benfinney.id.au>:
>
> > That's why I always try to say “Python doesn't have variables the way
> > you might know from many other languages”,
>
> Please elaborate. To me, Python variables are like variables in all
> programming languages I know.

Many established and still-popular languages have the following
behaviour::

    # pseudocode

    foo = [1, 2, 3]
    bar = foo          # bar gets the value [1, 2, 3]
    assert foo == bar  # succeeds
    foo[1] = "spam"    # foo is now == [1, "spam", 3]
    assert foo == bar  # FAILS, ‘bar’ == [1, 2, 3]

This is because such languages treat each variable as “containing” a
value. Assignment puts another copy of the value in the variable, after
which those two values have a distinct history. What happens to one
value does not affect the other.

Python, on the other hand, has this behaviour::

    foo = [1, 2, 3]
    bar = foo          # ‘bar’ binds to the value ‘[1, 2, 3]’
    assert foo == bar  # succeeds
    foo[1] = "spam"    # ‘foo’ *and* ‘bar’ now == [1, "spam", 3]
    assert foo == bar  # succeeds, ‘bar’ is bound to ‘[1, "spam", 3]’

The assignment statement in Python does not put a value in a container,
the way it does for variables in many popular languages. Instead,
assignment binds the left-hand-side reference (in these examples, names)
to the right-hand-side value. Both remain references to the same value
until the binding changes to some other value.

So Python doesn't have variables in the way programmers coming from many
other languages expect. Instead, it has references bound to values.

-- 
 \      “Actually I made up the term “object-oriented”, and I can tell |
  `\            you I did not have C++ in mind.” —Alan Kay, creator of |
_o__)                                        Smalltalk, at OOPSLA 1997 |
Ben Finney

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

#71066

On Thu, 08 May 2014 10:35:46 +1000, Ben Finney wrote:

> Marko Rauhamaa <marko@pacujo.net> writes:
> 
>> Ben Finney <ben@benfinney.id.au>:
>>
>> > That's why I always try to say “Python doesn't have variables the way
>> > you might know from many other languages”,
>>
>> Please elaborate. To me, Python variables are like variables in all
>> programming languages I know.
> 
> Many established and still-popular languages have the following
> behaviour::
> 
>     # pseudocode
>     foo = [1, 2, 3]
>     bar = foo          # bar gets the value [1, 2, 3] 
>     assert foo == bar  # succeeds
>     foo[1] = "spam"    # foo is now == [1, "spam", 3] 
>     assert foo == bar  # FAILS, ‘bar’ == [1, 2, 3]

Pascal and Fortran are examples of this.

Any more recent examples? Any examples of languages with dynamic typing 
but this behaviour?

I note also that one may still have a name-binding model with copy-on-
assign semantics. For example, one might add syntactic sugar to a Python-
like language such that:

    spam = eggs

is a name binding, and 

    spam := eggs

makes a copy of eggs before binding.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#71079

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

> Many established and still-popular languages have the following
> behaviour::
>
>     # pseudocode
>
>     foo = [1, 2, 3]
>     bar = foo          # bar gets the value [1, 2, 3]
>     assert foo == bar  # succeeds
>     foo[1] = "spam"    # foo is now == [1, "spam", 3]
>     assert foo == bar  # FAILS, ‘bar’ == [1, 2, 3]
>
> This is because such languages treat each variable as “containing” a
> value.

I don't think that has much to do with variables but rather the values.

What you are describing is that Python has pointer semantics. Your
example, properly understood and translated, will yield Python-esque
results in any programming language:

   #!/bin/bash
   a = /tmp/xyz
   touch $a
   b = $a
   cmp $a $b || exit
   echo z >>/tmp/xyz
   cmp $a $b || exit


   #include <stdlib.h>
   #include <assert.h>
   int main(void)
   {
       int *a = malloc(sizeof *a);
       *a = 7;
       int *b = a;
       assert(*a == *b);
       *a = 8;
       assert(*a == *b);
       return 0;
   }


Marko

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

#71080

Marko Rauhamaa <marko@pacujo.net> writes:

> What you are describing is that Python has pointer semantics.

That doesn't describe it, no. To my eye, “pointer semantics” entails
that one can directly pass a pointer around as a value (which can't be
done for Python references), and that one can de-reference a pointer to
get the value pointed at (which can't be done for Python references).

> Your example, properly understood and translated, will yield
> Python-esque results in any programming language:
>
>    #!/bin/bash
>    a = /tmp/xyz
>    touch $a

Of course, if you feel free to turn “assignment” into something that
isn't assignment at all, you can get different results. But to do so,
you've had to ignore the language's native assignment operator, which
*doesn't* work that way.

I get the impression you're no longer engaging in this discussion trying
to learn, but rather to score points. I refuse to play.

-- 
 \         “Of all classes the rich are the most noticed and the least |
  `\      studied.” —John Kenneth Galbraith, _The Age of Uncertainty_, |
_o__)                                                             1977 |
Ben Finney

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

#71081 — Re: The "does Python have variables?" debate

On Thursday, May 8, 2014 12:10:45 PM UTC+5:30, Ben Finney wrote:
> Marko Rauhamaa writes:

> > What you are describing is that Python has pointer semantics.

> That doesn't describe it, no. To my eye, "pointer semantics" entails
> that one can directly pass a pointer around as a value (which can't be
> done for Python references), and that one can de-reference a pointer to
> get the value pointed at (which can't be done for Python references).

> > Your example, properly understood and translated, will yield
> > Python-esque results in any programming language:
> >    #!/bin/bash
> >    a = /tmp/xyz
> >    touch $a

> Of course, if you feel free to turn "assignment" into something that
> isn't assignment at all, you can get different results. But to do so,
> you've had to ignore the language's native assignment operator, which
> *doesn't* work that way.

> I get the impression you're no longer engaging in this discussion trying
> to learn, but rather to score points. I refuse to play.

I get the impression that you dont get the difference (I think Marko is making)
between 
- language has pointers
- language has pointer semantics

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

#71082 — Re: The "does Python have variables?" debate

Rustom Mody <rustompmody@gmail.com>:

> I get the impression that you dont get the difference (I think Marko
> is making) between
> - language has pointers
> - language has pointer semantics

Yes.

Like Python, Java doesn't have pointers. However, when you try to
dereference null, a NullPointerException is thrown. Pointers shining
through...

Lisp never tried to pretend otherwise. Any introductory lisp tutorial
will draw pictures of CAR/CDR cells with pointers coming out.


Marko

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

#71067

On 5/7/14 8:35 PM, Ben Finney wrote:
> Marko Rauhamaa <marko@pacujo.net> writes:
>
>> Ben Finney <ben@benfinney.id.au>:
>>
>>> That's why I always try to say “Python doesn't have variables the way
>>> you might know from many other languages”,
>>
>> Please elaborate. To me, Python variables are like variables in all
>> programming languages I know.
>
> Many established and still-popular languages have the following
> behaviour::
>
>      # pseudocode
>
>      foo = [1, 2, 3]
>      bar = foo          # bar gets the value [1, 2, 3]
>      assert foo == bar  # succeeds
>      foo[1] = "spam"    # foo is now == [1, "spam", 3]
>      assert foo == bar  # FAILS, ‘bar’ == [1, 2, 3]
>

Can we make this concrete by speaking about a specific language?  I 
don't recognize this.  I thought we were concerned with beginners 
incorrectly thinking Python worked like C, but this is nothing like C.

-- 
Ned Batchelder, http://nedbatchelder.com

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

#71084

On 08.05.2014 02:35, Ben Finney wrote:
> Marko Rauhamaa <marko@pacujo.net> writes:
[..]
> Python, on the other hand, has this behaviour::
>
>      foo = [1, 2, 3]
>      bar = foo          # ‘bar’ binds to the value ‘[1, 2, 3]’
>      assert foo == bar  # succeeds
>      foo[1] = "spam"    # ‘foo’ *and* ‘bar’ now == [1, "spam", 3]
[..]

IMHO this is the behavior of having a variable pointing to it's value; 
foo to the list and bar to foo.


consider the following:
 >>> def f(l):
...     l[1] = 'foo'
...
 >>> l1 =  [1,2,3]
 >>> f(l1)
 >>> l1
[1, 'foo', 3]

this means, l1 consists of "pointers" to its values.
Otherwise, it's not calling by reference, because

 >>> g(l1)
 >>> l1
[1, 'foo', 3]

does not change l1. Once again, if I pass an object it behaves like 
calling by reference:

 >>> class A:
...     a = 0
...
 >>> a = A()
 >>> a.a
0
 >>> def h(a1):
...     a1.a = 1
...
 >>> h(a)
 >>> a.a
1

bg,
Johannes


-- 
Johannes Schneider
Webentwicklung
johannes.schneider@galileo-press.de
Tel.: +49.228.42150.xxx

Galileo Press GmbH
Rheinwerkallee 4 - 53227 Bonn - Germany
Tel.: +49.228.42.150.0 (Zentrale) .77 (Fax)
http://www.galileo-press.de/

Geschäftsführer: Tomas Wehren, Ralf Kaulisch, Rainer Kaltenecker
HRB 8363 Amtsgericht Bonn

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

#71140

On Thu, 08 May 2014 09:26:57 +0200, Johannes Schneider wrote:

> On 08.05.2014 02:35, Ben Finney wrote:
>> Marko Rauhamaa <marko@pacujo.net> writes:
> [..]
>> Python, on the other hand, has this behaviour::
>>
>>      foo = [1, 2, 3]
>>      bar = foo          # ‘bar’ binds to the value ‘[1, 2, 3]’ assert
>>      foo == bar  # succeeds
>>      foo[1] = "spam"    # ‘foo’ *and* ‘bar’ now == [1, "spam", 3]
> [..]
> 
> IMHO this is the behavior of having a variable pointing to it's value;
> foo to the list and bar to foo.

You're almost right -- foo is a reference to the list, that is, foo 
"points to" the list. But the second part is completely wrong: bar does 
not point at *foo*, it points at the *same list* that foo points to.

What's the difference? Consider this ASCII diagram (best viewed in a 
monospaced font):

foo ------+
          |
          V
bar ---> [1, 2, 3]

If you modify the list, both foo and bar see the same change, because 
they refer to the same list. But if you *assign* to either foo or bar, 
let's say foo:

foo ---> 42
bar ---> [1, 2, 3]


bar continues to refer to the list, while foo has been rebound to a new 
value. That's how Python works. Now, instead, let's suppose bar pointed 
to foo:

bar ---> foo ---> [1, 2, 3]

Both bar's and foo's value is the list, like before. (We suppose that, 
when looking up a name, Python follows the chain of pointers as far as 
needed until it reaches a value.) And now we reassign foo:

bar ---> foo ---> [4, 5, 6, 7]

But since bar still points to foo, bar's value *follows* foo even after 
rebinding foo. bar is an alias for foo. And that is *not* how Python 
works: using the word "alias" to describe foo = bar = [1, 2, 3] is 
misleading. 


> consider the following:
>  >>> def f(l):
> ...     l[1] = 'foo'
> ...
>  >>> l1 =  [1,2,3]
>  >>> f(l1)
>  >>> l1
> [1, 'foo', 3]
> 
> this means, l1 consists of "pointers" to its values. 

That does not follow. It happens to be that CPython does implement lists 
as an array of pointers, but that is a coincidence and is not a 
consequence of what you see. For example, ll might have been a linked 
list of chained tuples (value, next) rather than a built-in list, and you 
would still see the same result.

What you are seeing is that setting an item causes an in-place 
modification, not a rebinding of the name ll. l[1] = 'foo' calls 
l.__setitem__ which mutates the list, it doesn't rebind l.

This confusion is a good demonstration of why the meme that Python 
variables is "just like C pointers" is harmful.


> Otherwise, it's not calling by reference,

But it isn't call by reference. If it were call by reference, you could 
write a swap procedure that swaps the contents of two variables:

a = 1
b = 2
swap(a, b)
print a, b
=> prints 2, 1


You cannot do this in Python! Python has no call by reference.

Please read this for more information:

http://import-that.dreamwidth.org/1130.html



[...snip example...]
> does not change l1. Once again, if I pass an object

But lists ARE objects. All values in Python are objects.


> it behaves like calling by reference:

It certainly does not. The best you can say is that mutation operations 
can, under some circumstances, mimic some of the effects of call by 
reference. For example, instead of using call by reference to get an 
output parameter, like Pascal uses, you can pass an object and mutate the 
object in place so that the caller sees the mutation.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#71085

Le 08/05/2014 02:35, Ben Finney a écrit :
> Marko Rauhamaa <marko@pacujo.net> writes:
>
>> Ben Finney <ben@benfinney.id.au>:
>>
>>> That's why I always try to say “Python doesn't have variables the way
>>> you might know from many other languages”,
>>
>> Please elaborate. To me, Python variables are like variables in all
>> programming languages I know.
>
> Many established and still-popular languages have the following
> behaviour::
>
>      # pseudocode
>
>      foo = [1, 2, 3]
>      bar = foo          # bar gets the value [1, 2, 3]
>      assert foo == bar  # succeeds
>      foo[1] = "spam"    # foo is now == [1, "spam", 3]
>      assert foo == bar  # FAILS, ‘bar’ == [1, 2, 3]
>
> This is because such languages treat each variable as “containing” a
> value. Assignment puts another copy of the value in the variable, after
> which those two values have a distinct history. What happens to one
> value does not affect the other.
>
> Python, on the other hand, has this behaviour::
>
>      foo = [1, 2, 3]
>      bar = foo          # ‘bar’ binds to the value ‘[1, 2, 3]’
>      assert foo == bar  # succeeds
>      foo[1] = "spam"    # ‘foo’ *and* ‘bar’ now == [1, "spam", 3]
>      assert foo == bar  # succeeds, ‘bar’ is bound to ‘[1, "spam", 3]’
>
> The assignment statement in Python does not put a value in a container,
> the way it does for variables in many popular languages. Instead,
> assignment binds the left-hand-side reference (in these examples, names)
> to the right-hand-side value. Both remain references to the same value
> until the binding changes to some other value.
>
> So Python doesn't have variables in the way programmers coming from many
> other languages expect. Instead, it has references bound to values.
>
For me, names bound to values is the same concept as pointer pointing to 
memory. bar = foo copies the pointer and not the underlying memory. This 
is not a foreign concept to C programmers.


---
Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active.
http://www.avast.com

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

#71086

On Thu, May 8, 2014 at 6:07 PM, Joseph Martinot-Lagarde
<joseph.martinot-lagarde@m4x.org> wrote:
> For me, names bound to values is the same concept as pointer pointing to
> memory. bar = foo copies the pointer and not the underlying memory. This is
> not a foreign concept to C programmers.
>

That is how it's implemented in CPython, after all... modulo the whole
refcounting thing, of course. But that's not strictly a part of the
definition of Python; it's just implementation. You could implement
Python on pencil-and-paper (aka a dry run), and as long as you have a
concept of names that reference objects, it's going to be fine. The
"reference" might be done with a physical piece of string connecting a
Post-It note with a name to a box with the object's state, meaning
there's no way of copying any pointer, and it's still Python.

ChrisA

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

#71096

On Thu, 08 May 2014 18:14:48 +1000, Chris Angelico wrote:

> On Thu, May 8, 2014 at 6:07 PM, Joseph Martinot-Lagarde
> <joseph.martinot-lagarde@m4x.org> wrote:
>> For me, names bound to values is the same concept as pointer pointing
>> to memory. bar = foo copies the pointer and not the underlying memory.
>> This is not a foreign concept to C programmers.
>>
>>
> That is how it's implemented in CPython, after all... modulo the whole
> refcounting thing, of course. But that's not strictly a part of the
> definition of Python; it's just implementation.

Yes. And that's *not* how Jython or IronPython implement it, since 
neither Java nor .Net provide pointers (in the C sense). Nor does PyPy, 
which is Python written in Python (to be pedantic, RPython).

Now obviously you need to have *some* way to implement indirect 
references. If this were 1965 or so and we were implementing Python in 
FORTRAN, we'd use a big array and use array indexes as our "pointers". 
After all, isn't that what C pointers are like? The index (address) of a 
block of memory in a giant array (the heap)?

Given the architecture of our computing devices, I would expect that if 
you go down deep enough, you would find something like a C pointer. But 
Python is not necessarily implemented on such a device. In principle, we 
could write a Python interpreter on a Turing machine, or using clockwork. 
"Python uses pointers" is an *implementation detail*, not a language 
feature.

> You could implement
> Python on pencil-and-paper (aka a dry run), and as long as you have a
> concept of names that reference objects, it's going to be fine. The
> "reference" might be done with a physical piece of string connecting a
> Post-It note with a name to a box with the object's state, meaning
> there's no way of copying any pointer, and it's still Python.

Yes, exactly.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#71087

Ned Batchelder <ned@nedbatchelder.com> writes:

> I thought we were concerned with beginners incorrectly thinking Python
> worked like C, but this [pseudocode] is nothing like C.

I'm not concerned about where these misconceptions come from, whether C
or any other language.

The concern is that the term “variable”'s existing baggage in the
programming community encourages *false inferences* that a beginner
doesn't even realise they're drawing. By discouraging use of that term
and replacing it with “name binding” or “reference”, a more accurate
model is implied, to the extent that its existing baggage encourages
significantly fewer false inferences.

(good sigmonster, have a cookie)

-- 
 \      “We suffer primarily not from our vices or our weaknesses, but |
  `\    from our illusions.” —Daniel J. Boorstin, historian, 1914–2004 |
_o__)                                                                  |
Ben Finney

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

#71088

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

> The concern is that the term “variable”'s existing baggage in the
> programming community encourages *false inferences* that a beginner
> doesn't even realise they're drawing. By discouraging use of that term
> and replacing it with “name binding” or “reference”, a more accurate
> model is implied, to the extent that its existing baggage encourages
> significantly fewer false inferences.

I don't think flogging the beginner for talking about variables helps
them get Python's data model. All that accomplishes is that they will
shut up about variables in the fear of being flogged and not understand
the data model any better.

Any C programmer will get Python easily because they are familiar with
malloc() and pointers. You will have more trouble with the beginner who
has no prior programming knowledge. Do you first have to drag them along
the keel by teaching them C and them graduating them to higher-level
programming languages?

Back to the topic of variables. IMO the crucial factor that makes
Python's variables ordinary, prosaic, programming language variables is
the assignment. A real "non-variable" name-value binding would be
permanent. Lisp without setq (or scheme without set!) would be such a
language; in fact, the implementation would then not have anything
resembling variables on the inside. It's the resettability that makes a
variable a mundane memory slot, whether you have access to its address
or not.

(BTW, in lambda calculus and predicate logic, the names cannot be
rebound, but they are still called variables.)


Marko

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

#71091

Marko Rauhamaa <marko@pacujo.net> writes:

> I don't think flogging the beginner for talking about variables helps
> them get Python's data model. All that accomplishes is that they will
> shut up about variables in the fear of being flogged and not understand
> the data model any better.

Who does that? I haven't seen anyone raising this topic with a beginner
in a hostile manner (“flogging”? why the hyperbole?), and it's certainly
not characteristic of how the topic is raised here.

I don't know what your point is, but please don't prop up straw men to
make it.

-- 
 \        “Humanity has advanced, when it has advanced, not because it |
  `\     has been sober, responsible, and cautious, but because it has |
_o__)            been playful, rebellious, and immature.” —Tom Robbins |
Ben Finney

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

#71092

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

> Marko Rauhamaa <marko@pacujo.net> writes:
>
>> I don't think flogging the beginner for talking about variables helps
>> them get Python's data model. All that accomplishes is that they will
>> shut up about variables in the fear of being flogged and not
>> understand the data model any better.
>
> Who does that? I haven't seen anyone raising this topic with a
> beginner in a hostile manner (“flogging”? why the hyperbole?), and
> it's certainly not characteristic of how the topic is raised here.

Flogging, spanking, admonishing, whatever.

> I don't know what your point is, but please don't prop up straw men to
> make it.

Does that count as admonishing, at least?

Point being, shunning the term "variable" is counterproductive. Python
variables are nothing special and calling them "variables" doesn't
mislead anybody.


Marko

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

#71120

Marko Rauhamaa <marko@pacujo.net> writes:

> Ben Finney <ben@benfinney.id.au>:
>
> > Who does that? I haven't seen anyone raising this topic with a
> > beginner in a hostile manner (“flogging”? why the hyperbole?), and
> > it's certainly not characteristic of how the topic is raised here.
>
> Flogging, spanking, admonishing, whatever.

So, you just continue asserting that, without responding to a request to
back it up.

> > I don't know what your point is, but please don't prop up straw men to
> > make it.
>
> Does that count as admonishing, at least?

Yes, I admonished you.

> Point being, shunning the term "variable" is counterproductive. Python
> variables are nothing special and calling them "variables" doesn't
> mislead anybody.

Okay, that's your point. You haven't backed it up, so I'll ignore it for now.

-- 
 \     “If you ever catch on fire, try to avoid seeing yourself in the |
  `\        mirror, because I bet that's what REALLY throws you into a |
_o__)                                             panic.” —Jack Handey |
Ben Finney

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

#71131

On 05/08/2014 12:14 PM, Ben Finney wrote:
> Marko Rauhamaa writes:
>
>> Point being, shunning the term "variable" is counterproductive. Python
>> variables are nothing special and calling them "variables" doesn't
>> mislead anybody.
>
> Okay, that's your point. You haven't backed it up, so I'll ignore it for now.

I'll speak up as a data point:  When I came to Python my only experience with variables was: it's a box that holds a 
value.  So it took me a while, and a really, really good explanation with beautiful ascii art, to explain to me how 
Python variables work.

The astute reader will notice I still called them variables.  Had they been called something else I may have discovered 
sooner what the difference was, but I don't think it's worth mangling the (English) language.  As a newcomer to Python I 
also didn't know that functions were first class objects, so it was a while before I realized the cool things you could 
do because of that -- yet we still call them functions, not, for example, callable objects.

Python has variables -- they just work more like aliases.  (Okay, who wants to make the graphic of a Python object in a 
mug shot? ;)

I guess my point is, calling aliases variables wasn't the misleading part, it was my lack of knowledge that there was 
more than one kind of variable possible.  Such ignorance is only solved by learning different languages, and isn't aided 
if every language has their own unique terminology.

--
~Ethan~

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

#71137

On Thu, 08 May 2014 14:50:08 -0700, Ethan Furman wrote:

> I guess my point is, calling aliases variables wasn't the misleading
> part, it was my lack of knowledge that there was more than one kind of
> variable possible.  Such ignorance is only solved by learning different
> languages,

The *only* way?

I'm feeling kind of ignored and unloved here... *wink* As I've said 
multiple times now, my personal experience is that "such ignorance" of 
different variable semantics can also be solved by explicitly rejecting 
the use of the term "variable".

Let me put it this way: both horse-drawn carriages and cars are examples 
of the same general concept. "Horse-drawn carriage" is a back-formation 
from the time when people wished to distinguish carriages with horses 
from horseless carriages. Today we routinely call horseless carriages 
"cars", and nobody would blink if I pointed at a Prius or a Ford Explorer 
and said "that's not a carriage, it's a car" except to wonder why on 
earth I thought something so obvious needed to be said.

And yet the majority view expressed on this thread is that somehow 
programmers are allegedly confused and distressed by the use of distinct 
terminology for different kinds of variable name-value bindings.

Programmers tend to be more intelligent than average, they tend to know 
dozens or hundreds of very technical terms differing only in fine degrees 
of detail (I'm still not sure what the difference, if any, between 
*delegation* and *composition* is, or between the ever more specialist 
adaptor design patterns). We expect newbie programmers to learn all sorts 
of jargon: functions, factories, methods, class methods, static methods, 
types, decorators, descriptors, trampolines, threads, namespaces, 
mutable, immutable, properties... and yet distinguishing "variable" from 
"name binding" is supposed to cause more harm than good? I remain 
unconvinced.


> and isn't aided if every language has their own unique terminology.

Nobody is talking about giving every language their own unique 
terminology. There are, so far as I know, two general models of 
computational variables: the name binding in a dynamic namespace model 
and the static memory location model. Different languages may implement 
slight variations on these, for example CPython uses fixed memory 
locations for local variables of functions as an optimization, Java uses 
name binding except for unboxed native data types, traditionally Forth 
doesn't use fixed memory locations but a threaded list, but the basic 
dichotomy is very common. So to a first approximation, most languages 
fall fully or mostly within one of two categories: they have name 
bindings, or C-style variables. Name binding is even a standard computer 
science term:

https://en.wikipedia.org/wiki/Name_binding

The pedantic reader will notice that "name binding" equally applies to 
the C compiler associating a name with a fixed memory location at compile 
time ("early binding") as the Python virtual machine associating a value 
with a key in a namespace at run time ("late binding"). Nevertheless, for 
a generation of programmers raised on C, "variable" means what C does.

The whole point is not that "name binding" somehow causes the reader to 
intuit the differences between early and late binding, or between boxes 
in fixed memory locations and name:value pairs in a namespace, but that 
it *opens their mind* to the possibility that they are using the wrong 
mental model. It is the start of the dialog, not the end.



-- 
Steven D'Aprano
http://import-that.dreamwidth.org/

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

#71142 — Re: The � debate

Steven D'Aprano wrote:
> Today we routinely call horseless carriages 
> "cars", and nobody would blink if I pointed at a Prius or a Ford Explorer 
> and said "that's not a carriage, it's a car" except to wonder why on 
> earth I thought something so obvious needed to be said.

That's only because the term "car" *is* well established.
The situation with the word "variable" is more like if you
pointed at a Prius and said "That's not a car, it's an
electric vehicle". Most people would wonder why you refused
to categorise it as a type of car.

If you look at the way the word "variable" is used across
a variety of language communities, the common meaning is
more or less "something that can appear on the left hand
side of an assignment statement".

Nobody seems to complain about using the term "assigment"
in relation to Python, despite it meaning something a bit
different from what it means in some other languages, so I
don't see anything wrong with using the term "variable"
with the above definition.

-- 
Greg

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

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

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

csiph-web