> > > > I've just had a thought. Maybe it would be less of a mess > > > > if what we are calling "iterators" had been called "streams" > > > > > > Possibly -- I did use the "streams" name often in the tutorial > > > on iterators and generators, it's a very natural term. > > > > OTOH in C++ and Java, "stream" refers to an open file object (to > > emphasize the iteratorish feeling of a file opened for sequential > > reading or writing, as opposed to the concept of a file as a > > random-access array of bytes on disk). > > ...and in Unix Sys/V, if I recall correctly, it refered to an allegedly > superior way to do things BSD did with sockets (and more). Any > nice-looking term will be complicatedly overloaded by now. I > think "seborrea" is still free, though (according to some old Dilbert > strips, at least). Bah. I rather like the idea of using "stream" to denote the future rewritten I/O object, so I don't want to use it for iterators. > Which leads us back to my "this is rather academic" statement: > don't we need to stick with stdio to support existing extensions > which use FILE*'s, anyway? We'll need to support the old style files for a long time. But that doesn't mean we can't invent something new that does't use stdio (or perhaps it uses stdio, just doesn't rely on stdio for various features). --Guido van Rossum (home page: http://www.python.org/~guido/)
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