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
py3: numerous string fixes to sage.numerical.backends #24740
Comments
Commit: |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Replying to @embray:
They don't seem to be performance-critical methods, so I'm fine with it. One potential problem for reviewing this ticket is that it involves several external packages, some of which are not even free to install. |
comment:4
This ticket makes me think of a general problem with |
comment:5
In |
comment:6
Several "vertex" methods in |
comment:7
Replying to @jdemeyer:
That would actually be bad because it would break most cases which explicitly should not accept bytes. Specifically for filenames, it's better to just make a special case for accepting bytes. Though I don't think high-level file handling functions need accept bytes in most cases either unless there were an explicit reason to. |
comment:8
Replying to @jdemeyer:
I can't say I'm 100% clear on that myself since it's not obvious that this code is even used anywhere in Sage. But it's duplicating the Sage Graph API and I don't see what makes you think it should accept bytes. |
comment:9
Replying to @jdemeyer:
It is a problem, and some of these modules are not well tested because of it. Though in the cases I've changed it should be fairly clear that it's the right approach in general (i.e. we are passing python |
comment:11
I believe this issue can reasonably be addressed for Sage 8.4. |
comment:12
Replying to @embray:
How about a new function |
comment:13
How does this ticket now relate to #26020? It wasn't clear to me why it needed to broken into a separate ticket in the first place. Are we still going to add |
comment:15
These changes look fine to me (but I haven't tested anything). |
comment:18
Sorry, yeah, I'll take care of it. I think I stalled on this one because Jeroen had made some comments earlier, which seemed to suggest a course of action he preferred, and I was waiting for confirmation from him but it never came. I'll just clean up the existing fixes here and worry about the |
comment:21
I just rebased the existing branch on 8.5.beta6. I can see that there's a case to be made for still allowing some of these methods to accept filenames as bytes, but I think this is fine for now until and unless a specific need for it arises. |
comment:22
the import of |
Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:
|
Reviewer: Frédéric Chapoton |
comment:25
in src/sage/numerical/backends/cvxopt_sdp_backend.pyx, same in src/sage/numerical/backends/generic_sdp_backend.pyx otherwise, looks good to me (as far as I can tell) |
comment:26
Ah, very true (not that many people are likely to read that, but best to be consistent). |
comment:27
No, they're fine. I checked the code and it doesn't need updating in those cases. For some reason they already correctly read |
comment:28
oh, well. Let it be. @vbraun: probably safer to keep this one for 8.6.beta0 |
Changed branch from u/embray/python3/sage-numerical-backends/string to |
comment:31
Maybe the problem described in ticket #26999 was produced by the numerous string fixes made here. Can you take a look? |
Changed commit from |
Trying to make progress on my backlog of Python 3 fixes I haven't made tickets for...
This one is slightly questionable in that there were many
cpdef
functions in this package that takechar *
arguments, and I changed them to take non-typed arguments (effectivelystr
).I'm not exactly sure what implication this has for the C interfaces that were exported for these methods, or if we care.
Component: python3
Author: Erik Bray
Branch:
da920d5
Reviewer: Frédéric Chapoton
Issue created by migration from https://trac.sagemath.org/ticket/24740
The text was updated successfully, but these errors were encountered: