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

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

Can Python function return multiple data?

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

Contents

  Can Python function return multiple data? fl <rxjwg98@gmail.com> - 2015-06-02 14:27 -0700
    Re: Can Python function return multiple data? Joel Goldstick <joel.goldstick@gmail.com> - 2015-06-02 17:35 -0400
    Re: Can Python function return multiple data? sohcahtoa82@gmail.com - 2015-06-02 14:40 -0700
    Re: Can Python function return multiple data? John Gordon <gordon@panix.com> - 2015-06-02 21:40 +0000
    Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-03 09:56 +1000
      Re: Can Python function return multiple data? Thomas Rachel <nutznetz-0c1b6768-bfa9-48d5-a470-7603bd3aa915@spamschutz.glglgl.de> - 2015-06-03 15:56 +0200
        Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-04 07:35 +1000
        Re: Can Python function return multiple data? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-03 22:56 +0100
          Re: Can Python function return multiple data? sohcahtoa82@gmail.com - 2015-06-03 15:28 -0700
            Re: Can Python function return multiple data? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-06-03 21:30 -0400
            Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-04 11:52 +1000
            Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-04 23:47 +1000
              Re: Can Python function return multiple data? Marko Rauhamaa <marko@pacujo.net> - 2015-06-04 17:25 +0300
                Re: Can Python function return multiple data? Grant Edwards <invalid@invalid.invalid> - 2015-06-04 14:37 +0000
                  Re: Can Python function return multiple data? Marko Rauhamaa <marko@pacujo.net> - 2015-06-04 18:04 +0300
                    Re: Can Python function return multiple data? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-06-04 19:51 -0400
                  Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 03:11 +1000
                    Re: Can Python function return multiple data? Marko Rauhamaa <marko@pacujo.net> - 2015-06-04 20:30 +0300
                      Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 08:37 +1000
                    Re: Can Python function return multiple data? random832@fastmail.us - 2015-06-04 13:30 -0400
                      Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 08:31 +1000
                    Re: Can Python function return multiple data? Grant Edwards <invalid@invalid.invalid> - 2015-06-04 18:38 +0000
                      Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 08:52 +1000
                        Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-05 09:04 +1000
                        Re: Can Python function return multiple data? Grant Edwards <invalid@invalid.invalid> - 2015-06-05 02:02 +0000
                          Re: Can Python function return multiple data? Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-05 09:11 +0200
                            Re: Can Python function return multiple data? Marko Rauhamaa <marko@pacujo.net> - 2015-06-05 12:27 +0300
                              Re: Can Python function return multiple data? Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-05 14:04 +0200
                    Re: Can Python function return multiple data? BartC <bc@freeuk.com> - 2015-06-04 21:52 +0100
                      Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 09:13 +1000
                        Re: Can Python function return multiple data? BartC <bc@freeuk.com> - 2015-06-05 01:16 +0100
                          Re: Can Python function return multiple data? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-05 02:40 +0100
                            Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 11:48 +1000
                              Re: Can Python function return multiple data? BartC <bc@freeuk.com> - 2015-06-05 11:06 +0100
                    Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-05 07:44 +1000
                  Re: Can Python function return multiple data? BartC <bc@freeuk.com> - 2015-06-05 10:51 +0100
              Re: Can Python function return multiple data? ElChino <elchino@cnn.cn> - 2015-06-04 17:37 +0200
                Re: Can Python function return multiple data? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2015-06-04 19:57 -0400
              Re: Can Python function return multiple data? random832@fastmail.us - 2015-06-04 13:26 -0400
                Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 08:16 +1000
                  Re: Can Python function return multiple data? random832@fastmail.us - 2015-06-04 18:59 -0400
                    Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 12:37 +1000
                      Re: Can Python function return multiple data? Rustom Mody <rustompmody@gmail.com> - 2015-06-04 20:16 -0700
                        Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 21:06 +1000
                          Re: Can Python function return multiple data? Rustom Mody <rustompmody@gmail.com> - 2015-06-05 06:29 -0700
                            Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-06 07:59 +1000
                              Re: Can Python function return multiple data? Rustom Mody <rustompmody@gmail.com> - 2015-06-05 20:20 -0700
                                Re: Can Python function return multiple data? random832@fastmail.us - 2015-06-05 23:28 -0400
                                  Re: Can Python function return multiple data? Rustom Mody <rustompmody@gmail.com> - 2015-06-05 22:28 -0700
                                    Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-06 15:43 +1000
                                      Lawful != Mutable (was Can Python function return multiple data?) Rustom Mody <rustompmody@gmail.com> - 2015-06-07 08:49 -0700
                                        Re: Lawful != Mutable (was Can Python function return multiple data?) Chris Angelico <rosuav@gmail.com> - 2015-06-08 02:07 +1000
                                        Re: Lawful != Mutable (was Can Python function return multiple data?) Rustom Mody <rustompmody@gmail.com> - 2015-06-07 09:20 -0700
                                          Re: Lawful != Mutable (was Can Python function return multiple data?) Chris Angelico <rosuav@gmail.com> - 2015-06-08 02:34 +1000
                                            Re: Lawful != Mutable (was Can Python function return multiple data?) Rustom Mody <rustompmody@gmail.com> - 2015-06-20 18:59 -0700
                                              Re: Lawful != Mutable (was Can Python function return multiple data?) Chris Angelico <rosuav@gmail.com> - 2015-06-21 12:32 +1000
                                                Re: Lawful != Mutable (was Can Python function return multiple data?) Rustom Mody <rustompmody@gmail.com> - 2015-06-20 19:50 -0700
                                                  Re: Lawful != Mutable (was Can Python function return multiple data?) Laura Creighton <lac@openend.se> - 2015-06-21 11:14 +0200
                                                  Re: Lawful != Mutable (was Can Python function return multiple data?) Ron Adam <ron3200@gmail.com> - 2015-06-21 08:55 -0400
                                    Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-07 15:51 +1000
                                Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-06 13:49 +1000
                                Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-06 14:50 +1000
                                  Re: Can Python function return multiple data? Chris Angelico <rosuav@gmail.com> - 2015-06-06 15:29 +1000
                                  Re: Can Python function return multiple data? Rustom Mody <rustompmody@gmail.com> - 2015-06-05 22:32 -0700
                                    Re: Can Python function return multiple data? Dave Farrance <df@see.replyto.invalid> - 2015-06-06 07:52 +0100
                                    Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-07 15:53 +1000
                      Re: Can Python function return multiple data? random832@fastmail.us - 2015-06-05 08:21 -0400
                        Re: Can Python function return multiple data? Marko Rauhamaa <marko@pacujo.net> - 2015-06-05 16:37 +0300
                  Re: Can Python function return multiple data? Rustom Mody <rustompmody@gmail.com> - 2015-06-04 19:07 -0700
              Re: Can Python function return multiple data? Michael Torrie <torriem@gmail.com> - 2015-06-04 11:36 -0600
              Re: Can Python function return multiple data? random832@fastmail.us - 2015-06-04 13:51 -0400
              Re: Can Python function return multiple data? Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-04 20:17 +0200
                Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-05 08:45 +1000
                  Re: Can Python function return multiple data? Alain Ketterlin <alain@universite-de-strasbourg.fr.invalid> - 2015-06-05 08:59 +0200
            Re: Can Python function return multiple data? Michael Torrie <torriem@gmail.com> - 2015-06-04 08:16 -0600
          Re: Can Python function return multiple data? sohcahtoa82@gmail.com - 2015-06-05 11:55 -0700
        Re: Can Python function return multiple data? random832@fastmail.us - 2015-06-04 01:01 -0400
        Re: Can Python function return multiple data? Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-04 12:34 -0600
        Re: Can Python function return multiple data? Mark Lawrence <breamoreboy@yahoo.co.uk> - 2015-06-04 20:16 +0100
    Re: Can Python function return multiple data? Serhiy Storchaka <storchaka@gmail.com> - 2015-06-04 09:56 +0300
    Re: Can Python function return multiple data? fl <rxjwg98@gmail.com> - 2015-06-06 10:57 -0700
      Re: Can Python function return multiple data? Rustom Mody <rustompmody@gmail.com> - 2015-06-06 21:35 -0700
      Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-07 15:47 +1000
    Re: Can Python function return multiple data? Steven D'Aprano <steve@pearwood.info> - 2015-06-07 15:33 +1000

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

#92100

On Thu, Jun 4, 2015, at 18:16, Steven D'Aprano wrote:
> Remember, you've tried to claim that it is not invisible or unknown, so
> you
> must be able to see and know that value. So what is the value?

It doesn't have to have a string representation to exist. But if you
really want one?

>>> object.__repr__(23)
'<int object at 0x10024af00>'

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

#92118

On Fri, 5 Jun 2015 08:59 am, random832@fastmail.us wrote:

> On Thu, Jun 4, 2015, at 18:16, Steven D'Aprano wrote:
>> Remember, you've tried to claim that it is not invisible or unknown, so
>> you
>> must be able to see and know that value. So what is the value?
> 
> It doesn't have to have a string representation to exist. But if you
> really want one?
> 
>>>> object.__repr__(23)
> '<int object at 0x10024af00>'

That's not a reference to the value. That's a string that describes the
object. If it returned

"twenty-three"

would you claim that the string "twenty three" is the value of x?

I think there is a simple, obvious, common-sense answer here:

* given `x = 23`, the value of x is 23;

* given `x = [1, 2]`, the value of x is the given list [1, 2];

* given `x = "Hello World", the value of x is the string "Hello World";

* given `x = object()`, the value of x is the given instance of type object.

That's so simple and obviously correct. Compare to:

* given `x = 23`, the value of x is not actually 23, but some invisible
reference to 23;

* given `x = [1, 2]`, the value of x is not actually [1, 2], but some
invisible reference to [1, 2]; 

etc. I'm sure you can extrapolate to the other examples.

The *only* reason for making this claim is to rationalise the belief that
passing x to a function is pass by value. Since the list [1, 2] is
obviously not copied, it becomes necessary to find something, anything,
which *is* copied, and identify that as "the value of x". Is there any
other context where you would want to say that the value of x isn't [1, 2]?


-- 
Steven

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

#92120

On Friday, June 5, 2015 at 8:07:41 AM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 5 Jun 2015 08:59 am, random832 wrote:
> 
> > On Thu, Jun 4, 2015, at 18:16, Steven D'Aprano wrote:
> >> Remember, you've tried to claim that it is not invisible or unknown, so
> >> you
> >> must be able to see and know that value. So what is the value?
> > 
> > It doesn't have to have a string representation to exist. But if you
> > really want one?
> > 
> >>>> object.__repr__(23)
> > '<int object at 0x10024af00>'
> 
> That's not a reference to the value. That's a string that describes the
> object. If it returned
> 
> "twenty-three"
> 
> would you claim that the string "twenty three" is the value of x?
> 
> I think there is a simple, obvious, common-sense answer here:
> 
> * given `x = 23`, the value of x is 23;
> 
> * given `x = [1, 2]`, the value of x is the given list [1, 2];
> 
> * given `x = "Hello World", the value of x is the string "Hello World";
> 
> * given `x = object()`, the value of x is the given instance of type object.
> 
> That's so simple and obviously correct. Compare to:
> 
> * given `x = 23`, the value of x is not actually 23, but some invisible
> reference to 23;
> 
> * given `x = [1, 2]`, the value of x is not actually [1, 2], but some
> invisible reference to [1, 2]; 
> 
> etc. I'm sure you can extrapolate to the other examples.
> 
> The *only* reason for making this claim is to rationalise the belief that
> passing x to a function is pass by value. Since the list [1, 2] is
> obviously not copied, it becomes necessary to find something, anything,
> which *is* copied, and identify that as "the value of x". Is there any
> other context where you would want to say that the value of x isn't [1, 2]?
> 

