e, but
further attributes can be dynamically-added to the object-instance!
Yes, if the code included:
coordinates = Coordinates( 5, 6, )
the new "coordinates" identifier would point to a different id()
'address', ie a fresh immutable-instance.
The 'book of word
On 2023-04-12, Roel Schroeven wrote:
>> Huh? If we'd been discussing namedtuples over (say) dictionaries, I'd
>> perhaps have accepted the reply.
>
> ChatGPT is wrong.
>
>> Anything I've 'missed'?
>> - or a salutary tale of not depending upon ChatGPT etc?
> You didn't miss anything, ChatGPT is
Op 12/04/2023 om 6:58 schreef dn via Python-list:
Are dataclasses (or instances thereof) mutable or immutable?
- and in what sense?
Instances of dataclasses are mutable, just like normal classes.
Dataclasses *are* normal classes, with some extra special methods. They
are totally different from
output:
Commencing execution
Coordinates(x=1, y=2) 140436963150928
Coordinates(x=3, y=2) 140436963150928
Coordinates(x=3, y=2) 140436963150928
3 2 4
Terminating
###
Not only are a dataclass instance's attribute-values mutable, but
further attributes can be dynamically-added to the obje
On Wed, Jan 29, 2020 at 1:50 AM Random832 wrote:
>
> On Wed, Jan 22, 2020, at 02:34, Stephen Tucker wrote:
> > Oh dear, I am sorry. I have created quite a storm.
> >
> > Moreover, I am sorry because I misremembered what I had typed into Idle. My
> > original tuple only had two elements, not three,
On Wed, Jan 22, 2020, at 02:34, Stephen Tucker wrote:
> Oh dear, I am sorry. I have created quite a storm.
>
> Moreover, I am sorry because I misremembered what I had typed into Idle. My
> original tuple only had two elements, not three, so the slicing [:2] didn't
> affect the tuple at all - and s
On Tue, Jan 28, 2020 at 9:33 PM Daniel Haude wrote:
>
> Am 27.01.2020 15:23 schrieb Chris Angelico:
>
> > The way execution works in Python, you first evaluate the object, then
> > assign it to the target. The new object HAS to exist before the old
> > one is replaced. There's no such thing as "at
Am 27.01.2020 15:23 schrieb Chris Angelico:
The way execution works in Python, you first evaluate the object, then
assign it to the target. The new object HAS to exist before the old
one is replaced. There's no such thing as "atomic reassignment" that
simultaneously destroys the old object and a
On Tue, Jan 28, 2020 at 2:44 AM Souvik Dutta wrote:
>
> If the two objects have the same value that means that when called all of
> them will point to the same object rather than creating the same value -
> object pairs twice. Immutability is the characteristics that does not let y
On Tue, Jan 28, 2020 at 1:13 AM Musbur wrote:
>
> Am 21.01.2020 19:38 schrieb Chris Angelico:
> > Are you sure that it does? I can't reproduce this. When you slice the
> > first two from a tuple, you create a new tuple, and until the
> > assignment happens, both the new one and the original coexis
Am 21.01.2020 19:38 schrieb Chris Angelico:
On Wed, Jan 22, 2020 at 4:42 AM Stephen Tucker
wrote:
and even that the first id(mytup) returns the same address as the
second
one, I am left wondering exactly what immutability is.
Let's look at id()'s documentation:
id(object)
On 1/21/20 8:41 PM, Jon Ribbens via Python-list wrote:
Whether we call the link between 'foo' and (1, 2) a pointer or a
reference is almost entirely irrelevant, the difference is essentially
meaningless.
The issue is that in Python, objects and names are fairly distinct.
Unlike a language like
On 1/21/20, Jon Ribbens via Python-list wrote:
>
> Whether we call the link between 'foo' and (1, 2) a pointer or a
> reference is almost entirely irrelevant, the difference is essentially
> meaningless.
In programming terms, a "pointer" is always an address in memory, and,
at least to me, the te
Oh dear, I am sorry. I have created quite a storm.
Moreover, I am sorry because I misremembered what I had typed into Idle. My
original tuple only had two elements, not three, so the slicing [:2] didn't
affect the tuple at all - and so the second id() gave the same address as
the first one.
So, y
On 1/21/20 6:52 PM, Ethan Furman wrote:
> On 01/21/2020 10:55 AM, Michael Torrie wrote:
>
>> Slicing
>> returns a new object whether one is slicing a tuple, list, or a string,
>> the latter two are mutable objects.
>
> Strings are not mutable.
Yup I got my items in the wrong order. I meant to sa
On 2020-01-22 01:52, Ethan Furman wrote:
On 01/21/2020 10:55 AM, Michael Torrie wrote:
Slicing
returns a new object whether one is slicing a tuple, list, or a string,
the latter two are mutable objects.
Strings are not mutable.
In the case of tuples and strings, if the slicing encompasses th
On 01/21/2020 10:55 AM, Michael Torrie wrote:
Slicing
returns a new object whether one is slicing a tuple, list, or a string,
the latter two are mutable objects.
Strings are not mutable.
--
~Ethan~
--
https://mail.python.org/mailman/listinfo/python-list
On 2020-01-21, Chris Angelico wrote:
> On Wed, Jan 22, 2020 at 8:01 AM Jon Ribbens via Python-list
> wrote:
>> On 2020-01-21, Chris Angelico wrote:
>> > On Wed, Jan 22, 2020 at 4:42 AM Stephen Tucker
>> > wrote:
>> >> I am left concluding that mytup is not actually a tuple (even though type
>>
On 22Jan2020 09:15, Cameron Simpson wrote:
It doesn't say anything about the contents of the internal objects:
>>> mytup = (1, [2, 3], (4, 5))
[...]
>>> mytupl[1] = [7, 8]
Traceback (most recent call last):
File "", line 1, in
NameError: name 'mytupl' is not defined
Please igno
ht", "credits" or "license" for more information.
>>> mytup = ("q", "w", "e")
>>> id(mytup)
4541315104
>>> mytup = mytup [:2]
>>> id(mytup)
4542334880
>>>
I am left wondering exactly what
On Wed, Jan 22, 2020 at 8:01 AM Jon Ribbens via Python-list
wrote:
>
> On 2020-01-21, Chris Angelico wrote:
> > On Wed, Jan 22, 2020 at 4:42 AM Stephen Tucker
> > wrote:
> >> I am left concluding that mytup is not actually a tuple (even though type
> >> (mytup) tells me that it is).
> >
> > If
On 2020-01-21, Chris Angelico wrote:
> On Wed, Jan 22, 2020 at 4:42 AM Stephen Tucker wrote:
>> I am left concluding that mytup is not actually a tuple (even though type
>> (mytup) tells me that it is).
>
> If type(mytup) is tuple, then mytup really truly is a tuple. There is
> no other conclusio
ens, both the new one and the original coexist, which
> > means they MUST have unique IDs.
>
> And furthermore this has nothing to do with immutability. Slicing
> returns a new object whether one is slicing a tuple, list, or a string,
> the latter two are mutable objects.
True, but th
unique IDs.
And furthermore this has nothing to do with immutability. Slicing
returns a new object whether one is slicing a tuple, list, or a string,
the latter two are mutable objects.
--
https://mail.python.org/mailman/listinfo/python-list
", "w", "e")
> id(mytup)
> mytup = mytup [:2]
> id(mytup)
>
> and even that the first id(mytup) returns the same address as the second
> one, I am left wondering exactly what immutability is.
Are you sure that it does? I can't reproduce this. When you sl
rst id(mytup) returns the same address as the second
one, I am left wondering exactly what immutability is.
I am left concluding that mytup is not actually a tuple (even though type
(mytup) tells me that it is).
My only explanation is that mytup is, actually, a pointer to a tuple; the
pointer can
On Thu, Apr 18, 2019 at 6:16 PM Gregory Ewing
wrote:
>
> Arup Rakshit wrote:
> > What protocols I need to
> > learn, to define a custom immutable class ?
>
> That depends on how strictly you want to enforce immutability.
>
> The easiest thing is not to enforce it at
Arup Rakshit wrote:
What protocols I need to
learn, to define a custom immutable class ?
That depends on how strictly you want to enforce immutability.
The easiest thing is not to enforce it at all and simply refrain
from mutating it. This is very often done.
You can provide some protection
Hi All,
Thanks for explaining it so nice way. I got it now. What protocols I need to
learn, to define a custom immutable class ?
Thanks,
Arup Rakshit
a...@zeit.io
> On 16-Apr-2019, at 10:54 PM, Dennis Lee Bieber wrote:
>
> On Tue, 16 Apr 2019 13:13:18 +0530, Arup Rakshit declaimed the
>
hat contains a reference to a mutable object can change when the latter’s
> > value is changed; however the container is still considered immutable,
> > because the collection of objects it contains cannot be changed. So,
> > immutability is not strictly the same as having an unch
tainer is still considered immutable, because the collection
> of objects it contains cannot be changed. So, immutability is not strictly
> the same as having an unchangeable value, it is more subtle.) An object’s
> mutability is determined by its type; for instance, numbers, strings and
czw., 22 lis 2018 o 11:14 Thomas Jollans napisał(a):
> [..] this allows other classes' __init__s to set attributes.
Fair point.
> I might try setting a self._fixed flag at the end of init and do a check
>
> if getattr(self, '_fixed', False):
> raise TypeError(f"'{type(self)}' is immutable")
On 2018-11-21 17:45, Iwo Herka wrote:
> Hello,
>
> Let's say I want to implement immutability for user-defined class.
> More precisely, a class that can be modified only in its (or its
> super-class') __init__ method. My initial idea was to do it the
> following fashi
czw., 22 lis 2018 o 10:53 Thomas Jollans napisał(a):
> If you're tempted to go down that route and can require Python 3.7, use
> dataclasses!
I'm aware of them, thanks. :) Dataclasses are great for certain use-cases;
I was just wondering how hard would it be to implement something
approximating g
gt;> Hello,
>>
>> Let's say I want to implement immutability for user-defined class.
>> More precisely, a class that can be modified only in its (or its
>> super-class') __init__ method. My initial idea was to do it the
>> following fashion:
>>
>
Dan Sommers <2qdxy4rzwzuui...@potatochowder.com> wrote:
> If an instance of your class contains a list, and you change one
> of the elements of that list, then the instance's __setattr__
> never comes into play:
I think that's within the bounds of what is understood as
"immutable" in Python. Tuple
Iwo Herka writes:
> Let's say I want to implement immutability for user-defined class.
> More precisely, a class that can be modified only in its (or its
> super-class') __init__ method. My initial idea was to do it the
> following fashion:
>
> def __set
If you want to create your own immutable class, maybe inherit from a
namedtuple?
On Wed, Nov 21, 2018 at 11:45 AM Iwo Herka wrote:
> Hello,
>
> Let's say I want to implement immutability for user-defined class.
> More precisely, a class that can be modified only in its (or
On 11/21/18 11:45 AM, Iwo Herka wrote:
Hello,
Let's say I want to implement immutability for user-defined class.
More precisely, a class that can be modified only in its (or its
super-class') __init__ method. My initial idea was to do it the
following fashion:
def __setattr__(s
Hello,
Let's say I want to implement immutability for user-defined class.
More precisely, a class that can be modified only in its (or its
super-class') __init__ method. My initial idea was to do it the
following fashion:
def __setattr__(self, *args, **kwargs):
if sys._
On Fri, Nov 25, 2016, at 06:33, Ned Batchelder wrote:
> A Python implementation can choose when to reuse immutable objects and
> when not to. Reusing a value has a cost, because the values have to
> be kept, and then found again. So the cost is only paid when there's
> a reasonable chance that the
On Fri, 25 Nov 2016 10:37 pm, Ned Batchelder wrote:
> And: floats are rarely checked for equality, and very very very rarely
> used as dict keys, so there's no gain by short-circuiting the equality
> check.
You cannot short-circuit the equality check, at least not without giving up
IEEE-754 seman
On Friday, November 25, 2016 at 7:17:08 AM UTC-5, BartC wrote:
> On 25/11/2016 11:24, Nikunj wrote:
> >
> > Out of curiosity, I wanted to understand the reason behind having different
> > memory location for two identical floats . This is unlike ints or strings.
> > Tried googling but couldn't fi
On 25/11/2016 11:24, Nikunj wrote:
Out of curiosity, I wanted to understand the reason behind having different
memory location for two identical floats . This is unlike ints or strings.
Tried googling but couldn't find anything concrete. Any links or references
would be appreciated!
Do you
On Friday, November 25, 2016 at 6:34:00 AM UTC-5, Ned Batchelder wrote:
> On Friday, November 25, 2016 at 6:24:47 AM UTC-5, Nikunj wrote:
> > Hi All,
> >
> > Out of curiosity, I wanted to understand the reason behind having different
> > memory location for two identical floats . This is unlike i
On Friday, November 25, 2016 at 6:24:47 AM UTC-5, Nikunj wrote:
> Hi All,
>
> Out of curiosity, I wanted to understand the reason behind having different
> memory location for two identical floats . This is unlike ints or strings.
> Tried googling but couldn't find anything concrete. Any links o
Hi All,
Out of curiosity, I wanted to understand the reason behind having different
memory location for two identical floats . This is unlike ints or strings.
Tried googling but couldn't find anything concrete. Any links or references
would be appreciated!
Example:
For FLOATS:
==
>>>
On 3/12/2014 9:35 PM, Ian Kelly wrote:
On Wed, Mar 12, 2014 at 5:20 PM, Steven D'Aprano
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
operati
On Wed, Mar 12, 2014 at 5:20 PM, Steven D'Aprano
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
On Tue, 11 Mar 2014 17:06:43 -0600, Ian Kelly wrote:
> On Tue, Mar 11, 2014 at 10:46 AM, Steven D'Aprano
> 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 si
Op 12-03-14 10:51, Ian Kelly schreef:
> On Wed, Mar 12, 2014 at 3:39 AM, Antoon Pardon
> wrote:
>> The documentation is wrong at that point as the following code illustrates.
> Either way it still has to do a getitem and a setitem, but if you have
> a more nested structure then the extra getitems
On 12 March 2014 03:25, Terry Reedy wrote:
> On 3/11/2014 10:01 PM, Rick Johnson wrote:
>>
>>
>> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
>>>
>>> x += y is meant to be equivalent, except possibly in-place and
>>> more efficient, than x = x + y.
>
>
> The manual actually says "An
On Wed, Mar 12, 2014 at 3:39 AM, Antoon Pardon
wrote:
> The documentation is wrong at that point as the following code illustrates.
Either way it still has to do a getitem and a setitem, but if you have
a more nested structure then the extra getitems are not repeated. For
example, using your log
On Wed, Mar 12, 2014 at 12:28 AM, Steven D'Aprano wrote:
> On Tue, 11 Mar 2014 23:25:19 -0400, Terry Reedy wrote:
>> Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once
>> and possibly allocating a new object versus not take extra time. In a
>> statement like "x.y.z[3*n+m] += 1
Op 12-03-14 07:28, Steven D'Aprano schreef:
> On Tue, 11 Mar 2014 23:25:19 -0400, Terry Reedy wrote:
>
>> Nope, 'similar' is not 'equivalent'. Evaluating x twice instead of once
>> and possibly allocating a new object versus not take extra time. In a
>> statement like "x.y.z[3*n+m] += 1", calculati
On 03/11/2014 08:25 PM, Terry Reedy wrote:
On 3/11/2014 10:01 PM, Rick Johnson wrote:
On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
x += y is meant to be equivalent, except possibly in-place and
more efficient, than x = x + y.
The manual actually says "An augmented assignment e
On Tue, 11 Mar 2014 23:25:19 -0400, Terry Reedy wrote:
> On 3/11/2014 10:01 PM, Rick Johnson wrote:
>>
>> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
>>> x += y is meant to be equivalent, except possibly in-place and more
>>> efficient, than x = x + y.
>
> The manual actually says
On 3/11/2014 10:01 PM, Rick Johnson wrote:
On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
x += y is meant to be equivalent, except possibly in-place and
more efficient, than x = x + y.
The manual actually says "An augmented assignment expression like x += 1
can be rewritten as x
On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
> x += y is meant to be equivalent, except possibly in-place and more
> efficient, than x = x + y.
In an ideal world, the speed of these two codes should be the same, of course
i'm "assuming" that most competent language designers wou
On Wed, Mar 12, 2014 at 1:01 PM, Rick Johnson
wrote:
> On Thursday, February 27, 2014 4:18:01 PM UTC-6, Ian wrote:
>> x += y is meant to be equivalent, except possibly in-place and more
>> efficient, than x = x + y.
>
> In an ideal world, the speed of these two codes should be the same, of course
On Tue, Mar 11, 2014 at 10:46 AM, Steven D'Aprano
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 isi
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 op
On Tue, 11 Mar 2014 04:39:39 -0600, Ian Kelly wrote:
> On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing
> 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 circ
On Mon, Mar 10, 2014 at 11:03 PM, Gregory Ewing
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 in
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
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.
I
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 no
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 stri
u 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? Mutability versus
immutability is part of the interface, not implementation, not
withstanding that
On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing
wrote:
> Ian Kelly wrote:
>>
>> In my view the second one is wrong. a += b should be understood as
>> being equivalent to a = a + b, but with the *possible* and by no means
>> guaranteed optimization that the operation may be performed in-place.
>
>
>
On 3/9/2014 6:03 PM, Gregory Ewing wrote:
Ian Kelly wrote:
In my view the second one is wrong. a += b should be understood as
being equivalent to a = a + b, but with the *possible* and by no means
guaranteed optimization that the operation may be performed in-place.
This interpretation is at
Ian Kelly wrote:
In my view the second one is wrong. a += b should be understood as
being equivalent to a = a + b, but with the *possible* and by no means
guaranteed optimization that the operation may be performed in-place.
This interpretation is at odds with the Language Reference,
section 6
On Mon, Mar 10, 2014 at 6:57 AM, Joshua Landau wrote:
> I would probably implement it closer to home. Inside
> tuple.__getitem__, there would be something like
>
> if context_is_augmented_assignment():
> raise TypeError(message+warning)
> else:
> raise TypeError(message)
>
On 9 March 2014 18:13, Chris Angelico wrote:
> I think I see what you're saying here. But ignore "top-level"; this
> should just be a part of the exception message, no matter what.
I don't think I was clear, but yes. That.
> What you're saying is that this should notice that it's doing an
> augm
On Mon, Mar 10, 2014 at 4:54 AM, Joshua Landau wrote:
> On 28 February 2014 14:43, Chris Angelico wrote:
>> On Sat, Mar 1, 2014 at 1:41 AM, Joshua Landau 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 inp
On 28 February 2014 14:43, Chris Angelico wrote:
> On Sat, Mar 1, 2014 at 1:41 AM, Joshua Landau 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 failur
Ian Kelly :
> In my view the second one is wrong. a += b should be understood as
> being equivalent to a = a + b, but with the *possible* and by no means
> guaranteed optimization that the operation may be performed in-place.
Some call it an optimization, others call it a side effect.
Anyway, th
On Sat, Mar 8, 2014 at 5:45 PM, Gregory Ewing
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
On Sat, Mar 8, 2014 at 5:40 PM, Gregory Ewing
wrote:
> Ian Kelly wrote:
>>
>> class LessThanFilter:
>>
>> def __init__(self, the_list):
>> self._the_list = the_list
>>
>> def __getitem__(self, bound):
>> return [x for x in self._the_list if x < bound]
>>
>>
>> filter = Less
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 th
Ian Kelly wrote:
class LessThanFilter:
def __init__(self, the_list):
self._the_list = the_list
def __getitem__(self, bound):
return [x for x in self._the_list if x < bound]
filter = LessThanFilter([10, 20, 30, 40, 50])
filter[25] += [15, 17, 23]
Should that last line
On Sat, Mar 8, 2014 at 12:34 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> 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.
>
> True.
>
> Speaking
On Sat, Mar 8, 2014 at 1:34 AM, Marko Rauhamaa wrote:
> Speaking of which, are there plans to add a balanced tree to the
> "batteries" of Python? Timers, cache aging and the like need it. I'm
> using my own AVL tree implementation, but I'm wondering why Python
> still doesn't have one.
None curre
Ian Kelly :
> 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.
True.
Speaking of which, are there plans to add a balanced tree to the
"batteries"
On Fri, Mar 7, 2014 at 7:17 PM, Gregory Ewing
wrote:
> Here's another idea: If the __iadd__ method returns the
> same object, *and* the LHS doesn't have a __setitem__
> method, then do nothing instead of raising an exception.
Maybe it doesn't have a __setitem__ because the object that was
retriev
Duncan Booth wrote:
Is there any reason why tuples need to throw an exception on assigning to
the element if the old value and new value are the same object?
It would make introspection misleading, because tuples
would have a __setitem__ method event though they don't
actually support item assi
On Fri, Mar 7, 2014 at 4:51 AM, Alister wrote:
> I would think it would be better if the exception was thrown before the
> assignment to the list took place
> simply seeing that a modification action was being applied to a tupple
> should be enough.
> this would alert the programmer to the fact th
In article ,
Duncan Booth wrote:
> Is there any reason why tuples need to throw an exception on assigning to
> the element if the old value and new value are the same object?
>
> If I say:
>
> a = ("spam", [10, 30], "eggs")
>
> then
>
> a[0] = a[0]
>
> won't actually mutate the obj
On Fri, 07 Mar 2014 09:33:49 +, Duncan Booth wrote:
> Chris Angelico wrote:
>
>> On Sat, Mar 1, 2014 at 1:41 AM, Joshua Landau 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 pro
On Fri, Mar 7, 2014 at 10:38 PM, Peter Otten <__pete...@web.de> wrote:
> TypeError: 257 is not 257
>
> I'm not sure "help" is the right word here ;)
It doesn't help with non-small integers, yes, but the original case
was a list. Personally, I don't think there are many situations that
would benefi
Chris Angelico wrote:
> On Fri, Mar 7, 2014 at 8:33 PM, Duncan Booth
> wrote:
>> Is there any reason why tuples need to throw an exception on assigning to
>> the element if the old value and new value are the same object?
>
> It'd be easy enough to implement your own tuple subclass that behaves
On Fri, Mar 7, 2014 at 8:33 PM, Duncan Booth
wrote:
> Is there any reason why tuples need to throw an exception on assigning to
> the element if the old value and new value are the same object?
It'd be easy enough to implement your own tuple subclass that behaves
that way. Try it! See how many si
Duncan Booth writes:
> Is there any reason why tuples need to throw an exception on assigning
> to the element if the old value and new value are the same object?
Special cases aren't special enough to break the rules.
--
\ “I do not believe in forgiveness as it is preached by the |
Chris Angelico wrote:
> On Sat, Mar 1, 2014 at 1:41 AM, Joshua Landau
> 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 requir
On Sun, 02 Mar 2014 15:17:11 +0100, Eric Jacoboni
wrote:
Le 02/03/2014 15:05, Mark Lawrence a écrit :
The behaviour is consistent except when you try to modify a tuple.
Not in my opinion...
li = [10, 30]
li = li + "spam" --> TypeError: can only concatenate list (not "str")
li += "spam
Le 02/03/2014 15:05, Mark Lawrence a écrit :
> The behaviour is consistent except when you try to modify a tuple.
>
Not in my opinion...
li = [10, 30]
li = li + "spam" --> TypeError: can only concatenate list (not "str")
li += "spam" --> Ok
So, not, that's not what i call consistent.
On 02/03/2014 13:38, Eric Jacoboni wrote:
Le 02/03/2014 13:32, Ian Kelly a écrit :
On Sat, Mar 1, 2014 at 7:04 PM, Eric Jacoboni wrote:
In fact, i think i'm gonna forget += on lists :)
Well, do what you want, but I think you're taking the wrong lesson
from this. Don't forget about using +=
Le 02/03/2014 13:32, Ian Kelly a écrit :
> On Sat, Mar 1, 2014 at 7:04 PM, Eric Jacoboni wrote:
>> In fact, i think i'm gonna forget += on lists :)
>
> Well, do what you want, but I think you're taking the wrong lesson
> from this. Don't forget about using += on lists. Instead, forget
> about u
On Sat, Mar 1, 2014 at 7:04 PM, Eric Jacoboni wrote:
> In fact, i think i'm gonna forget += on lists :)
Well, do what you want, but I think you're taking the wrong lesson
from this. Don't forget about using += on lists. Instead, forget
about using assignments, augmented or otherwise, on tuple e
On Saturday, March 1, 2014 8:04:32 PM UTC-6, Eric Jacoboni wrote:
>
>
> In fact, i think i'm gonna forget += on lists :)
hi Eric, well, that might be extreme, but you certainly want to avoid
trying to change an immutable. Something you might want to consider
is trying something like creating a n
1 - 100 of 270 matches
Mail list logo
