typehinting

[AiyionPrime]

In order to make this library more useful to modern python codebases, I'd like to propose the use of typehinting. (Which might not look straight forward, as we'd technically try to typehint classes with dynamically created attributes.)

One performant option would be the style of pep526, which introduced instance variable type annotations on the classes level.
It looks similar to class variables, but is not.

class BasicStarshipProtocol(dpkt.Packet):
    damage: int                           # instance variable without default

https://peps.python.org/pep-0526/#class-and-instance-variable-annotations

While this is what I'm doing on local codebases dpkt.Packet does not provide any form of typehints yet.

This certainly won't happen before we start working on #551.

---

A workaround would be to provide .pyi stub files for the proptocols.
We could place them alongside the python files and python2 should ignore them, while python3 will pick up the hints.

I'll open a PR for the latter, which introduces an exemplary .pyi file for dpkts packet.

Another option (if typehints were rejected in this repo) would be to track such stub files in an external repo. (hopefully not necessary)

https://peps.python.org/pep-0484/#storing-and-distributing-stub-files

I really would like to hear what you think about typed Protocol Packets.

[kbandla]

@AiyionPrime this has been discussed and would surely be nice to have. To tackle this we first need to finish #551. Once we do that we can surely take this on.
I much prefer typehints added to code than to maintain .pyi files. Also note that dpkt uses metaclasses heavily and some of the types are dynamically built at runtime, so even with typehinting some IDEs might not be able to generate typeahead suggestions. Will keep this issue open for now.