Re: [Python-Dev] version compare function into main lib
anatoly techtonik wrote: Correct me if I wrong, but shouldn't Python include function for version comparisons? snip What do you think about adding cmpversions(first, second, strict=false) based on distutils into main lib? distutils _is_ already in the main lib, that is, the standard library. Will it be more appropriate to isolate the function into versions module? Should it be rewritten to remove re dependency in this case? Given that re is also in the standard library, and this is hardly speed critical, I'd say no. Distutils version comparisons: http://svn.python.org/view/python/branches/release26-maint/Lib/distutils/version.py?view=markup I don't see the point of moving this, unless it's part of some larger, radical fix distutils effort. And even then I'm not convinced. This probably belongs on the python-ideas mailing list, or on the distutils SIG list. I expect you'll see a lot of discussion on distutils SIG list in the coming days. Eric. ___ 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
Re: [Python-Dev] version compare function into main lib
anatoly techtonik wrote: Correct me if I wrong, but shouldn't Python include function for version comparisons? Can't you just compare sys.version_info tuples? sys.version_info (2, 5, 0, 'final', 0) Assuming the other possibilities for 'final' are 'alpha' and 'beta', these should compare in the right order. -- Greg ___ 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
Re: [Python-Dev] version compare function into main lib
Correct me if I wrong, but shouldn't Python include function for version comparisons? On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers. There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it 10.3.40-beta, but perhaps 10.3.40b1 or 10.3.40~beta. 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
Re: [Python-Dev] version compare function into main lib
See http://wiki.python.org/moin/ApplicationInfrastructure , Version handling below for a possible strict version API. The page is relevant for the general packaging discussion as well, although it's not fully fleshed out yet. MS On Fri, Mar 27, 2009 at 5:11 PM, Martin v. Löwis mar...@v.loewis.dewrote: Correct me if I wrong, but shouldn't Python include function for version comparisons? On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers. There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it 10.3.40-beta, but perhaps 10.3.40b1 or 10.3.40~beta. 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
Re: [Python-Dev] version compare function into main lib
On 2009-03-27 17:01, Eric Smith wrote: Martin v. Löwis wrote: Correct me if I wrong, but shouldn't Python include function for version comparisons? On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers. Yes. There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it 10.3.40-beta, but perhaps 10.3.40b1 or 10.3.40~beta. I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Instead of trying to parse some version string, distutils should require defining the version as tuple with well-defined entries - much like what we have in sys.version_info for Python. The developer can then still use whatever string format s/he wants. The version compare function would then work on this version tuple and probably be called cmp() (at least in Python 2.x ;-). -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Mar 27 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/ 2009-03-19: Released mxODBC.Connect 1.0.1 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/ ___ 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
Re: [Python-Dev] version compare function into main lib
Martin v. Löwis wrote: Correct me if I wrong, but shouldn't Python include function for version comparisons? On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers. Yes. There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it 10.3.40-beta, but perhaps 10.3.40b1 or 10.3.40~beta. I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Eric. ___ 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
Re: [Python-Dev] version compare function into main lib
Instead of trying to parse some version string, distutils should require defining the version as tuple with well-defined entries - much like what we have in sys.version_info for Python. The developer can then still use whatever string format s/he wants. The version compare function would then work on this version tuple and probably be called cmp() (at least in Python 2.x ;-). Except there need to be functions for parsing the tuple from a string and preferably a canonical string representation to ease that parsing. Hence the Version class in Version Handling referred to above. ___ 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
Re: [Python-Dev] version compare function into main lib
At 05:08 PM 3/27/2009 +0100, M.-A. Lemburg wrote: On 2009-03-27 17:01, Eric Smith wrote: Martin v. Löwis wrote: Correct me if I wrong, but shouldn't Python include function for version comparisons? On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers. Yes. There was no conclusion of how specifically that functionality should be offered; several people agreed that Python should mandate a standard format, which it is then able to compare. So you might not be able to spell it 10.3.40-beta, but perhaps 10.3.40b1 or 10.3.40~beta. I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Instead of trying to parse some version string, distutils should require defining the version as tuple with well-defined entries - much like what we have in sys.version_info for Python. The developer can then still use whatever string format s/he wants. The version compare function would then work on this version tuple and probably be called cmp() (at least in Python 2.x ;-). By the way, pkg_resources.parse_version of course returns a tuple that can be compared with cmp(). ___ 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
Re: [Python-Dev] version compare function into main lib
I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Procedurally, I think it's a very bad approach. I don't mind the setuptools implementation being used as a basis (assuming it gets contributed), but *independently* I think a specfication is needed what version strings it actually understands. Such specification must precede the actual implementation (in distutils). 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
Re: [Python-Dev] version compare function into main lib
Martin v. Löwis wrote: I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Procedurally, I think it's a very bad approach. I don't mind the setuptools implementation being used as a basis (assuming it gets contributed), but *independently* I think a specfication is needed what version strings it actually understands. Such specification must precede the actual implementation (in distutils). Agreed. Specifications first, for all of this work. ___ 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
