Eliminate more implicit optionals in transport #1873
Conversation
This reverts commit 5d1b59f.
pymodbus/transport/transport.py
Outdated
| @@ -159,7 +159,11 @@ def __init__( | |||
| self.transport: asyncio.BaseTransport = None | |||
| self.loop: asyncio.AbstractEventLoop = None | |||
| self.recv_buffer: bytes = b"" | |||
| self.call_create: Callable[[], Coroutine[Any, Any, Any]] = lambda: None | |||
|
|
|||
| async def _noop(): | |||
There was a problem hiding this comment.
I really do not like adding _noop methods (potentially quite a lot). Lambda is a perfectly legal one line function call.
Adding more lines of code, just to please mypy is not a good way!
There was a problem hiding this comment.
This is the only one!
(dev is down to 9 mypy errors with strict_optional = true)
There was a problem hiding this comment.
It's the principle, we do not want to have extra code just to please mypy....of course assuming the original is correct and in accordance with the PEP
There was a problem hiding this comment.
self.call_create: Callable[[], Coroutine[Any, Any, Any]] = lambda: Noneis not in accordance with the revised PEP484.
self.call_create: Callable[[], Coroutine[Any, Any, Any]] | None = lambda: Nonewould be, but of course it introduces other type errors with calling code.
I tried to come up with an async lambda => return None or similar, but could not find one.
| @@ -38,7 +38,7 @@ def setup(self): | |||
|
|
|||
| def close(self, exc: Exception | None = None) -> None: | |||
| """Close the transport gracefully.""" | |||
| if not self.sync_serial: | |||
| if not hasattr(self, 'sync_serial'): | |||
There was a problem hiding this comment.
Yes, I understand your concern. Permitting sync_serial to be None means introducing more code to guard against calling it when None, so I found it cleanest to simply del the whole object.
There was a problem hiding this comment.
Or telling mypy to keep silent !!! we do not add code, just to please mypy.
There was a problem hiding this comment.
My experience is actually different a lot of the juniors do not understand nor agree with type checking at all....
There are many python developers who see the lack of type checking as a big advantage...being a C/C++/C# I am very used to strict type checking, but have also seen how it can make code a lot more complicated.
Personally I think the bridge (free use / type checking) python tries to build might end being a split into 2 products.
I like the freedom python allows, but see that mypy catches many problems....so for me a balance is the correct choice, meaning think if what mypy suggest mamés the code better if not ask mypy to stop complaining.
|
Closing in favor of #1888 |
Instead of
use
Also, revert #1859
pymodbus/transport/transport.py:255: error: "None" not callable [misc]