[Bf-python] Proposed BPyAPI Additions.

Joel Leineweber jleineweber at gmail.com
Fri Dec 8 02:20:24 CET 2006


Just in case it matters, it seems the bug in the object module causing a
crash only happens when the object being created is a curve. I should've
mentioned that when I submitted the bug report.

hope that helps,
bydesign


On 12/7/06, Martin Poirier <theeth at yahoo.com> wrote:
>
>
> --- Ken Hughes <khughes at pacific.edu> wrote:
>
> > Campbell Barton wrote:
> > > Joe Eagar wrote:
> > >> Campbell Barton wrote:
> > >>> One thing about removing the need for
> > >>> import Blender
> > >>>
> > >>> If your a game engine developer it would not be
> > desirable.
> > >>>
> > >>> Maybe we could have 2 contexts.
> > >>>
> > >>> Alt+P and menu scripts and GE scripts?
> > >> GE scripts are totally separate anyway.  why
> > would they care?  I
> > >> thought we already had two contexts.
> > >>
> > >> Joe
> > > My Bad for this one, looks like it won't adversely
> > effect the GE.
> > > One other thing
> > >  scn.object.new(obdata)
> > >
> > >  - Works fine, however what about empties?
> > >
> > > Was thinking no obdata for empties, just None.
> > > empty=  scn.object.new(None)
> > >
> > > 2 bad points, if any new obkects are added without
> > data like empties, it
> > > would not fit in (Realisticly this probably wont
> > happen)
> > > And if the obdata is intended to be a lamp, mesh
> > etc and somehow gets
> > > set to None, it may be trickyer to debug, then if
> > we
> > > used....scn.object.new(Types.Empty)  - ore some
> > other format.
> >
> > Wanted to poke this thread; now that we're is BCon2.
> >  I just woke up and
> > realized some of this is in the Scene module now but
> > I don't see epydocs
> > for it.  Tom just assigned a nasty bug to me that
> > would best be fixed by
> > encouraging users to not use Object.New(), so it
> > would be nice to
> > document this (the scn.object.new() method) as the
> > "recommended" methods
> > if we're going to keep it.
>
> Add a deprecation warning to Object.New if that's no
> longer wanted and known to be broken.
>
> I really think it's time we start having a policy on
> that sort of thing.
>
> Here's what I propose:
>
> 1- Deprecation warning in methods that will disappear
> 2- At least 6 months after it has been released with
> that warning (at the current rate of thing, that means
> one major release), remove the method from the API.
>
> If we always keep old known to be broken calls, it's
> dangerous for everyone (script users, writers and API
> maintainers).
>
> Martin
>
>
>
>
>
> ____________________________________________________________________________________
> Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it
> now.
> _______________________________________________
> Bf-python mailing list
> Bf-python at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-python/attachments/20061207/c0711f96/attachment.html>


More information about the Bf-python mailing list