Selected shape object disappears (undesired garbage collection?)

[olcc]

Hello,

In the following script, shape s disappears even though it is still bound to an identifier. Is it normal? Can it be improved?

import pya
import time

layout_view = pya.LayoutView.current() 
     
def get_selection():
  return layout_view.object_selection
  
# We suppose that the selection contains shapes
shapes = [opath.shape for opath in get_selection()]

s = shapes[0]
print("Shape: {}".format(s))  # Shape: box (x;y)
time.sleep(1)
print("Shape: {}".format(s))  # Shape: null

Note: A workaround is to keep a reference to layout_view.object_selection. But, as said, it is a workaround. The shape object should normally survive without this workaround, no?

[klayoutmatthias]

Thanks for reporting this. It's kind of weird. Apparently I don't understand precisely what the list comprehension does with the reference count of Python objects. A simple print("anything") is sufficient to spoil the reference to the Shape objects.

The expanded form works well:

shapes = []
for opath in get_selection():
  shapes.append(opath.shape)

I wonder what's the difference between this form and [ opath.shape for opath in get_selection() ]. That's going to be some awful debugging ...

Matthias

[thomaslima]

Is there a way to print the reference count from C++? On 17 Jun 2019, at 16:47, Matthias Köfferlein <notifications@github.com<mailto:notifications@github.com>> wrote: Thanks for reporting this. It's kind of weird. Apparently I don't understand precisely what the list comprehension does with the reference count of Python objects. A simple print("anything") is sufficient to spoil the reference to the Shape objects. The expanded form works well: shapes = [] for opath in get_selection(): shapes.append(opath.shape) I wonder what's the difference between this form and [ opath.shape for opath in get_selection() ]. That's going to be some awful debugging ... Matthias — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#278?email_source=notifications&email_token=AAIJZE2MAO4WIW46N2DPEBLP27Z5BA5CNFSM4HYRABWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX4M2ZA#issuecomment-502844772>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAIJZE4B42SWLLNM662TNRDP27Z5BANCNFSM4HYRABWA>.

[klayoutmatthias]

OK, wasn't that difficult :)

[klayoutmatthias]

@thomaslima It wasn't the reference count in fact (if you use Python from debug build it will track the counts). The issue was actually that the Shape object from ObjectInstPath#shape wasn't passed as copy but as pointer (the Python function generator by default treats const db::Shape & with copy semantics and db::Shape & as reference-to-member which bears the risk of lost references). In this case, this wasn't intended and is easy to fix by picking the right overload.

[thomaslima]

I guess we can release a new version in pypi with this fix... On 17 Jun 2019, at 17:55, Matthias Köfferlein <notifications@github.com<mailto:notifications@github.com>> wrote: @thomaslima<https://github.com/thomaslima> It wasn't the reference count in fact (if you use Python from debug build it will track the counts). The issue was actually that the Shape object from ObjectInstPath#shape wasn't passed as copy but as pointer (the Python function generator by default treats const db::Shape & with copy semantics and db::Shape & as reference-to-member which bears the risk of lost references). In this case, this wasn't intended and is easy to fix by picking the right overload. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#278?email_source=notifications&email_token=AAIJZE6RP7ERN2UYX2QTPALP3AB2LA5CNFSM4HYRABWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODX4R5UA#issuecomment-502865616>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAIJZE4DFTSRLO223NAD4YTP3AB2LANCNFSM4HYRABWA>.