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!