Closed philipstarkey closed 6 years ago
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Ah, I see.
My "loader" object didn't implement the entire Python 3 spec for loader objects, but the Python docs assured me that that the Python 2 spec would be sufficient. Looks like this isn't the case for running modules as main using the -m
flag in Python 3. Should be fixed by pull request #38.
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Merged in cbillington/labscript_utils/bugfix (pull request #38)
Fix issue #16
Approved-by: Jan Werkmann jan.wrk.fb@gmail.com
→ \<\<cset a69040a02cbb46a4a6d7307399f1b16cd9237ce3>>
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Fix issue #16 by inheriting from the default Loader object.
→ \<\<cset 18cc52505e9998a47dc9fb5dd3db1a7f2d84d9c4>>
Original comment by Chris Billington (Bitbucket: cbillington, GitHub: chrisjbillington).
Merged in cbillington/labscript_utils/bugfix (pull request #38)
Fix issue #16
Approved-by: Jan Werkmann jan.wrk.fb@gmail.com
→ \<\<cset a69040a02cbb46a4a6d7307399f1b16cd9237ce3>>
Original report (archived issue) by Jan Werkmann (Bitbucket: PhyNerd, GitHub: PhyNerd).
In modules where labscrupt_utils is imported the command
python -m module_name_here
leads to a exception:I did a bit of debugging and it seems to be caused by loader being of type <labscript_utils.double_import_denier.Loader object at 0x10e910438>. So we should maybe fix that for python 3 compat. Fun fact
python filepath_to_module
still works.