Closed aplavin closed 1 year ago
Merging #997 (d2b9cd0) into master (b27bd5a) will decrease coverage by
0.01%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## master #997 +/- ##
==========================================
- Coverage 68.36% 68.35% -0.02%
==========================================
Files 20 20
Lines 2023 2038 +15
==========================================
+ Hits 1383 1393 +10
- Misses 640 645 +5
Flag | Coverage Δ | |
---|---|---|
unittests | 68.35% <100.00%> (-0.02%) |
:arrow_down: |
Flags with carried forward coverage won't be shown. Click here to find out more.
Impacted Files | Coverage Δ | |
---|---|---|
src/PyCall.jl | 72.18% <100.00%> (+1.49%) |
:arrow_up: |
src/gui.jl | 0.00% <0.00%> (ø) |
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.
bump
Looks good, modulo a couple of minor tweaks noted above.
I also pushed the corresponding setproperty fix, if you know the proper way to check the exception please update it as well! For now, getproperty tests fail with your changes.
What is e.T
that pyisinstance(e.T, @pyglobalobjptr(:PyExc_AttributeError))
fails to give the expected result?
In the two corresponding cases, it's:
e.T = PyObject <class 'ValueError'>
# and
e.T = PyObject <class 'AttributeError'>
What does pyisinstance(e.T, @pyglobalobjptr(:PyExc_AttributeError))
return in those cases?
Oh, I see the problem. e.T
is not an instance of AttributeError
, it is the type itself. So the correct check is
if PyPtr(e.T) != @pyglobalobjptr(:PyExc_AttributeError)
(The goal here is to avoid the string conversion. Also, checking whether it is actually PyExc_AttributeError
, not just named "AttributeError"
, is in principle more robust.)
this throws KeyError as before when the attribute isn't there (AttributeError in python) when the attribute is present, but its computation throws a python exception, this PR rethrows it in julia
fixes https://github.com/JuliaPy/PyCall.jl/issues/696