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

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

Tuples and immutability

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

Contents

  Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-02-27 17:01 +0100
    Re: Tuples and immutability Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-27 10:13 -0600
      Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-02-27 17:27 +0100
        Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-02-28 03:33 +1100
        Re: Tuples and immutability Zachary Ware <zachary.ware+pylist@gmail.com> - 2014-02-27 10:47 -0600
        Re: Tuples and immutability Nick Timkovich <prometheus235@gmail.com> - 2014-02-27 15:47 -0600
        Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-02-28 08:52 +1100
        Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-27 15:18 -0700
        Re: Tuples and immutability Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-01 18:55 +0000
    Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-02-28 03:14 +1100
    Re: Tuples and immutability Marko Rauhamaa <marko@pacujo.net> - 2014-02-27 18:19 +0200
      Re: Tuples and immutability John O'Hagan <research@johnohagan.com> - 2014-02-28 16:17 +1100
        Re: Tuples and immutability Marko Rauhamaa <marko@pacujo.net> - 2014-02-28 09:54 +0200
    Re: Tuples and immutability Joshua Landau <joshua@landau.ws> - 2014-02-28 14:41 +0000
    Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-01 01:43 +1100
    Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 16:22 -0800
      Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-01 02:27 +0100
        Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 20:45 -0800
          Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-28 22:34 -0700
            Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 21:50 -0800
              Re: Tuples and immutability Ned Batchelder <ned@nedbatchelder.com> - 2014-03-01 12:56 -0500
        Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-28 22:26 -0700
      Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-01 12:39 +1100
      Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-02-28 22:16 -0700
        Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 22:16 -0800
          Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-01 17:29 +1100
          Re: Tuples and immutability Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-01 14:54 +0000
            Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 13:01 -0800
        Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-02-28 22:25 -0800
          Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-01 12:45 -0700
        Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 13:21 -0800
          Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-02 03:04 +0100
            Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 18:28 -0800
            Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-02 05:32 -0700
              Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-02 14:38 +0100
                Re: Tuples and immutability Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-02 14:05 +0000
                  Re: Tuples and immutability Eric Jacoboni <eric.jacoboni@gmail.com> - 2014-03-02 15:17 +0100
                    Re: Tuples and immutability "albert visser" <albert.visser@gmail.com> - 2014-03-02 15:37 +0100
          Re: Tuples and immutability "Mark H. Harris" <harrismh777@gmail.com> - 2014-03-01 18:15 -0800

Page 1 of 2  [1] 2  Next page →

#67151 — Tuples and immutability

Hi,

I'm using Python 3.3 and i have a problem for which i've still not found
any reasonable explanation...

>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1] += [20]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: 'tuple' object does not support item assignment

Ok... I accept this message as += is a reassignment of a_tuple[1] and a
tuple is immutable...

But, then, why a_tuple is still modified?

>>> a_tuple
('spam', [10, 30, 20], 'eggs')

I get a TypeError for an illegal operation, but this operation is still
completed?

[toc] | [next] | [standalone]

#67152

On Thu, Feb 27, 2014 at 10:01 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
> Hi,
>
> I'm using Python 3.3 and i have a problem for which i've still not found
> any reasonable explanation...
>
>>>> a_tuple = ("spam", [10, 30], "eggs")
>>>> a_tuple[1] += [20]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment
>
> Ok... I accept this message as += is a reassignment of a_tuple[1] and a
> tuple is immutable...
>
> But, then, why a_tuple is still modified?
>
>>>> a_tuple
> ('spam', [10, 30, 20], 'eggs')
>
> I get a TypeError for an illegal operation, but this operation is still
> completed?

You're not the first person to have this question :)

http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works

-- 
Zach

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

#67156

Le 27/02/2014 17:13, Zachary Ware a écrit :
>
> You're not the first person to have this question :)
> 
> http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works
> 

Oh yes, i was aware of this explanation (thanks to Chris for his answer,
too)... and that's why i wrote "reasonable" :)
I know i should use append() or extend() and i understand the tricky
implications of += in this context. But, imho, it's far from being a
intuitive result, to say the least.

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

#67157

On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
> But, imho, it's far from being a intuitive result, to say the least.

It's unintuitive, but it's a consequence of the way += is defined. If
you don't want assignment, don't use assignment :)

ChrisA

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

#67158

On Thu, Feb 27, 2014 at 10:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
> Le 27/02/2014 17:13, Zachary Ware a écrit :
>>
>> You're not the first person to have this question :)
>>
>> http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works
>>
>
> Oh yes, i was aware of this explanation (thanks to Chris for his answer,
> too)... and that's why i wrote "reasonable" :)
> I know i should use append() or extend() and i understand the tricky
> implications of += in this context. But, imho, it's far from being a
> intuitive result, to say the least.

Well, once you understand what's actually going on, it's the result
that you should expect.  The FAQ entry I linked to exists to help
people get to that point.

To answer your specific questions:

> But, then, why a_tuple is still modified?

It is not.  a_tuple is still "('spam', <list object at specific
address>, 'eggs')", exactly the same before and after the attempted
"a_tuple[1] += [20]".  The change is internal to <list object at
specific address>.

> I get a TypeError for an illegal operation, but this operation is still
> completed?

Half completed.  The extension of <list object at specific address>
happened as expected, but the assignment of <list object at specific
address> to a_tuple[1] didn't.  It looks like it did, though, because
the assignment was just trying to assign the same object to the same
index.

-- 
Zach

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

#67166

[Multipart message — attachments visible in raw view] — view raw

On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico <rosuav@gmail.com> wrote:

> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com>
> wrote:
> > But, imho, it's far from being a intuitive result, to say the least.
>
> It's unintuitive, but it's a consequence of the way += is defined. If
> you don't want assignment, don't use assignment :)
>
> ChrisA
>

Where is `.__iadd__()` called outside of `list += X`?  If the only
difference from `.extend()` is that it returns `self`, but the list was
already modified anyway, why bother with reassignment?

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

#67168

On Fri, Feb 28, 2014 at 8:47 AM, Nick Timkovich <prometheus235@gmail.com> wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com>
>> wrote:
>> > But, imho, it's far from being a intuitive result, to say the least.
>>
>> It's unintuitive, but it's a consequence of the way += is defined. If
>> you don't want assignment, don't use assignment :)
>>
>> ChrisA
>
>
> Where is `.__iadd__()` called outside of `list += X`?  If the only
> difference from `.extend()` is that it returns `self`, but the list was
> already modified anyway, why bother with reassignment?

Not everything handles += that way. You can't mutate the integer 5
into 7 because someone had 5 in x and wrote "x += 2". So it has to
reassign.

Actually, integers just don't define __iadd__, but the principle applies.

ChrisA

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

#67172

On Thu, Feb 27, 2014 at 2:47 PM, Nick Timkovich <prometheus235@gmail.com> wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni <eric.jacoboni@gmail.com>
>> wrote:
>> > But, imho, it's far from being a intuitive result, to say the least.
>>
>> It's unintuitive, but it's a consequence of the way += is defined. If
>> you don't want assignment, don't use assignment :)
>>
>> ChrisA
>
>
> Where is `.__iadd__()` called outside of `list += X`?  If the only
> difference from `.extend()` is that it returns `self`, but the list was
> already modified anyway, why bother with reassignment?

x += y is meant to be equivalent, except possibly in-place and more
efficient, than x = x + y.  If you skip the assignment, and that
assignment is meaningful to whatever the left side may be (e.g.
assigning to a descriptor or something that invokes __setitem__ or
__setattr__), then the operation is not equivalent.

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

#67338

On 27 February 2014 21:47, Nick Timkovich <prometheus235@gmail.com> wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico <rosuav@gmail.com> wrote:
>>
>> It's unintuitive, but it's a consequence of the way += is defined. If
>> you don't want assignment, don't use assignment :)
>
> Where is `.__iadd__()` called outside of `list += X`?

Numpy uses it for in-place operations with numpy arrays:

>>> import numpy
>>> a = numpy.arange(10)
>>> a
array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])
>>> a[::2] += 10
>>> a
array([10,  1, 12,  3, 14,  5, 16,  7, 18,  9])

It makes sense for any mutable type that supports +. The stdlib
doesn't have many of these. The obvious one is list but there's also
MutableString (in 2.x):

