"sins" (aka, acknowledged language problems)

[skaller]

Alex Martelli wrote:
 
> So, maybe I can move down a notch and try fishing
> for Python things which at least "annoy" a "vast"
> (carefully vague term:-) number of Pythonistas,
> without compensating advantages to "many" others.
> 
> E.g., "lack of full GC", since it can be rephrased as
> "with care, you can control where and when your
> objects are finalized", would not qualify!-)

	Available in Viper and JPython.
 
> The type/class split has been mentioned (it does
> not affect most people, it helps none, it hinders,
> albeit slightly, most of those who are trying to
> do certain advanced things).

	Available in Jpython. Unification via
a different route in Viper.
 
> Would this also apply, to a weaker but broader
> extent, to the lack of assigning-operators, 

	Available in Viper.

[Story of how easy it was to implement a simply idea simply 
in python ..]

> And YET... human nature being what it is...
> I cannot help but keep staring at the result:

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

> OK, OK, this is no doubt the kind of thing
> that can be classified as a very pet peeve,
> rather than as a "deadly sin"!-).

	Actually, I disagree. I think this
is a deadly sin. It manifests in python, where
a lot of extraneous variables and statements
are needed which actually make code harder
to read because you need to read lots
of simple bits and reason how they fit togther,
insead of just 'seeing' it.
 
> 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.

> 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
> on an example such as these, such warts
> as having to take 4 lines for such a very
> common idiom may stand out sharply by
> contrast, particularly since single-line
> idioms for this sort of thing are so common
> in languages otherwise far less powerful,
> AND since Python itself would easily allow
> a single-line idiom if the semantics was
> a slightly different one of roughly similar
> frequency.

	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.

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

or, worse,

	for i in len(seq):
		v = seq[i]

or even:

	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 'break'
in python isn't labelled, and there is no goto,
so you end up having to use exceptions ... Uggghhhh.

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

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850