[Bf-committers] Bf-committers Digest, Vol 53, Issue 8

[joe]

Py3 would break scripts, yes.  Switching to lua probably would not be an
option, though it might be possible to add support for it later depending on
how things go.

Joe

On Fri, Dec 5, 2008 at 10:30 AM, Bob Holcomb <bholcomb at mak.com> wrote:

> If going to python 3 is going to break scripts, and that's ok, would
> switching to lua be a consideration?
>
> Cheers,
>
> Bob
>
> --
> Sent from my mobile device
>
> On Dec 5, 2008, at 12:09 PM, bf-committers-request at blender.org wrote:
>
> > Send Bf-committers mailing list submissions to
> >    bf-committers at blender.org
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> >    http://lists.blender.org/mailman/listinfo/bf-committers
> > or, via email, send a message with subject or body 'help' to
> >    bf-committers-request at blender.org
> >
> > You can reach the person managing the list at
> >    bf-committers-owner at blender.org
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Bf-committers digest..."
> >
> >
> > Today's Topics:
> >
> >   1. Re: Bundle Python 3.0 for Blender 2.5 (Roland Hess)
> >   2. Re: Bundle Python 3.0 for Blender 2.5 (Campbell Barton)
> >   3. Re: Bundle Python 3.0 for Blender 2.5 (Campbell Barton)
> >   4. Re: Bundle Python 3.0 for Blender 2.5 (Brecht Van Lommel)
> >   5. Re: Bundle Python 3.0 for Blender 2.5 (Martin Poirier)
> >   6. Re: Bundle Python 3.0 for Blender 2.5 (Timothy Baldridge)
> >   7. Re: Bundle Python 3.0 for Blender 2.5 (Chris Want)
> >   8. Re: Bundle Python 3.0 for Blender 2.5 (Ken Hughes)
> >   9. Re: Bundle Python 3.0 for Blender 2.5 (Timothy Baldridge)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Fri, 05 Dec 2008 07:46:49 -0500
> > From: Roland Hess <rolandh at reed-witting.com>
> > Subject: Re: [Bf-committers] Bundle Python 3.0 for Blender 2.5
> > To: bf-committers at blender.org
> > Message-ID: <493922B9.9030007 at reed-witting.com>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Would the current python stick around as well for backward
> > compatibility? I'd read that Py 3.0 wasn't backward compatible in a
> > number of ways:
> >
> > http://docs.python.org/dev/3.0/whatsnew/3.0.html
> >
> > There is a converter available for that takes care of things like the
> > "print" statement, but I think changes like the ones noted in that doc
> > would break almost every existing script. While that's not a problem
> > for
> > me personally, that would be a serious frustration for people who
> > search
> > for a script, find it and have it not work. Not saying Blender 2.5
> > shouldn't go with Python 3.0, just that I'm surprised this wasn't
> > noted
> > on the "Cons" part of the proposal. This is a significant change, much
> > more than Py2.3->Py2.4->Py2.5.
> >
> > --
> > Roland Hess
> > harkyman
> >
> >
> >
> > ------------------------------
> >
> > Message: 2
> > Date: Sat, 6 Dec 2008 00:41:20 +1100
> > From: "Campbell Barton" <ideasman42 at gmail.com>
> > Subject: Re: [Bf-committers] Bundle Python 3.0 for Blender 2.5
> > To: "bf-blender developers" <bf-committers at blender.org>
> > Message-ID:
> >    <7c1ab96d0812050541u4f3bdc26m3053873848170fb0 at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > On Fri, Dec 5, 2008 at 11:46 PM, Roland Hess <rolandh at reed-
> > witting.com> wrote:
> >> Would the current python stick around as well for backward
> >> compatibility? I'd read that Py 3.0 wasn't backward compatible in a
> >> number of ways:
> >>
> >> http://docs.python.org/dev/3.0/whatsnew/3.0.html
> >>
> >> There is a converter available for that takes care of things like the
> >> "print" statement, but I think changes like the ones noted in that
> >> doc
> >> would break almost every existing script. While that's not a
> >> problem for
> >> me personally, that would be a serious frustration for people who
> >> search
> >> for a script, find it and have it not work. Not saying Blender 2.5
> >> shouldn't go with Python 3.0, just that I'm surprised this wasn't
> >> noted
> >> on the "Cons" part of the proposal. This is a significant change,
> >> much
> >> more than Py2.3->Py2.4->Py2.5.
> >>
> >> --
> >> Roland Hess
> >> harkyman
> >>
> >> _______________________________________________
> >> Bf-committers mailing list
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> >
> > Its highly likely many/most? scripts will need to be modified to run
> > in Blender2.5 - so having to do edits for py3 is minimal effort if
> > your already updating your script for a new/modified api.
> > It is a con, but comparatively not a huge one IMHO. especially if you
> > consider we will move to py3 at some point anyway.
> >
> > The proposals are in 2 parts, I only had pros/cons for including
> > python with blender.
> >
> > I cross posted on blenderartist, where some scripters have replied.
> > http://blenderartists.org/forum/showthread.php?t=142544
> >
> > --
> > - Campbell
> >
> >
> > ------------------------------
> >
> > Message: 3
> > Date: Sat, 6 Dec 2008 01:12:50 +1100
> > From: "Campbell Barton" <ideasman42 at gmail.com>
> > Subject: Re: [Bf-committers] Bundle Python 3.0 for Blender 2.5
> > To: "bf-blender developers" <bf-committers at blender.org>
> > Message-ID:
> >    <7c1ab96d0812050612r2b4a7eaaw3c598e7672e18dce at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > To clarify...
> > Including python with blender wont exclude system python modules
> > (PyGame/Numpy/PIL etc), Its just those modules will need to be built
> > with the same python as blender is. so blender can load them.
> >
> > Basically - Do what we are doing on win32 on other OS's, and include
> > more modules so scripts dont complain for a full python install.
> >
> >
> > ------------------------------
> >
> > Message: 4
> > Date: Fri, 05 Dec 2008 15:51:46 +0100
> > From: Brecht Van Lommel <brecht at blender.org>
> > Subject: Re: [Bf-committers] Bundle Python 3.0 for Blender 2.5
> > To: bf-blender developers <bf-committers at blender.org>
> > Message-ID: <49394002.30802 at blender.org>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Hi,
> >
> >> Campbell Barton wrote:
> >>> Hey All, this proposal covers 2 topics
> >>> * Distribute Blender with python on all OS's (I'd suggest this
> >>> irrespective of py version used)
> >>> * Move to Python 3.0 for blender 2.5 (relies on a bundling python)
> >
> > I think some sort of painful transition is inevitable. Python 3.0 will
> > inevitably break most scripts, just grep for "print" in
> > release/scripts and see how often it is used, and there are many more
> > incompatibilities, external scripts are probably no different.
> >
> > On the other hand 2.5 is going to break the Draw module. For example
> > Draw.PupMenu is blocking, but this is not allowed in 2.50. Again more
> > than half of the scripts in release/scripts use that, so they will
> > break even if we try to preserve the 2.4x api.
> >
> > I think we might as well get it over with in one go.
> >
> > Further, I do not really understand the objection to bundling python
> > with Blender. If Blender is compiled with the same version as is
> > installed on the operating system, external modules using that version
> > will still be available.
> >
> > If you are distributing a script with external modules you can
> > distribute them with the script even and it's easier because you know
> > the python version Blender uses. If this is for some custom script for
> > your own purposes I'm sure you are capable of compiling either Blender
> > or the external module so they use the same python version, if the
> > version is not the same already. Right now even, chances are there is
> > no Blender release with the python version you are using.
> >
> > So, basically I agree with Campbell in that we should bundle 2.5 with
> > python 3.0, I don't see what would be the better alternative that is
> > feasible, as I don't think having two python versions compiled into
> > Blender is a practical possibility.
> >
> > Brecht.
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 5
> > Date: Fri, 5 Dec 2008 07:49:44 -0800 (PST)
> > From: Martin Poirier <theeth at yahoo.com>
> > Subject: Re: [Bf-committers] Bundle Python 3.0 for Blender 2.5
> > To: bf-blender developers <bf-committers at blender.org>
> > Message-ID: <289590.76304.qm at web51303.mail.re2.yahoo.com>
> > Content-Type: text/plain; charset=us-ascii
> >
> >
> >
> >
> > --- On Fri, 12/5/08, Campbell Barton <ideasman42 at gmail.com> wrote:
> >
> >> Its highly likely many/most? scripts will need to be
> >> modified to run
> >> in Blender2.5 - so having to do edits for py3 is minimal
> >> effort if
> >> your already updating your script for a new/modified api.
> >> It is a con, but comparatively not a huge one IMHO.
> >> especially if you
> >> consider we will move to py3 at some point anyway.
> >
> > True, but I really don't think that point should be now (as in this
> > very moment). For one thing, Py3K is just out of the door, as you
> > said yourself in the BA thread, the first version of a rewrite is
> > often not the most stable. ;)
> >
> > 2.50 is not going to be released any time soon and you said
> > switching to Py3K means very little changes internally, so no need
> > to rush that decision (at least not until the design of the API is
> > fixed)
> >
> > Regarding bundling, going over the *pro* list:
> >
> > * We can include modules bundled scripts use so that users are not
> > faced with error messages when they try a python tool.
> >
> > I guess that's a fix for users not reading the download page
> > properly? (or the page not being precise enough about external
> > dependency on Python)
> >
> > If it's a problem with bundled script not having correct failsafe,
> > then that's different altogether.
> >
> > * No need to distribute blender for versions py 2.3, 2.4, 2.5, 2.6....
> > and later 3.0 - We already are having to do both 32 and 64bit Blender
> > builds. Many users wont know what python version is installed on
> > their system.
> >
> > We currently only have builds with 2.4 and 2.5 on the download page
> > (or py 2.3 for os X, but they don't have 2.4 builds), so I don't
> > quite see where you got your list. Moreover, if we decide to move to
> > 3K, there's no way in hell that we'll be maintaining two sets of
> > bundled script for backward compatibilities, so we can drop all 2.X
> > versions then.
> >
> > Heck, we could stick to a single version too, regardless of bundling.
> >
> > * A reliable python means we can use it for more important aspects
> > of Blender 2.5 (something Ton has suggested)
> >
> > That, IMHO, should be the biggest argument.
> >
> > * No conflicts with the system python - there have been bug reports
> > where the system python was crashing blender.
> >
> > The one I remember (there might have been others mind you) was
> > caused by a faulty compile (of Python or Blender, it wasn't clear)
> > and couldn't be reproduced on other systems using the same distro.
> >
> > * Blender already includes FFMpeg and some other significant libs on
> > most OS's
> >
> > Comparing to ffmpeg is a bit loaded, their API is about as stable as
> > a pile of rumble and they don't have released versions we can
> > reliably link against (or did they finally bit that bullet?)
> >
> > * Openoffice and some games include python, searched for python
> > problems with these apps and didnt find complaints, common with
> > Blender.
> >
> > If you were thinking of EVE, they include Stackless Python, hardly
> > comparable (moreover, we already bundle on windows).
> >
> > The most frequent "complain" about Blender's Python is the site-
> > package missing warning, if they disable import of external package,
> > of course they wouldn't see that.
> >
> > I have a couple of technical questions though. By bundling the
> > interpreter and some libs but still leaving the possibility of
> > importing external libs, won't this also leave us open to the same
> > site-package incompatibilities/missing warning message that we
> > currently have and that you seem to identify as "the big problem
> > with not bundling python"? I mean, we already bundle Python on
> > windows and most of the reports are on that OS, so how is that a fix?
> >
> > I find the long list of BA threads somewhat disingenuous (have you
> > even read them before posting?) as lots of them wouldn't be fixed
> > with bundling Python (permission problem on Vista, wrong libc
> > version, how to run multiple versions of blender, exception in a
> > script at runtime, ...), but I digress.
> >
> > Martin
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > Message: 6
> > Date: Fri, 5 Dec 2008 09:59:07 -0600
> > From: "Timothy Baldridge" <tbaldridge at gmail.com>
> > Subject: Re: [Bf-committers] Bundle Python 3.0 for Blender 2.5
> > To: "bf-blender developers" <bf-committers at blender.org>
> > Message-ID:
> >    <b33fdb110812050759w590ecf1p981d5bda737ed7a6 at mail.gmail.com>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> >> * Openoffice and some games include python, searched for python
> >> problems with these apps and didnt find complaints, common with
> >> Blender.
> >
> > True, but the installs for most of these games stay constant, you're
> > not removing and adding modules on a regular basis. If we do bundle
> > Pythonr we should always check for a system Python first, as auto
> > installers won't know about the Blender Python. Or perhaps we've
> > solved this issue already?
> >
> > If a user installs numpy into the system directory, does Blender see
> > it?
> >
> >
> > ------------------------------
> >
> > Message: 7
> > Date: Fri, 05 Dec 2008 09:25:10 -0700
> > From: Chris Want <cwant at ualberta.ca>
> > Subject: Re: [Bf-committers] Bundle Python 3.0 for Blender 2.5
> > To: bf-blender developers <bf-committers at blender.org>
> > Message-ID: <493955E6.5020706 at ualberta.ca>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> >
> > Reading this thread, I become more agreeable to the suggestion
> > that Early Ehlinger made earlier (no pun intended). He suggested
> > that python scripting should be handled as an external plugin
> > that loads at run time. Then the problem of having builds of
> > blender for different python versions doesn't matter: just
> > have one blender build and distribute it with plugins for
> > the different python versions. This, of course, would be a
> > lot easier with a well thought out C API, which I believe should
> > be the first step before tackling python (as I've mentioned
> > before).
> >
> > I should also point out that bundling python with blender adds
> > extra complexity to Blender's plethora of build systems. The
> > example of FFMPEG is a poor one since not all build
> > systems support it, there are issues under windowa, the
> > scons system supports it by having the additional
> > requirement of having autoconf installed, and I have
> > recently seen mails on the list from our game engine developer
> > trying to change the FFMPEG sources in extern, to which
> > there are no replies from the official maintainer. This is
> > not a role model to follow.
> >
> > Cheers,
> > Chris
> >
> >
> > ------------------------------
> >
> > Message: 8
> > Date: Fri, 05 Dec 2008 08:46:38 -0800
> > From: Ken Hughes <khughes at pacific.edu>
> > Subject: Re: [Bf-committers] Bundle Python 3.0 for Blender 2.5
> > To: bf-blender developers <bf-committers at blender.org>
> > Message-ID: <49395AEE.2090608 at pacific.edu>
> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> > Martin Poirier wrote:
> >> 2.50 is not going to be released any time soon and you said
> >> switching to Py3K means very little changes internally, so no need
> >> to rush that decision (at least not until the design of the API is
> >> fixed)
> >>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20081205/bdb805a4/attachment-0001.htm