evaluation question

[Rob Cliffe]

On 07/02/2023 08:15, Chris Angelico wrote:
> On Tue, 7 Feb 2023 at 18:49, Rob Cliffe via Python-list
> <python-list at python.org> wrote:
>>
>>
>> On 02/02/2023 09:31, Muttley at dastardlyhq.com wrote:
>>> On Wed, 1 Feb 2023 18:28:04 +0100
>>> "Peter J. Holzer" <hjp-python at 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, Muttley at 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