Sounds simple...
Until you realize that what the *is* is emphasizing [your emphasis] is not all
that clear.

Consider the C canonical linked-list example (of some type T):

struct node
{
   T elem;
   struct node *next;
};

Is the list in C to be identified with 'struct node'?

If you will see the usage pattern you would find that in most cases the
usage is for some p of type struct node*
To make it more explicit there are TWO mutually recursive types:

typedef struct node *nodeptr;
struct node
{
  T elem;
  nodeptr next;
}; 

And now if we ask which of node and nodeptr should we identify with the
list type, the answer is not quite clear.
- In all cases of usage we would find we need to use nodeptr
- Except for  "newp = (nodeptr)malloc(sizeof(struct node))"
- However nodeptr has no meaning other than referring (pointing) to 
   something... What?

My conclusion: C does not support lists at all in a first class way.
The C programmer needs to visualize/imagine them in the nebulous gap between
node and nodeptr.

The same situation obtains here in python:

The abstract platonic immutable list is non-existent in python
Use no mutation and the pretence that the list [1,2] *is* the list [1,2] works.

Start using mutation and the ground starts wobbling.
The only way to stay steady (that I know) in this wobbly world is to hold to
two concepts:
1. The abstract platonic immutable type -- good to think with, supported by 
python in only a half-assed way

2. The 'maybe-reference-maybe-value' actual mess

And to keep dancing between these

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

#92134

On Fri, 5 Jun 2015 01:16 pm, Rustom Mody wrote:

> Consider the C canonical linked-list example (of some type T):
> 
> struct node
> {
>    T elem;
>    struct node *next;
> };
> 
> Is the list in C to be identified with 'struct node'?

Lists in C are not first class values. There is no one thing which can be
identified as the entire list, because the C language gives you the tools
to break any "list" abstraction.

In C, there is no single thing which refers to the entire list, *except by
convention*. There is *at least* one node which represents the head of the
list, followed by other nodes:


node->node->node->node->node
             ^
             |
node->node---

(ASCII diagram best viewed in a monospaced font)

But there is nothing which encapsulates the entire list, and indeed the
concept "the list" is ill-defined, as in the above diagram. We can use the
convention that "the list" means "the sequence of nodes, starting from this
node, which we assume is the head of the list", but that's about it. You
might even find some clever way of tracking which node is the head and
which are not in your own code, but C won't do it for you. You might refuse
to create such double-headed lists as shown above, but C won't enforce that
rule for you, you have to enforce it yourself. In short, C doesn't have the
concept of lists as first class values and so anything you do with it is
entirely in your own hands.


[...]
> My conclusion: C does not support lists at all in a first class way.

Exactly!


> The same situation obtains here in python:

Not so.

In Python, lists *are* first class values, and the Python language manages
all the book-keeping for you to ensure that when you look at a list, it is
the whole list, regardless of implementation. From your Python code, you
don't have to do any book-keeping, you don't have to be careful not to
create double-headed lists, or accidentally start in the middle of the
list, since Python simply doesn't allow you to do so from pure Python code,
unlike C. So in Python, we can always consider the list as a encapsulated
whole, regardless of how it is implemented.

(CPython documents that lists are actually arrays of pointers to objects,
but that's an implementation detail we can ignore.)


> The abstract platonic immutable list is non-existent in python

Just pretend that "immutable list" is spelled "tuple".


> Use no mutation and the pretence that the list [1,2] *is* the list [1,2]
> works.
> 
> Start using mutation and the ground starts wobbling.

Mutation is irrelevant here. Some objects are immutable, others are mutable,
but the language semantics are the same for both.

In particular, Python provides as a language feature two ways to compare
objects for identity. Python makes no promises as to when it will re-use
immutable objects, but it does promise that you can always test for re-use
by using `is` or `id()`. So there's no "wobbly ground" here. You can
*always* tell if (supposedly) two objects are in fact the same object or
not, since `is` cannot be shadowed or monkey-patched.


> The only way to stay steady (that I know) in this wobbly world is to hold
> to two concepts:
> 1. The abstract platonic immutable type -- good to think with, supported
> by python in only a half-assed way
> 
> 2. The 'maybe-reference-maybe-value' actual mess
> 
> And to keep dancing between these

All the words are in English, but I have no idea what you are trying to say
here.


-- 
Steven

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

#92144

On Friday, June 5, 2015 at 4:36:35 PM UTC+5:30, Steven D'Aprano wrote:
> On Fri, 5 Jun 2015 01:16 pm, Rustom Mody wrote:
> > The abstract platonic immutable list is non-existent in python
> 
> Just pretend that "immutable list" is spelled "tuple".

Ok lets say I make no fuss about the need to 'pretend'.

And I try...

>>> a=[1,2,3]
>>> b=(a,a)
>>> a
[1, 2, 3]
>>> b
([1, 2, 3], [1, 2, 3])
>>> a.append(4)
>>> b
([1, 2, 3, 4], [1, 2, 3, 4])

> 
> 
> > Use no mutation and the pretence that the list [1,2] *is* the list [1,2]
> > works.
> > 
> > Start using mutation and the ground starts wobbling.
> 
> Mutation is irrelevant here. Some objects are immutable, others are mutable,
> but the language semantics are the same for both.
> 
> In particular, Python provides as a language feature two ways to compare
> objects for identity. Python makes no promises as to when it will re-use
> immutable objects, but it does promise that you can always test for re-use
> by using `is` or `id()`. So there's no "wobbly ground" here. You can
> *always* tell if (supposedly) two objects are in fact the same object or
> not, since `is` cannot be shadowed or monkey-patched.
> 
> 
> > The only way to stay steady (that I know) in this wobbly world is to hold
> > to two concepts:
> > 1. The abstract platonic immutable type -- good to think with, supported
> > by python in only a half-assed way
> > 
> > 2. The 'maybe-reference-maybe-value' actual mess
> > 
> > And to keep dancing between these
> 
> All the words are in English, but I have no idea what you are trying to say
> here.

It was an analogy.
C programmers use lists all right all the time.
However until they see something like python, they dont know that they never
REALLY saw lists. ie lists in python are more first-class than C.

Analogously immutable lists are more first-class than python lists.

Of course the language (we are conversing in) is itself very misleading.
We dont call a number an 'immutable' number. In
x = 3
x = x - 1
it is x that changes, not 3.

Whatever would/could it mean that 3 becomes 2?

If 3 becomes 2 does π become 2.142? Do circles look different?
Does the normal curve (with a π in the denominator) start wiggling?

What I am driving at is that immutable numbers are so deeply enshrined in our
culture that anything else is inconceivable.

Yet for lists one needs to spell out
immutable → tuple
mutable → list
This means that in our culture lists have not reached the first-class status 
that numbers have.  Python is just following the culture

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

#92163

On Fri, Jun 5, 2015 at 11:29 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Friday, June 5, 2015 at 4:36:35 PM UTC+5:30, Steven D'Aprano wrote:
>> On Fri, 5 Jun 2015 01:16 pm, Rustom Mody wrote:
>> > The abstract platonic immutable list is non-existent in python
>>
>> Just pretend that "immutable list" is spelled "tuple".
>
> Ok lets say I make no fuss about the need to 'pretend'.
>
> And I try...
>
>>>> a=[1,2,3]
>>>> b=(a,a)
>>>> a
> [1, 2, 3]
>>>> b
> ([1, 2, 3], [1, 2, 3])
>>>> a.append(4)
>>>> b
> ([1, 2, 3, 4], [1, 2, 3, 4])

Congrats! You just proved that an object can itself be immutable, but
can contain references to mutables. Ain't that awesome?

Did you have a point?

> It was an analogy.
> C programmers use lists all right all the time.
> However until they see something like python, they dont know that they never
> REALLY saw lists. ie lists in python are more first-class than C.

If you're talking about the things C programmers use all the time,
they're not linked lists, they're arrays - identified by base pointer
and element count. Linked lists are common in LISPy languages, but not
all that common in C, nor C-derived APIs. Most APIs designed for C
usage are either array-based or generator-based.

http://www.gnu.org/software/libc/manual/html_node/Scanning-Directory-Content.html
Array-based: scandir accepts a pointer-to-pointer, which it populates
with a pointer to freshly-allocated data, and it returns the number of
entries stashed there.

http://www.gnu.org/software/libc/manual/html_node/Opening-a-Directory.html
http://www.gnu.org/software/libc/manual/html_node/Reading_002fClosing-Directory.html
Generator-based: opendir returns a generator, readdir gives the next
result or NULL

http://www.gnu.org/software/libc/manual/html_node/Array-Sort-Function.html
Array-based: pass it a base pointer and a count (and an object size,
since it's completely generic), and it sorts the elements.

Your point is still broadly valid, though; these arrays are not
first-class objects. They do have their own little quirks; so long as
the original array isn't deallocated, you can efficiently work with
views by simply using a base pointer inside the original array and a
length that's shorter than the whole array. Very convenient if you
need it, but most certainly not first-class lists, and can cause
problems if you're not careful. Python lists truly are first-class
objects; "more first-class than C" in the sense that 1 is more true
than 0.

ChrisA

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

#92166

On Saturday, June 6, 2015 at 3:30:23 AM UTC+5:30, Chris Angelico wrote:
> On Fri, Jun 5, 2015 at 11:29 PM, Rustom Mody wrote:
> > On Friday, June 5, 2015 at 4:36:35 PM UTC+5:30, Steven D'Aprano wrote:
> >> On Fri, 5 Jun 2015 01:16 pm, Rustom Mody wrote:
> >> > The abstract platonic immutable list is non-existent in python
> >>
> >> Just pretend that "immutable list" is spelled "tuple".
> >
> > Ok lets say I make no fuss about the need to 'pretend'.
> >
> > And I try...
> >
> >>>> a=[1,2,3]
> >>>> b=(a,a)
> >>>> a
> > [1, 2, 3]
> >>>> b
> > ([1, 2, 3], [1, 2, 3])
> >>>> a.append(4)
> >>>> b
> > ([1, 2, 3, 4], [1, 2, 3, 4])
> 
> Congrats! You just proved that an object can itself be immutable, but
> can contain references to mutables. Ain't that awesome?
> 
> Did you have a point?

[Under assumption you are not being facetious...]
The word immutuable happens to have existed in English before python.
I also happen to have used it before I knew of python
The two meanings do not match
I am surprised
Is that surprising?

As a parallel here is Dijkstra making fun of AI-ers use of the word
'intelligent'
 http://www.cs.utexas.edu/users/EWD/transcriptions/EWD06xx/EWD618.html

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

#92167

On Fri, Jun 5, 2015, at 23:20, Rustom Mody wrote:
> The word immutuable happens to have existed in English before python.
> I also happen to have used it before I knew of python
> The two meanings do not match
> I am surprised
> Is that surprising?

They don't match only if you consider the objects a tuple references to
be part of the tuple.

You cannot change the reference. It will always point to the same list.

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

#92170

On Saturday, June 6, 2015 at 8:58:13 AM UTC+5:30, rand...@fastmail.us wrote:
> On Fri, Jun 5, 2015, at 23:20, Rustom Mody wrote:
> > The word immutuable happens to have existed in English before python.
> > I also happen to have used it before I knew of python
> > The two meanings do not match
> > I am surprised
> > Is that surprising?
> 
> They don't match only if you consider the objects a tuple references to
> be part of the tuple.
> 
> You cannot change the reference. It will always point to the same list.

You just repeated what Chris said, replacing 'immutable' with 'same'
There was a list: [1,2,3]
At some point that list is found to be(come) [1,2,3,4]
They dont look same to me.

IOW if immutable₂ is to have cognitive resonance with immutable₁ it needs to be
'deep-immutable' in analogy to deep-copy.

Anyways... All this is rather far from my original point
Python may or may not have genuine immutables and we may call skin-immutable 
as 'immutable'
We have muddled along thusly for the last 60 years and its called
'imperative programming'.

My point is that without a common conceptual basis there is neither
communication nor understanding.
That common base is usually called math/logic:
Your '1/2/3' matches mine
Your 'and/or/not' matches mine
They are immutable₁ therefore we can think and communicate with them

With [1,2,3] ([1,2],[1,2]) that is not the case
I regard that as unfortunate
[You are of course free to regard that as ok]

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

#92173

On Sat, Jun 6, 2015 at 3:28 PM, Rustom Mody <rustompmody@gmail.com> wrote:
> You just repeated what Chris said, replacing 'immutable' with 'same'
> There was a list: [1,2,3]
> At some point that list is found to be(come) [1,2,3,4]
> They dont look same to me.

"I'm going shopping, can you get me the shopping list please?"
*goes and fetches a piece of paper from the kitchen*
"Wait, this isn't the right list! This one has more things on it!"

The question of whether or not the thing fetched is indeed the
shopping list is independent of the items on it. The list has an
identity and it has a value (the items needed). If I hand you an empty
list on the basis that the shopping list you placed there last week
was empty, I've destroyed the value of the posted shopping list -
people have added things to it during the week, and they expect those
things to be on the list that gets referenced to make purchases.

ChrisA

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

#92261 — Lawful != Mutable (was Can Python function return multiple data?)

On Saturday, June 6, 2015 at 11:13:52 AM UTC+5:30, Chris Angelico wrote:
> On Sat, Jun 6, 2015 at 3:28 PM, Rustom Mody  wrote:
> > You just repeated what Chris said, replacing 'immutable' with 'same'
> > There was a list: [1,2,3]
> > At some point that list is found to be(come) [1,2,3,4]
> > They dont look same to me.
> 
> "I'm going shopping, can you get me the shopping list please?"
> *goes and fetches a piece of paper from the kitchen*
> "Wait, this isn't the right list! This one has more things on it!"
> 
> The question of whether or not the thing fetched is indeed the
> shopping list is independent of the items on it. The list has an
> identity and it has a value (the items needed). If I hand you an empty
> list on the basis that the shopping list you placed there last week
> was empty, I've destroyed the value of the posted shopping list -
> people have added things to it during the week, and they expect those
> things to be on the list that gets referenced to make purchases.


Well that is a more useful metaphor than much of what I see being said here.
[Most of what I see being summarizable into:
This is the way python is
Python is Holy Writ
THOU SHALT NOT QUESTION
]

So thanks Chris for a non-pythonic metaphor.

May we look a little into it?

Is your shopping list really a list? If I have:

1. Bread
2. Eggs
3. Rice

Presumably that's the 'same' list as

1. Eggs
2. Bread
3. Rice

IOW if we have to make a python data-structure for it, the (python) list
["eggs", "bread", "rice"]
is overspecific. Whereas the set
set(["eggs", "bread", "rice"])
works better for the simple reason that python will conform with our informal
expectation of the two differently listed shopping lists being 
equal with the set data structure and not the list data structure.  ie
["eggs", "bread", "rice"] == ["bread", "eggs", "rice"] fails
whereas
set(["eggs", "bread", "rice"]) == set(["bread", "eggs", "rice"]) works

Is it only coincidentally related to the math law: 
{1,2,3} = {2,1,3}  ?

Now say we change the example slightly, from shopping list to
shopping itenary:
1. Grocer
2. Hardware
3. Clothes

and due to geography of the stores the above order is the best one.
[Yeah I am assuming the Travelling Buysman problem is a solved problem]


So I model that as
itinerary = ["grocer", "hardware", "clothes"]

O! I forgot... Need to cut my hair

itinerary[:2] + ["barber"] + itinerary[-1:]
['grocer', 'hardware', 'barber', 'clothes']
>>> 

Nice... Just one doubt
Do I need to parenthesize that expression??

I try
>>> itinerary[:2] + (["barber"] + itinerary[-1:])
['grocer', 'hardware', 'barber', 'clothes']
>>> (itinerary[:2] + ["barber"]) + itinerary[-1:]
['grocer', 'hardware', 'barber', 'clothes']
>>> 

Seems to be the same.
Nice...

But is it always so?
Or did it just happen by coincidence?

IOW: Does list-+ satisfy an associative LAW of the form:

(∀ a,b,c:list • (a + b) + c = a + (b + c) ) ??


Now try it with mutation.

Some (wiseguy) told me that mutating data structures can be more efficient
than 'functional' ones.

Sounds good... Just not sure how/when associativity works/breaks.

Say we want to stuff a 4 between the 2 and the 3 in [1,2,3]
[Its a bit tiresome to keep typing 'grocer' etc]

>>> it = [1,2,3]
>>> it[:2]
[1, 2]
>>> it[:2].append(4)
>>> it
[1, 2, 3]

Ho Hum.
Try again

>>> it = [1,2,3]
>>> it = it[:2].append(4)
>>> it = it.append(it[-1])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'append'


Got to 'un-None' the #$@%%^ thing

>>> def app(a,b):
...   a.extend(b)
...   return a
... 

>>> a,b,c=[1,2],[3,4],[5,6]
>>> app(app(a,b),c)
[1, 2, 3, 4, 5, 6]
>>> a,b,c=[1,2],[3,4],[5,6]
>>> app(a,app(b,c))
[1, 2, 3, 4, 5, 6]

Looks right so far.
A few more checks...

>>> a,b=[1,2],[3,4]
>>> app(app(a,a),b)  # (a + a) + b
[1, 2, 1, 2, 3, 4]
>>> a,b=[1,2],[3,4]  # ok
>>> app(a,app(a,b))  # a + (a + b)
[1, 2, 3, 4, 1, 2, 3, 4]  # Whooops!


No I am not claiming that my pretence at noob struggles is very convincing.
Hopefully works enough to show that mutatory programming may be a lot of 'fun'
However imperative ≡ mutating  ≢ not-lawful

In Summary:

Correct programs are in accordance with math/logic laws
Incorrect programs are written by people ignorant of laws
Immutability is the bedrock of lawfulness -- If Newton had assumed
that between the time Kepler made his calculations and Newton recast them
into general form, the gravitional constant 'G' was changing, we would not
have physics or science as we know it
Properties like (python's version of) immutability just make stating of lawful
behavior unduly hard by asserting gibberish such as
[1,2,3] is [1,2,3,4].

[Just to be clear, I find python's notion of immutability sloppy but hard
to avoid whereas python's use of the 'is' operator for pointer-equality
a much bigger linguistic blunder. The two errors are closely related]

Piquant footnote: The big proponent of 'lawful¹' programming is
Lambert Meertens, who happens to be the grandfather² of python.

¹ http://www.kestrel.edu/home/people/meertens/publications/papers/Algorithmics.pdf
² http://en.wikipedia.org/wiki/ABC_%28programming_language%29

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

#92265 — Re: Lawful != Mutable (was Can Python function return multiple data?)

On Mon, Jun 8, 2015 at 1:49 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> On Saturday, June 6, 2015 at 11:13:52 AM UTC+5:30, Chris Angelico wrote:
>> On Sat, Jun 6, 2015 at 3:28 PM, Rustom Mody  wrote:
>> > You just repeated what Chris said, replacing 'immutable' with 'same'
>> > There was a list: [1,2,3]
>> > At some point that list is found to be(come) [1,2,3,4]
>> > They dont look same to me.
>>
>> "I'm going shopping, can you get me the shopping list please?"
>> *goes and fetches a piece of paper from the kitchen*
>> "Wait, this isn't the right list! This one has more things on it!"
>>
>> The question of whether or not the thing fetched is indeed the
>> shopping list is independent of the items on it. The list has an
>> identity and it has a value (the items needed). If I hand you an empty
>> list on the basis that the shopping list you placed there last week
>> was empty, I've destroyed the value of the posted shopping list -
>> people have added things to it during the week, and they expect those
>> things to be on the list that gets referenced to make purchases.
>
>
> Well that is a more useful metaphor than much of what I see being said here.
> [Most of what I see being summarizable into:
> This is the way python is
> Python is Holy Writ
> THOU SHALT NOT QUESTION
> ]
>
> So thanks Chris for a non-pythonic metaphor.
>
> May we look a little into it?
>
> Is your shopping list really a list? If I have:
>
> 1. Bread
> 2. Eggs
> 3. Rice
>
> Presumably that's the 'same' list as
>
> 1. Eggs
> 2. Bread
> 3. Rice
>
> IOW if we have to make a python data-structure for it, the (python) list
> ["eggs", "bread", "rice"]
> is overspecific. Whereas the set
> set(["eggs", "bread", "rice"])
> works better for the simple reason that python will conform with our informal
> expectation of the two differently listed shopping lists being
> equal with the set data structure and not the list data structure.  ie
> ["eggs", "bread", "rice"] == ["bread", "eggs", "rice"] fails
> whereas
> set(["eggs", "bread", "rice"]) == set(["bread", "eggs", "rice"]) works

Well, yes and no. I used the term "list" because most people don't
talk about a "shopping set", and the list that's posted does have an
order to it; the effect of the list will be the same regardless of
order, but the order might be useful for curiosity purposes - the
items at the head of the list have been on it longer than the ones at
the tail, so they most likely will be more needed. For a comparison,
I'm sure you'd agree that the order of a program's arguments matters,
so you need a list and not a set; but if you type "cp spam eggs ham
target/" it's going to have the same net result as "cp eggs spam ham
target/", in that all three files will be copied to the same target
directory.

There are plenty of real-world lists where order turns out to not
matter, but they still retain that order. On any membership list, the
important thing is whether you're on it or not, but somewhere on a
sheet of paper, someone's going to be higher and someone's going to be
lower. A list of the different types of Cadbury Roses has to be sorted
one way or another; the Wikipedia page [1] mentions Cherry Heaven
above Turkish Delight, but my blog [2] has them the other way around -
is one of them somehow wrong? These are, in a way, sets masquerading
as lists, but given that many contexts don't really allow any
distinction, it's not usually considered to be a problem.

So you can call them sets if you like, but there's no real
significance either way.

ChrisA

[1] http://en.wikipedia.org/wiki/Cadbury_Roses
[2] http://rosuav.blogspot.com.au/2012/06/scientific-research-into-cadbury-roses.html

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

#92266 — Re: Lawful != Mutable (was Can Python function return multiple data?)

On Saturday, June 6, 2015 at 10:20:49 AM UTC+5:30, Steven D'Aprano wrote:
> On Sat, 6 Jun 2015 01:20 pm, Rustom Mody wrote:
> 
> > On Saturday, June 6, 2015 at 3:30:23 AM UTC+5:30, Chris Angelico wrote:
> 
> >> Congrats! You just proved that an object can itself be immutable, but
> >> can contain references to mutables. Ain't that awesome?
> >> 
> >> Did you have a point?
> > 
> > [Under assumption you are not being facetious...]
> > The word immutuable happens to have existed in English before python.
> > I also happen to have used it before I knew of python
> > The two meanings do not match
> > I am surprised
> > Is that surprising?
> 
> Yes, I am surprised that you are surprised. You have been a regular, and
> prolific, contributor on this forum for some years now, teach Python, blog
> about it. You're quite obviously well-read and experienced. How is it that
> you are surprised by such a fundamental part of not just Python's object
> model, but of real life objects too?
> 
> I suspect you are pretending to be surprised to make a rhetorical point.

Dunno why the fuss...
As someone who often asks for short-simple-self-contained examples,
I would have expected you to prefer clarity of communication over
fidelity of experience??

Anyways...

Did I(rusi) now(2015) find that specific example surprising??

No, but:

1. Questioners here regularly do show similar confusions.
2. I did go through similar decades ago when I first encountered programming
3. And most to the point, just add a little complexity and I (rusi-now)
am as confused as any noob.

A few weeks ago there was this example.
It completely knocked me.
ChrisA's exxplanation clarified.
Here is a reconstruction based on Chris clarification
[Chris do you remember the question?]

>>> t=([1,2],[3,4])
>>> t
([1, 2], [3, 4])
>>> t[1] = t[1].append(5)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment
>>> t
([1, 2], [3, 4, 5])

> 
> Like many English words, "immutable" has a few meanings in plain English.
> Bouvier's Law Dictionary included in 1856 this definition:
> 
>     IMMUTABLE. What cannot be removed, what is unchangeable.
>     The laws of God peing perfect, are immutable, but no 
>     human law can be so considered.
> 
> Clearly tuples can be removed. They are garbage-collected like any other
> values in Python. If nothing else, you can turn the computer off, remove
> the RAM, grind it down into the finest powder, and scatter it to the winds.
> That surely is enough to remove the tuples <wink> 

Ok now rewrite that para above with 
s/tuple/numbers like 3 or 666/
So I put '3' on the ram and grind it to finest powder.
Have all trinities (of religious or secular variety) disappeared?
666 gone has the devil been banished from God's (or Steven's) universe?

> So according to Bouvier's definition, tuples are not immutable. But I trust
> that we can agree that Bouvier's definition is not useful here.

Actually its a very nice and apt quote.
Just add laws of mathematics to laws of God and it will be perfect.
[Or better remember that for Plato they were the same]

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

#92269 — Re: Lawful != Mutable (was Can Python function return multiple data?)

On Mon, Jun 8, 2015 at 2:20 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Ok now rewrite that para above with
> s/tuple/numbers like 3 or 666/
> So I put '3' on the ram and grind it to finest powder.
> Have all trinities (of religious or secular variety) disappeared?
> 666 gone has the devil been banished from God's (or Steven's) universe?

If you write down your phone number and give it to a girl you like,
and she burns that piece of paper, do you no longer have a phone
number? No, but she certainly doesn't have your phone number any more.
There's a difference between destroying a representation and
destroying the original entity. But Steven's point wasn't about how
easy/hard it is to destroy something; it was about a tuple's
immutability NOT being a prevention of its destruction, and therefore
it's not that sense of the word in which they're immutable. Similarly,
you could destroy a document on which God's laws are written (in the
original dictionary sense; if you don't want to believe in immutable
laws of a Deity, you can substitute in a law of physics - for
instance, the law that two objects with mass exert a force of
attraction on each other due to gravity), and it wouldn't destroy the
law itself.

