Fwd: Fwd: A PEP to define basical metric which allows to guarantee minimal code quality

Forwarding my reply, since Google Groups still can't get the Reply-To headers for the mailing list right, and we still don't know how to categorically prohibit posting from there. ---------- Forwarded message ---------- From: Nick Coghlan <ncoghlan@gmail.com> Date: 26 September 2017 at 12:51 Subject: Re: [Python-ideas] Fwd: A PEP to define basical metric which allows to guarantee minimal code quality To: Alexandre GALODE <alexandre.galode@gmail.com> Cc: python-ideas <python-ideas@googlegroups.com> On 25 September 2017 at 21:49, <alexandre.galode@gmail.com> wrote:
Your question is essentially "Are python-dev prepared to offer generic code quality assessment advice to Python developers?" The answer is "No, we're not". It's not our role, and it's not a role we're the least bit interested in taking on. Just because we're the ones making the software equivalent of hammers and saws doesn't mean we're also the ones that should be drafting or signing off on people's building codes :) Python's use cases are too broad, and what's appropriate for my ad hoc script to download desktop wallpaper backgrounds, isn't going to be what's appropriate for writing an Ansible module, which in turn isn't going to be the same as what's appropriate for writing a highly scalable web service or a complex data analysis job. So the question of "What does 'good enough for my purposes' actually mean?" is something for end users to tackle for themselves, either individually or collaboratively, without seeking specific language designer endorsement of their chosen criteria. However, as mentioned earlier in the thread, it would be *entirely* appropriate for the folks participating in PyCQA to decide to either take on this work themselves, or else endorse somebody else taking it on. I'd see such an effort as being similar to the way that packaging.python.org originally started as an independent PyPA project hosted at python-packaging-user-guide.readthedocs.io, with a fair bit of content already being added before we later requested and received the python.org subdomain. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

Hi, After some reflexion on this full thread, with all your arguments and discussion with my team, i have finally a better understanding on PEP finality. I saw that PEP 8 & 20 i used as example are "specials" PEP. So i let my idea here, and eventually, as previously suggested, i'll contact PYCQA. Thank you very much everybody for your help and your attention :) Le mardi 26 septembre 2017 04:54:45 UTC+2, Nick Coghlan a écrit :

Hi, After some reflexion on this full thread, with all your arguments and discussion with my team, i have finally a better understanding on PEP finality. I saw that PEP 8 & 20 i used as example are "specials" PEP. So i let my idea here, and eventually, as previously suggested, i'll contact PYCQA. Thank you very much everybody for your help and your attention :) Le mardi 26 septembre 2017 04:54:45 UTC+2, Nick Coghlan a écrit :
participants (2)
-
alexandre.galode@gmail.com
-
Nick Coghlan