Check this out:
for node in Glyphs.font.selectedLayers[0].paths[0].nodes:
print node
Does it have a reason, that the first node is not exactly the one which is marked as starting point? I am working on a SVG export script and this behaviour is just mind bending while trying to write the bezierPath-to-svgPath translator.
Wouldn’t it be logical to start the iteration at the ”Make Node First« node? Am I missing something?
The first node is the one before the first segment.
Not here (or i don’t understand what you mean by that). Please see the images. I highlighted the First node that the loop spits out. It is contradictory to what the triangle marks.
The first segment is the line or curve that leads to the first on curve point. But it has to come from somewhere. I pick the approach to go back to the previous node as the first moveTo operation on the path. In most cases the “Start Node” (maybe the name is better then first node) is mostly the last on the list. Otherwise, if I draw the path, at the end, I would need to check it the first is an offcurve node and draw that segment.
So either find the start node as the last oncurve node in the list and then just draw the list of all nodes. The second approach to find the first oncurve node, draw all following nodes and then if there is a curve segment at the beginning (because we skipped it in the beginning). You could always order the nodes that it always starts with an oncurve node. But that would put the nodes of that curve segment at two different places on the path and I don’t like that.
Thank you very much, Georg. Very interesting. This is pretty comprehensible, I’ll give it a shot. Good to know the logic behind it, and that it is all on purpose. Understanding the structure definitely helps to make the parser work. 
What are you trying to do?
I am iterating over a path and rewrite the path’s nodes as SVG-structure. Kinda like this:
svgPath += " C %.1f, %.1f %.1f, %.1f %.1f, %.1f" % (node.prevNode.prevNode.x, node.prevNode.prevNode.y, node.prevNode.x, node.prevNode.y, node.x, node.y)
Depending on the Node’s type of course. It is already working, but the closing got weird before I knew how Glyphs iterates over the nodes. You’ll tell me that there is a way more easy approach to get an SVG from a Glyph (programmatically)? 
Use a pen. That is much easier.
The RoboFab Pen?
yes. Even through there is a native pen protocol in Glyphs. But is is not yet prepared for usage in python. I’ll have a look.
I’ll give it a try. Thanks.