[Python-ideas] Integrate some itertools into the Python syntax

Chris Barker chris.barker at noaa.gov
Thu Mar 24 17:20:27 EDT 2016


I haven't seen enough in this conversation to persuade me that we need more
built ins, but:

I recently taught Intro to Python using py3 for the first time recently,
and really noticed that while the most obvious difference (at the beginning
level)  is that print is a function now, that is only annoying, but didn't
confuse anyone at all. (and Unicode because a non-issue -- yeah!)

However, where I found things changed in a conceptual way is the movement
from sequences to iterables in many places: zip() dict.keys(), etc....

I found that my approach of focusing a lot on sequences -- you can iterate
over them, you can slice them, you can.... seems out of date now, and I
think lead to confusion as folks got a bit more advanced.

Py2 was all about sequences -- py3 is all about iterables, and I think I
need to start teaching it that way -- start with iterables, and introduce
sequences as a special case of iterables, rather than starting from
sequences, and introducing iterables as a more advanced topic.

I understand the focus on iterables -- for performance reasons if nothing
else, but I think it does, in fact, make the language more complex. and I
think we should think about making the language more iterable-focused.

This certainly comes up with this discussion -- if Python is all about
iterables, then some of itertools should be more discoverable and obvious.

And it came up in another recent thred about a mechanism for doing
something after a for loop that didn't loop -- in that case, for sequences,
the idiom is obvious:

if seq:
    do_the_for_loop
else:
    do_somethign else since the loop wont have run.

But when you plug in an arbitrary iterable into that, it doesn't work, and
there is no easy, obvious, and robust idiom to replace that with. I don't
know that that particular issue needs to be solved, but it makes my point
-- there is much to be done to make python really about iterables, rather
than sequences.

For my part, I would like to see iterables look more like sequences -- I
know it's going to be inefficient in many cases to index an iterable, but
it i really less efficient that wrapping list() around it? One tiny example:

I often need to parse text files, which I used to do with code like:

for line in the_file.readlines():
    ....

then, particulary  when debugging, I could do:

for line in the_file.readlines()[:10]:
    ....

and just work with the first ten lines....

but now that file objects ar iterable, I can do:

for line in the_file:
    ....

much nicer!

but it breaks when I want to debug and try to do:

for line in the_file[:10]:
   ...

arrgg! files are not indexable!.

(and by the way, not only for testing, but also when you really do want the
next ten lines from the file -- maybe it's a header, or...)

Sure, I have plenty of ways to work around this, but frankly, they are all
a bit ugly, even if trivial.

So maybe there should be some ability to index / slice iterables?

But aside from that -- just the idea that looking at how to make iterable a
more "natural" part of the language is a good thing.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160324/4bf3708d/attachment-0001.html>


More information about the Python-ideas mailing list