On Sunday 25. January 2015 10.07.34 Elena ``of Valhalla'' wrote: > On 2015-01-25 at 02:56:43 -0300, Werner Almesberger wrote: > > Bas Wijnen wrote: > > > If you want to be future-proof, you probably want to use python3, in > > > which 3/2 == 1.5 (and 4/2 == 2.0, not 2); you have to specify integer > > > division explicitly as 3//2 there. > > > > Oooh, that explains everything. That's a pretty fundamental change to > > make in a widely deployed language. > > [...] > > Hmm, just saw that they removed (converted) the print statement in > > version 3. And I thought the gcc folks were reckless ;-)
Where have you been, Werner?! Python 3.0 came out in 2008. :-) > Python 3.0 was designed explicitely to allow for fundamental changes > that broke compatibility: in a way it can be considered almost a > (close) derivative of python 2.x rather than a version of the same > language. > > Some changes were however backported to python2 and it is possible to > write at least some code that is able to run under both 2 and 3 > by importing the relevant changes from __future__; it is the first > approach listed on https://wiki.python.org/moin/PortingPythonToPy3k Python 2.7 is pretty much the recommended vehicle for moving off Python 2 and onto Python 3, although Python 2.6 was the first release where this was considered viable. And in fact, Python 2.6 introduced some performance regressions that may have been due to the compatibility features added specially for Python 3 porting purposes. Even now, you can be unlucky and have whining stderr messages about Python 3 incompatibility produced by libraries imported by your Python 2 programs, which could be regarded as a form of filling people's logs out of spite for them not having incurred the cost of porting their software to Python 3. > You can use just the new division behaviour by importing ``division`` > from __future__, or you can import all of the four modules and > try to keep the code running under both versions. "Future" division was introduced before Python 3.0 came about, and in fact brought about the __future__ mechanism of supposedly graceful change within the Python 2.x series. The idea was that such incremental changes would very slowly lead to the mythical "Python 3000" - a fixed-up and more elegant version of Python - but when the core developers realised that they had the time to push for Python 3000 in the near term, the discontinuity between Python 2 and the newly-created Python 3 came about. I'm not a fan of what they did with Python 3, even if it could be said to be a better language. On the topic of CAD and modelling, I believe the Blender project experienced a degree of inconvenience after being persuaded to be Python 3 early adopters. And the whole business has just created confusion and fragmentation (and a degree of hostility towards anyone who doesn't unconditionally advocate Python 3 adoption). Having now acquainted Werner with Python 3, perhaps we shouldn't mention the latest core developer push for type annotations in Python. :-) Paul _______________________________________________ Qi Hardware Discussion List Mail to list (members only): [email protected] Subscribe or Unsubscribe: http://lists.en.qi-hardware.com/mailman/listinfo/discussion
