[Python-Dev] PEP 204 - Range Literals

[esr@thyrsus.com]

Thomas Wouters <thomas@xs4all.net>:
> I wrote this using 'joe', which is still my favorite editor, because despite
> many, many minutes of effort, xemacs simply refused to do what I wanted it
> to do. How do you 're-flow' a paragraph,

Esc-g

>                                 for instance, or enable word
> wrapping, or better yet: word wrapping with autoindentation ?

Esc-x set-variable auto-fill 1

To always enable it in text mode, add

(setq text-mode-hook
   '(lambda () (auto-fill-mode 1)))

to your .emacs file.  Emacs will detect your indent level and honor it.

>     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.

But all this is academic until Python has continuations, really.  For
finite cases eager vs. lazy only makes a difference in the timing of
computations, not their result.  While this could be semantically 
significant for some list comprehensions, it won't be for range
literals.

(You might want to go look at Haskell or Icon to learn more about
how lazy and eager evaluation interact.)
     
>     Should it be possible to mix range syntax with normal list
>     literals, creating a single list, like so:
> 
>     >>> [5, 6, 1:6, 7, 9]
>     to create
>     [5, 6, 1, 2, 3, 4, 5, 7, 9]

I'm completely neutral on this.
 
>     However, as the syntax and semantics of list comprehensions are
>     still subject of hot debate, these issues are probably best
>     addressed by the `list comprehensions' PEP.

Agreed.
     
>     Range literals accept objects other than integers: it performs
>     PyInt_AsLong() on the objects passed in, so as long as the objects
>     can be coerced into integers, they will be accepted.  The
>     resulting list, however, is always composed of standard integers.
> 
>     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:
>     
>     >>> [ 1L : 2L<<64 : 2<<32L ]    
>     >>> ["a":"z":"b"]
>     >>> ["a":"z":2]
>     
>     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.

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.

>     The PyList_FromRange() and PyList_GetLenOfRange() functions need
>     to be classified: are they part of the API, or should they be made
>     private functions ?

No opinion.
-- 
		<a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a>

...the Federal Judiciary...an irresponsible body, working like gravity
by night and by day, gaining a little today and a little tomorrow, and
advancing its noiseless step like a thief over the field of
jurisdiction until all shall be usurped from the States; and the
government of all be consolidated into one.