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.