On Wed, 1 Feb 2023 08:56:40 -0000 (UTC), Muttley wrote:

> Why couldn't they just keep "print" and call the function , oh I dunno,
> "printf" ?

<Venting> Why does every language have to invent their own function to
print to the console that is very similar but not the same as the rest of
the herd?</Venting>

rbowman <bowman@montana.com> writes:
><Venting> Why does every language have to invent their own function to
>print to the console that is very similar but not the same as the rest of
>the herd?</Venting>

Why do there have to be different languages at all?

On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
> Its not evolution, its revolution. Evolution retains old functionality.

Tell a penguin that it can fly :-)

hp

--
_ | Peter J. Holzer | Story must make more sense than reality.
|_|_) | |
| | | hjp@hjp.at | -- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"

On 2023-02-01, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>
>>No, but it was decided that Python 3 would have to be backwards
>>incompatible, mainly to sort out the Unicode mess. Given that,
>>the opportunity was taken to clean up some other mistakes as well.
>
> Unicode is just a string of bytes.

No it isn't. Certain _encodings_ of Unicode are strings of bytes
(UTF-8, for example).

> C supports it with a few extra library functions to get unicode
> length vs byte length and similar. Its really not that
> hard.

It is, actually.

C (the language) doesn't support Unicode at all. There are, however,
libraries that can be used to deal with it.

> Rewriting an entire language just to support that sounds a bit
> absurd to me but hey ho...

Feel free to maintain your own fork of 2.7 :)

The 2.7->3 incompatibility that created the most work for me was
bytes.

On 2023-02-01, Peter J. Holzer <hjp-python@hjp.at> wrote:
> On 2023-02-01 09:00:39 -0000, Muttley@dastardlyhq.com wrote:
>> Its not evolution, its revolution. Evolution retains old functionality.
>
> Tell a penguin that it can fly :-)

Penguins can fly. They just do it underwater...

On Thu, 2 Feb 2023 at 04:29, <Muttley@dastardlyhq.com> wrote:
>
> On Wed, 1 Feb 2023 11:59:25 +1300
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
> >On 31/01/23 10:24 pm, Muttley@dastardlyhq.com wrote:
> >> All languages have their ugly corners due to initial design mistakes and/or
> >> constraints. Eg: java with the special behaviour of its string class, C++
> >> with "=0" pure virtual declaration. But they don't dump them and make all old
> >
> >> code suddenly cease to execute.
> >
> >No, but it was decided that Python 3 would have to be backwards
> >incompatible, mainly to sort out the Unicode mess. Given that,
> >the opportunity was taken to clean up some other mistakes as well.
>
> Unicode is just a string of bytes. C supports it with a few extra library
> functions to get unicode length vs byte length and similar. Its really
> not that hard. Rewriting an entire language just to support that sounds a
> bit absurd to me but hey ho...
>

No, Unicode is NOT a string of bytes. UTF-8 is a string of bytes, but
Unicode is not.

If you disagree with the way Python has been developed, you're welcome
to fork Python 2.7 and make your own language (but not called Python).
Meanwhile, the rest of us really appreciate the fact that Python
supports Unicode properly, not just as "a string of bytes". Also, be
sure to deal with the technical debt of refusing to ever remove any
feature. I'm curious how many dev hours that costs you.

Incidentally, the bytes->unicode transformation wasn't Python 3's
biggest reason for being. See https://peps.python.org/pep-3100/ for
details.

ChrisA

On Thu, 2 Feb 2023 at 04:26, <Muttley@dastardlyhq.com> wrote:
>
> Its not evolution, its revolution. Evolution retains old functionality.
>

By the way, I'd like to see your opinions on eternal retention of old
functionality. Which of these features are you willing to put effort
into supporting?

1) Long integer constants eg 1234L which are the long type rather than
the int type
2) dict.has_key method, doing the same job as "key in dict"
3) The input() function, which automatically evals what was entered at
the keyboard
4) `x` which does the same as repr(x)
5) "from module import *" inside a function

Retaining old functionality is all well and good, but there are
limits, especially when the old functionality is downright wrong
(input vs raw_input). Before you complain about other people's
decisions, find out how many hours of YOUR time you're willing to
invest into a project.

Or alternatively, how many dollars you would spend on it. Let's
pretend that you can pay for as many core Python developers as you
like for USD 150,000 a year each. (See job posting
https://jobs.pyfound.org/apply/TwgMP1b4OV/Security-Developer-In-Residence
for where I got that figure from.) How many are you personally willing
to hire in order to have these features maintained?

It's easy to whine. Much harder to actually do something about it.

ChrisA

On 2/1/23 3:59 AM, Muttley@dastardlyhq.com wrote:
> On Wed, 1 Feb 2023 11:59:25 +1300
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> On 31/01/23 10:24 pm, Muttley@dastardlyhq.com wrote:
>>> All languages have their ugly corners due to initial design mistakes and/or
>>> constraints. Eg: java with the special behaviour of its string class, C++
>>> with "=0" pure virtual declaration. But they don't dump them and make all old
>>> code suddenly cease to execute.
>> No, but it was decided that Python 3 would have to be backwards
>> incompatible, mainly to sort out the Unicode mess. Given that,
>> the opportunity was taken to clean up some other mistakes as well.
> Unicode is just a string of bytes. C supports it with a few extra library
> functions to get unicode length vs byte length and similar. Its really
> not that hard. Rewriting an entire language just to support that sounds a
> bit absurd to me but hey ho...
>
No, Unicode is a string of 21 bit characters. UTF-8 is a representation
that uses bytes, but isn't itself "Unicode".

The key fact is that a "String" variable is indexed not by bytes of
UTF-8 encoding, but by actual characters.

Python3 will store a string as either a sequence of Bytes if the data is
all Latin-1, as a sequence of 16-bit words if the data all fits on th
BMP, and a sequence of 32 bit words if it has a value outside the BMP.

--
Richard Damon

On 2/1/23 12:46 PM, Grant Edwards wrote:
> C (the language) doesn't support Unicode at all. There are, however,
> libraries that can be used to deal with it.

No, it does, but only optionally.

<uchar.h> provides functions that manipulate Unicode "Characters"

The type char32_t will hold Unicode Code Points, and you can define
string literals of that type with

U"string" notation.

--
Richard Damon

On 1 Feb 2023 17:31:02 GMT, Stefan Ram wrote:

> rbowman <bowman@montana.com> writes:
>><Venting> Why does every language have to invent their own function to
>>print to the console that is very similar but not the same as the rest
>>of the herd?</Venting>
>
> Why do there have to be different languages at all?

https://homepages.cwi.nl/~steven/abc/programmers/introduction.html

"Why ABC?
The answer to the question 'Why a new language?' is the same as the answer
to the question 'Why new computers?': because they can help you do the job
better. With the choice between a language where it will take a week to
write a program, and a language where it will take an afternoon, most
people will choose the latter."

That leads to the question of when Van Rossum was looking for a hobby
project, why not extend ABC? Or Pike?

https://pike.lysator.liu.se/about/history/

Then there is the question of how a new language becomes popular. When
Matsumoto developed Ruby it was almost 4 years before there was any
coherent English documentation. How did it get traction?

How about Go? Thompson and Pike hate C++ (with cause) so they went back to
C and reworked it. Then there is C++ itself, which was released before its
time.

There are many more obscure languages when someone saw a need. Then there
are features the propagate like lambdas. Everyone came down with lambda
envy and shoehorned them into the language one way or the other.

On Wed, 1 Feb 2023 18:28:04 +0100
"Peter J. Holzer" <hjp-python@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@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.

On Wed, 01 Feb 2023 09:46:29 -0800 (PST)
Grant Edwards <grant.b.edwards@gmail.com> wrote:
>On 2023-02-01, Muttley@dastardlyhq.com <Muttley@dastardlyhq.com> wrote:
>>
>>>No, but it was decided that Python 3 would have to be backwards
>>>incompatible, mainly to sort out the Unicode mess. Given that,
>>>the opportunity was taken to clean up some other mistakes as well.
>>
>> Unicode is just a string of bytes.
>
>No it isn't. Certain _encodings_ of Unicode are strings of bytes
>(UTF-8, for example).

No sane person (or language) uses any other encoding these days.

>> C supports it with a few extra library functions to get unicode
>> length vs byte length and similar. Its really not that
>> hard.
>
>It is, actually.

No it isn't. I wrote some unicode functions in C. Doesn't exactly require
a Mensa IQ to do it.

>> Rewriting an entire language just to support that sounds a bit
>> absurd to me but hey ho...
>
>Feel free to maintain your own fork of 2.7 :)

I get tired of this cretinous response.

"I don't like the styling of new BMWs"

"Feel free to update the old model".

Whatever.

On Thu, 2 Feb 2023 05:22:41 +1100
Chris Angelico <rosuav@gmail.com> wrote:
>On Thu, 2 Feb 2023 at 04:26, <Muttley@dastardlyhq.com> wrote:
>>
>> Its not evolution, its revolution. Evolution retains old functionality.
>>
>
>By the way, I'd like to see your opinions on eternal retention of old
>functionality. Which of these features are you willing to put effort
>into supporting?

Where did I say keep it forever? You deprecate it first THEN eventually
remove it when people have had time to update their code.

At least thats what sensible language authors do.

On Thu, 2 Feb 2023 09:31:46 -0000 (UTC), Muttley wrote:

> 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.

Isn't that prolonging the agony? I had some 2.7 scripts I had to move to
3. It wasn't that painful and I learned the new syntax. Being lazy if they
still worked I would have kept using 2.7 syntax until someday it really
went away.

MS did it big time with VB .NET. I'm sure there still are people
maintaining and extending old-style VB until it ceases to work altogether.
Then they'll be faced with the same learning curve most people suffered
through 20 years ago.

On 2 Feb 2023 15:41:07 GMT
rbowman <bowman@montana.com> wrote:
>On Thu, 2 Feb 2023 09:31:46 -0000 (UTC), Muttley wrote:
>
>
>> 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.
>
>Isn't that prolonging the agony? I had some 2.7 scripts I had to move to

What if its not a few scripts? What if its 10s of thousands of lines of
core production code? If the company it belongs to wants to add new Python 3
features it can't just plug them into the code because it won't run under
Python 3, they have to do a full overhaul or even complete rewrite and that
costs a lot of time and money.

Unfortunately a lot of people who've never worked in large institutions with
huge code bases don't understand this.

>MS did it big time with VB .NET. I'm sure there still are people
>maintaining and extending old-style VB until it ceases to work altogether.

And thats exactly what happened. Clunky old code was kept way beyond its
use by date because rewriting for .NET was simply too much pain.

>Then they'll be faced with the same learning curve most people suffered
>through 20 years ago.

The learning curve is irrelevant, its time and cost that matters.

On Fri, 3 Feb 2023 at 04:48, <Muttley@dastardlyhq.com> wrote:
> 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.

What, you mean Python 2.7 could have continued to be supported until
Python 3.8 (yes, that's not a typo) was released?

It was.

ChrisA

Muttley@dastardlyhq.com wrote:
> On Wed, 1 Feb 2023 18:28:04 +0100
> "Peter J. Holzer" <hjp-python@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@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.

Python 2 *was* retained for X versions of Python 3. From a quick check,
Python 3.0 was released in December 2008 and Python 2 support ended in
January 2020 - by which time Python 3 was up to 3.8 as ChrisA mentioned.
That's about an 11 year transition period, which is hardly sudden!
Python 3 *was* the point at which the features deprecated in Python 2
were removed.

The problem is, a lot seemed to ignore Python 3 for the first 12 years
and then suddenly panic because Python 2 support had ended.

--
Mark.

On 3/02/23 5:09 am, Muttley@dastardlyhq.com wrote:
> What if its 10s of thousands of lines of
> core production code? If the company it belongs to wants to add new Python 3
> features it can't just plug them into the code because it won't run under
> Python 3, they have to do a full overhaul or even complete rewrite and that
> costs a lot of time and money.

A possible strategy in that case would have been to incrementally
rewrite it in such a way that the code would run in both 2.7 and 3.x
(various features were added to 2.7 to make that possible).

When that point is reached, you can then switch to running it with
Python 3 and start using the new features.

Also, if you're a company whose business is totally reliant on some
piece of code, it would be prudent to plan ahead and budget for
rewriting or replacing it at some point.

People seem to think that because code doesn't wear out like
hardware, you don't have to budget for replacing it. But you can't
expect third party software to be maintained forever -- particularly
when, as with Python, the maintenance is mainly being done by
*volunteers*.

--
Greg

On Thu, 2 Feb 2023 16:09:09 -0000 (UTC), Muttley wrote:

> What if its not a few scripts? What if its 10s of thousands of lines of
> core production code? If the company it belongs to wants to add new
> Python 3 features it can't just plug them into the code because it won't
> run under Python 3, they have to do a full overhaul or even complete
> rewrite and that costs a lot of time and money.

Tell me about it... Esri is the 500 pound gorilla in the GIS industry.
They haven't been secretive about their roadmap but the tools people have
been using for almost 20 years are going, going, GONE.

Part of that is their scripting language ArcPy moved to 3.8. It's a minor
inconvenience for me to update some old scripts and to develop with 3 but
a lot of firms have those thousands of lines of code they've developed
over the years in ArcPy for GIS data manipulation.

More painful for me is the C++ API is also gone. Legacy sites have a
couple of more years before it's all over. That leaves me with a foot in
both worlds.

> Unfortunately a lot of people who've never worked in large institutions
> with huge code bases don't understand this.

I don't work in a large company but I deal with about 25 years of legacy
code every day. The core functionality is good but the time and money is
spent putting lipstick on a pig.

Technical debt is an industry wide problem.

On Fri, 3 Feb 2023 05:12:31 +1100
Chris Angelico <rosuav@gmail.com> wrote:
>On Fri, 3 Feb 2023 at 04:48, <Muttley@dastardlyhq.com> wrote:
>> 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.
>
>What, you mean Python 2.7 could have continued to be supported until
>Python 3.8 (yes, that's not a typo) was released?

Thats really useful if you've got 100K line Python 2 codebase and want to
use some Python 3 only features in it isn't it?

On 02/02/2023 09:31, Muttley@dastardlyhq.com wrote:
> On Wed, 1 Feb 2023 18:28:04 +0100
> "Peter J. Holzer" <hjp-python@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@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.
Better a clean break, with Python 2 support continuing for a long time
(as it was).
Best wishes
Rob Cliffe

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

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, Muttley@dastardlyhq.com wrote:
>>> On Wed, 1 Feb 2023 18:28:04 +0100
>>> "Peter J. Holzer" <hjp-python@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@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

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:rosuav@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, Muttley@dastardlyhq.com wrote:
>>> On Wed, 1 Feb 2023 18:28:04 +0100
>>> "Peter J. Holzer" <hjp-python@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@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

On Mon, Jan 30, 2023 at 09:41:03AM -0000, Muttley@dastardlyhq.com wrote:
> >Because print() returns nothing (i.e., the statement x is None is True).
>
> I don't understand this. What was the point of the upheaval of converting
> the print command in python 2 into a function in python 3 if as a function
> print() doesn't return anything useful? Surely even the length of the
> formatted string as per C's sprintf() function would be helpful?

Python is far from the only language that allows functions to return
nothing explicit. Statically typed languages typically use the void
keyword or something similar to indicate this, and dynamically typed
languages often just don't explicitly return anything. [Some
languages, like Perl, just implicitly return the value of the last
expression, or something of the sort, but some do not.] In Pascal, in
fact, there are two different types of subroutines to distinguish
between those things: functions return a value, and procedures do not.
Modern languages commonly don't provide this distinction because by
and large it is unnecessary.

Typically the reason NOT to return a value is that the function is
designed to DO something, rather than to calculate some value.
Examples might be updating the appearance of a UI widget, printing
some information to the screen, or twiddling some bits in a register
(i.e. in-place update of a value). They don't need to return anything
because the "output" is whatever was done. In some languages it might
be typical to return a status indicating success or failure, but in
many languages this is unnecessary; status may be returned via a
parameter provided for the purpose, or in many languages, success can
be assumed, whereas failure will raise an exception.

If it's the case that you simply want to know the length of the string
that will be printed, you can, rather than expecting the I/O function
to tell that to you, figure it out for yourself ahead of time, e.g.
instead of:

username = "John Smith"
job = "Python programmer"

# this doesn't work as desired
len = print(f"{username} has occupation {job}.")
print(len)
...

You would do this instead:

message = f"{username} has the occupation {job}."
message_length = len(message)
print(message)
print(message_length)
...