Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #67151 > unrolled thread
| Started by | Eric Jacoboni <eric.jacoboni@gmail.com> |
|---|---|
| First post | 2014-02-27 17:01 +0100 |
| Last post | 2014-03-10 07:06 +1100 |
| Articles | 20 on this page of 161 — 33 participants |
Back to article view | Back to comp.lang.python
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 Rick Johnson <rantingrickjohnson@gmail.com> - 2014-03-11 19:01 -0700
Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-12 13:10 +1100
Re: Tuples and immutability Terry Reedy <tjreedy@udel.edu> - 2014-03-11 23:25 -0400
Re: Tuples and immutability Steven D'Aprano <steve@pearwood.info> - 2014-03-12 06:28 +0000
Re: Tuples and immutability Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-12 10:39 +0100
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-12 03:40 -0600
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-12 03:51 -0600
Re: Tuples and immutability Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-12 12:21 +0100
Re: Tuples and immutability Ethan Furman <ethan@stoneleaf.us> - 2014-03-11 23:32 -0700
Re: Tuples and immutability Oscar Benjamin <oscar.j.benjamin@gmail.com> - 2014-03-12 10:20 +0000
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 Duncan Booth <duncan.booth@invalid.invalid> - 2014-03-07 09:33 +0000
Re: Tuples and immutability Ben Finney <ben+python@benfinney.id.au> - 2014-03-07 22:04 +1100
Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-07 22:11 +1100
Re: Tuples and immutability Peter Otten <__peter__@web.de> - 2014-03-07 12:38 +0100
Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-07 22:45 +1100
Re: Tuples and immutability Alister <alister.ware@ntlworld.com> - 2014-03-07 11:51 +0000
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-07 11:23 -0700
Re: Tuples and immutability Roy Smith <roy@panix.com> - 2014-03-07 08:37 -0500
Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-08 15:17 +1300
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-07 21:17 -0700
Balanced trees (was: Re: Tuples and immutability) Marko Rauhamaa <marko@pacujo.net> - 2014-03-08 10:34 +0200
Re: Balanced trees (was: Re: Tuples and immutability) Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-08 04:03 -0700
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-08 13:26 +0200
Re: Balanced trees (was: Re: Tuples and immutability) Dan Stromberg <drsalists@gmail.com> - 2014-03-08 11:58 -0800
Re: Balanced trees Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-08 20:37 +0000
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-08 23:21 +0200
Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-08 17:22 -0500
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 11:17 +0200
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-08 17:31 -0800
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 11:27 +0200
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-09 14:20 -0700
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 23:32 +0200
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-09 14:37 -0700
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 23:43 +0200
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-09 15:08 -0700
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 00:24 +0200
Re: Balanced trees Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-09 18:04 -0600
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 03:24 +0000
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 03:24 +0000
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 08:16 +0200
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 08:53 +0000
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 11:41 +0200
Re: Balanced trees Ned Batchelder <ned@nedbatchelder.com> - 2014-03-10 06:57 -0400
Re: Balanced trees Rustom Mody <rustompmody@gmail.com> - 2014-03-10 09:01 -0700
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-11 02:02 +0000
Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-10 22:20 -0400
Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 13:29 +1100
Re: Balanced trees Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-10 09:51 +0000
Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-10 09:59 -0400
Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 03:20 +1100
Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 03:24 +1100
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 19:08 +0200
Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 04:17 +1100
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-10 19:34 +0200
Re: Balanced trees Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-13 12:40 -0600
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-13 23:57 +0000
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-13 20:12 -0700
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-14 05:02 +0000
Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-10 19:24 -0400
Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 10:27 +1100
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-11 01:26 +0000
Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 12:45 +1100
Re: Balanced trees Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-10 21:38 -0600
Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 15:28 +1100
Re: Balanced trees "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-12 00:57 +0000
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-11 12:12 +0200
Re: Balanced trees alex23 <wuwei23@gmail.com> - 2014-03-12 10:13 +1000
Re: Balanced trees Alister <alister.ware@ntlworld.com> - 2014-03-11 09:25 +0000
Re: Balanced trees Antoon Pardon <antoon.pardon@rece.vub.ac.be> - 2014-03-12 10:08 +0100
Re: Balanced trees Tim Chase <python.list@tim.thechases.com> - 2014-03-10 11:33 -0500
Re: Balanced trees Chris Angelico <rosuav@gmail.com> - 2014-03-11 03:39 +1100
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-10 18:05 -0700
Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-10 22:13 -0400
Re: Balanced trees Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-03-10 19:57 -0400
Re: Balanced trees Joshua Landau <joshua@landau.ws> - 2014-03-15 01:13 +0000
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-18 00:05 +0200
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-18 12:26 -0700
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-18 22:55 +0200
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-18 14:45 -0700
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 00:03 +0200
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-18 15:21 -0700
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 01:11 +0200
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-19 01:15 +0000
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 10:49 +0200
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-19 13:42 +0000
Re: Balanced trees Marko Rauhamaa <marko@pacujo.net> - 2014-03-19 15:54 +0200
Re: Balanced trees Roy Smith <roy@panix.com> - 2014-03-19 10:06 -0400
Re: Balanced trees Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-19 01:15 +0000
Re: Balanced trees Ethan Furman <ethan@stoneleaf.us> - 2014-03-19 08:15 -0700
Re: Balanced trees "Rhodri James" <rhodri@wildebst.org.uk> - 2014-03-20 02:16 +0000
Re: Balanced trees Dan Stromberg <drsalists@gmail.com> - 2014-03-19 19:34 -0700
Re: Balanced trees Chris Kaynor <ckaynor@zindagigames.com> - 2014-03-18 18:02 -0700
Re: Balanced trees Daniel Stutzbach <stutzbach@google.com> - 2014-03-18 13:18 -0700
blist in standard library (was Re: Balanced trees) Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-03-15 12:31 +0000
Re: Balanced trees Daniel Stutzbach <stutzbach@google.com> - 2014-03-17 14:16 -0700
Re: Balanced trees Joshua Landau <joshua@landau.ws> - 2014-03-18 00:08 +0000
Re: Balanced trees Daniel Stutzbach <stutzbach@google.com> - 2014-03-17 18:01 -0700
Re: Balanced trees Joshua Landau <joshua@landau.ws> - 2014-03-18 07:46 +0000
Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-09 13:40 +1300
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-08 19:39 -0700
Re: Tuples and immutability Marko Rauhamaa <marko@pacujo.net> - 2014-03-09 11:35 +0200
Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-10 11:03 +1300
Re: Tuples and immutability Terry Reedy <tjreedy@udel.edu> - 2014-03-09 19:00 -0400
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-09 17:42 -0600
Re: Tuples and immutability Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 02:37 +0000
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-10 02:35 -0600
Re: Tuples and immutability Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-10 09:13 +0000
Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-11 18:15 +1300
Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-11 18:03 +1300
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-11 04:39 -0600
Re: Tuples and immutability Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-11 16:46 +0000
Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-12 10:23 +1300
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-11 17:06 -0600
Re: Tuples and immutability Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-03-12 23:20 +0000
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-12 19:35 -0600
Re: Tuples and immutability Terry Reedy <tjreedy@udel.edu> - 2014-03-12 22:09 -0400
Re: Tuples and immutability Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2014-03-09 13:45 +1300
Re: Tuples and immutability Ian Kelly <ian.g.kelly@gmail.com> - 2014-03-08 19:55 -0700
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
Re: Tuples and immutability Joshua Landau <joshua@landau.ws> - 2014-03-09 17:54 +0000
Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-10 05:13 +1100
Re: Tuples and immutability Joshua Landau <joshua@landau.ws> - 2014-03-09 19:57 +0000
Re: Tuples and immutability Chris Angelico <rosuav@gmail.com> - 2014-03-10 07:06 +1100
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-03-10 02:35 -0600 |
| Message-ID | <mailman.7984.1394440586.18130.python-list@python.org> |
| In reply to | #68113 |
On Sun, Mar 9, 2014 at 8:37 PM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: > On Sun, 09 Mar 2014 17:42:42 -0600, Ian Kelly wrote: > >> On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing >> <greg.ewing@canterbury.ac.nz> wrote: > >>> Note that it says "when possible", not "if the implementation feels >>> like it". >> >> That's quite vague, and not much stronger a guarantee than "maybe". It's >> technically "possible" for this augmented assignment to be performed in >> place: >> >> x = 12 >> x += 4 >> >> But it's not done in-place, because ints are meant to be immutable. > > That's incorrect. Ints aren't merely "meant" to be immutable, which > implies that's it's optional, they are defined by the language > specification and the reference implementation as immutable. Any > interpreter where ints are mutable *is not Python*. That's true, but is beside the point, which is that "when possible" is not very meaningful. >> In any case, this means that whether the operation is actually performed >> in-place is an implementation detail -- if not of the Python >> implementation then at least of the class -- and not something the user >> should take for granted. > > Whether += operates in place or not is part of the interface of the > class, not the implementation. > > Would you say that whether list.append operates in place or creates a new > list is an implementation detail? Whether str.upper() creates a new > string or modifies the existing one in place? Of course not. list.append is documented as modifying the list. str.upper is documented as returning a copy of the string. > Mutability versus > immutability is part of the interface, not implementation, not > withstanding that somebody could create an alternative class with the > opposite behaviour: a MutableStr, or ImmutableList. If the in-place behavior of += is held to be part of the interface, then we must accept that += is not polymorphic across mutable and immutable types, which in my mind largely* defeats the purpose of having it. After all, there should be one -- and preferably only one -- obvious way to do it. If you want in-place concatenation, the obvious way to do it is by calling extend. If you want copy concatenation, the obvious way to do it is with the + operator. Why then should not just mutable sequences but immutable sequences as well even offer the += operator? * The one exception I can think of is numpy, where there is no more obvious way to do in-place addition, and in that context I would consider the in-place behavior to be part of the interface.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-03-10 09:13 +0000 |
| Message-ID | <531d8244$0$29994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #68127 |
On Mon, 10 Mar 2014 02:35:36 -0600, Ian Kelly wrote:
> On Sun, Mar 9, 2014 at 8:37 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Sun, 09 Mar 2014 17:42:42 -0600, Ian Kelly wrote:
>>
>>> On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing
>>> <greg.ewing@canterbury.ac.nz> wrote:
>>
>>>> Note that it says "when possible", not "if the implementation feels
>>>> like it".
>>>
>>> That's quite vague, and not much stronger a guarantee than "maybe".
>>> It's technically "possible" for this augmented assignment to be
>>> performed in place:
>>>
>>> x = 12
>>> x += 4
>>>
>>> But it's not done in-place, because ints are meant to be immutable.
>>
>> That's incorrect. Ints aren't merely "meant" to be immutable, which
>> implies that's it's optional, they are defined by the language
>> specification and the reference implementation as immutable. Any
>> interpreter where ints are mutable *is not Python*.
>
> That's true, but is beside the point, which is that "when possible" is
> not very meaningful.
It's meaningful. It refers not to ints, but the infinite number of
possible classes which might include augmented assignment. Some of them
will be immutable, in which case it is not possible for += etc. to be
performed in-place. Some of them will be mutable, but there won't be any
reasonable (or even unreasonable) way to perform += in-place.
But for some mutable classes, it will be possible to perform += in place,
in which case the docs say that they have to do so.
>>> In any case, this means that whether the operation is actually
>>> performed in-place is an implementation detail -- if not of the Python
>>> implementation then at least of the class -- and not something the
>>> user should take for granted.
>>
>> Whether += operates in place or not is part of the interface of the
>> class, not the implementation.
>>
>> Would you say that whether list.append operates in place or creates a
>> new list is an implementation detail? Whether str.upper() creates a new
>> string or modifies the existing one in place?
>
> Of course not. list.append is documented as modifying the list.
> str.upper is documented as returning a copy of the string.
Right. And += is documented as modifying the list too.
>> Mutability versus
>> immutability is part of the interface, not implementation, not
>> withstanding that somebody could create an alternative class with the
>> opposite behaviour: a MutableStr, or ImmutableList.
>
> If the in-place behavior of += is held to be part of the interface, then
> we must accept that += is not polymorphic across mutable and immutable
> types,
I'm fine with that.
> which in my mind largely* defeats the purpose of having it.
Not to my mind. I think that having augmented assignment is worthwhile
even if it behaves differently and incompatibly for different classes.
After all, so does * (multiplication):
py> x = 24
py> x*x
576
but:
py> x = []
py> x*x
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can't multiply sequence by non-int of type 'list'
I don't think that we ought to throw away * and I don't think we ought to
throw away *= either.
> After all, there should be one -- and preferably only one -- obvious way
> to do it. If you want in-place concatenation, the obvious way to do it
> is by calling extend. If you want copy concatenation, the obvious way
> to do it is with the + operator. Why then should not just mutable
> sequences but immutable sequences as well even offer the += operator?
*shrug*
I can see that each individual operation:
list.extend
list +
list +=
makes good sense in isolation, but I can also see that the combination
don't quite gel together as smoothly as we might hope.
--
Steven D'Aprano
http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-03-11 18:15 +1300 |
| Message-ID | <bo7kfnFsehvU1@mid.individual.net> |
| In reply to | #68127 |
Ian Kelly wrote: > If the in-place behavior of += is held to be part of the interface, > then we must accept that += is not polymorphic across mutable and > immutable types, That's quite correct, it's not. As I said, it's one notation doing double duty. Usually there isn't any confusion, because you know whether any particular instance of it is intended to operate on a mutable or immutable type. If that's not the case -- if you're writing a function intended to operate on a variety of types, some mutable and some not -- then using in-place operators would not be appropriate. > If you want in-place concatenation, the > obvious way to do it is by calling extend. It might be the obvious way for that particular operation on that particular type. But what about all the others? What's the obvious way to spell in-place set intersection, for example? (Quickly -- no peeking at the docs!) The in-place operators provide a standardised spelling for in-place versions of all the binary operations. That's a useful thing to have, I think. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-03-11 18:03 +1300 |
| Message-ID | <bo7jo9Fsaf1U1@mid.individual.net> |
| In reply to | #68107 |
Ian Kelly wrote: > It's technically "possible" for this augmented assignment to be > performed in place: > > x = 12 > x += 4 > > But it's not done in-place, because ints are meant to be immutable. Which means it's *not* possible, because doing so would violate the documented properties of the int type. > In any case, this means that whether the operation is actually > performed in-place is an implementation detail The implementation could theoretically perform this optimisation if there are no other references to the object. But this will be completely invisible, because to even find out whether it's the same object, you need to keep another reference to the original object, preventing the optimisation from being performed. As far as observable effects are concerned, it's quite clear: mutable objects can *always* be updated in-place, and immutable objects can *never* be. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-03-11 04:39 -0600 |
| Message-ID | <mailman.8040.1394534428.18130.python-list@python.org> |
| In reply to | #68196 |
On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > As far as observable effects are concerned, it's > quite clear: mutable objects can *always* be updated > in-place, and immutable objects can *never* be. Hm. Consider the circle-ellipse problem. Briefly, a circle is-an ellipse, so in an inheritance hierarchy it is natural to make Circle a subclass of Ellipse. Now suppose the Ellipse has a stretch method that mutates the ellipse by changing the length of one of its axes while preserving the other. To avoid violating LSP, the Circle class must support all the methods of its ancestor. However it cannot, because the stretch method would invalidate the invariant of the Circle class that both of its axes must always be equal. There are a number of possible solutions. One possibility would be to copy the Circle as an Ellipse and return the new object instead of mutating it. Then you have the situation where, given a mutable object x that satisfies isinstance(x, Ellipse), the stretch method *may* be able to update the object in-place, or it *may* not. I can't think of a reasonable example that would replace the stretch method here with an augmented assignment, but then it is rather late. > It might be the obvious way for that particular operation on > that particular type. But what about all the others? > What's the obvious way to spell in-place set intersection, > for example? (Quickly -- no peeking at the docs!) You mean set.intersection_update? The in-place set methods are not hard to remember, because they all end in _update.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-03-11 16:46 +0000 |
| Message-ID | <531f3dfb$0$29994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #68208 |
On Tue, 11 Mar 2014 04:39:39 -0600, Ian Kelly wrote:
> On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing
> <greg.ewing@canterbury.ac.nz> wrote:
>> As far as observable effects are concerned, it's quite clear: mutable
>> objects can *always* be updated in-place, and immutable objects can
>> *never* be.
>
> Hm. Consider the circle-ellipse problem.
Oh, not that old chestnut! The circle-ellipse problem demonstrates one
limitation of OOP (specifically "subtype polymorphism"), as well as a
general difficulty with hierarchical taxonomies. Mammals have hair --
what do you make of hairless[1] dolphins? Circle/Ellipse is not a good
place to start from in order to critic augmented assignment in Python.
You're starting from a place where inheritance itself is problematic, so
naturally you're going to find problems.
> Briefly, a circle is-an ellipse, so in an inheritance hierarchy it is
> natural to make Circle a subclass of Ellipse.
Natural and wrong. It's only natural if you don't think through the
consequences. As you go on to say:
> Now suppose the Ellipse has a stretch method that
> mutates the ellipse by changing the length of one of its axes while
> preserving the other. To avoid violating LSP, the Circle class must
> support all the methods of its ancestor. However it cannot, because the
> stretch method would invalidate the invariant of the Circle class that
> both of its axes must always be equal.
Right. So *Circles cannot be Ellipses*, not without violating the Liskov
Substitution Principle. If I think that they are, I haven't thought it
through. Nor can Ellipses be Circles. That's the problem of the Circle/
Ellipse relationship.
(Aside: the LSP is not a Law Of Physics that cannot be touched. There are
other OOP models that don't require LSP.)
Even in the case of immutable shapes, one might not wish to inherit
Circle from Ellipsis. Ellipses have five degrees of freedom:
2 x position
size (scale)
orientation
shape
while circles only have three:
2 x position
size
Orientation and shape are meaningless for circles! So they should not
inherit from a class where they are meaningful: given the LSP, a subclass
cannot be more restrictive than a superclass.
> There are a number of possible solutions. One possibility would be to
> copy the Circle as an Ellipse and return the new object instead of
> mutating it. Then you have the situation where, given a mutable object
> x that satisfies isinstance(x, Ellipse), the stretch method *may* be
> able to update the object in-place, or it *may* not.
That is a really lousy design. Of course we are free to create classes
with ugly, inconsistent, stupid or unworkable APIs if we like. Python
won't stop us:
class MyList(list):
def append(self, obj):
if len(self) % 17 == 3:
return self + [obj]
super(MyList, self).append(obj)
> I can't think of a reasonable example that would replace the stretch
> method here with an augmented assignment, but then it is rather late.
>
>> It might be the obvious way for that particular operation on that
>> particular type.
Um, yes? Nobody suggests that a method of type X has to be the most
obvious way for *any operation* on *any type*. What's your point?
> But what about all the others? What's the obvious way
>> to spell in-place set intersection, for example?
I would expect it to be &=, let's find out if I'm right:
py> a = set("abcde")
py> b = a # save a reference to it
py> c = set("cdefg")
py> a &= c
py> a, b
({'c', 'd', 'e'}, {'c', 'd', 'e'})
py> a is b
True
>> (Quickly -- no peeking at the docs!)
The only reason I'd need to look at the docs is because I always forget
whether & is intersection and | is union, or the other way around. But
having remembered which is which, going from & to &= was easy.
> You mean set.intersection_update? The in-place set methods are not hard
> to remember, because they all end in _update.
And hard to spell.
[1] Technically they aren't *entirely* hairless. They may have a few
hairs around the blowhole, and baby dolphins are born with whiskers which
they soon lose. But from a functional perspective, they are hairless.
--
Steven D'Aprano
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-03-12 10:23 +1300 |
| Message-ID | <bo9d69F9vf6U1@mid.individual.net> |
| In reply to | #68226 |
Steven D'Aprano wrote: > On Tue, 11 Mar 2014 04:39:39 -0600, Ian Kelly wrote: > >>On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing > >>What's the obvious way >>>to spell in-place set intersection, for example? > > I would expect it to be &=, That's my point -- once you know the binary operator for an operation, the corresponding in-place operator is obvious. But there's no established standard set of method names for in-place operations -- each type does its own thing. >>You mean set.intersection_update? The in-place set methods are not hard >>to remember, because they all end in _update. For that particular type, maybe, but I wouldn't trust that rule to extend to other types. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-03-11 17:06 -0600 |
| Message-ID | <mailman.8066.1394579251.18130.python-list@python.org> |
| In reply to | #68226 |
On Tue, Mar 11, 2014 at 10:46 AM, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote: >> There are a number of possible solutions. One possibility would be to >> copy the Circle as an Ellipse and return the new object instead of >> mutating it. Then you have the situation where, given a mutable object >> x that satisfies isinstance(x, Ellipse), the stretch method *may* be >> able to update the object in-place, or it *may* not. > > That is a really lousy design. Of course we are free to create classes > with ugly, inconsistent, stupid or unworkable APIs if we like. Python > won't stop us: That's true but irrelevant to my point, which was to counter the assertion that mutable types can always be assumed to be able to perform operations in-place.
[toc] | [prev] | [next] | [standalone]
| From | Steven D'Aprano <steve+comp.lang.python@pearwood.info> |
|---|---|
| Date | 2014-03-12 23:20 +0000 |
| Message-ID | <5320ebce$0$29994$c3e8da3$5496439d@news.astraweb.com> |
| In reply to | #68248 |
On Tue, 11 Mar 2014 17:06:43 -0600, Ian Kelly wrote: > On Tue, Mar 11, 2014 at 10:46 AM, Steven D'Aprano > <steve+comp.lang.python@pearwood.info> wrote: >>> There are a number of possible solutions. One possibility would be to >>> copy the Circle as an Ellipse and return the new object instead of >>> mutating it. Then you have the situation where, given a mutable object >>> x that satisfies isinstance(x, Ellipse), the stretch method *may* be >>> able to update the object in-place, or it *may* not. >> >> That is a really lousy design. Of course we are free to create classes >> with ugly, inconsistent, stupid or unworkable APIs if we like. Python >> won't stop us: > > That's true but irrelevant to my point, which was to counter the > assertion that mutable types can always be assumed to be able to perform > operations in-place. "Always"? Not so fast. This is Python. We have freedom to abuse nearly everything, and if you want to shoot yourself in the foot, you can. With the exception of a handful of things which cannot be overridden (e.g. None, numeric literals, syntax) you cannot strictly assume anything about anything. Python does not enforce that iterators raise StopIteration when empty, or that indexing beyond the boundaries of a sequence raises IndexError, or that __setitem__ of a mapping sets the key and value, or that __len__ returns a length. Augmented assignment is no different. The docs describe the intention of the designers and the behaviour of the classes that they control, so with standard built-in classes like int, str, list, tuple etc. you can safely assume that mutable types will perform the operation in place and immutable types won't, but with arbitrary types from some arbitrarily eccentric or twisted programmer, who knows what it will do? -- Steven D'Aprano http://import-that.dreamwidth.org/
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-03-12 19:35 -0600 |
| Message-ID | <mailman.8118.1394674579.18130.python-list@python.org> |
| In reply to | #68312 |
On Wed, Mar 12, 2014 at 5:20 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Tue, 11 Mar 2014 17:06:43 -0600, Ian Kelly wrote:
>
>> That's true but irrelevant to my point, which was to counter the
>> assertion that mutable types can always be assumed to be able to perform
>> operations in-place.
>
> "Always"? Not so fast.
>
> This is Python. We have freedom to abuse nearly everything, and if you
> want to shoot yourself in the foot, you can. With the exception of a
> handful of things which cannot be overridden (e.g. None, numeric
> literals, syntax) you cannot strictly assume anything about anything.
> Python does not enforce that iterators raise StopIteration when empty, or
> that indexing beyond the boundaries of a sequence raises IndexError, or
> that __setitem__ of a mapping sets the key and value, or that __len__
> returns a length.
Thank you; you've stated my point more succinctly than I did.
> Augmented assignment is no different. The docs describe the intention of
> the designers and the behaviour of the classes that they control, so with
> standard built-in classes like int, str, list, tuple etc. you can safely
> assume that mutable types will perform the operation in place and
> immutable types won't, but with arbitrary types from some arbitrarily
> eccentric or twisted programmer, who knows what it will do?
This got me curious about how consistent the standard library is about
this exactly, so I did some grepping. In the standard library there
are 5 mutable types that support concatenation that I was able to
find: list, deque, array, bytearray, and Counter. There are none that
support addition, which I find interesting in that the language
provides hooks for in-place addition but never uses them itself.
All of the classes above appear to follow the rule that if you can
concatenate an operand, you can in-place concatenate the same operand.
The converse however does not hold: list.__iadd__ and
Counter.__iadd__ are both more permissive in what types they will
accept than their __add__ counterparts, and especially interesting to
me is that deque implements __iadd__ but does not implement __add__ at
all. This last in particular seems to support the assertion that +=
should be viewed more as a shorthand for an in-place operation, less
as an equivalent for x = x + y.
>>> l = [1,2,3]
>>> l + (4,5,6)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: can only concatenate list (not "tuple") to list
>>> l += (4,5,6)
>>> l
[1, 2, 3, 4, 5, 6]
>>> c = collections.Counter('mississippi')
>>> c + collections.Counter('alabama')
Counter({'s': 4, 'a': 4, 'i': 4, 'p': 2, 'm': 2, 'b': 1, 'l': 1})
>>> c + dict({'a': 4, 'l': 1, 'b': 1, 'm': 1})
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'Counter' and 'dict'
>>> c += dict({'a': 4, 'l': 1, 'b': 1, 'm': 1})
>>> c
Counter({'s': 4, 'a': 4, 'i': 4, 'p': 2, 'm': 2, 'b': 1, 'l': 1})
>>> d = collections.deque([1,2,3])
>>> d += [4,5,6]
>>> d
deque([1, 2, 3, 4, 5, 6])
>>> d + [7,8,9]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'collections.deque' and 'list'
>>> d.__add__
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'collections.deque' object has no attribute '__add__'
[toc] | [prev] | [next] | [standalone]
| From | Terry Reedy <tjreedy@udel.edu> |
|---|---|
| Date | 2014-03-12 22:09 -0400 |
| Message-ID | <mailman.8119.1394676599.18130.python-list@python.org> |
| In reply to | #68312 |
On 3/12/2014 9:35 PM, Ian Kelly wrote:
> On Wed, Mar 12, 2014 at 5:20 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Tue, 11 Mar 2014 17:06:43 -0600, Ian Kelly wrote:
>>
>>> That's true but irrelevant to my point, which was to counter the
>>> assertion that mutable types can always be assumed to be able to perform
>>> operations in-place.
>>
>> "Always"? Not so fast.
>>
>> This is Python. We have freedom to abuse nearly everything, and if you
>> want to shoot yourself in the foot, you can. With the exception of a
>> handful of things which cannot be overridden (e.g. None, numeric
>> literals, syntax) you cannot strictly assume anything about anything.
>> Python does not enforce that iterators raise StopIteration when empty, or
>> that indexing beyond the boundaries of a sequence raises IndexError, or
>> that __setitem__ of a mapping sets the key and value, or that __len__
>> returns a length.
>
> Thank you; you've stated my point more succinctly than I did.
>
>> Augmented assignment is no different. The docs describe the intention of
>> the designers and the behaviour of the classes that they control, so with
>> standard built-in classes like int, str, list, tuple etc. you can safely
>> assume that mutable types will perform the operation in place and
>> immutable types won't, but with arbitrary types from some arbitrarily
>> eccentric or twisted programmer, who knows what it will do?
>
> This got me curious about how consistent the standard library is about
> this exactly, so I did some grepping. In the standard library there
> are 5 mutable types that support concatenation that I was able to
> find: list, deque, array, bytearray, and Counter. There are none that
> support addition, which I find interesting in that the language
> provides hooks for in-place addition but never uses them itself.
>
> All of the classes above appear to follow the rule that if you can
> concatenate an operand, you can in-place concatenate the same operand.
> The converse however does not hold: list.__iadd__ and
> Counter.__iadd__ are both more permissive in what types they will
> accept than their __add__ counterparts, and especially interesting to
> me is that deque implements __iadd__ but does not implement __add__ at
> all. This last in particular seems to support the assertion that +=
> should be viewed more as a shorthand for an in-place operation, less
> as an equivalent for x = x + y.
>
>>>> l = [1,2,3]
>>>> l + (4,5,6)
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: can only concatenate list (not "tuple") to list
>>>> l += (4,5,6)
>>>> l
> [1, 2, 3, 4, 5, 6]
Like it or not, one should actually think of 'somelist += iterable' as
equivalent to 'somelist.extend(iterable)'. Without looking at the C
code, I suspect that the latter is the internal implementation.
Collections.deque also has .extend. Collections.Counter has .update and
that is += seems to be doing.
>>>> c = collections.Counter('mississippi')
>>>> c + collections.Counter('alabama')
> Counter({'s': 4, 'a': 4, 'i': 4, 'p': 2, 'm': 2, 'b': 1, 'l': 1})
>>>> c + dict({'a': 4, 'l': 1, 'b': 1, 'm': 1})
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for +: 'Counter' and 'dict'
>>>> c += dict({'a': 4, 'l': 1, 'b': 1, 'm': 1})
>>>> c
> Counter({'s': 4, 'a': 4, 'i': 4, 'p': 2, 'm': 2, 'b': 1, 'l': 1})
>
>>>> d = collections.deque([1,2,3])
>>>> d += [4,5,6]
>>>> d
> deque([1, 2, 3, 4, 5, 6])
>>>> d + [7,8,9]
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> TypeError: unsupported operand type(s) for +: 'collections.deque' and 'list'
>>>> d.__add__
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> AttributeError: 'collections.deque' object has no attribute '__add__'
>
--
Terry Jan Reedy
[toc] | [prev] | [next] | [standalone]
| From | Gregory Ewing <greg.ewing@canterbury.ac.nz> |
|---|---|
| Date | 2014-03-09 13:45 +1300 |
| Message-ID | <bo1rseFlmgoU1@mid.individual.net> |
| In reply to | #68023 |
Ian Kelly wrote: > I already mentioned this earlier in the thread, but a balanced binary > tree might implement += as node insertion and then return a different > object if the balancing causes the root node to change. That would be a really bad way to design a binary tree implementation. What if there is another reference to the tree somewhere? It's still going to be referring to the old root object, and will have an incoherent view of the data -- partly old and partly new. If you're going to have a mutable tree, it needs to be encapsulated in a stable top-level object. -- Greg
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-03-08 19:55 -0700 |
| Message-ID | <mailman.7946.1394333769.18130.python-list@python.org> |
| In reply to | #68056 |
On Sat, Mar 8, 2014 at 5:45 PM, Gregory Ewing <greg.ewing@canterbury.ac.nz> wrote: > Ian Kelly wrote: > >> I already mentioned this earlier in the thread, but a balanced binary >> tree might implement += as node insertion and then return a different >> object if the balancing causes the root node to change. > > > That would be a really bad way to design a binary tree > implementation. What if there is another reference to > the tree somewhere? It's still going to be referring to > the old root object, and will have an incoherent view > of the data -- partly old and partly new. > > If you're going to have a mutable tree, it needs to be > encapsulated in a stable top-level object. Well, as I parenthetically noted the first time I brought it up, "whether this is good design is tangential; it's a possible design". The language shouldn't be written such that only those designs deemed "good" by some external committee can be implemented. What you dismiss as "really bad" may be exactly what somebody else needs, and maybe they intend that there won't be other references.
[toc] | [prev] | [next] | [standalone]
| From | "Mark H. Harris" <harrismh777@gmail.com> |
|---|---|
| Date | 2014-02-28 16:22 -0800 |
| Message-ID | <059a3d10-453a-40fd-99f9-33ceb8ecabf7@googlegroups.com> |
| In reply to | #67151 |
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]
| From | Eric Jacoboni <eric.jacoboni@gmail.com> |
|---|---|
| Date | 2014-03-01 02:27 +0100 |
| Message-ID | <lerd1m$311j$1@cabale.usenet-fr.net> |
| In reply to | #67260 |
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]
| From | "Mark H. Harris" <harrismh777@gmail.com> |
|---|---|
| Date | 2014-02-28 20:45 -0800 |
| Message-ID | <2ddad91d-e188-4fd0-be1c-ed30edbf280b@googlegroups.com> |
| In reply to | #67275 |
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]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-28 22:34 -0700 |
| Message-ID | <mailman.7501.1393652140.18130.python-list@python.org> |
| In reply to | #67290 |
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]
| From | "Mark H. Harris" <harrismh777@gmail.com> |
|---|---|
| Date | 2014-02-28 21:50 -0800 |
| Message-ID | <2c38b941-9f3f-485f-9e97-525f28c5453a@googlegroups.com> |
| In reply to | #67294 |
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]
| From | Ned Batchelder <ned@nedbatchelder.com> |
|---|---|
| Date | 2014-03-01 12:56 -0500 |
| Message-ID | <mailman.7521.1393696597.18130.python-list@python.org> |
| In reply to | #67295 |
On 3/1/14 12:50 AM, Mark H. Harris wrote: > 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 > Everyone can agree that it is not great to raise an exception and also leave the list modified. But I very much doubt that anything will be done to change the situation. All of the solutions are too extreme, and bring their own infelicities, and the actual problems caused by this scenario are vanishingly small. BTW: I also am mystified why you uses ellipses to end your sentences, surely one period would be enough? :) -- Ned Batchelder, http://nedbatchelder.com
[toc] | [prev] | [next] | [standalone]
| From | Ian Kelly <ian.g.kelly@gmail.com> |
|---|---|
| Date | 2014-02-28 22:26 -0700 |
| Message-ID | <mailman.7500.1393651610.18130.python-list@python.org> |
| In reply to | #67275 |
On Fri, Feb 28, 2014 at 6:27 PM, Eric Jacoboni <eric.jacoboni@gmail.com> wrote: > Anyway, the TypeError should rollback, not commit the mistake. The Python interpreter isn't a database. It can't rollback the object because the operation that was performed may not be reversible. Consider for example a socket class where the += operator is overloaded to send a message on the socket. The message can't be unsent.
[toc] | [prev] | [next] | [standalone]
Page 7 of 9 — ← Prev page 1 2 3 4 5 6 [7] 8 9 Next page →
Back to top | Article view | comp.lang.python
csiph-web