-
-
Notifications
You must be signed in to change notification settings - Fork 491
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
Meta-ticket: Support Python's __copy__ / __deepcopy__ protocol #13811
Comments
Author: cnassau |
Changed author from cnassau to Christian Nassau |
comment:4
Hi Christian! Families are (semantically) immutable objects. Why would we want to copy them? Cheers, |
comment:5
Replying to @nthiery:
Good point... I stumbled across this issue while I was struggling to create a disjoint union of a dynamically generated family of I do think that user code can expect that
Cheers, |
comment:6
Replying to @cnassau:
Yes, it would make sense to have copy(x) return x for all immutable objects in Sage. I am not sure how to achieve this though: we do not (yet?) have a class for providing code for all immutable objects in Sage, and I would not want to force every relevant class to reimplement a trivial For the case at hand (families), maybe one could add a method Parent.copy returning Cheers, |
A patch for this problem |
comment:7
Attachment: lazyfamcopy.patch.gz |
comment:11
Hi, As Nicolas suggested in his comnent 6,
It is standard Python for immutable objects
Vincent |
Changed author from Christian Nassau to none |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:48
For the pattern in comment:45, with #29101 ("Refined protocol for
Decision time... |
comment:49
Replying to @mkoeppe:
This pattern -- expecting that |
Dependencies: #32454 |
comment:52
That may indeed be the case. As you say, at the time the goal was standardized Sage command structure, but if there is a more (modern) Pythonic way to handle this, #6522 alone shows how much gnashing of teeth surrounded some of these changes at the time, so more power to you as long as any syntax changes would be documented. One should also be sure that things which would "naturally" be seen as copyable are, but other than |
comment:53
Regarding the pair of methods |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
comment:57
Some more data points on other libraries:
|
Most Sage objects are immutable. Nevertheless,
copy
anddeepcopy
make copies (through pickling/unpickling) for them because we have not provided the classes with__copy__
methods (which should just return the object) and__deepcopy__
methods (which in many cases should just return the object).Another symptom (from the original ticket description): Copying of (immutable!)
LazyFamily
objects only works for families that can be pickled:The case of
__deepcopy__
of immutable container-like objects (likeFamily
orSequence
) is a bit trickier: Is immutability intended to imply that the elements are immutable too? In this ticket, we make no such assumption.Tickets:
__copy__
and__deepcopy__
methods for number types__copy__
and__deepcopy__
methods for number field elements__copy__
and__deepcopy__
methods for symbolic expressions and functions__copy__
and__deepcopy__
methods forFamily
andSet
__copy__
methods for all classes that definecopy
methodssage.tensor
,sage.manifolds
:__copy__
,__deepcopy__
methods for all classes that definecopy
methodscopy(CombinatorialFreeModule.Element)
broken by Cythonize CombinatorialFreeModuleElement #22632Related:
Depends on #32454
CC: @tscrim @mjungmath @nbruin @kwankyu @williamstein @mwageringel @kcrisman
Component: pickling
Keywords: LazyFamily, copy, pickle
Author: Matthias Koeppe
Branch/Commit: u/mkoeppe/__copy___and___deepcopy___methods_for_all_immutable_sage_objects @
2bd01ae
Issue created by migration from https://trac.sagemath.org/ticket/13811
The text was updated successfully, but these errors were encountered: