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
