On Tue, Jul 18, 2000 at 11:08:23AM -0400, esr@thyrsus.com wrote: > Thomas Wouters <thomas@xs4all.net>: > > One possible solution to the discrepancy of requiring the `end' > > argument in range literals is to allow the range syntax to create > > a `generator', rather than a list, such as the `xrange' builtin > > function does. However, a generator would not be a list, and it > > would be impossible, for instance, to assign to items in the > > generator, or append to it. > Not so. Appending to the generator object, or assigning to it, would > simply force eager rather than lazy evaluation of the generator. This > would have to throw an exception on infinite generators. > (You might want to go look at Haskell or Icon to learn more about > how lazy and eager evaluation interact.) Well, I had an xrange() like generator in mind. There currently isn't a very good way for a generator to turn itself into a list, unless it's some kind of polymorphic object that behaves one way until it gets assigned to... In which case I wouldn't want to meet it in a dark alley, alone, at night, without my language reference printout. I don't have the human resources to do an in-depth study of generators (or other languages) right now. The idiots I have to cooperate with at work (from our parent company) are sucking all life out of me, in a bad way ;P > > Should range literals create a list of the passed-in type ? It > > might be desirable in the cases of other builtin types, such as > > longs and strings: [..] > > However, this might be too much `magic' to be obvious. It might > > also present problems with user-defined classes: even if the base > > class can be found and a new instance created, the instance may > > require additional arguments to __init__, causing the creation to > > fail. > +1. Whenever possible, builtins ought to do something intuitive with > any type that is passed in, and range literals have an obvious and > intuitive definition for any well-ordered base type. I think it > would be more surprising if this did *not* work for well-ordered > scalar types. Well, I guess I agree. The above was just a bit of 'Red Red Wine' induced brainstorm, but on reflection it does seem logical. The one-dimensionality of range and xrange always bothered me ;) The biggest problem is, however, how to create a 'range' of a specific type of object, given a start, step and end object. A new PyNumberMethods member 'int_range' ? Or some kind of 'newobject_fromnumber' protocol ? How about we checkin the current patch, which does what the PEP describes, and continue the PEP for the sake of these issues ? :) > I don't view the issue for user-defined classes as a showstopper; > it would be OK, and semantically reasonable, to throw an exception > in this case. Agreed. And thanx for the emacs pointers ! :) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
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