-
-
Notifications
You must be signed in to change notification settings - Fork 374
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
Do we want to guarantee deepcopied attributes when converting ? #43
Comments
Eh could you rephrase + elaborate please? I have a nasty head cold and can’t entirely follow. :) |
Let me try again :) As in #28, the speed difference is because we iterate over the attr descriptors using In #28, we've fixed it by iterating using |
Um this would only matter, if someone would modify the attribute list in their container, right? (which they never should) |
Ok, let me prepare a PR then. What is the rationale for using |
I find there’s a difference between a public API like fields and misbehaving in an converter. But maybe I’m wrong. :) |
do you think you can get it done by say Wed? I’d like to push out a release before PyCon |
looks like I could ! Too bad I could not make it up this year at PyCon... |
aw :( |
A reminiscence of #28:
Now, the fix may not be as trivial as #28, because I can see how it may be part of the API that the original attribute is not touched when using
convert
, and not usingfields
to iterate in https://github.com/hynek/attrs/blob/master/src/attr/_make.py#L447 would break that promise. As I have not seen any test related to this, maybe that promise could be relaxed ?The text was updated successfully, but these errors were encountered: