Open source developers work on whatever they want or need to work on, so the particular problems you have will get solved when someone with the time, skill, and motivation to do so decides to scratch that itch. If you want to speed this process along, you have a few options:

- Persuade a suitable developer to work on the problem areas you have (usually with money or a job)
- Fix the problems you have yourself (hey, at least you CAN)
- Deal with it as-is

.. beggars can't be choosers :)

-bob [ comment in the context of distribution packages but it applies to the discussion of IDE chaos as well].

My comment:

(1) In this business, beggars do choose, and they vote with their feet. If a beginner-friendly IDE is not an interesting problem for cognoscenti, the python foundation (or some such) should step in, or the python community should consider the possibility that the demographics of the development community is in danger of ceding the next generation...


On Feb 13, 2005, at 6:00 AM, [EMAIL PROTECTED] wrote:

Send Pythonmac-SIG mailing list submissions to
pythonmac-sig@python.org

To subscribe or unsubscribe via the World Wide Web, visit
http://mail.python.org/mailman/listinfo/pythonmac-sig
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]

You can reach the person managing the list at
[EMAIL PROTECTED]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Pythonmac-SIG digest..."
Today's Topics:

1. appscript (Michael Terry)
2. Re: Zope py2app, some progress (Bob Ippolito)
3. Re: Mac User Python Newbies (Bob Ippolito)
4. Re: appscript (Jacob Kaplan-Moss)
5. Re: Mac User Python Newbies (Robert Kern)

From:
Michael Terry <[EMAIL PROTECTED]>
Date: February 12, 2005 12:02:08 PM EST
To: pythonmac-sig@python.org
Subject: [Pythonmac-SIG] appscript


Hi,

I installed the appscript module. Can someone explain to me why the following script:

#!/usr/bin/pythonw

from appscript import *

peopleRef = app('Address Book.app').people.filter(its.emails != [])
print zip(peopleRef.name.get(), peopleRef.emails.value.get())

... errors with:

from: can't read /var/mail/appscript

... when one from the command line?

Thanks,
Mike


From:
Bob Ippolito <[EMAIL PROTECTED]>
Date: February 12, 2005 1:00:00 PM EST
To: "Roger Binns" <[EMAIL PROTECTED]>
Cc: Pythonmac-SIG@python.org
Subject: Re: [Pythonmac-SIG] Zope py2app, some progress



On Feb 11, 2005, at 12:26 PM, Roger Binns wrote:

All the example code is in Objective C. Quite simply there is
far too steep a learning curve to get through these layers be
it Objective C or pseudo objects in C plus mapping into Python
land.
Uh, no it isn't. A fair share of the IOKit examples are pure C or C++.

Ok, more accurately the examples that were looking at hierarchies
are in Objective C. And I'm sure that working with IOKit, in C or Objective C, once you have done it a few times is quick and easy. If you haven't then a time investment is needed to understand the docs, the examples, the types, actually write code that works, map it into Python etc.

There's a command-line application called ioreg that prints the hierarchy. It is written in C, so it's only using IOKit, CoreFoundation, and POSIX:

http://www.opensource.apple.com/darwinsource/10.3.8/IOKitTools-38/ioreg.tproj/

-bob





From:
Bob Ippolito <[EMAIL PROTECTED]>
Date: February 12, 2005 7:04:03 PM EST
To: Louis Pecora <[EMAIL PROTECTED]>
Cc: PythonMac <pythonmac-sig@python.org>
Subject: Re: [Pythonmac-SIG] Mac User Python Newbies



On Feb 12, 2005, at 6:25 PM, Louis Pecora wrote:

Bob Ippolito wrote:

I really like the ability to edit and just hit cmd-R to run the script.
The IDE could use some updating and wart removal. Syntax coloring, better scrolling (that's damaged right now), use of scroll wheel (if present), a few other interface changes.

In the end it's my tool.
I don't really understand how your are doing the development. You have to jump to a term window to run the script?


The source code for the old MacPython IDE is extremely ancient and nobody has expressed interest in updating it...

Bob, Yeah I can see that, although for us non-guru python types who just want a nice language to use it still is very nice. Sad that no one will update it, but I realize all this stuff is on a volunteer basis.

In this particular case, fixing the MacPython IDE to use the newer Carbon conventions and facilities would more or less be a rewrite anyway, so people have expressed interest in writing an equivalent using Cocoa. One such effort is PyOXIDE, though it would be nice if more of it was written in Python.

I've personally been working on software that would be extremely useful in the context of an IDE, such as an out-of-process GUI Python interpreter, loading code into remote processes, creating applications and plugins (py2app), determining dependencies (macholib/modulegraph), PyObjC, etc. but I'm not currently working on creating or directly improving any IDE because frankly, I'm generally more interested in the low level stuff and an IDE wouldn't really be all that useful to me most of the time.

Having said that I will lament what someone else on this list recently said about python (he's new to the lingo and wants to use python stuff), namely, everything seems scattered and now more so that the IDE is decaying. What to replace it with?

It'll be replaced when a suitable replacement exists. It's not yet clear what that replacement is, or when this will happen.

I know there are "solutions" since plenty of you are getting stuff done in Python. However, for people like me the need to separately install several packages just to get another one going is daunting, especially since the dependencies are hard to decipher. I am not complaining that the developers don't try to enlighten us, but since the development is only loosely coordinated a sense of fragility exists (at least for me) for any group of installed packages that have to work together.

It's absolutely true that it can currently be difficult to get a suite of packages installed if you don't already know what you're doing.

That's part of the reason why I wrote bdist_mpkg. All it takes is one person to build a package and package it up, and then anyone else can just install it with a download and a few clicks. The process of creating a package with bdist_mpkg is as easy as the usual "sudo python setup.py install". Honestly, all you have to do (py2app svn) is type "bdist_mpkg --zipdist --open" in the same directory as setup.py and it will build the package, create a zip file of the package for redistribution, and open up the package with the Installer GUI. If you just want to install it, you can just type "bdist_mpkg" which will do the same, minus the creation of the zip file.

Detection of or downloading dependencies for packages are not solved by this, largely because there IS NO STANDARD for declaring them (not even a de-facto one, though there is ongoing work in this area), so it is the "maintainers" job to do it by hand. However, it would be entirely possible to build an "Enthought Python" type distribution for Mac OS X using these facilities as-is. At least one person is interested in creating such a distribution <http://www.scipy.org/wikis/featurerequests/MacEnthon>, but it's not ready yet as far as I know. I am hosting several packages built using this system <http://undefined.org/python/packages.html> and that list will grow whenever I have the need or when someone else packages something and contributes it. I do, of course, reserve the right to stop maintaining this whenever I no longer have the time or interest to do so.

Eventually a better system will exist, whether that's some combination of PackageManger and bdist_mpkg, or something else like Python Eggs <http://peak.telecommunity.com/DevCenter/PythonEggs>. Unfortunately, for the most part, the people that are currently working on these systems don't really have an immediate need for them, so it's not an area of rapid development.

Where I'm going with this is that I am torn between my love for the Python language (the best I've ever used) and my needs to get work done (I do numerical work in my scientific research) without spending a lot of time and energy maintaining the software environment.
I'm not sure how to cure this. If there is a cure. It may be endemic to open source. I sense that for developers its just part of the job and maybe even enjoyable while for potential users like me it is a sad frustration.

Just a view from the users' side. Thanks for letting me vent.

Open source developers work on whatever they want or need to work on, so the particular problems you have will get solved when someone with the time, skill, and motivation to do so decides to scratch that itch. If you want to speed this process along, you have a few options:

- Persuade a suitable developer to work on the problem areas you have (usually with money or a job)
- Fix the problems you have yourself (hey, at least you CAN)
- Deal with it as-is

.. beggars can't be choosers :)

-bob





From:
Jacob Kaplan-Moss <[EMAIL PROTECTED]>
Date: February 12, 2005 7:04:52 PM EST
To: pythonmac-sig@python.org
Cc: Subject: Re: [Pythonmac-SIG] appscript


On Feb 12, 2005, at 11:02 AM, Michael Terry wrote:
I installed the appscript module. Can someone explain to me why the following script:

#!/usr/bin/pythonw

Michael --

It's because pythonw is a script itself; bash doesn't like #! lines to use other scripts. It's easily enough fixed, though; just use:

#!/usr/bin/env pythonw

and you should be fine.

Jacob





From:
Robert Kern <[EMAIL PROTECTED]>
Date: February 13, 2005 5:30:58 AM EST
To: pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Mac User Python Newbies


Bob Ippolito wrote:
However, it would be entirely possible to build an "Enthought Python" type distribution for Mac OS X using these facilities as-is. At least one person is interested in creating such a distribution <http://www.scipy.org/wikis/featurerequests/MacEnthon>, but it's not ready yet as far as I know.

All the packages in the main list build and install cleanly. Now I'm working on packaging up the documentation for each package, and unfortunately, Real Life annoyances are taking up too much time. Maybe next week there will be a beta release.

--
Robert Kern
[EMAIL PROTECTED]

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter




=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Schull, Ph.D.
Associate Professor
Information Technology
Rochester Institute of Technology
102 Lomb Memorial Drive
Rochester, New York 14623
[EMAIL PROTECTED] 585-738-6696

_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Reply via email to