Ok I understand
Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows From: Rob Cliffe via Python-list<mailto:python-list@python.org> Sent: Tuesday, February 7, 2023 6:54 PM To: Chris Angelico<mailto:ros...@gmail.com>; python-list@python.org<mailto:python-list@python.org> Subject: Re: evaluation question On 07/02/2023 08:15, Chris Angelico wrote: > On Tue, 7 Feb 2023 at 18:49, Rob Cliffe via Python-list > <python-list@python.org> wrote: >> >> >> On 02/02/2023 09:31, mutt...@dastardlyhq.com wrote: >>> On Wed, 1 Feb 2023 18:28:04 +0100 >>> "Peter J. Holzer" <hjp-pyt...@hjp.at> wrote: >>>> --b2nljkb3mdefsdhx >>>> Content-Type: text/plain; charset=us-ascii >>>> Content-Disposition: inline >>>> Content-Transfer-Encoding: quoted-printable >>>> >>>> On 2023-02-01 09:00:39 -0000, mutt...@dastardlyhq.com wrote: >>>>> Its not evolution, its revolution. Evolution retains old functionality. >>>> Tell a penguin that it can fly :-) >>> Yeah ok :) But the ancestors of penguins didn't wake up one morning, flap >>> their wings and fall out the tree, it happened gradually. Python2 syntax >>> could have been retained for X versions of 3 just as C++ keeps old stuff >>> until its eventually deprecated them removed. >> Yeah? So what would this do: >> print () >> In Python 2 this prints an empty tuple. >> In Python 3 this is a call to the print function with no arguments, >> which prints a blank line. >> You can't have it both ways. >> In any case, supporting two different syntaxes simultaneously would be >> messy and difficult to maintain. > There are two solutions to this. The most obvious is "from __future__ > import print_function", which gives you the full power and flexibility > of Py3 in anything back as far as 2.6; the other is to always pass a > single string argument to print: > > print("") > print("spam %d ham %d" % (spam, ham)) > > This will work in pretty much ANY version of Python [1] and doesn't > require any sort of per-module configuration. > > The idea that old syntax should be retained is only part of the story. > While it's definitely important to not break old code unnecessarily, > it is far more important to ensure that there's *some way* to write > code that works across multiple versions. That's what we have here: > even with the breaking changes, there was usually a way to make your > code run identically on multiple versions. Sometimes this means a > compatibility shim at the top, like "try: raw_input; except NameError: > raw_input = input", and sometimes it means following a discipline like > putting b"..." for all strings that need to be bytes. But there always > needs to be a way. > > ChrisA > > [1] This is the part where someone points out to me that it wouldn't > work in Python 1.3 or something You are quite right Chris, and indeed I have used both solutions in my own code to keep 2-3 compatibility. I was just pointing out that continuing to support Python 2 syntax in Python 3 was not an option. Best wishes Rob Cliffe -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