ChrisA

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

#92923 — Re: Lawful != Mutable (was Can Python function return multiple data?)

On Sunday, June 7, 2015 at 10:04:37 PM UTC+5:30, Chris Angelico wrote:
> On Mon, Jun 8, 2015 at 2:20 AM, Rustom Mody  wrote:
> > Ok now rewrite that para above with
> > s/tuple/numbers like 3 or 666/
> > So I put '3' on the ram and grind it to finest powder.
> > Have all trinities (of religious or secular variety) disappeared?
> > 666 gone has the devil been banished from God's (or Steven's) universe?
> 
> If you write down your phone number and give it to a girl you like,
> and she burns that piece of paper, do you no longer have a phone
> number? No, but she certainly doesn't have your phone number any more.
> There's a difference between destroying a representation and
> destroying the original entity. But Steven's point wasn't about how
> easy/hard it is to destroy something; it was about a tuple's
> immutability NOT being a prevention of its destruction, and therefore
> it's not that sense of the word in which they're immutable. Similarly,
> you could destroy a document on which God's laws are written (in the
> original dictionary sense; if you don't want to believe in immutable
> laws of a Deity, you can substitute in a law of physics - for
> instance, the law that two objects with mass exert a force of
> attraction on each other due to gravity), and it wouldn't destroy the
> law itself.
> 
> ChrisA

