George Sakkis wrote: > Given the overly negative reaction to a base iterator type, I withdraw > the part of my proposal that suggests this type as the base of all > iterators. Instead I propose a builtin Iter (or even better iter, if > there is no objection to change iter's current behavior) as an OO > replacement of the (functional) itertools API. In other words, instead > of: > > from itertools import chain, islice, groupby > for k,sub in groupby(chain(islice(it1, 1, None), islice(it2, 5)), > key=str.lower): > print k, list(sub) > > you will write: > > for k,sub in (Iter(it1)[1:] + Iter(it2)[:5]).groupby(str.lower): > print k, list(sub)
Uhuh. And why would this more important than adding, say, Array, AtExit, Bz2, Cgi, CgiTB, Cmath, Code, Codecs, Collections, Copy, Csv, DateTime, Decimal, ElementTree, ErrNo, Ftplib, Gc, GetOpt, GetText, Glob, Gzip, HashLib, HMac, Inspect, Locale, Logging, Marshal, Math, Mmap, Operator, Os, OsPath, Pickle, Platform, Random, Re, Select, ShUtil, SmtpLib, Socket, Struct, SubProcess, Sys, TempFile, Threading, Time, Traceback, UnicodeData, UrlLib, UrlLib2, UrlParse, Warnings, WeakRef, XmlDom, XmlSax, ZipFile, or Zlib builtins? Most of these are definitely used a lot more often than itertools in typical Python programs... </F> _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
