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
Currently, to support NumPy's unconventional == operator (returns array of bools, not a bool), the constructor for taxon_info reaches into Python, grabs the object's classes __eq__ operator, and then uses a try-catch statement to swap in the numpy.array_equal operator.
For a given systematics manager, however, the == should be the same for all taxon_info objects. Thus, there is almost certainly a way to store single copy per systematics manager and avoid having to reach into Python every time the constructor is called.
Possible solutions:
The equals operator could live in the wrapped systematics object (need to figure out how to give taxon_info objects access to it).
The taxon_info object could have the equals operator as a static member (tricky, because it can seg-fault on destruction)
The text was updated successfully, but these errors were encountered:
Currently, to support NumPy's unconventional
==
operator (returns array of bools, not a bool), the constructor for taxon_info reaches into Python, grabs the object's classes__eq__
operator, and then uses a try-catch statement to swap in thenumpy.array_equal
operator.For a given systematics manager, however, the
==
should be the same for all taxon_info objects. Thus, there is almost certainly a way to store single copy per systematics manager and avoid having to reach into Python every time the constructor is called.Possible solutions:
The text was updated successfully, but these errors were encountered: