Thought on PEP 204 and 276

[Steve Horne]

Replying to the main replies...

On Mon, 27 May 2002 15:45:28 -0500, Gustavo Cordova
<gcordova at hebmex.com> wrote:

>class _Ints:
>  def __init__(self): pass
>  def __getitem__(self, range):
>    if type(range) != SliceType:
>      raise ValueError("The range must be a slice!")
>    return xrange(range.start, range.stop, range.step)

I'll admit that I didn't think of that, but Ints[a:b:c] has no
advantage over range(a,b,c). The real issue is not...

  for i in range(10) :

but...

  for i in range(len(list)) :

and other, even longer, expressions where the range becomes annoying.
While 'annoying' is subjective, it's a common enough view to have
given rise to a number of PEPs so it's not just me.


On 27 May 2002 22:11:02 +0200, Chris Liechti <cliechti at gmx.net> wrote:

>but all those don't make a real imprevement (some would say the would make 
>the language worse).

For most of the 'additional' cases, I agree - which is why I said
'KISS' - but the basic case is as clear as slices yet more concise. It
does duplicate range, but sometimes 'more concise' means 'more
readable'.


>and in the end, >>> import this: "explicit is better than implicit"

In general I agree, but the only language that is fully explicit is
XML. I kind of like the idea of XML as an intermediate language, or as
markup for a 'rich' source language requiring a specialist editor, but
not as directly edited source code.

If 'explicit is better than implicit' for ranges, why not for slices?
- we could easily have an explicit slice function, yet an implicit
notation was used instead.


>what would be more useful is the ability to write 
>different open/closed itervals, such as 0<i<=7 -> range(1,8).

I've seen that and in some ways I like it, but if support for open and
closed ranges is needed, then limiting it purely to for loops seems a
little odd.

I'd suggest having a couple of range-like library functions,
'inclusive' and 'exclusive' (or similar) to support these
requirements, especially as the most common case will be a replacement
for the basic...

  for i in range(1, 10) :

which can become...

  for i in inclusive (1, 9) :

or...

  for i in exclusive (0, 10) :

with no problem at all. It's also more explicit than your idea ;-)

Finally, it fits in better with the existing 'range' and 'zip', and
the soon-to-arrive 'enumerate'.


On Mon, 27 May 2002 21:33:47 +0200, holger krekel
<pyth at devel.trillke.net> wrote:

>The reasoning in PEP 276 is IMO somewhat superseded by PEP279 (enumerate).
>For example in PEP276 this code is given:

The only things I'm not sure I like about enumerate are...

- the name (admittedly I can't think of a better one, especially not
  after reading the PEP)
- it's not immediately obvious to people used to using more
  traditional for loops.

Mention it in the tutorial where the for loop is introduced and I
guess those minor problems disappear.

-- 
Steve Horne
steve at lurking.demon.co.uk