> On 8 Aug 2016, at 17:06, Yury Selivanov <yseliva...@gmail.com> wrote:
>>
>> As to having a PEP or putting something in PEP 8, I feel pretty lukewarm to
>> those ideas. If the core Python team was able to legislate good coding
>> practices via PEPs I think the world would be a very different place.
>
> What does this mean? A lot of people, in any serious project at least,
> follow PEP 8 and coding with linters is a wide-spread practice.
Sure, but that only works for things that linters can enforce, and I sincerely
doubt that this is one of them. How would you code a linter in order to confirm
that protocol code and I/O code are separated?
More importantly though, people follow the bits of PEP 8 that are easy to
enforce and that don’t require substantive architectural changes. If PEP 8 said
something like “wherever possible use dependency injection as a design
pattern”, that guideline would be ignored as both entirely unenforceable and
totally subjective. Where is the line for “wherever possible”? How does one
enforce the use of dependency injection? Can you programmatically determine
dependency injection? What dependencies do not need to be injected?
Dependency injection is a great design pattern that produces lots of useful
side effects, and I use it often. But if I saw PEP 8 mandating it I’d be
extremely perplexed. Realistically, at a certain point it’s the equivalent of
writing “You should write good, maintainable code, obeying all relevant best
practices” into PEP 8. *Of course* you should. This goes without saying. But
that makes the advice not that helpful.
Now, PEP 8 could *recommend* design patterns to follow, and that’s a whole
other kettle of fish. But then we’re just asking a different question: how
universally praised does a design pattern have to be to become part of PEP 8?
Cory
_______________________________________________
Async-sig mailing list
Async-sig@python.org
https://mail.python.org/mailman/listinfo/async-sig
Code of Conduct: https://www.python.org/psf/codeofconduct/
