PEP 308: A PEP Writer's Experience - PRO

[James J. Besemer]

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