Hi --Person who I've never met-- Steven,
I happen to have a few insights on the matter. Doing a quick example class (see below), the following observations were made when instanciating this class. Note that we'll only cover the instanciation case, not the calling of those functions, as it is pretty easy to see that they will crash.
classdef SomeDummyClass
properties
Foo (1,1)double
end
methods
function SomethingThatClearlyUsesPython(this)
% This crashes when python is not installed
py.SomePackage.SomeFunction();
end
function SomethingThatIndirectlyUsesPython(this)
% This does not crash
ThisFunctionCallsPyDotSomePackageDotSomeFunction();
end
function out = SomethingThatUsesANonexistantClass(this, other)
arguments
this
other (1,1)ThisClassDoesNotExist
end
% This does not crash
out = ThisClassDoesNotExist();
end
end
end
When python is not installed, only direct calls to "py." cause the error on instanciation. If we comment out the whole "SomethingThatClearlyUsesPython" function, the instanciation works without any issue.
From this, I would hypothesize that:
Matlab does not care about the contents of class methods during instanciation, except if there is "py." somewhere inside it.
Would be nice if a Matlab person could confirm if this statement is truly accurate, but so far it seems to be empyrically correct.
I would recommend moving the direct calls to "py." outside of your class, this will allow you to load the data without caring about what is contained inside the functions.
Cheers!
