[Pythonmac-SIG] My stab at a new page

[Bob Ippolito]

On Feb 10, 2006, at 10:02 AM, gandreas at gandreas.com wrote:

>
> On Feb 10, 2006, at 11:27 AM, Bob Ippolito wrote:
>
>>
>> On Feb 10, 2006, at 7:24 AM, gandreas at gandreas.com wrote:
>>
>>>
>>> On Feb 9, 2006, at 1:32 PM, Kevin Walzer wrote:
>>>> If I'm a newbie, I'm going to go, "Huh?", then "shrug," and move
>>>> on to
>>>> Realbasic. There needs to be something double-clickable there for a
>>>> newbie to use. PythonIDE, though it had many flaws, was useful this
>>>> way.
>>>>  BTW, what happened to PyOXIDE? It had major bugs, but was
>>>> promising as
>>>> a "next-generation" basic IDE for Python development on the Mac.
>>>
>>>
>>> PyOXIDE isn't dead - it's just sleeping.
>>>
>>> Seriously, there are several issues:
>>>
>>> 1) Lack of available time
>>> 2) It mostly does everything _I_ need (I actually use it on a fairly
>>> regular basis, and I have no burning need to add new features)
>>> 3) It needs to basically be re-written - it started as an editor  
>>> with
>>> python embedded in it (i.e., use the python.framework and the  
>>> various
>>> python embedding routines).  Unfortunately, with 2.4 and the
>>> corresponding PyObjC, that just plain doesn't work well - PyObjC
>>> pretty much requires the thing to be a PyObjC-based application
>>> ("application embedded in python"), instead of an application
>>> embedding python.
>>
>> That's not true, and I've told you the correct way to fix that...
>> That's why py2app can build plugins.
>
>
> Perhaps "requires" is too strong a word - how about "is easiest to
> use if" instead?
>
> Still, the current architecture of PyOXIDE (links with
> Python.framework, and calls the various PyRun_SimpleString,
> PyRun_SimpleFile and other commands as listed at <http://
> ftp.python.org/doc/ext/embedding.html> via various UI callbacks,
> tries to manage the GIL, etc...) has a high impedance match against
> the way PyObjC works (since it wants to take care of all the details
> for you, made worse when _that_ code does UI work).  My point is that
> the better way is just to make PyOXIDE a py2app based creature from
> the start (and then python code calls the IDE framework), though
> moving all the python code into py2app generated plugins is an
> interesting option (with it's own benefits/drawbacks).

It would work just fine if you were managing all that stuff  
correctly.  PyObjC and py2app definitely manage the GIL correctly  
with the tests and field experience to prove it...

> If it were trivial to fix, I'd have done it already...

I didn't say it was trivial, but it doesn't require a rewrite.  The  
majority of the work would be removing code.

-bob