"sins" (aka, acknowledged language problems)

Neel Krishnaswami neelk at brick.cswv.com
Sat Dec 25 20:14:50 EST 1999


skaller <skaller at maxtal.com.au> wrote:
>Alex Martelli wrote:
>
>> But why can't I change those 4 lines to, say:
>>     while line := inp.readline():
>> using the suggested ":=" operator that I've
>> seen mentioned now and then?  Or, maybe
>> even better, "while line from inp.readline()"
>> or other variants suggested in the past.
>
>Ok. You have set me a problem here. I need more cases to examine!

This is a failure of data structure, not of syntax. What's needed
is a way to write 

  for foo in file.readlines():
      ...
  
without allocating an entire list. IOW, we want to write:

 for foo in file.xreadlines():
    ...

just like we currently write

 for i in xrange(100):
    ...

So the hypothetical xreadlines() method should return an object 
that reads one additional line from the file each time it is called.

The general problem that needs fixing is that Python really needs a
better iteration protocol. (I understand that Guido has worked one
out, but hasn't yet implemented it. You may want to contact him so
that the two of you can use Viper as a test bed for advanced Python
ideas.) 

>Unfortunately, new control structures are easy to introduce,
>but we don't want to litter the language with TOO many.
>Here's one that is going in to Viper, when I can
>come up with the right keyword:
>
>	ifor k,v in e: ..
>
>where k and v are the keys and values of a dictionary,
>or, the indices and values of a sequence. This is
>commonly needed, instead of:
>
>	for k in d.keys():
>		v = d[k]
>		..

In Cpython, there is the items() method on dictionaries,
so you can write:

  for key, val in dict.items()
     ...

There's nothing like it for tuples and lists, but that should be
fixed.


Digression:

As a general rule, syntax is a bad thing, to be avoided whenever
possible. Calls for additional syntax are typically a sign that
one of the basic operations of the semantics needs generalization.

Additional syntax adds cruft that makes that generalization doubly
harder to see. One, the immediate sop silences the people being
bothered, so you won't think any more about the problem until it crops
up again in a seemingly-different context. Two, adding special syntax
makes it harder to build the appropriate generalization, because the
special syntax reduces the regularity of the language.


Neel



More information about the Python-list mailing list