On Feb 10, 2006, at 1:53 PM, Bob Ippolito wrote: > > On Feb 10, 2006, at 1:06 PM, Kevin Walzer wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Christopher Barker wrote: >>> Louis Pecora wrote: >>>> This seems to be where this argument goes: the user/newbies vs. >>>> the >>>> developers. >>> >>> I don't think so. This entire conversation is about supporting the >>> newbies. The disagreements are about how best to do that. >>> >>>> You shouldn't be forcing everyone to adopt a python system >>>> that then suits your marketing model. >>> >>> I know why I'm pushing for the "Install the 2.4 version" approach, >>> and >>> it's precisely to support newbies, not to fit a marketing model. >>> >>> If we make it clear that there is one "Standard" way to do python >>> on the >>> Mac, then it's easier for everyone: >>> >>> - Newbies don't have to make a decision they don't understand the >>> implications of. >>> >>> - We don't have to field questions about more than one version. >>> >>> - When they need to add an extension package, there is only one >>> set of >>> pre-built packages to look at. >>> >>> - Extension package builders and maintainers only need to target one >>> version, and as a result, more packages will work on the Mac. (you >>> should see what's in the matplotlib setup.py: a fragile mess >>> inside the >>> "darwin" section, looking around for whether you're running fink, or >>> darwinports, etc. so that libs can be found. What a pain!) >>> >>> Those are some of the reasons that I think we need to establish a >>> single, standard, "Recommended by the MacPython community" version. >> >> +1 for what Chris is advocating here. >> >> A good model for this is Tk Aqua: see http:// >> tcltkaqua.sourceforge.net. >> For the past few years this has been the standard way to get the >> "latest and greatest" Tcl/Tk for the Mac. It's been superseded a >> bit by >> ActiveState's distribution, but because ActiveState has licensing >> restrictions, that's not for everyone. >> >> ActivePython is also an example to consider that's a little more >> relevant. Not to recommend ActivePython itself, as its licensing is >> more >> restrictive than the build that will result from this discussion, >> but it >> is a self-contained, easily-installed, well-documented, and up-to- >> date >> bundle of Python and packages. > > The licensing issues with ActivePython were clarified last year: It > is explicitly legal to redistribute self-contained application > bundles (a la py2exe or py2app) built with ActiveState's > distributions. This gives it a leg up on Apple's distro (which has > no such clause; components of OS X are not redistributable), and > makes it a candidate Python distribution for almost anyone. > Personally, I have tried it out a bit on one of my machines and found > a couple bugs that were quickly resolved. Nothing outstanding and > nothing major, and the turnaround was quick. > > Currently, ActivePython on Mac OS X is almost exactly the same thing > that we're going to be shipping with the universal build of 2.4.2. > The differences will be: > > 1. They aren't shipping readline, we will > 2. We'll probably ship universal first > 3. I don't believe they have the PATH hack in their installer > 4. They ship with an ActivePython icon for pythonw, we'll stick with > the current icon.
5. We're also shipping some bug fixes that aren't in Python yet, like doing the select.poll check at runtime instead of configure time. Mac OS X 10.4.4 has a fully working poll implementation, but I believe some point version back in the day didn't. Some applications depend on select.poll and associated constants being there. I can't think of anything open source at the moment, but I know people who have internal apps that depend on poll because it has higher performance for their deployment environment. -bob _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
