Fair enough. Robin
On 30/11/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Robin Bryce schrieb: > > Yes, especially with the regard to the level you pitch for LSB. I > > would go as far as to say that if this "contract in spirit" is broken > > by vendor repackaging they should: > > * Call the binaries something else because it is NOT python any more. > > * Setup the installation layout so that it does NOT conflict or > > overlap with the standard layout. > > * Call the whole package something else. > > I think that would be counter-productive. If applied in a strict > sense, you couldn't call it Python anymore if it isn't in /usr/local. > I see no point to that. > > It shouldn't be called Python anymore if it doesn't implement > the Python language specification. No vendor is modifying it > in such a way that > > print "Hello" > > stops working. > > > Is it a bad idea to suggest that: Python grows a vendor_variant > > attribute somewhere in the standard lib; That its content is > > completely dictated by a new ./configure argument which is the empty > > string by default; And, request that it is left empty by re-packagers > > if the installation is 'reasonably standard' ? > > I'm not sure in what applications that would be useful. > > > I would strongly prefer _not_ write code that is conditional on such > > an attribute. However if there was a clear way for a vendor to > > communicate "This is not a standard python runtime" to the python run > > time, early failure (in the application) with informative error > > messages becomes much more viable. > > Again: none of the vendors modifies Python in a way that what > you get is "not a standard Python runtime". They *all* > are "standard Python runtimes". > > Regards, > Martin > _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
