Trying to convert my personal scripts from Ironpython to Cpython.
In some cases I get an error and cant understand why.
viewTypeCollection = FilteredElementCollector(doc).OfClass(ViewFamilyType) for i in viewTypeCollection: if i.ViewFamily == ViewFamily.ThreeDimensional: viewType = i else: continue
I get an error here when changing to Cpython
if i.ViewFamily == ViewFamily.ThreeDimensional:
ERROR MESSAGE: ViewFamilyType has no attribute ViewFamily
When I look in the API my code seems right, what am I missing here?
I recommend you check to see what options you have available to you on the viewTypes objects.
Comment out the for loop and anything that relies upon it by adding a triple quotation mark before it, and after the last line of code.
Before the new triple quoted string add the line OUT = dir(viewTypes[0]), which will pull the directory of what you can do to a view type. If you see ViewFamily as an option, pull itās documentation by changing the line to OUT = viewTypes[0].ViewFamily.__documentation__ and see if that gives you any indication of what added override requirements may be. You can also check to see if there is a method called something like get_ViewFamily, which would be the CPython converted method to call the results of the ViewFamily property.
I would also check what the Filtered Element Collector is returning as the only difference when getting the ViewFamily attribute between IronPython and CPython is that IP returns a Type and CP returns an integer
This code works for me in both versions of python
viewTypeCollection = FilteredElementCollector(doc).OfClass(ViewFamilyType)
output = []
for vt in viewTypeCollection:
if vt.ViewFamily == ViewFamily.ThreeDimensional:
output.append(vt)
OUT = output
Your code could be cleaner else: continue is implied in the if statement so is unnecessary.
You overwrite viewType so, if there are multiple types, you will get the last one.
Solās original code has a break so it selects the first available 3D view type before further processing
Your first triple wuotestion mark is in the wrong spot. It should be at the start of the line after the first comment at the top of the original screenshot.
I am of the opinion āif it aināt broke, donāt fix itā here. Ask why is there a need to convert from IronPython to CPython. I think the use case comes down to using Python3 libraries like Pandas, Numpy etc.
There are cases where CPython presently does not work such as sub-classing .net interfaces which are used to supress warnings or load families back into Revit. Pythonnet is still version 2.5.2 (use clr.__version__) which is from February 2021
Search for āPython 2 CVEā and you might change your mind. This is software with a large footprint and can be utilized in any environment itās found in perpetuity as there are no new security updates. And so eventually there will be an exploit so severe that it has to go away all at once. This means two things for those of us managing Dynamo content.
Would you want to be the one responsible for not removing this dependency and therefore the root cause of a breach? If not, itās best to migrate faster.
If you arenāt breached but someone else is an then a patch is quickly pushed out, will you be ok with all of your old Python 2 content no longer working, and therefore most of your Python work until you can update each of the associated graphs? If not, itās best to reduce this dependency where you can, even if it means everything but your scripts with iInterface calls.
While we might not think our companyās network or data is worth it to any threat actor, AEC firms are actually targeted at a higher rate than we think. And we can certainly decide to invest in tools to mitigate the risk, exposure, and even paid external support for custom patchesā¦ but you canāt get to ānearly no riskā while it is in use.
One last note: this also impacts packages which are currently IronPython based, and the inevitable migration isnāt something that any of us in the community, the Dynamo team, Autodesk or others can prevent.
urllib says hi!
I understand code needs to be maintained and the biggest pain has been how IronPython3 just flopped about for years - Itās nice to have CPython3 where I have done most of my coding, however having this probably opens up more vulnerabilities <Pillow has entered the chat>
A bit of damned if you do, damned if you donāt
That being said, a maintained code base is better than inactive code base with cobwebs and trapdoors
I donāt know what you are talk about IronPython3, but with me CPython3 make me 10x time to resolve for problem come from user asking about python script, It good for datascience, but with some case intergrate with Revit, It is pain
Hello everyone, I want to start by wishing you a happy new year.
I personally think that everything should evolve and improve, above all, eliminate all possible security risks.
Finding it a pain to convert from Ironpython 2 to Cpython, I think I get strange error messages that I donāt know how to deal with, take the example below that I got this morning.
I have previously developed in VB.NET and never experienced this issue between .NET versions that I experience with Python.
systemerror: RevitServices
When I change to Ironpython 2 everything works as expected
This is caused precisely by the fact that the Cpython3 packages are not loaded from Dynamo startup. The way to solve this is to force the python graph to run.
Alternatively, you can use IronPython3 (available via package manager) of all the python engines available to date in DynamoBIM, to date in my opinion Ipy3 is the best implementation/compatibility with Net FrameWork AND especially NetCore with future versions of DynamoBIM (maybe it can change with PythonNet 3 in future).
Iām glad to hear that you suggest IPY3, then Iāll download it from packages and use that engine insted.
Is there any security issues or something else to keep in mind?
CPYTON is not working for me at all, what ever I do it returns errors even when using IntelliSenses
We can assume that all software is currently unsecure, and if not it will be at some point. The important thing in considering security impact is āwill someone patch a vulnerability when it is foundā. Projects which are no longer maintained (ie: Python 2, AutoCAD 2001, Windows XP, Silverlight, Flash, etc.) wonāt have such patches put in place.
