On 2023-01-28, Chris Green <cl@isbd.net> wrote:

> As far as I am aware the mirroring of the Python mailing list on
> comp.lan.python works perfectly. I love gmane! :-)

If gmane stopped working, I'd have to retire and give up on computers.

I supposed I might be able to hammer procmail and mutt into something
tolerable, but slrn pointed at gmane works wonderfully without any
futzing.

NNTP and newsreaders are designed specifically for the task to which
people have coopted e-mail into via mailing lists.

--
Grant

On 2023-01-28, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> On Sat, 28 Jan 2023 20:07:44 +0000, Chris Green <cl@isbd.net> declaimed the
> following:
>
>
>>As far as I am aware the mirroring of the Python mailing list on
>>comp.lan.python works perfectly. I love gmane! :-)
>
> Is gmane's gmane.comp.python.general allowing posts to go through
> again? I had to revert to comp.lang.python some time back when gmane kept
> rejecting outgoing posts.

No. FWIW, it's the mailing list that's blocking them, not Gmane.

That's why I wrote this:

https://github.com/GrantEdwards/hybrid-inews

It's an inews work-alike that submits most posts via gmanes NNTP
server, but will deal with particular groups
(e.g. gmane.comp.python.general) that want posts submitted via email.

It allows me to continue to read (and post to) the Python mailling
list via slrn pointed at gmane.

It is, of course, written in Python.

On 30/01/2023 09:41, Muttley@dastardlyhq.com wrote:
> On Sun, 29 Jan 2023 23:57:51 -0500
> Thomas Passin <list1@tompassin.net> wrote:
>> On 1/29/2023 4:15 PM, elvis-85792@notatla.org.uk wrote:
>>> On 2023-01-28, Louis Krupp <lkrupp@invalid.pssw.com.invalid> wrote:
>>>> On 1/27/2023 9:37 AM, Muttley@dastardlyhq.com wrote:
>>>
>>>>>>>> eval("print(123)")
>>>>> 123
>>>
>>> Does OP expect the text to come from the eval or from the print?
>>>
>>>>>> x = print( [i for i in range(1, 10)] )
>>> [1, 2, 3, 4, 5, 6, 7, 8, 9]
>>>
>>>>>> x
>>> (nothing printed)
>> 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?
>
That's a fair question, or rather 2 fair questions.
There is an explanation of why the change was made at
    https://snarky.ca/why-print-became-a-function-in-python-3/
In brief: (a) the print() function is more flexible and can be used in
expressions
               (b) Python's syntax was simplified by dropping the
special syntax used by the print statement.
sys.stdout.write() does return the number of characters output (you
could use this instead of print() if you need this;
remember to add a '\n' character at the end of  a line).  I guess the option
of making print() do the same either was not considered, or was
rejected, when print was made a function.
Best wishes
Rob Cliffe

On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
> 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?

It was made a function because there's no good reason for it
to have special syntax in the language.

Functions don't need to return things to justify their existence,
and in fact the usual convention is that functions whose purpose
is to have an effect just return None.

--
Greg

On Tue, 31 Jan 2023 12:57:33 +1300
Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>> 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?
>
>It was made a function because there's no good reason for it
>to have special syntax in the language.

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.

Pragmatism should always come before language purity.

Grant Edwards <grant.b.edwards@gmail.com> writes:

> No. FWIW, it's the mailing list that's blocking them, not Gmane.
>
> That's why I wrote this:
>
> https://github.com/GrantEdwards/hybrid-inews
>
> It's an inews work-alike that submits most posts via gmanes NNTP
> server, but will deal with particular groups
> (e.g. gmane.comp.python.general) that want posts submitted via email.
>
> It allows me to continue to read (and post to) the Python mailling
> list via slrn pointed at gmane.

Interesting. In Gnus it was just a couple of settings to make it
understand that in this group (i.e. gmane group
gmane.comp.python.general) posts and follow-ups should be sent via mail
to the mailing list address.

On 2023-01-31, Anssi Saari <as@sci.fi> wrote:
> Grant Edwards <grant.b.edwards@gmail.com> writes:
>
>> No. FWIW, it's the mailing list that's blocking them, not Gmane.
>>
>> That's why I wrote this:
>>
>> https://github.com/GrantEdwards/hybrid-inews
>>
>> It's an inews work-alike that submits most posts via gmanes NNTP
>> server, but will deal with particular groups
>> (e.g. gmane.comp.python.general) that want posts submitted via email.
>>
>> It allows me to continue to read (and post to) the Python mailling
>> list via slrn pointed at gmane.
>
> Interesting. In Gnus it was just a couple of settings to make it
> understand that in this group (i.e. gmane group
> gmane.comp.python.general) posts and follow-ups should be sent via mail
> to the mailing list address.

Ah, slrn is missing that feature. It will let you e-mail a response
instead of posting a followup (IIRC, you hit 'r' instead of 'f'), but
when you do that it sends the e-mail to the poster rather than to the
list. You can edit the To: header to fix that, but that's too much to
remember. :)

I looked into adding such a feature to slrn, but it was far easier to
switch the slrn setting so that it posted via an external inews
utility instead of the built-in NNTP client. Then all I needed was a
smarter 'inews'. Thanks the the NNTP and SMTP libraries in Python, it
took only 50 lines of Python to implement an external inews utility
that routed postings to either gname via NNTP or list-servers via SMTP
depending on the group.

--
Grant

On 28/01/2023 21:36, Dennis Lee Bieber wrote:

> Now -- last time I checked the gmane server says posting is prohibited.
> I used to use gmane as it retrieved directly from the mailing list

I still use gmane but its no posting thing is a pain because responding
(or posting new stuff) is a now more complicated than before. So
I have to be very highly motivated to jump through the hoops.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

On 1/31/2023 4:24 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 31 Jan 2023 12:57:33 +1300
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>>> 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?
>>
>> It was made a function because there's no good reason for it
>> to have special syntax in the language.
>
> 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.
>
> Pragmatism should always come before language purity.
>

It was more fundamental than that, and not mainly about print():

https://snarky.ca/why-python-3-exists/

On 2023-01-31, Alan Gauld <learn2program@gmail.com> wrote:
> On 28/01/2023 21:36, Dennis Lee Bieber wrote:
>
>> Now -- last time I checked the gmane server says posting is prohibited.
>> I used to use gmane as it retrieved directly from the mailing list
>
> I still use gmane but its no posting thing is a pain because responding
> (or posting new stuff) is a now more complicated than before. So
> I have to be very highly motivated to jump through the hoops.

If your newsreader can post via an external inews utility, you can use
this Python implementation of inews to post to specified groups via
e-mail instead of NNTP:

https://github.com/GrantEdwards/hybrid-inews

Thomas Passin <list1@tompassin.net> writes:
>It was more fundamental than that, and not mainly about print():

That URI is only about the encoding of strings, which does not
help when people try to understand why the function "print" was
introduced.

Something about "print" that I have not yet read in this thread:
Some people say it is a function now so that you can redefine it.

It would still be possible to have a special syntax for the outermost
expression of an expression statement that would allow one to omit
the parentheses, as in VB and VBA.

This is an example written in VBA; user input is not indented or
indented by four spaces; system output is indented by one space.
Note the ultimate user input for a call without parentheses.

|
|Function F( x )
| Debug.Print( x )
| F = Len( x )
|End Function
| |Debug.Print( F( 123 )+ F( 456 ))
| 123
| 456
| 6
| |Debug.Print( F( 123 ))
| 123
| 3
| |Call F( 123 )
| 123
| |F 123
| 123
|

I think its has been discussed here that many functions are DELIBERATELY
designed to return without returning anything. Earlier languages like Pascal
had explicit ideas that a function that did not return a value was declared
as a "procedure" but many other languages like python make no real
differentiation.

Some functions are designed for a sort of side-effect and often there is
nothing much that needs to be returned or even can be. If a function prints
a dozen items one at a time, should it return nothing, or a copy of the last
item or somehow of all items? Generally nothing looks right. If you want to
return something, fine. Do it explicitly.

Similar arguments have been made about methods that do things like sort the
contents of an object internally and then return nothing. Some would like
the return to be the (now altered) object itself. You can emulate that by
not sorting internally but instead sorted(object) returns a new object that
has been sorted from the old one.

So should or could print return anything? Other languages exist, like R,
that do return (and often ignore) whatever print displayed elsewhere. This
can be of use in many ways such as making it easier to print or store
additional copies without recalculating.

My preference might be to simply allow a local option at the end of a print
statement such as print(..., return=True) or even a way to set a global
option so all print statements can be turned on when you want. But is this
pythonic? In particular, people who want to give type hints now can safely
claim it returns None and would have to modify that so it can optionally
return something like str or None. And, of course, once you change print()
this way, someone else will want the number of characters (or perhaps bytes)
returned instead.

Much of this can be worked around by simply making your own customized print
function which evaluates the arguments to make a string and then calls
print, perhaps with the results pre-calculated, and returns what you wanted.
That is not as easy as it sounds, though as print supports various
arguments like sep= and end= and file= and flush= so a weird but doable idea
is simply to substitute a temporary file for any file= argument and write
the results to a temporary file or something in memory that emulates a file.
You can then read that back in and return what you want after handling the
original print statement with the original arguments, or perhaps just use
your result to any actually specified file or the default.

You can thus create something like what you want and leave the original
print() command alone to do what it was designed to do.

And, in general, people who want a copy of what they print, often use other
python functionality to craft some or all parts of the text they want
printed and only then call print() and thus already may have the ability to
use the text afterwards.

For many purposes, including efficiency, returning nothing makes good sense.
But it is not really the only choice or the right choice and yet, if you
want to use THIS language, it has to be accepted as the documented choice.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On
Behalf Of Thomas Passin
Sent: Tuesday, January 31, 2023 1:16 PM
To: python-list@python.org
Subject: Re: evaluation question

On 1/31/2023 4:24 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 31 Jan 2023 12:57:33 +1300
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>>> 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?
>>
>> It was made a function because there's no good reason for it to have
>> special syntax in the language.
>
> 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.
>
> Pragmatism should always come before language purity.
>

It was more fundamental than that, and not mainly about print():

https://snarky.ca/why-python-3-exists/
--
https://mail.python.org/mailman/listinfo/python-list

Greg Ewing wrote:
> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>> 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?
>
> It was made a function because there's no good reason for it
> to have special syntax in the language.

I think I saw somewhere that making print a function also had something
to do with being able to add extra keyword arguments like sep and end.
The syntax for printing to a specific file already seemed a bit odd with
the print statement, and adding extra arguments would have made it even
more clunky (yeah, I know ">>" is similar to C++ streams, but it looks
out of place in Python).

They couldn't fully make the change from print statement to print
function without breaking backward compatibility for existing code. But
there were other breaking changes being made in Python 3 anyway, so may
as well sort print out while at it and have all the breaking changes at
once.

> Functions don't need to return things to justify their existence,
> and in fact the usual convention is that functions whose purpose
> is to have an effect just return None.

--
Mark.

import io

def countprint(*args, **kwargs):
capturekw = {k:v for k,v in kwargs.items() if k != 'file'}
buffer = io.StringIO()
capturekw['file'] = buffer
print(*args,**kwargs)
print(*args,**capturekw)
return len(buffer.getvalue())

def boolprint(*args,active:bool, **kwargs):
if active:
print(*args,**kwargs)

with open("text.txt",'w') as f:
y = countprint(1, 3, 3, sep=',', end='\n\n',file=f)
print(y)
boolprint(3,4,5,sep='/',active=True)
boolprint(7,11,active=False)

From: Python-list <python-list-bounces+gweatherby=uchc.edu@python.org> on behalf of avi.e.gross@gmail.com <avi.e.gross@gmail.com>
Date: Tuesday, January 31, 2023 at 3:01 PM
To: 'Thomas Passin' <list1@tompassin.net>, python-list@python.org <python-list@python.org>
Subject: RE: evaluation question
*** Attention: This is an external email. Use caution responding, opening attachments or clicking on links. ***

I think its has been discussed here that many functions are DELIBERATELY
designed to return without returning anything. Earlier languages like Pascal
had explicit ideas that a function that did not return a value was declared
as a "procedure" but many other languages like python make no real
differentiation.

Some functions are designed for a sort of side-effect and often there is
nothing much that needs to be returned or even can be. If a function prints
a dozen items one at a time, should it return nothing, or a copy of the last
item or somehow of all items? Generally nothing looks right. If you want to
return something, fine. Do it explicitly.

Similar arguments have been made about methods that do things like sort the
contents of an object internally and then return nothing. Some would like
the return to be the (now altered) object itself. You can emulate that by
not sorting internally but instead sorted(object) returns a new object that
has been sorted from the old one.

So should or could print return anything? Other languages exist, like R,
that do return (and often ignore) whatever print displayed elsewhere. This
can be of use in many ways such as making it easier to print or store
additional copies without recalculating.

My preference might be to simply allow a local option at the end of a print
statement such as print(..., return=True) or even a way to set a global
option so all print statements can be turned on when you want. But is this
pythonic? In particular, people who want to give type hints now can safely
claim it returns None and would have to modify that so it can optionally
return something like str or None. And, of course, once you change print()
this way, someone else will want the number of characters (or perhaps bytes)
returned instead.

Much of this can be worked around by simply making your own customized print
function which evaluates the arguments to make a string and then calls
print, perhaps with the results pre-calculated, and returns what you wanted..
That is not as easy as it sounds, though as print supports various
arguments like sep= and end= and file= and flush= so a weird but doable idea
is simply to substitute a temporary file for any file= argument and write
the results to a temporary file or something in memory that emulates a file..
You can then read that back in and return what you want after handling the
original print statement with the original arguments, or perhaps just use
your result to any actually specified file or the default.

You can thus create something like what you want and leave the original
print() command alone to do what it was designed to do.

And, in general, people who want a copy of what they print, often use other
python functionality to craft some or all parts of the text they want
printed and only then call print() and thus already may have the ability to
use the text afterwards.

For many purposes, including efficiency, returning nothing makes good sense..
But it is not really the only choice or the right choice and yet, if you
want to use THIS language, it has to be accepted as the documented choice.

-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com@python.org> On
Behalf Of Thomas Passin
Sent: Tuesday, January 31, 2023 1:16 PM
To: python-list@python.org
Subject: Re: evaluation question

On 1/31/2023 4:24 AM, Muttley@dastardlyhq.com wrote:
> On Tue, 31 Jan 2023 12:57:33 +1300
> Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
>> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>>> 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?
>>
>> It was made a function because there's no good reason for it to have
>> special syntax in the language.
>
> 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.
>
> Pragmatism should always come before language purity.
>

It was more fundamental than that, and not mainly about print():

https://urldefense.com/v3/__https://snarky.ca/why-python-3-exists/__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yGhlD2rfk$<https://urldefense.com/v3/__https:/snarky.ca/why-python-3-exists/__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yGhlD2rfk$>
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yG5f0h2No$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yG5f0h2No$>

--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yG5f0h2No$<https://urldefense.com/v3/__https:/mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!ldtLZeCkbC0gawIJRrbrunA0AqA_btcJ9M1TOlajHrezsXh5AqpuLFCg1mITKq8qvR8f3u-d8K2WF9yG5f0h2No$>

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.

--
Greg

On 1/02/23 7:33 am, Stefan Ram wrote:
> Thomas Passin <list1@tompassin.net> writes:

> Some people say it is a function now so that you can redefine it.

Well, that's one benefit, but I wouldn't say it's the main one.

The point is really that you can do *anything* with it now that
you can do with a regular function -- pass it as an argument,
wrap it with another function, define your own function with a
similar signature for duck-typing purposes, etc.

> It would still be possible to have a special syntax for the outermost
> expression of an expression statement that would allow one to omit
> the parentheses,

That's only one of the syntactic oddities of the old print
statement, thogh. There was also the >> thing, special treatment
of trailing commas, etc.

Also, introducing a paren-less call syntax would be a very big
and controversial change that would be way out of proportion to
the problem.

--
Greg

On Wed, 1 Feb 2023 at 10:47, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
> That's only one of the syntactic oddities of the old print
> statement, thogh. There was also the >> thing, special treatment
> of trailing commas, etc.

"Soft space" (the trailing comma behaviour) was an incredibly complex
wart. Glad it's gone.

> Also, introducing a paren-less call syntax would be a very big
> and controversial change that would be way out of proportion to
> the problem.

Oddly enough, that WAS actually proposed recently - by Guido himself -
as a demonstration of the power of the new PEG parser:

https://mail.python.org/archives/list/python-ideas@python.org/thread/NCQX6ZIBREUTLS52VVG3DSZ43OEXJFTT/

(The mailing list archive messes up formatting a bit with REPL
transcripts, thinking they're quoted text.)

The general consensus was "allowing function calls without parens
causes more issues than it solves", with plenty of examples from other
programming languages to prove this - Ruby, while generally a decent
language, shows a rather nasty wart with this particular feature (see
"Ruby allows parens-less function calls" from Steven D'Aprano in that
thread). I don't think it'll ever happen in Python, but it's nice to
know that the parser is flexible enough. It means that other weird
cases, where the intuitive expectation is different, can be better
handled (see eg "with (x as y, a as b):" syntax).

Having print as a function is WAY better than having it as a special
case with lots of warts. And it's so much easier to add extra features
to it; for instance, how would you add a "flush after printing" flag
to Py2's print statement? With a function, it's easy - just print(...,
flush=True).

ChrisA

On 1/31/2023 6:18 PM, Greg Ewing wrote:
> On 1/02/23 7:33 am, Stefan Ram wrote:
>> Thomas Passin <list1@tompassin.net> writes:
>
>>    Some people say it is a function now so that you can redefine it.

Hmm, I didn't write these quotes. Maybe someone got confused by the
depth of the nested replies in this thread. Easy enough to do.

> Well, that's one benefit, but I wouldn't say it's the main one.
>
> The point is really that you can do *anything* with it now that
> you can do with a regular function -- pass it as an argument,
> wrap it with another function, define your own function with a
> similar signature for duck-typing purposes, etc.
>
>>    It would still be possible to have a special syntax for the outermost
>>    expression of an expression statement that would allow one to omit
>>    the parentheses,
>
> That's only one of the syntactic oddities of the old print
> statement, thogh. There was also the >> thing, special treatment
> of trailing commas, etc.
>
> Also, introducing a paren-less call syntax would be a very big
> and controversial change that would be way out of proportion to
> the problem.
>

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.

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
realise that it has become dated or inflexible, and have to learn a new,
replacement, language!

--
Regards,
=dn

Thomas Passin <list1@tompassin.net> writes:
>On 1/31/2023 6:18 PM, Greg Ewing wrote:
>> On 1/02/23 7:33 am, Stefan Ram wrote:
>>> Thomas Passin <list1@tompassin.net> writes:
>>
>>>    Some people say it is a function now so that you can redefine it.

>Hmm, I didn't write these quotes. Maybe someone got confused by the
>depth of the nested replies in this thread. Easy enough to do.

Above, ">>> Thomas Passin <list1@tompassin.net> writes:" with three
greater signs means that anything that follows with four greater
signs was written by you. Nothing follows with four greater signs.
So it is not claimed that you wrote anything!

On 1/02/23 1:17 pm, dn wrote:
> 1 nothing "ceased to execute" and Python 2 was maintained and developed
> for quite some time and in-parallel to many Python 3 releases.

And a lot of effort was put into making the transition as easy
as possible, e.g. 2to3, and the features added to 2.7 to make
it easier to write code that would work in both versions.

--
Greg

On 2023-01-31, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:

> That's only one of the syntactic oddities of the old print
> statement, thogh. There was also the >> thing, special treatment
> of trailing commas, etc.

In "old" Python I used to use the trailing comma extensively, but I
could never get myself to use the >> thing. I don't know why, but it
just felt wrong.

--
Grant

On Tue, 31 Jan 2023 21:00:53 +0000
Mark Bourne <nntp.mbourne@spamgourmet.com> wrote:
>Greg Ewing wrote:
>> On 30/01/23 10:41 pm, Muttley@dastardlyhq.com wrote:
>>> 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?
>>
>> It was made a function because there's no good reason for it
>> to have special syntax in the language.
>
>I think I saw somewhere that making print a function also had something
>to do with being able to add extra keyword arguments like sep and end.
>The syntax for printing to a specific file already seemed a bit odd with
>the print statement, and adding extra arguments would have made it even
>more clunky (yeah, I know ">>" is similar to C++ streams, but it looks
>out of place in Python).

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

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

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.