Open briango28 opened 4 months ago
Thanks for the report, do you have a code snippet to reproduce the problem as stated in the title?
See the following colab:
https://colab.research.google.com/drive/1p7YnYJpIvpM197VKUX7Ig3kTojpL_ILK?usp=sharing
A TypeError
is raised due to incompatible dtypes (tf.string
given to a numeric op), but Sequential
intercepts it and reraises a misleading ValueError
.
The call function signatures are direct implementations of the side effect cases mentioned above.
Note that no. 2 is rather niche because keras prevents a Layer
with such a call signature from being instantiated; the example works because the call method is replaced after instantiation.
keras.Sequential.build()
builds by running a placeholder tensor through each given layer to build aFunctional
model.The method explicitly handles two types of exceptions:
NotImplementedError
andTypeError
, of which the latter is intercepted in order to reraise aValueError
in the case of parameter incompatibility.However, the mechanism to check whether the layer's
call()
method is compatible with theSequential
API currently assumes any argument without a default value is a positional argument, presenting some unintended side effects:call()
method with default values for all parameters will be reported to have no positional argumentscall()
method with a single keyword-only parameter without a default value will not be detected as erroneous.*args
or**kwargs
parameters will be included as positional arguments, whether or not they are required for the layer to runWhile there is no sane way to detect whether a layer with variable arguments is properly defined, the other issues may be avoided by checking the
kind
field of each parameter along with the existence of a default value.I might've missed some possible cases; feedback would be appreciated.