Closed ldunham1 closed 7 years ago
Hmm, this is a problem... we'll look into this!
(Apologies, for some reason I had originally misread your report, thinking you were saying the inverse - that it errored, and you wanted to delete...)
Looks like you figured it out. =)
...and your description was perfectly clear - I just need to not respond to issues first thing after waking up, I guess. =)
Re: the issue though... it turns out to be a little trickier than I had thought. It seems that most pymel operations will operate in this manner - ie, warn when resolving to a name, but then operate on that name if it exists, and only error if it no longer does.
I'm not a fan of this behavior - I think it should error as you do - but changing this would probably break a lot of "functioning" code. (Ie, cases where folks have long lists of nodes, one or two of which are deleted, and they would like it to essentially "ignore" the deleted nodes and just operate on the non-deleted ones... and/or actually DO want the deleted ones to just operate on nodes of the same name).
I think I'll perhaps make this a configurable option - so that instead of printing a warning, it simply errors. It would then give the "desired" behavior in your example, with one exception - it would also error when simply printing the deleted node's name. While I can see an argument for still allowing access to a deleted node's name without error, I think there's an at-least-equally-valid argument to be made for also erroring on name access... and from a practical standpoint, trying to allow name-access, but not anything else, would be very difficult to do. If you do have situations where you really want to know the name of deleted nodes, then you can probably temporarily turn off the error-on-deleted-nodes setting using a try/finally clause.
I would expect calling delete on a deleted PyNode to raise an error even if another node has the same unique name.