Eugene Alterman writes:
> a = 1, 2, 3
>
> b = *a, # assignment - OK
> b += *a, # augmented assignment - syntax error
>
> Need to enclose in parenthesis:
>
> b += (*a,)
>
> Why isn't it allowed with an augmented assignment, while i
a = 1, 2, 3
b = *a, # assignment - OK
b += *a, # augmented assignment - syntax error
Need to enclose in parenthesis:
b += (*a,)
Why isn't it allowed with an augmented assignment, while it is OK with a
regular assignment?
--
https://mail.python.org/mailman/listinfo/p
On 03/07/2014 10:35, candide wrote:
>From that link:
"""
An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to achieve a similar, but not exactly equal effect. In the
augmented version, x is only evaluated once. Also, when possible, the
a
> >From that link:
>
>
>
> """
>
> An augmented assignment expression like x += 1 can be rewritten as x =
>
> x + 1 to achieve a similar, but not exactly equal effect. In the
>
> augmented version, x is only evaluated once. Also, when
On Thu, Jul 3, 2014 at 5:51 PM, candide wrote:
> Good and interesting observation. But I can't find out where this feature is
> referenced in the Language/Library Reference. Because, as my first post
> explains, augmented assignment performs the binary operation associated to
&
seq+= {5, 6} # the order of extending is not determined
>
> >>> seq
>
> [1, 2, 3, 4, 5, 6]
>
> >>>
Good and interesting observation. But I can't find out where this feature is
referenced in the Language/Library Reference. Because, as my first p
On 7/2/2014 10:39 PM, candide wrote:
An hybrid list-tuple concatenation is not allowed
[]+(1, 2)
Traceback (most recent call last):
File "", line 1, in
TypeError: can only concatenate list (not "tuple") to list
hence I was expecting (*) that the following code raises a TypeError :
>>>
[1, 2]
>>>
Any explanation ?
(*) as the docs states, the augmented assignment is supposed to perform the
concatenation :
An augmented assignment (...) performs the binary operation specific to the
type of assignment on the two operands (...)
--
https://mail.python.org/mailman/listinfo/python-list
ow wrong it was until now.
It's true almost everywhere except augmented assignment. Augmented
assignment is a prime example of the compromises one needs to make in
adding features.
--
Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/
"And if that m
In article <[EMAIL PROTECTED]>,
OKB (not okblacke) <[EMAIL PROTECTED]> wrote:
>
> This sentence is phrased as though it is the whole story, but it
>isn't, because the operation might not in fact wind up being an
>assignment. Shouldn't there be an "except see below" or something
>there, to
object does not support item assignment
>
>> Obviously, you can easily work around it:
>>
>>>>> t = ([],)
>>>>> l = t[0]
>>>>> l += ['foo']
>>>>> t
>> (['foo'],)
>
> This is quite shock
you can easily work around it:
>
>>>> t = ([],)
>>>> l = t[0]
>>>> l += ['foo']
>>>> t
> (['foo'],)
This is quite shocking to me, although after staring at the
documentation for a while I guess I understand it. But
LOAD_CONST 0 (None)
> 22 RETURN_VALUE
>
> Notice the critical sequence: BINARY_SUBSCR, INPLACE_ADD, STORE_SUBSCR.
> It has to work that way to allow this:
>
>>>> l = [7]
>>>> l[0] += 1
>>>> l
> [8]
>
>
In article <[EMAIL PROTECTED]>,
Roel Schroeven <[EMAIL PROTECTED]> wrote:
>Aahz schreef:
>>
>> Although Alex is essentially correct, the situation is a bit more complex
>> and you are correct that augmented assignment allows the object to decide
>> wh
guage Reference seems a little confused about the
>>>> terminology.
>>>>
>>>> 3.4.7 Emulating numeric types
>>>> 6.3.1 Augmented assignment statements
>>>>
>>>> The former refers to "augmented arithmetic operations", whi
the
>>> terminology.
>>>
>>> 3.4.7 Emulating numeric types
>>> 6.3.1 Augmented assignment statements
>>>
>>> The former refers to "augmented arithmetic operations", which I
>>> think is a nice terminology, since assignment
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> I'm sorry to see you missed it, but since I had answered this already in
>AP> this thread I saw at the moment no need to repeat it: There would be no
>AP> value for c, the line would raise an UnboundLocalError.
OK. That could have been chos
This is probably my last response to you in this thread. My impression
is that for the moment nothing productive can come from this exchange.
I have the feeling that you are not reading so much with the interntion
of understanding what I want to say, but with the intention of
confirming your suspit
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> When someone gets confused over the difference between rebinding or
>AP> mutating a variable on an intermediate scope, the explanation he
>AP> mostly seems to get boils down to: one is rebinding, the other is
>AP> mutation, this is a fundame
On 2006-07-08, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 8 Jul 2006 18:52:56 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>
>>
>> I'm not fooled by that phrase. I just think the mutate vs rebind
>> explanation is not complete.
>>
>> If we have tw
On 2006-07-09, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>
>>AP> It is conceptually different. In the line 'a = b' you don't need to
>>AP> search for the scope of a. You know it is the current scope, if you
>
> Except when it has been declared
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> It is conceptually different. In the line 'a = b' you don't need to
>AP> search for the scope of a. You know it is the current scope, if you
Except when it has been declared global.
>AP> want to know the scope of b on the other hand, you n
On 2006-07-07, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>
>>AP> On 2006-07-07, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>>AP> Could you maybe clarify what problem we are discussi
On 2006-07-07, Terry Reedy <[EMAIL PROTECTED]> wrote:
>
> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
>> And if Nested variables are harmfull,
>
> I don't know if anyone said that they were, but Guido obviously does not
> think so, or he would not have added the
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> On 2006-07-07, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>>>
>AP> Could you maybe clarify what problem we are discussing? All I wrote
>AP> was that with an assignment the search for t
"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> others might be helped if you took the trouble of explaining
> what was wrong.
Aside from F., I tried to explain what I think you said wrong. Did you
read it? Did it help any?
tjr
--
http://mail.python.org/mai
Fredrik Lundh wrote:
> Bruno Desthuilliers wrote:
>
>> Certainly not. Nested scopes allow closures, which allow decorators and
>> lot of *very* useful things.
>
>
> decorators can be trivially implemented as classes, of course. it's a
> bit unfortunate that many people seem to think that decora
On 2006-07-07, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>>> have any of your "my mental model of how Python works is more important
>>> than how it actually works" ever had a point ?
>>
>> Be free to correct me. But just suggesting that I'm wrong doesn't help
>> me in cha
On 2006-07-07, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Antoon "I'm no nincompoop, but I play one on the internet" Pardon wrote:
>
>> I don't see the contradiction. That Namespaces and names lookup are
>> fundamentel parts of the Python language, doesn't mean that
>> the right behaviour can't be
On 2006-07-07, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>
>>AP> Could you maybe clarify what problem we are discussing? All I wrote
>>AP> was that with an assignment the search for the lefthand variable
>>AP> depends on whether the lefthand si
Bruno Desthuilliers wrote:
> Certainly not. Nested scopes allow closures, which allow decorators and
> lot of *very* useful things.
decorators can be trivially implemented as classes, of course. it's a
bit unfortunate that many people seem to think that decorators *have* to
be implemented as n
Antoon Pardon wrote:
> On 2006-07-06, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>
>
>>>AP> Aren't we now talking about implementation details? Sure the compilor
>>>AP> can set things up so that local names are bound to the local scope and
>>>AP> so the same code can be used. But it seems somewh
Piet van Oostrum wrote:
(snip)
> There is no big difference I think. Only Python doesn't have syntax for the
> former. Older versions of Python didn't even have nested scopes. maybe it
> was a mistake to add them.
Certainly not. Nested scopes allow closures, which allow decorators and
lot of *very
Antoon Pardon wrote:
> On 2006-07-06, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>
>>Antoon Pardon wrote:
>>
>>>On 2006-07-05, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>>>
>>>
>>>It's not about "finding a name/identifier", it's about the difference
>>>between (re)binding a name and
Piet van Oostrum wrote:
> There is no big difference I think. Only Python doesn't have syntax for the
> former. Older versions of Python didn't even have nested scopes.
arbitrarily nested scopes, at least. the old local/global/builtin
approach (the LGB rule) is of course a kind of nesting; the
Antoon "I'm no nincompoop, but I play one on the internet" Pardon wrote:
> I don't see the contradiction. That Namespaces and names lookup are
> fundamentel parts of the Python language, doesn't mean that
> the right behaviour can't be implemented in multiple ways and
> doesn't contradict that a
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> Could you maybe clarify what problem we are discussing? All I wrote
>AP> was that with an assignment the search for the lefthand variable
>AP> depends on whether the lefthand side is a simple variable or
>AP> more complicated.
What do you
> "Terry Reedy" <[EMAIL PROTECTED]> (TR) wrote:
>TR> "Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
>TR> news:[EMAIL PROTECTED]
>>> And if Nested variables are harmfull,
>TR> I don't know if anyone said that they were, but Guido obviously does not
>TR> think so, or he would not have
Antoon Pardon wrote:
>> have any of your "my mental model of how Python works is more important
>> than how it actually works" ever had a point ?
>
> Be free to correct me. But just suggesting that I'm wrong doesn't help
> me in changing my mental model.
over the years, enough people have waste
"Antoon Pardon" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> And if Nested variables are harmfull,
I don't know if anyone said that they were, but Guido obviously does not
think so, or he would not have added them. So skip that.
> what is then the big difference between rebi
On 2006-07-06, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-07-05, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>>
>>It's not about "finding a name/identifier", it's about the difference
>>between (re)binding a name and mutating an object.
>>>
AP> The
On 2006-07-06, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>>AP> Aren't we now talking about implementation details? Sure the compilor
>>AP> can set things up so that local names are bound to the local scope and
>>AP> so the same code can be used. But it seems somewhere was made the
>>AP> decision
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> Well if someone explains what is wrong about my understanding, I
>AP> certainly care about that (although I confess to sometimes being
>AP> impatient) but someone just stating he is not sure I understand?
That is just a euphemistic way of s
Antoon Pardon wrote:
> On 2006-07-05, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>
>>>Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>>
>>>AP> On 2006-07-05, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>>>
>Antoon Pardon wrote:
>(snip)
>
>>Well no matter what explanation you
On 2006-07-05, Piet van Oostrum <[EMAIL PROTECTED]> wrote:
>> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>
>>AP> On 2006-07-05, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
Antoon Pardon wrote:
(snip)
> Well no matter what explanation you give to it, and I understand how it
>
On 2006-07-05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>
>> Python could have chosen an approach with a "nested" keyword
>
> sure, and Python could also have been invented by aliens, powered by
> space potatoes, and been illegal to inhale in Belgium.
At one time one could
> Antoon Pardon <[EMAIL PROTECTED]> (AP) wrote:
>AP> On 2006-07-05, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>>> Antoon Pardon wrote:
>>> (snip)
Well no matter what explanation you give to it, and I understand how it
works,
>>>
>>> I'm not sure of this.
>AP> Should I care abo
Antoon Pardon wrote:
> Python could have chosen an approach with a "nested" keyword
sure, and Python could also have been invented by aliens, powered by
space potatoes, and been illegal to inhale in Belgium.
have any of your "my mental model of how Python works is more important
than how it ac
On 2006-07-05, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
> (snip)
>> Well no matter what explanation you give to it, and I understand how it
>> works,
>
> I'm not sure of this.
Should I care about that?
>> I keep finding it strange that something like
>>
>> k = [0]
Bruno Desthuilliers wrote:
> It's not about "finding a name/identifier", it's about the difference
> between (re)binding a name and mutating an object.
the difference between binding and performing an operation on an object
(mutating or not), in fact.
this is Python 101.
--
http://mail.pyth
Antoon Pardon wrote:
(snip)
> Well no matter what explanation you give to it, and I understand how it
> works,
I'm not sure of this.
> I keep finding it strange that something like
>
> k = [0]
> def f(i):
> k[0] += i
> f(2)
>
> works but the following doesn't
>
> k = 0
> def f(i)
On 2006-07-04, Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
> Tim N. van der Leeuw wrote:
>
>> Hi,
>>
>> The following might be documented somewhere, but it hit me unexpectedly
>> and I couldn't exactly find this in the manual either.
>>
>&g
Tim N. van der Leeuw wrote:
> Hi,
>
> The following might be documented somewhere, but it hit me unexpectedly
> and I couldn't exactly find this in the manual either.
>
> Problem is, that I cannot use augmented assignment operators in a
> nested scope, on variables fro
Hi,
The following might be documented somewhere, but it hit me unexpectedly
and I couldn't exactly find this in the manual either.
Problem is, that I cannot use augmented assignment operators in a
nested scope, on variables from the outer scope:
PythonWin 2.4.3 (#69, Mar 29 2006, 17:35:34)
Hello, just a couple points
On 6/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
[errors involving the shadowing of a variable by another]
> > Of course everybody makes errors, but it doesn't follow from this, that
> > all make the same errors, or should.
>
> If I implied that everyone has
n stopped it at "ref to uninitialized local" - or in some other langiage
> context ? In the Python case, I can only wonder as to what could make it
> memorable - not the debugging, certainly.
I wouldn't call the shadowing gratuitous, but it was unfortunate. It
happened to me in the c
On 17/06/2006 8:00 AM, Boris Borcic wrote:
> Josiah Carlson wrote:
Please consider abandoning this "conversation".
Plan B: Please consider conducting it using private e-mail.
Plan C: Please consider conducting it in alt.you.said.I.said.you.said.I.said
--
http://mail.python.org/mailman/listinfo/py
o, do you mean it happened to you in the Python context so that
Python stopped it at "ref to uninitialized local" - or in some other langiage
context ? In the Python case, I can only wonder as to what could make it
memorable - not the debugging, certainly.
In the non-Python case, we
Boris Borcic <[EMAIL PROTECTED]> wrote:
> [this is bytes of an oversized put-all-into-it intervention. A possibly
> expanded
> version will be submitted on clp with local followup before a couple days]
>
> Josiah Carlson wrote:
>
> [BB]
> >> I'd say a first step in convincing me I am wrong wo
Terry Hancock wrote:
> On Tue, 21 Feb 2006 10:55:42 +0530
> Suresh Jeevanandam <[EMAIL PROTECTED]> wrote:
> Seriously,
> I think they are usually equivalent internally,
> at least for immutable objects.
>
yah, but when you do augmented assigns on lists, or mix immutable an
dmutable:
http://zeph
On Tue, 21 Feb 2006 10:55:42 +0530
Suresh Jeevanandam <[EMAIL PROTECTED]> wrote:
> Is there any gain in performance because of
> augmented assignments.
>
> x += 1 vs x = x+1
Yep. I perform better when I only type names once.
Especially if they are long:
length_of_object_I_must
<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
> Terry Reedy wrote:
>> Program performance might be noticeable if 'x' is something like a.b.c.d
>> that takes some lookup time. But again, I would use the += form for
>> readability without testing run time.
>
> Would x=x + 1 be more
I think it heavily depends on what is "x". If x is bound to a mutable
x=x+1 and x+=1 can not only have different speed but indeed can do two
very unrelate things (the former probably binding to a new object, the
latter probably modifying the same object). For example consider what
happens with list
Terry Reedy wrote:
> Program performance might be noticeable if 'x' is something like a.b.c.d
> that takes some lookup time. But again, I would use the += form for
> readability without testing run time.
Would x=x + 1 be more readable, regardless of the background(whether
being introduced to the
Thanks Alex. I was not aware of mtimeit.
regards,
Suresh
Alex Martelli wrote:
> Suresh Jeevanandam <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>> Is there any gain in performance because of augmented assignments.
>>
>> x += 1 vs x = x+1
>>
>> Or are both of them the same.
>
> Just *MEASURE*
"Suresh Jeevanandam" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
> Is there any gain in performance because of augmented assignments.
>
> x += 1 vs x = x+1
>
> Or are both of them the same.
The main gain is in programmer performance for writing a long name such as
number_
Suresh Jeevanandam <[EMAIL PROTECTED]> wrote:
> Hi,
> Is there any gain in performance because of augmented assignments.
>
> x += 1 vs x = x+1
>
> Or are both of them the same.
Just *MEASURE*, man!
helen:~/apy alex$ python -mtimeit -s'x=0.0' 'x=x+1'
100 loops, best of 3: 0.507
Hi,
Is there any gain in performance because of augmented assignments.
x += 1 vs x = x+1
Or are both of them the same.
regards,
Suresh
--
http://mail.python.org/mailman/listinfo/python-list
On Thu, 29 Sep 2005, Pierre Barbier de Reuille wrote:
> a discussion began on python-dev about this. It began by a bug report,
> but is shifted and it now belongs to this discussion group.
>
> The problem I find with augmented assignment is it's too complex, it's
> ba
I thought along these lines:
It is an augmented ASSIGNMENT. (It even has an equals sign in it).
tuples are immutable so you should not be able to assign to one of
its elements.
- So there is no problem for me - I shouldn't be messing with an
element of an
immutable type!
- Cheers,
Reinhold Birkenfeld a écrit :
> Pierre Barbier de Reuille wrote:
>
>
>>So, what I would suggest is to drop the user-defined augmented
>>assignment and to ensure this equivalence :
>>
>>a X= b <=> a = a X b
>>
>>with 'X' begin one of th
Pierre Barbier de Reuille wrote:
> So, what I would suggest is to drop the user-defined augmented
> assignment and to ensure this equivalence :
>
> a X= b <=> a = a X b
>
> with 'X' begin one of the operators.
It can be done, but it's unnecessary for mu
Hello,
a discussion began on python-dev about this. It began by a bug report,
but is shifted and it now belongs to this discussion group.
The problem I find with augmented assignment is it's too complex, it's
badly explained, it's error-prone. And most of all, I don't see
73 matches
Mail list logo
