evaluation question

[Chris Angelico]

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