Hi, 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 justified. @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.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
