Trying to overcome some basic blender python understanding hurdles

I initially tagged this on the end of someone elses thread and then realised that it was potentially hijacking so I have placed this here in it’s own instead…

Firstly for anyone who is a python beginner like me…

‘screens’ is referring to the screen layouts that can be selected on the top header bar, usually this boots up with ‘Default’, i’ve switched to ‘scripting’ which makes it number 4 in the list. Hence the number 4 below.

The ‘areas’ is referring to the various window panels that are shown, the 3d view happens to be the 3rd along so is 2 in the list, i.e. [0, 1, 2]

That means the following line can be written in the console so long as you’re in the scripting scene layout and be able to switch the shading mode to wireframe in the 3dview…

bpy.data.screens[4].areas[2].spaces.active.viewport_shade=‘WIREFRAME’

However in the blender python api searching for the ‘viewport_shade’ function shows the location as -
class
bpy.types.SpaceView3D(Space)

What does the word ‘space’ represent in the brackets? I was expecting you could go something like…
bpy.types.SpaceView3D(Something here?).viewport_shade=‘WhateverOptionYouLike’.

Can anyone shed some light on this?

Also what are ‘screens’ or ‘areas’? I mean are they classes? Which contain lists? Hence the square brackets? I’m floundering here obviously. It’s tricky to translate what i’ve learned about python into practical examples for blender i must admit.

I’m intending to rewrite all this up for people like me so hopefully this will help many others to crack into blender python with these sorts of examples. (In addition to the other practical resources like blendercookie of course)

Sorry for the obviously beginner-like question and long ramble that this has turned into, many thanks for reading this far if you made it! :slight_smile:

Thanks again,
Aidy.

It’s like you were writing it as a python class definition, class ClassName(ParentClass):

In general (or always, take your pick) you can’t use bpy.types directly since they aren’t instances of the class.

Also what are ‘screens’ or ‘areas’? I mean are they classes? Which contain lists? Hence the square brackets? I’m floundering here obviously. It’s tricky to translate what i’ve learned about python into practical examples for blender i must admit.

Screens are the layout which contain different Areas (3dview, outliner, etc…) which contain Regions (property pane, tool pane, headers, etc…) – hopefully, just going by memory here.

Kind of like the DOM in html I suppose.

Accessing these areas through bpy.data.screens[x].areas[x] is tricky and you shouldn’t really rely on that since people can set up their screens any way they want, best to use a context sensitive operator since the active screen/area is quite easy to get at that way.

Your best bet is either to use dir(class) or ctrl+space (for the lazy) in the console to figure out the different properties contained on objects. Also type(class) helps out to figure out what section of the docs you need to be looking at.

AHA!

Many thanks Uncle Entity! That is definitely making things clearer.

That dir(class) advice is a great one by the way, i had totally forgotten that that was possible, it’s that sort of mental slippage that has me in the kind of fog i’m laying out here i guess, which is happily starting to lift!

And the type(class) answers some of my other confusions! Screen and areas are indeed classes! Although not lists despite the square brackets, or perhaps a class can be a list? Hmm, i’m starting to drift back into the fog perhaps!

I’m still a little unclear on how when searching in the blender python api for the ‘viewport_shade’ function it shows the location as -
bpy.types.SpaceView3D.viewport_shade

and how i would then turn that to information i could use.

In the sense that location doesn’t seem to work if you search for it in the console, in fact it is located in the following location, shouldn’t the api include that location as well or instead? …

bpy.data.screens[x].areas[x].spaces.active.RightHere!

Incidentally i’ve just found out that using

bpy.app.debug =True

will show a lot more handy hints as to where things are but unfortunately still doesn’t seem to give me anything i can make legible with the viewport shade changes for example.

Do you have any ideas?

Many thanks!
Aidy.