Release SymPy 1.11 soon

[Oscar Benjamin]

Hi all,

I'm thinking about making a release of SymPy 1.11. Until now I've been
too busy at work to make a release but things are beginning to ease up
at the end of the academic year. We're already at the point where
we're getting new reports for bugs that were fixed months ago so a new
release would be good:
https://github.com/sympy/sympy/issues/23639

Does anyone know of anything that should be done before issuing a new
release? Are there any significant pull requests etc that should be
merged? Is there any work that is incomplete and should be fixed
first?

Of course we have GSOC projects underway so potentially it's good to
wait until that's over but that would delay the next release by a long
time (there's usually some unfinished work so it's not as simple as
just releasing as soon as GSOC is over).

Another possibility here would be to make a release branch, put out a
beta release and let that sit for a while to collect bug fixes.
Pre-releases don't seem to get that much downstream testing though
(but maybe that's because they aren't used consistently by SymPy).

A few minor fixes have been made for Python 3.11 so it would be good
to get out a new release before 3.11 comes out. We're still in the
3.11 beta cycle though so there's the potential for more fixes to be
needed by the time of 3.11 final.

Oscar

[Oscar Gustafsson]

I've marked a few PRs as candidates to be merged, one requires resolving merge conflicts, but as far as I can tell there are no major arguments against merging them. Feel free to remove the milestone and point out what still may be missing.

BR Oscar

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxS0MvFbhc2J%2B7VcyLsft4hLZH2%2BuqgL8XEHhiEyYm3Lng%40mail.gmail.com.

[Arthur Ryman]

Oscar B,

As a theme, how about making SymPy more mypy-friendly? I ran into one problem, caused by the mypy folks not accepting certain syntax. You diagnosed it:

class A:
    pass

# B = A    # <--- this is fine
B = C = A  # <--- mypy chokes on this

a: B = B()

The error message is:

$ mypy t.py
t.py:7: error: Variable "t.B" is not valid as a type
t.py:7: note: See https://mypy.readthedocs.io/en/stable/common_issues.html#variables-vs-type-aliases
Found 1 error in 1 file (checked 1 source file)

