christiansandberg / canopen

CANopen for Python
http://canopen.readthedocs.io/
MIT License
449 stars 197 forks source link

Type annotation of Mapping in Python 3.8 #502

Open sveinse opened 4 months ago

sveinse commented 4 months ago

This is a discussion related to typing, #358.

canopen use Mapping and MutableMapping for 10 classes. Due to limitations in Python 3.8, they cannot be annotated and the following will not work

class Network(MutableMapping[int, Union[RemoteNode, LocalNode]]):

Python 3.8 gives the error: TypeError: 'ABCMeta' object is not subscriptable. The effect is that a code base supporting 3.8 cannot use type hints on Mapping. These classes are very central to the function of canopen, so I think we'd miss out on significant type annotation aids if we don't get to use it.

There are a few options available to us:

  1. Bump the minimum Python version to 3.9
  2. Don't use type annotations on any of the Mapping and MutableMapping classes because we need Python 3.8 compatibility
  3. Use a run-time hack that conditionally adds the type annotations. Below example is inspired from this example
  4. Some way to annotate these classes that works with >=3.8 that I don't know about
# Example to annotate MutableMapping that makes it run on Python 3.8
import sys
if sys.version_info >= (3, 9):
    TMutableMapping = MutableMapping[int, Union[RemoteNode, LocalNode]]
else:
    TMutableMapping = MutableMapping

class Network(TMutableMapping):
    """Representation of one CAN bus containing one or more nodes."""
erlend-aasland commented 4 months ago

FTR, Python 3.8 goes EOL in October 2024.

acolomb commented 4 months ago

I'd avoid jumping to a 3.9 requirement soon. It's very common to work on devices with older distributions when hardware interaction is concerned, so waiting some time until after Python 3.8 has EOLed seems sensible.

Do we really have to introduce a subindexed MutableMapping type here? The results should be very useful already with the generic type - being able to check methods and their signatures at least. And for the other classes, it will get messy trying to list all kinds of possible entry objects. We could just stick with the status quo and revisit once there is a stronger reason (and better time) to bump our Python requirement.

For the type annotations, I absolutely prefer the str | int syntax instead of Union[str, int] for example. But as we're trying hard to be backwards-compatible, we'll just need to live with the older syntax for a while longer.