Re: NoneType List
On 12/31/2022 10:17 PM, [email protected] 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 On Behalf Of Greg Ewing Sent: Saturday, December 31, 2022 7:21 PM To: [email protected] Subject: Re: NoneType List On 1/01/23 11:36 am, [email protected] 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 -- https://mail.python.org/mailman/listinfo/python-list
NoneType List
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! -- https://mail.python.org/mailman/listinfo/python-list
Re: Possible re bug when using ".*"
On 2022-12-28 19:07:06 +, MRAB wrote:
> On 2022-12-28 18:42, Alexander Richert - NOAA Affiliate via Python-list
> wrote:
> > print(re.sub(".*", "replacement", "pattern"))
> > yields the output "replacementreplacement".
[...]
> It's not a bug, it's a change in behaviour to bring it more into line with
> other regex implementations in other languages.
Interesting. Perl does indeed behave that way, too. Never noticed that
in 28 years of using it.
hp
--
_ | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| | | [email protected] |-- Charles Stross, "Creative writing
__/ | http://www.hjp.at/ | challenge!"
signature.asc
Description: PGP signature
--
https://mail.python.org/mailman/listinfo/python-list
Re: NoneType List
On 1/1/2023 8:47 AM, Stefan Ram wrote: Thomas Passin 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. Wirth developed Pascal as a teaching language. IIRC, originally it was taught to students before there were any implementations. I did most of my programming with Turbo Pascal for many years. Just to clarify what you wrote above, in Pascal a "procedure" does not return anything while a "function" does. I really liked (Turbo) Pascal and I hated C back then. No wonder I like Python so much. It must be something about how my mind works. 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
RE: NoneType List
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 On Behalf Of Stefan Ram Sent: Sunday, January 1, 2023 8:47 AM To: [email protected] Subject: Re: NoneType List Thomas Passin 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
Re: NoneType List
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 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 > On > Behalf Of Stefan Ram > Sent: Sunday, January 1, 2023 8:47 AM > To: [email protected] > Subject: Re: NoneType List > > Thomas Passin 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 > -- https://mail.python.org/mailman/listinfo/python-list
RE: NoneType List
Thomas, I used PASCAL before C and I felt like I was wearing a straitjacket at times in PASCAL when I was trying to write encryption/decryption functions and had to find ways to fiddle with bits. Similar things were easy in C, and are even easier in many more recent languages such as Python. The distinction between teaching a first language, or one that is so cautious as to catch and prevent all mistakes it can, is not for people willing to be bolder or work faster or write routines that can be used more generally. What has not been mentioned is that languages like python go a step further and allow a function to return many arguments and even a varying number of arguments, as well as none at all. To do anything like that in PASCAL took some thought on how to make some structure you could fill out then return as a single value that the receiving code had to sort of decode and perhaps deal with parts that could hold a union of several things. Can a compiler or interpreter easily verify you did something reasonable, as compared to say python that allows something like: (res1, res2, _, res4, _, rest) = f(x) The above tells the interpreter you expect perhaps 6 or more results and what to do with them. -Original Message- From: Python-list On Behalf Of Thomas Passin Sent: Sunday, January 1, 2023 1:03 PM To: [email protected] Subject: Re: NoneType List On 1/1/2023 8:47 AM, Stefan Ram wrote: > Thomas Passin 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. Wirth developed Pascal as a teaching language. IIRC, originally it was taught to students before there were any implementations. I did most of my programming with Turbo Pascal for many years. Just to clarify what you wrote above, in Pascal a "procedure" does not return anything while a "function" does. I really liked (Turbo) Pascal and I hated C back then. No wonder I like Python so much. It must be something about how my mind works. >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
Re: Python-list Digest, Vol 232, Issue 1
Re: Nonetype List In my introductory programming course, I have drawn some attention to this behavior regarding mutating lists. Indeed, Python is very consistent with its behavior: Any function that mutates a list parameter does not return that list as a return value. For one thing, there is no need to return that value, because the caller still owns the list parameter that has been modified. But secondly, (and what I find especially important), is that returning the modified list would lead too many program bugs or misunderstandings. For example, if append did return the list, you might see this: x = [1,2,3] y = x.append(4) z = y.append(5) The principal of 'least surprise' would cause a casual reader to believe that x retains the value of [1,2,3], y would have the value of [1,2,3,4], and z would contain [1,2,3,4,5]. So it would be very surprising indeed to discover that x contains [1,2,3,4,5], especially after that statement that makes no reference to x. Since append modifies the list in place, returning that list would make x, y, and z all aliases of each other, and aliasing is a source of many bugs that are very hard to find. So a recommendation that I make to my class (and which coincides with Python behavior), is to NEVER return a modified list as a return value, but only to return lists that were newly created within the function. So to support this principal of 'least surprise', the append method above would necessarily create new lists for y and z that are not aliases to x. Why Python does not do that is a very obvious cases of run-time efficiency (constant time to append vs. linear to recreate a new list). And as another observation, I have my students review all of the methods defined for the list object, and they are all very consistent. Most of them either define a return value, or modify the list parameter, but almost none do both. The sole exception is the pop() function that modified a list and returns a value, but that returned value still is not the modified list, so the aliasing problem will never arise. So, I am very happy with this Python language decision -- it allows for the most efficient means to modify a list in place and also very much reduce the danger of aliasing bugs. Roger Christman Pennsylvania State University From: Python-list on behalf of [email protected] Sent: Sunday, January 1, 2023 12:00 PM To: [email protected] Subject: Python-list Digest, Vol 232, Issue 1 Send Python-list mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-list&data=05%7C01%7Cdvl%40psu.edu%7C744c83fc485a4b1c79db08daec19a436%7C7cf48d453ddb4389a9c1c115526eb52e%7C0%7C0%7C638081892123929669%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=etYqO01OszhEpqgjLeKQTMC9b3wT0sc%2FcN8oJo9eEhk%3D&reserved=0 or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Python-list digest..." Today's Topics: 1. Re: NoneType List (Thomas Passin) 2. Re: NoneType List (MRAB) 3. Re: NoneType List (dn) 4. RE: NoneType List ([email protected]) 5. Re: NoneType List (Thomas Passin) 6. Re: NoneType List (Greg Ewing) 7. RE: NoneType List ([email protected]) 8. Re: NoneType List (Chris Angelico) 9. RE: NoneType List ([email protected]) 10. Re: NoneType List (Chris Angelico) 11. Re: NoneType List (Thomas Passin) -- Message: 1 Date: Sat, 31 Dec 2022 12:07:25 -0500 From: Thomas Passin To: [email protected] Subject: Re: NoneType List Message-ID: <[email protected]> Content-Type: text/plain; charset=UTF-8; format=flowed Oops, my reply got lost somehow. Here it is: Everyone's answer to date has been too complicated. What is going on is that list.append() changes the list in place. It returns nothing. If you want to append an item and then assign the result to a new list, you have to do just that: l1.append(item) # If we want a *copy* of the appended list: l2 = l1[:] # Changes to l2 will not change l1 # If we want another name for the appended list: l2 = l1 # Changes to l2 will change l1 since they are the same object list.sort() also operates in place. There is a function sorted() that returns the sorted list (without changing the original list). The same thing is true of set.add(). The set is changed in place, and nothing is returned. On 12/31/2022 10:50 AM, Thomas Passin wrote: > Happy New Year, everybody! >
Re: NoneType List
On 1/1/2023 9:14 PM, [email protected] wrote: Thomas, I used PASCAL before C and I felt like I was wearing a straitjacket at times in PASCAL when I was trying to write encryption/decryption functions and had to find ways to fiddle with bits. Similar things were easy in C, and are even easier in many more recent languages such as Python. PASCAL was not the first language I learned. I won't pretend I had to do anything very complicated, or do much bit-twiddling. It was, though, the first one (except probably for FORTH) I enjoyed programming with more than I disliked the boiler-plate formalities. The distinction between teaching a first language, or one that is so cautious as to catch and prevent all mistakes it can, is not for people willing to be bolder or work faster or write routines that can be used more generally. What has not been mentioned is that languages like python go a step further and allow a function to return many arguments and even a varying number of arguments, as well as none at all. To do anything like that in PASCAL (or C, for that matter) took some thought on how to make some structure you could fill out then return as a single value that the receiving code had to sort of decode and perhaps deal with parts that could hold a union of several things. Can a compiler or interpreter easily verify you did something reasonable, as compared to say python that allows something like: (res1, res2, _, res4, _, rest) = f(x) Yes, that's one of the good things about Python, how it makes working with tuples so easy and natural. OTOH, harking back to PASCAL for a minute, it had enumerations and sets long before Python got them. The above tells the interpreter you expect perhaps 6 or more results and what to do with them. -Original Message- From: Python-list On Behalf Of Thomas Passin Sent: Sunday, January 1, 2023 1:03 PM To: [email protected] Subject: Re: NoneType List On 1/1/2023 8:47 AM, Stefan Ram wrote: Thomas Passin 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. Wirth developed Pascal as a teaching language. IIRC, originally it was taught to students before there were any implementations. I did most of my programming with Turbo Pascal for many years. Just to clarify what you wrote above, in Pascal a "procedure" does not return anything while a "function" does. I really liked (Turbo) Pascal and I hated C back then. No wonder I like Python so much. It must be something about how my mind works. 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
RE: NoneType List
Not to wax poetic about our pasts, Thomas, but I do did not start with PASCAL and used quite a few languages before and plenty after. At the time it had interesting contrasts to languages like BASIC, FORTRAN and LISP and I tended to use whatever was available on the machines I was using. My first computer job (other than in grad school itself) was using OMSI PASCAL. I even wrote my thesis as a PASCAL program containing comments that included typesetting instructions in a language called RUNOFF while the PASCAL program itself was a set of comments as far as RUNOFF was concerned. So it compiled or was typeset and printed from the same source. But my next job after graduation was for Bell Labs and I had to forget all the mainframe or DEC systems and adapt to UNIX, and of course C and later C++ and the various other little languages that came with that such as AWK and PERL ... There is no one right language but there often is a small set of right languages given your circumstances, such as what your employer has everyone using and especially in group projects. To be fair, languages like Python and R seem to keep having parts rewritten in C or C++ to make some things run faster and can include libraries written ages ago in languages like FORTRAN that have been finely tuned. Under the hood, these languages often hide parts so that developing a new python (or R or ...) module/package can start by writing it all in that language and then taking some functionality and rewriting it in the other language for critical regions where a slower interpreted method may be speeded up. But for prototyping, or when speed is not a big deal, I really prefer Python to ... -Original Message- From: Python-list On Behalf Of Thomas Passin Sent: Sunday, January 1, 2023 10:15 PM To: [email protected] Subject: Re: NoneType List On 1/1/2023 9:14 PM, [email protected] wrote: > Thomas, > > I used PASCAL before C and I felt like I was wearing a straitjacket at > times in PASCAL when I was trying to write encryption/decryption > functions and had to find ways to fiddle with bits. Similar things > were easy in C, and are even easier in many more recent languages such > as Python. PASCAL was not the first language I learned. I won't pretend I had to do anything very complicated, or do much bit-twiddling. It was, though, the first one (except probably for FORTH) I enjoyed programming with more than I disliked the boiler-plate formalities. > The distinction between teaching a first language, or one that is so > cautious as to catch and prevent all mistakes it can, is not for > people willing to be bolder or work faster or write routines that can > be used more generally. > > What has not been mentioned is that languages like python go a step > further and allow a function to return many arguments and even a > varying number of arguments, as well as none at all. To do anything > like that in PASCAL (or C, for that matter) > took some thought on how to make some structure you could fill out > then return as a single value that the receiving code had to sort of > decode and perhaps deal with parts that could hold a union of several > things. Can a compiler or interpreter easily verify you did something > reasonable, as compared to say python that allows something like: > > (res1, res2, _, res4, _, rest) = f(x) Yes, that's one of the good things about Python, how it makes working with tuples so easy and natural. OTOH, harking back to PASCAL for a minute, it had enumerations and sets long before Python got them. > The above tells the interpreter you expect perhaps 6 or more results > and what to do with them. > > > > -Original Message- From: Python-list > On Behalf Of > Thomas Passin Sent: Sunday, January 1, 2023 1:03 PM To: > [email protected] Subject: Re: NoneType List > > On 1/1/2023 8:47 AM, Stefan Ram wrote: >> Thomas Passin 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. > > Wirth developed Pascal as a teaching language. IIRC, originally it was > taught to students before there were any implementations. I did most > of my programming with Turbo Pascal for many years. Just to clarify > what you wrote above, in Pascal a "procedure" does not return anything > while a "function" does. > > I really liked (Turbo) Pascal and I hated C back then. No wonder I > like Python so much. It must be something about how my mind works. > >> 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 kno
