PEP 308: A PEP Writer's Experience - PRO
James J. Besemer
jb at cascade-sys.com
Fri Feb 14 10:43:20 EST 2003
Andrew Dalke wrote:
> Erik Max Francis:
>
>>In the portion you [David Eppstein] clipped, I acknowledged that I'm
>>ure that that syntax is used _occasionally_, my point was just that it is
>>so rare as to be totally irrelevant,
>
> And my - at least implicit - argument has been that without analysis
> is hard to tell if a gut feeling has basis in reality. Yours does not.
Your own analysis of Python and Linux here also is suspect. In both cases
you you neglected to include the thousands of files nested deeper than 1 or 2
levels of sub directories. You also neglect to include .h files, which
normally are a large source of ?: usages (though in this particular case,
there may not be very many).
I don't know (or care) by how much this perturbs your conclusion. It may be
a big change or it may be a minor one. Hard to predict since there was a
factor of 2 difference in the two code bases. Anyway, it invalidates all the
work you did thus far on this ridiculously trivial point. And IMO your
first-order carelessness on these minor points casts some suspicion on your
other 'analysis' to date.
And what did your 'analysis' prove after all in this case? The poor Mr.
Francis expresses an opinion, using the common terms "occasionally" and
"rare". You pounce on him but after the dust clears, his statement is
entirely consistent with your results, which range as low as 5 parts per
million for his specific example. If anything, his description actually
exaggerates the significance of the given error. Even if we accept your
higher figure of 25 PPM (1 in 40K), one would still have to agree with Erik's
characterization that entire issue is essentially "irrelevant".
To look at it from another angle, you predict one of these heinous errors in
every 40K LOC of Python (which already is sounding pretty friggin'
irrelevant). I measure around 160K lines of python code and 669 modules in
the 2.2.2 Lib directory. So this would translate to a grand total of 4
errors in the entire library, or one error on average in every 167 modules.
So this clearly is angels on the head of a pin nonsense. It's even more
pointless: in this example the real number more likely would be zero, since
people working on the library likely would be more conservative than the code
base you drew from. So what good are your predictions in the first place?
More importantly, I disagree with both of you that this particular bogeyman
is such a heinous sin in the first place. Nested conditionals are so
extremely common to almost not be worth talking about. The fact that a
conditional expression might be nested within an if statement -- it's no big
deal, hardly of more consequence than using 'and' or 'or or a nested if. But
I think your examples show the usage has some value. It may take some
getting used to but it does NOT present the rubic cube puzzle some of you
make it out to be. To be sure, your complaint here may be further argument
that the c-style, operator form would be less confusing overall than the
if/else keyword alternative. But either way, once people learn the
construct, it's not going to present a major hardship for anybody. Tempest
in a teapot.
Besides, if a programmer in his judgment feels it's the right thing to do in
a given circumstance, who the heck are YOU to say he's a bad person? Sure,
you're entitled to your opinion and in your shop you can enforce any rules
you want. But the obsession you show about imposing every minuscule detail
of your personal taste on the rest of the world is disturbingly reminiscent
of the moral majority folks.
> Let's assume every occurance would correspond to an occurance in Python
> code. I earlier used a factor of 5 to convert from lines of C code to lines
> of Python code.
This is a glaring inconsistency with your past assumptions. Here you're
talking about 'bad' examples of the construct, so naturally it's convenient
for you to ASSUME they carry over to 1:1 from C to Python. Just about
everywhere else, when the subject was 'good' examples, you went to great
lengths before hand to disqualify as many instances as possible. Now it's
hard to say if your bigger error was excluding too many in the good case or
not excluding enough in the bad case but the fact that you do it differently,
and always do it biased towards your own foregone conclusion is practically
the opposite of being objective. It's bad enough to introduce bias
consistently one way, but to change your assumptions on the fly like this is
indefensible.
Your analysis would be more credible and I think intellectually more honest
if you reversed these assumptions: being generous about admitting possible
good usages and stingy with the bad ones. Then if you came up with some
otherwise credible, scary statistics, your conclusion would be very strong.
Of course, the problem with the intellectually honest route is you probably
don't end up with an 'analysis' that suits your agenda. Since you instead
skew the data with assumptions that support your own bias, your elaborate
'analyses' are arguably little more than than an unnecessarily complicated
expression of your own opinion, which we all knew to begin with.
> Yet you continue to argue based on gut feelings, and do not
> back them up with any sort of rigour.
Perhaps you should apologize to Erik. Given the arbitrary choices you have
made in building up YOUR 'analysis,' your own pronouncements seem to have
little more than the ILLUSION of rigor, if that. [I address this in a little
more detail in my previous post.] This is why we all should be constantly
on guard about "lies, damned lies and then statistics."
>>I don't doubt that _someone_, _somewhere_, will misuse a Python
>>conditional operator in this way. I'm just saying that it will be so
>>rare in actual practice that it's not worth worrying about.
Exactly! Erik is 100% correct, despite the lack of a pointless attempt to
quantify "rare".
> What level would indicate a sufficiently high level of misuse to
> warrant its exclusion from a future Python?
Personally the I think the chance of misuse of PEP 308 should be pretty
friggin' high for it to be rejected.
> If you accept my analysis,
Per above, I question it.
> then [PEP308] will be used in bad form about 2-3% of the time.
Geeze, 2-3%. Once every 40K LOC. Wake the President! The sky is falling!
Frankly I think trying to analyze the probability of abuse by looking at code
is of dubious value to begin with. I think you've been barking up the wrong
tree all along. It isn't about (heavily massaged) code stats; it's about
people. Most Pythonistas will Never abuse the damn thing. Some have vowed
ahead of time, sight unseen, that they'll never even use the feature in any
form. A few users from time to time will screw up, commit the grave error of
writing a more complicated snipped than absolutely necessary. For the vast
majority of them the only person they'll hurt will be themselves, as nobody
else is ever gonna read their code in the first place. Others of you who are
in a position of leadership or power can suggest or demand that people under
your influence to use whatever style you think best. After all that, what
are the odds that you will be confronted with one if these evil forms? Maybe
never, since the people around you will be careful.
I think a more meaningful statistic would be for you to go to all your 'non
programmer' clients, have them study the PEP (without a lot of coaching by
you) then and ask THEM if THEY have trouble understanding the construct.
Frankly, I suspect that some of them would actually be INSULTED the way you
carry on about what a hardship this trivial extension would present for them,
how much trouble they would necessarily get into trying to use it and, by
implication, how weak their computer programming skills must actually be.
After all, there are thousands of ways to abuse Python as it is. In this
case, perhaps all that's needed are a few additional guidelines in PEP-8 to
steer people away from the worst pit falls. Most people obey it pretty
religiously.
Regards
--jb
--
James J. Besemer 503-280-0838 voice
2727 NE Skidmore St. 503-280-0375 fax
Portland, Oregon 97211-6557 mailto:jb at cascade-sys.com
http://cascade-sys.com
More information about the Python-list
mailing list