>>> from UserString import MutableString
>>> a = MutableString("qwe")
>>> a
'qwe'
>>> b = a
>>> b += "asd"
>>> a
'qweasd'

> If the only difference from `.extend()` is that it returns `self`, but the list was
> already modified anyway, why bother with reassignment?

I don't know of any situation where __iadd__ is defined but doesn't
return self and I can't think of a use case apart from operator abuse.

I had thought that the other difference was that .extend would accept
any iterable but it seems += does also. Perhaps that was changed at
some point.

>>> l = [1, 2, 3]
>>> l + (1, 2, 3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "tuple") to list
>>> l += (1, 2, 3)
>>> l
[1, 2, 3, 1, 2, 3]


Oscar

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

#67153

On Fri, Feb 28, 2014 at 3:01 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
> I'm using Python 3.3 and i have a problem for which i've still not found
> any reasonable explanation...
>
>>>> a_tuple = ("spam", [10, 30], "eggs")
>>>> a_tuple[1] += [20]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment
>
> Ok... I accept this message as += is a reassignment of a_tuple[1] and a
> tuple is immutable...
>
> But, then, why a_tuple is still modified?
>
>>>> a_tuple
> ('spam', [10, 30, 20], 'eggs')
>
> I get a TypeError for an illegal operation, but this operation is still
> completed?

This is a common confusion.

The += operator does two things. First, it asks the target to please
do an in-place addition of the other operand. Then, it takes whatever
result the target gives back, and assigns it back into the target. So
with a list, it goes like this:

>>> foo = [10, 30]
>>> foo.__iadd__([20])
[10, 30, 20]
>>> foo = _

Note that the second step returned a three-element list. Then the +=
operator stuffs that back into the source. In the case of a list, it
does that addition by extending the list, and then returning itself.

The putting-back-into-the-target step fails with a tuple, because a
tuple's members can't be reassigned. But the list has already been
changed by that point. So, when you go to look at it, you see a
changed list.

You can call on this behaviour more safely by using the append() or
extend() methods.

>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1].extend([20])
>>> a_tuple
('spam', [10, 30, 20], 'eggs')

>>> a_tuple = ("spam", [10, 30], "eggs")
>>> a_tuple[1].append(20)
>>> a_tuple
('spam', [10, 30, 20], 'eggs')

(append will add one more element, extend is roughly the same as you
had). Then you're not trying to assign to the tuple, but you're still
mutating the list.

Hope that helps!

ChrisA

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

#67154

Eric Jacoboni <eric.jacoboni@gmail.com>:

>>>> a_tuple[1] += [20]
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> TypeError: 'tuple' object does not support item assignment
>
> [...]
>
> But, then, why a_tuple is still modified?

