[Chicago] Resolving lists within lists within lists within .....

[Lewit, Douglas]

Hi Mark,

I opened up that first link.

I love this quote from Guido Von Rossum!

*- Don't write Java (or C++, or Javascript, ...) in Python.*

Reminds me of the time Professor Iacobelli at NEIU told me, "Doug, you're
talking Python with a Java accent!"  Probably because I've had 4 courses in
Java and 0 courses in Python.  I suspect it happens with a lot of
programmers.  The first language that they really master becomes the
template against which all other languages are compared to.  I know one guy
who told me, "I speak Java with a C accent".

I know a tiny bit about stack traces.  I think the default number of stack
traces in Python is 1000.  But the programmer can change that this way:

import sys

sys.setrecursionlimit( whatever integer you like )

print( sys.getrecursionlimit( ) )   ####  Just checking to make sure that
the last command worked.

A professor and now dean at Oakton Community College told me, "Doug,
iteration is always faster than recursion and that's final!"  But.... later
on I found out some interesting things.  1) Merge sort ( recursive ) is
much faster and more efficient than let's say bubble sort or insertion sort
( both iterative ), 2) Iteratively searching a binary search tree is a real
mess.  The code is really complicated and messy.  Recursively searching a
binary search tree uses code that is short, sweet and simple.  And finally
3) Recursion is a fun, great mental exercise and helps people think about
complicated problems in a new way by breaking the problem down until you
reach the base cases.  I think iteration rocks, but it's overused.  And
according to some predictions I've read on the web, functional programming
could be the new big deal in about 10 or 20 or so years.  ( By then I
probably won't care!  Oh well. )  Recursion is a big cornerstone of
functional languages, so I guess I'm a recursion enthusiast!   :-)

Gotta run.  Thanks Mark!  I love those quotes from Guido.  It's also
interesting to find out what the creator of a language was trying to do.
Larry Wall ( the guy that wrote Perl ) has some interesting YouTube videos
where he talks about why he created Perl and what the future of computer
science looks like.  An interesting guy with a friendly style of lecturing.

Best,

Doug.



On Thu, Feb 18, 2016 at 9:29 PM, Mark Graves <mgraves87 at gmail.com> wrote:

> Doug,
>
> Also, I didn't see your question get answered.
>
> "The" answer to why is recursion expensive vs iteration is stack traces.
> See Guido's answer here
> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/5ba2375237a9fdc8efa681b19014981f/d6c3025efb0710ebe9f6fa425f843d2c/plus.google.com/115212051037621986145/posts/HajXHPGN752> or
> try it yourself as mentioned here
> <http://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/5ba2375237a9fdc8efa681b19014981f/dda1509570b2b5d9d162e6293a1b3f07/stackoverflow.com/questions/22893139/why-is-a-function-method-call-in-python-expensive>
> .
>
> Recursion means creating more functions / stack traces.
>
> On Thu, Feb 18, 2016 at 7:55 PM, Adam Forsyth <adam at adamforsyth.net>
> wrote:
>
>> Phil,
>>
>> That's generally true, but one small correction. Aaron's solution won't
>> actually won't flatten strings, as they don't have "__iter__" methods. They
>> implement iteration because they take sequential numeric indexes starting
>> at 0, and raise an IndexError after the index passed is too large.
>>
>> Adam
>> On Feb 18, 2016 19:22, "Robare, Phillip (TEKSystems)" <proba at allstate.com>
>> wrote:
>>
>>> Aaron, unlike Massimo’s elegant one-liner you don’t check that what you
>>> are iterating over is a list.  Since Python will happily iterate over
>>> strings, dictionaries, and much more you quickly get into problems when the
>>> list includes more types than lists and numbers.  I recount this from
>>> experience when I tried to throw together a flatten routine and pass it a
>>> data structure that I got from loading a JSON string.
>>>
>>>
>>>
>>> Phil Robare
>>>
>>>
>>>
>>> *<snip/>*
>>>
>>>
>>>
>>> On Thu, Feb 18, 2016 at 1:43 PM, Aaron Elmquist <elmq0022 at umn.edu>
>>> wrote:
>>>
>>> Douglas,
>>>
>>> Here's one more version for you and the rest of the list. It's based on
>>> Brad's code.  I will let you think about why this version might be better
>>> or worse.  Also, recursion is great.  It's just too bad it's not one of
>>> python's strong points.
>>>
>>>
>>> def flatten(lst):
>>>     for item1 in lst:
>>>         if hasattr(item1, '__iter__'):
>>>             for item2 in flatten(item1):
>>>                 yield item2
>>>         else:
>>>             yield item1
>>>
>>> print([x for x in flatten([1, [2,3,[4,5,6,[7,8,9]]]]) if x%2 == 1])
>>>
>>> y = flatten([1, [2,3,[4,5,6,[7,8,9]]]])
>>>
>>> print(next(y))
>>> print(next(y))
>>> print(next(y))
>>> .
>>> .
>>> .
>>> <snip/>
>>>
>>> On Wed, Feb 17, 2016 at 9:48 PM, DiPierro, Massimo <
>>> MDiPierro at cs.depaul.edu> wrote:
>>>
>>> here is a one liner:
>>>
>>> def flatten(x):
>>>     return [z for y in x for z in flatten(y)] if isinstance(x,list) else
>>> [x]
>>>
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160219/7c19a980/attachment.html>