Mailing List Archive

1 2 3  View All
Re: evaluation question [ In reply to ]
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...


--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Wed, 1 Feb 2023 13:17:33 +1300
dn <PythonList@DancesWithMice.info> wrote:
>On 01/02/2023 11.59, Greg Ewing 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.
>
>+1
>and the move to Unicode has opened-up the Python community beyond the
>US, to embrace 'the world' - a proposition (still) not well-recognised
>by (only) English-speakers/writers/readers.
>
>
>Even though the proposition has a troll-bait smell to it:-
>
>1 nothing "ceased to execute" and Python 2 was maintained and developed
>for quite some time and in-parallel to many Python 3 releases.

MacOS only comes with python3 now. If you have a whole load of python2 code
you want to run you now have to manually install python2 yourself.

>2 the only constant in this business is 'change'. I'd rather cope with
>an evolution in this language (which we know and love), than one day

Its not evolution, its revolution. Evolution retains old functionality.

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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>

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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!"
Re: evaluation question [ In reply to ]
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.
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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...


--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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.

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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.

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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.
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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.
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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.

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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
RE: evaluation question [ In reply to ]
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

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
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)
...

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Sat, 11 Feb 2023 at 07:36, Python <python@bladeshadow.org> wrote:
> 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)
> ...
>

It's worth noting WHY output functions often return a byte count. It's
primarily for use with nonblocking I/O, with something like this:

buffer = b".............."
buffer = buffer[os.write(fd, buffer):]

It's extremely important to be able to do this sort of thing, but not
with the print function, which has a quite different job.

ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On Sat, Feb 11, 2023 at 08:30:22AM +1100, Chris Angelico wrote:
> On Sat, 11 Feb 2023 at 07:36, Python <python@bladeshadow.org> wrote:
> > You would do this instead:
> >
> > message = f"{username} has the occupation {job}."
> > message_length = len(message)
> > print(message)
> > print(message_length)
> > ...
> >
>
> It's worth noting WHY output functions often return a byte count. It's
> primarily for use with nonblocking I/O, with something like this:
>
> buffer = b".............."
> buffer = buffer[os.write(fd, buffer):]
>
> It's extremely important to be able to do this sort of thing, but not
> with the print function, which has a quite different job.

I would agree with this only partially. Your case applies to
os.write(), which is essentially just a wrapper around the write()
system call, which has that sort of property... though it applies also
to I/O in blocking mode, particularly on network sockets, where the
number of bytes you asked to write (or read) may not all have been
transferred, necessitating trying in a loop.

However, Python's print() function is more analogous to C's printf(),
which returns the number of characters converted for an entirely
different reason... It's precisely so that you'll know what the length
of the string that was converted is. This is most useful with the
*snprintf() variants where you're actually concerned about overrunning
the buffer you've provided for the output string, so you can realloc()
the buffer if it was indeed too small, but it is also useful in the
context of, say, a routine to format text according to the size of
your terminal. In that context it really has nothing to do with
blocking I/O or socket behavior.

--
https://mail.python.org/mailman/listinfo/python-list
Re: evaluation question [ In reply to ]
On 2/10/2023 4:55 PM, Python wrote:
> However, Python's print() function is more analogous to C's printf(),
> which returns the number of characters converted for an entirely
> different reason... It's precisely so that you'll know what the length
> of the string that was converted is. This is most useful with the
> *snprintf() variants where you're actually concerned about overrunning
> the buffer you've provided for the output string, so you can realloc()
> the buffer if it was indeed too small, but it is also useful in the
> context of, say, a routine to format text according to the size of
> your terminal. In that context it really has nothing to do with
> blocking I/O or socket behavior.

But none of that applies to the Python print() function. There are no
buffers to overrun, no reason to know the length of the printed string,
no re-allocating of a buffer. It's certainly possible that one might
want to know the actual physical length of a displayed string - perhaps
to display it on a graphic - but now we're getting into font metrics and
such things, and we'll be doing something more active than displaying on
a terminal via stdout.

I don't know why the print() function doesn't return anything, but I'm
fine with it. I've never felt that I needed to know.
--
https://mail.python.org/mailman/listinfo/python-list

1 2 3  View All