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

[www.stani.be]

Hi Willian,
Thanks a lot! I'm really happy you accepted the
proposal.  If there are any other pythonic related
issues, don't bother to ask me.
Stani

http://spe.pycs.net
http://www.stani.be

--- Willian Padovani Germano <wgermano at ig.com.br>
wrote:

> 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
> 
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
>
http://projects.blender.org/mailman/listinfo/bf-python
> 



		
__________________________________ 
Do you Yahoo!? 
Check out the new Yahoo! Front Page. 
www.yahoo.com