Drop support for python 3.9

[misi9170]

Following #1078 , and based on comments #953 (comment) and #951 (comment), this PR drops support for python version 3.9. This should remain as an open pull request until we feel that it is appropriate to drop support as python 3.9 nears end-of-life.

This PR also:

• Adds testing for mac-os and windows, thus superseding Add back in explicit windows and mac testing #953
• Add example checks for mac-os and windows as well as ubuntu (currently failing!) Runs examples check on ubuntu only, using the oldest supported python version (3.10)
• Add testing for the yet-to-be released python 3.14 EDIT: not released so installation fails
• Removes the __future__ import annotations needed to make type hinting compatible with python 3.9. This is not possible everywhere: see comments below.
• Begins using the match/case structure EDIT: After discussion, decided against a concerted change to switch case since it is not super common in python yet.

Open questions:

• Should we consider limiting the check-working-examples workflow to a single python version (e.g. 3.13) across all operating systems to limit the total number of actions? YES---chose 3.10, under the notion that all later versions 3.x should be back-compatible.
• Can we change the python-version: "3.13" to python-version: "3.x" in the deploy-book workflow to allow this to float up with the latest python releases?

[misi9170]

At this stage, I have updated the check-working-examples workflow to include mac and windows. However, this is causing a bit of a headache, because there are a number of bash commands that are OS-specific and are currently not working. We could consider running tests on mac, windows, and ubuntu, but only running examples on ubuntu. This was the approach taken in #953.

[rafmudaf]

I love the evolution of the commit messages. YOLO force-pushes coming soon :)

[misi9170]

I love the evolution of the commit messages. YOLO force-pushes coming soon :)

Haha nothing like pushing changes in a shell language I don't use to see what works!

[misi9170]

After some back and forth and trying different things, we have decided to simplify the workflows while providing some coverage across OSs:

• examples run only with ubunutu-latest, and only with python 3.10 (the thinking being that if the examples run on the minimum supported python version, they should also run on more recent python versions)
• tests run on all supported OSs (ubuntu-latest, macos-latest, windows-latest) and all support python versions (3.10--3.13)

[misi9170]

I've now also removed most from __future__ import annotations imports, since python 3.10 enabled the type hinting we use throughout FLORIS. However, there is a catch: Any class methods that instantiate the class and have an output type hint like:

def instantiation_method(...) -> ClassName

still require this annotations import. See here for an explanation of "forward references".

This currently affects two files, where I've left the from __future__ import annotations line in:

• floris/core/core.py here
• floris/wind_data.py here and here

Alternatively, the explicit return type hints could be removed in these locations, which would free us up to remove the annotations import. However, that doesn't seem like a great solution. Unfortunately, we may just need to add the from __future__ import annotations back to any files containing classes with some "self-instantiation" method.

[paulf81]

Alternatively, the explicit return type hints could be removed in these locations, which would free us up to remove the annotations import. However, that doesn't seem like a great solution. Unfortunately, we may just need to add the from __future__ import annotations back to any files containing classes with some "self-instantiation" method.

I think this is ok if it is what it is, but nice to have a bunch of them removed, thanks @misi9170 !