Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #10776 > unrolled thread

Syntactic sugar for assignment statements: one value to multiple targets?

Back to article view | Back to comp.lang.python

Contents

  Syntactic sugar for assignment statements: one value to multiple targets? gc <gc1223@gmail.com> - 2011-08-02 18:45 -0700
    Re: Syntactic sugar for assignment statements: one value to multiple targets? Chris Angelico <rosuav@gmail.com> - 2011-08-03 03:09 +0100
    Re: Syntactic sugar for assignment statements: one value to multiple targets? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-08-03 18:25 +1000
      Re: Syntactic sugar for assignment statements: one value to multiple targets? Tim Chase <python.list@tim.thechases.com> - 2011-08-03 06:15 -0500
      Re: Syntactic sugar for assignment statements: one value to multiple targets? Tim Chase <python.list@tim.thechases.com> - 2011-08-03 06:25 -0500
        Re: Syntactic sugar for assignment statements: one value to multiple targets? gc <gc1223@gmail.com> - 2011-08-16 12:50 -0700
    Re: Syntactic sugar for assignment statements: one value to multiple targets? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-08-03 20:29 +1200
    Re: Syntactic sugar for assignment statements: one value to multiple targets? "Martin P. Hellwig" <martin.hellwig@gmail.com> - 2011-08-16 21:39 +0100
      Re: Syntactic sugar for assignment statements: one value to multiple targets? gc <gc1223@gmail.com> - 2011-08-16 17:14 -0700
        Re: Syntactic sugar for assignment statements: one value to multiple targets? MRAB <python@mrabarnett.plus.com> - 2011-08-17 03:11 +0100
        Re: Syntactic sugar for assignment statements: one value to multiple targets? Chris Angelico <rosuav@gmail.com> - 2011-08-17 08:13 +0100
          Re: Syntactic sugar for assignment statements: one value to multiple targets? gc <gc1223@gmail.com> - 2011-08-17 02:26 -0700
            Re: Syntactic sugar for assignment statements: one value to multiple targets? Chris Angelico <rosuav@gmail.com> - 2011-08-17 10:45 +0100
              Re: Syntactic sugar for assignment statements: one value to multiple targets? gc <gc1223@gmail.com> - 2011-08-17 03:33 -0700
            Re: Syntactic sugar for assignment statements: one value to multiple targets? Terry Reedy <tjreedy@udel.edu> - 2011-08-17 12:12 -0400
            Re: Syntactic sugar for assignment statements: one value to multiple targets? MRAB <python@mrabarnett.plus.com> - 2011-08-17 17:55 +0100
            Re: Syntactic sugar for assignment statements: one value to multiple targets? Chris Angelico <rosuav@gmail.com> - 2011-08-17 18:25 +0100
            Re: Syntactic sugar for assignment statements: one value to multiple targets? "OKB (not okblacke)" <brenNOSPAMbarn@NObrenSPAMbarn.net> - 2011-08-17 19:13 +0000
        Re: Syntactic sugar for assignment statements: one value to multiple targets? Zero Piraeus <schesis@gmail.com> - 2011-08-17 16:07 -0400
    Re: Syntactic sugar for assignment statements: one value to multiple targets? Ethan Furman <ethan@stoneleaf.us> - 2011-08-17 12:52 -0700
    Re: Syntactic sugar for assignment statements: one value to multiple targets? John Pinner <funthyme@gmail.com> - 2011-08-18 02:26 -0700
    Re: Syntactic sugar for assignment statements: one value to multiple targets? Roy Smith <roy@panix.com> - 2011-08-18 09:13 -0400

Page 2 of 2 — ← Prev page 1 [2]

#11742

