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

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

Re: Pass variable by reference

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: Pass variable by reference Ned Batchelder <ned@nedbatchelder.com> - 2014-05-06 16:31 -0400
    Re: Pass variable by reference Mark H Harris <harrismh777@gmail.com> - 2014-05-06 16:00 -0500
      Re: Pass variable by reference Ned Batchelder <ned@nedbatchelder.com> - 2014-05-06 17:27 -0400
      Re: Pass variable by reference Chris Angelico <rosuav@gmail.com> - 2014-05-07 09:46 +1000
        Re: Pass variable by reference Rustom Mody <rustompmody@gmail.com> - 2014-05-06 19:18 -0700
          Re: Pass variable by reference Chris Angelico <rosuav@gmail.com> - 2014-05-07 12:39 +1000
            Re: Pass variable by reference Rustom Mody <rustompmody@gmail.com> - 2014-05-06 19:54 -0700
              Re: Pass variable by reference Steven D'Aprano <steve@pearwood.info> - 2014-05-07 04:59 +0000
        Re: Pass variable by reference Mark H Harris <harrismh777@gmail.com> - 2014-05-07 13:11 -0500
          Re: Pass variable by reference Marko Rauhamaa <marko@pacujo.net> - 2014-05-08 00:22 +0300
            Values and objects [was Re: Pass variable by reference] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-08 01:08 +0000
              Re: Values and objects [was Re: Pass variable by reference] Mark H Harris <harrismh777@gmail.com> - 2014-05-09 16:56 -0500
                Re: Values and objects Marko Rauhamaa <marko@pacujo.net> - 2014-05-10 01:34 +0300
                  Re: Values and objects Ben Finney <ben@benfinney.id.au> - 2014-05-10 10:24 +1000
                  Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 01:01 +0000
                    Re: Values and objects Rustom Mody <rustompmody@gmail.com> - 2014-05-09 19:19 -0700
                      Re: Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-10 12:33 +1000
                        Re: Values and objects Rustom Mody <rustompmody@gmail.com> - 2014-05-09 20:05 -0700
                          Re: Values and objects Mark H Harris <harrismh777@gmail.com> - 2014-05-09 23:15 -0500
                        Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 06:15 +0000
                          Re: Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-10 17:21 +1000
                            Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 09:09 +0000
                              Re: Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-10 19:32 +1000
                              Re: Values and objects Ethan Furman <ethan@stoneleaf.us> - 2014-05-10 12:10 -0700
                              Re: Values and objects MRAB <python@mrabarnett.plus.com> - 2014-05-10 20:22 +0100
                              Re: Values and objects Ethan Furman <ethan@stoneleaf.us> - 2014-05-10 12:28 -0700
                              Re: Values and objects Terry Reedy <tjreedy@udel.edu> - 2014-05-10 16:16 -0400
                              Re: Values and objects Terry Reedy <tjreedy@udel.edu> - 2014-05-10 16:24 -0400
                              Re: Values and objects Devin Jeanpierre <jeanpierreda@gmail.com> - 2014-05-10 14:03 -0700
                                Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 03:17 +0000
                                  Re: Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-11 13:30 +1000
                                    Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 05:11 +0000
                                      Re: Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-11 15:22 +1000
                                        Re: Values and objects Rustom Mody <rustompmody@gmail.com> - 2014-05-10 22:31 -0700
                                          Re: Values and objects Marko Rauhamaa <marko@pacujo.net> - 2014-05-11 09:21 +0300
                                            Re: Values and objects Rustom Mody <rustompmody@gmail.com> - 2014-05-10 23:48 -0700
                                              Re: Values and objects Marko Rauhamaa <marko@pacujo.net> - 2014-05-11 18:10 +0300
                                            Re: Values and objects Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-05-11 11:26 +0300
                                              Re: Values and objects Rustom Mody <rustompmody@gmail.com> - 2014-05-11 01:48 -0700
                                                Re: Values and objects Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-05-11 15:22 +0300
                                                  Re: Values and objects Marko Rauhamaa <marko@pacujo.net> - 2014-05-11 18:46 +0300
                                                    Re: Values and objects Marko Rauhamaa <marko@pacujo.net> - 2014-05-11 22:56 +0300
                                              Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 12:51 +0000
                                                Re: Values and objects Rustom Mody <rustompmody@gmail.com> - 2014-05-11 07:12 -0700
                                      Re: Values and objects Ethan Furman <ethan@stoneleaf.us> - 2014-05-10 22:42 -0700
                                        Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 06:40 +0000
                              Re: Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-11 09:18 +1000
                                Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 03:11 +0000
                                  Re: Values and objects Rotwang <sg552@hotmail.co.uk> - 2014-05-11 14:46 +0100
                                    Re: Values and objects Ned Batchelder <ned@nedbatchelder.com> - 2014-05-11 14:40 -0400
                                      Re: Values and objects Rotwang <sg552@hotmail.co.uk> - 2014-05-12 00:06 +0100
                              Re: Values and objects Ethan Furman <ethan@stoneleaf.us> - 2014-05-10 18:28 -0700
                                Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 07:24 +0000
                              Re: Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-11 11:59 +1000
                                Re: Values and objects Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-11 07:29 +0000
                              Re: Values and objects Ethan Furman <ethan@stoneleaf.us> - 2014-05-10 21:46 -0700
                              Re: [Python-Dev] Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-11 16:08 +1000
                              Re: Values and objects albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-05-17 14:26 +0000
                  Re: Values and objects Chris Angelico <rosuav@gmail.com> - 2014-05-10 11:58 +1000
                    Re: Values and objects Marko Rauhamaa <marko@pacujo.net> - 2014-05-10 10:57 +0300
                      Re: Values and objects Jussi Piitulainen <jpiitula@ling.helsinki.fi> - 2014-05-10 11:06 +0300
                  Re: Values and objects Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-05-10 12:07 -0400
          Re: Pass variable by reference Chris Angelico <rosuav@gmail.com> - 2014-05-08 11:31 +1000
            Re: Pass variable by reference Mark H Harris <harrismh777@gmail.com> - 2014-05-09 17:30 -0500
              Abstractions [was Re: Pass variable by reference] Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-10 00:58 +0000
                Re: Abstractions [was Re: Pass variable by reference] Mark H Harris <harrismh777@gmail.com> - 2014-05-09 21:17 -0500
    Re: Pass variable by reference Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-05-07 01:14 +0000

