Skip to content
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

copy() method for UTCDateTime #1452

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

claudiodsf
Copy link
Member

Just found myself needing to copy a UTCDateTime() object.
I thought that it might be useful.

@claudiodsf claudiodsf added this to the 1.1.0 milestone Jun 15, 2016
@trichter
Copy link
Member

trichter commented Jun 15, 2016

Why not just assign utc2=utc instead of copy utc2=utc.copy()?

EDIT: OK, for a real copy you need to do utc2=utc+0

@claudiodsf
Copy link
Member Author

@trichter Yep, but that solution is pretty inelegant...
Another solution is utc2 = UTCDateTime(utc). This is what I do in my code, but it happened that, after few months, I forgot why I was doing that and I reverted my code to urc2 = utc which obviously didn't give the good results.
That's why I thought that utc.copy() would be a nice solution because it clearly says what you want to do.

@krischer
Copy link
Member

At one point we discussed making the UTCDateTime object immutable which would still be nice. Assuming we would have that I still don't think one can make Python objects "copy at assignment" which is effectively how integers work in Python.

So I think we might want to have this method. It still needs a test.

@claudiodsf
Copy link
Member Author

Sure. Will add a test later today.

@jkmacc-LANL
Copy link
Contributor

@krischer Immutable? I've got a lot of dt += 1.5 usage; would it just .copy() as part of the __add__?

@megies
Copy link
Member

megies commented Jun 16, 2016

UTCDateTime doesn't have __iadd__ implemented, that means it's falling back to __add__, creating a new object and returning it. (edit: since UTCDateTime is circling around a single float, it kind of behaves like one, immutability-wise)

I think currently the only way to really change a UTCDateTime object in place is using one of the private ._set_...() methods or manually setting the .timestamp.

If we really add the copy() method, we also might want to think about making properties like year settable (via _set_year()), I think. So that's basically saying, either we make it strictly immutable or also allow modifying via convenience properties (e.g. t.year += 1).

@megies megies added the .core issues affecting our functionality at the very core label Jun 16, 2016
@claudiodsf
Copy link
Member Author

@megies I'm probably missing something: isn't t.year += 1 already possible?

@megies
Copy link
Member

megies commented Jun 16, 2016

Oh, indeed.. 😊 didn't see the property() call (usually use the decorator notation myself..)
👍 for the copy() method..

@krischer
Copy link
Member

I think we should still make UTCDateTime immutable. += would return a new object and dt.year = 1 and consorts should raise an error. I reopened #568 to discuss this in a bit more detail.

@claudiodsf
Copy link
Member Author

I'm holding on this one, until you decide whether UTCDateTime should become immutable or not.

@megies megies modified the milestones: 1.1.0, 1.2.0 Nov 7, 2016
@megies megies modified the milestones: 1.2.0, 1.3.0 Apr 19, 2018
@megies megies modified the milestones: 1.3.0, 2.0.0 Feb 15, 2019
@trichter trichter modified the milestones: 1.3.0, 1.4.0 Jan 6, 2022
@megies megies modified the milestones: 1.4.0, Future release Jun 21, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
.core issues affecting our functionality at the very core
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants