Same class but imported twice from different nodes will not be recognized as same about nodezator HOT 6 CLOSED

I'm always glad to be of help.

Since it seems it will be a while before you can even consider doing anything about this, I'm going to close the issue for now.

And don't worry: when you have the time to get back to this issue and try what I suggested, if at that time things don't work and you still want help solving this, just drop a message to me on discord and I'll reopen this issue so we can keep searching for the cause of the problem and solve it.

from nodezator.

This might be related to my answer on issue #81

Could you share more details, please?

For instance, is the class imported from the same library? Or, perhaps, is the class definition (source) present in both node scripts?

I might know what is causing this but I need more information about the problem to be certain and come up with possible solutions.

from nodezator.

The class (let's say Microblog) definiton is present in lazycommon (a package available as an import)

...and 2 node-packs (in this instance lazycommon is a node-pack in itself, and the other is from lazysummary).

Now as I connect a node from lazycommon that has an option menu widget with the avail. classes (such as Microblog) it outputs the chosen class. (Not an instance, the class itself.)
(Callables for each class might've worked here, but a new class can be added anytime, so a widget seemed more appropiate.)

Now when that class is received on a node from lazysummary (as in), checking issubclass(in, Microblog) no longer works (even though we do the same import statement in both nodes).

(I'll post my repo here if I wasn't detailed enough, but it's undocumented atm.)

from nodezator.

I myself switched approaches now (as this solution had scaling issues anyway), but the root of the problem is still there for anyone who needs checking like that. Actually my current system could use both, and I'd prefer that classes equal to themselves over 2 nodes.

(Plus for a future type system this could cause troubles too.)

from nodezator.

Hello, Mr Vári,

As you know, I've been busy with other Nodezator dev tasks, other unrelated tasks and your other issue for which I released a bugfix recently (the overflowing dialog). This is why I couldn't look into this issue sooner.

I read carefully your explanation, downloaded and inspected the code you linked as well, but couldn't pinpoint the problem.

I also wasn't able to reproduce the bug on my end. That is, I tested two different dummy node packs that imported classes from a third-party library installed with pip (the Pillow library). I also made it so the node packs imported a dummy class I put in a module I created on my site-packages folder.

In both cases, the classes returned from the nodes were passed to the issubclass node (that just calls Python's issubclass built-in) and the behaviour you described wasn't observed.

This indicates the likelihood of the problem being on your end or, as you said, maybe a Python oddity.

Even so, it will be my pleasure to keep helping you pinpoint the problem if you are still interested. Even though you said you switched approaches, it may help you in future having this kind of problem figured out so that you avoid tripping on it or can quickly solve it if you encounter it again.

If you are willing to figure it out, here's what you could do next: in cases such as this one where an unexpected result or comparison happens, you could try to further inspect the runtime objects involved, as this can reveal valuable info about them.

In your case specifically, simply printing the classes could reveal their origin, as the packages/modules from where the classes were imported should appear in the printed string (like this: pkg.mod.ClassName, etc.). This info could help identify whether they were imported from the same place or not (for instance, if their name is slightly different like this: pkg.mod1.ClassName and pkg2.mod2.ClassName).

If you are too busy or just not interested in this approach anymore, it is fine. You can just ignore this message and I'll close this issue in one or two weeks. Otherwise, if you are interested, please, see if you can recreate your original context and try the steps I suggested above to see if you can pinpoint the problem. There's no rush either, just let me know if you are interested and I'll wait patiently for your reply when you can.

For now, I suspect the problem may be caused by a name clash (since the code is deeply nested and has many modules with the same name) or some kind of internal transformation the original class is being subjected to in some part of the code away from your control (maybe imported code from other libs). This is all mere speculation, however.

Despite my analysis, there's always the possibility that I'm wrong or perhaps missed something, so I'd like to know the true cause of this problem. That is, only if you are indeed interested and have the time.

Peace.

from nodezator.

In your case specifically, simply printing the classes could reveal their origin, as the packages/modules from where the classes were imported should appear in the printed string (like this: pkg.mod.ClassName, etc.). This info could help identify whether they were imported from the same place or not (for instance, if their name is slightly different like this: pkg.mod1.ClassName and pkg2.mod2.ClassName).

Didn't knew I could do this, thanks.

If you are too busy or just not interested in this approach anymore, it is fine.

I'm in the middle of my exam season, so it'll be quite some time until I can get back to my projects: and as it's probably a problem on my end, it's not an urgent issue.

Thanks for analysing my code!

from nodezator.