This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author mark.dickinson
Recipients isoschiz, mark.dickinson, meador.inge, pconnell, pitrou, serhiy.storchaka, skrah
Date 2013-04-21.11:23:56
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1366543436.95.0.426092084487.issue17804@psf.upfronthosting.co.za>
In-reply-to
Content
This seems like an attractive idea.  There's definitely a need for repeated unpacking with the same pattern, and I agree that putting the repetition into the pattern is suboptimal (not least from the point of view of caching structs).

One thing that feels a bit unorthogonal is that this is doing two things at once:  both allowing for repetition of a pattern, and also adding the lazy iteration.  I'd guess that there's also a use-case for allowing repetition but not returning an iterator;  but then that's easily covered by list(iter_unpack).

+1 from me.

Hmm;  the name.  'iterunpack'?  'iter_unpack'?  'unpack_stream'?  'unpack_all'?

Would we want something similar for packing, too?  I guess that's effectively covered by b''.join(s.pack(item) for item in ...).
History
Date User Action Args
2013-04-21 11:23:56mark.dickinsonsetrecipients: + mark.dickinson, pitrou, skrah, meador.inge, serhiy.storchaka, pconnell, isoschiz
2013-04-21 11:23:56mark.dickinsonsetmessageid: <1366543436.95.0.426092084487.issue17804@psf.upfronthosting.co.za>
2013-04-21 11:23:56mark.dickinsonlinkissue17804 messages
2013-04-21 11:23:56mark.dickinsoncreate