On 9/15/2017 1:58 AM,
alexandre.gal...@gmail.com wrote:
Hi,
Thanks for your return, and link. I knew PyCQA but not the others.
It seems i didn't success to precise my idea correctly. I'm 100% OK with
you that this is not language role to indicate precisely which tools to
use.
But my idea is only to define basical metrics, useful to evaluate
quality code, and related to PEPs if existing. I precise i'd like to
propose informational PEP only. I'm not considering that my idea must be
mlandatory, but only an indication to improve its code quality. So each
developer/society would be free to evaluate each metrics with the way
he/it want. As for PEP8 for example, for which each developer can use
pep8, pylint, ...
It seems to me that you are talking about stuff more appropriate to blog
posts or the python wiki or even to a web site.
The PEP257, for docstrings, indicate how to structure our docstring. My
PEP, in my mind, would indicate how to basically evaluate our quality
code, only which metrics are useful for that. But only this, no tools
indication.
Customer i see regularly ask me for being PEP8 & 257 & ... "certified".
Why do they care? In my view, style is not quality. It is a means to
better quality. I say this as someone who enforces most of PEP 8 on new
IDLE patches, whether by myself or others, and who even upgrades
existing code. The relevance to users is that it facilitates making
IDLE work better.
Automated test coverage is also a means to code quality, not quality in
itself. I recently fixed a bug in 100% covered code. I discovered it
by using the corresponding widgets like a user would. The automated
test did not properly simulate a particular pattern of user actions.
This PEP could be opportunity to have opportunity saying be "PEPxxxx
certified", so customers would be sure that several metrics, based on
PEP and other parameter, would be use to gurantee their quality code.
PEP 8 started as a guide for new stdlib code, but we do not 'pep8
certify' Python patches to the stdlib. Security, stability,
correctness, test coverage, and speed are all more important. It just
happened that others eventually adopted PEP 8 for their own use,
including in code checkers.
Information about .rst only belongs in a PEP because we use it in our
own docs.
Information about code metrics might belong in a PEP only if we were
applying them to the CPython code base. Note that our C code is checked
by Coverity, but I don't believe there is a PEP about it. (No title has
'coverity'.) After pydev discussion, a core developer made the
available free checks happen and then followed up on the deficiency reports.
--
Terry Jan Reedy
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
