[Python-Dev] PEP 204 - Range Literals

[Thomas Wouters]

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!