Ben Finney writes:
Ben Finney
Date:
11/24/2015 04:49 AM
To:
python-list@python.org
George Trojan writes:
The following code has bitten me recently:
t=(0,1)
x,y=t if t else 8, 9
print(x, y)
(0, 1) 9
You can simplify this by taking assignment out of the picture::
>>> t = (0, 1)
On Tue, 24 Nov 2015 02:25 pm, George Trojan wrote:
> The following code has bitten me recently:
>
> >>> t=(0,1)
> >>> x,y=t if t else 8, 9
> >>> print(x, y)
> (0, 1) 9
>
> I was assuming that a comma has the highest order of evaluation, that is
> the expression 8, 9 should make a tuple. Why t
George Trojan writes:
> The following code has bitten me recently:
>
> >>> t=(0,1)
> >>> x,y=t if t else 8, 9
> >>> print(x, y)
> (0, 1) 9
You can simplify this by taking assignment out of the picture::
>>> t = (0, 1)
>>> t if t else 8, 9
((0, 1), 9)
So that's an “expression list”
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
On Mon, 10 Mar 2014 02:35:36 -0600, Ian Kelly wrote:
> On Sun, Mar 9, 2014 at 8:37 PM, Steven D'Aprano
> wrote:
>> On Sun, 09 Mar 2014 17:42:42 -0600, Ian Kelly wrote:
>>
>>> On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing
>>> wrote:
>>
Note that it says "when possible", not "if the implement
On Sun, Mar 9, 2014 at 8:37 PM, Steven D'Aprano
wrote:
> On Sun, 09 Mar 2014 17:42:42 -0600, Ian Kelly wrote:
>
>> On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing
>> wrote:
>
>>> Note that it says "when possible", not "if the implementation feels
>>> like it".
>>
>> That's quite vague, and not much
On Sun, 09 Mar 2014 17:42:42 -0600, Ian Kelly wrote:
> On Sun, Mar 9, 2014 at 4:03 PM, Gregory Ewing
> 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"
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
On Saturday, March 1, 2014 3:21:44 PM UTC-6, Mark H. Harris wrote:
> On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote:
hi Ian, I thought of something else after I slept on it, so to speak.
Consider this:
>>> s=(2,3,[42,43,44],7)
>>> s[2]
[42, 43, 44]
>>>
s[2] is a list. We shoul
Le 01/03/2014 22:21, Mark H. Harris a écrit :
> The point I'm trying to make with this post is that s[2]+=[46] and
> s[2]=s[2]+[46] are handled inconsistently.
For my own, the fact that, in Python, a_liste += e_elt gives a different
result than a_list = a_list + e_elt is a big source of trou
On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote:
> How would you propose doing that? Bear in mind that while Python
> knows that tuples specifically are immutable, it doesn't generally
> know whether a type is immutable.
hi Ian, I thought of something else after I slept on it, so to
On Saturday, March 1, 2014 8:54:43 AM UTC-6, Mark Lawrence wrote:
> you're also using google groups... it doesn't wrap paragraphs
>
> correctly... please read and action this
>
> https://wiki.python.org/moin/GoogleGroupsPython... it does wrap
>
> paragraphs correctly... it also prevents
On Fri, Feb 28, 2014 at 11:25 PM, Mark H. Harris wrote:
> On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote:
>
>> How would you propose doing that? Bear in mind that while Python
>> knows that tuples specifically are immutable, it doesn't generally
>> know whether a type is immutable.
>
>
On 27 February 2014 21:47, Nick Timkovich wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico 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`?
N
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
On 01/03/2014 06:16, Mark H. Harris wrote:
On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote:
How would you propose doing that? Bear in mind that while Python
knows that tuples specifically are immutable, it doesn't generally
know whether a type is immutable.
hi Ian, consider the
On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote:
> How would you propose doing that? Bear in mind that while Python
> knows that tuples specifically are immutable, it doesn't generally
> know whether a type is immutable.
I was going to bed, and then thought of the solution. Allow th
On Sat, Mar 1, 2014 at 5:16 PM, Mark H. Harris wrote:
> This is what I mean... the error message is telling the user that it cannot
> do what he has requested, and yet IT DID. You have one of two scenarios:
> 1) the message is arbitrarily lying and it really can assign an immutable's
> ite
On Friday, February 28, 2014 11:16:18 PM UTC-6, Ian wrote:
> How would you propose doing that? Bear in mind that while Python
> knows that tuples specifically are immutable, it doesn't generally
> know whether a type is immutable.
hi Ian, consider the problem... its a "cake" and "eat it too
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
On Fri, Feb 28, 2014 at 9:45 PM, Mark H. Harris 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
> overhea
On Fri, Feb 28, 2014 at 6:27 PM, Eric Jacoboni 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 t
On Fri, Feb 28, 2014 at 5:22 PM, Mark H. Harris wrote:
> 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
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 o
On Sat, Mar 1, 2014 at 11:22 AM, Mark H. Harris wrote:
> 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
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 w
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) b
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 require figuring out whether or not the va
On 27 February 2014 16:14, Chris Angelico wrote:
> On Fri, Feb 28, 2014 at 3:01 AM, Eric Jacoboni
> wrote:
>>
> a_tuple = ("spam", [10, 30], "eggs")
> a_tuple[1] += [20]
>> Traceback (most recent call last):
>> File "", line 1, in
>> TypeError: 'tuple' object does not support item ass
John O'Hagan :
> 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:
http://docs.python.org/3.2/reference/simple_stmts.html
#augmented-assignment-statements>:
Also, when possib
On Thu, 27 Feb 2014 18:19:09 +0200
Marko Rauhamaa wrote:
> Eric Jacoboni :
>
> a_tuple[1] += [20]
> > Traceback (most recent call last):
> > File "", line 1, in
> > TypeError: 'tuple' object does not support item assignment
> >
> > [...]
> >
> > But, then, why a_tuple is still modified?
On Thu, Feb 27, 2014 at 2:47 PM, Nick Timkovich wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico wrote:
>>
>> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni
>> wrote:
>> > But, imho, it's far from being a intuitive result, to say the least.
>>
>> It's unintuitive, but it's a consequence
On Fri, Feb 28, 2014 at 8:47 AM, Nick Timkovich wrote:
> On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico wrote:
>>
>> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni
>> wrote:
>> > But, imho, it's far from being a intuitive result, to say the least.
>>
>> It's unintuitive, but it's a consequence
On Thu, Feb 27, 2014 at 10:33 AM, Chris Angelico wrote:
> On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni
> 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
On Thu, Feb 27, 2014 at 10:27 AM, Eric Jacoboni 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 wa
On Fri, Feb 28, 2014 at 3:27 AM, Eric Jacoboni 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
--
https://mail.python.org/mailman/listinf
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
Eric Jacoboni :
a_tuple[1] += [20]
> Traceback (most recent call last):
> File "", line 1, in
> 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. tri
On Fri, Feb 28, 2014 at 3:01 AM, Eric Jacoboni 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 "", line 1, in
> TypeE
On Thu, Feb 27, 2014 at 10:01 AM, Eric Jacoboni 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 "", line 1, in
Spencer Pearson wrote:
Hi!
This might be more of a personal-preference question than anything,
but here goes: when is it appropriate for a function to take a list or
tuple as input, and when should it allow a varying number of
arguments? It seems as though the two are always interchangeable. For
On Fri, 19 Mar 2010 17:20:31 -0700, Spencer Pearson wrote:
> Hi!
>
> This might be more of a personal-preference question than anything, but
> here goes: when is it appropriate for a function to take a list or tuple
> as input, and when should it allow a varying number of arguments?
That depend
On 5 июн, 21:22, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Jun 5, 11:48 am, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
>
>
> > On 5 июн, 19:38, George Sakkis <[EMAIL PROTECTED]> wrote:
>
> > > On Jun 5, 11:21 am, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
> > > > On 5 июн, 18:56, Ivan Illar
On Jun 5, 11:48 am, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> On 5 июн, 19:38, George Sakkis <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Jun 5, 11:21 am, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
> > > On 5 июн, 18:56, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
> > > > On 5 июн, 18:19, "[EMAIL
On 5 июн, 19:38, George Sakkis <[EMAIL PROTECTED]> wrote:
> On Jun 5, 11:21 am, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
>
>
> > On 5 июн, 18:56, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
> > > On 5 июн, 18:19, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > On Jun 5, 3:49 pm,
On Jun 5, 11:21 am, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> On 5 июн, 18:56, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
>
>
> > On 5 июн, 18:19, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > wrote:
>
> > > On Jun 5, 3:49 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
> > > > On 5 ÉÀÎ, 01:57,
On 5 июн, 18:56, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> On 5 июн, 18:19, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > On Jun 5, 3:49 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
> > > On 5 ÉÀÎ, 01:57, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > > wrote:
>
> > > > Hi Everyone
On 5 июн, 18:19, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> On Jun 5, 3:49 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
>
>
> > On 5 ÉÀÎ, 01:57, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > wrote:
>
> > > Hi Everyone,
>
> > > i have another question. What if i wanted to make n tuples, each
On 5 июн, 18:19, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> On Jun 5, 3:49 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
>
>
>
> > On 5 ÉÀÎ, 01:57, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> > wrote:
>
> > > Hi Everyone,
>
> > > i have another question. What if i wanted to make n tuples, each
On Jun 5, 3:49 pm, Ivan Illarionov <[EMAIL PROTECTED]> wrote:
> On 5 ÉÀÎ, 01:57, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> wrote:
>
>
>
> > Hi Everyone,
>
> > i have another question. What if i wanted to make n tuples, each with
> > a list of coordinates. For example :
>
> > coords = list()
> > for
On 5 июн, 01:57, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> Hi Everyone,
>
> i have another question. What if i wanted to make n tuples, each with
> a list of coordinates. For example :
>
> coords = list()
> for h in xrange(1,11,1):
>for i in xrange(1, 5, 1) :
> for j in xrange(1, 5
On Jun 5, 9:26 am, "[EMAIL PROTECTED]"
<[EMAIL PROTECTED]> wrote:
> On Jun 5, 1:37 am, [EMAIL PROTECTED] wrote:
>
>
>
> > [EMAIL PROTECTED]:
>
> > Do you mean something like this? (notice the many formatting
> > differences, use a formatting similar to this one in your code)
>
> > coords = []
>
> >
1 - 100 of 290 matches
Mail list logo
