Thank you - it worked! I'm glad you are no longer sleepy!
Actually I wanted the naming to remain consistent with the other loops
So the name of the function/method (it is in a class) caused the use of
the underscore
locChoices == location choices
def locChoices(self) cause me to use loc_Choices in the code.
I am torn about the readability of the code - at least in my mind I can
read the loop a lot easier than I can read the comprehension.
Of course I considered the use of a function where I passed the required
parameters. But the issue is the access to the data - that getDataSet()
was a performance hit when I used a passed parameter. I could have
opened/accessed/retrieve the data during the opening but thought it best
to use a lazy data access as needed.
Today was not really about performance but more about learning to use
the comprehension. You see I did attempt to do create the
comprehension. But after seeing your code I realized that I had the '['
and the '{' confused. I believed I had to use '{'. I just reviewed a
tutorial off the net and that was what they were using.
Thanks again,
Johnf
Just because this morning I needed something to kick-start my sleepy
brain into being able to "think"...
When most people think of 'multiples' in the context of
list-comprehensions, they are talking about "nested-loops" - which are
easy-enough (or at least, well-documented).
However, I've often wondered about the multiple being on the
'left-hand side' of the equation/expression, and whether that is even
possible?
It is!
Thus:
python3
Python 3.6.8 (default, Mar 21 2019, 10:08:12)
[GCC 8.3.1 20190223 (Red Hat 8.3.1-2)] on linux
Type "help", "copyright", "credits" or "license" for more information.
# build the data-structure (I hope)
>>> d1 = { 'pkid':1, 'facility':'here' }
>>> d2 = { 'pkid':2, 'facility':'there' }
>>> d3 = { 'pkid':3, 'facility':'nowhere' }
>>> locDS = ( d1, d2, d3 )
# let's check that the data-format is as-described?
>>> type( locDS )
<class 'tuple'>
>>> for row in locDS: print( row )
...
{'pkid': 1, 'facility': 'here'}
{'pkid': 2, 'facility': 'there'}
{'pkid': 3, 'facility': 'nowhere'}
# are we on the right track?
# this is the original code and approach
>>> loc_Choices = [ '<None>' ]
>>> locKeys = [ 0 ]
>>> for row in locDS:
... loc_Choices.append( row[ 'facility' ] )
... locKeys.append( row[ 'pkid' ] )
...
# which (I hope) shows the existing (and desired) results
>>> print( loc_Choices )
['<None>', 'here', 'there', 'nowhere']
>>> print( locKeys )
[0, 1, 2, 3]
# we can do the list inits, cf leaving it to the list comprehension
>>> loc_Choices = [ '<None>' ]
>>> locKeys = [ 0 ]
# but how might we achieve this using a (single) list comprehension?
>>> [ [ loc_Choices.append( row[ 'facility' ] ), locKeys.append( row[
'pkid' ] ) ] for row in locDS ]
# in (proper) code, I'd format this over two lines (at least)
# correct me if I'm wrong, but these o/ps will
# 'disappear into the ether' when run within a pgm...
[[None, None], [None, None], [None, None]]
# leaving us with 'the proof of the pudding'
>>> print( loc_Choices )
['<None>', 'here', 'there', 'nowhere']
>>> print( locKeys )
[0, 1, 2, 3]
>>>
Possible considerations:
1 some sample data would have eased the way/its lack leaves room for
misinterpretation
2 a list comprehension normally executes more quickly than the
traditional (long-form) multi-line code-block. However, it would be
worth measuring that on your particular machine h/w and Py__version__.
The other 'efficiency' is readability, but "elegance" is largely a
matter of (personal) taste. So that ('mine-field') I leave to you...
3 taking the multi-line code-block and splitting it into TWO separate
(consecutive) list comprehensions (one for loc_Choices and the other
for locKeys) will most-likely be noticeably MORE 'expensive'
4 it is no matter if row/the locDS tuple dict-elements contain more
key-value pairs
5 during code review, my colleagues would delight in criticising the
choice of names such as locKeys - describing them as "JavaScript" (a
'dirty word' to some), loc_Choices as contrary to PEP-8 ("flake", or
whatever), etc - despite that I have a little 'set' of abbreviations
with which I do the same, eg locNR. YMMV!
6 however, this simple boy will venture criticism of the inconsistency
in using the underline word-separator, eg locKeys but loc_Choices.
Even more potential for confusion: locChoices and loc_Choices!?
7 consider the data structures (outside of our view, here). Assuming
there are more elements in each 'loc dict', might it be just as easy
to leave the two pertinent elements 'there' and iterate over locDS
when actually applied. Alternately, perhaps it might be better to
construct a dictionary with the 'pkid's as keys and the 'facility' as
values for direct-access application? Not knowing how the structure(s)
will be utilised makes this pure speculation!
8 any?every time "similar loops" are found, re-factor to a function
(let's see if that philosophy kicks-off a retort or two...)
9 was it Knuth who described "premature optimisation" as "evil"?
Certainly I'm a believer in 'make it work before you make it better'.
So, (after all that!) what are we really achieving here? With such
quantities, is it critical to 'save time'? If so, is this part of the
code really the greatest time-sink?
(and we're back to the 'readability' consideration, previously mentioned)
Thanks, for the provocation into answering this long-held question -
and for the fact that my brain isn't sleepy any longer.
(mind you, such exertion suggests it must be time for a tea-break)...
_______________________________________________
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