On Aug 3, 2:45 am, gc <gc1...@gmail.com> wrote:
> Hi everyone! Longtime lurker, hardly an expert, but I've been using
> Python for various projects since 2007 and love it.
>
> I'm looking for either (A) suggestions on how to do a very common
> operation elegantly and Pythonically, or (B) input on whether my
> proposal is PEP-able, assuming there's no answer to A. (The proposal
> is sort of like the inverse of PEP 3132; I don't think it has been
> proposed before, sorry if I missed it.)
>
> Anyway, I frequently need to initialize several variables to the same
> value, as I'm sure many do. Sometimes the value is a constant, often
> zero; sometimes it's more particular, such as defaultdict(list). I use
> dict() below.
>
> Target lists using comma separation are great, but they don't work
> very well for this task. What I want is something like
>
> a,b,c,d,e = *dict()
>
> where * in this context means something like "assign separately to
> all." I'm not sure that * would the best sugar for this, but the
> normal meaning of * doesn't seem as if it would ever be valid in this
> case, and it somehow feels right (to me, anyway).
>
> Statements fitting the form above would get expanded during parsing to
> a sequence of separate assignments (a = dict(); b = dict(); c = dict()
> and so forth.) That's all there is to it. Compared to the patterns
> below, it's svelte, less copy-paste-y (so it removes an opportunity
> for inconsistency, where I remember to change a-d to defaultdict(list)
> but forget with e), and it doesn't require me to keep count of the
> number of variables I'm initializing.
>
> This would update section 6.2 of the language reference and require a
> small grammar expansion.
>
> But: Is there already a good way to do this that I just don't know?
> Below, I compare four obvious patterns, three of which are correct but
> annoying and one of which is incorrect in a way which used to surprise
> me when I was starting out.
>
> # Option 1 (separate lines)
> # Verbose and annoying, particularly when the varnames are long and of
> irregular length
>
> a = dict()
> b = dict()
> c = dict()
> d = dict()
> e = dict()
>
> # Option 2 (one line)
> # More concise but still pretty annoying, and hard to read (alternates
> variables and assignments)
>
> a = dict(); b = dict(); c = dict(); d = dict(); e = dict()
>
> # Option 3 (multiple target list: this seems the most Pythonic, and is
> normally what I use)
> # Concise, separates variables from assignments, but somewhat
> annoying; have to change individually and track numbers on both sides.
>
> a,b,c,d,e = dict(),dict(),dict(),dict(),dict()
>
> # Option 4 (iterable multiplication)
> # Looks better, and if the dict() should be something else, you only
> have to change it once, but the extra brackets are ugly and you still
> have to keep count of the targets...
>
> a,b,c,d,e = [dict()] * 5
>
> # and it will bite you...
>
> >>> a[1] = 1
> >>> b
> {1: 1}
> >>> id(a) == id(b)
>
> True
>
> # Gotcha!
>
> # Other forms of 4 also have this behavior:
>
> a,b,c,d,e = ({},) * 5>>> a[1] = 1
> >>> b
>
> {1: 1}
>
> Alternatively, is there a version of iterable multiplication that
> creates new objects rather than just copying the reference? That would
> solve part of the problem, though it would still look clunky and you'd
> still have to keep count.
>
> Any thoughts? Thanks!

I hesitate to put this forward, as it smells and is probably
considered bad practice, but heh!

for char in 'abcdefg' :
    globals()[ char ] = dict()

does what you wanted.

Best wishes,

John
--

[toc] | [prev] | [next] | [standalone]

#11748

In article 
<16ea4848-db0c-489a-968c-ca40700f5806@m5g2000prh.googlegroups.com>,
 gc <gc1223@gmail.com> wrote:

> I frequently need to initialize several variables to the same
> value, as I'm sure many do. Sometimes the value is a constant, often
> zero; sometimes it's more particular, such as defaultdict(list). I use
> dict() below.

Keep in mind that when you do:

a = dict()
b = dict()

you are NOT initializing a and b to the same value.  You are 
initializing each of them to a different empty dictionary, which is very 
different from

a = b = dict()

I suspect you knew that, but it's worth mentioning.

> # Option 1 (separate lines)
> # Verbose and annoying, particularly when the varnames are long and of
> irregular length
> 
> a = dict()
> b = dict()
> c = dict()
> d = dict()
> e = dict()

This seems the best to me.  Simple, straight-forward, easy to 
understand.  What could be bad?  It may not be elegant, but if I could 
have a nickel for every hour I've wasted trying to understand elegant 
code, I'd be a rich man.  I can understand the above code in an instant, 
even at 2 AM juiced up on sugar and caffeine.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web