[Async-sig] SansIO (Was: PEP: asynchronous generators)

[Cory Benfield]

> On 8 Aug 2016, at 17:06, Yury Selivanov <yselivanov at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/async-sig/attachments/20160808/a609969f/attachment.html>