-
Notifications
You must be signed in to change notification settings - Fork 549
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Python 3.10 not recognized #160
Comments
@adamjstewart , Python 3.10 alpha is already available. But when you write |
Ah, I was hoping
It should say 3.10, not 3.1. |
Please pay attention that task input follow semver notation. As for the confusing error message, it is a feature of YAML parsing. When you specify input like version: 3.10
version: '3.10' The first and the second examples in README file shows the correct way with quotes. |
FIX: Python version notation actions/setup-python#160
YAML interprets 3.10 as 3.1 if used without strings. actions/setup-python#160
This commit is the next in a commit chain resurrecting Python 3.10 support in our GitHub Actions-based continuous integration (CI) configuration. Specifically, this commit circumvents upstream issue actions/setup-python#160 by coercively double-quoting *all* Python version strings used as the values of "python-version:" keys. (*Malignant lignite tonight!*)
This patch release delivers obstreperous support for **Sphinx** (*curse ye and yer little side effects too, `autodoc` extension!*), **generator callables, readable exception messages,** and **Python 3.10 CI.** This release resolves **4 issues** and merges **0 pull requests.** Fearsome changes include: ## Compatibility Improved * **Sphinx.** `@beartype` now explicitly provides first-class support for Sphinx's `autodoc` extension (i.e., `sphinx.ext.autodoc`), resolving issue #61, kindly submitted by SeldonIO/alibi ML dev maestro supremum Janis Klaise (@jklaise). `@beartype` now transparently ignores `autodoc`-mocked module attributes (e.g., produced by the `autodoc_mock_imports` list global in Sphinx-specific `doc{s,}/conf.py` configuration files of downstream documentation trees) used as type hints annotating `@beartype`-decorated callables, rendering `@beartype` compatible with `autodoc`-documented codebases. Since Sphinx lacks a public API for detecting when `autodoc` is currently generating documentation (see: sphinx-doc/sphinx#9805), `@beartype` now performs its own ad-hoc detection at decoration time with micro-optimized runtime complexity: * `O(1)` in the common case (i.e., Sphinx's `autodoc` extension has *not* been previously imported under the active Python interpreter). * `O(n)` in the worst case (i.e., Sphinx's `autodoc` extension has been previously imported under the active Python interpreter), where `n` is the height of the call stack leading to `@beartype`. * **Generator callables.** `@beartype` now relaxes the requirement that [a]synchronous generator callables be annotated by [PEP 484][PEP 484] -compliant `typing.{Async,}Generator[...]` or [PEP 585][PEP 585]-compliant `collections.abc.{Async,}Generator[...]` type hints to additionally accept [PEP 484][PEP 484]-compliant `typing.{Async,}Iterable[...]` and `typing.{Async,}Iterator[...]` as well as [PEP 585][PEP 585]-compliant `collections.abc.{Async,}Iterable[...]` and `collections.abc.{Async,}Iterator[...]` type hints, resolving issue #65 kindly submitted by the @posita the positronic brain emitter. ## Features Improved * **Exception message readability.** `@beartype` now emits more human-readable, disambiguous, and useful exception messages. Notably: * `@beartype`-decorated callables annotated by one or more numeric types (e.g., `int`, `float`, `complex`) now raise exceptions on type-checking failures whose exception messages disambiguate those numbers from strings, resolving issue #63 kindly submitted by @jefcolbi. Previously, these messages double-quoted all numbers for disambiguity with the possibly preceding sequence index of those numbers in their parent containers -- which then introduced yet another unanticipated ambiguity between numbers and strings. Numbers are now preserve in their vanilla unquoted form; meanwhile, sequence items are additionally disambiguated from sequence values with additional explanatory substrings. * Edge-case exception messages emitted by our memoized code generator no longer contain the mostly inappropriate substring `"wrapper parameter" *except* where absolutely appropriate. * Annotation-centric exception messages now guaranteeably contain the critical substring `"type hint"`. ## Issues Resolved * **#61,** kindly submitted by SeldonIO/alibi ML dev maestro supremum Janis Klaise (@jklaise). See "Compatibility Improved" above. * **#62,** kindly submitted by Cal Leeming (@foxx), may his serious eyebrow-raising monochrome GitHub avatar be a guiding light to us all. See "Documentation Revised" below. (Thanks again to the foxy @foxx for appraising us all of hitherto unknown typing horrors. And just in time for Halloween too.) * **#63,** kindly submitted by @jefcolbi. See "Features Improved" above. * **#65,** kindly submitted by @posita the positronic brain emitter. See "Compatibility Improved" above. ## Tests Improved * **Python 3.10 CI.** This release resurrects Python 3.10 support in our GitHub Actions-based continuous integration (CI) configuration, circumventing upstream issue actions/setup-python#160 by coercively double-quoting *all* Python version strings specified as the values of "python-version:" keys. *Ya!* ## Documentation Revised * **Reverse dependency showcase.** The introduction of our front-facing `README.rst` documentation now gratefully advertises popular reverse dependencies (i.e., downstream open-source Python projects directly leveraging `beartype`) with a new on-brand icon bar. Gaze upon iconic icons and know the stylish face of unabashed beauty. * **Type hint elision.** The new "Type Hint Connectives" subsection of our front-facing `README.rst` documentation documents various means of circumventing counter-intuitive historicity in Python's core type hierarchy with (*wait for it*) beartype validators, resolving issue #62 kindly submitted by Cal Leeming (@foxx). Specifically, this subsection documents how to effectively declare: * A new PEP-compliant `int - bool` type hint as a beartype validator matching the set of all integers that are *not* booleans. * A new PEP-compliant `Sequence - str` type hint as a beartype validator matching the set of all sequences that are *not* strings. [PEP 484]: https://www.python.org/dev/peps/pep-0484 [PEP 585]: https://www.python.org/dev/peps/pep-0585 (*Unleaded laden jelly-like underbellies!*)
correcting Python version 3.10 element to avoid notation issue actions/setup-python#160
Fix for python 3.10 (needs to be quoted) See actions/setup-python#160
on workflow Django CI adding |
* Remove pyemd in favor of scipy * Bump python version to 3.8 in actions and setup * Fix python version for YAML Per actions/setup-python#160
* Move env inside job * fix django.yaml * Move env back to root * Move requirements.txt inside source folder * Add python version matrix and dependency install to django.yaml * Rename Django workflow and job name * Fix python matrix for 3.10 being recognized as 3.1 Ref: actions/setup-python#160 * Bump actions/setup-python to v5 * remove python 3.12 from matrix as it will raise error on test: AttributeError: 'ExampleTestCase' object has no attribute 'assertEquals'. Did you mean: 'assertEqual'?
version 3.10 was interpreted as 3.1. Per actions/setup-python#160 use quotes around versions to get around yaml limitation
version 3.10 was interpreted as 3.1. Per actions/setup-python#160 use quotes around versions to get around yaml limitation
Add mysqlclient to requirements.txt Remove mysql from django CI workflow Fix python 3 version number in django workflow See actions/setup-python#160 Don't drop DB in CI workflow Remove mysqlclient and mysql from django CI workflow
Add mysqlclient to requirements.txt Remove mysql from django CI workflow Fix python 3 version number in django workflow See actions/setup-python#160 Don't drop DB in CI workflow Remove mysqlclient and mysql from django CI workflow
Describe the bug
All of the documentation for
setup-python
suggests that Python versions can be listed without quotes:However, this doesn't seem to work for 3.10. The action errors out, with the following error msg:
If I wrap
3.10
in quotes, it says 3.10 is not found, which is a little better, although I would like to be able to use the alpha version if possible.Which version of the action are you using?
v1
v2
v2.0.1
ormaster
)Environment
Python Versions
3.10
To Reproduce
Steps to reproduce the behavior:
python-version
without quotesRun/Repo Url
https://github.com/adamjstewart/fiscalyear/actions/runs/346374366
https://github.com/adamjstewart/fiscalyear/actions/runs/346388888
The text was updated successfully, but these errors were encountered: