Re: Odd version scheme
On Thu, Feb 12, 2015 at 11:58 AM, MRAB pyt...@mrabarnett.plus.com wrote: On 2015-02-12 17:35, Ian Kelly wrote: On Thu, Feb 12, 2015 at 10:19 AM, Skip Montanaro skip.montan...@gmail.com wrote: I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions 9. There are too many similar assumptions about version numbers out in the real world. It still becomes an issue when we get to Python 10. Just call it Python X! :-) Things break down again when we get to Python XIX. 'XVIII' 'XIX' False -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 12/02/2015 19:16, Ian Kelly wrote: On Thu, Feb 12, 2015 at 11:58 AM, MRAB pyt...@mrabarnett.plus.com wrote: On 2015-02-12 17:35, Ian Kelly wrote: On Thu, Feb 12, 2015 at 10:19 AM, Skip Montanaro skip.montan...@gmail.com wrote: I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions 9. There are too many similar assumptions about version numbers out in the real world. It still becomes an issue when we get to Python 10. Just call it Python X! :-) Things break down again when we get to Python XIX. 'XVIII' 'XIX' False I believe that this could be solved by borrowing from Mark Pilgrim's excellent Dive Into Python which uses (or used?) these hex (?) numbers as the basis for a look at unit testing. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2015-02-12 17:35, Ian Kelly wrote: On Thu, Feb 12, 2015 at 10:19 AM, Skip Montanaro skip.montan...@gmail.com wrote: I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions 9. There are too many similar assumptions about version numbers out in the real world. It still becomes an issue when we get to Python 10. Just call it Python X! :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2015-02-12 12:16, Ian Kelly wrote: It still becomes an issue when we get to Python 10. Just call it Python X! :-) Things break down again when we get to Python XIX. 'XVIII' 'XIX' False You know what this sub-thread gives me? The icks. https://www.youtube.com/watch?v=6DzfPcSysAg -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2/12/2015 11:16 AM, Ian Kelly wrote: Things break down again when we get to Python XIX. 'XVIII' 'XIX' False Looks to me like you better check if your PEP313 patch is installed properly. :) Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: Parsing and comparing version strings (was: Odd version scheme)
On 2015-02-13 12:20, Ben Finney wrote:
Not sure why this is ridiculous.
Right, versions are effectively a special type [0], specifically
*because* they intentionally don't compare as scalar numbers or
strings. It's not “ridiculous” to need custom comparisons when
that's the case.
Python even comes with support for version parsing and comparison
in the standard library [1]. So if anything's “ridiculous”, it's
the act of re-implementing that and getting it wrong.
(Or maybe that such an important part of the standard library is
largely undocumented.)
I was surprised (pleasantly) to learn of that corner of distutils,
but can never remember where it is in the stdlib or what it's
called. So it's pretty standard for my process to be something like
- Hmm, I need to compare version-strings
- search the web for python compare version number
- note the top-ranked Stack Overflow answer
- spot that it uses distutils.version.{LooseVersion,StrictVersion}
- use that in my code, optionally searching to get full docs with
site:python.org LooseVersion StrictVersion, only to be
surprised when something like
https://docs.python.org/2/library/{module}
isn't anywhere in the top umpteen hits.
largely undocumented is an understatement :-)
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
Parsing and comparing version strings (was: Odd version scheme)
Gisle Vanem gva...@yahoo.no writes: That's exactly what they do now in IPython/utils/version.py with the comment: Utilities for version comparison It is a bit ridiculous that we need these. Not sure why this is ridiculous. Right, versions are effectively a special type [0], specifically *because* they intentionally don't compare as scalar numbers or strings. It's not “ridiculous” to need custom comparisons when that's the case. Python even comes with support for version parsing and comparison in the standard library [1]. So if anything's “ridiculous”, it's the act of re-implementing that and getting it wrong. (Or maybe that such an important part of the standard library is largely undocumented.) [0] URL:https://wiki.python.org/moin/Distutils/VersionComparison [1] Unfortunately undocumented, like much of the Distutils API. Try URL:http://epydoc.sourceforge.net/stdlib/distutils.version.StrictVersion-class.html. -- \ “Programs must be written for people to read, and only | `\incidentally for machines to execute.” —Abelson Sussman, | _o__) _Structure and Interpretation of Computer Programs_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
Skip Montanaro wrote: I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions 9. There are too many similar assumptions about version numbers out in the real world. Which is why there will be no Windows 9. Too many bad programmers that test for Windows 95 or 98 by checking the version string and doing a prefix test for Windows 9. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2015-02-12 17:45, Gisle Vanem wrote: I tried using Interactive Python with a PyQt4 console: IPython.exe qtconsole But got a ImportError: IPython requires PyQT4 = 4.7, found 4.10.4 Looking at Ipython's check (in site-packages\IPython\external\qt.py): if QtCore.PYQT_VERSION_STR '4.7': raise ImportError(IPython requires PyQt4 = 4.7, found %s%QtCore.PYQT_VERSION_STR) So even if '4.10' '4.7', my '4.10' is newer. What odd version scheme is this really? I just edited that line to read: if QtCore.PYQT_VERSION_STR '4.10':' This looks like it's comparing them as strings. It would be wiser if the program compared them as version-numbers: from distutils.version import LooseVersion, StrictVersion qt_ver = QtCore.PYQT_VERSION_STR target_ver = 4.10 for t, desc in [ (str, String), (LooseVersion, Loose), (StrictVersion, Strict), ]: a = t(qt_ver) b = t(target_ver) print(Using %s comparison, '%r %r' is %s % ( desc, qt_ver, target_ver, a b) So the test should actually be something like if LooseVersion(QtCore.PYQT_VERSION_STR) LooseVersion(4.10): balk() -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions 9. There are too many similar assumptions about version numbers out in the real world. Skip -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Thu, Feb 12, 2015 at 9:45 AM, Gisle Vanem gva...@yahoo.no wrote: I tried using Interactive Python with a PyQt4 console: IPython.exe qtconsole But got a ImportError: IPython requires PyQT4 = 4.7, found 4.10.4 Looking at Ipython's check (in site-packages\IPython\external\qt.py): if QtCore.PYQT_VERSION_STR '4.7': raise ImportError(IPython requires PyQt4 = 4.7, found %s%QtCore.PYQT_VERSION_STR) So even if '4.10' '4.7', my '4.10' is newer. What odd version scheme is this really? I just edited that line to read: if QtCore.PYQT_VERSION_STR '4.10': Seems to be working fine now. There's nothing wrong with the version scheme; 4.10 is a greater version than 4.7. The problem appears to be IPython using a simple lexicographical string comparison to compare the version numbers and failing when it gets to a number that isn't a single digit. -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Fri, Feb 13, 2015 at 3:45 AM, Gisle Vanem gva...@yahoo.no wrote: Looking at Ipython's check (in site-packages\IPython\external\qt.py): if QtCore.PYQT_VERSION_STR '4.7': raise ImportError(IPython requires PyQt4 = 4.7, found %s%QtCore.PYQT_VERSION_STR) So even if '4.10' '4.7', my '4.10' is newer. What odd version scheme is this really? I just edited that line to read: if QtCore.PYQT_VERSION_STR '4.10': Looks to me like a fault in comparison format. Normally, you'd expect that 4.10 follows 4.9 - that is, that the version number is a tuple of integers - but this is attempting a naive string comparison on it. Check for an ipython bug tracker and report the matter; that ought to be fixed. Bear in mind that your change now means that you're accepting too much - for instance. '4.6' is not less than '4.10', even though it's supposed to be rejecting that. Presumably this won't be a problem on your own system, but for upstream, a more reliable fix will be needed. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Odd version scheme
I tried using Interactive Python with a PyQt4 console: IPython.exe qtconsole But got a ImportError: IPython requires PyQT4 = 4.7, found 4.10.4 Looking at Ipython's check (in site-packages\IPython\external\qt.py): if QtCore.PYQT_VERSION_STR '4.7': raise ImportError(IPython requires PyQt4 = 4.7, found %s%QtCore.PYQT_VERSION_STR) So even if '4.10' '4.7', my '4.10' is newer. What odd version scheme is this really? I just edited that line to read: if QtCore.PYQT_VERSION_STR '4.10': Seems to be working fine now. -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Fri, Feb 13, 2015 at 4:19 AM, Skip Montanaro skip.montan...@gmail.com wrote: I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions 9. There are too many similar assumptions about version numbers out in the real world. I don't think the policy is quite that strong; 2.7.10 has already been scheduled, and there's sufficient resistance to a Python 4.0 that there's likely to be a 3.10; although some people are saying that it might be worth following 3.9 with 4.0, drop only stuff that's been deprecated for a long time (on par with the disallowing of string exceptions during 2.x), and basically dodge the whole issue. But yes, there's a general feeling that two-digit version components cause trouble, and it's usually easy enough to avoid them. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On Thu, Feb 12, 2015 at 10:19 AM, Skip Montanaro skip.montan...@gmail.com wrote: I believe this sort of lexicographical comparison wart is one of the reasons the Python-dev gang decided that there would be no micro versions 9. There are too many similar assumptions about version numbers out in the real world. It still becomes an issue when we get to Python 10. -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
Tim Chase wrote: So the test should actually be something like if LooseVersion(QtCore.PYQT_VERSION_STR) LooseVersion(4.10): balk() That's exactly what they do now in IPython/utils/version.py with the comment: Utilities for version comparison It is a bit ridiculous that we need these. Not sure why this is ridiculous. I had an old version of IPython v0.13 installed! I've upgraded to v2.10 and all is good. -- --gv -- https://mail.python.org/mailman/listinfo/python-list
Re: Odd version scheme
On 2015-02-12 18:37, Gisle Vanem wrote: Tim Chase wrote: So the test should actually be something like if LooseVersion(QtCore.PYQT_VERSION_STR) LooseVersion(4.10): balk() That's exactly what they do now in IPython/utils/version.py with the comment: Utilities for version comparison It is a bit ridiculous that we need these. Not sure why this is ridiculous. Well, if you're storing them as strings, then duh, you need the helper utilities. If you store them as comparable tuples, then it's not a problem. :-/ # library.VERSION = (3, 14, 15) if library.VERSION (2, 3, 18): complain() It does become harder to mark things as alpha/beta/pre/rc, but something Enum-like might suffice for that in a fourth field of the tuple. -tkc -- https://mail.python.org/mailman/listinfo/python-list
