NoneType List

[avi.e.gross at gmail.com]

Agreed, there are lots of pro/con arguments and the feature is what it  is
historically and not trivial to change. Inline changes to an object make
sense to just be done "silently" and if there are errors, they propagate the
usual way.

As Guido was a major influence at that time,  one view was seen as more
important and prevailed.

Had a language like that been created today, I wonder if some designs might
have looked a bit different so that some functions could be called with
optional arguments that specified what the user wanted returned.

In particular, besides a function where you add a value returning
nothing/None, there may be room for other choices and any choice hard-wired
in would eleicit complaints from others.

lst.add("Value") 

could also return one of several other things such as a pointer to the
upgraded object but also of  a pointer to the object as it looked before the
change (not a serious proposal) or a True/False value specifying if the
change was able to be completed (such as running out of memory, or the
addition not being something you can put in the object) or even return what
was added or how many objects are now in the object at the top level, or how
many times the method was called so far!

I suspect, at the expense of some overhead, you could just add an argument
to many kinds of methods or even functions such as returning='option' that
guides what you want returned, with the default often being what Guido and
others currently have set.

Python already allows functions to return anything they feel like, so this
probably would not break many things.

Of course there are other paths in that direction, such as setting an
attribute of the list/object first that affects how things get returned but
that seems more cumbersome and makes all kinds of errors more likely. Still,
that is a path often used by some Python modules where objects are created
and then tweaked to behave in various ways when later methods are invoked.

But is any of it needed? The current system generally works fine and we have
seen many ways to get other results without tampering with the current
implementation.

This may be yet another example of people who come to python with
pre-existing bias, such as insisting it work like another language they have
used, or wanting the computer to do what they MEANT rather than what they
explicitly or implicitly programmed!


-----Original Message-----
From: Python-list <python-list-bounces+avi.e.gross=gmail.com at python.org> On
Behalf Of Greg Ewing
Sent: Saturday, December 31, 2022 7:21 PM
To: python-list at python.org
Subject: Re: NoneType List

On 1/01/23 11:36 am, avi.e.gross at gmail.com wrote:
> And, of course, we had the philosophical question of why the feature 
> was designed to not return anything ... rather than return the changed 
> object.

My understanding is that Guido designed it that way to keep a clear
separation between mutating and non-mutating methods, and to help catch
mistakes resulting from mixing them up.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list