[Pythonmac-SIG] The future

[Bob Ippolito]

On Friday, Sep 5, 2003, at 17:51 America/New_York, Jack Jansen wrote:

> Folks,
> with Python 2.3 in all probability going to be included in OSX 10.3 
> and with
> lots of nifty new stuff coming available from MacPython developers 
> (aeve and
> the CF additions, to name just two) we need to come up with a scheme to
> gradually introduce these.

I believe Package Manager is a good testbed for these.  I don't think 
we should accept new modules into MacPython proper until they are 
properly documented, tested, and relatively popular.  PyObjC is a prime 
example of this, and should DEFINITELY be a battery of the next release 
of Python (assuming it hits 1.0 and fixes the few remaining known bugs, 
I guess).

> Under MacOS9 there was really no problem, because there were so few 
> core
> developers. Most new things got done by a small group who had access to
> it immediately, and the rest of the world had to wait. Moreover, they
> often didn't have to wait all that long, because often I would 
> introduce
> stealthily introduce new functionality (if it was backward compatible)
> in a minor release. And the MacPython user community was so small that
> if someone was a minor release behind and something didn't work it
> was easy to make them upgrade.

I think that a bunch of MacOS9 functionality has been broken already, I 
propose to break even more ;)  For example, I believe colon delimited 
file specifications should be completely deprecated, and FSSpec, FSRef 
and Alias should be given useful __str__ and __unicode__ methods 
(return unix path), for example.

Someone should also buckle down and wrap QuickTime properly so that you 
can do whatever you want with it.  I've been maintaining my own version 
of the QuickTime wrapper because I've had to make changes to the bgen 
so that it actually lets you create a QuickTime movie from scratch, for 
example.  Maybe we need to make bgen smarter, or make it output Pyrex 
instead of C?  I've had very good results with Pyrex so far, though 
automating the C header file -> Pyrex include file stuff would be 
excellent (so far I've been doing it in Vim by hand each time with 
regexps).

Although, in MacOS X, sometimes it's preferable to have paths as URLs.. 
  hmm.

> All of these assertions are going to break with 10.3, or already 
> broken.
> There are a lot more developers, and they come up with all sorts of
> goodies. But 99.9% of the Python installed base will remain at
> MacPython 2.3.0 until MacOSX 10.4 comes out, so sneaking in 
> functionality
> in 2.3.1 is a strict no-no, as it would potentially break things badly
> for people distributing software to third parties.

I sort of agree with this, but I think that this problem is mostly 
solved with bundlebuilder.  If 2.3.1's bundlebuilder knows what changed 
between Python 2.3.1 and Python 2.3.0 modulewise, then it could include 
those changed modules for compatibility across the 2.3.x board... as 
long as sys.path is setup properly so that the replacements are 
preferred over system modules.

> What I want to do is something similar to "from future import ...",
> but it's a bit different. For example, if we have a new Carbon.CF 
> module
> then "from MacPython24 import Carbon.CF" won't cut it, because
> you really want some sort of a statement that will, from that point
> on, *everything* to use the new module. Carbon.CF is a prime example,
> because it is also used under the hood: the core Python engine
> (and through it extensions like PyObjC) will import it itself
> when it needs to create a CF object.
>
> I have a couple of ideas on how to do this, but they're all either
> clunky, or contradictory, or both. So: let's hear any bright ideas you 
> all have,
> please...

I don't know if this really makes sense.  Old versions of ModuleX are 
going to depend on the functionality and bugs of the version of 
Carbon.CF it was released with (for example, LaunchServices makes up 
for a retain count bug in Carbon.CF, and would leak on a fixed 
version).  It is up to the author of ModuleX to be aware that there are 
multiple versions of Carbon.CF it may be using, but Carbon.CF doesn't 
say what version it is (though you could extrapolate this from the sys 
module, if the user hasn't replaced the installed version of Carbon.CF).

As far as making everything use the new module goes, something that 
does sys.modules['Carbon.CF'] = MacPython24.Carbon.CF *should* work, 
although I don't know what that would do if another module in the 
Carbon package said "import CF".

IMHO, there should be a standard way for doing module metadata.  Many 
package and module authors use __version__, I think this should be a 
standard for all modules, even system modules.  It would make 
PackageManager easier, for sure.  This could partially be solved if 
PackageManager had package receipts, since all the metadata is known 
when it installs a package.. but this should really be distutils 
functionality (actually I think that most of PackageManager should be 
distutils functionality).

Oh, FYI, I make a small update to makepimp.py the other day so it is 
tolerant of setup.py scripts that like to print crap to stdout.  Now it 
runs setup.py twice, the first time to determine the amount of line 
noise, and the second time to actually query package metadata.

http://undefined.org/python/makepimp.py

-bob