On Fri, 15 Jun 2012, Terry Reedy wrote: > On 6/15/2012 1:03 PM, Tomasz Rola wrote: > > > Last time I checked, Python didn't have linked lists - arrayed lists are > > nice, but their elements can't be automatically GC-ed (or, this requires > > very nontrivial GC algorithm), the easiest way I can think would be > > replacing them with None manually. I'm not sure if del is > > performance-nice. > > Python does not come with a linked-list class, but one can easily use tuples > or lists with two items as linked-list cells. One can optionally wrap such > cell in a linked-list class. However, if array lists do the job, which they > usually do, using linked-lists will take more time and space. The problem > being discussed may be a case where they are useful and make it easier to save > space.
Yes. I made linked lists in Python few years ago, just to test something. At the time Python was my main algorithmic toy, so I couldn't resist. However, handling the list felt half Pascal-y and half unnatural. Later on, I felt I didn't like cramming everything into arrays and switched to something else. > > Also, around the same time, Python couldn't do tail-call, > > Nonsense. A tail call is a call temporally followed by a return. In CPython > bytecode, it would be a call followed by return. In Python code, it is a call > spatially preceded by 'return'. Any "return f(whatever)", a common operation > is a tail call. Actually I was wrong. http://code.activestate.com/recipes/474088-tail-call-optimization-decorator/ Now I am intrigued because this code just worked a minute ago, on 2.6. Given this was written for 2.4, I was wrong. Definitely something I would like to experiment with a bit. The need for adding decorator takes some joy away but it is interesting. > In practice, should_loop, A, and B will usually be in-line expressions rather > than calls. There may be additional statements after if, else, and while > headers. In while_equiv, move b=start into the body. Else is typically omitted > from the while version, but I prefer it in the recursive version. You see, I spend quite a lot of time playing with concepts etc. Code performance is nice to have, but I prefer to maximize my performance as I write something and move on. If I feel (from my own point of view) something would be nicer to write with recursion, so be it - even though some Common Lisp manual advises to use loops because they are faster. Actually, from what I have tested, this not always is true - both recursion and loops were comparable speed wise in some simple cases I checked. This manual is a bit old, and new compiler had its own say about optimisation, maybe that's the truth behind it. For cases where I really want speed, proper algorithm (if only I can think it) and compilation rule. If algorithm codes better with loops, this is ok. But if it codes better with recursion, this should be ok too, because if I feel better while coding it, I make less errors. > > Even more cool, with lazy evaluation (like in Haskell) one can generate > > lists on a fly and process them like they were statically allocated. > > Python iterators can do lazy evaluation. All the builtin classes come with a > corresponding iterator. This is fine, but I don't mind having more, like the whole language supporting the idea of being lazy. http://stackoverflow.com/questions/265392/why-is-lazy-evaluation-useful > > Yes, you could also run it in a loop or simulate lazy-eval manually (with > > yield) > > There is nothing simulated about yield. Yes, yield is real and not simulated. And one can use it to do tricks with how/when Python evaluates/generates/performs. It is nicer than if I had to write lazy code in, say, C or Pascal, but it doesn't mean one should only use one language rather than choose language according to the task, > Python mostly does what you tell it to do. You just have to learn how to > tell it to do what you want. Well I believe I have already learnt some of it. I am not using Python on a daily basis nowadays, and I am stuck somewhere in 2.x land. To stay in this semicurrent state I read this group and, from time to time, some shorter PEPs. So I think I can tell Python a thing or two, but at the same time I don't want to tell it everything, everytime. :-) I like telling things in a language that sounds better, which depends on what I tell, actually. Regards, Tomasz Rola -- ** A C programmer asked whether computer had Buddha's nature. ** ** As the answer, master did "rm -rif" on the programmer's home ** ** directory. And then the C programmer became enlightened... ** ** ** ** Tomasz Rola mailto:tomasz_r...@bigfoot.com ** -- http://mail.python.org/mailman/listinfo/python-list
