On 05/04/2021 00:47, dn via Python-list wrote:
On 04/04/2021 01.00, Rob Cliffe via Python-list wrote:

On 03/04/2021 04:09, 2qdxy4rzwzuui...@potatochowder.com wrote:
On 2021-04-03 at 02:41:59 +0100,
Rob Cliffe via Python-list <python-list@python.org> wrote:

      x1 = 42; y1 =  3;  z1 = 10
      x2 = 41; y2 = 12; z2 = 9
      x3 =  8;  y3 =  8;  z3 = 10
(please imagine it's in a fixed font with everything neatly vertically
aligned).
This has see-at-a-glance STRUCTURE: the letters are aligned vertically
and the "subscripts" horizontally.  Write it as 9 lines and it becomes
an amorphous mess in which mistakes are harder to spot.
I agree that writing it as 9 lines is an accident waiting to happen, but
if you must see that structure, then go all in:

      (x1, y1, z1) = (43,  3, 10)
      (x2, y2, z2) = (41, 12,  9)
      (x3, y3, z3) = ( 8,  8, 10)
Agreed, that is even easier to read.  (It would be kinda nice if the
compiler could optimise the tuples away, for those of us who are
paranoid about performance.)
I think I've read that the compiler is smart-enough to realise that the
RHS 'literal-tuples'?'tuple-literals' are being used as a 'mechanism',
and thus the inits are in-lined. Apologies: I can't find a web.ref.
Likely one of our colleagues, who is 'into' Python-internals, could
quickly clarify...
[snip]
It doesn't appear to, at least not always.  In Python 3.8.3:
from dis import dis
def f(): x = 1 ; y = 2
def g(): (x,y) = (1,2)
dis(f)
dis(g)

Output:
  2           0 LOAD_CONST               1 (1)
              2 STORE_FAST               0 (x)
              4 LOAD_CONST               2 (2)
              6 STORE_FAST               1 (y)
              8 LOAD_CONST               0 (None)
             10 RETURN_VALUE
  3           0 LOAD_CONST               1 ((1, 2))
              2 UNPACK_SEQUENCE          2
              4 STORE_FAST               0 (x)
              6 STORE_FAST               1 (y)
              8 LOAD_CONST               0 (None)
             10 RETURN_VALUE

Thinking some more about this, this (removing the tuples) is not a straightforward optimisation to do.
Example 1:
    (x, y) = (y, x)
is not the same as
    x = y ; y = x
Example 2:
    L[v], y = a, f()
is not the same as
    L[v] = a ; y = f()
if v is a global changed by f().
I guess it's safe if the RHS is a tuple containing only
    constants, by which I think I mean number/string literals and built-in constants (None, True etc.).     variables (NOT expressions containing variables such as "z+1") which do not occur on the LHS     tuple/list/dictionary/set displays which themselves contain only the above, or nested displays which themselves ... etc. It appears (even though I use Windows where timing anything is a nightmare) that tuple versions are slightly slower.
Rob Cliffe
--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to