Re: [Distutils] PEP 386 status - last round here ?
At 09:15 PM 11/29/2009 +0100, Tarek Ziadé wrote:
2009/11/29 P.J. Eby
: [..] WSGI and setuptools have been widely adopted in spite of their
technical and
ideological flaws, because they had good incentive engineering.
Or, in other words, because practicality beats purity, every single time.
Do you mean here that this independently-created standard, this good incentive engeneering a.k.a. Setuptools, is doomed not to evolve anymore ? e.g. to adapt its standard to a common standard that is going to raise and be added in stldib at some point ?
I'm saying that ignoring backwards compatibility (as MAL and Ben have proposed) is bad incentive engineering. I don't have any disagreement with what you're doing wrt PEP 386, btw; we already had all the technical issue discussion necessary back when you first wrote it. I've just been chiming in on a couple of threads where people have proposed changes that would break backward compatibility and present user experience.
"P.J. Eby"
I'm saying that ignoring backwards compatibility (as MAL and Ben have proposed) is bad incentive engineering.
I deny this characterisation. PEP 386, by declaring a distinction between version string comparisons that do or do not conform to a standard, is *necessarily* backward-incompatible: there will be version string comparison semantics currently in use that do not meet the standard. So if anything, it's PEP 386 that breaks backward compatibility. That's unavoidable, of course, and I can only trust that the proponents of PEP 386 have a means of dealing with those existing version comparisons that won't meet the standard. What I'm proposing is a modification to the specification; I'm not introducing backward incompatibility, since that's inherent in the standardisation effort. -- \ “The flattening of underwear with pleasure is the job of the | `\ chambermaid.” —hotel, Yugoslavia | _o__) | Ben Finney
P.J. Eby wrote:
At 09:15 PM 11/29/2009 +0100, Tarek Ziadé wrote:
2009/11/29 P.J. Eby
: [..] WSGI and setuptools have been widely adopted in spite of their
technical and
ideological flaws, because they had good incentive engineering.
Or, in other words, because practicality beats purity, every single time.
Do you mean here that this independently-created standard, this good incentive engeneering a.k.a. Setuptools, is doomed not to evolve anymore ? e.g. to adapt its standard to a common standard that is going to raise and be added in stldib at some point ?
I'm saying that ignoring backwards compatibility (as MAL and Ben have proposed) is bad incentive engineering.
Ignoring backwards compatibility is a bad thing, IMHO. Breaking forward compatibility (sometimes) is a good thing, since it allows evolution to find new better paths of development. Fact is, you are just misinterpreting what I wrote. You can't expect setuptools as-of today to work with a standard that is devised to be implemented by future tools. What you are referring to is breaking forward compatibility, ie. you expect today's setuptools to work with future packages that will be written against a future standard. New packages relying on the the new version format will, of course, require and use a package manager that supports the new format. If setuptools doesn't want to support it, that's fine. I'm sure Distribute will ... and could even support old setuptools packages by adding a --use-old-style-setuptools-package-format option ;-) to Distribute, so I don't see much of a problem with breaking forward compatibility in this case. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Nov 30 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Mon, Nov 30, 2009 at 10:49:55AM +0100, M.-A. Lemburg wrote:
so I don't see much of a problem with breaking forward compatibility in this case.
Indeed, but equally so I don't see an advantage in breaking forward compatibility in this case (i.e. underscores in PEP 386 don't allow us to express something that we otherwise couldn't) so PJE's argument of practicality vs purity still wins IMHO. And besides setuptools isn't alone in not liking underscores in versions, it's just that the others manually translate the versions before using it so can work around it. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org
participants (4)
-
Ben Finney
-
Floris Bruynooghe
-
M.-A. Lemburg
-
P.J. Eby