Re: Experimental Python packages
On Fri, Sep 07, 2001 at 10:00:26AM -0500, Ben Burton wrote:
|
| > The real problem is making assumptions about what /usr/bin/python is
| > beyond what the RefMan says. The same sort of problem occurs if a
| > script writer assumes /bin/sh is bash and uses bash-isms rather than
| > sticking to the POSIX specification because /bin/sh could be any POSIX
| > compliant shell (ie ash).
|
| I'm not sure if we're agreeing or disagreeing here. I suspect the problem is
| that AFAICT nobody who wants /usr/bin/python to be a symlink to alternatives
| seems to have suggested a precise list of properties that said alternative
| should have.
I think we are mostly in agreement. I'm not arguing over the
suitability of any given python implementation to be the default. I
am arguing that we should give the admin the choice to choose which
implementation they want to be the default, whether it is via
alternatives or something else. In order to make the choice feasible
I think that all packages/products/whatever that need python must
either work with a (probably limited) set of well documented (as you
mentioned) features OR explicitly require and use a certain
version/implementation.
| I had implicitly assumed that the ability to open a random .so module was one
| such property, which jython will (likely) never satisfy.
If support of the C extension API (of a given version, I imagine since
it changes from time to time) is listed as a requirement for
/usr/bin/python then I agree that jython would not be suitable, but
the choice should still be present. Just as I have the choice to make
/bin/sh be csh, even though that would certainly not function
properly.
-D
Reply to: