[Bf-committers] Blender 2.5 Python API Introduction.
ideasman42 at gmail.com
Sat Jan 23 20:49:09 CET 2010
+1 for operators adopting dot syntax (idnames not C functions ofcourse).
If anyone didnt follow - this would mean naming all operators
identifiers "OBJECT_OT_select_all" into "object.select_all" in C.
This should also be done for panels and menus too.
On Sat, Jan 23, 2010 at 8:14 PM, Elia Sarti <vekoon at gmail.com> wrote:
> Hi, now that introductory tutorials and howto's-like documentation is
> starting to be written down I'd suggest we bring up again the topic of
> naming. I understand this could be seen as topic hijacking, but well...I
> have a bomb!
> Although pretty much settled all over the API there are still some
> places which are inconsistent in regards to naming. Maybe you remember
> we already talked about this in IRC.
> The main issue is all that BLABLA_BLA_somestuff naming style that
> although perfectly reasonable C side where you don't have namespaces or
> packages or anything like that, doesn't really fit in Py code,
> especially considering that some parts, like for instance operators, are
> already converted to the dot naming syntax.
> The very easy solution for this, considering that all these names are
> actually stored as C strings so can be anything really, is that we adopt
> dot-syntax for all of these in all places and keep the
> BLABLA_BLA_somestuff syntax only for C code names. This would keep the
> code from having to convert back and forth between Py naming and C
> naming and would also be easy to implement and could be done quickly for
> ops, panels, headers, etc.
> Of course I don't mean this as an unilateral absolute truth so any valid
> counter-argument is well accepted.
> Campbell Barton wrote, on 01/23/2010 06:52 PM:
>> Last meeting I agreed to work on some python introduction page since
>> the API reference. here is a first pass.
>> Id appreciate if people want to read through and make edits or suggest
>> areas to improve.
>> I made this page as a wiki so others could edit however Id like to
>> include it here eventually.
>> The section on integration and types could become a lot bigger however
>> it might also mean adding details on subclassing which wasn't my
>> intention for this doc.
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers