Skip to content
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

Fully support PEP 695 #757

Open
evhub opened this issue May 28, 2023 · 7 comments
Open

Fully support PEP 695 #757

evhub opened this issue May 28, 2023 · 7 comments

Comments

@evhub
Copy link
Owner

evhub commented May 28, 2023

We already mostly support PEP 695, except for:

@evhub evhub added this to the v3.0.2 milestone May 28, 2023
@evhub evhub changed the title Fully support [PEP 695](https://peps.python.org/pep-0695/) Fully support PEP 695 May 28, 2023
@evhub
Copy link
Owner Author

evhub commented May 28, 2023

I don't think lazy evaluation of type statements is something we can do while also keeping type checkers happy, so probably we'll just stick with the existing string-based solution (though since we'll use the literal syntax on 3.12, we'll still get the lazy evaluation there).

@evhub evhub removed this from the v3.0.2 milestone May 29, 2023
@evhub
Copy link
Owner Author

evhub commented May 29, 2023

Tuple constraint syntax should work now, but I'll probably wait until 3.12 is released to get all the literal syntax working.

evhub added a commit that referenced this issue May 29, 2023
@evhub evhub added this to the v3.0.4 milestone Oct 22, 2023
@evhub evhub modified the milestones: v3.0.4, v3.1.0 Nov 24, 2023
@evhub
Copy link
Owner Author

evhub commented Feb 25, 2024

This is basically done except that it can't really be tested yet because mypy still doesn't support it.

@evhub evhub removed this from the v3.1.0 milestone Feb 25, 2024
@evhub
Copy link
Owner Author

evhub commented Mar 21, 2024

Actually, we need to also emit literal syntax for def f[T](...): ... as well, since if we don't it messes up typing.overload declarations by inserting the typevar declarations in-between.

@evhub evhub added this to the v3.1.1 milestone Mar 21, 2024
evhub added a commit that referenced this issue Mar 21, 2024
@evhub
Copy link
Owner Author

evhub commented Apr 15, 2024

I think the only thing remaining now is we're just waiting on mypy to support this so we can test it on 3.12.

@evhub evhub mentioned this issue Jun 8, 2024
@evhub evhub modified the milestones: v3.1.1, v3.1.2 Jun 9, 2024
evhub added a commit that referenced this issue Jun 9, 2024
See Coconut's
[documentation](http://coconut.readthedocs.io/en/develop/DOCS.html) for
more information on all of the features listed below.

Language features:
* #833: New `case def` syntax for more easily defining pattern-matching
functions with many patterns.
* #811: New `f(name=)` syntax as a shorthand for `f(name=name)`,
replacing the now deprecated `f(...=name)` syntax.
* #836: New `CoconutWarning` built-in used for Coconut runtime warnings.

Compiler features:
* #837: Coconut will now warn about implicit string concatenation and
disable it completely with `--strict`.
* #718: Coconut will now warn about use of `addpattern def` without a
prior `match def`. This was a previously-supported feature to make
pattern-matching functions with many patterns easier to write, but the
new recommended way to do that is now via `case def`.
* #785: Initial [pyright](https://github.com/microsoft/pyright) support
via the `--pyright` flag.

Bugfixes:
* #839, #840: Fixed some f-string parsing issues.
* #834: Fixed `len` of empty `zip` objects.
* #830: Improved use of colored output.
* #757: Improved PEP 695 support on Python 3.12.
@evhub
Copy link
Owner Author

evhub commented Sep 1, 2024

We're waiting for infer_variance support here: python/mypy#15238

@evhub evhub modified the milestones: v3.1.2, v3.1.3 Sep 1, 2024
@evhub
Copy link
Owner Author

evhub commented Oct 23, 2024

It looks like this has now been moved to here: python/mypy#17811

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant