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

Add .copy() to all TL objects #3158

Closed
penn5 opened this issue Sep 12, 2021 · 9 comments
Closed

Add .copy() to all TL objects #3158

penn5 opened this issue Sep 12, 2021 · 9 comments
Labels
enhancement Nice to have things that are not a bug

Comments

@penn5
Copy link
Contributor

penn5 commented Sep 12, 2021

It should accept only kwargs, each one overriding that property in the newly created object.

@penn5 penn5 added the enhancement Nice to have things that are not a bug label Sep 12, 2021
@penn5
Copy link
Contributor Author

penn5 commented Sep 12, 2021

This wouldn't be backwards incompatible

@Lonami
Copy link
Member

Lonami commented Sep 12, 2021

(Split off #1169 (comment)). I'm still not sold on this idea. Also, we would need a better name, since copy can easily be used as an identifier in the api.tl. I'm even thinking about removing all but the special methods in the TLObject and provide the extra functionality through some utils.

namedtuple side-steps this issue by requiring all fields to not start with an underscore, so it can provide namedtuple._replace -- but I'm not fully on board with ignoring the "private names start with underscore" convention just to provide a "useful" _replace method:

>>> A = namedtuple('A', '_replace')

ValueError: Field names cannot start with an underscore: '_replace'

@penn5 penn5 mentioned this issue Sep 12, 2021
@penn5
Copy link
Contributor Author

penn5 commented Sep 12, 2021

I would be in favour of appending an underscore to the TL bit when it has a name collision.

@Lonami
Copy link
Member

Lonami commented Sep 12, 2021

If anything, custom methods would always be end with underscore, so that future versions do not need to be a breaking change.

@penn5
Copy link
Contributor Author

penn5 commented Sep 12, 2021

yeah that's reasonable

@penn5
Copy link
Contributor Author

penn5 commented Dec 28, 2021

This also leads the way to making TL objects immutable and hashable

@Lonami
Copy link
Member

Lonami commented Jan 4, 2022

I'm looking at ways to make objects immutable, and it seems there's no "clean" way to do so? Ways to make a class immutable in Python (and linked How to make an immutable object in Python?). I wonder if it's really worth the effort attempting to forbid immutability.

@penn5
Copy link
Contributor Author

penn5 commented Jan 4, 2022 via email

@Lonami
Copy link
Member

Lonami commented Apr 6, 2023

This is unlikely to happen in the near future so I will be closing the issue. We can reopen it if there's still interest once the time is right.

@Lonami Lonami closed this as completed Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Nice to have things that are not a bug
Projects
None yet
Development

No branches or pull requests

2 participants