ENH: Make layout order an initialization parameter of ArrayProxy #1131
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1131 +/- ##
=======================================
Coverage 91.80% 91.80%
=======================================
Files 101 101
Lines 12445 12454 +9
Branches 2430 2433 +3
=======================================
+ Hits 11425 11434 +9
Misses 693 693
Partials 327 327
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
effigies
force-pushed
the
enh/arrayproxy_order
branch
from
6da2600 to
24b8507
Compare
|
Anybody up for a review? |
|
Will do, tomorrow ... |
There was a problem hiding this comment.
Hmm - I see what you mean, but the interface is now a bit clunky, because there are two ways to override the order. I guess the most direct interface would be to make the class variable be default_order. Is there a good way of going there without breaking people's code?
| fobj.write(arr.tobytes(order='F')) | ||
| prox = ArrayProxy(fobj, hdr) | ||
| sliceobj = (None, slice(None), 1, -1) | ||
| assert_array_equal(arr[sliceobj] * 2.0 + 1.0, prox[sliceobj]) | ||
|
|
||
|
|
||
| @pytest.mark.parametrize("order", ("C", "F")) |
There was a problem hiding this comment.
Does not work for fobj.write(arr.tobytes(order=order)) (currently L198). This is testing override specifically, so I'm not sure "use default" is really relevant.
Could change |
Co-authored-by: Matthew Brett <[email protected]>
effigies
force-pushed
the
enh/arrayproxy_order
branch
from
b7c179c to
8acd26f
Compare
Nice idea. |
effigies
force-pushed
the
enh/arrayproxy_order
branch
from
8acd26f to
dcf9566
Compare
|
Matthew, any further comments? |
| 'to avoid conflict with instance variables.\n' | ||
| '* deprecated in version: 5.0\n' | ||
| '* will raise error in version: 7.0\n', | ||
| DeprecationWarning, stacklevel=2) |
There was a problem hiding this comment.
I forget the mechanism to time out the deprecation warning ... but shouldn't we put that in here?
There was a problem hiding this comment.
It's a decorator that works for deprecating an entire function/method/class. It does not work for cases like this. This is why I added the check below:
| _default_order = 'C' | ||
|
|
||
|
|
||
| class DeprecatedCArrayProxy(ArrayProxy): |
There was a problem hiding this comment.
Timed out depraction again (as above)?
There was a problem hiding this comment.
This is specifically for testing. The warning/expiration will show up in test_deprecated_order_classvar. When we remove that function, we can remove this class. I'll add a comment...
Co-authored-by: Matthew Brett <[email protected]>
| 'to avoid conflict with instance variables.\n' | ||
| '* deprecated in version: 5.0\n' | ||
| '* will raise error in version: 7.0\n', | ||
| DeprecationWarning, stacklevel=2) |
There was a problem hiding this comment.
It's a decorator that works for deprecating an entire function/method/class. It does not work for cases like this. This is why I added the check below:
| # Start raising errors when we crank the dev version | ||
| if Version(__version__) >= Version('7.0.0.dev0'): | ||
| cm = pytest.raises(ExpiredDeprecationError) | ||
| else: | ||
| cm = pytest.deprecated_call() |
| _default_order = 'C' | ||
|
|
||
|
|
||
| class DeprecatedCArrayProxy(ArrayProxy): |
There was a problem hiding this comment.
This is specifically for testing. The warning/expiration will show up in test_deprecated_order_classvar. When we remove that function, we can remove this class. I'll add a comment...
|
Thanks! |
For #1090, it's been useful to set the proxy order dynamically, rather than subclassing
ArrayProxy. This makes it an initialization argument. I've left it as a class variable on the off-chance that somebody actually uses something like:Minor in-passing cleanups, such as removing the explicit
(object)superclass and moving the test loops to parametrizations.