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
Remove Python access from Parent._element_constructor #23881
Comments
Replying to @jdemeyer:
I am not sure whether |
comment:2
Replying to @simon-king-jena:
I never claimed that it is. Please see my last comments on #23880. |
comment:3
Replying to @jdemeyer:
So, your suggestion is to rename |
comment:4
Replying to @simon-king-jena:
Note that a Cython |
comment:5
I guess the following is what we have to change:
and
|
comment:6
Replying to @simon-king-jena:
The above is strange. Shouldn't
Here we could probably use the default implementation of
An internal attribute such as |
comment:7
Replying to @simon-king-jena:
Why should it be a tuple?? Very strange. |
comment:8
Replying to @simon-king-jena:
I see: It is not a tuple, but it is the class . That's probably a tricky case: The elements are tuples, so, the elements are not instances of |
comment:9
Replying to @simon-king-jena:
looking at the last few lines of sagemath/sagetrac-mirror@a291564 |
comment:10
Replying to @mantepse:
Probably you are right. And the fact that it doesn't fail indicates that it isn't sufficiently tested. |
comment:11
Replying to @simon-king-jena:
I just checked, it's just a speedup of a factor 4 - I guess there is no performance testing in sage:
|
comment:12
Replying to @mantepse:
What is |
comment:13
Replying to @simon-king-jena:
That's the new (correct) implementation - I always put in old and new in parallel for the comparison. That's #23882 now. |
Dependencies: #23882 |
comment:15
On top of #23882, I propose to first remove |
comment:16
I think the following grep is also needed:
|
comment:17
and another one:
|
comment:18
The documentation already is a lot worse than I thought:
Of course, the documentation should explain how to implement |
Commit: |
comment:22
Briefly looking at your commit: I find it a good idea that you are using a My commit fixes one part of the documentation (in sage.schemes). New commits:
|
Changed author from Jeroen Demeyer to Jeroen Demeyer, Simon King |
New commits:
|
comment:51
Green patchbot => positive review. |
Reviewer: Travis Scrimshaw |
comment:52
Both arando and rk02-math seem to fail the same test:
Which they do not seem to fail on with other tickets. |
comment:53
I don't see how those failures could be related to the changes in this ticket unless they appear also in one of the dependencies. Even still, I don't see how they could be connected, much less be machine dependent. |
comment:54
I don't see see why either so I agree it is highly unlikely, but since There are two machines failing on this ticket and I have not seen it on either arando or rk02-math in at least 10 other failing logs that I checked. So from this point of view it is also very unlikely that it is not from this ticket. Of course this ticket could have been very unlucky to expose a rare random bug twice for the first time but this is also highly unlikely. I just would like to see arguments for why we are in one unlikely scenario and not the other. Note that this ticket also has a lot of dependencies merged so it could also be exposed by one of the dependencies, which might explain why I didn't see it on any of the arando and rk02-math logsI checked. If only we could search through the patchbot log easily, then we could get conclusive answers much faster. |
comment:55
I don't think that the failures have anything to do with this ticket, so I'm setting it to positive_review. If the failures are real, then it will fail on Volker's buildbot anyway. |
comment:56
I also tested it on arando manually (without the patchbot) and that test passed. |
comment:57
Before you reported that arando passes all test I kicked the patchbot to get more info. And arando did fail again on the run resulting from that kick, while the bug did not occur in two tests ran on arando in between. I am a bit mystified by the situation since it can't be the optional packages since rk02-math has none, so it must be a randomly occuring bug. |
comment:58
I tested this with
on arando and they all pass so it is not easily reproducible. |
comment:59
The sha_tate doctest fails on sage8.1.beta7 without any patches on arando so I created #23962, since arando failed on the 3 tests it ran on this ticket, but none of the other beta6 tests, I still suspect it to be something introduced by one of the dependencies of this ticket that got merged in sage8.1.beta7. Anyway it can't be this ticket so lets move the discussion to #23962. |
Changed branch from u/jdemeyer/rename_parent__element_constructor____parent___construct_element to |
comment:63
Good that this is merged now... |
Changed commit from |
In order to avoid confusion between
_element_constructor_
(a public interface) and_element_constructor
(a private attribute), we change the latter fromcdef public
tocdef
. The same for_element_init_pass_parent
. This way, those attributes can no longer be accessed from Python.Depends on #23882
Depends on #23884
Depends on #23894
Depends on #23899
Depends on #23905
Depends on #23907
Depends on #23914
Depends on #24033
CC: @simon-king-jena @koffie
Component: coercion
Author: Jeroen Demeyer, Simon King
Branch:
41614a7
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/23881
The text was updated successfully, but these errors were encountered: