Closed vnmabus closed 4 years ago
Thanks. Fixed in 1bba115.
What happened is when a multimethod detects that a subscripted type is in use, it switches to a custom type getter to support checking items in iterables, e.g., List[int]
. In this case, it didn't need to do that (yet), because Union
is more of a special case. So the check is stricter now.
But keep in mind there's still probably a bug in FDataBasis
. From the traceback it looks likes that object is supposed to be iterable but is entering a infinite loop on iteration. Meaning you would see the same error if you tried to register something like FDataBasis[int]
, in which case a multimethod would have to try iterating the instance to work correctly.
Thank you for looking at this. FDataBasis
is not a type which should be iterable at the class level, only instances are supposed to be iterated. Also, maybe related with the infinite recursion, is that obtaining a FDataBasis
element returns another FDataBasis
object (like with the str
class), which maybe is confusing your methods.
Thanks again for your help and your package!
First, let me thank you for this small but incredibly useful package.
I have a problem when the register method tries to infer the parameters from the typing annotations. If I register a function as
then, upon calling the multimethod it will fail with
I see from the call stack that
__iter__
is being called in my objects without reason, so maybe the problem is related with iterable objects.Registering the types manually, however, works well:
Thanks in advance.