osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

printing to stdout


On Mon, 20 Aug 2018 08:19:12 +1000
Cameron Simpson <cs at cskk.id.au> wrote:

[sorry for late reply]

> Someone else has descibed zip tersely: it pairs it the elements of 2
> lists. In fact it joins up matching elements of an arbitrary number
> of iterables. Here is a 3 iterable example:
> 
>     >>> zip( (1,2,3), (4,5,6), (7,8,9) )
>     <zip object at 0x10aa4ce88>
>     >>> list( zip( (1,2,3), (4,5,6), (7,8,9) ) )
>     [(1, 4, 7), (2, 5, 8), (3, 6, 9)]
> 
> See that is has collected the first element of each tuple, then the
> second and so forth?

Yep, an image or an example says more than 1000 pages of explanation
 
> In my sentence above, "iterable" means any object you can iterate
> over - any object you could use in a for-loop. So, obviously, a list
> as in your programme. And also a tuple like (1,2,3) as in the example
> above (a tuple is an unmodifiable list). ANd any number of other
> things that will yield a sequence of values.
> 
> In Python 3 (which you're using) zip returns a lazy object, which
> does the zipping as you request the values. That is why the example
> shows a base "zip()" returning a "zip object" - we hand it to list()
> to get an actual list of all the values. This is fast (instant return
> of the zip object without doing much work) and cheap in memory (no
> need to make a huge result if you're zipping big lists) and
> cheap in time (no need to make the whole result if you're only using
> the first part of it).
> 
> So, to the code using the zip:
> 
>   for device_nr, (pcf, pcf_value) in enumerate(zip(list_pcf,
> list_pcf_value)):
> 
> The inner zip yields (pcf, pcf_value) pairs from zipping list_pcf and 
> list_pcf_value, an iterable of:
> 
>   (pcf[0], pcf-value[0]), (pcf[1], pcf_value[1]), ...
> 
> and you can write a for loop like this:
> 
>   for pcf, pcf_value in zip(list_pcf, list_pcf_value):
> 
> to deal with each of those pairs in turn.
> 
> However, since you also need the index (device_nr) in order to update 
> list_pcf_value:
> 
>   list_pcf_value[device_nr] = output
> 
> we then hand the whole thing to enumerate:
> 
>   for device_nr, (pcf, pcf_value) in enumerate(zip(list_pcf,
> list_pcf_value)):
> 
> The enumerate does just what the previous one did, yields pairs of
> (index, value). Each value is a pair from the zip, so it yields:
> 
>   (0, (pcf[0], pcf-value[0])),
>   (1, (pcf[1], pcf_value[1])),
>   ...
> 
> and Python's tuple unpacking syntax is fairly generous, so you want
> write:
> 
>   device_nr, (pcf, pcf_value) = (0, (pcf[0], pcf-value[0]))
> 
> and you can stick that in the for loop, getting the syntax you're
> using in the programme:
> 
>   for device_nr, (pcf, pcf_value) in enumerate(zip(list_pcf,
> list_pcf_value)):

Well, that's a nice and clear explanation, at the prompt I played a bit
with the enumerate and zip functions and after all it's quite simple :)

> >The code is now as follows:
> 
> Much nicer. A few tiny nit picks:

[..] changes applied

> >while True:
> >  if GPIO.input(23) == 1: # if still 0, another event has occurred
> >    GPIO.wait_for_edge(23, GPIO.FALLING)
> 
> Can the GPIO ops also raise IOErrors? Just wondering.

Probably, sounds logigal, the GPIO pin is read and if something is
wrong it will generate an I/O error. 

R.

-- 
richard lucassen
http://contact.xaq.nl/