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