I need to create an issue for this (I've been distracted lately). 

Yes, this is a mypy bug and I'll also report it to the mypy project. However, SymPy could avoid this bug simply by splitting the double type assignment for Matrix into two single assignments.

fyi, I had to roll back SymPy 1.10 to 1.9 since I rely on mypy.

-- Arthur

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAFjzj-KUbWEU2uj%3DdT4BrHbjtzvpMTub2YtMk0eWO2aZnY_EXQ%40mail.gmail.com.

[Jeremy Monat]

Aaron Meurer pointed out that we should move the solving main page before the next release, so the page is in its final location when it gets published to the "latest" (not dev) version of the documentation web site. Given that, I'll make a simple pull request to reorganize the solving main page from guides/solving.md to guides/solving/index.md.

I included that reorganization in my draft pull request #23638 Documentation guide: Solve an equation algebraically but the new sub-page is still very much in development, so I'll split out the reorganization into its own pull request.

Jeremy Monat

P.S. Creating this release will also have the benefit of making the "latest" version of the docs use the new Sphinx theme. That will address the "bug" in the docs that was raised in this mailing list recently, about clicking a link in the left navigation bar not doing anything.

On Sat, Jun 18, 2022 at 8:25 AM Oscar Gustafsson <oscar.gu...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAFjzj-KUbWEU2uj%3DdT4BrHbjtzvpMTub2YtMk0eWO2aZnY_EXQ%40mail.gmail.com.

[Oscar Benjamin]

On Sat, 18 Jun 2022 at 13:42, Arthur Ryman <arthur...@gmail.com> wrote:
>
> Oscar B,
>
> As a theme, how about making SymPy more mypy-friendly? I ran into one problem, caused by the mypy folks not accepting certain syntax. You diagnosed it:
>
> class A:
> pass
>
> # B = A # <--- this is fine
> B = C = A # <--- mypy chokes on this
>
> a: B = B()
>
> The error message is:
>
> $ mypy t.py
> t.py:7: error: Variable "t.B" is not valid as a type
> t.py:7: note: See https://mypy.readthedocs.io/en/stable/common_issues.html#variables-vs-type-aliases
> Found 1 error in 1 file (checked 1 source file)
>
> I need to create an issue for this (I've been distracted lately).
>
> Yes, this is a mypy bug and I'll also report it to the mypy project. However, SymPy could avoid this bug simply by splitting the double type assignment for Matrix into two single assignments.

I don't mind making that change because it's trivial so feel free to
open a PR. I do want to see this opened as an issue with mypy in the
first instance though.

It's a very slippery slope if the expectation is to rewrite anything
in downstream python libraries to be compatible with bugs in mypy.
There needs to be pressure on the mypy developers to support perfectly
valid code rather than pressure on everyone else to workaround their
bugs. If you aren't going to open a bug report with mypy or they
aren't prepared to fix bugs like this then I don't see why we should
make any change to accomodate using sympy with mypy.

> fyi, I had to roll back SymPy 1.10 to 1.9 since I rely on mypy.

That seems a bit drastic. Several alternatives:

1. Use the actual class name which is MutableDenseMatrix.
2. Make your own alias Matrix = MutableDenseMatrix
3. Add type:ignore
4. And so on...

--
Oscar

[Arthur Ryman]

Oscar,

I opened two issues:

* mypy - https://github.com/python/mypy/issues/12995
* sympy - https://github.com/sympy/sympy/issues/23647

I agree that the best way to fix this is in the mypy code. Let's see how they respond.

Splitting the Matrix chained type alias assignment in the sympy code base is a pragmatic workaround and not too unnatural. I haven't contributed a PR to sympy yet so I'll need to spend some time understanding the contribution guidelines and doing whatever setup is required to run tests, etc. I'm glad you are supportive of this workaround.

I'll also try overriding the Matrix type alias with a local definition.

-- Arthur

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxQ%2Bs-i8x02asQWY8%3Dh__zHX%3DybmkOotY%2B3O%3DZben4wZvA%40mail.gmail.com.

[Oscar Benjamin]

On Sat, 18 Jun 2022 at 13:45, Jeremy Monat <jem...@gmail.com> wrote:
>
> Aaron Meurer pointed out that we should move the solving main page before the next release, so the page is in its final location when it gets published to the "latest" (not dev) version of the documentation web site. Given that, I'll make a simple pull request to reorganize the solving main page from guides/solving.md to guides/solving/index.md.
>
> I included that reorganization in my draft pull request #23638 Documentation guide: Solve an equation algebraically but the new sub-page is still very much in development, so I'll split out the reorganization into its own pull request.

This reminds me that also I'm not really happy with the current
organisation of the API docs:
https://groups.google.com/g/sympy/c/L2zd54HDAxU

If anyone wants to put some work into that then it would be good to
get something in before the next release.

--
Oscar

[Aaron Meurer]

Isn't this something that's already a problem with 1.10? The only difference in dev is the new theme, which makes organization issues more evident. 

Aaron Meurer

--

Oscar

--
You received this message because you are subscribed to the Google Groups "sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxTX6yTBpUkWxDoLioGzTKxugyMwfwZz5arVn6CoHR7AnA%40mail.gmail.com.

[Oscar Benjamin]

On Sun, 19 Jun 2022 at 09:01, Aaron Meurer <asme...@gmail.com> wrote:
>
> On Sat, Jun 18, 2022 at 3:49 PM Oscar Benjamin <oscar.j....@gmail.com> wrote:
>>
>> On Sat, 18 Jun 2022 at 13:45, Jeremy Monat <jem...@gmail.com> wrote:
>> >
>> > Aaron Meurer pointed out that we should move the solving main page before the next release, so the page is in its final location when it gets published to the "latest" (not dev) version of the documentation web site. Given that, I'll make a simple pull request to reorganize the solving main page from guides/solving.md to guides/solving/index.md.
>> >
>> > I included that reorganization in my draft pull request #23638 Documentation guide: Solve an equation algebraically but the new sub-page is still very much in development, so I'll split out the reorganization into its own pull request.
>>
>> This reminds me that also I'm not really happy with the current
>> organisation of the API docs:
>> https://groups.google.com/g/sympy/c/L2zd54HDAxU
>>
>> If anyone wants to put some work into that then it would be good to
>> get something in before the next release.
>
>
> Isn't this something that's already a problem with 1.10? The only difference in dev is the new theme, which makes organization issues more evident.

Yes, it's already a problem in 1.10. Ideally we would make it not be a
problem in 1.11 though.

Imagine being a new user or even an experienced user or contributor
and you go to consult the docs for something starting from the main
page:
https://docs.sympy.org/dev/index.html

From there clicking through the different headings and then clicking
through from those pages still nothing really makes sense. The guides
section is mostly about contributing to SymPy apart from one very long
page about the old assumptions. The tutorials page makes sense but the
most important part (installing sympy) is for some reason in the
guides section rather than the tutorial section. Probably there should
be a big fat "installing" link right on the main page of the docs
(perhaps similar for "contributing"). The "explanation" section seems
completely random when you go and look at what's in there.

Then there's the API reference which is organised in a way that
doesn't really reflect any particular organisation that makes sense to
anyone I think. It doesn't really break down into the kinds of things
that users might want to do. Probably most of what a beginner would
want to do is in "basics" but once you click through there the
important stuff like "solvers" is really not very prominent.

Clearly a lot of work is still needed on the organisation here but the
basic question I want to ask about here is for the API reference: what
is a good way to group the different aspects of SymPy into
approximately 5 different categories that actually makes sense to
users and also reflects what SymPy is actually useful for?

--
Oscar

[Aaron Meurer]

> On Jun 19, 2022, at 5:50 AM, Oscar Benjamin <oscar.j....@gmail.com> wrote:

I can take a look at this this week, but I can't promise what can be done by the release. The whole thing is rather bikesheddy, so it might be hard to come to a good consensus.

The main thing I would worry about is any change to the layout that would break urls, as those would need redirects to keep them from breaking. The api categories aren't part of the urls, but the top level categories are.

I think the top level categories are actually fine, though. They just need better explanations of what they are. The separation is based on Diataxis, but that isn't clear from the text on the main page. It's true there aren't many guides yet but that is going to change soon (we already have my work on the custom functions guide and Jeremy's work on the solvers guide).

>
> Then there's the API reference which is organised in a way that
> doesn't really reflect any particular organisation that makes sense to
> anyone I think. It doesn't really break down into the kinds of things
> that users might want to do. Probably most of what a beginner would
> want to do is in "basics" but once you click through there the
> important stuff like "solvers" is really not very prominent.
>
> Clearly a lot of work is still needed on the organisation here but the
> basic question I want to ask about here is for the API reference: what
> is a good way to group the different aspects of SymPy into
> approximately 5 different categories that actually makes sense to
> users and also reflects what SymPy is actually useful for?

Is there a reason to not have more than 5 categories? With the new Furo theme sidebar navigation it's easier to deal with top level nesting.

Aaron Meurer

>
> --
> Oscar
>
> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to sympy+un...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAHVvXxRSj0KK%2BCeurbPiLtSB06qeUOJbRq%2Be%3Do3wFeu40j9_JA%40mail.gmail.com.

[Aaron Meurer]

Here's a first pass and cleaning up the top-level organization. I will look at cleaning up the API docs sections in a separate PR. https://github.com/sympy/sympy/pull/23669

Aaron Meurer

[Oscar Benjamin]

On Sat, 18 Jun 2022 at 13:25, Oscar Gustafsson
<oscar.gu...@gmail.com> wrote:
>
> I've marked a few PRs as candidates to be merged, one requires resolving merge conflicts, but as far as I can tell there are no major arguments against merging them. Feel free to remove the milestone and point out what still may be missing.

I've opened an issue to track releasing SymPy 1.11:
https://github.com/sympy/sympy/issues/23740

I've summarised my view of the status of all issues and PRs tagged for
1.11 there.

--
Oscar