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 : > > 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 <ncog...@gmail.com <javascript:>> > 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 <alexandr...@gmail.com <javascript:>> > Cc: python-ideas <python...@googlegroups.com <javascript:>> > > > On 25 September 2017 at 21:49, <alexandr...@gmail.com <javascript:>> > wrote: > > 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. > > > > Perfect solution does not exist, i know it, but i think this "PEP" > could, > > partially, be a good guideline. > > 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 | ncog...@gmail.com <javascript:> | Brisbane, > Australia > > > -- > Nick Coghlan | ncog...@gmail.com <javascript:> | Brisbane, > Australia > _______________________________________________ > Python-ideas mailing list > python...@python.org <javascript:> > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