Recent thread on python ideas
https://mail.python.org/pipermail/python-ideas/2015-June/034177.html

Since "python's immutable" ≠ "really immutable", we now need a "really immutable"

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

#92925 — Re: Lawful != Mutable (was Can Python function return multiple data?)

On Sun, Jun 21, 2015 at 11:59 AM, Rustom Mody <rustompmody@gmail.com> wrote:
> Recent thread on python ideas
> https://mail.python.org/pipermail/python-ideas/2015-June/034177.html
>
> Since "python's immutable" ≠ "really immutable", we now need a "really immutable"

That's because it requires mutable memory to keep track of reference
counts. In a non-refcountinig Python, strings and integers can be
truly immutable; that thread is suggesting (among other options)
simply storing the refcounts in a separate table. Conceptually, a
string or integer IS immutable, but CPython currently needs to be able
to fiddle with some bookkeeping data about them, in order to pretend
it has plenty of memory. A Python implementation could theoretically
just abandon its strings whenever it's done with them, wasting gobs of
memory in the process, and having them in read-only memory. More
practically, a pure mark-and-sweep GC (such as MicroPython uses)
trades prompt disposal for simple management, and in doing so,
achieves (I think) the same total immutability.

You have to distinguish between Python (the language) and CPython (the
implementation) here. Python's notion of mutability has nothing to do
with thread safety. You could achieve perfect thread safety for
immutables by simply replicating them into every thread; it'd be
inefficient, but perfectly legal.

ChrisA

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

#92926 — Re: Lawful != Mutable (was Can Python function return multiple data?)

On Sunday, June 21, 2015 at 8:03:18 AM UTC+5:30, Chris Angelico wrote:
> On Sun, Jun 21, 2015 at 11:59 AM, Rustom Mody wrote:
> > Recent thread on python ideas
> > https://mail.python.org/pipermail/python-ideas/2015-June/034177.html
> >
> > Since "python's immutable" ≠ "really immutable", we now need a "really immutable"
> 
> That's because it requires mutable memory to keep track of reference
> counts. In a non-refcountinig Python, strings and integers can be
> truly immutable; that thread is suggesting (among other options)
> simply storing the refcounts in a separate table. Conceptually, a
> string or integer IS immutable, but CPython currently needs to be able
> to fiddle with some bookkeeping data about them, in order to pretend
> it has plenty of memory. A Python implementation could theoretically
> just abandon its strings whenever it's done with them, wasting gobs of
> memory in the process, and having them in read-only memory. More
> practically, a pure mark-and-sweep GC (such as MicroPython uses)
> trades prompt disposal for simple management, and in doing so,
> achieves (I think) the same total immutability.
> 
> You have to distinguish between Python (the language) and CPython (the
> implementation) here. Python's notion of mutability has nothing to do
> with thread safety. You could achieve perfect thread safety for
> immutables by simply replicating them into every thread; it'd be
> inefficient, but perfectly legal.
> 
> ChrisA

