#20246: Use `with strict_equality(True)` to work around hashing of p-adics
-------------------------------------+-------------------------------------
Reporter: saraedum | Owner:
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-7.2
Component: padics | Resolution:
Keywords: days71 | Merged in:
Authors: Julian RĂ¼th | Reviewers:
Report Upstream: N/A | Work issues:
Branch: | Commit:
u/saraedum/use__with_strict_equality_true___to_work_around_hashing_of_p_adics|
f4c5a9db729ccf911517039fdced282588210133
Dependencies: #16342, #16339 | Stopgaps:
-------------------------------------+-------------------------------------
Comment (by nbruin):
Replying to [comment:31 saraedum]:
> I am slightly confused now. So the scenario you described about weak
references does not happen with `weak_dict`, right?
> I do not understand what you mean with "your callback code". Are we just
talking about weakref callback code?
No, any callback code that may exist in sage, may be used by a user, or
may be written in the future.
It's part of Python that various events (deallocation of weakreffed
objects, finalizers for objects, signals) can have code attached to them.
Python will perform callbacks when the relevant events occur. These
callbacks may be triggered within a `with strictequality(true):` block,
because we don't have a way to make these blocks atomic. Thus, callbacks
run with an undefined `strictequality` state. That means that, in order to
verify correctness of code, you would need to prove that no code that
executes during the callback depends on the strictequality state. That's a
highly nonlocal check to make. A real-world example of code that does not
satisfy this requirement is `weakref.WeakValueDictionary`, which is part
of Python's standard lib.
If we were to introduce `strictequality` state, we would invalidate the
use of part of the python standard lib in sage. I don't think it is wise,
from a future development and from a maintenance point of view, to do
this.
Callback code is always precarious to write. I don't think we want to make
it even more difficult to get it right in sage than it already is in
normal python.
--
Ticket URL: <http://trac.sagemath.org/ticket/20246#comment:32>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.