That's because the += operator

 1. modifies the list object in place

 2. tries to replace the tuple slot with the list (even though the list
    hasn't changed)

It's Step 2 that raises the exception, but the damage has been done
already.

One may ask why the += operator modifies the list instead of creating a
new object. That's just how it is with lists.

BTW, try:

   >>> a_tuple[1].append(20)
   >>> a_tuple[1].extend([20])

Try also:

   >>> a_tuple[1] = a_tuple[1]


Marko

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

#67197

On Thu, 27 Feb 2014 18:19:09 +0200
Marko Rauhamaa <marko@pacujo.net> wrote:

> Eric Jacoboni <eric.jacoboni@gmail.com>:
> 
> >>>> a_tuple[1] += [20]
> > Traceback (most recent call last):
> >   File "<stdin>", line 1, in <module>
> > TypeError: 'tuple' object does not support item assignment
> >
> > [...]
> >
> > But, then, why a_tuple is still modified?
> 
> That's because the += operator
> 
>  1. modifies the list object in place
> 
>  2. tries to replace the tuple slot with the list (even though the
> list hasn't changed)
> 
> It's Step 2 that raises the exception, but the damage has been done
> already.
> 
> One may ask why the += operator modifies the list instead of creating
> a new object. That's just how it is with lists.
> 
> BTW, try:
> 
>    >>> a_tuple[1].append(20)
>    >>> a_tuple[1].extend([20])
> 
> Try also:
> 
>    >>> a_tuple[1] = a_tuple[1]
> 

[...]

Also try:

x = a_tuple[1] #What's in a name?
x is a_tuple[1] #Obviously, but:
x += [1] #No error
a_tuple[1] += [1] #Error

Same object, just a different name - but a different result. I get why,
but still find that odd.

--

John

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

#67205

John O'Hagan <research@johnohagan.com>:

> Same object, just a different name - but a different result. I get
> why, but still find that odd.

The general principle is stated in the language specification:

   <URL: http://docs.python.org/3.2/reference/simple_stmts.html
   #augmented-assignment-statements>:

   Also, when possible, the actual operation is performed in-place,
   meaning that rather than creating a new object and assigning that to
   the target, the old object is modified instead.

   [...] with the exception of the possible in-place behavior, the
   binary operation performed by augmented assignment [x += y] is the
   same as the normal binary operations [x = x + y].

We should call += "dual-use technology."


Marko

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

#67225

On 27 February 2014 16:14, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, Feb 28, 2014 at 3:01 AM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote:
>>
>>>>> a_tuple = ("spam", [10, 30], "eggs")
>>>>> a_tuple[1] += [20]
>> Traceback (most recent call last):
>>   File "<stdin>", line 1, in <module>
>> TypeError: 'tuple' object does not support item assignment
>>
>> Ok... I accept this message as += is a reassignment of a_tuple[1] and a
>> tuple is immutable...
>>
>> But, then, why a_tuple is still modified?
>
> This is a common confusion.
>
> The += operator does two things. First, it asks the target to please
> do an in-place addition of the other operand. Then, it takes whatever
> result the target gives back, and assigns it back into the target. So
> with a list, it goes like this:
>
>>>> foo = [10, 30]
>>>> foo.__iadd__([20])
> [10, 30, 20]
>>>> foo = _

Would it be better to add a check here, such that if this gets raised
to the top-level it includes a warning ("Addition was inplace;
variable probably mutated despite assignment failure")?

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

#67227

On Sat, Mar 1, 2014 at 1:41 AM, Joshua Landau <joshua@landau.ws> wrote:
> Would it be better to add a check here, such that if this gets raised
> to the top-level it includes a warning ("Addition was inplace;
> variable probably mutated despite assignment failure")?

That'd require figuring out whether or not the variable was actually
mutated, and that's pretty hard to work out. So there's a FAQ entry,
which Zachary already posted:

http://docs.python.org/3/faq/programming.html#why-does-a-tuple-i-item-raise-an-exception-when-the-addition-works

Also, we just answer this question every now and then :) Presumably
more often on -tutor than here.

ChrisA

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

#67260

On Thursday, February 27, 2014 10:01:39 AM UTC-6, Eric Jacoboni wrote:

> 
> ('spam', [10, 30, 20], 'eggs')
> 

> I get a TypeError for an illegal operation, but this operation is still
> 
> completed?

hi Eric,  others have answered your question specifically, but the issue (which is recurring) begs a couple of questions, which will also be recurring...  ehem.

This little snag (if it can be called that) is a side effect from two python inherent design considerations:

1)  not to be a nudge, but dynamic typing is the first...

2)  and the concept of immutability is the second.

I'll address the second first by asking a question...  should an immutable type (object) be able to hold (contain) mutable objects ... should tuples be allowed to hold lists? 

lists within a tuple should be converted to tuples.    If you want a tuple to hold a list,  make it a list in the first place.  Tuples should not be changed... and as you point out... half changing a tuple is not a good condition if there is an exception...

Which brings me to my second point... dynamic binding...  (and everything associated with that) is at play here too....  please, don't get me wrong,  this is not flame bait and I'm not advocating static binding, nor do I want static binding, nor do I want to open that can of worms again... just saying.

I really think this is a bug; honestly.  IMHO it should be an error to use  +=  with an immutable type and that means not at all.  In other words,  the list should not even be considered, because we're talking about changing a tuple... which should not be changed (nor should its members be changed). 

Soooo....   the type does not support item assignment, yet the item got assigned.  This is at least inconsistent... and to my small mind means... bug report.

:)

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

#67275

Le 01/03/2014 01:22, Mark H. Harris a écrit :

> I'll address the second first by asking a question...  should an immutable type (object) be able to hold (contain) mutable objects ... should tuples be allowed to hold lists? 
> 
> lists within a tuple should be converted to tuples.    If you want a tuple to hold a list,  make it a list in the first place.  

You're perfectly right and that why i've corrected my code to use a list
of lists instead of tuple of list. I was hoping Python would prevent me
for such a mistake (because such a situation can't be cleary
intentional, isn't ?). Now, i will use tuple only with immutable items.


IMHO it should be an error to use  +=  with an immutable type and that
means not at all.

In other words,  the list should not even be considered, because we're
talking about changing a tuple...

which should not be changed (nor should its members be changed).

I agree with that too... My error was to first consider the list, then
the tuple... I should have considered the tuple first...
Anyway, the TypeError should rollback, not commit the mistake.

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

#67290

On Friday, February 28, 2014 7:27:17 PM UTC-6, Eric Jacoboni wrote:

> I agree with that too... My error was to first consider the list, then
> the tuple... I should have considered the tuple first...
> Anyway, the TypeError should rollback, not commit the mistake.

I believe so too,  but I'm not one of the core devs.  And they do not agree. 

Ever since day one with me and python I have questioned whether a tuple even makes sense.  Well, certainly it does, because it has so much less overhead and yet it acts like a list (which for so many situations thats really what we want anyway... a list, that never changes).  Tuples are great, for what they are designed to do.

But now consider,  why would I purposely want to place a mutable object within an immutable list?  A valid question of high importance.  Why indeed?  

I really believe IMHO that the error should have come when you made the list an item of a tuple.  An immutable object should have NO REASON to contain a mutable  object like list... I mean the whole point is to eliminate the overhead of a list ... why would the python interpreter allow you to place a mutable object within an immutable list in the first place.   This is just philosophical, and yes, the core dev's are not going to agree with me on this either.

I think the situation is interesting for sure... and it will surface again, you can count on that.

Cheers

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

#67294

On Fri, Feb 28, 2014 at 9:45 PM, Mark H. Harris <harrismh777@gmail.com> wrote:
> I really believe IMHO that the error should have come when you made the list an item of a tuple.  An immutable object should have NO REASON to contain a mutable  object like list... I mean the whole point is to eliminate the overhead of a list ... why would the python interpreter allow you to place a mutable object within an immutable list in the first place.   This is just philosophical, and yes, the core dev's are not going to agree with me on this either.

One very common example of tuples containing lists is when lists are
passed to any function that accepts *args, because the extra arguments
are passed in a tuple.  A similarly common example is when returning
multiple objects from a function, and one of them happens to be a
list, because again they are returned in a tuple.

    def f(*args):
        print(args)
        return (args[1:])

    >>> result = f(1, 2, 3, [4, 5])
    (1, 2, 3, [4, 5])
    >>> print(result)
    (2, 3, [4, 5])

Both of these things are quite handy, and if you restrict tuples from
containing lists, then you lose both of them (or you switch to lists
and lose the optimization for no good reason).

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

#67295

On Friday, February 28, 2014 11:34:56 PM UTC-6, Ian wrote:

> One very common example of tuples containing lists is when lists are
> passed to any function that accepts *args, because the extra arguments
> are passed in a tuple.  A similarly common example is when returning
> multiple objects from a function, and one of them happens to be a
> list, because again they are returned in a tuple.

>     def f(*args):
>         print(args)
>         return (args[1:]
> 
>     >>> result = f(1, 2, 3, [4, 5])
>     (1, 2, 3, [4, 5])
>     >>> print(result)
>     (2, 3, [4, 5])

I agree Ian... good points all.   ... again, I'm not arguing with anyone... just saying that an error (whatever we mean by that) should not half-way-fail....   we are only pointing out the problem... we have not idea what the solution is yet. 

Intuitively everyone can see that there is a problem here...  the debate cannot be answered either because of the inherent design of python (almost all of which we love). So, as they say, what is a mother to do?  ... I mean, some people's kids... 

I don't know how I propose to handle the problem... I think the first step is getting everyone to agree that there IS a problem... then debate how to tackle the solution proposals.

marcus

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web