Here is Eric Snow:

| Keep in mind that by "immutability" I'm talking about *really*
| immutable, perhaps going so far as treating the full memory space
| associated with an object as frozen.  For instance, we'd have to
| ensure that "immutable" Python objects like strings, ints, and tuples
| do not change (i.e. via the C API).  The contents of involved
| tuples/containers would have to be likewise immutable.  Even changing
| refcounts could be too much, hence the idea of moving refcounts out to
| a separate table.
|  
| This level of immutability would be something new to Python.  We'll
| see if it's necessary.  If it isn't too much work it might be a good
| idea regardless of the multi-core proposal.

Does the second para look like CPython implementation or python-the-language?

Also note the 'Even' in the first para. ie Eric is talking of low-level
(ie thread-safety, refcounting etc) immutability after the even and higher
level semantic immutability before

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

#92944 — Re: Lawful != Mutable (was Can Python function return multiple data?)

In a message of Sat, 20 Jun 2015 19:50:21 -0700, Rustom Mody writes:
>Here is Eric Snow:
>
>| Keep in mind that by "immutability" I'm talking about *really*
>| immutable, perhaps going so far as treating the full memory space
>| associated with an object as frozen.  For instance, we'd have to
>| ensure that "immutable" Python objects like strings, ints, and tuples
>| do not change (i.e. via the C API).  The contents of involved
>| tuples/containers would have to be likewise immutable.  Even changing
>| refcounts could be too much, hence the idea of moving refcounts out to
>| a separate table.
>|  
>| This level of immutability would be something new to Python.  We'll
>| see if it's necessary.  If it isn't too much work it might be a good
>| idea regardless of the multi-core proposal.
>
>Does the second para look like CPython implementation or python-the-language?

Regardless of how it looks, it's only about the CPython implementation.
PyPy and Jython will not have this problem, as they don't have a C API
to worry about.  Of course the PyPy position is that STM will solve
all of this in a much cleaner way, and we're getting closer to a
perfectly working solution for as many cores as you have (as opposed
to only 4) that works on all OS's (as opposed to just 64 bit linux)
all the time.

This is very much a 'how to hack CPython to support multiple cores'
idea.  It's a 'kill the GIL' proposal.  But PyPy-STM and Jython
don't have a GIL, so they don't need to kill it.

>Also note the 'Even' in the first para. ie Eric is talking of low-level
>(ie thread-safety, refcounting etc) immutability after the even and higher
>level semantic immutability before

The ref-counting should be a very strong hint that this is a CPython
implementation proposal.  Again, Jython and PyPy don't use a ref counting
GC.

Laura

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

#92957 — Re: Lawful != Mutable (was Can Python function return multiple data?)

On 06/20/2015 10:50 PM, Rustom Mody wrote:
> Here is Eric Snow:
>
> | Keep in mind that by "immutability" I'm talking about*really*
> | immutable, perhaps going so far as treating the full memory space
> | associated with an object as frozen.  For instance, we'd have to
> | ensure that "immutable" Python objects like strings, ints, and tuples
> | do not change (i.e. via the C API).  The contents of involved
> | tuples/containers would have to be likewise immutable.  Even changing
> | refcounts could be too much, hence the idea of moving refcounts out to
> | a separate table.
> |
> | This level of immutability would be something new to Python.  We'll
> | see if it's necessary.  If it isn't too much work it might be a good
> | idea regardless of the multi-core proposal.
>
> Does the second para look like CPython implementation or python-the-language?
>
> Also note the 'Even' in the first para. ie Eric is talking of low-level
> (ie thread-safety, refcounting etc) immutability after the even and higher
> level semantic immutability before

It seems to me, this will take a lot more changes to python overall.

Adding a way to raise an exception if an object is mutated would be a good 
initial step.  Have it turned off by default.

I think it will be needed to test how any of the above is working.

It may also allow some multiprocessing just by avoiding raising any 
MutatedObject exceptions.

Cheers,
    Ron

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

#92201

On Sat, 6 Jun 2015 03:28 pm, Rustom Mody wrote:

> There was a list: [1,2,3]
> At some point that list is found to be(come) [1,2,3,4]
> They dont look same to me.

When you pour water into an empty bottle, does it turn into a different
bottle?

When you append items to a list (or remove them), it is still the same list.



-- 
Steven

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

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

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

csiph-web