Python - understanding types of returned values


I would appriciate some advise on understanding returned values from Python expressions in Dynamo.

I’m fairly new to Dyanmo and I think part of the issues I have is that I’m not understanding the difference between some values.

So to give an example:

locations = doc.ProjectLocations

Returns: Autodesk.Revit.DB.ProjectLocation


locations = doc.ActiveProjectLocation

Returns: ProjectLocation 1218

So whats the difference between these two results? And why is one of returned instead of the other?

I think the second one is an actual object in the Revit database (hence the ID at the end), but the is not the first one the same thing?


Hi Kevin,

this isn’t necessarily a quick and easy answer. Do you have access to the Revit API help file, Revit 2017.1 API.chm? (Name depends on what version of the SDK you’ve downloaded). This tends to have pretty good explanations about the way Revit works internally; its structures aren’t always the most intuitive (at least to me, but I’m no software engineer!).

For instance the ProjectLocation Class has a remark:

“Revit Architecture projects can have named locations. A named location is the position of a model instance in a Revit Architecture project. By default, each Revit Architecture project contains at least one named location, called Internal. Existing ProjectLocation objects can be found by using the ProjectLocations property on the Document object. New project locations can be created by duplicating an existing project location using the Duplicate method, and modifying the location’s project position.”

ActiveProjectLocation is a property of the Document class, because it relates to the geographical settings of the project file (document) Dynamo attached itself when you opened it.

Hi @Kevin.Bell

Didn’t this was answered before on this thread.

1 Like

I guess my question was more about understanding the types of returned data as opposed to the actual ProjectLocation class.

i.e., the difference between as result returned as:


as opposed to:

something 1234

I think the difference is that the first one is a class that has been returned, whereas the second one is an actual element within the database.

So to work out what Methods and Properites apply to each of the returned values (using the ProjectLocation as an example), I ran dir() on each thinking I could match whats returned to the info in the API help:


Even though doc.ProjectLocations returns Autodesk.Revit.DB.ProjectLocation, looking at the ProjectLocation class in the API help none of the Methods / Properties returned match those listed in dir().

Where as, doc.ActiveProjectLocation that returns ProjectLocation 1234 some of the Methods / Properties returned do match those listed in the API help document, so I assume that I’m looking at the correct help information.

So, in a nut shell, I’m trying to understand where to look when I get a returned value from Dynamo, I expected to simply look up the class and see a list of what can be done, but I’m now often coming across data which is not what I expect.

I hope I’m making sense!


Hi Kevin,

If you look at the API documentation you will see that doc.ProjectLocations returns a ‘ProjectLocationSet’ (so a collection of all the projectlocations in the model).
The doc.ActivePojectLocation returns a single ‘ProjectLocation’ (which is also included in the above ProjectLocationSet).

Ah yes, I see.

Whats confusing me is that Dynamo / Revit calls it:


Whereas, like you say, its a:


So why does it not state that its a Set, then I could refer to the correct class - or am I missing something?

Thanks for your help.

Well actualy if you use .GetType() method then it does return that:

Why Dynamo does not return this I don’t know, but I’ve noticed the same behaviour with ConnectorSets, where Dynamo just returns ‘Connector’ instead of ‘ConnectorSet’. Maybe it has something to do with the fact that Dynamo only recognizes lists as data structure? LocationSets seem to be an implementation of IEnumerable.


Well GetType() is a useful thing to know nonetheless, thank!

1 Like