🐞 Python 3.9.7 causes tests to fail

[keithrfung]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Python 3.9.7 was found by the CI to cause issues with the existing test suite.

Expected Behavior

Tests should run as 3.9.5 and successfully pass.

Steps To Reproduce

1. Set environment to 3.9.7
   This can be done with poetry env use 3.9.7 and pyenv local 3.9.7

2. Run make tests

Environment

- OS: Mac, Windows, Linux

Anything else?

This workflow shows the bugs if you wish to see the problems before starting
https://github.com/microsoft/electionguard-python/runs/3655735644?check_suite_focus=true

[ronnie-llamado]

I think the issue originates from here and was recently patched.

electionguard.hash.CryptoHashable and electionguard.hash.CryptoHashCheckable inherit typing.Protocol, so anything that then inherits from either of these two classes will show errors.

[keithrfung]

@ronnie-llamado Thanks for the information. Will have to test this!

[keithrfung]

@ronnie-llamado Did you happen to have any success getting this working with 3.9.7?

[ronnie-llamado]

I haven't pursued the issue further yet, but I can get on it. From some more looking around, there seems like two options:

1. Wait for the patch in the python source to be released in 3.9.8

2. Explicitly defined __init__ in dataclasses that inherit from Protocol (or in electionguard's case from CryptoHashable or CryptoHashCheckable). Here's another project that took this path to resolve the same issue: link.

Here's the list of all dataclasses that inherit from CryptoHashable (no dataclasses inherit CryptoHashCheckable):

src/electionguard/manifest.py:92:class AnnotatedString(CryptoHashable):
src/electionguard/manifest.py:111:class Language(CryptoHashable):
src/electionguard/manifest.py:130:class InternationalizedText(CryptoHashable):
src/electionguard/manifest.py:148:class ContactInformation(CryptoHashable):
src/electionguard/manifest.py:169:class GeopoliticalUnit(ElectionObjectBase, CryptoHashable):
src/electionguard/manifest.py:192:class BallotStyle(ElectionObjectBase, CryptoHashable):
src/electionguard/manifest.py:213:class Party(ElectionObjectBase, CryptoHashable):
src/electionguard/manifest.py:246:class Candidate(ElectionObjectBase, CryptoHashable):
src/electionguard/manifest.py:278:class SelectionDescription(OrderedObjectBase, CryptoHashable):
src/electionguard/manifest.py:305:class ContestDescription(OrderedObjectBase, CryptoHashable):
src/electionguard/manifest.py:522:class Manifest(CryptoHashable):

[keithrfung]

@ronnie-llamado If you can work on this that would be amazing, but regardless, thank you so much for the clarification.

[ronnie-llamado]

@keithrfung I realized this right as #458 was merged. Pulling over last comment from PR:

I believe AnnotatedString doesn't throw because of the ordering of the elements. AnnotatedString has only optional parameters where all the others have both.

I had the same thought at one point, but ContactInformation also only has optional parameters.

It actually looks like AnnotatedString is not being instantiated in the testing, so no errors are being thrown. When generating ContactInformation, emails are passed in straight from hypothesis and no phone numbers are passed in. These two are expected to be of type AnnotatedString.

https://github.com/microsoft/electionguard-python/blob/f3e2f09503cab2214706240404ca70d5f7a925b0/src/electionguard_tools/strategies/election.py#L178-L185

Explicitly defining __init__ for AnnotatedString will complete the workaround for Python 3.9.7. In addition, emails() can be cast as an AnnotatedString to ensure testing coverage.