-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
__slots__ #3250
__slots__ #3250
Conversation
V interesting! Is there any downside? IIRC objects don't have a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm glad to see you were able to get rid of _initialized
and speed things up!
It might be (harmless) premature optimization to use __slots__
for every internal xarray class. But certainly doing it for class involved in constructing every xarray object (e.g., Variable/DataArray) makes sense.
This check is only triggered in Python 3.6+. | ||
""" | ||
if not hasattr(object.__new__(cls), "__dict__"): | ||
cls.__setattr__ = cls._setattr_slots |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To clarify, in the future (Python 3.6+ only, post deprecation warning) will we be able to remove assignment to cls.__setattr__
from __init_subclass__
? I'd rather avoid dynamically building methods if possible.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Post deprecation warning and after dropping support for py35, there will only be __setattr__
, statically implemented with what is now the body of _setattr_slots
. __init_subclass__
will retain only the health check.
@max-sixty any package that for any reason expects xarray objects to have a |
We definitely do not guarantee implementation details like xarray objects
having a __dict__. A warning for subclasses is already going above and
beyond IMO.
…On Fri, Aug 23, 2019 at 2:42 PM crusaderky ***@***.***> wrote:
@max-sixty <https://github.com/max-sixty> any package that for any reason
expects xarray objects to have a __dict__ will break overnight. Any
package that subclasses from xarray will get a warning.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#3250?email_source=notifications&email_token=AAJJFVUD2QSIIOF5DHLCGUTQGBDR5A5CNFSM4IO7AUA2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5BI4IA#issuecomment-524455456>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAJJFVUYHG37O2SWYURYRDDQGBDR5ANCNFSM4IO7AUAQ>
.
|
Added automated unit tests for the automated check on |
Python 3.7: In [1]: class A(xarray.DataArray):
...: pass
...:
miniconda3/envs/xarray-py37/bin/ipython:1: FutureWarning: xarray subclass A should explicitly define __slots__
In [2]: a = A()
In [3]: a.x = 1
miniconda3/envs/xarray-py37/bin/ipython:1: FutureWarning: Setting attribute 'x' on a 'A' object. Explicitly define __slots__ to suppress this warning for legitimate custom attributes and raise an error when attempting variables assignments.
In [4]: a.x
Out[4]: 1
In [5]: a.__dict__
Out[5]: {'x': 1} Python 3.5: Same, but without the first FutureWarning. |
Ready for merge if there are no additional comments |
thanks @crusaderky ! |
👍 Thanks @crusaderky |
👍 |
What changes:
__slots__
_initialized
property__slots__
. For third-party subclasses, this is for now a DeprecationWarning and should be changed into a hard crash later on._to_temp_dataset
roundtripDISCUSS: support for third party subclasses is very poor at the moment (#1097). Should we skip the deprecation altogether?
Performance benchmark:
Output:
The performance degradation on Python 3.5 is caused by the deprecation mechanism - see changes to common.py.
I honestly never realised that xarray objects are measured in kilobytes (vs. 32 bytes of underlying buffers!)