Page 1 of 4  [1] 2 3 4  Next page →

#70985 — Re: Pass variable by reference

On 5/6/14 12:42 AM, Gary Herron wrote:
> This gets confusing, but in fact the most accurate answer is that Python
> does not have "variables", so there is no such thing as passing
> "variables" by reference or any other method.  Python *does* have names
> bound to values, but that's a very different thing. If necessary, you
> may consider that the *values* are passed by reference.

This meme bugs me so much.  Python has variables.  They work differently 
than variables in C.  In fact, they work by having names bound to values.

If you want to insist that Python has no variables, you will have to 
also say that neither do Javascript, Ruby, Java, PHP, etc.  And if 
Javascript has no variables, what does the var keyword mean?

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

[toc] | [next] | [standalone]

#70987

On 5/6/14 3:31 PM, Ned Batchelder wrote:
> On 5/6/14 12:42 AM, Gary Herron wrote:
>> This gets confusing, but in fact the most accurate answer is that Python
>> does not have "variables", so there is no such thing as passing
>> "variables" by reference or any other method.  Python *does* have names
>> bound to values, but that's a very different thing. If necessary, you
>> may consider that the *values* are passed by reference.
>
> This meme bugs me so much.  Python has variables.  They work differently
> than variables in C.  In fact, they work by having names bound to values.

What does the word "variable" mean. Think BASIC variables. You can set 
them, you can reset them, you can delete them, you can change them.  ... 
because they are variable.

Python has names bound to objects... some of which you may not change. 
Once the name is bound to an object you may bind it to another object, 
but you may not change it, nor may you change the object it is bound to 
if the object is immutable.

marcus

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

#70988

On 5/6/14 5:00 PM, Mark H Harris wrote:
> On 5/6/14 3:31 PM, Ned Batchelder wrote:
>> On 5/6/14 12:42 AM, Gary Herron wrote:
>>> This gets confusing, but in fact the most accurate answer is that Python
>>> does not have "variables", so there is no such thing as passing
>>> "variables" by reference or any other method.  Python *does* have names
>>> bound to values, but that's a very different thing. If necessary, you
>>> may consider that the *values* are passed by reference.
>>
>> This meme bugs me so much.  Python has variables.  They work differently
>> than variables in C.  In fact, they work by having names bound to values.
>
> What does the word "variable" mean. Think BASIC variables. You can set
> them, you can reset them, you can delete them, you can change them.  ...
> because they are variable.

>
> Python has names bound to objects... some of which you may not change.
> Once the name is bound to an object you may bind it to another object,
> but you may not change it, nor may you change the object it is bound to
> if the object is immutable.

I quite like the definition I found on Wikipedia: "a symbolic name 
associated with a value and whose associated value may be changed."  The 
word "change" here is ambiguous: it could mean mutating an existing 
value, or rebinding to another value.  While I can't mutate immutable 
values, I can always rebind a Python name to another value.

Python cannot do "pass variable by reference", but not because it lacks 
variables.  What it lacks is the ability to refer to a variable.  Names 
cannot be referred to, so there is no way to refer to a variable.  This 
is definitely different than C.

You are right about the comparison to BASIC: BASIC's variables can 
always be mutated.  Python's variables cannot always be, because some of 
them have immutable values (or happen to at the moment, they can always 
be rebound!)

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

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

#70990

On Wed, May 7, 2014 at 7:00 AM, Mark H Harris <harrismh777@gmail.com> wrote:
> What does the word "variable" mean. Think BASIC variables. You can set them,
> you can reset them, you can delete them, you can change them.  ... because
> they are variable.
>
> Python has names bound to objects... some of which you may not change. Once
> the name is bound to an object you may bind it to another object, but you
> may not change it, nor may you change the object it is bound to if the
> object is immutable.

Is this code mutating or rebinding?

x = 1.1
y = 2.2
x = x + y

What language did I write that in? Is there really a fundamental
difference between languages in which that is equally valid syntax and
does exactly the same thing? Apart from the fact that BASIC defaults
to single-precision float (in the absence of a hash suffix), Python
uses double-precision, and REXX uses decimal strings, this sequence
will work identically in all of them. Does BASIC have variables?
Presumably, since you can pass them by reference. Does REXX? You can't
pass by reference (all you can do is EXPOSE, which is more like
scoping rules, only it isn't); a C function can fiddle with any named
variable in its caller's scope, so a common way to "return" multiple
values is to pass the name of a stem (which isn't an array, and isn't
a dict/mapping, and isn't really an object at all) into which the
results will be placed. Python has objects and names, and changes
which object a name is bound to.

The mechanics differ, but fundamentally, x started out as 1.1 and
ended up as 3.3. That means x varied in value, and is thus a variable.
The differences are relatively insignificant.

ChrisA

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

#71002

On Wednesday, May 7, 2014 5:16:16 AM UTC+5:30, Chris Angelico wrote:
> On Wed, May 7, 2014 at 7:00 AM, Mark H Harris wrote:

> Is this code mutating or rebinding?

> x = 1.1
> y = 2.2
> x = x + y


Heh! Neat example!


> What language did I write that in? Is there really a fundamental
> difference between languages in which that is equally valid syntax and
> does exactly the same thing? Apart from the fact that BASIC defaults
> to single-precision float (in the absence of a hash suffix), Python
> uses double-precision, and REXX uses decimal strings, this sequence
> will work identically in all of them. Does BASIC have variables?
> Presumably, since you can pass them by reference. Does REXX? You can't
> pass by reference (all you can do is EXPOSE, which is more like
> scoping rules, only it isn't); a C function can fiddle with any named
> variable in its caller's scope, so a common way to "return" multiple
> values is to pass the name of a stem (which isn't an array, and isn't
> a dict/mapping, and isn't really an object at all) into which the
> results will be placed. Python has objects and names, and changes
> which object a name is bound to.

> The mechanics differ, but fundamentally, x started out as 1.1 and
> ended up as 3.3. That means x varied in value, and is thus a variable.
> The differences are relatively insignificant.

Wrong conclusion!

These 3 lines look the same and amount to much the same in python and C.

But as the example widens to something beyond 3 lines, the difference
will become more and more significant

OTOH...

As for meaning of the word 'variable,' the way mathematicians use it
seems to date to the 16th century:
http://en.wikipedia.org/wiki/Variable_%28mathematics%29#Genesis_and_evolution_of_the_concept

That is, its closer to the binding notion of python than the imperative notion
of C like languages.

However if we go further back, the book by Al-Khwarizmi is about
al-Jabr
ie the name of the guy who invented algebra is used for 'algorithm'!!

I find this ironic, given this current discussion:
- algorithm corresponds to the mutating notion
- algebra corresponds to the non-mutating notion

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

#71004

On Wed, May 7, 2014 at 12:18 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> Wrong conclusion!
>
> These 3 lines look the same and amount to much the same in python and C.
>
> But as the example widens to something beyond 3 lines, the difference
> will become more and more significant

Python, C, REXX, BASIC, and pretty much anything else with a broadly
imperative style.

The thing is, though, the difference between one language's variable
semantics and another's is similar to, as Ned said, the difference
between one language's integer semantics and another's. What happens
in C when you do this?

x = 1 << 31;
x += x;

The only possible answer is "it depends", as you can't know how big an
int is, but certainly it's of finite size. In Python, the equivalent
is guaranteed to put 2**32 into x, because integers store arbitrary
precision. That's a pretty important difference, yet we're happy to
call both "integer". A Python list is very different from a LISP list.
A Python array is very different from a Pike array. A Python function
is very different from a mathematical function. Why do we object to
the difference in "variable" but not the others?

Yes, there are differences. That's why we have different languages;
you can't do a minimalist transformation of source code and expect
exactly identical semantics. But we start with familiar names that
will give people some idea of what's going on.

ChrisA

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

#71005

On Wednesday, May 7, 2014 8:09:34 AM UTC+5:30, Chris Angelico wrote:
> On Wed, May 7, 2014 at 12:18 PM, Rustom Mody wrote:
> > Wrong conclusion!
> > These 3 lines look the same and amount to much the same in python and C.
> > But as the example widens to something beyond 3 lines, the difference
> > will become more and more significant

> Python, C, REXX, BASIC, and pretty much anything else with a broadly
> imperative style.

> The thing is, though, the difference between one language's variable
> semantics and another's is similar to, as Ned said, the difference
> between one language's integer semantics and another's. What happens
> in C when you do this?

> x = 1 << 31;
> x += x;

> The only possible answer is "it depends", as you can't know how big an
> int is, but certainly it's of finite size. In Python, the equivalent
> is guaranteed to put 2**32 into x, because integers store arbitrary
> precision. That's a pretty important difference, yet we're happy to
> call both "integer". A Python list is very different from a LISP list.
> A Python array is very different from a Pike array. A Python function
> is very different from a mathematical function. Why do we object to
> the difference in "variable" but not the others?

> Yes, there are differences. That's why we have different languages;
> you can't do a minimalist transformation of source code and expect
> exactly identical semantics. But we start with familiar names that
> will give people some idea of what's going on.


The number of possible concepts is infinite

The number of words is finite (even assuming unicode!!)

IOW A combinatorial problem...

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

#71006

On Tue, 06 May 2014 19:54:28 -0700, Rustom Mody wrote:

> The number of possible concepts is infinite
> 
> The number of words is finite (even assuming unicode!!)

Not true. If you allow longer and longer words, with no upper limit, the 
number of words is also infinite.

If you allow compound words (joined by spaces or hyphens), with no limit 
on the number of parts, the number of words is also infinite.

> IOW A combinatorial problem...

Not really. The problem is actually a compression problem, not a 
combinatorial problem. We have no difficulty in coming up with a 
(possibly very long) word for the concepts:

    C uses "32-bit-twos-complement-signed-integers"; 
    Python uses "twos-complement-signed-big-integer-objects"

but since programmers are lazy, we like short names for things, and the 
more frequently we use something, the shorter we like it. Hence we apply 
lossy compression to the concepts to get short names:

    C uses ints;
    Python uses ints

and the distinction between the two is lost.


-- 
Steven

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

#71042

On 5/6/14 6:46 PM, Chris Angelico wrote:

>  Is there really a fundamental
> difference between languages in which that is equally valid syntax and
> does exactly the same thing?

No. And from that standpoint, python has variables. I know, because I 
thought about python's 'variables' as variables for quite sometime 
before I learned about the 'beautiful heart of python'.  AND I used them 
as variables too, ignorantly of course.

And we must never forget that CPython's underpinnings, uhm C, uses 
variables, C ones...  (never mind)

Here is the rub. What happens when a newbie (me, some some years ago) 
gets a strange 'surprise' when trying to use python's variables:

Given that A is bound to 3.5, and B is also bound to another object 3.5:

A == B
True

A is B
False

... and now they want to know why if A == 3.5 and B == 3.5 does (A is B) 
come up False?

This is just one of a dozen 'different' kinds of examples. And the 
answer is the same, Python does not have variables, Python has names 
bound to objects.

The cleanest clearest explanation of Python's (name-->object) model is 
'the beautiful heart of python' in Mark Summerfield's Programming Python 
3.

I think we should STOP saying that python does not have variables (like 
that horse hasn't been beaten before, to death) but instead explain 
Python's beautiful heart. uhm,  "What you have been using in ignorance 
as a simple variable is, uhm, a 'name' bound to an object... and these 
are its strange properties:
    ... enumerated...


marcus

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

#71055

Mark H Harris <harrismh777@gmail.com>:

> A == B
> True
>
> A is B
> False
>
> [...]
>
> This is just one of a dozen 'different' kinds of examples. And the
> answer is the same, Python does not have variables, Python has names
> bound to objects.

That is a different topic and isn't related to variables at all.
Instead, you are talking about object identity:

  >>> 2 * 3000 == 6000
  True
  >>> 2 * 3000 is 6000
  False
  >>> "abc"[:1] == "a"
  True
  >>> "abc"[:1] is "a"
  False

But hey, we can open another thread for whether Python has values or
objects!


Marko

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

#71064 — Values and objects [was Re: Pass variable by reference]

On Thu, 08 May 2014 00:22:55 +0300, Marko Rauhamaa wrote:

> But hey, we can open another thread for whether Python has values or
> objects!

In Python, all values *are* objects. It isn't a matter of choosing one or 
the other. The value 1 is an object, not a native (low-level, unboxed) 32 
or 64 bit int.

Unlike C# or Java, there is no direct language facility to box native 
values into objects or unbox objects to native values.

But note that Python objects can encompass machine values. For example, 
the array type is implemented as an array of native values, transparently 
packing and unpacking the values as needed.




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

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

#71197 — Re: Values and objects [was Re: Pass variable by reference]

On 5/7/14 8:08 PM, Steven D'Aprano wrote:
> In Python, all values *are* objects. It isn't a matter of choosing one or
> the other. The value 1 is an object, not a native (low-level, unboxed) 32
> or 64 bit int.
>
> Unlike C# or Java, there is no direct language facility to box native
> values into objects or unbox objects to native values.
>
     Yes.  In the context of the rest of this discussion, this one point 
is just one of the many reasons why it is not helpful to think of 
Python's {name: object} relationship as 'variable -- value'.

     Typically when I think about variables (particularly from the past, 
say Pascal, Basic, C, Fortran, Cobol &c) I am thinking about modeling 
memory is some way where the variable (some naming convention) is a 
value handle or value pointer of some chunk of memory (by type | length) 
---  where I am creating a 'box' into which I may place something 
(usually some native type).

     When I think of Python's 'variables' (and I don't believe Python 
has variables) I am now thinking of a naming convention (for handling 
objects) where I am not the least interested in modeling memory for 
native types. I am instead interested in modeling the real world (or 
subset) with object abstractions. I am no longer interested in creating 
a 'box' into which I may place some type. I don't need variables any 
longer for that purpose.  What I want is some very efficient naming 
convention whereby I can handle the objects I am constructing (for 
whatever abstract purpose).

     If a programmer new to Python thinks in terms of 'variables' from C 
or Pascal, or Fortran or Basic, they will run into surprises when it 
comes to handling the {name: object} idea in Python. In fact, most of 
the time this debate comes up it is precisely that the new user is 
finding Python's 'variables' aren't behaving correctly or finding that 
they are not able to 'do' what they used to do (say) with C's variables.

     It really comes down to the definition of 'variable' and whether 
the language in question is modeling memory, or modeling object 
abstractions.

marcus

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

#71200 — Re: Values and objects

Mark H Harris <harrismh777@gmail.com>:

>     Typically when I think about variables (particularly from the
> past, say Pascal, Basic, C, Fortran, Cobol &c) I am thinking about
> modeling memory is some way where the variable (some naming
> convention) is a value handle or value pointer of some chunk of memory
> (by type | length) --- where I am creating a 'box' into which I may
> place something (usually some native type).
>
>     When I think of Python's 'variables' (and I don't believe Python
> has variables) I am now thinking of a naming convention (for handling
> objects) where I am not the least interested in modeling memory for
> native types. I am instead interested in modeling the real world (or
> subset) with object abstractions. I am no longer interested in
> creating a 'box' into which I may place some type. I don't need
> variables any longer for that purpose. What I want is some very
> efficient naming convention whereby I can handle the objects I am
> constructing (for whatever abstract purpose).

Right, Python's variables aren't like variables in C. Rather, Python's
variables are like CPU registers. They cannot hold typed or structured
objects and you can't pass references to them.


Marko

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

#71205 — Re: Values and objects

Marko Rauhamaa <marko@pacujo.net> writes:

> Right, Python's variables aren't like variables in C. Rather, Python's
> variables are like CPU registers.

What is the salient difference between those two? I don't see the point
of the distinction.

Why have you chosen an analogy – CPU registers – that still uses the
misleading “copies in containers” model, rather than the “sticky-notes
on objects” model? The latter more accurately describes Python's
references.

> They cannot hold typed or structured objects

This is quite false. Every object in Python is typed and structured, and
to the extent that Python has “variables”, they always refer to a typed
and structured object.

-- 
 \     “Do unto others twenty-five percent better than you expect them |
  `\      to do unto you. (The twenty-five percent is [to correct] for |
_o__)                            error.)” —Linus Pauling's Golden Rule |
Ben Finney

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

#71208 — Re: Values and objects

On Sat, 10 May 2014 01:34:58 +0300, Marko Rauhamaa wrote:

> Right, Python's variables aren't like variables in C. Rather, Python's
> variables are like CPU registers. They cannot hold typed or structured
> objects 

Surely you cannot mean that? It is *trivially simple* to disprove that 
statement:

py> x = [1, 2, 3]  # A structured object
py> type(x)  # that has a type
<class 'list'>


> and you can't pass references to them.

That at least you have got right.



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

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

#71214 — Re: Values and objects

On Saturday, May 10, 2014 6:31:49 AM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 10 May 2014 01:34:58 +0300, Marko Rauhamaa wrote:

> 
> > and you can't pass references to them.
> 
> 
> That at least you have got right.
> 

And that's Marko's main point

> 
> 
> > Right, Python's variables aren't like variables in C. Rather, Python's
> > variables are like CPU registers. They cannot hold typed or structured
> > objects 
> 
> 
> Surely you cannot mean that? It is *trivially simple* to disprove that 
> statement:
> 
> 
> py> x = [1, 2, 3]  # A structured object
> py> type(x)  # that has a type
> <class 'list'>

You missed the 'hold'

For me, Marko's comment that variables in python are not first-class
whereas in C they are is for me the most important distinction Ive seen
(in a long time of seeing these discussions).

In C a pointer is a 'pre-variable' in this sense:
int i, *p;
p = &i

after this
i and *p are completely interchangeable

However p can also refer to -- (contain?hold?) depends on which side of this debate you are -- an element of an array or struct
p = &some_array[some_index]
p = &some_struct.some_field

And all the way to anonymity with
p = malloc(sizeof(*p))

This is what makes p a kind of meta-variable:
- it can 'contain' other variables
- it can contain variale-ish things like array elements
- it can contain new variables on the fly via malloc

These possibilities dont exist in python

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

#71217 — Re: Values and objects

On Sat, May 10, 2014 at 12:19 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> For me, Marko's comment that variables in python are not first-class
> whereas in C they are is for me the most important distinction Ive seen
> (in a long time of seeing these discussions).
>

https://en.wikipedia.org/wiki/First-class_citizen

For variables in C to be considered first-class, they must, by most
definitions, be able to be passed around as parameters and return
values. Some definitions also require that they be able to be
constructed at run-time. How do C variables shape up?

1) Passing them as parameters. You can pass a pointer to a variable,
which is effectively the same as passing a variable to a function. The
callee can mutate your variable through the pointer.
2) Returning them. This is a lot more dodgy, owing to the
dangling-pointer issue, but as long as you accept that the reference
to a variable doesn't ensure its continued life, I suppose this might
be acceptable. Maybe. But it's pushing it.
3) Constructing at run-time. Really REALLY pushing it. You can malloc
and call that a "variable", but it's not a variable any more, it's
just a patch of memory. In fact, all this proves is that variables
represent patches of memory, and patches of memory are first-class.

Not liking the results here. You might just as well define that all
Python variables must be backed by a dictionary (it's just as true as
"all C variables must be backed by memory") and then define the
first-class-variable as a combination of a dict and a key.

ChrisA

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

#71219 — Re: Values and objects

On Saturday, May 10, 2014 8:03:28 AM UTC+5:30, Chris Angelico wrote:
> 
> 2) Returning them. This is a lot more dodgy, owing to the
> dangling-pointer issue, but as long as you accept that the reference
> to a variable doesn't ensure its continued life, I suppose this might
> be acceptable. Maybe. But it's pushing it.
> 
> 3) Constructing at run-time. Really REALLY pushing it. You can malloc
> and call that a "variable", but it's not a variable any more, it's
> just a patch of memory. In fact, all this proves is that variables
> represent patches of memory, and patches of memory are first-class.
> 

Not sure what the 'just' is emphasizing/delimiting. Consider:
int i;
int *pi;
char *pc;

pi = &i;
pc = pi;

If your 'just' were just (excuse pun!) then *pi would be identical to *pc -- 
just the same patch of memory

> 
> Not liking the results here. You might just as well define that all
> Python variables must be backed by a dictionary (it's just as true as
> "all C variables must be backed by memory") and then define the
> first-class-variable as a combination of a dict and a key.

Yes this is the rub.
C pointers are first-class but half-assed due to dangling pointers --
(Function returning address of an automatic variale etc)

Likewise python's name-spaces go almost all the way to first-classing variables 
but not quite as Marko discovered when locals() looks like a dict, waddles like 
a dict but does not quack like a dict.

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

#71221 — Re: Values and objects

On 5/9/14 10:05 PM, Rustom Mody wrote:
> Likewise python's name-spaces go almost all the way to first-classing variables
> but not quite as Marko discovered when locals() looks like a dict, waddles like
> a dict but does not quack like a dict.
>
  QOTWeekEnd

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

#71224 — Re: Values and objects

On Sat, 10 May 2014 12:33:28 +1000, Chris Angelico wrote:

> On Sat, May 10, 2014 at 12:19 PM, Rustom Mody <rustompmody@gmail.com>
> wrote:
>> For me, Marko's comment that variables in python are not first-class
>> whereas in C they are is for me the most important distinction Ive seen
>> (in a long time of seeing these discussions).
>>
>>
> https://en.wikipedia.org/wiki/First-class_citizen
> 
> For variables in C to be considered first-class, they must, by most
> definitions, be able to be passed around as parameters and return
> values. Some definitions also require that they be able to be
> constructed at run-time. How do C variables shape up?
> 
> 1) Passing them as parameters. You can pass a pointer to a variable,
> which is effectively the same as passing a variable to a function. 

No it is not. It is nothing like passing a variable to a function. You 
are passing a pointer, which is itself a value. True, it is a value which 
you, the author, gives meaning as a pointer to a variable, but that need 
not be the case. It might be a pointer to a part of an array, or a 
record, or to some random address in memory, or a dangling pointer. C 
allows you to perform arithmetic on pointers, which means you can 
construct pointers to nothing in particular.

In C, pointers are first-class values, since you can:

    - construct pointers at runtime;
    - pass them to functions;
    - return them from functions;
    - assign them to variables;
    - stuff them in structs or arrays.

But variables are not. You cannot create new variables, nor treat 
variables themselves as function arguments, or return them from 
functions. The closest you can do is *manually* use a pointer to a 
variable to simulate the same effect, but this is both too much and too 
little:

    - too much, because you aren't limited to passing pointers 
      to a variable, you can pass pointers to anything you 
      like, or nothing at all;

    - too little, because you are responsible for managing the 
      pointers, instead of having the compiler do so.

In Pascal, like C, you can't create new variables, or return them from 
functions, or embed them in records. But unlike C, you can pass them to 
functions, using a var parameter to use pass-by-reference. Algol is 
similar, except pass-by-name instead. I guess that makes Pascal variables 
second-and-a-half class values. Given:

procedure foo(var inside: integer);
  begin
    {...}
  end;

begin
  foo(outside);
end.

the global variable "outside" is passed to foo where it effectively 
becomes the local variable "inside". Notice that we don't manually have 
to concern ourselves with pointers, in fact whether Pascal uses pointers 
to implement this or not is entirely invisible to the coder using the 
feature. It could be using magic fairy dust for all we know. We simply 
write the most direct, natural code we possibly can:

foo(outside);

and the compiler does whatever magic is needed to ensure the variable 
outside, rather than the value of outside, is passed to the procedure foo.

There is nothing like that in C. You can only manually simulate it by 
passing a pointer to a variable, not by passing the variable itself. To 
argue that C pointers are "pass by reference" is like arguing that C has 
a garbage collector, because you can write one yourself.


> The
> callee can mutate your variable through the pointer. 2) Returning them.
> This is a lot more dodgy, owing to the dangling-pointer issue, but as
> long as you accept that the reference to a variable doesn't ensure its
> continued life, I suppose this might be acceptable. Maybe. But it's
> pushing it. 3) Constructing at run-time. Really REALLY pushing it. You
> can malloc and call that a "variable", but it's not a variable any more,
> it's just a patch of memory. In fact, all this proves is that variables
> represent patches of memory, and patches of memory are first-class.

It proves that pointers are first class (well, duh!). The C compiler 
makes very little effort to ensure that pointers actually point to 
anything. Nor can you create patches of memory ("I'll like an extra 
couple of terrabytes please"), or return them from functions, or insert 
them in arrays.

Rather than *creating* patches of memory, malloc merely allocates it from 
pre-existing memory.


> Not liking the results here. You might just as well define that all
> Python variables must be backed by a dictionary (it's just as true as
> "all C variables must be backed by memory") and then define the
> first-class-variable as a combination of a dict and a key.

Python variables aren't first-class either, but in fact we can get a bit 
closer to first-class than either C or Pascal.

Creating new variables is trivial. Since they don't need to be declared, 
you create a new variable just by assigning to it:

try:
    spam
except NameError:
    spam = 23


There are at least two other ways:

globals()['spam'] = 23
exec('spam = 23')


You can also delete variables:

del spam


Now this really shows first-class-ness. We don't have to give the name of 
the variable as a string, as in del("spam"), we just use the variable's 
name.

But there's no way to pass variables to functions, embed them in lists, 
etc. The closest we can do is pass a string, the name of the variable, 
and a namespace:

foo('spam', namespace)

To be truly first class, we ought to be able to write something like this:

x = 23
alist = [1, 2, x]
alist[2] = 42
assert x == 42


but we cannot.


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

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web