NoneType List

[Goran Ikac]

Thank you, guys, thank you very much!
I'm amazed by the time and effort so many of you have put into the answers.
And at this time of year!
Not only is the issue clear to me now, but I learned a lot (and I'm still
to learn a lot more) from your answers and the links you provided. And not
only about the issue that bothered me when I wrote the question!
I've read many times that one of the main features of Python was the large
community ready to help and discuss. Well, I'm just beginning to see the
true meaning of that, and I'm - well - amazed.
Thanks, guys, and Happy New Year!

ned, 1. sij 2023. u 19:17 <avi.e.gross at gmail.com> napisao je:

> Several of you have mentioned the role of history in the development of
> languages and what the founders of a language were trying to improve.
>
> As noted with PASCAL, some earlier languages strived to be different things
> and in a certain sense, their procedures were perhaps seen as a safer and
> better way to do things that languages like BASIC hade done with a GOSUB.
> On
> top of that, there were concerns in a compiled language such as not leaving
> an unused result on the stack when a function returned and even efficiency
> considerations of several kinds. If a function returns a value, that value
> has to persist beyond the lifetime of the function. It has to be in a kind
> of memory different than where you can store values that go away. In a
> procedure call, the compiler could use the fact that nothing is returned
> other than through external variables.
>
> As noted, Guido started various languages, including Python, in a
> historical
> context where he was not yet seeing things as "objects" in the way we often
> do now. And he was trying to avoid some features often used in languages
> like C for various reasons while keeping or extending others. I am not sure
> about timing, but there have been many debates in the field about things
> like programming without side effects and some insist that changing things
> IN PLACE is a poor way to do things and instead things should be copied
> when
> modified and so on.
>
> So it well may be that allowing an inline sort or addition to a list was
> added carefully in a way that made it very clear what you were doing and
> seeing it more as a procedure call than a function that returned a value of
> itself as Stefan points out.
>
> But Python evolved and keeps evolving and like many biological organisms,
> to
> some extent, ontogeny recapitulates phylogeny. It is really hard to get rid
> of some early design choices even when a brand new design might allow a
> cleaner design with more advantages. Python is becoming more like other
> languages as it borrows from them and they borrow from it, and all borrow
> or
> adapt from yet others. The result, frankly, can be a tad hard to understand
> as the languages both converge and diverge only to converge again and some
> simply go extinct or get totally re-done to adapt ...
>
> -----Original Message-----
> From: Python-list <python-list-bounces+avi.e.gross=gmail.com at python.org>
> On
> Behalf Of Stefan Ram
> Sent: Sunday, January 1, 2023 8:47 AM
> To: python-list at python.org
> Subject: Re: NoneType List
>
> Thomas Passin <list1 at tompassin.net> writes:
> >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.
>
>   In those days, there used to be a language called "Pascal".
>   Pascal had a dichotomy between "functions" and "procedures".
>   A call to a function was intended to have a value.
>   A call to a procedure was intended to have an effect.
>
>   For some beginners, the difference between a value and
>   and effect can be hard to grasp. So, Pascal's distinction
>   helps to hammer that home.
>
>   Experienced programmers know the difference and do no longer
>   require the effort of the language to teach it to them.
>
>   The time when someone is a beginner and still struggles
>   to understand the difference between values and effects
>   usually is significantly shorter than the later time
>   where he has understood it and is programming productively,
>   so it might be better when the language is adapted to
>   people who already have understood the difference.
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
> --
> https://mail.python.org/mailman/listinfo/python-list
>