Expected Ienumerable[curve], got list

It’s a bit case dependent, so if you can provide a (non-)working file that’d help. More generally, have a look at these articles:


There are definitely parts of RhinoCommon that are bit iffy to implement in IronPython if one doesn’t understand C#. Which perhaps could have been designed/documented to better accommodate IronPython users.

Is there realistically anything that could be done to improve that? Is it locked in, or maybe will it improve with the CPython using Python v3+ in v8 ?

As I recall, anyone can suggest/make pull requests to the RhinoCommon and Rhino Python documentation pages. But you’d have to ask e.g. @stevebaer, @eirannejad or @piac.

Specific to this subject, that probably depends quite a bit on how Python.NET handles overloads (edit: there’s a section on Overloaded and Generic Methods in the link). As I recall, again, that is the technology being implemented to interface CPython with RhinoCommon/.NET in Rhino 8.

I did a little bit more digging, and I do see some other methods.

where z and u are curve objects (done in ghpython):

crvlist = [y,z]
crvenum = Rhino.Collections.CurveList()
for i in crvlist:

#serves up an Ienumerable-ish object
myenum = Rhino.Collections.CurveList.GetEnumerator(crvenum)

myarray = crvenum.ToArray()

print type(crvenum)
print type(myenum)
print type(myarray)

But actually this only gave me the <type ‘CurveList’> and <type ‘Enumerator’>. And type Array[Curve]

I still feel quite strongly that this is a big ‘gotcha’ in learning python and applying it to the manipulation of the Rhinocommon namespace. I think it definitely deserves a mention on Rhino Python guides documentation in that intermediate level area. @stevebaer / @dale

I’m hoping we can improve this through how we present tips in the new editor being worked on for v8.

1 Like

Without any knowledge of .Net, in particular C#, using IronPython is always a challenge. It’s incredible complex to consider this in a documentation.

Because it’s not only about how you can call this functionality using Python syntax, but it’s also about to explain why this language feature need to exist. In a statically typed language like C# you need interfaces (e.g. an IConfusable) to write methods and classes without the need hard-code or tightly-couple to a specific datatype. Instead, you design by contract, meaning you say give whatever you like, as long this object implements this interface owning some methods, properties etc. This is (almost) redundant in Python, because dynamic typed languages are not declaring types at all.
But it’s not just about interfaces, but also about how to call some advanced language features, like delegates, finalizers, iterators or some specific keywords like volatile.

Essentially, the one misconception about IronPython is, that just because it’s Python syntax, it’s an easy to handle language. I would argue that because of this issue and some others, it is one of the harder languages to master!


I feel like the simplest way could’ve been that for some of those object types that don’t ‘play nicely’ with iron python, there could be a python sample as there are in other places. Or just one section in the guides web pages for handling these few anomalies that do exist.

Not to sound like I’m being difficult or a bit dumb, but I do have to search the forums every time I come up against these kind of objects, the syntax isn’t something very memorable.

1 Like

Not that I’m totally against that, but that’s something you need to do anyway. Just if you encounter something syntactically weird, look for Iron Python (not CPython) explanations or try to get at least a basic understanding of C#, for being able to read the MSDN documentation.

If you want to know what the IEnumerable interface is, then you have to look at MSDN page or ask in the Microsoft forums. Essentially, writing good documentation is difficult, but it’s not the task of McNeel or any other Software company to explain you Microsoft code or explaining how a programming language works.

Apart from the fact that this might be a total overkill, any extra noise in an interface documentation, might annoy the more advanced software developer for extracting the essential information. There is definitely also a problem with inflationary and redundant documentation, just as with having no or hardly any.

Yeah that’s true to be fair, I can’t disagree with you there.

When I referred to documentation, I meant merely an article additional to the below :slight_smile:


Well … IMO if a software house decides to use some complicated technology for user scripts, then it’s somehow its task to explain something about those intricacies to users. :slight_smile:

1 Like

Which they do very generously already. Look at all the example files that have been provided and all the immediate help you get when running into these issues.
Beside that, McNeel offers not just one way of scripting, you can use anything from basic to advanced.

1 Like

Yeah, maybe my last post was not on point to what I was trying to say. I’m not saying McNeel shouldn’t generously explain how to handle some things (as they already do), I’m just trying to say that this is more difficult to do than someone would expect and that this becomes incredible complex.

Because, it really depends on the programming skills of the reader!

Again, a C# interface is something a pure Python developer might not understand, because it’s something you don’t really need in that language. But is the documentation about explaining Rhinocommon, or about C# interfaces, or even teach programming? Is it really necessary to explain to the audience e.g. about classes, just that the user is able to utilize them from Rhinocommon?

Since, I’m teaching people inside my company on how to code, I know that very basic concepts are often hard to understand. It’s very often that people quickly claim this being the fault of bad documentation, bad teachings or utilizing bad technology. But the actual reason is, that they failed to ask the right questions.

Of course, IronPython is a controversial technology because of this conceptional mix. But it solved the problem for McNeel to expose Python scripting to the audience, while utilizing the .Net ecosystem.
Maybe it would be easier to write a second Rhinocommon for CPython, and I believe McNeel actually works on something like this…


While I completely agree, the topic in question regarding the C# data types and their use down the line in a script to be manipulated don’t appear in any method samples, if I’m not mistaken. This does add to their mystique, bringing oneself to the forum to find out how you handle it in your python routine.

However, I appreciate it would not feasible to expect a python snippet/sample which applies every single method or property that returns one of these data types :slight_smile:

1 Like

Yes :slight_smile:
That is what I meant … but did not explain clearly due to my poor English etc. :blush:
I’ll try to write that down anyway … :neutral_face:

Using something like IronPython for your software’s scripts has its drawbacks.
Exactly because people writing those scripts will not usually be professional programmers, or even programming enthusiasts.

I think that would have been the right thing to do, if you plan to use Python …
But I also know that McNeel if often short on time, and RhinoCommon is a pretty large library. :wink:

Maybe adding a few non-overloaded methods to RhinoCommon would have helped people to write Python scripts more easily. … And possibly also something to clealry translate between C# and Python data types.

BTW … I don’t have Rhino 8 WIP, but if I understand it correctly the new CPython API will again be a (different) software tool to be able to use (C#) RhinoCommon classes in Python.

A little ‘tuning’ to RhinoCommon to help Python users would maybe still make sense IMO … :wink:

Thanks for replying ! :slight_smile:

Guilty :raised_hand:t2: :blush:


Hehe …
So am I, BTW … :grinning: