Hi @jorenham, thanks for the PR.

Edit: disregard the previous comment, this is the first time I saw the diff through the mobile app and got confused... Embarrassing!

I'll look at this soon.

Edit: disregard the previous comment, this is the first time I saw the diff through the mobile app and got confused... Embarrassing!

The mobile app kinda sucks, so no worries :)

First: There's a single commit here that mixes up style fixes (removal of trailing whitespace, at least) with functional changes. I don't mind the style fixes (in fact, they're always appreciated), but I do mind them not being in a separate commit.

That aside, I'm not sure we want to do this.

Pydot has traditionally had a policy of supporting older, even EOL, Python versions as long as there's meaningful demand for them. We're well aware 3.9 is EOL, in fact several Python 3.9 fixes were added AFTER it became EOL. As long as there's still significant Pydot download traffic on PyPi from Python 3.9 installs, it's worth (minimally) supporting. (And our support is minimal. We don't even test typecheck under Python 3.9, because the Pyparsing releases with type annotations have dropped support. We just try not to go out of our way to actively break 3.9 users.)

Last I heard from @lkk7 regarding the PyPi stats, there was still a depressingly significant amount of Python 3.SEVEN traffic, to say nothing of 3.8 and 3.9. Until whatever Ubuntu LTS release shipped with Python 3.9 is itself EOL, there will still be a lot of demand. Because Ubuntu's LTS policies have ultimately proven more contagious than the GPL.

First: There's a single commit here that mixes up style fixes (removal of trailing whitespace, at least) with functional changes. I don't mind the style fixes (in fact, they're always appreciated), but I do mind them not being in a separate commit.

Ah sorry, that wasn't intentional; it was just VSCode being "helpful". I'll revert it

Pydot has traditionally had a policy of supporting older, even EOL, Python versions as long as there's meaningful demand for them. We're well aware 3.9 is EOL, in fact several Python 3.9 fixes were added AFTER it became EOL. As long as there's still significant Pydot download traffic on PyPi from Python 3.9 installs, it's worth (minimally) supporting. (And our support is minimal. We don't even test typecheck under Python 3.9, because the Pyparsing releases with type annotations have dropped support. We just try not to go out of our way to actively break 3.9 users.)

If you publish a new pydot release that doesn't support those versions, then that doesn't mean that things will break for those that are still using the (very insecure) EOL Python versions; they just won't be able to use the latest pydot version; they probably wouldn't even notice.

Oh and for context: My plan was to improve type annotation coverage of pydot. Doing so would be significantly easier if we don't have to take these EOL Python versions into account, because then we'd be able to use the fancy | union syntax for example.

And to be clear; if you really don't want to drop these Python versions, then that's not a deal-breaker for me or anything. I just figured that it's something you'd wanted to do anyways 🤷.

Thoughts @ferdnyc?
To be honest, he's right about the new version release. 3.9 users would not notice a new major version. And any critical patches could be done in the older branch too (which is annoying but doable).
BUT, I guess if any improvements are coming, we'd also like to release them for old versions users. Because they do exist. So it's a matter of doubling the work for every future improvement. And due to new typing you couldn't just push the new work to the old branch. Then, it'd be easier to drop the new typing usage. But that defeats the main benefit of the version drop...
Unless I got it wrong somewhere.