[Python-ideas] Fwd: A PEP to define basical metric which allows to guarantee minimal code quality

alexandre.galode at gmail.com alexandre.galode at gmail.com
Mon Sep 25 07:49:42 EDT 2017


Sorry from being late, i was in professional trip to Pycon FR.

I see that the subject is divising advises. 

Reading responses, i have impression that my proposal has been saw as 
mandatory, that i don't want of course. As previously said, i see this 
"PEP" as an informational PEP. So it's a guideline, not a mandatory. Each 
developer will have right to ignore it, as each developer can choose to 
ignore PEP8 or PEP20. 

Someones was saying that it was too generic, and not attached to Python, 
but i'm not OK on this point, because some metrics basically measured on 
Python code is justly PEP8 respect, with tools like PEP8, pylint, ... Not 
every metrics could be attached to another PEP, i'm OK on this point, but 
if at least one of its could be, it means in my mind, that a PEP can be 

@Jason, about false sense of security. Reading this make me thinking to the 
last week Pycon. Someone was talking to me to its coverage rate was 
falling. But in fact it was because an add of code lines, without TU on it. 
It means, that the purposed metrics are not to be used as "god" metrics, 
that we have only to read to know precisely the "health" of our code, but 
metrics which indicates to us the "health" trend of our code. 

@Chris, about we measure only what we know. Effectively, i think it's the 
reality. One year ago, i didn't know McCabe principle and associated tool. 
But now, i'm using it. If a "PEP", existing from a time, was talking about 
this concept, i would read it and apply the concept.

Perfect solution does not exist, i know it, but i think this "PEP" could, 
partially, be a good guideline.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170925/c53fda45/attachment.html>

More information about the Python-ideas mailing list