A new to Python question

[Steven Bethard]

I have dissed it myself
My argument, if you can call it that, is that it is not clear that
Python is going to do a tuple unpacking here or not !

Hmm... Well, I wouldn't say that. I think it's quite clear that
Python's doing a tuple unpacking. Just like it always does anytime
there's a comma on the left-hand side of an assignment statement.

Note that there's nothing that forces you to write the unpack sequence
like a tuple display. You can write it like a list display too, and
Python will treat it identically:

py> def unpack_tuple(t):
.... [x, y] = t
....
py> dis.dis(unpack_tuple)
2 0 LOAD_FAST 0 (t)
3 UNPACK_SEQUENCE 2
6 STORE_FAST 2 (x)
9 STORE_FAST 1 (y)
12 LOAD_CONST 0 (None)
15 RETURN_VALUE

I don't know how UNPACK_SEQUENCE is implemented, but at least on the
Python level, no tuple or list is created in the unpacking process.

Seems weird, non-intuitive that a tuple unpacking and tuple creation
have the same bytecode.

Sorry, I don't understand. Why do you think this?

py> def create_tuple(x, y):
.... (x, y)
....
py> dis.dis(create_tuple)
2 0 LOAD_FAST 0 (x)
3 LOAD_FAST 1 (y)
6 BUILD_TUPLE 2
9 POP_TOP
10 LOAD_CONST 0 (None)
13 RETURN_VALUE
py> def unpack_tuple(t):
.... x, y = t
....
py> dis.dis(unpack_tuple)
2 0 LOAD_FAST 0 (t)
3 UNPACK_SEQUENCE 2
6 STORE_FAST 2 (x)
9 STORE_FAST 1 (y)
12 LOAD_CONST 0 (None)
15 RETURN_VALUE

To me, it looks like tuple creation uses the BUILD_TUPLE op-code, and
tuple unpacking uses the UNPACK_SEQUENCE op-code. Could you explain
what you meant by "a tuple unpacking and tuple creation have the same
bytecode"?

STeVe

 

[M.E.Farmer]

I explained what i meant in previous post there was nothing more than
just a discussion I have no real problem here just more of a sore point
in style for me. I feel that parens are quite overloaded and it can be
confusing to newbies.
But if the parens are just fluff then get rid of them, it is clearer *
at least to me *
There are enough things wrapped in parens nowadays it is starting to
look like lisp.

BTW, UIAM it is the commas that define tuples, so the outermost parens are really >expression
parens more than tuple syntax.

Hadn't really thought of that way but it makes sense"""tuple() -> an empty tuple
tuple(sequence) -> tuple initialized from sequence's items

If the argument is a tuple, the return value is the same object."""
Thanks for your time Bengt!
M.E.Farmer

 

[M.E.Farmer]

Ok I give up you have convinced me. Of what I am not sure
Anyway I have always viewed :
a,b,c= (1,2,3)
as unpacking a tuple
and :
(a,b,c) = (1,2,3)
as creation of a tuple
It was a false assumption, I have used Python for years and have never
written an unpacking as:
(a,b,c) = (1,2,3)
I have always put parens around my tuples I always thought that a tuple
was a parens with at least one comma
It is just not something I have done, it seems counter to my thinking ,
till I read from Bengt it is the commas that make the tuple not the
parens.
It all makes sense now, but if they are not needed I think they that
should be avoided for clarity.
Steve thanks for your time. I always learn a little from you
M.E.Farmer

 

[Terry Reedy]

But if the parens are just fluff then get rid of them, it is clearer *
at least to me *

While I find unnecessary parens on the right of '=' tolerable, I agree as
to the style preference.

Terry J. Reedy

 

[Fredrik Lundh]

I said exactly what I meant, the parentheses around the values creates
a tuple that you have no reference to!

repeating it doesn't make you right; no extra tuple is created, and the
parens are part of the syntax:

If the target is a target list enclosed in parentheses or in square
brackets: The object must be a sequence with the same number
of items as there are targets in the target list, and its items are
assigned, from left to right, to the corresponding targets.

http://docs.python.org/ref/assignment.html

(originally, you had to use [] to unpack lists, and () or no parens only
worked for tuples. the ability to use an arbitrary sequence was added
in 1.5)

on the other hand, the function you're calling in this example *does*
create a tuple that you have no reference to after the assignment.
that doesn't matter, of course, since the tuple is removed by the
garbage collector immediately after it has been unpacked.

</F>

 

[Fredrik Lundh]

That is the way Fortran handles them:

which is one of the things you really love when you link against
underdocumented Fortran programs from C. ("is that parameter
a scalar or an array? crash! oh, an array. how many values does
it expect? crash! oh, a few more, I suppose").

</F>

 

[Bernd Nawothnig]

I explained what i meant in previous post there was nothing more than
just a discussion

No. You claimed

<quote>
This will only create a tuple in memory
</quote>

But we just learned that this is not the case.

I have no real problem here just more of a sore point in style for
me. I feel that parens are quite overloaded and it can be confusing
to newbies. But if the parens are just fluff then get rid of them, it
is clearer * at least to me *

Reduced to this argument I have no objection.

There are enough things wrapped in parens nowadays it is starting to
look like lisp.

Lisp is far from being ugly ;-)




Bernd

 

[Bengt Richter]

I said exactly what I meant, the parentheses around the values creates
a tuple that you have no reference to!

repeating it doesn't make you right; no extra tuple is created, and the
parens are part of the syntax:

If the target is a target list enclosed in parentheses or in square
brackets: The object must be a sequence with the same number
of items as there are targets in the target list, and its items are
assigned, from left to right, to the corresponding targets.

http://docs.python.org/ref/assignment.html

(originally, you had to use [] to unpack lists, and () or no parens only
worked for tuples. the ability to use an arbitrary sequence was added
in 1.5)

Note that (x) without a comma doesn't unpack like [x] however:

>>> (x)= 123,
>>> x (123,)
>>> [x]= 123,
>>> x 123
>>> (x,)= 123,
>>> x 123
>>> x,= 123,
>>> x

123

Also, BTW,

>>> 123, (123,)
>>> [123,]

[123]

I.e., that last result is not [(123,)]

There's actually a bunch of context-sensitive things about commas that
you just have to get used to, in lists, tuples, function call arg lists,
subscripts (__getitem__ args), unpacking assignment targets, etc.

on the other hand, the function you're calling in this example *does*
create a tuple that you have no reference to after the assignment.

Yeah, but it would create that tuple whether there was an assignment
of the returned result or not. Collecting unconnected facts in one
breath remind me too much of political speeches ;-)

that doesn't matter, of course, since the tuple is removed by the
garbage collector immediately after it has been unpacked.

I'm too tired to figure a humorous segue ;-)

Regards,
Bengt Richter

 

[Steven Bethard]

which is one of the things you really love when you link against
underdocumented Fortran programs from C. ("is that parameter
a scalar or an array? crash! oh, an array. how many values does
it expect? crash! oh, a few more, I suppose").

+1 QOTW

STeVe

 

[M.E.Farmer]

No. You claimed

<quote>
This will only create a tuple in memory
</quote>
That is not what I said please do not edit my words and call it a
quote!

But we just learned that this is not the case.

Yes it seems I was proven wrong and have learned much from the
discussion
That is why I am here to learn from others and help if I can (
sometimes I am just plain wrong and I get the help )

Reduced to this argument I have no objection.

Glad to hear it.

Lisp is far from being ugly ;-)

Your words not mine.I never said it was ugly.
Lisp is beautiful but Python isn't Lisp, and the () *are* getting
overloaded.

M.E.Farmer

 

[M.E.Farmer]

Fredrik and Bengt:
Thank you for the time.
I will study the docs and play with the shell till this is firm.
M.E.Farmer

 

[Bernd Nawothnig]

<quote>
This will only create a tuple in memory
</quote>
That is not what I said please do not edit my words and call it a
quote!

Again the whole sentence:

Message-ID: <[email protected]>

| This will only create a tuple in memory that has no name to reference
| it by!

Please check it out. I did only cut the sentence. But that did not
change the sense of the part I quoted. (As I understood it, correct me
if I'm wrong, I'm not a native English speaker).

Yes it seems I was proven wrong and have learned much from the
discussion That is why I am here to learn from others and help if
I can ( sometimes I am just plain wrong and I get the help )

I know that very well. I often learned much from such discussions too.

Your words not mine.I never said it was ugly.
Lisp is beautiful but Python isn't Lisp, and the () *are* getting
overloaded.

Understood and accepted.



Bernd

 

[M.E.Farmer]

It looks like the docs could use some examples of the various
assignments it refers to.
I think something like Bengt posted would be a nice addition if it
included assignments with slices and dicts too.
Just a thought.
M.E.Farmer