You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It seems Spacy has some kind of comparison overloading that throws an error when attempting to compare a Token (and other types) to an unrelated object.
To make python.Boot.toString1 (and trace) more resilient, I propose that isMetaType generates:
type(v) == type and v == t
instead of just
v == t
and also to type t as Class<T> just in case.
What do you think ?
The text was updated successfully, but these errors were encountered:
clemos
pushed a commit
to clemos/haxe
that referenced
this issue
Oct 20, 2021
Hi 👋
I'm working on a personal project with Haxe + Spacy and stumbled upon this "bug".
When calling
trace
on a native python SpacyToken
object, the program will throw:The error occurs in
python.Boot.toString1
, at the following line, which checks if the traced value is the python "str" type:https://github.com/HaxeFoundation/haxe/blob/development/std/python/Boot.hx#L195
which in turn calls this method:
https://github.com/HaxeFoundation/haxe/blob/development/std/python/Boot.hx#L226
It seems Spacy has some kind of comparison overloading that throws an error when attempting to compare a Token (and other types) to an unrelated object.
To make
python.Boot.toString1
(andtrace
) more resilient, I propose thatisMetaType
generates:instead of just
and also to type
t
asClass<T>
just in case.What do you think ?
The text was updated successfully, but these errors were encountered: