8000 Make Sequence pretty-printed in IPython by user202729 · Pull Request #39027 · sagemath/sage · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Make Sequence pretty-printed in IPython #39027

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

Merged
merged 12 commits into from
Jan 4, 2025

Conversation

user202729
Copy link
Contributor
@user202729 user202729 commented Nov 24, 2024

Related to #36801 , but this does not resolve that one. Instead:

  • modify the function to respect _repr_pretty_ just like IPython
  • implement _repr_pretty_ for Sequence and PolynomialSequence
  • Add notes that _repr_ and cr= and cr_str= of Sequence are mostly unused
  • Add # need sage.groups (automatic fix by sage-fixdoctests)

When #36801 is implemented part of this would be redundant (because Sequence derives from list)

📝 Checklist

  • The title is concise and informative.
  • The description explains in detail what this PR is about.
  • I have linked a relevant issue or discussion.
  • I have created tests covering the changes.
  • I have updated the documentation and checked the documentation preview.
  • fix doc tests
  • explain meaning of cr=True in Sequence constructor

⌛ Dependencies

Copy link
github-actions bot commented Nov 24, 2024

Documentation preview for this PR (built with commit 2d5ce6d; changes) is ready! 🎉
This preview will update shortly after each push to this PR.

@tobiasdiez
Copy link
Contributor

In general, I like the new output more. Especially:

File "src/sage/tests/books/computational-mathematics-with-sagemath/linalg_doctest.py", line 402, in sage.tests.books.computational-mathematics-with-sagemath.linalg_doctest
Failed example:
    A.eigenvectors_right()
Expected:
    [(4, [
    (1, 5, 5, 1)
    ], 1), (1, [
    (0, 1, 1, 4)
    ], 1), (2, [
    (1, 3, 0, 1),
    (0, 0, 1, 1)
    ], 2)]
Got:
    [(4, [(1, 5, 5, 1)], 1),
     (1, [(0, 1, 1, 4)], 1),
     (2, [(1, 3, 0, 1), (0, 0, 1, 1)], 2)]

Since its also aligns well with standard IPython behavior, I would say go ahead and fix the tests so we can merge it.

@user202729
Copy link
Contributor Author
user202729 commented Dec 11, 2024

#39058 bites again.


The code actually become quite ugly once I notice PolynomialSequence exists. Will leave a note there for the thing to be cleaned up eventually when #36801 is fixed.

On another note, should we deprecate cr= and cr_str=?

@user202729 user202729 marked this pull request as draft December 12, 2024 13:08
@user202729
Copy link
Contributor Author

I realize this is rather problematic: the current behavior ignores _repr_pretty_ (which IPython supports), and the representation logic of PolynomialSequence is rather complicated:

        if len(self) < 20:
            return Sequence_generic._repr_(self)
        else:
            return "Polynomial Sequence with %d Polynomials in %d Variables" % (len(self),self.nvariables())

I propose we add back _repr_pretty_ support, then move the current Sequence pretty printer (as well as PolynomialSequence) to the class.

Also avoid confusion like #26792 (comment)

8000

@user202729 user202729 force-pushed the ipython-sequence-pretty branch from 1c240dd to 76bc991 Compare December 22, 2024 13:25
@user202729 user202729 marked this pull request as ready for review December 22, 2024 14:45
Copy link
Contributor
@tobiasdiez tobiasdiez left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@user202729
Copy link
Contributor Author

I just went through the whole diff and notice a handful of ... being changed automatically or # random being automatically removed by --fixdoctests… so I just add them back.

vbraun pushed a commit to vbraun/sage that referenced this pull request Jan 1, 2025
sagemathgh-39027: Make Sequence pretty-printed in IPython
    
Related to sagemath#36801 , but this does not resolve that one. Instead:

* modify the function to respect `_repr_pretty_` just like IPython
* implement `_repr_pretty_` for `Sequence` and `PolynomialSequence`
* Add notes that `_repr_` and `cr=` and `cr_str=` of `Sequence` are
mostly unused
* Add `# need sage.groups` (automatic fix by sage-fixdoctests)

When sagemath#36801 is implemented part of this would be redundant (because
`Sequence` derives from `list`)

### 📝 Checklist

<!-- Put an `x` in all the boxes that apply. -->

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [ ] I have updated the documentation and checked the documentation
preview.
- [x] fix doc tests
- [x] explain meaning of `cr=True` in `Sequence` constructor


### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->
    
URL: sagemath#39027
Reported by: user202729
Reviewer(s): Tobias Diez
@vbraun vbraun merged commit c529293 into sagemath:develop Jan 4, 2025
20 of 22 checks passed
vbraun pushed a commit to vbraun/sage that referenced this pull request Feb 22, 2025
sagemathgh-39420: Replace reproducible_repr() with usage of displayhook
    
* It is not very well-known that doctest has magic features to ignore
the ordering of `dict` and `set` (see for example
sagemath#39413 (comment) ), I
try to make it more discoverable.
* Since the displayhook is in place (since
68b10e1), the `reproducible_repr`
(added in e68d6eb) is mostly redundant.
* Implement `_repr_pretty_` for `KeyConvertingDict` to make doctest
deterministic. (based on the framework of
sagemath#39027)

There's a slight difference between `reproducible_repr` ordering (which
always order by string representation) and this function (which tries
first to order by element values, then by string representation), and
the ordering of elements is reversed for multivariate polynomial ring
(in `R.<x,y,z> = QQ[]`, `z < y < x`). However, it should still be
deterministic.

### 📝 Checklist

<!-- Put an `x` in all the boxes that apply. -->

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation and checked the documentation
preview.

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->
    
URL: sagemath#39420
Reported by: user202729
Reviewer(s): Tobias Diez, user202729
vbraun pushed a commit to vbraun/sage that referenced this pull request Feb 24, 2025
sagemathgh-39420: Replace reproducible_repr() with usage of displayhook
    
* It is not very well-known that doctest has magic features to ignore
the ordering of `dict` and `set` (see for example
sagemath#39413 (comment) ), I
try to make it more discoverable.
* Since the displayhook is in place (since
68b10e1), the `reproducible_repr`
(added in e68d6eb) is mostly redundant.
* Implement `_repr_pretty_` for `KeyConvertingDict` to make doctest
deterministic. (based on the framework of
sagemath#39027)

There's a slight difference between `reproducible_repr` ordering (which
always order by string representation) and this function (which tries
first to order by element values, then by string representation), and
the ordering of elements is reversed for multivariate polynomial ring
(in `R.<x,y,z> = QQ[]`, `z < y < x`). However, it should still be
deterministic.

### 📝 Checklist

<!-- Put an `x` in all the boxes that apply. -->

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation and checked the documentation
preview.

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->
    
URL: sagemath#39420
Reported by: user202729
Reviewer(s): Tobias Diez, user202729
vbraun pushed a commit to vbraun/sage that referenced this pull request Feb 27, 2025
sagemathgh-39420: Replace reproducible_repr() with usage of displayhook
    
* It is not very well-known that doctest has magic features to ignore
the ordering of `dict` and `set` (see for example
sagemath#39413 (comment) ), I
try to make it more discoverable.
* Since the displayhook is in place (since
68b10e1), the `reproducible_repr`
(added in e68d6eb) is mostly redundant.
* Implement `_repr_pretty_` for `KeyConvertingDict` to make doctest
deterministic. (based on the framework of
sagemath#39027)

There's a slight difference between `reproducible_repr` ordering (which
always order by string representation) and this function (which tries
first to order by element values, then by string representation), and
the ordering of elements is reversed for multivariate polynomial ring
(in `R.<x,y,z> = QQ[]`, `z < y < x`). However, it should still be
deterministic.

### 📝 Checklist

<!-- Put an `x` in all the boxes that apply. -->

- [x] The title is concise and informative.
- [x] The description explains in detail what this PR is about.
- [x] I have linked a relevant issue or discussion.
- [x] I have created tests covering the changes.
- [x] I have updated the documentation and checked the documentation
preview.

### ⌛ Dependencies

<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->
    
URL: sagemath#39420
Reported by: user202729
Reviewer(s): Tobias Diez, user202729
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0