"sins" (aka, acknowledged language problems)

[William Tanksley]

On Fri, 17 Dec 1999 10:20:46 +0100, Alex Martelli wrote:
>Tim Peters is kind enough to respond to my request
>for an URL about acknowledged Python defects with
>detailed considerations boiling down to:

>	lots of tiny pet peeves, but no consensus
>which seems to be a very accurate assessment.

No it's not -- if there was no consensus I wouldn't be agreeing with it.
But I am agreeing, so there must be consensus.  Therefore it can't be true.

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

Okay.

First, Python doesn't have any way to transfer control statically; the
only control transfer statement is exceptions, which are not the right
tool sometimes, because they get thrown dynamically.  We could use named
loop-breaks.

Second, Python uses 'else' in some VERY bizarre ways.  Here's a quick way
to memorize the proper way to use the 'else' statement with 'for': "forget
it."  (FYI, 'else' clauses on 'for' execute only if the loop terminates
normally, which only doesn't happen if a break executes.)

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

I mainly agree, although I suspect that's managable.  Someday, perhaps;
it's no concern to me so long as I've got a way to implement weak
pointers.  Of course, I haven't ever needed those, but if I do I seem to
recall an implementation :-).

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

Shrug.  Somewhat.  It doesn't really matter to me, as long as it's not
taken too far -- nothing like Java's 'final' keyword (which allowed a
library programmer to declare that no users would ever want to subclass
his code, and worst of all was advertised as a way to SPEED UP code, ugh).

>Would this also apply, to a weaker but broader
>extent, to the lack of assigning-operators, an
>"expression" kind of assignment, increment and
>decrement in particolar, or other issues of the 
>expression/statement split?

Hmm...  I've never really cared :-).

Take a look at Ruby -- it doesn't really have an expression/statement
split.  At least not in the same sense.

>Alex-the-Python-newbie

-- 
-William "Billy" Tanksley, in hoc signo hack