NoneType List

Thomas Passin list1 at tompassin.net
Sun Jan 1 08:11:02 EST 2023


On 12/31/2022 10:17 PM, avi.e.gross at gmail.com wrote:
> 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.

Guido had been working on the ABC language for some years before he 
developed Python.  ABC was intended mainly as a teaching and prototyping 
language.  Guido probably had a good sense of what things worked well 
and what didn't in that usage.  IIRC, Python did not originally have 
classes or instances, and a "fluent" style of programming probably 
wasn't in use yet. Having an object return itself after an operation is 
useful (mostly, perhaps) for fluent programming (that is, the style 
where one can write X.method1().method2().method3() ...).

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



More information about the Python-list mailing list