On 8/07/20 10:19 PM, Peter J. Holzer wrote:
On 2020-07-08 12:26:06 +1200, dn via Python-list wrote:
OTOH, using a tuple doesn't prevent the function from mutating mutable
arguments:
#!/usr/bin/python3
def f(*a):
a[0]["new"] = 2
v = { "old": 1}
f(v)
print(v)
prints «{'old': 1, 'new': 2}».
' mailto:python-list@python.org>> Subject: Questioning the effects of
multiple assignment TLDR; if you are a Python 'Master' then feel
free to skim the first part (which you should know hands-down),
...
Dunno about the rest of the list but I'm finding this
On 8/07/20 2:40 PM, Kyle Stanley wrote:
A matter of style, which I like to follow [is it TDD's influence? - or
does it actually come-from reading about DBC (Design by Contract*)?] is
the injunction that one *not* vary the value of a parameter inside a
method/function.
(useful
On Tue, Jul 7, 2020 at 2:30 AM Mike Dewhirst wrote:
>
> Original message From: dn via Python-list <
> python-list@python.org> Date: 7/7/20 16:04 (GMT+10:00) To: 'Python' <
> python-list@python.org> Subject: Questioning the effects of multip
On 2020-07-08 12:26:06 +1200, dn via Python-list wrote:
> A matter of style, which I like to follow [is it TDD's influence? - or
> does it actually come-from reading about DBC (Design by Contract*)?]
I think Design by Contract only affects the interfaces (parameters,
return values and side effects
>
> A matter of style, which I like to follow [is it TDD's influence? - or
> does it actually come-from reading about DBC (Design by Contract*)?] is
> the injunction that one *not* vary the value of a parameter inside a
> method/function.
> (useful in 'open-box testing' to check both the API and th
On 7/07/20 7:44 PM, Kyle Stanley wrote:
Can you explain why these two (apparently) logical assignment processes
have been designed to realise different result-objects?
The reason is because of the conventions chosen in PEP 3132, which
implemented the feature in the first place. It wa
On 7/07/20 7:21 PM, Mike Dewhirst wrote:
Original message
For comparison, here's the original form:-
>>> def f( a, *b, c=0 ):
... print( a, type( a ) )
... print( c, type( c ) )
... print( b )
...
>>> f( 1, 'two', 3, 'four' )
1
0
('two', 3, 'four')
Shouldn't
>
> Can you explain why these two (apparently) logical assignment processes
> have been designed to realise different result-objects?
The reason is because of the conventions chosen in PEP 3132, which
implemented the feature in the first place. It was considered to return a
tuple for the consiste
Original message From: dn via Python-list
Date: 7/7/20 16:04 (GMT+10:00) To: 'Python'
Subject: Questioning the effects of multiple
assignment TLDR; if you are a Python 'Master' then feel free to skim the first
part (which you should know hands-down)
TLDR; if you are a Python 'Master' then feel free to skim the first part
(which you should know hands-down), until the excerpts from 'the manual'
and from there I'll be interested in learning from you...
Yesterday I asked a junior prog to expand an __init__() to accept either
a series of (>1)
On 2/16/2016 7:46 AM, srinivas devaki wrote:
Hi,
a = b = c
as an assignment doesn't return anything, i ruled out a = b = c as
chained assignment, like a = (b = c)
SO i thought, a = b = c is resolved as
a, b = [c, c]
https://docs.python.org/3/reference/simple_stmts.html#assignment-statements
"
On Tue, Feb 16, 2016 at 6:35 PM, Sven R. Kunze wrote:
>
> First, the rhs is evaluated.
> Second, the lhs is evaluated from left to right.
Great, I will remember these two lines :)
On Tue, Feb 16, 2016 at 8:46 PM, Steven D'Aprano wrote:
> _temp = c
> a = _temp
> b = _temp
> del _temp
>
>
> except
On Tue, 16 Feb 2016 11:46 pm, srinivas devaki wrote:
> Hi,
>
> a = b = c
>
> as an assignment doesn't return anything, i ruled out a = b = c as
> chained assignment, like a = (b = c)
> SO i thought, a = b = c is resolved as
> a, b = [c, c]
That is one way of thinking of it. A better way would b
On 16.02.2016 14:05, Sven R. Kunze wrote:
Hi Srinivas,
I think the tuple assignment you showed basically nails it.
First, the rhs is evaluated.
Second, the lhs is evaluated from left to right.
Completely wrong?
Best,
Sven
As you mentioned swapping. The following two statements do the same (
Hi Srinivas,
On 16.02.2016 13:46, srinivas devaki wrote:
Hi,
a = b = c
as an assignment doesn't return anything, i ruled out a = b = c as
chained assignment, like a = (b = c)
SO i thought, a = b = c is resolved as
a, b = [c, c]
at-least i fixed in my mind that every assignment like operation
Hi,
a = b = c
as an assignment doesn't return anything, i ruled out a = b = c as
chained assignment, like a = (b = c)
SO i thought, a = b = c is resolved as
a, b = [c, c]
at-least i fixed in my mind that every assignment like operation in
python is done with references and then the references a
Anand wrote:
>>>Wouldn't it be nice to say
>>>id, *tokens = line.split(',')
>>
>>
>>id, tokens_str = line.split(',', 1)
>
>
> But then you have to split tokens_str again.
>
> id, tokens_str = line.split(',', 1)
> tokens = tokens_str.split(',')
>
> this is too verbose.
>
head_tail = lambda seq
Anand wrote:
> Suppose i have a big list and i want to take tke the first one and rest
> of the list like car/cdr in lisp.
> is there any easy way to do this in python?
It seems like overkill to me to make the syntax more
complex just to avoid writing a one-line function.
def first_rest(seq): ret
Anand wrote:
>>> Wouldn't it be nice to say
>>> id, *tokens = line.split(',')
>>
>> id, tokens_str = line.split(',', 1)
>
> But then you have to split tokens_str again.
>
> id, tokens_str = line.split(',', 1)
> tokens = tokens_str.split(',')
Sorry, it wasn't clear that you needed the tokens from
>> Wouldn't it be nice to say
>> id, *tokens = line.split(',')
>
>
> id, tokens_str = line.split(',', 1)
But then you have to split tokens_str again.
id, tokens_str = line.split(',', 1)
tokens = tokens_str.split(',')
this is too verbose.
anand
--
http://mail.python.org/mailman/listinfo/python
Anand wrote:
> Wouldn't it be nice to say
>
> id, *tokens = line.split(',')
id, tokens_str = line.split(',', 1)
STeVe
--
http://mail.python.org/mailman/listinfo/python-list
> You're right, that would not be so far off.
> But then, the following should be also supported:
>
> *x, y = a # x, y = a[:-1], y = a[-1]
> x, *y, z = a # x, y, z = a[0], a[1:-1], a[-1]
>
> Of course, there can be only one variable with an asterisk.
> (But note that in the situation of a function
Christoph Zwerschke wrote:
> You're right, that would not be so far off.
> But then, the following should be also supported:
>
> *x, y = a # x, y = a[:-1], y = a[-1]
> x, *y, z = a # x, y, z = a[0], a[1:-1], a[-1]
>
> Of course, there can be only one variable with an asterisk.
> (But note that in
Anand schrieb:
> Suppose i have a big list and i want to take tke the first one and rest
> of the list like car/cdr in lisp.
> is there any easy way to do this in python?
>
> Only way i know is
>
> a = range(10)
> x, y = a[0], a[1:]
You have so many higher-level ways to access and iterate throug
Suppose i have a big list and i want to take tke the first one and rest
of the list like car/cdr in lisp.
is there any easy way to do this in python?
Only way i know is
a = range(10)
x, y = a[0], a[1:]
In perl, it is possible to do multiple assignment like this
@a = (1, 2, 3);
($x, @y
On Tue, 21 Feb 2006 10:53:21 +0530
Suresh Jeevanandam <[EMAIL PROTECTED]> wrote:
> I read in "Python in a Nutshell" that when we have
> multiple assignments
> made on a single line, it is equivalent to have those many
> simple assignments and that the right side is evaluated
> once fo
Suresh Jeevanandam <[EMAIL PROTECTED]> wrote:
...
> I think I got confused because of "Each time" in the sentence which
> gives a feeling that it gets executed several times. Maybe, It could
> have been just written, "When the statement gets executed, the right
> hand side is evaluated once,
Alex Martelli wrote:
> Suresh Jeevanandam <[EMAIL PROTECTED]> wrote:
>
>> Dear all,
>> I read in "Python in a Nutshell" that when we have multiple assignments
>> made on a single line, it is equivalent to have those many simple
>> assignments and that the right side is evaluated once for ea
While I think that the paragraph is correct still there is IMO indeed
the (low) risk of such a misunderstanding. The problem is that "the
statement executes" can IMO easily be understood as "the statements
execute" (especially if your background includes only languages where
Suresh Jeevanandam <[EMAIL PROTECTED]> wrote:
> Dear all,
> I read in "Python in a Nutshell" that when we have multiple assignments
> made on a single line, it is equivalent to have those many simple
> assignments and that the right side is evaluated once for each
> assignment. [The wordin
e wordings are mine. I am not sure if this is what he
> intended].
No, it isn't. He says, "Each time the statement executes, the right-hand side
expression is evaluated once." "[T]he statement" refers to the multiple
assignment as a whole.
--
Robert Kern
[EMAIL PROTECTE
Dear all,
I read in "Python in a Nutshell" that when we have multiple assignments
made on a single line, it is equivalent to have those many simple
assignments and that the right side is evaluated once for each
assignment. [The wordings are mine. I am not sure if this is what he
intende
33 matches
Mail list logo
