On Sun, Nov 24, 2002 at 11:12:51AM +0100, Alex Martelli wrote: > > I think the question becomes whether we want to start adding modules that > > service specific language abilities like generators. We have the string > > module, but that is on its way out (right?). There is no module for list, > > dict, or tuple tricks or helper functions. There is also no module for > > No, but that's because lists and dicts (and strings) package their > functionality up as methods, so there's no need to have any supporting > module. I've always felt it counter-intuitive and even confusing that lists and dicts are built-in types with methods, whereas iterators are just an expected interface with no user-visible methods apart from 'next', which is also a magic name (a magic name with no __??). The lack of common implementational part between iterator forces us to use a module to collect useful operations, which goes against the current everything-as-a-method trend. I wish we would have a standard built-in 'iter' type with a standard set of methods, instead of the current 'iter(x)' which is essentially just 'x.__iter__()' and returns anything. If 'iter' were a built-in type it could provide additional methods, e.g. a, b, c = iter(x).peel(2) as an equivalent to the proposed iterator-returning 'a,b,*c=x'. A similar option would be to require that iterator objects be instances of subtypes of 'iter'. Well, it's probably too late to change that kind of thing anyway. Armin.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4