[Bf-python] Adding help info to scripts (alternative proposal)

[Willian Padovani Germano]

Hi,

Fair, Stani

After reading your msg a few hours ago I took the script and changed it 
to follow your suggestions instead of the original format.  Ok, first I 
sighed for a second for having to recode the thing, but hey, you are 
right :) (And Tony was too, but back then, from looking at the suggested 
asyncore.py code, I thought the format proposed was to use pure 
"""...""" blocks, this with vars works better).

So now the expected format is with vars: __author__, __email__, __url__, 
__version__.  For now either __bpydoc__ or, if it's not available, 
__doc__ can contain the help information itself.  Later I can improve to 
alternatively show pure """...""" blocks if the vars are not available.

Only thing kept is the *optional* <br> tag to force line breaks, since 
line widths depend on window width in the script's gui.

I won't send the new version to the list, but after testing more I'll 
put it at the scripts cvs, where I'll update scripts to follow it.

LarstiQ:

>Willian, are there any technical or other reasons not to go the python
>route?
>  
>
No, and I say that from experience :).

>(having a pythonic api is something much larger, not sure how to tackle
>that, but Theo de Ridder might have something to say about that)
>  
>
Without breaking compatibility, the newer (than bpy's api) get/set way 
in Python can be implemented along with the current methods.

I took a look (while writing Radio module) at the possibility of 
changing the current C functions to adapt to it (so we wouldn't have to 
duplicate code), but from what I remember it wouldn't be possible, don't 
recall details now, but we'd lose the .get*/.set* methods (ex: 
camera.setLens, etc) if the C functions got changed.

For those newer here, keeping compatibility was a key point when Michel 
Selten started the project to rewrite the 2.25 bpython api in pure C.  
It was the third or so api in Blender in a couple of years and script 
writers were tired of having to update their scripts, of course.

Should a new api come before a new Blender (2.5? 3.0?) is something to 
be discussed with the whole community carefully.  Lots of work involved, 
for sure (though a new Blender could be written from start to get along 
well with boost or another tool to generate python/etc wrappings 
"automatically").

-- 
Willian