[Python-Dev] Re: PEP 285: Adding a bool type

[Alex Martelli]

Robin Becker wrote:
        ...
> The great designer has several times expressed his desire to cripple
> python's more dynamic features. Many recent changes have been in the
> wrong direction eg the restriction on imports in functions etc.

Any restriction on "from wherever import *" and other namespace-polluting
things is very much in the RIGHT direction -- and has nothing to do with
"crippling Python's more dynamic features".

While Python scales quite well up and down the range of program sizes,
the size ranges of most interest to me are scripts of a few tens of
SLOCs, modules of about 100-1000 SLOCs, packages of about 1000-5000
SLOCs, subsystems of a few tens of thousand SLOCs, applications of
about 100 to 500 thousand SLOCs.  SLOC=Source Line Of Code, roughly
the equivalent of a Python "logical line" with common sense adjustmenta
("if x: print y" being 2 SLOCs whether you break the line or not:-).

These are *Python* SLOCs, roughly 15 statements/FP by my estimate
(Capers Jones might disagree, as he estimates 21 statements/FP for
Perl, but I also evaluate Perl at roughly 15 stat/FP on my own code),
versus a range of around 40 to 120 statements/FP for C++ depending
on how the latter is used (C.J. estimates 53 for C++ and Java, 128 for C); 
let's say you need to multiply by a factor between 3 and 8 (most
likely around 5) to get roughly equivalent program/module size
ranges for "typical" C++ or Java.

Substantial reductions in dynamic functionality would substantially
reduce language-level (increase statements per FP).  But at the larger
size ranges (as opposed, maybe, to the small scripts), namespace
pollution is a SERIOUS problem.  eval or (shudder) exec without
specified dictionaries, 'from blah import *', tampering with
__builtins__ -- each is a hard-to-debug subtle interaction just
waiting to bite.  Python has never had some of the worst features
in this regard, such as the ability to modify existing built-in
classes a la Smalltalk/Ruby -- superficially very attractive, but
really requiring lots of programmer discipline to avoid.  Thanks be.


> I believe the fundamental choice here is more about style than substance
> as it's clear this addition adds little and effects much. Of course

Hard to disagree on this one (except maybe s/effect/affects/ --- a
subtle nuance of meaning, but an important one:-).

> there are similarities to the 'only one way to do things' syndrome in
> this proposal.

Nothing wrong with "one obvious way, and preferably only one".  It's
an ideal, of course; as long as you need to ensure that a+b and b+a
give the same results for numbers a and b, you can't really approach
that ideal all that closely, for example (well, one COULD add a
syntax constraint about additions of variables having to have the
variables in alphabetical order, I guess -- and maybe emit a warning
[suppressable on request] otherwise...).


> If we slavishly give people dictator status we get dictators. GvR
> designed a reasonable language and it has improved up to now. I'm fairly
> sure adding this will not improve things.

I'm also "fairly sure" on the specifics -- but I'm even surer that,
whatever the technical and conceptual issues in one specific case,
*overall* GvR has done (and will probably keep doing) a better job
than I could have done, or that any committee could have done.  So,
I'd rather see things continue this way, than have him give up the
decision-making burden to any committee or any other individual.

Even though some more consensus-management, diplomatic, and rhetorical
skills, might well help the medicine go down in a most delightful way.
Despite our bruised egos, and the justified bitter after-taste for being 
ASKED to provide arguments and then REPROACHED for having actually done so,
"the language's the thing" -- I'd rather have a great language and some
ego bruises, than a "just pretty good" language and a well-soothed ego:-)


> GvR asked for opinions and got them. The most articulate and compelling
> are against. Well we got told that these are FUD etc etc. My gut feeling
> is that this is wrong and that lambda, map, etc are good. Perhaps I
> should eat sour grapes for breakfast.

Our guts may not be the best guide at the moment:-).  And anybody who
things lambda (as present in Python) is GOOD thinks thoughts just too
different from mine to allow easy communication, anyway:-).


Alex