Blacken #177
Blacken #177
Conversation
|
to be clear: this is literally just |
trio.MultiError is deprecated, and for technical reasons involving how the deprecation is implemented, this means pylint can't see it and thinks it doesn't exist. It does exist.
|
OK the last two commits did actually change things in trivial ways to get the lint passing. Still no semantic changes, or even syntactic ones. |
|
Thank you for investigating that problem. I'm not a fan of blacken formatting*, but the plea I'll make is that making a huge formatting change is not ideal for a project on life support. With a legacy codebase and departed authors, it's critical to be able to dig through code history and understand things-- I'd rather avoid having to navigate through this diff on every blame output going forward. Would it be reasonable to revisit if the project becomes more actively maintained? [*] - for example, some of the formatting choices are not friendly to vertical footprint, and I do 100% development on a small laptop having a short ratio display. |
|
I was requested to add type hints to this repository, so
is now relevant. I would vastly prefer if the code was black-formatted for me to change stuff.
you can tell |
| @@ -11,6 +11,7 @@ test: | |||
| $(PYTHON) -m pytest --cov=trio_websocket --no-cov-on-fail | |||
|
|
|||
| lint: | |||
| $(PYTHON) -m black trio_websocket/ tests/ autobahn/ examples/ | |||
There was a problem hiding this comment.
Hi @jakkdl
I was requested to add type hints to this repository
Would you share some context of that conversation? (gitter link etc.)
Please see the thread here before we discuss type annotation coverage.
#167 (comment)
Would it be reasonable to revisit if the project becomes more actively maintained?
is now relevant
To me, being off life-support maintenance would mean things like 1) there is at least another person that has some history on the project and I can trust to share the load on whatever comes up going forward, 2) there is activity like revising the API, rewriting the implementation or tests, etc. I wouldn't say that adding type annotations or auto formatting means that the project is out of the woods regarding stewardship, and there are aspects of full type annotations that make maintenance harder.
Regards,
There was a problem hiding this comment.
Thank you! We'll look into possible alternative libraries that are under more active support and reconsider whether to use trio-websockets. If we don't find any great alternatives, I could go with a more minimal approach and just write separate stub files that needn't touch the existing code at all, and if you don't want the extra maintenance burden of them we can just stick them in an entirely separate repo.
I'm working on fixing a bug with connection shutdown, and standarizing the formatting first makes the source easier to work with