On Saturday 25 October 2003 18:03, David Eppstein wrote:
...
> > > pos2d =
> > > dict([(s,(positions[s][0]+dx*positions[s][2],positions[s][1]+dy*posit
> > >ions[s ][2]))
> > > for s in positions])
...
> > pos2d = {}
> > for s, (x, y, delta) in positions.iteritems():
> > pos2d[s] = x+dx*delta, y+dy*delta
> >
> > seems just SO much clearer and more transparent to me.
...
> I like the comprehension syntax so much that I push it harder than I
> guess I should. If I'm building a dictionary by performing some
> transformation on the items of another dictionary, I prefer to write it
> in a way that avoids sequencing the items one by one; I don't think of
> that sequencing as an inherent part of the loop.
>
> Put another way, I prefer declarative to imperative when possible.
Hmmm, I see. List comprehensions are in fact fully imperative (in
Python), but they may be "thought of" in quasi-declarative terms;
I do see the allure of that. Thanks for clarifying!
We DO have to keep in mind this source of attractiveness in
comprehensions over simple loops, I think.
> Let's try to spread it out a little and use intermediate variable names:
> pos2d = dict([(s, (x + dx*z, y + dy*z))
> for s,(x,y,z) in positions.items()])
>
> Better?
Yes, it does seem better to me. And with generator expressions,
dropping those slightly intrusive [ ... ] would be another little helpful
step. Once you can write:
pos2d = dict( (s, (x+dx*z, y+dy*x) for s,(x,y,z) in position.items() )
I don't think the further slight added value in clarity in being able
to write a "dict comprehension" directly, e.g.
pos2d = { s: (x+dx*z, y+dy*x) for s,(x,y,z) in position.items() }
would be enough to warrant the addition to Python's syntax.
Alex
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4