arcade
arcade copied to clipboard
pythonarcade
Enhancement / Doc: Single source of truth for minimum Python version
Enhancement request:
What should be added/changed?
We should use a single source of truth for the minimum Python version.
What would it help with?
In 10 months, 3.7 is reaching EOL. If we make the proposed fix now, we'll never have to go through multiple doc pages to update the minimum python version again.
Potential Fixes
tl;dr I can do the same thing I did for pyglet if you want this done fast
Option 1 : The same thing I did for pyglet
I implemented a crude version of this proposal for pyglet: https://github.com/pyglet/pyglet/pull/668. I could do the same for arcade.
Option 2: Option 1 + Add a maximum version
I mentioned maximum version because shapely has issues on 3.11, but I don't know if it's a hard requirement or just an optional one.
If we want to get fancy, we could also do something like this in arcade's __init__.py:
class Version(tuple):
"""A tuple that renders versions neatly to strings.
In addition to printing neatly, constants declared with it can also
be imported and compared against in other files. This would allow
for centralizing control over minimum interpreter versions for
specific features.
It works with string.format and f-strings, but does not work with
% interpolation.
"""
def __new__(cls, *args):
return tuple.__new__(cls, args)
def __str__(self) -> str:
result = []
for val in self:
result.append(str(val))
return '.'.join(result)
It was overkill for pyglet since they don't need to track a maximum Python version.
Option 3: Explore additional dependencies
We could also try using sphinx extensions or other dependencies. This might be overkill since we don't offer partial support for Python versions.
The min/max sounds like a good idea. We have historically run into issues around this and I see no reason that won't continue to be an issue.
tl;dr Would printing a warning be an acceptable way of dealing with exceeding max version?
I think my initial writeup made a flawed assumption because we may actually offer a form of partial support for Python versions due to shapely being a semi-optional dependency, even if the python-only collision is buggy right now.
From what I remember, all options other than a warning require workarounds while developing or installing.
| Approach | Problem created |
|---|---|
| Pip-side restriction | Can't install on versions higher than max Python version |
| Hard crash when Py > max | Requires additional complexity to override it |
I'd support a warning for a too-new python version. The python-only collision was just fixed in the development branch. It just isn't as fast as Shapely.
I think a hard error would be bad.
Python 3.11 is 30% faster than previous versions, it should be used in resource heavy games. What are the problems with shapely and 3.11?
Python 3.11 is 30% faster than previous versions, it should be used in resource heavy games
Not everyone has that option.
What are the problems with shapely and 3.11?
I'm not sure if it's still an issue. EDIT: Shapely isn't used in 3.X at all, so it doesn't matter going forward. See this comment.
As to this issue, I've done some more Sphinx experimentation and I'm pretty sure we could safely apply it in arcade. However, there's something I want to double check before I start adding it.
@pvcraven is there a particular reason for keeping the VERSION + version.py files we use at the moment? We use them in a few places like the PyPI build script, but this seems redundant given we have pyproject.toml. Do you have any objections to refactoring that?
No objections to a refactor. The auto bump code I think required it's own file.