"sins" (aka, acknowledged language problems)

[Alex Martelli]

John Skaller writes:

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

Please see my answer to Neel Krishnaswami --
I think I've come upon a good solution to the
dilemma -- a simple wrapper class (small set
of wrapper classes, actually) that will let me
use elegant "for/in" syntax in these cases,
without (I think/hope) substantial overhead.
Tim's responses were of course precious in
getting me to think along the right lines.


> > And yet, what else can you expect when a
> > language lets a newbie develop in 15 minutes
> > a task that by rights should take quite a few
> > hours...?  
> 
> You can expect other ways of doing
> something which you would learn later.

And I got that -- even better, perhaps, I got
the added intellectual stimulus of seeing that
the solution "was" already "in" the language,
yet I had to exert a modicum of effort to see
it and package it up.  Didactically speaking,
this IS something of an ideal outcome!-)

(Despite which, I'd still like to see this wrapper
idea [a] either shot to pieces because of some
subtle problem I can't see, or [b] made more
available as a 'standard' idiom, perhaps in an
example or tutorial).


> > Another way to put it -- when a language
> > manages to combine expressiveness, clarity,
> > concision, and power, to the extent that
> > Python exhibits even in a newbie's hands
    [snip]
> I agree with you entirely.
> What happened to me was: I needed to do a lot
> of these thing SO often, that the resulting
> code was more cluttered than the equivalent
> C would have been.
> 
> I have introduced ONE entirely
> new statement into Viper (my version of Python):
> 
> with: ...
> do: ...
> 
> in which the variables introduced in the with part
> are available in the do part, and then forgotten.
> This adds to the lexical scoping Viper provides,
> to correct Python's lousy scope control.

Now that sounds extremely interesting.  Python's
scopes are extremely simple, but perhaps this IS
too simple, as you claim.

In my newbie status, in your shoes, I would
probably introduce a temporary dictionary to
fake out a scope, but I realize readability
would suffer -- "d['x']" is more verbose than
plain simple "x" by enough to matter.

Perhaps a solution might hinge around extending
the "exec" statement, which already provides
for explicitly supplied local and global dictionaries,
but currently only executes a string or a code
object.  If "exec" would let me express the "code
object to be executed" as a plain suite of normal
Python statements, we'd be there, wouldn't we?

I.e., rather than your:
    with:
        x=23
        y=45
    do:
        z=x+y

we might instead write:

    exec:
        z=x+y
    in {'x':23, 'y':45}

or some similar variation thereof.  This might fit
better with existing constructs, requiring no new
keywords, and perhaps providing better control
thanks to the explicit supplying of the dictionaries
being used/affected...?


> Unfortunately, new control structures are easy to introduce,
> but we don't want to litter the language with TOO many.

Absolute agreement here!

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

Neel Krishnaswami already suggested "items" for the
dictionary case, and I proposed a tiny wrapper that
would let you write
    for k,v in seqenum(e):
        ...
for the sequence case.

> i = 0
> while 1:
> v = seq[i]
> ..
> i = i + 1
> if i>= len(seq): break 
> 
> The latter is almost essential when generalising
> to parallel sequence processing. 

But "for" already internally provides the semantics
of starting the key from 0, stepping it, and bailing
out (albeit when it gets an IndexError, rather than
based on a test of "len") -- the idea of having a
wrapper can be seen as an attempt to reuse these
parts (and the nice semantics that goes with them).

What are the drawbacks of supplying the needed
wrappers, rather than adding new syntax...?

> But 'break'
> in python isn't labelled, and there is no goto,
> so you end up having to use exceptions ... Uggghhhh.

Labeled breaks might well be a good idea, I guess.


> Of course, most functional languages provide coherent
> and very concise ways of doing this kind of thing.
> So it is fairly well known WHAT is required, just not
> what syntax to use in a 'pythonic' version. :-)

What about the "for x in y" syntax -- that seems neat
to me, as long as we can supply the y appropriately:-).


Alex