From leon at mushroomthejournal.com  Mon Feb  1 11:13:51 2016
From: leon at mushroomthejournal.com (Leon Shernoff)
Date: Mon, 1 Feb 2016 11:13:51 -0500
Subject: [Chicago] When to load?
Message-ID: <56AF843F.8050101@mushroomthejournal.com>

Hello,

I have a modularity design question. I am writing a program that, as it 
goes along, calls a text-parsing routine. In fact, the main program is a 
scraping program (or pseudo-scraping -- it will also run on a collection 
of text files) that runs this parsing routine in a loop over many 
pages/files.

The parsing routine calls various other subroutines, so I'd like to put 
the whole set of them in a separate file that gets imported by the main 
program. The parsing program uses several dictionaries of terms, and as 
it processes more and more texts it adds more terms to those 
dictionaries and they get stored in a database that is read at launch to 
construct the dictionaries. So the dictionaries are a bit expensive to 
generate and I'd like to have to construct them only once.

So, I'm unclear on the persistence here (experienced developer, pretty 
new to Python):

1) If I put the database-read dictionary-construction code in the 
parser's file, will those get run (and the dictionaries reconstructed) 
each time the main program uses the parser?

2) If so, do I need to construct the dictionaries in the main program 
and pass them to the parser each time I invoke it? That would make for 
several parameters, all of which would be the same each time except for 
the text to be parsed. This may be one of those things that's more 
annoying to humans than it is to machines; but if the whole point of 
sequestering the parse routines in a separate file is to make my main 
program look cleaner and understand, it is kind of backwards to do that 
and then issue ugly, cluttered calls to those routines. :-)

3) Is there a better way? (or is #1 just not a problem and they only get 
constructed once) (Please, please...)  :-)

-- 
Best regards,
     Leon

"Creative work defines itself; therefore, confront the work."
      -- John Cage


Leon Shernoff
1511 E 54th St, Bsmt
Chicago, IL  60615

(312) 320-2190


From zitterbewegung at gmail.com  Mon Feb  1 12:25:23 2016
From: zitterbewegung at gmail.com (Joshua Herman)
Date: Mon, 1 Feb 2016 11:25:23 -0600
Subject: [Chicago] When to load?
In-Reply-To: <56AF843F.8050101@mushroomthejournal.com>
References: <56AF843F.8050101@mushroomthejournal.com>
Message-ID: <CAB3V1znZ1svLUB9+SXcW1syuHvTbtgP6wUR0YMSvF3iBCdwAow@mail.gmail.com>

Dear Leon,
You might want to use pickle or dill (if pickle doesn't work) to
serialize the dictionaries to disk so that you don't have to do the
complicated construction of dictionaries. I assume that they are
computationally expensive to construct so if you serialize them once
they are constructed you just need the space to store the serialized
form. Once they are serialized you should only have to generate them
once and then you just have to load it into your environment.

pickle.dump( obj_you_want_to_persist, open( "yourpicklefilenamehere.p", "wb" ) )

See https://docs.python.org/2/library/pickle.html# or
https://docs.python.org/3/library/pickle.html# for more information.

Sincerely,
Joshua Herman

On Mon, Feb 1, 2016 at 10:13 AM, Leon Shernoff
<leon at mushroomthejournal.com> wrote:
> Hello,
>
> I have a modularity design question. I am writing a program that, as it goes
> along, calls a text-parsing routine. In fact, the main program is a scraping
> program (or pseudo-scraping -- it will also run on a collection of text
> files) that runs this parsing routine in a loop over many pages/files.
>
> The parsing routine calls various other subroutines, so I'd like to put the
> whole set of them in a separate file that gets imported by the main program.
> The parsing program uses several dictionaries of terms, and as it processes
> more and more texts it adds more terms to those dictionaries and they get
> stored in a database that is read at launch to construct the dictionaries.
> So the dictionaries are a bit expensive to generate and I'd like to have to
> construct them only once.
>
> So, I'm unclear on the persistence here (experienced developer, pretty new
> to Python):
>
> 1) If I put the database-read dictionary-construction code in the parser's
> file, will those get run (and the dictionaries reconstructed) each time the
> main program uses the parser?
>
> 2) If so, do I need to construct the dictionaries in the main program and
> pass them to the parser each time I invoke it? That would make for several
> parameters, all of which would be the same each time except for the text to
> be parsed. This may be one of those things that's more annoying to humans
> than it is to machines; but if the whole point of sequestering the parse
> routines in a separate file is to make my main program look cleaner and
> understand, it is kind of backwards to do that and then issue ugly,
> cluttered calls to those routines. :-)
>
> 3) Is there a better way? (or is #1 just not a problem and they only get
> constructed once) (Please, please...)  :-)
>
> --
> Best regards,
>     Leon
>
> "Creative work defines itself; therefore, confront the work."
>      -- John Cage
>
>
> Leon Shernoff
> 1511 E 54th St, Bsmt
> Chicago, IL  60615
>
> (312) 320-2190
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago

From proba at allstate.com  Mon Feb  1 12:19:54 2016
From: proba at allstate.com (Robare, Phillip (TEKSystems))
Date: Mon, 1 Feb 2016 17:19:54 +0000
Subject: [Chicago] When to load?
In-Reply-To: <56AF843F.8050101@mushroomthejournal.com>
References: <56AF843F.8050101@mushroomthejournal.com>
Message-ID: <50869A74BA4F07468AD797C9BFF1FE3E0D9C0115@A0185-XPO1026-C.ad.allstate.com>

Leon,

You have asked a deeper and more pertinent question than I have seen on this list for a while.  Thank you for upping the discussion level.

When a module is imported the code in each module is loaded and executed only once, regardless of how often you use the import statement.  Subsequent import statements simply bind the module name to the module object already created by the previous import.  You can find a dictionary containing all currently loaded modules in the variable sys.modules.  This dictionary maps module names to module objects.  The contents of this dictionary are used to determine whether import loads a fresh copy of a module. (Python Essential Reference, 4th edition by David Beazley, pg 144)

So in answer to your questions:
1) If the dictionary import code is part of your module's __init__.py it will be run only once.
2) Hiding the operation of your program to make the code 'look cleaner' is not a best practice.  A good program has methods that depend only on their parameters and their (static) environment.  This allows the reader to determine how the code will run based on its input.  This doesn't mean that your python code has to look like Fortran with a few dozen parameters.  Use Python's data structures to create a structure (probably a class or list) that will hold the parser and its parameters and then you will have only one added parameter to pass to your analysis routines.
3) See answer for 2


Phil Robare

-----Original Message-----
From: Chicago [mailto:chicago-bounces+proba=allstate.com at python.org] On Behalf Of Leon Shernoff
Sent: Monday, February 01, 2016 10:14 AM
To: chicago at python.org
Subject: [Chicago] When to load?

Hello,

I have a modularity design question. I am writing a program that, as it goes along, calls a text-parsing routine. In fact, the main program is a scraping program (or pseudo-scraping -- it will also run on a collection of text files) that runs this parsing routine in a loop over many pages/files.

The parsing routine calls various other subroutines, so I'd like to put the whole set of them in a separate file that gets imported by the main program. The parsing program uses several dictionaries of terms, and as it processes more and more texts it adds more terms to those dictionaries and they get stored in a database that is read at launch to construct the dictionaries. So the dictionaries are a bit expensive to generate and I'd like to have to construct them only once.

So, I'm unclear on the persistence here (experienced developer, pretty new to Python):

1) If I put the database-read dictionary-construction code in the parser's file, will those get run (and the dictionaries reconstructed) each time the main program uses the parser?

2) If so, do I need to construct the dictionaries in the main program and pass them to the parser each time I invoke it? That would make for several parameters, all of which would be the same each time except for the text to be parsed. This may be one of those things that's more annoying to humans than it is to machines; but if the whole point of sequestering the parse routines in a separate file is to make my main program look cleaner and understand, it is kind of backwards to do that and then issue ugly, cluttered calls to those routines. :-)

3) Is there a better way? (or is #1 just not a problem and they only get constructed once) (Please, please...)  :-)

--
Best regards,
     Leon

"Creative work defines itself; therefore, confront the work."
      -- John Cage


Leon Shernoff
1511 E 54th St, Bsmt
Chicago, IL  60615

(312) 320-2190

_______________________________________________
Chicago mailing list
Chicago at python.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mail.python.org_mailman_listinfo_chicago&d=CwICAg&c=gtIjdLs6LnStUpy9cTOW9w&r=VXIryE9UwJGlNMLzgMzDT4_t2NMrZf6alSphHwSEwC0&m=OkiVgo931DJbjZrn5eyuk-W1Y2XI6TpIscU-PVfJTno&s=tLbB0f0AZsSDvVf1Uzg5rawQh6ASuyMeUUtFL9f3Es8&e= 

From leon at mushroomthejournal.com  Mon Feb  1 11:22:35 2016
From: leon at mushroomthejournal.com (Leon Shernoff)
Date: Mon, 1 Feb 2016 11:22:35 -0500
Subject: [Chicago] PostgreSQL and Python
Message-ID: <56AF864B.4040205@mushroomthejournal.com>

and pursuant to working with databases,

I'd like to get running with PostgreSQL, and it seems that pg8000 will 
be the best choice for me since I'm on Windows 7 (Win-64) and Psycopg2 
doesn't have a version for my environment. However I'm working in 
Anaconda, and pg8000 isn't one of the packages it has. In fact, it's 
hard for me to see any way for Python to hook up to PostgreSQL on my 
machine, though I have it running fine on its own. Does anyone know how 
I might proceed?

-- 
Best regards,
     Leon

"Creative work defines itself; therefore, confront the work."
      -- John Cage


Leon Shernoff
1511 E 54th St, Bsmt
Chicago, IL  60615

(312) 320-2190


From elmq0022 at umn.edu  Mon Feb  1 13:03:44 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Mon, 1 Feb 2016 12:03:44 -0600
Subject: [Chicago] When to load?
In-Reply-To: <CAB3V1znZ1svLUB9+SXcW1syuHvTbtgP6wUR0YMSvF3iBCdwAow@mail.gmail.com>
References: <56AF843F.8050101@mushroomthejournal.com>
 <CAB3V1znZ1svLUB9+SXcW1syuHvTbtgP6wUR0YMSvF3iBCdwAow@mail.gmail.com>
Message-ID: <CAPrZ9umqgX5uY4qrkXsLbUqNtHMUB7=4nk==+EC3c8+k2F5QLg@mail.gmail.com>

If simple persistence on disk answers your problem, consider the json
module.  Simple dictionaries map to json objects well and you get all the
benefits of json.

Pickle is great, but I often read about security issues (execution of
arbitrary code) and the binary format is not consistent across CPython
versions.  If you do go the pickle route, maybe look at shelve as well.

Also, I wonder if you need to pull in a large portion of the database prior
to web scraping.  Could you build updates in memory and push the updates to
the database after you parse the file(s)?

If you do have a lot of parameters that are annoying to look at, I would
encapsulate them in single object (a namedtuple from the collections module
would be great for this) and pass the object to the parse routine.

On Mon, Feb 1, 2016 at 11:25 AM, Joshua Herman <zitterbewegung at gmail.com>
wrote:

> Dear Leon,
> You might want to use pickle or dill (if pickle doesn't work) to
> serialize the dictionaries to disk so that you don't have to do the
> complicated construction of dictionaries. I assume that they are
> computationally expensive to construct so if you serialize them once
> they are constructed you just need the space to store the serialized
> form. Once they are serialized you should only have to generate them
> once and then you just have to load it into your environment.
>
> pickle.dump( obj_you_want_to_persist, open( "yourpicklefilenamehere.p",
> "wb" ) )
>
> See https://docs.python.org/2/library/pickle.html# or
> https://docs.python.org/3/library/pickle.html# for more information.
>
> Sincerely,
> Joshua Herman
>
> On Mon, Feb 1, 2016 at 10:13 AM, Leon Shernoff
> <leon at mushroomthejournal.com> wrote:
> > Hello,
> >
> > I have a modularity design question. I am writing a program that, as it
> goes
> > along, calls a text-parsing routine. In fact, the main program is a
> scraping
> > program (or pseudo-scraping -- it will also run on a collection of text
> > files) that runs this parsing routine in a loop over many pages/files.
> >
> > The parsing routine calls various other subroutines, so I'd like to put
> the
> > whole set of them in a separate file that gets imported by the main
> program.
> > The parsing program uses several dictionaries of terms, and as it
> processes
> > more and more texts it adds more terms to those dictionaries and they get
> > stored in a database that is read at launch to construct the
> dictionaries.
> > So the dictionaries are a bit expensive to generate and I'd like to have
> to
> > construct them only once.
> >
> > So, I'm unclear on the persistence here (experienced developer, pretty
> new
> > to Python):
> >
> > 1) If I put the database-read dictionary-construction code in the
> parser's
> > file, will those get run (and the dictionaries reconstructed) each time
> the
> > main program uses the parser?
> >
> > 2) If so, do I need to construct the dictionaries in the main program and
> > pass them to the parser each time I invoke it? That would make for
> several
> > parameters, all of which would be the same each time except for the text
> to
> > be parsed. This may be one of those things that's more annoying to humans
> > than it is to machines; but if the whole point of sequestering the parse
> > routines in a separate file is to make my main program look cleaner and
> > understand, it is kind of backwards to do that and then issue ugly,
> > cluttered calls to those routines. :-)
> >
> > 3) Is there a better way? (or is #1 just not a problem and they only get
> > constructed once) (Please, please...)  :-)
> >
> > --
> > Best regards,
> >     Leon
> >
> > "Creative work defines itself; therefore, confront the work."
> >      -- John Cage
> >
> >
> > Leon Shernoff
> > 1511 E 54th St, Bsmt
> > Chicago, IL  60615
> >
> > (312) 320-2190
> >
> > _______________________________________________
> > 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/20160201/52b855f4/attachment.html>

From leon at mushroomthejournal.com  Wed Feb  3 12:37:10 2016
From: leon at mushroomthejournal.com (Leon Shernoff)
Date: Wed, 3 Feb 2016 11:37:10 -0600
Subject: [Chicago] When to load?
Message-ID: <56B23AC6.5040504@mushroomthejournal.com>

Thanks!

Philip, that was indeed what I was looking for.
Joshua, there are indeed reasons that I'm using databases, but for 
relatively unstructured things like some of these word lists, I may be 
able to use pickle, so that was a good reminder.

-- 
Best regards,
     Leon

"Creative work defines itself; therefore, confront the work."
      -- John Cage


Leon Shernoff
1511 E 54th St, Bsmt
Chicago, IL  60615

(312) 320-2190


From zitterbewegung at gmail.com  Thu Feb  4 00:04:47 2016
From: zitterbewegung at gmail.com (Joshua Herman)
Date: Thu, 04 Feb 2016 05:04:47 +0000
Subject: [Chicago] PostgreSQL and Python
In-Reply-To: <56AF864B.4040205@mushroomthejournal.com>
References: <56AF864B.4040205@mushroomthejournal.com>
Message-ID: <CAB3V1znN6_dODj8y39jkgAWFwoKo=PErZ4v-L8-mrJ6rgh8fTA@mail.gmail.com>

Dear Leon,
In anaconda you can still use pip to install packages. In the anaconda
console you can do   pip install pg8000  without the quotes.
Sincerely,
Joshua Herman

On Wed, Feb 3, 2016 at 11:02 PM Leon Shernoff <leon at mushroomthejournal.com>
wrote:

> and pursuant to working with databases,
>
> I'd like to get running with PostgreSQL, and it seems that pg8000 will
> be the best choice for me since I'm on Windows 7 (Win-64) and Psycopg2
> doesn't have a version for my environment. However I'm working in
> Anaconda, and pg8000 isn't one of the packages it has. In fact, it's
> hard for me to see any way for Python to hook up to PostgreSQL on my
> machine, though I have it running fine on its own. Does anyone know how
> I might proceed?
>
> --
> Best regards,
>      Leon
>
> "Creative work defines itself; therefore, confront the work."
>       -- John Cage
>
>
> Leon Shernoff
> 1511 E 54th St, Bsmt
> Chicago, IL  60615
>
> (312) 320-2190
>
> _______________________________________________
> 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/20160204/0f4b1604/attachment.html>

From brianhray at gmail.com  Thu Feb  4 10:40:14 2016
From: brianhray at gmail.com (Brian Ray)
Date: Thu, 4 Feb 2016 09:40:14 -0600
Subject: [Chicago] Help entering talks,@1871 for next Thursday
Message-ID: <CANKg38uJ9c0oWzYfDsNWdUPRrgQBVeSawg682c-bv2+opd8--A@mail.gmail.com>

This is for organizers and for companies we spoke with regarding your talks
on Thursday. Please enter your talks here:

http://www.chipy.org/meetings/topics/propose

Organizers check for duplicates in the Admin:
http://www.chipy.org/admin/meetings/topic/

Hit Approve unless it's not a Python Powered Talk.

Anyone else want to talk? No problem fill out the form. Talk should be 7-10
min long about how you use (or wish to use Python) within your
Organizations.

Talks, once approved will end up here: http://Chipy.org

Thanks, Brian




-- 
Brian Ray
@brianray
(773) 669-7717
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160204/193a4ec3/attachment.html>

From leon at mushroomthejournal.com  Thu Feb  4 22:52:34 2016
From: leon at mushroomthejournal.com (Leon Shernoff)
Date: Thu, 4 Feb 2016 21:52:34 -0600
Subject: [Chicago] When to load? [Aaron Elmquist]
Message-ID: <56B41C82.7030501@mushroomthejournal.com>

Thanks, Aaron

JSON might be a quick way of serializing a bunch of little dictionaries 
in one file.
I do indeed intend to update the dictionaries in memory as the scraping 
proceeds, and then reserialize them after the task is finished.
The parser shouldn't need a clunky parameter list as long as the 
dictionaries are available in its namespace.

-- 
Best regards,
     Leon

"Creative work defines itself; therefore, confront the work."
      -- John Cage


Leon Shernoff
1511 E 54th St, Bsmt
Chicago, IL  60615

(312) 320-2190


From leon at mushroomthejournal.com  Thu Feb  4 23:02:19 2016
From: leon at mushroomthejournal.com (Leon Shernoff)
Date: Thu, 4 Feb 2016 22:02:19 -0600
Subject: [Chicago] PostgreSQL and Python [Joshua Herman]
Message-ID: <56B41ECB.4030606@mushroomthejournal.com>

Hi, Joshua

and thanks for your suggestion, but unfortunately that doesn't work and 
is actually something of a known error:
http://stackoverflow.com/questions/8548030/why-does-pip-install-raise-a-syntaxerror

pip install pg8000
raises that syntax error when executed from anaconda's python consoles, 
and anaconda has its own separate installation that's sort of walled off 
from the default installation of Python (and its packages). This is sort 
of the root (so to speak!) of the problem: in the command window I can 
install pg8000 (via pip) for my plain old original Python installation, 
but not (without some fanciness unknown to me) to my Anaconda 
installation. Hence the dependence on Anaconda making packages available 
through its conda command in the console.


Date: Thu, 04 Feb 2016 05:04:47 +0000
From: Joshua Herman <zitterbewegung at gmail.com>
To: The Chicago Python Users Group <chicago at python.org>
Subject: Re: [Chicago] PostgreSQL and Python

Dear Leon,
In anaconda you can still use pip to install packages. In the anaconda
console you can do   pip install pg8000  without the quotes.
Sincerely,
Joshua Herman

On Wed, Feb 3, 2016 at 11:02 PM Leon Shernoff <leon at mushroomthejournal.com>
wrote:

 > and pursuant to working with databases,
 >
 > I'd like to get running with PostgreSQL, and it seems that pg8000 will
 > be the best choice for me since I'm on Windows 7 (Win-64) and Psycopg2
 > doesn't have a version for my environment. However I'm working in
 > Anaconda, and pg8000 isn't one of the packages it has. In fact, it's
 > hard for me to see any way for Python to hook up to PostgreSQL on my
 > machine, though I have it running fine on its own. Does anyone know how
 > I might proceed?

-- 
Best regards,
     Leon

"Creative work defines itself; therefore, confront the work."
      -- John Cage


Leon Shernoff
1511 E 54th St, Bsmt
Chicago, IL  60615

(312) 320-2190


From shekay at pobox.com  Fri Feb  5 09:56:12 2016
From: shekay at pobox.com (sheila miguez)
Date: Fri, 5 Feb 2016 08:56:12 -0600
Subject: [Chicago] PostgreSQL and Python [Joshua Herman]
In-Reply-To: <56B41ECB.4030606@mushroomthejournal.com>
References: <56B41ECB.4030606@mushroomthejournal.com>
Message-ID: <CAHCs_raFtCgo1Wq0AHSc7DKw6QV=UuS8OE9Yfk3m47RZy35_nw@mail.gmail.com>

When you use conda at the command line to create the environment, if you
want to use pip you can add it to your conda environment. Then, at the
command line, run the pip install command. Not in the python console. Does
that work?

On Thu, Feb 4, 2016 at 10:02 PM, Leon Shernoff <leon at mushroomthejournal.com>
wrote:

> Hi, Joshua
>
> and thanks for your suggestion, but unfortunately that doesn't work and is
> actually something of a known error:
>
> http://stackoverflow.com/questions/8548030/why-does-pip-install-raise-a-syntaxerror
>
> pip install pg8000
> raises that syntax error when executed from anaconda's python consoles,
> and anaconda has its own separate installation that's sort of walled off
> from the default installation of Python (and its packages). This is sort of
> the root (so to speak!) of the problem: in the command window I can install
> pg8000 (via pip) for my plain old original Python installation, but not
> (without some fanciness unknown to me) to my Anaconda installation. Hence
> the dependence on Anaconda making packages available through its conda
> command in the console.
>
>
> Date: Thu, 04 Feb 2016 05:04:47 +0000
> From: Joshua Herman <zitterbewegung at gmail.com>
> To: The Chicago Python Users Group <chicago at python.org>
> Subject: Re: [Chicago] PostgreSQL and Python
>
> Dear Leon,
> In anaconda you can still use pip to install packages. In the anaconda
> console you can do   pip install pg8000  without the quotes.
> Sincerely,
> Joshua Herman
>
> On Wed, Feb 3, 2016 at 11:02 PM Leon Shernoff <leon at mushroomthejournal.com
> >
> wrote:
>
> > and pursuant to working with databases,
> >
> > I'd like to get running with PostgreSQL, and it seems that pg8000 will
> > be the best choice for me since I'm on Windows 7 (Win-64) and Psycopg2
> > doesn't have a version for my environment. However I'm working in
> > Anaconda, and pg8000 isn't one of the packages it has. In fact, it's
> > hard for me to see any way for Python to hook up to PostgreSQL on my
> > machine, though I have it running fine on its own. Does anyone know how
> > I might proceed?
>
> --
> Best regards,
>     Leon
>
> "Creative work defines itself; therefore, confront the work."
>      -- John Cage
>
>
> Leon Shernoff
> 1511 E 54th St, Bsmt
> Chicago, IL  60615
>
> (312) 320-2190
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago
>



-- 
shekay at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160205/1daead6d/attachment.html>

From elmq0022 at umn.edu  Fri Feb  5 12:27:31 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Fri, 5 Feb 2016 11:27:31 -0600
Subject: [Chicago] When to load? [Aaron Elmquist]
In-Reply-To: <56B41C82.7030501@mushroomthejournal.com>
References: <56B41C82.7030501@mushroomthejournal.com>
Message-ID: <CAPrZ9u=qEReQWPRznA_KyO7__skOWV-oDTSyqU0hyvutjAOVWg@mail.gmail.com>

Sounds good.  Good luck with your project.

On Thu, Feb 4, 2016 at 9:52 PM, Leon Shernoff <leon at mushroomthejournal.com>
wrote:

> Thanks, Aaron
>
> JSON might be a quick way of serializing a bunch of little dictionaries in
> one file.
> I do indeed intend to update the dictionaries in memory as the scraping
> proceeds, and then reserialize them after the task is finished.
> The parser shouldn't need a clunky parameter list as long as the
> dictionaries are available in its namespace.
>
> --
> Best regards,
>     Leon
>
> "Creative work defines itself; therefore, confront the work."
>      -- John Cage
>
>
> Leon Shernoff
> 1511 E 54th St, Bsmt
> Chicago, IL  60615
>
> (312) 320-2190
>
> _______________________________________________
> 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/20160205/19ac8c7d/attachment.html>

From leon at mushroomthejournal.com  Mon Feb  8 11:52:48 2016
From: leon at mushroomthejournal.com (Leon Shernoff)
Date: Mon, 8 Feb 2016 10:52:48 -0600
Subject: [Chicago] PostgreSQL and Python [sheila miguez]
Message-ID: <56B8C7E0.9000202@mushroomthejournal.com>

Thanks, Sheila!

Well, I guess Anaconda has taken over my normal package deployment path. 
:-) I decided to do test-driven :-) installation and run the pip command 
from my default shell location, and then do it from the Anaconda 
directory. But after running it from my default directory, I can now 
import pg8000 in Anaconda, but not in IDLE. So I guess all my future 
packages are going to Anaconda whether I like it or not, but in the 
meantime this is what I was trying to do so it's all good. :-)


Date: Fri, 5 Feb 2016 08:56:12 -0600
From: sheila miguez <shekay at pobox.com>
To: The Chicago Python Users Group <chicago at python.org>
Subject: Re: [Chicago] PostgreSQL and Python [Leon Shernoff]

When you use conda at the command line to create the environment, if you
want to use pip you can add it to your conda environment. Then, at the
command line, run the pip install command. Not in the python console. Does
that work?

-- 
Best regards,
     Leon

"Creative work defines itself; therefore, confront the work."
      -- John Cage


Leon Shernoff
1511 E 54th St, Bsmt
Chicago, IL  60615

(312) 320-2190


From tanya at tickel.net  Mon Feb  8 13:03:03 2016
From: tanya at tickel.net (Tanya Schlusser)
Date: Mon, 8 Feb 2016 12:03:03 -0600
Subject: [Chicago] PostgreSQL and Python
Message-ID: <CA+bo0=SG6o52qvREkv3bja1yirppaC-c5gGLZ0e=+AYvDiQ__g@mail.gmail.com>

While we're on the topic of Postgres + Python ...

Apparently Kenneth Reitz just released a new library of the weekend,
Records (https://github.com/kennethreitz/records) that seems similar to
pg8000 in that there's no ORM building, just querying.

"Records is a very simple, but powerful, library for making raw SQL queries
to Postgres databases."

sweet.
happy lunar new year
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160208/6b116ade/attachment.html>

From wesclemens at gmail.com  Mon Feb  8 14:48:14 2016
From: wesclemens at gmail.com (William E. S. Clemens)
Date: Mon, 8 Feb 2016 13:48:14 -0600
Subject: [Chicago] PostgreSQL and Python [sheila miguez]
In-Reply-To: <56B8C7E0.9000202@mushroomthejournal.com>
References: <56B8C7E0.9000202@mushroomthejournal.com>
Message-ID: <CAOo02k9twgEfvdovbbRUOiwSBpBJdEcUwWWqAr3Q3PpRYZVR3A@mail.gmail.com>

I have two suggestions:

First, it looks to me that pandas has a win64 Psycopg2 build on
anaconda.org[1],
I would try installing this before using pg8000 in pip. I don't use
anaconda personally so I maybe leading you down the wrong path.

Second, when people have the problem you described above with imports not
working from within Idle but working from the command line it's almost
always you'r running two different python installations. You can start Idle
form the command line like such `python -m idlelib` and it will ensure that
you are running with the same version of python as the command line.

I hope this helps.

[1] http://anaconda.org/pandas/psycopg2

On Mon, Feb 8, 2016 at 10:52 AM, Leon Shernoff <leon at mushroomthejournal.com>
wrote:

> Thanks, Sheila!
>
> Well, I guess Anaconda has taken over my normal package deployment path.
> :-) I decided to do test-driven :-) installation and run the pip command
> from my default shell location, and then do it from the Anaconda directory.
> But after running it from my default directory, I can now import pg8000 in
> Anaconda, but not in IDLE. So I guess all my future packages are going to
> Anaconda whether I like it or not, but in the meantime this is what I was
> trying to do so it's all good. :-)
>
>
> Date: Fri, 5 Feb 2016 08:56:12 -0600
> From: sheila miguez <shekay at pobox.com>
> To: The Chicago Python Users Group <chicago at python.org>
> Subject: Re: [Chicago] PostgreSQL and Python [Leon Shernoff]
>
> When you use conda at the command line to create the environment, if you
> want to use pip you can add it to your conda environment. Then, at the
> command line, run the pip install command. Not in the python console. Does
> that work?
>
> --
> Best regards,
>     Leon
>
> "Creative work defines itself; therefore, confront the work."
>      -- John Cage
>
>
> Leon Shernoff
> 1511 E 54th St, Bsmt
> Chicago, IL  60615
>
> (312) 320-2190
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago
>



-- 
William Clemens
Phone: 847.485.9455
E-mail: wesclemens at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160208/2aa43817/attachment.html>

From zitterbewegung at gmail.com  Mon Feb  8 15:19:08 2016
From: zitterbewegung at gmail.com (Joshua Herman)
Date: Mon, 08 Feb 2016 20:19:08 +0000
Subject: [Chicago] PostgreSQL and Python
In-Reply-To: <CA+bo0=SG6o52qvREkv3bja1yirppaC-c5gGLZ0e=+AYvDiQ__g@mail.gmail.com>
References: <CA+bo0=SG6o52qvREkv3bja1yirppaC-c5gGLZ0e=+AYvDiQ__g@mail.gmail.com>
Message-ID: <CAB3V1zm_vBXiHsADrqC_GCpg8EJGrw22Udg61o-cQoS+xSes2A@mail.gmail.com>

Looking at the documentation it looks pretty nice. One difference between
this and other database libraries is that it returns dictionaries instead
of tuples .
On Mon, Feb 8, 2016 at 12:03 PM Tanya Schlusser <tanya at tickel.net> wrote:

> While we're on the topic of Postgres + Python ...
>
> Apparently Kenneth Reitz just released a new library of the weekend,
> Records (https://github.com/kennethreitz/records) that seems similar to
> pg8000 in that there's no ORM building, just querying.
>
> "Records is a very simple, but powerful, library for making raw SQL
> queries to Postgres databases."
>
> sweet.
> happy lunar new year
> _______________________________________________
> 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/20160208/f9f168d4/attachment.html>

From joe.jasinski at gmail.com  Mon Feb  8 23:58:32 2016
From: joe.jasinski at gmail.com (Joe Jasinski)
Date: Mon, 8 Feb 2016 22:58:32 -0600
Subject: [Chicago] ChiPy February 11th Meeting
Message-ID: <CACdfcwUPP-gvkZQWcRQ0DqTa=4BNqX2QXbpNXNujJL9QQSCXkQ@mail.gmail.com>

ChiPy,

Our February 11th meeting is on the horizon and we have an interesting
event planned. Companies around Chicago, who use Python, will be presenting
about how they use Python in their business.

Starting from this month, attendees are invited to arrive at the venue at
6:00pm to hang out, network, and eat. The presentations will begin promptly
at 7:00pm.


   - After party at nearby bar kindly provided by OptionsAway
   - Venue/Drink/Food Sponsor "The Connected Intelligence Foundation"
   - The "Best Talk" will receive a gift from OpenAirplane
   - Prize for first place "OpenAirplane arrange with one of the
      Chicago-area flight schools to send the winner on their first flight
      lesson. If the winner happens to be a pilot, they'll cover the first hour
      of ground instruction + first hour of flight toward a Universal Pilot
      Checkout."


All are welcome! Please RSVP
<http://www.meetup.com/_ChiPy_/events/228139009/> soon.

*When:*
Thursday February 11th

   - 6:00pm - doors open; food arrives
   - 7:00pm - Meeting Start


*How:*
You can rsvp at chipy.org or via our Meetup
<http://www.meetup.com/_ChiPy_/> group.


*Where:*
1871 <https://goo.gl/maps/sCevntCGhLG2>
222 W Merchandise Mart Plaza #1212, Chicago, IL 60654

*What:*
*How SpotHero uses Python*
By: Cezar Jenkins
SpotHero is one of the leading online parking reservation companies in the
country. Come see how were using Python to make that happen.

*Python at OptionsAway*
By: Tim Saylor
How OptionsAway, an airfare lock startup, uses Python.

*Python at Credit Suisse*
By: David Matsumura

*How Credit Suisse uses Python.*
Python at Datascope Analytics
By: Brian Lange
How Datascope Analytics uses Python to improve business and society through
science and design.

*Python at ShiftGig*
By: Brian Eagan , Tyler Hendrickson
How ShiftGig, which connects the right people with the right job, uses
Python.

*Python at Modest*
By: Emily Anderson , Mark Ashton
We will describe how Modest, recently acquired by Braintree (PayPal) uses
Python.

*Python at Deloitte*
By: Brian Ray
How Deloitte uses Python within the Enterprise Science Team.

*Python-Powered Data Science at Civis*
By: Stephen Hoover
Civis Analytics uses Python to develop the machine learning software which
powers our products, and we run our Python software in production. I'll
give a (very) brief overview of what Civis Analytics does and where Python
and the open source community fit into the picture.


Thanks always to all our Platinum sponsors, especially: Braintree,
Imaginary Landscape, and Telnyx.

Please be aware of our code of conduct http://www.chipy.org/pages/conduct/


Brian Ray promises this will be "our best meeting ever!"


-- 
Joe J. Jasinski
www.joejasinski.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160208/9b9b4a32/attachment.html>

From bob.haugen at gmail.com  Sat Feb 13 11:01:45 2016
From: bob.haugen at gmail.com (Bob Haugen)
Date: Sat, 13 Feb 2016 10:01:45 -0600
Subject: [Chicago] Fwd: [LCLUG] Ben Davidson SO project
In-Reply-To: <CAGgMGko+KZByFE5aGgTfNhX509=YMK7BZX51DzLBXDRPWpuONQ@mail.gmail.com>
References: <CAGgMGko+KZByFE5aGgTfNhX509=YMK7BZX51DzLBXDRPWpuONQ@mail.gmail.com>
Message-ID: <CA+Svw0VL9rgH=50qLH9eushMW9Ft8m2iNY_rOJqSh7RzS-QRyw@mail.gmail.com>

---------- Forwarded message ----------
From: Ben Hansen <ben at mwt.net>
Date: Sat, Feb 13, 2016 at 9:53 AM
Subject: [LCLUG] Ben Davidson SO project
To: LCLUG <lacrosselug at googlegroups.com>


A pass on from Ben Davidson, Space Weather guy. I thought there might be
some one in the group with some interest~

Looking for computer programmers who can write a very specific program
designed to detect and measure the amount of color in an image. Can you
write a program that can detect these black coronal holes? Would it be able
to detect how close to the center of the image the coronal holes are? Could
it determine how much of the earth-facing circle was covered by coronal
holes?

For more details, send a resume and a few words about the brief description
given to Ben at ObservatoryProject.com with the subject ?Coronal Hole Program?

Some of his public face here for a quick browse, links to all sites on the
you tube page.
Ben Davidson FB request page
<https://www.facebook.com/photo.php?fbid=963232981506&set=a.538828306876.2053831.28503841&type=3&theater>

https://youtu.be/CM0wzZnmDwI

Benjamen

-- 
-- 
You received this message because you are subscribed to the "La Crosse
Linux Users Group" on Google.

To visit our web site, go to http://www.lclug.org

To post to this group, send email to lacrosselug at googlegroups.com
To unsubscribe from this group, send email to
lacrosselug-unsubscribe at googlegroups.com
For more options, visit this group at
http://groups.google.com/group/lacrosselug?hl=en

---
You received this message because you are subscribed to the Google Groups
"La Crosse Linux Users Group" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to lacrosselug+unsubscribe at googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160213/d4df51e2/attachment.html>

From d-lewit at neiu.edu  Mon Feb 15 17:12:20 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Mon, 15 Feb 2016 16:12:20 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
Message-ID: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>

Hi everyone,

Well it's President's Day and I've got the day off!  Hooray!!!  Finally
some time to just relax and mess around.  So I'm at my computer playing
around with Python and wondering how to resolve the issue of multiple lists
embedded within other lists.  I came up with two functions that I think
solve the problem.  But I was wondering if Guido or someone else added a
builtin function or method that does this automatically for the
programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
wondering why I called the function "flatten" it's because I know from
experience that Wolfram Mathematica and Ocaml have these "flatten"
functions.  I think Ruby has something similar, but I haven't played with
Ruby in a while so I'm not really sure. )  The try: except block is
important because you can't subscript non-list data structures in Python.
The IndexError is what you get when you try to index an empty list.  So I
****think**** my try: except block covers most commonly encountered
exceptions when working with lists embedded within other lists.

Best,

Douglas.

def flatten(lst):
if lst == [ ]:
return lst
else:
try:
return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
except TypeError:
return [lst[0]] + flatten(lst[1:])
except IndexError:
return flatten(lst[1:])

def flattenAgain(lst):
newList = lst[:]
while newList != flatten(newList):
newList = flatten(newList)
return newList
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160215/91ed5061/attachment.html>

From daniel.galtieri at gmail.com  Mon Feb 15 17:31:36 2016
From: daniel.galtieri at gmail.com (Daniel Galtieri)
Date: Mon, 15 Feb 2016 16:31:36 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
Message-ID: <CAJgjJzRYuf2fkZgoUNBKPMKN492KXJY1bbGYLdzJ-6+DP2V6LQ@mail.gmail.com>

Look at itertools.chain(), basically does what you want.
On Feb 15, 2016 4:12 PM, "Lewit, Douglas" <d-lewit at neiu.edu> wrote:

> Hi everyone,
>
> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
> some time to just relax and mess around.  So I'm at my computer playing
> around with Python and wondering how to resolve the issue of multiple lists
> embedded within other lists.  I came up with two functions that I think
> solve the problem.  But I was wondering if Guido or someone else added a
> builtin function or method that does this automatically for the
> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
> wondering why I called the function "flatten" it's because I know from
> experience that Wolfram Mathematica and Ocaml have these "flatten"
> functions.  I think Ruby has something similar, but I haven't played with
> Ruby in a while so I'm not really sure. )  The try: except block is
> important because you can't subscript non-list data structures in Python.
> The IndexError is what you get when you try to index an empty list.  So I
> ****think**** my try: except block covers most commonly encountered
> exceptions when working with lists embedded within other lists.
>
> Best,
>
> Douglas.
>
> def flatten(lst):
> if lst == [ ]:
> return lst
> else:
> try:
> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
> except TypeError:
> return [lst[0]] + flatten(lst[1:])
> except IndexError:
> return flatten(lst[1:])
>
> def flattenAgain(lst):
> newList = lst[:]
> while newList != flatten(newList):
> newList = flatten(newList)
> return newList
>
>
>
> _______________________________________________
> 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/20160215/55133b11/attachment.html>

From d-lewit at neiu.edu  Mon Feb 15 18:03:05 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Mon, 15 Feb 2016 17:03:05 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAJgjJzRYuf2fkZgoUNBKPMKN492KXJY1bbGYLdzJ-6+DP2V6LQ@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <CAJgjJzRYuf2fkZgoUNBKPMKN492KXJY1bbGYLdzJ-6+DP2V6LQ@mail.gmail.com>
Message-ID: <CAPdZZGxKC6GurWQu-7wfoOZ0k_mwJfYG3pDddJ2KF++pyFu5uQ@mail.gmail.com>

Thanks Daniel,

I'll go check it out.

Hope you had a nice Valentine's Day.

Best,

Douglas.


On Mon, Feb 15, 2016 at 4:31 PM, Daniel Galtieri <daniel.galtieri at gmail.com>
wrote:

> Look at itertools.chain(), basically does what you want.
> On Feb 15, 2016 4:12 PM, "Lewit, Douglas" <d-lewit at neiu.edu> wrote:
>
>> Hi everyone,
>>
>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
>> some time to just relax and mess around.  So I'm at my computer playing
>> around with Python and wondering how to resolve the issue of multiple lists
>> embedded within other lists.  I came up with two functions that I think
>> solve the problem.  But I was wondering if Guido or someone else added a
>> builtin function or method that does this automatically for the
>> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
>> wondering why I called the function "flatten" it's because I know from
>> experience that Wolfram Mathematica and Ocaml have these "flatten"
>> functions.  I think Ruby has something similar, but I haven't played with
>> Ruby in a while so I'm not really sure. )  The try: except block is
>> important because you can't subscript non-list data structures in Python.
>> The IndexError is what you get when you try to index an empty list.  So I
>> ****think**** my try: except block covers most commonly encountered
>> exceptions when working with lists embedded within other lists.
>>
>> Best,
>>
>> Douglas.
>>
>> def flatten(lst):
>> if lst == [ ]:
>> return lst
>> else:
>> try:
>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>> except TypeError:
>> return [lst[0]] + flatten(lst[1:])
>> except IndexError:
>> return flatten(lst[1:])
>>
>> def flattenAgain(lst):
>> newList = lst[:]
>> while newList != flatten(newList):
>> newList = flatten(newList)
>> return newList
>>
>>
>>
>> _______________________________________________
>> 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/20160215/62cb39ec/attachment.html>

From zitterbewegung at gmail.com  Mon Feb 15 22:09:33 2016
From: zitterbewegung at gmail.com (Joshua Herman)
Date: Mon, 15 Feb 2016 21:09:33 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
Message-ID: <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>

The idea of flattening a object or datatype is a functional programming technique and not just a part of Ruby and Mathematica According to this answer on the programming stack exchange there is no method / function that implements flatten for build in Python functions but you can get almost there with itertools.chain.from_iterable . See http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists .
> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
> 
> Hi everyone,
> 
> Well it's President's Day and I've got the day off!  Hooray!!!  Finally some time to just relax and mess around.  So I'm at my computer playing around with Python and wondering how to resolve the issue of multiple lists embedded within other lists.  I came up with two functions that I think solve the problem.  But I was wondering if Guido or someone else added a builtin function or method that does this automatically for the programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're wondering why I called the function "flatten" it's because I know from experience that Wolfram Mathematica and Ocaml have these "flatten" functions.  I think Ruby has something similar, but I haven't played with Ruby in a while so I'm not really sure. )  The try: except block is important because you can't subscript non-list data structures in Python.  The IndexError is what you get when you try to index an empty list.  So I ****think**** my try: except block covers most commonly encountered exceptions when working with lists embedded within other lists.
> 
> Best,
> 
> Douglas.
> 
> def flatten(lst):
> 	if lst == [ ]:
> 		return lst
> 	else:
> 		try:
> 			return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
> 		except TypeError:
> 			return [lst[0]] + flatten(lst[1:])
> 		except IndexError:
> 			return flatten(lst[1:])
> 
> def flattenAgain(lst):
> 	newList = lst[:]
> 	while newList != flatten(newList):
> 		newList = flatten(newList)
> 	return newList
> 
> 
> _______________________________________________
> 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/20160215/2a302f43/attachment.html>

From tanya at tickel.net  Tue Feb 16 07:24:53 2016
From: tanya at tickel.net (Tanya Schlusser)
Date: Tue, 16 Feb 2016 06:24:53 -0600
Subject: [Chicago] Computer Science 4 All event at Google - 5pm Monday 5/22
Message-ID: <CA+bo0=TYhKGLiyDaoDpUbP48-SCMexw5cnk+uWwa+f73tSsDkQ@mail.gmail.com>

The Chicago Public Schools and Google are celebrating their Computer
Science 4 All initiative (the first in the nation), and talking about
computer science in public schools on Monday 22 February at 5pm.

They have a partnership with Code.org -- the people who run the Hour of
Code -- to bring computer programming to every public school in Chicago.


The eventbrite page cautions that people will only enjoy it if they want to
participate in meaty discussion about computer science teaching in public
education :-)


Here is the link to the event:
https://www.eventbrite.com/e/celebrate-computer-science-in-chicago-accelerate-cs4all-tickets-21392162534
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160216/354e9b18/attachment.html>

From bradley.marts at gmail.com  Tue Feb 16 14:13:49 2016
From: bradley.marts at gmail.com (Brad Martsberger)
Date: Tue, 16 Feb 2016 13:13:49 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
Message-ID: <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>

> you can get almost there with itertools.chain.from_iterable

It's tempting, but it fails in a lot of ways. It successfully flattens a
list of lists, but doesn't go any deeper than that and fails completely on
a list composed of some lists and some non-list objects. You can also get
the same behavior out of a list comprehension.

Douglas, you have written a recursive function, but I think you've missed
on what the base case is. The base case is not whether or not you've been
passed an empty list, but rather whether an element is a list or not (if
it's not, you don't need any further flattening. Also, all those indices
don't look very pythonic.

Here is a recursive flatten function that will handle any depth and mixed
depths at different elements (no indexing required)

def flatten(lst):
    new_list = []
    for element in lst:
        if isinstance(element, list):
            new_list.extend(flatten(element))
        else:
            # This is the base case where the recursion ends
            new_list.append(element)

    return new_list

>>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
[1, 1.1, 2, 3, 4, 5, 6, 7, 8]

On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com>
wrote:

> The idea of flattening a object or datatype is a functional programming
> technique and not just a part of Ruby and Mathematica According to this
> answer on the programming stack exchange there is no method / function that
> implements flatten for build in Python functions but you can get almost
> there with itertools.chain.from_iterable . See
> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
> .
>
> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>
> Hi everyone,
>
> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
> some time to just relax and mess around.  So I'm at my computer playing
> around with Python and wondering how to resolve the issue of multiple lists
> embedded within other lists.  I came up with two functions that I think
> solve the problem.  But I was wondering if Guido or someone else added a
> builtin function or method that does this automatically for the
> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
> wondering why I called the function "flatten" it's because I know from
> experience that Wolfram Mathematica and Ocaml have these "flatten"
> functions.  I think Ruby has something similar, but I haven't played with
> Ruby in a while so I'm not really sure. )  The try: except block is
> important because you can't subscript non-list data structures in Python.
> The IndexError is what you get when you try to index an empty list.  So I
> ****think**** my try: except block covers most commonly encountered
> exceptions when working with lists embedded within other lists.
>
> Best,
>
> Douglas.
>
> def flatten(lst):
> if lst == [ ]:
> return lst
> else:
> try:
> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
> except TypeError:
> return [lst[0]] + flatten(lst[1:])
> except IndexError:
> return flatten(lst[1:])
>
> def flattenAgain(lst):
> newList = lst[:]
> while newList != flatten(newList):
> newList = flatten(newList)
> return newList
>
>
> _______________________________________________
> 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/20160216/aa67b3c6/attachment.html>

From d-lewit at neiu.edu  Tue Feb 16 15:50:51 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Tue, 16 Feb 2016 14:50:51 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
Message-ID: <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>

Whether it looks pythonic or not Joshua, it works!  Try it before you
criticize it!!!   ;-)   In implementing recursive functions on lists, one
of the base cases is almost always whether the list is empty or not.  A
little lesson I learned from studying lists in Haskell and Ocaml.  Hard
languages for sure, but they made me a stronger programmer when it comes to
the dreaded "R" ( Recursion ).   ;-)


On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <bradley.marts at gmail.com>
wrote:

> > you can get almost there with itertools.chain.from_iterable
>
> It's tempting, but it fails in a lot of ways. It successfully flattens a
> list of lists, but doesn't go any deeper than that and fails completely on
> a list composed of some lists and some non-list objects. You can also get
> the same behavior out of a list comprehension.
>
> Douglas, you have written a recursive function, but I think you've missed
> on what the base case is. The base case is not whether or not you've been
> passed an empty list, but rather whether an element is a list or not (if
> it's not, you don't need any further flattening. Also, all those indices
> don't look very pythonic.
>
> Here is a recursive flatten function that will handle any depth and mixed
> depths at different elements (no indexing required)
>
> def flatten(lst):
>     new_list = []
>     for element in lst:
>         if isinstance(element, list):
>             new_list.extend(flatten(element))
>         else:
>             # This is the base case where the recursion ends
>             new_list.append(element)
>
>     return new_list
>
> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>
> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com>
> wrote:
>
>> The idea of flattening a object or datatype is a functional programming
>> technique and not just a part of Ruby and Mathematica According to this
>> answer on the programming stack exchange there is no method / function that
>> implements flatten for build in Python functions but you can get almost
>> there with itertools.chain.from_iterable . See
>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>> .
>>
>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>
>> Hi everyone,
>>
>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
>> some time to just relax and mess around.  So I'm at my computer playing
>> around with Python and wondering how to resolve the issue of multiple lists
>> embedded within other lists.  I came up with two functions that I think
>> solve the problem.  But I was wondering if Guido or someone else added a
>> builtin function or method that does this automatically for the
>> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
>> wondering why I called the function "flatten" it's because I know from
>> experience that Wolfram Mathematica and Ocaml have these "flatten"
>> functions.  I think Ruby has something similar, but I haven't played with
>> Ruby in a while so I'm not really sure. )  The try: except block is
>> important because you can't subscript non-list data structures in Python.
>> The IndexError is what you get when you try to index an empty list.  So I
>> ****think**** my try: except block covers most commonly encountered
>> exceptions when working with lists embedded within other lists.
>>
>> Best,
>>
>> Douglas.
>>
>> def flatten(lst):
>> if lst == [ ]:
>> return lst
>> else:
>> try:
>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>> except TypeError:
>> return [lst[0]] + flatten(lst[1:])
>> except IndexError:
>> return flatten(lst[1:])
>>
>> def flattenAgain(lst):
>> newList = lst[:]
>> while newList != flatten(newList):
>> newList = flatten(newList)
>> return newList
>>
>>
>> _______________________________________________
>> 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/20160216/a88570fd/attachment.html>

From zitterbewegung at gmail.com  Tue Feb 16 23:26:33 2016
From: zitterbewegung at gmail.com (Joshua Herman)
Date: Tue, 16 Feb 2016 22:26:33 -0600
Subject: [Chicago] Easier way of finding sha256 of python packages
Message-ID: <CAB3V1z=HooFqY5fY0ODeUbGYqUmPMjiohpqOW6EpLZv64LYciQ@mail.gmail.com>

So currently I am working on a python project where I have a
requirements.txt which is also enforcing that the hashes of the python
packages that are in the project being verified. When I install a
python package I have to get the hash to put it in the
requirements.txt I was wondering if there is a better way of doing
this than doing the following.

1. Download the package I want to add to my project from pip.
2. Run pip hash on the downloaded file .

From bradley.marts at gmail.com  Tue Feb 16 23:37:47 2016
From: bradley.marts at gmail.com (Brad Martsberger)
Date: Tue, 16 Feb 2016 22:37:47 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
Message-ID: <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>

Douglas, I don't know if that was supposed to be sarcastic or what.

In fact, your code does not work.

>>> flatten([[[1, 2], 3], 4])
[[1, 2], 3, 4]

Looks like it fails to fully flatten the list.

I assumed from your original email you were interested in other approaches,
so I gave one that looks to me like it's much less complex (no need for
try/except, no need for indexing, 1 recursive call instead of 3). Less
complex code is usually easier to reason about and less prone to bugs.

In purely functional languages there is no for loop, so if you want to
iterate over a list, you have to do it with recursive function calls.
Recursion stops when there's nothing left in the list, so the base case is
the empty list. Since iterating over a list is so common in programming, it
can start to feel like this is the way recursion and lists go together.

But a good rule of thumb is only good if it doesn't trip you up when you
com across an exception to the rule. In the problem of flattening a list,
the recursion is down the depth of nesting, not across the list. In this
case, you can stop flattening when you hit a non-list object, so that's
your base case.

Brad

On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:

> Whether it looks pythonic or not Joshua, it works!  Try it before you
> criticize it!!!   ;-)   In implementing recursive functions on lists, one
> of the base cases is almost always whether the list is empty or not.  A
> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
> languages for sure, but they made me a stronger programmer when it comes to
> the dreaded "R" ( Recursion ).   ;-)
>
>
> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <bradley.marts at gmail.com
> > wrote:
>
>> > you can get almost there with itertools.chain.from_iterable
>>
>> It's tempting, but it fails in a lot of ways. It successfully flattens a
>> list of lists, but doesn't go any deeper than that and fails completely on
>> a list composed of some lists and some non-list objects. You can also get
>> the same behavior out of a list comprehension.
>>
>> Douglas, you have written a recursive function, but I think you've missed
>> on what the base case is. The base case is not whether or not you've been
>> passed an empty list, but rather whether an element is a list or not (if
>> it's not, you don't need any further flattening. Also, all those indices
>> don't look very pythonic.
>>
>> Here is a recursive flatten function that will handle any depth and mixed
>> depths at different elements (no indexing required)
>>
>> def flatten(lst):
>>     new_list = []
>>     for element in lst:
>>         if isinstance(element, list):
>>             new_list.extend(flatten(element))
>>         else:
>>             # This is the base case where the recursion ends
>>             new_list.append(element)
>>
>>     return new_list
>>
>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>
>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com>
>> wrote:
>>
>>> The idea of flattening a object or datatype is a functional programming
>>> technique and not just a part of Ruby and Mathematica According to this
>>> answer on the programming stack exchange there is no method / function that
>>> implements flatten for build in Python functions but you can get almost
>>> there with itertools.chain.from_iterable . See
>>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>>> .
>>>
>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>>
>>> Hi everyone,
>>>
>>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
>>> some time to just relax and mess around.  So I'm at my computer playing
>>> around with Python and wondering how to resolve the issue of multiple lists
>>> embedded within other lists.  I came up with two functions that I think
>>> solve the problem.  But I was wondering if Guido or someone else added a
>>> builtin function or method that does this automatically for the
>>> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
>>> wondering why I called the function "flatten" it's because I know from
>>> experience that Wolfram Mathematica and Ocaml have these "flatten"
>>> functions.  I think Ruby has something similar, but I haven't played with
>>> Ruby in a while so I'm not really sure. )  The try: except block is
>>> important because you can't subscript non-list data structures in Python.
>>> The IndexError is what you get when you try to index an empty list.  So I
>>> ****think**** my try: except block covers most commonly encountered
>>> exceptions when working with lists embedded within other lists.
>>>
>>> Best,
>>>
>>> Douglas.
>>>
>>> def flatten(lst):
>>> if lst == [ ]:
>>> return lst
>>> else:
>>> try:
>>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>> except TypeError:
>>> return [lst[0]] + flatten(lst[1:])
>>> except IndexError:
>>> return flatten(lst[1:])
>>>
>>> def flattenAgain(lst):
>>> newList = lst[:]
>>> while newList != flatten(newList):
>>> newList = flatten(newList)
>>> return newList
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20160216/3332da71/attachment.html>

From d-lewit at neiu.edu  Tue Feb 16 23:44:32 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Tue, 16 Feb 2016 22:44:32 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
Message-ID: <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>

Use flattenAgain.... which calls flatten repeatedly until there's no change
in the list.  You have to use BOTH functions!

Sarcasm?  What's that?


On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <bradley.marts at gmail.com>
wrote:

> Douglas, I don't know if that was supposed to be sarcastic or what.
>
> In fact, your code does not work.
>
> >>> flatten([[[1, 2], 3], 4])
> [[1, 2], 3, 4]
>
> Looks like it fails to fully flatten the list.
>
> I assumed from your original email you were interested in other
> approaches, so I gave one that looks to me like it's much less complex (no
> need for try/except, no need for indexing, 1 recursive call instead of 3).
> Less complex code is usually easier to reason about and less prone to bugs.
>
> In purely functional languages there is no for loop, so if you want to
> iterate over a list, you have to do it with recursive function calls.
> Recursion stops when there's nothing left in the list, so the base case is
> the empty list. Since iterating over a list is so common in programming, it
> can start to feel like this is the way recursion and lists go together.
>
> But a good rule of thumb is only good if it doesn't trip you up when you
> com across an exception to the rule. In the problem of flattening a list,
> the recursion is down the depth of nesting, not across the list. In this
> case, you can stop flattening when you hit a non-list object, so that's
> your base case.
>
> Brad
>
> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>
>> Whether it looks pythonic or not Joshua, it works!  Try it before you
>> criticize it!!!   ;-)   In implementing recursive functions on lists, one
>> of the base cases is almost always whether the list is empty or not.  A
>> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
>> languages for sure, but they made me a stronger programmer when it comes to
>> the dreaded "R" ( Recursion ).   ;-)
>>
>>
>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <
>> bradley.marts at gmail.com> wrote:
>>
>>> > you can get almost there with itertools.chain.from_iterable
>>>
>>> It's tempting, but it fails in a lot of ways. It successfully flattens a
>>> list of lists, but doesn't go any deeper than that and fails completely on
>>> a list composed of some lists and some non-list objects. You can also get
>>> the same behavior out of a list comprehension.
>>>
>>> Douglas, you have written a recursive function, but I think you've
>>> missed on what the base case is. The base case is not whether or not you've
>>> been passed an empty list, but rather whether an element is a list or not
>>> (if it's not, you don't need any further flattening. Also, all those
>>> indices don't look very pythonic.
>>>
>>> Here is a recursive flatten function that will handle any depth and
>>> mixed depths at different elements (no indexing required)
>>>
>>> def flatten(lst):
>>>     new_list = []
>>>     for element in lst:
>>>         if isinstance(element, list):
>>>             new_list.extend(flatten(element))
>>>         else:
>>>             # This is the base case where the recursion ends
>>>             new_list.append(element)
>>>
>>>     return new_list
>>>
>>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>>
>>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com
>>> > wrote:
>>>
>>>> The idea of flattening a object or datatype is a functional programming
>>>> technique and not just a part of Ruby and Mathematica According to this
>>>> answer on the programming stack exchange there is no method / function that
>>>> implements flatten for build in Python functions but you can get almost
>>>> there with itertools.chain.from_iterable . See
>>>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>>>> .
>>>>
>>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
>>>> some time to just relax and mess around.  So I'm at my computer playing
>>>> around with Python and wondering how to resolve the issue of multiple lists
>>>> embedded within other lists.  I came up with two functions that I think
>>>> solve the problem.  But I was wondering if Guido or someone else added a
>>>> builtin function or method that does this automatically for the
>>>> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
>>>> wondering why I called the function "flatten" it's because I know from
>>>> experience that Wolfram Mathematica and Ocaml have these "flatten"
>>>> functions.  I think Ruby has something similar, but I haven't played with
>>>> Ruby in a while so I'm not really sure. )  The try: except block is
>>>> important because you can't subscript non-list data structures in Python.
>>>> The IndexError is what you get when you try to index an empty list.  So I
>>>> ****think**** my try: except block covers most commonly encountered
>>>> exceptions when working with lists embedded within other lists.
>>>>
>>>> Best,
>>>>
>>>> Douglas.
>>>>
>>>> def flatten(lst):
>>>> if lst == [ ]:
>>>> return lst
>>>> else:
>>>> try:
>>>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>>> except TypeError:
>>>> return [lst[0]] + flatten(lst[1:])
>>>> except IndexError:
>>>> return flatten(lst[1:])
>>>>
>>>> def flattenAgain(lst):
>>>> newList = lst[:]
>>>> while newList != flatten(newList):
>>>> newList = flatten(newList)
>>>> return newList
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/20160216/53a347af/attachment-0001.html>

From foresmac at gmail.com  Wed Feb 17 11:02:49 2016
From: foresmac at gmail.com (Chris Foresman)
Date: Wed, 17 Feb 2016 10:02:49 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
Message-ID: <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>

Honestly, Douglas, you come to the list all the time asking for help or opinions and then you precede to generally be a jerk to people that respond to you. The fact is your solution is sloppy, confusing, and doesn?t work at least as far as you originally explained it was supposed to work. Brad pointed all this out and suggested a vastly better alternative, and did so in an extremely polite way. Your response was just acerbic and doltish. Please consider either accepting constructive criticism with humility or just stop asking for help.


Regards,
Chris Foresman
chris at chrisforesman.com



> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
> 
> Use flattenAgain.... which calls flatten repeatedly until there's no change in the list.  You have to use BOTH functions!
> 
> Sarcasm?  What's that?
> 
> 
> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <bradley.marts at gmail.com <mailto:bradley.marts at gmail.com>> wrote:
> Douglas, I don't know if that was supposed to be sarcastic or what.
> 
> In fact, your code does not work. 
> 
> >>> flatten([[[1, 2], 3], 4])
> [[1, 2], 3, 4]
> 
> Looks like it fails to fully flatten the list.
> 
> I assumed from your original email you were interested in other approaches, so I gave one that looks to me like it's much less complex (no need for try/except, no need for indexing, 1 recursive call instead of 3). Less complex code is usually easier to reason about and less prone to bugs.
> 
> In purely functional languages there is no for loop, so if you want to iterate over a list, you have to do it with recursive function calls. Recursion stops when there's nothing left in the list, so the base case is the empty list. Since iterating over a list is so common in programming, it can start to feel like this is the way recursion and lists go together.
> 
> But a good rule of thumb is only good if it doesn't trip you up when you com across an exception to the rule. In the problem of flattening a list, the recursion is down the depth of nesting, not across the list. In this case, you can stop flattening when you hit a non-list object, so that's your base case.
> 
> Brad
> 
> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu <mailto:d-lewit at neiu.edu>> wrote:
> Whether it looks pythonic or not Joshua, it works!  Try it before you criticize it!!!   ;-)   In implementing recursive functions on lists, one of the base cases is almost always whether the list is empty or not.  A little lesson I learned from studying lists in Haskell and Ocaml.  Hard languages for sure, but they made me a stronger programmer when it comes to the dreaded "R" ( Recursion ).   ;-)  
> 
> 
> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <bradley.marts at gmail.com <mailto:bradley.marts at gmail.com>> wrote:
> > you can get almost there with itertools.chain.from_iterable
> 
> It's tempting, but it fails in a lot of ways. It successfully flattens a list of lists, but doesn't go any deeper than that and fails completely on a list composed of some lists and some non-list objects. You can also get the same behavior out of a list comprehension.
> 
> Douglas, you have written a recursive function, but I think you've missed on what the base case is. The base case is not whether or not you've been passed an empty list, but rather whether an element is a list or not (if it's not, you don't need any further flattening. Also, all those indices don't look very pythonic.
> 
> Here is a recursive flatten function that will handle any depth and mixed depths at different elements (no indexing required)
> 
> def flatten(lst):
>     new_list = []
>     for element in lst:
>         if isinstance(element, list):
>             new_list.extend(flatten(element))
>         else:
>             # This is the base case where the recursion ends
>             new_list.append(element)
> 
>     return new_list
> 
> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
> 
> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com <mailto:zitterbewegung at gmail.com>> wrote:
> The idea of flattening a object or datatype is a functional programming technique and not just a part of Ruby and Mathematica According to this answer on the programming stack exchange there is no method / function that implements flatten for build in Python functions but you can get almost there with itertools.chain.from_iterable . See http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists <http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists> .
>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu <mailto:d-lewit at neiu.edu>> wrote:
>> 
>> Hi everyone,
>> 
>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally some time to just relax and mess around.  So I'm at my computer playing around with Python and wondering how to resolve the issue of multiple lists embedded within other lists.  I came up with two functions that I think solve the problem.  But I was wondering if Guido or someone else added a builtin function or method that does this automatically for the programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're wondering why I called the function "flatten" it's because I know from experience that Wolfram Mathematica and Ocaml have these "flatten" functions.  I think Ruby has something similar, but I haven't played with Ruby in a while so I'm not really sure. )  The try: except block is important because you can't subscript non-list data structures in Python.  The IndexError is what you get when you try to index an empty list.  So I ****think**** my try: except block covers most commonly encountered exceptions when working with lists embedded within other lists.
>> 
>> Best,
>> 
>> Douglas.
>> 
>> def flatten(lst):
>> 	if lst == [ ]:
>> 		return lst
>> 	else:
>> 		try:
>> 			return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>> 		except TypeError:
>> 			return [lst[0]] + flatten(lst[1:])
>> 		except IndexError:
>> 			return flatten(lst[1:])
>> 
>> def flattenAgain(lst):
>> 	newList = lst[:]
>> 	while newList != flatten(newList):
>> 		newList = flatten(newList)
>> 	return newList
>> 
>> 
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org <mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago <https://mail.python.org/mailman/listinfo/chicago>
> 
> 
> _______________________________________________
> Chicago mailing list
> Chicago at python.org <mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago <https://mail.python.org/mailman/listinfo/chicago>
> 
> 
> 
> _______________________________________________
> Chicago mailing list
> Chicago at python.org <mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago <https://mail.python.org/mailman/listinfo/chicago>
> 
> 
> 
> _______________________________________________
> Chicago mailing list
> Chicago at python.org <mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago <https://mail.python.org/mailman/listinfo/chicago>
> 
> 
> 
> _______________________________________________
> Chicago mailing list
> Chicago at python.org <mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago <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/20160217/a2271052/attachment.html>

From adam at adamforsyth.net  Wed Feb 17 11:05:59 2016
From: adam at adamforsyth.net (Adam Forsyth)
Date: Wed, 17 Feb 2016 10:05:59 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
Message-ID: <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>

Hey everyone,

Please remember that intentions can be hard to judge on the mailing list.
I've met Douglas in person and he's a nice guy. Please don't assign motives
just because there are issues communicating.

Adam Forsyth
Sponsorship Director, ChiPy


On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com> wrote:

> Honestly, Douglas, you come to the list all the time asking for help or
> opinions and then you precede to generally be a jerk to people that respond
> to you. The fact is your solution is sloppy, confusing, and doesn?t work at
> least as far as you originally explained it was supposed to work. Brad
> pointed all this out and suggested a vastly better alternative, and did so
> in an extremely polite way. Your response was just acerbic and doltish.
> Please consider either accepting constructive criticism with humility or
> just stop asking for help.
>
>
> Regards,
> Chris Foresman
> chris at chrisforesman.com
>
>
>
> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>
> Use flattenAgain.... which calls flatten repeatedly until there's no
> change in the list.  You have to use BOTH functions!
>
> Sarcasm?  What's that?
>
>
> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <
> bradley.marts at gmail.com> wrote:
>
>> Douglas, I don't know if that was supposed to be sarcastic or what.
>>
>> In fact, your code does not work.
>>
>> >>> flatten([[[1, 2], 3], 4])
>> [[1, 2], 3, 4]
>>
>> Looks like it fails to fully flatten the list.
>>
>> I assumed from your original email you were interested in other
>> approaches, so I gave one that looks to me like it's much less complex (no
>> need for try/except, no need for indexing, 1 recursive call instead of 3).
>> Less complex code is usually easier to reason about and less prone to bugs.
>>
>> In purely functional languages there is no for loop, so if you want to
>> iterate over a list, you have to do it with recursive function calls.
>> Recursion stops when there's nothing left in the list, so the base case is
>> the empty list. Since iterating over a list is so common in programming, it
>> can start to feel like this is the way recursion and lists go together.
>>
>> But a good rule of thumb is only good if it doesn't trip you up when you
>> com across an exception to the rule. In the problem of flattening a list,
>> the recursion is down the depth of nesting, not across the list. In this
>> case, you can stop flattening when you hit a non-list object, so that's
>> your base case.
>>
>> Brad
>>
>> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>
>>> Whether it looks pythonic or not Joshua, it works!  Try it before you
>>> criticize it!!!   ;-)   In implementing recursive functions on lists, one
>>> of the base cases is almost always whether the list is empty or not.  A
>>> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
>>> languages for sure, but they made me a stronger programmer when it comes to
>>> the dreaded "R" ( Recursion ).   ;-)
>>>
>>>
>>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <
>>> bradley.marts at gmail.com> wrote:
>>>
>>>> > you can get almost there with itertools.chain.from_iterable
>>>>
>>>> It's tempting, but it fails in a lot of ways. It successfully flattens
>>>> a list of lists, but doesn't go any deeper than that and fails completely
>>>> on a list composed of some lists and some non-list objects. You can also
>>>> get the same behavior out of a list comprehension.
>>>>
>>>> Douglas, you have written a recursive function, but I think you've
>>>> missed on what the base case is. The base case is not whether or not you've
>>>> been passed an empty list, but rather whether an element is a list or not
>>>> (if it's not, you don't need any further flattening. Also, all those
>>>> indices don't look very pythonic.
>>>>
>>>> Here is a recursive flatten function that will handle any depth and
>>>> mixed depths at different elements (no indexing required)
>>>>
>>>> def flatten(lst):
>>>>     new_list = []
>>>>     for element in lst:
>>>>         if isinstance(element, list):
>>>>             new_list.extend(flatten(element))
>>>>         else:
>>>>             # This is the base case where the recursion ends
>>>>             new_list.append(element)
>>>>
>>>>     return new_list
>>>>
>>>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>>>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>>>
>>>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <
>>>> zitterbewegung at gmail.com> wrote:
>>>>
>>>>> The idea of flattening a object or datatype is a functional
>>>>> programming technique and not just a part of Ruby and Mathematica According
>>>>> to this answer on the programming stack exchange there is no method /
>>>>> function that implements flatten for build in Python functions but you can
>>>>> get almost there with itertools.chain.from_iterable . See
>>>>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>>>>> .
>>>>>
>>>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>>>>
>>>>> Hi everyone,
>>>>>
>>>>> Well it's President's Day and I've got the day off!  Hooray!!!
>>>>> Finally some time to just relax and mess around.  So I'm at my computer
>>>>> playing around with Python and wondering how to resolve the issue of
>>>>> multiple lists embedded within other lists.  I came up with two functions
>>>>> that I think solve the problem.  But I was wondering if Guido or someone
>>>>> else added a builtin function or method that does this automatically for
>>>>> the programmer.  Or is there an easier way?  Okay.... thanks.  ( In case
>>>>> you're wondering why I called the function "flatten" it's because I know
>>>>> from experience that Wolfram Mathematica and Ocaml have these "flatten"
>>>>> functions.  I think Ruby has something similar, but I haven't played with
>>>>> Ruby in a while so I'm not really sure. )  The try: except block is
>>>>> important because you can't subscript non-list data structures in Python.
>>>>> The IndexError is what you get when you try to index an empty list.  So I
>>>>> ****think**** my try: except block covers most commonly encountered
>>>>> exceptions when working with lists embedded within other lists.
>>>>>
>>>>> Best,
>>>>>
>>>>> Douglas.
>>>>>
>>>>> def flatten(lst):
>>>>> if lst == [ ]:
>>>>> return lst
>>>>> else:
>>>>> try:
>>>>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>>>> except TypeError:
>>>>> return [lst[0]] + flatten(lst[1:])
>>>>> except IndexError:
>>>>> return flatten(lst[1:])
>>>>>
>>>>> def flattenAgain(lst):
>>>>> newList = lst[:]
>>>>> while newList != flatten(newList):
>>>>> newList = flatten(newList)
>>>>> return newList
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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
>
>
>
> _______________________________________________
> 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/20160217/666018a4/attachment.html>

From shekay at pobox.com  Wed Feb 17 12:35:38 2016
From: shekay at pobox.com (sheila miguez)
Date: Wed, 17 Feb 2016 11:35:38 -0600
Subject: [Chicago] Python Project Night tomorrow @Braintree
Message-ID: <CAHCs_raHtFzorau8YMDjxhOfg_1xdkJt0LHe9NJhMa3WjVL7qA@mail.gmail.com>

Hi all,

The monthly Python Project Night is tomorrow! Come over to Braintree and
get help, talk through ideas, or just work alongside other Pythonistas.

RSVP here http://www.meetup.com/ChicagoPythonistas/events/224880680/


-- 
shekay at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160217/0b47c723/attachment.html>

From mikaeltamillow96 at gmail.com  Wed Feb 17 12:50:39 2016
From: mikaeltamillow96 at gmail.com (Mike Tamillow)
Date: Wed, 17 Feb 2016 11:50:39 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
Message-ID: <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>

Yeah, but I generally agree that this list shouldn't be used for help with personal programming problems. There is a website called stack overflow as well as much documentation that can be consulted for this.

What I like best is when messages come out exposing me to some open source tool I have yet to hear about that may be useful.

I'm sure there's other great discussions but I don't think code by email is quite a good thing to send out to hundreds of people.

Sent from my iPhone

> On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net> wrote:
> 
> Hey everyone,
> 
> Please remember that intentions can be hard to judge on the mailing list. I've met Douglas in person and he's a nice guy. Please don't assign motives just because there are issues communicating.
> 
> Adam Forsyth
> Sponsorship Director, ChiPy
> 
> 
>> On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com> wrote:
>> Honestly, Douglas, you come to the list all the time asking for help or opinions and then you precede to generally be a jerk to people that respond to you. The fact is your solution is sloppy, confusing, and doesn?t work at least as far as you originally explained it was supposed to work. Brad pointed all this out and suggested a vastly better alternative, and did so in an extremely polite way. Your response was just acerbic and doltish. Please consider either accepting constructive criticism with humility or just stop asking for help.
>> 
>> 
>> Regards,
>> Chris Foresman
>> chris at chrisforesman.com
>> 
>> 
>> 
>>> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>> 
>>> Use flattenAgain.... which calls flatten repeatedly until there's no change in the list.  You have to use BOTH functions!
>>> 
>>> Sarcasm?  What's that?
>>> 
>>> 
>>>> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <bradley.marts at gmail.com> wrote:
>>>> Douglas, I don't know if that was supposed to be sarcastic or what.
>>>> 
>>>> In fact, your code does not work. 
>>>> 
>>>> >>> flatten([[[1, 2], 3], 4])
>>>> [[1, 2], 3, 4]
>>>> 
>>>> Looks like it fails to fully flatten the list.
>>>> 
>>>> I assumed from your original email you were interested in other approaches, so I gave one that looks to me like it's much less complex (no need for try/except, no need for indexing, 1 recursive call instead of 3). Less complex code is usually easier to reason about and less prone to bugs.
>>>> 
>>>> In purely functional languages there is no for loop, so if you want to iterate over a list, you have to do it with recursive function calls. Recursion stops when there's nothing left in the list, so the base case is the empty list. Since iterating over a list is so common in programming, it can start to feel like this is the way recursion and lists go together.
>>>> 
>>>> But a good rule of thumb is only good if it doesn't trip you up when you com across an exception to the rule. In the problem of flattening a list, the recursion is down the depth of nesting, not across the list. In this case, you can stop flattening when you hit a non-list object, so that's your base case.
>>>> 
>>>> Brad
>>>> 
>>>>> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>>>> Whether it looks pythonic or not Joshua, it works!  Try it before you criticize it!!!   ;-)   In implementing recursive functions on lists, one of the base cases is almost always whether the list is empty or not.  A little lesson I learned from studying lists in Haskell and Ocaml.  Hard languages for sure, but they made me a stronger programmer when it comes to the dreaded "R" ( Recursion ).   ;-)  
>>>>> 
>>>>> 
>>>>>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <bradley.marts at gmail.com> wrote:
>>>>>> > you can get almost there with itertools.chain.from_iterable
>>>>>> 
>>>>>> It's tempting, but it fails in a lot of ways. It successfully flattens a list of lists, but doesn't go any deeper than that and fails completely on a list composed of some lists and some non-list objects. You can also get the same behavior out of a list comprehension.
>>>>>> 
>>>>>> Douglas, you have written a recursive function, but I think you've missed on what the base case is. The base case is not whether or not you've been passed an empty list, but rather whether an element is a list or not (if it's not, you don't need any further flattening. Also, all those indices don't look very pythonic.
>>>>>> 
>>>>>> Here is a recursive flatten function that will handle any depth and mixed depths at different elements (no indexing required)
>>>>>> 
>>>>>> def flatten(lst):
>>>>>>     new_list = []
>>>>>>     for element in lst:
>>>>>>         if isinstance(element, list):
>>>>>>             new_list.extend(flatten(element))
>>>>>>         else:
>>>>>>             # This is the base case where the recursion ends
>>>>>>             new_list.append(element)
>>>>>> 
>>>>>>     return new_list
>>>>>> 
>>>>>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>>>>>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>>>>> 
>>>>>>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com> wrote:
>>>>>>> The idea of flattening a object or datatype is a functional programming technique and not just a part of Ruby and Mathematica According to this answer on the programming stack exchange there is no method / function that implements flatten for build in Python functions but you can get almost there with itertools.chain.from_iterable . See http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists .
>>>>>>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>>>>>>> 
>>>>>>>> Hi everyone,
>>>>>>>> 
>>>>>>>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally some time to just relax and mess around.  So I'm at my computer playing around with Python and wondering how to resolve the issue of multiple lists embedded within other lists.  I came up with two functions that I think solve the problem.  But I was wondering if Guido or someone else added a builtin function or method that does this automatically for the programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're wondering why I called the function "flatten" it's because I know from experience that Wolfram Mathematica and Ocaml have these "flatten" functions.  I think Ruby has something similar, but I haven't played with Ruby in a while so I'm not really sure. )  The try: except block is important because you can't subscript non-list data structures in Python.  The IndexError is what you get when you try to index an empty list.  So I ****think**** my try: except block covers most commonly encountered exceptions when working with lists embedded within other lists.
>>>>>>>> 
>>>>>>>> Best,
>>>>>>>> 
>>>>>>>> Douglas.
>>>>>>>> 
>>>>>>>> def flatten(lst):
>>>>>>>> 	if lst == [ ]:
>>>>>>>> 		return lst
>>>>>>>> 	else:
>>>>>>>> 		try:
>>>>>>>> 			return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>>>>>>> 		except TypeError:
>>>>>>>> 			return [lst[0]] + flatten(lst[1:])
>>>>>>>> 		except IndexError:
>>>>>>>> 			return flatten(lst[1:])
>>>>>>>> 
>>>>>>>> def flattenAgain(lst):
>>>>>>>> 	newList = lst[:]
>>>>>>>> 	while newList != flatten(newList):
>>>>>>>> 		newList = flatten(newList)
>>>>>>>> 	return newList
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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
>> 
>> 
>> _______________________________________________
>> 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/20160217/3650257e/attachment.html>

From adam at adamforsyth.net  Wed Feb 17 15:08:20 2016
From: adam at adamforsyth.net (Adam Forsyth)
Date: Wed, 17 Feb 2016 14:08:20 -0600
Subject: [Chicago] Use of Python in the LIGO Project (Gravitation Wave
 Detection)
Message-ID: <CABrs+N9LALOsFwbr8+6dZtdP1TR-r=_5VpDr02z6atx=maGgcg@mail.gmail.com>

There was a great post of the PSF-Community mailing list
<https://mail.python.org/pipermail/psf-community/2016-February/000235.html>
about how Python played a role in the recent detection of gravitational
waves, as predicted by Einstein 100 years ago. I've reproduced it below.
Really, really amazing to see how the tools I used all the time for often
unimportant purposes can be used for huge, significant discoveries.

hello everyone in this wonderful community,

probably, we already know about the recent confirmation by LIGO
<http://www.ligo.org/> about existence of "gravitational waves", a major
prediction by the "theory of relativity" by Albert Einstein. It is a huge
milestone to human endeavour to understand nature.

what we may or may not know that Python was the de-facto language of
software components of the experimentation. It was extensively used in
day-to-day operations, from orchestrating the instruments[1], gathering
data, analytics, to generating the finally published pretty graphs[2].
Usage of Python, IPython notebook & matplotlib was extensive among the
team-members of LIGO.[3], [4]

i am not a part of LIGO, or any of the member organisations.
Rather, as a common enthusiast of natural-sciences as well as a open-source
believer, I would like to take a moment to thank every single contributor
of Python. Please keep up pushing your commits.
We facilitated something bigger than us.

i would also like to take a moment to remember our lost friend, John D.
Hunter, the creator of matplotlib. Whom we lost in 2012 in a battle with
cancer. Dear John, you are long gone, but you will live generations through
2-D matplotlib plots.


Thanks everyone.

Khaled Monsoor,
a common user of Python


refs:
[1]:https://www.reddit.com/r/IAmA/comments/45g8qu/we_are_the_ligo_scientific_collaboration_and_we/czxnlux
[2]: https://pbs.twimg.com/media/Ca8jlVIWcAUmeP8.png
[3]: https://losc.ligo.org/s/events/GW150914/GW150914_tutorial.html
[4]: https://github.com/ligo-cbc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160217/3068ccb5/attachment.html>

From shekay at pobox.com  Wed Feb 17 15:38:53 2016
From: shekay at pobox.com (sheila miguez)
Date: Wed, 17 Feb 2016 14:38:53 -0600
Subject: [Chicago] Use of Python in the LIGO Project (Gravitation Wave
 Detection)
In-Reply-To: <CABrs+N9LALOsFwbr8+6dZtdP1TR-r=_5VpDr02z6atx=maGgcg@mail.gmail.com>
References: <CABrs+N9LALOsFwbr8+6dZtdP1TR-r=_5VpDr02z6atx=maGgcg@mail.gmail.com>
Message-ID: <CAHCs_rY76ePy1Om2kGw3wQ6LCwEJYMduNWPv=oj8OT=pxQ0sNw@mail.gmail.com>

And someone created a binder for the tutorial.

http://mybinder.org/repo/minrk/ligo-binder/GW150914_tutorial.ipynb

On Wed, Feb 17, 2016 at 2:08 PM, Adam Forsyth <adam at adamforsyth.net> wrote:

> There was a great post of the PSF-Community mailing list
> <https://mail.python.org/pipermail/psf-community/2016-February/000235.html>
> about how Python played a role in the recent detection of gravitational
> waves, as predicted by Einstein 100 years ago. I've reproduced it below.
> Really, really amazing to see how the tools I used all the time for often
> unimportant purposes can be used for huge, significant discoveries.
>
> hello everyone in this wonderful community,
>
> probably, we already know about the recent confirmation by LIGO
> <http://www.ligo.org/> about existence of "gravitational waves", a major
> prediction by the "theory of relativity" by Albert Einstein. It is a huge
> milestone to human endeavour to understand nature.
>
> what we may or may not know that Python was the de-facto language of
> software components of the experimentation. It was extensively used in
> day-to-day operations, from orchestrating the instruments[1], gathering
> data, analytics, to generating the finally published pretty graphs[2].
> Usage of Python, IPython notebook & matplotlib was extensive among the
> team-members of LIGO.[3], [4]
>
> i am not a part of LIGO, or any of the member organisations.
> Rather, as a common enthusiast of natural-sciences as well as a open-source
> believer, I would like to take a moment to thank every single contributor
> of Python. Please keep up pushing your commits.
> We facilitated something bigger than us.
>
> i would also like to take a moment to remember our lost friend, John D.
> Hunter, the creator of matplotlib. Whom we lost in 2012 in a battle with
> cancer. Dear John, you are long gone, but you will live generations through
> 2-D matplotlib plots.
>
>
> Thanks everyone.
>
> Khaled Monsoor,
> a common user of Python
>
>
> refs:
> [1]:https://www.reddit.com/r/IAmA/comments/45g8qu/we_are_the_ligo_scientific_collaboration_and_we/czxnlux
> [2]: https://pbs.twimg.com/media/Ca8jlVIWcAUmeP8.png
> [3]: https://losc.ligo.org/s/events/GW150914/GW150914_tutorial.html
> [4]: https://github.com/ligo-cbc
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago
>
>


-- 
shekay at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160217/81cc393c/attachment.html>

From mgraves87 at gmail.com  Wed Feb 17 15:52:44 2016
From: mgraves87 at gmail.com (Mark Graves)
Date: Wed, 17 Feb 2016 14:52:44 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
Message-ID: <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>

I don't mean to be argumentative or add to this discussion in a negative
way.

Could we have a little direction from a higher up around the code of
conduct here?  For reference, this is the only one I found:

http://www.chipy.org/pages/conduct/

I am in support of Doug asking his questions and agree with Adam on this.
I've met Doug, and sometimes his humor is lost on people through the
mailing list.  If you are bothered, you can always create an email filter.

FWIW, imagine if the developer at the top of this list had been discouraged
from asking questions about his "unusual" implementation?

https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ

https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D






On Wed, Feb 17, 2016 at 11:50 AM, Mike Tamillow <mikaeltamillow96 at gmail.com>
wrote:

> Yeah, but I generally agree that this list shouldn't be used for help with
> personal programming problems. There is a website called stack overflow as
> well as much documentation that can be consulted for this.
>
> What I like best is when messages come out exposing me to some open source
> tool I have yet to hear about that may be useful.
>
> I'm sure there's other great discussions but I don't think code by email
> is quite a good thing to send out to hundreds of people.
>
> Sent from my iPhone
>
> On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net> wrote:
>
> Hey everyone,
>
> Please remember that intentions can be hard to judge on the mailing list.
> I've met Douglas in person and he's a nice guy. Please don't assign motives
> just because there are issues communicating.
>
> Adam Forsyth
> Sponsorship Director, ChiPy
>
>
> On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com>
> wrote:
>
>> Honestly, Douglas, you come to the list all the time asking for help or
>> opinions and then you precede to generally be a jerk to people that respond
>> to you. The fact is your solution is sloppy, confusing, and doesn?t work at
>> least as far as you originally explained it was supposed to work. Brad
>> pointed all this out and suggested a vastly better alternative, and did so
>> in an extremely polite way. Your response was just acerbic and doltish.
>> Please consider either accepting constructive criticism with humility or
>> just stop asking for help.
>>
>>
>> Regards,
>> Chris Foresman
>> chris at chrisforesman.com
>>
>>
>>
>> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>
>> Use flattenAgain.... which calls flatten repeatedly until there's no
>> change in the list.  You have to use BOTH functions!
>>
>> Sarcasm?  What's that?
>>
>>
>> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <
>> bradley.marts at gmail.com> wrote:
>>
>>> Douglas, I don't know if that was supposed to be sarcastic or what.
>>>
>>> In fact, your code does not work.
>>>
>>> >>> flatten([[[1, 2], 3], 4])
>>> [[1, 2], 3, 4]
>>>
>>> Looks like it fails to fully flatten the list.
>>>
>>> I assumed from your original email you were interested in other
>>> approaches, so I gave one that looks to me like it's much less complex (no
>>> need for try/except, no need for indexing, 1 recursive call instead of 3).
>>> Less complex code is usually easier to reason about and less prone to bugs.
>>>
>>> In purely functional languages there is no for loop, so if you want to
>>> iterate over a list, you have to do it with recursive function calls.
>>> Recursion stops when there's nothing left in the list, so the base case is
>>> the empty list. Since iterating over a list is so common in programming, it
>>> can start to feel like this is the way recursion and lists go together.
>>>
>>> But a good rule of thumb is only good if it doesn't trip you up when you
>>> com across an exception to the rule. In the problem of flattening a list,
>>> the recursion is down the depth of nesting, not across the list. In this
>>> case, you can stop flattening when you hit a non-list object, so that's
>>> your base case.
>>>
>>> Brad
>>>
>>> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu>
>>> wrote:
>>>
>>>> Whether it looks pythonic or not Joshua, it works!  Try it before you
>>>> criticize it!!!   ;-)   In implementing recursive functions on lists, one
>>>> of the base cases is almost always whether the list is empty or not.  A
>>>> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
>>>> languages for sure, but they made me a stronger programmer when it comes to
>>>> the dreaded "R" ( Recursion ).   ;-)
>>>>
>>>>
>>>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <
>>>> bradley.marts at gmail.com> wrote:
>>>>
>>>>> > you can get almost there with itertools.chain.from_iterable
>>>>>
>>>>> It's tempting, but it fails in a lot of ways. It successfully flattens
>>>>> a list of lists, but doesn't go any deeper than that and fails completely
>>>>> on a list composed of some lists and some non-list objects. You can also
>>>>> get the same behavior out of a list comprehension.
>>>>>
>>>>> Douglas, you have written a recursive function, but I think you've
>>>>> missed on what the base case is. The base case is not whether or not you've
>>>>> been passed an empty list, but rather whether an element is a list or not
>>>>> (if it's not, you don't need any further flattening. Also, all those
>>>>> indices don't look very pythonic.
>>>>>
>>>>> Here is a recursive flatten function that will handle any depth and
>>>>> mixed depths at different elements (no indexing required)
>>>>>
>>>>> def flatten(lst):
>>>>>     new_list = []
>>>>>     for element in lst:
>>>>>         if isinstance(element, list):
>>>>>             new_list.extend(flatten(element))
>>>>>         else:
>>>>>             # This is the base case where the recursion ends
>>>>>             new_list.append(element)
>>>>>
>>>>>     return new_list
>>>>>
>>>>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>>>>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>>>>
>>>>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <
>>>>> zitterbewegung at gmail.com> wrote:
>>>>>
>>>>>> The idea of flattening a object or datatype is a functional
>>>>>> programming technique and not just a part of Ruby and Mathematica According
>>>>>> to this answer on the programming stack exchange there is no method /
>>>>>> function that implements flatten for build in Python functions but you can
>>>>>> get almost there with itertools.chain.from_iterable . See
>>>>>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>>>>>> .
>>>>>>
>>>>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>>>>>
>>>>>> Hi everyone,
>>>>>>
>>>>>> Well it's President's Day and I've got the day off!  Hooray!!!
>>>>>> Finally some time to just relax and mess around.  So I'm at my computer
>>>>>> playing around with Python and wondering how to resolve the issue of
>>>>>> multiple lists embedded within other lists.  I came up with two functions
>>>>>> that I think solve the problem.  But I was wondering if Guido or someone
>>>>>> else added a builtin function or method that does this automatically for
>>>>>> the programmer.  Or is there an easier way?  Okay.... thanks.  ( In case
>>>>>> you're wondering why I called the function "flatten" it's because I know
>>>>>> from experience that Wolfram Mathematica and Ocaml have these "flatten"
>>>>>> functions.  I think Ruby has something similar, but I haven't played with
>>>>>> Ruby in a while so I'm not really sure. )  The try: except block is
>>>>>> important because you can't subscript non-list data structures in Python.
>>>>>> The IndexError is what you get when you try to index an empty list.  So I
>>>>>> ****think**** my try: except block covers most commonly encountered
>>>>>> exceptions when working with lists embedded within other lists.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Douglas.
>>>>>>
>>>>>> def flatten(lst):
>>>>>> if lst == [ ]:
>>>>>> return lst
>>>>>> else:
>>>>>> try:
>>>>>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>>>>> except TypeError:
>>>>>> return [lst[0]] + flatten(lst[1:])
>>>>>> except IndexError:
>>>>>> return flatten(lst[1:])
>>>>>>
>>>>>> def flattenAgain(lst):
>>>>>> newList = lst[:]
>>>>>> while newList != flatten(newList):
>>>>>> newList = flatten(newList)
>>>>>> return newList
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>> _______________________________________________
>> 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/20160217/b6108c78/attachment-0001.html>

From d-lewit at neiu.edu  Wed Feb 17 22:30:08 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Wed, 17 Feb 2016 21:30:08 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
Message-ID: <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>

Hi Mark,

Thanks for those links.  Yes, Linus Torvalds is quite a legend in his own
time.  I'll be content to become 1% of the programmer that he is!   :-)

My original question was simple, "*Does Python have a builtin function for
flattening lists?*"  It was a very simple question that provoked a very
strange and hostile thread!  I'm not sure why that is.  Anyhow, someone
mentioned *itertools.chain( )*.  Can someone provide a concrete example of
how that function works?  Or is that question inappropriate?  And please,
I'm just asking about itertools.chain( ).  I am not asking for any other
type of reply, okay?  Thank you.



On Wed, Feb 17, 2016 at 2:52 PM, Mark Graves <mgraves87 at gmail.com> wrote:

> I don't mean to be argumentative or add to this discussion in a negative
> way.
>
> Could we have a little direction from a higher up around the code of
> conduct here?  For reference, this is the only one I found:
>
> http://www.chipy.org/pages/conduct/
>
> I am in support of Doug asking his questions and agree with Adam on this.
> I've met Doug, and sometimes his humor is lost on people through the
> mailing list.  If you are bothered, you can always create an email filter.
>
> FWIW, imagine if the developer at the top of this list had been
> discouraged from asking questions about his "unusual" implementation?
>
>
> https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ
>
> https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D
>
>
>
>
>
>
> On Wed, Feb 17, 2016 at 11:50 AM, Mike Tamillow <
> mikaeltamillow96 at gmail.com> wrote:
>
>> Yeah, but I generally agree that this list shouldn't be used for help
>> with personal programming problems. There is a website called stack
>> overflow as well as much documentation that can be consulted for this.
>>
>> What I like best is when messages come out exposing me to some open
>> source tool I have yet to hear about that may be useful.
>>
>> I'm sure there's other great discussions but I don't think code by email
>> is quite a good thing to send out to hundreds of people.
>>
>> Sent from my iPhone
>>
>> On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net> wrote:
>>
>> Hey everyone,
>>
>> Please remember that intentions can be hard to judge on the mailing list.
>> I've met Douglas in person and he's a nice guy. Please don't assign motives
>> just because there are issues communicating.
>>
>> Adam Forsyth
>> Sponsorship Director, ChiPy
>>
>>
>> On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com>
>> wrote:
>>
>>> Honestly, Douglas, you come to the list all the time asking for help or
>>> opinions and then you precede to generally be a jerk to people that respond
>>> to you. The fact is your solution is sloppy, confusing, and doesn?t work at
>>> least as far as you originally explained it was supposed to work. Brad
>>> pointed all this out and suggested a vastly better alternative, and did so
>>> in an extremely polite way. Your response was just acerbic and doltish.
>>> Please consider either accepting constructive criticism with humility or
>>> just stop asking for help.
>>>
>>>
>>> Regards,
>>> Chris Foresman
>>> chris at chrisforesman.com
>>>
>>>
>>>
>>> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>>
>>> Use flattenAgain.... which calls flatten repeatedly until there's no
>>> change in the list.  You have to use BOTH functions!
>>>
>>> Sarcasm?  What's that?
>>>
>>>
>>> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <
>>> bradley.marts at gmail.com> wrote:
>>>
>>>> Douglas, I don't know if that was supposed to be sarcastic or what.
>>>>
>>>> In fact, your code does not work.
>>>>
>>>> >>> flatten([[[1, 2], 3], 4])
>>>> [[1, 2], 3, 4]
>>>>
>>>> Looks like it fails to fully flatten the list.
>>>>
>>>> I assumed from your original email you were interested in other
>>>> approaches, so I gave one that looks to me like it's much less complex (no
>>>> need for try/except, no need for indexing, 1 recursive call instead of 3).
>>>> Less complex code is usually easier to reason about and less prone to bugs.
>>>>
>>>> In purely functional languages there is no for loop, so if you want to
>>>> iterate over a list, you have to do it with recursive function calls.
>>>> Recursion stops when there's nothing left in the list, so the base case is
>>>> the empty list. Since iterating over a list is so common in programming, it
>>>> can start to feel like this is the way recursion and lists go together.
>>>>
>>>> But a good rule of thumb is only good if it doesn't trip you up when
>>>> you com across an exception to the rule. In the problem of flattening a
>>>> list, the recursion is down the depth of nesting, not across the list. In
>>>> this case, you can stop flattening when you hit a non-list object, so
>>>> that's your base case.
>>>>
>>>> Brad
>>>>
>>>> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu>
>>>> wrote:
>>>>
>>>>> Whether it looks pythonic or not Joshua, it works!  Try it before you
>>>>> criticize it!!!   ;-)   In implementing recursive functions on lists, one
>>>>> of the base cases is almost always whether the list is empty or not.  A
>>>>> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
>>>>> languages for sure, but they made me a stronger programmer when it comes to
>>>>> the dreaded "R" ( Recursion ).   ;-)
>>>>>
>>>>>
>>>>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <
>>>>> bradley.marts at gmail.com> wrote:
>>>>>
>>>>>> > you can get almost there with itertools.chain.from_iterable
>>>>>>
>>>>>> It's tempting, but it fails in a lot of ways. It successfully
>>>>>> flattens a list of lists, but doesn't go any deeper than that and fails
>>>>>> completely on a list composed of some lists and some non-list objects. You
>>>>>> can also get the same behavior out of a list comprehension.
>>>>>>
>>>>>> Douglas, you have written a recursive function, but I think you've
>>>>>> missed on what the base case is. The base case is not whether or not you've
>>>>>> been passed an empty list, but rather whether an element is a list or not
>>>>>> (if it's not, you don't need any further flattening. Also, all those
>>>>>> indices don't look very pythonic.
>>>>>>
>>>>>> Here is a recursive flatten function that will handle any depth and
>>>>>> mixed depths at different elements (no indexing required)
>>>>>>
>>>>>> def flatten(lst):
>>>>>>     new_list = []
>>>>>>     for element in lst:
>>>>>>         if isinstance(element, list):
>>>>>>             new_list.extend(flatten(element))
>>>>>>         else:
>>>>>>             # This is the base case where the recursion ends
>>>>>>             new_list.append(element)
>>>>>>
>>>>>>     return new_list
>>>>>>
>>>>>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>>>>>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>>>>>
>>>>>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <
>>>>>> zitterbewegung at gmail.com> wrote:
>>>>>>
>>>>>>> The idea of flattening a object or datatype is a functional
>>>>>>> programming technique and not just a part of Ruby and Mathematica According
>>>>>>> to this answer on the programming stack exchange there is no method /
>>>>>>> function that implements flatten for build in Python functions but you can
>>>>>>> get almost there with itertools.chain.from_iterable . See
>>>>>>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>>>>>>> .
>>>>>>>
>>>>>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Well it's President's Day and I've got the day off!  Hooray!!!
>>>>>>> Finally some time to just relax and mess around.  So I'm at my computer
>>>>>>> playing around with Python and wondering how to resolve the issue of
>>>>>>> multiple lists embedded within other lists.  I came up with two functions
>>>>>>> that I think solve the problem.  But I was wondering if Guido or someone
>>>>>>> else added a builtin function or method that does this automatically for
>>>>>>> the programmer.  Or is there an easier way?  Okay.... thanks.  ( In case
>>>>>>> you're wondering why I called the function "flatten" it's because I know
>>>>>>> from experience that Wolfram Mathematica and Ocaml have these "flatten"
>>>>>>> functions.  I think Ruby has something similar, but I haven't played with
>>>>>>> Ruby in a while so I'm not really sure. )  The try: except block is
>>>>>>> important because you can't subscript non-list data structures in Python.
>>>>>>> The IndexError is what you get when you try to index an empty list.  So I
>>>>>>> ****think**** my try: except block covers most commonly encountered
>>>>>>> exceptions when working with lists embedded within other lists.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Douglas.
>>>>>>>
>>>>>>> def flatten(lst):
>>>>>>> if lst == [ ]:
>>>>>>> return lst
>>>>>>> else:
>>>>>>> try:
>>>>>>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>>>>>> except TypeError:
>>>>>>> return [lst[0]] + flatten(lst[1:])
>>>>>>> except IndexError:
>>>>>>> return flatten(lst[1:])
>>>>>>>
>>>>>>> def flattenAgain(lst):
>>>>>>> newList = lst[:]
>>>>>>> while newList != flatten(newList):
>>>>>>> newList = flatten(newList)
>>>>>>> return newList
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20160217/d7ccfdf9/attachment.html>

From MDiPierro at cs.depaul.edu  Wed Feb 17 22:48:30 2016
From: MDiPierro at cs.depaul.edu (DiPierro, Massimo)
Date: Thu, 18 Feb 2016 03:48:30 +0000
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
Message-ID: <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>

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]



On Feb 17, 2016, at 9:30 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:d-lewit at neiu.edu>> wrote:

Hi Mark,

Thanks for those links.  Yes, Linus Torvalds is quite a legend in his own time.  I'll be content to become 1% of the programmer that he is!   :-)

My original question was simple, "Does Python have a builtin function for flattening lists?"  It was a very simple question that provoked a very strange and hostile thread!  I'm not sure why that is.  Anyhow, someone mentioned itertools.chain( ).  Can someone provide a concrete example of how that function works?  Or is that question inappropriate?  And please, I'm just asking about itertools.chain( ).  I am not asking for any other type of reply, okay?  Thank you.



On Wed, Feb 17, 2016 at 2:52 PM, Mark Graves <mgraves87 at gmail.com<mailto:mgraves87 at gmail.com>> wrote:
I don't mean to be argumentative or add to this discussion in a negative way.

Could we have a little direction from a higher up around the code of conduct here?  For reference, this is the only one I found:

http://www.chipy.org/pages/conduct/

I am in support of Doug asking his questions and agree with Adam on this. I've met Doug, and sometimes his humor is lost on people through the mailing list.  If you are bothered, you can always create an email filter.

FWIW, imagine if the developer at the top of this list had been discouraged from asking questions about his "unusual" implementation?

https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ

https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D







On Wed, Feb 17, 2016 at 11:50 AM, Mike Tamillow <mikaeltamillow96 at gmail.com<mailto:mikaeltamillow96 at gmail.com>> wrote:
Yeah, but I generally agree that this list shouldn't be used for help with personal programming problems. There is a website called stack overflow as well as much documentation that can be consulted for this.

What I like best is when messages come out exposing me to some open source tool I have yet to hear about that may be useful.

I'm sure there's other great discussions but I don't think code by email is quite a good thing to send out to hundreds of people.

Sent from my iPhone

On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net<mailto:adam at adamforsyth.net>> wrote:

Hey everyone,

Please remember that intentions can be hard to judge on the mailing list. I've met Douglas in person and he's a nice guy. Please don't assign motives just because there are issues communicating.

Adam Forsyth
Sponsorship Director, ChiPy


On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com<mailto:foresmac at gmail.com>> wrote:
Honestly, Douglas, you come to the list all the time asking for help or opinions and then you precede to generally be a jerk to people that respond to you. The fact is your solution is sloppy, confusing, and doesn?t work at least as far as you originally explained it was supposed to work. Brad pointed all this out and suggested a vastly better alternative, and did so in an extremely polite way. Your response was just acerbic and doltish. Please consider either accepting constructive criticism with humility or just stop asking for help.


Regards,
Chris Foresman
chris at chrisforesman.com<mailto:chris at chrisforesman.com>



On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:d-lewit at neiu.edu>> wrote:

Use flattenAgain.... which calls flatten repeatedly until there's no change in the list.  You have to use BOTH functions!

Sarcasm?  What's that?


On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
Douglas, I don't know if that was supposed to be sarcastic or what.

In fact, your code does not work.

>>> flatten([[[1, 2], 3], 4])
[[1, 2], 3, 4]

Looks like it fails to fully flatten the list.

I assumed from your original email you were interested in other approaches, so I gave one that looks to me like it's much less complex (no need for try/except, no need for indexing, 1 recursive call instead of 3). Less complex code is usually easier to reason about and less prone to bugs.

In purely functional languages there is no for loop, so if you want to iterate over a list, you have to do it with recursive function calls. Recursion stops when there's nothing left in the list, so the base case is the empty list. Since iterating over a list is so common in programming, it can start to feel like this is the way recursion and lists go together.

But a good rule of thumb is only good if it doesn't trip you up when you com across an exception to the rule. In the problem of flattening a list, the recursion is down the depth of nesting, not across the list. In this case, you can stop flattening when you hit a non-list object, so that's your base case.

Brad

On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:d-lewit at neiu.edu>> wrote:
Whether it looks pythonic or not Joshua, it works!  Try it before you criticize it!!!   ;-)   In implementing recursive functions on lists, one of the base cases is almost always whether the list is empty or not.  A little lesson I learned from studying lists in Haskell and Ocaml.  Hard languages for sure, but they made me a stronger programmer when it comes to the dreaded "R" ( Recursion ).   ;-)


On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
> you can get almost there with itertools.chain.from_iterable

It's tempting, but it fails in a lot of ways. It successfully flattens a list of lists, but doesn't go any deeper than that and fails completely on a list composed of some lists and some non-list objects. You can also get the same behavior out of a list comprehension.

Douglas, you have written a recursive function, but I think you've missed on what the base case is. The base case is not whether or not you've been passed an empty list, but rather whether an element is a list or not (if it's not, you don't need any further flattening. Also, all those indices don't look very pythonic.

Here is a recursive flatten function that will handle any depth and mixed depths at different elements (no indexing required)

def flatten(lst):
    new_list = []
    for element in lst:
        if isinstance(element, list):
            new_list.extend(flatten(element))
        else:
            # This is the base case where the recursion ends
            new_list.append(element)

    return new_list

>>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
[1, 1.1, 2, 3, 4, 5, 6, 7, 8]

On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com<mailto:zitterbewegung at gmail.com>> wrote:
The idea of flattening a object or datatype is a functional programming technique and not just a part of Ruby and Mathematica According to this answer on the programming stack exchange there is no method / function that implements flatten for build in Python functions but you can get almost there with itertools.chain.from_iterable . See http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists .
On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:d-lewit at neiu.edu>> wrote:

Hi everyone,

Well it's President's Day and I've got the day off!  Hooray!!!  Finally some time to just relax and mess around.  So I'm at my computer playing around with Python and wondering how to resolve the issue of multiple lists embedded within other lists.  I came up with two functions that I think solve the problem.  But I was wondering if Guido or someone else added a builtin function or method that does this automatically for the programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're wondering why I called the function "flatten" it's because I know from experience that Wolfram Mathematica and Ocaml have these "flatten" functions.  I think Ruby has something similar, but I haven't played with Ruby in a while so I'm not really sure. )  The try: except block is important because you can't subscript non-list data structures in Python.  The IndexError is what you get when you try to index an empty list.  So I ****think**** my try: except block covers most commonly encountered exceptions when working with lists embedded within other lists.

Best,

Douglas.

def flatten(lst):
if lst == [ ]:
return lst
else:
try:
return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
except TypeError:
return [lst[0]] + flatten(lst[1:])
except IndexError:
return flatten(lst[1:])

def flattenAgain(lst):
newList = lst[:]
while newList != flatten(newList):
newList = flatten(newList)
return newList


_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago


_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago



_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago



_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago



_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago


_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago


_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago


_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago

_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago



_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago


_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago


From adam at adamforsyth.net  Wed Feb 17 23:03:58 2016
From: adam at adamforsyth.net (Adam Forsyth)
Date: Wed, 17 Feb 2016 22:03:58 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
Message-ID: <CABrs+N9sqB+WffMAUiYbMZeB-FpqEYGh_MQKp1fTLr2rsJ00mw@mail.gmail.com>

If there is any more meta-discussion, please keep it off-list, or at least
start a separate thread. This thread is about flattening lists.

Mark,

Programming questions have been on-topic for this list as long as I've been
around (about four years, two as an organizer), so I'm also in support of
questions like this one. Like Douglas, I've asked questions here when I
wanted to open a discussion rather than just get a one-off technical answer
(which is what Stack Overflow is for).

As far as the code of conduct goes, the organizers spoke to a couple of
people about the tone of their replies in this thread, and I hope we're all
on the same page now about what the expected behavior is in the future --
it's outlined in the code of conduct, but in this case it comes down to
treating everyone with respect and communicating politely and with
patience. If anyone consistently fails to do that, they'll be asked to
leave the list.

If you feel anyone on the list isn't behaving appropriately, please let
them and / or the organizers know (chicago-organizers at python.org) rather
than responding in kind.


As I said at the beginning, if there is any more discussion of these
issues, please keep it off the list, or if anyone really wants to reply to
the whole group, do it in a separate thread.

Best,
Adam


On Wed, Feb 17, 2016 at 2:52 PM, Mark Graves <mgraves87 at gmail.com> wrote:

> I don't mean to be argumentative or add to this discussion in a negative
> way.
>
> Could we have a little direction from a higher up around the code of
> conduct here?  For reference, this is the only one I found:
>
> http://www.chipy.org/pages/conduct/
>
> I am in support of Doug asking his questions and agree with Adam on this.
> I've met Doug, and sometimes his humor is lost on people through the
> mailing list.  If you are bothered, you can always create an email filter.
>
> FWIW, imagine if the developer at the top of this list had been
> discouraged from asking questions about his "unusual" implementation?
>
>
> https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ
>
> https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D
>
>
>
>
>
>
> On Wed, Feb 17, 2016 at 11:50 AM, Mike Tamillow <
> mikaeltamillow96 at gmail.com> wrote:
>
>> Yeah, but I generally agree that this list shouldn't be used for help
>> with personal programming problems. There is a website called stack
>> overflow as well as much documentation that can be consulted for this.
>>
>> What I like best is when messages come out exposing me to some open
>> source tool I have yet to hear about that may be useful.
>>
>> I'm sure there's other great discussions but I don't think code by email
>> is quite a good thing to send out to hundreds of people.
>>
>> Sent from my iPhone
>>
>> On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net> wrote:
>>
>> Hey everyone,
>>
>> Please remember that intentions can be hard to judge on the mailing list.
>> I've met Douglas in person and he's a nice guy. Please don't assign motives
>> just because there are issues communicating.
>>
>> Adam Forsyth
>> Sponsorship Director, ChiPy
>>
>>
>> On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com>
>> wrote:
>>
>>> Honestly, Douglas, you come to the list all the time asking for help or
>>> opinions and then you precede to generally be a jerk to people that respond
>>> to you. The fact is your solution is sloppy, confusing, and doesn?t work at
>>> least as far as you originally explained it was supposed to work. Brad
>>> pointed all this out and suggested a vastly better alternative, and did so
>>> in an extremely polite way. Your response was just acerbic and doltish.
>>> Please consider either accepting constructive criticism with humility or
>>> just stop asking for help.
>>>
>>>
>>> Regards,
>>> Chris Foresman
>>> chris at chrisforesman.com
>>>
>>>
>>>
>>> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>>>
>>> Use flattenAgain.... which calls flatten repeatedly until there's no
>>> change in the list.  You have to use BOTH functions!
>>>
>>> Sarcasm?  What's that?
>>>
>>>
>>> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <
>>> bradley.marts at gmail.com> wrote:
>>>
>>>> Douglas, I don't know if that was supposed to be sarcastic or what.
>>>>
>>>> In fact, your code does not work.
>>>>
>>>> >>> flatten([[[1, 2], 3], 4])
>>>> [[1, 2], 3, 4]
>>>>
>>>> Looks like it fails to fully flatten the list.
>>>>
>>>> I assumed from your original email you were interested in other
>>>> approaches, so I gave one that looks to me like it's much less complex (no
>>>> need for try/except, no need for indexing, 1 recursive call instead of 3).
>>>> Less complex code is usually easier to reason about and less prone to bugs.
>>>>
>>>> In purely functional languages there is no for loop, so if you want to
>>>> iterate over a list, you have to do it with recursive function calls.
>>>> Recursion stops when there's nothing left in the list, so the base case is
>>>> the empty list. Since iterating over a list is so common in programming, it
>>>> can start to feel like this is the way recursion and lists go together.
>>>>
>>>> But a good rule of thumb is only good if it doesn't trip you up when
>>>> you com across an exception to the rule. In the problem of flattening a
>>>> list, the recursion is down the depth of nesting, not across the list. In
>>>> this case, you can stop flattening when you hit a non-list object, so
>>>> that's your base case.
>>>>
>>>> Brad
>>>>
>>>> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu>
>>>> wrote:
>>>>
>>>>> Whether it looks pythonic or not Joshua, it works!  Try it before you
>>>>> criticize it!!!   ;-)   In implementing recursive functions on lists, one
>>>>> of the base cases is almost always whether the list is empty or not.  A
>>>>> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
>>>>> languages for sure, but they made me a stronger programmer when it comes to
>>>>> the dreaded "R" ( Recursion ).   ;-)
>>>>>
>>>>>
>>>>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <
>>>>> bradley.marts at gmail.com> wrote:
>>>>>
>>>>>> > you can get almost there with itertools.chain.from_iterable
>>>>>>
>>>>>> It's tempting, but it fails in a lot of ways. It successfully
>>>>>> flattens a list of lists, but doesn't go any deeper than that and fails
>>>>>> completely on a list composed of some lists and some non-list objects. You
>>>>>> can also get the same behavior out of a list comprehension.
>>>>>>
>>>>>> Douglas, you have written a recursive function, but I think you've
>>>>>> missed on what the base case is. The base case is not whether or not you've
>>>>>> been passed an empty list, but rather whether an element is a list or not
>>>>>> (if it's not, you don't need any further flattening. Also, all those
>>>>>> indices don't look very pythonic.
>>>>>>
>>>>>> Here is a recursive flatten function that will handle any depth and
>>>>>> mixed depths at different elements (no indexing required)
>>>>>>
>>>>>> def flatten(lst):
>>>>>>     new_list = []
>>>>>>     for element in lst:
>>>>>>         if isinstance(element, list):
>>>>>>             new_list.extend(flatten(element))
>>>>>>         else:
>>>>>>             # This is the base case where the recursion ends
>>>>>>             new_list.append(element)
>>>>>>
>>>>>>     return new_list
>>>>>>
>>>>>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>>>>>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>>>>>
>>>>>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <
>>>>>> zitterbewegung at gmail.com> wrote:
>>>>>>
>>>>>>> The idea of flattening a object or datatype is a functional
>>>>>>> programming technique and not just a part of Ruby and Mathematica According
>>>>>>> to this answer on the programming stack exchange there is no method /
>>>>>>> function that implements flatten for build in Python functions but you can
>>>>>>> get almost there with itertools.chain.from_iterable . See
>>>>>>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>>>>>>> .
>>>>>>>
>>>>>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi everyone,
>>>>>>>
>>>>>>> Well it's President's Day and I've got the day off!  Hooray!!!
>>>>>>> Finally some time to just relax and mess around.  So I'm at my computer
>>>>>>> playing around with Python and wondering how to resolve the issue of
>>>>>>> multiple lists embedded within other lists.  I came up with two functions
>>>>>>> that I think solve the problem.  But I was wondering if Guido or someone
>>>>>>> else added a builtin function or method that does this automatically for
>>>>>>> the programmer.  Or is there an easier way?  Okay.... thanks.  ( In case
>>>>>>> you're wondering why I called the function "flatten" it's because I know
>>>>>>> from experience that Wolfram Mathematica and Ocaml have these "flatten"
>>>>>>> functions.  I think Ruby has something similar, but I haven't played with
>>>>>>> Ruby in a while so I'm not really sure. )  The try: except block is
>>>>>>> important because you can't subscript non-list data structures in Python.
>>>>>>> The IndexError is what you get when you try to index an empty list.  So I
>>>>>>> ****think**** my try: except block covers most commonly encountered
>>>>>>> exceptions when working with lists embedded within other lists.
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Douglas.
>>>>>>>
>>>>>>> def flatten(lst):
>>>>>>> if lst == [ ]:
>>>>>>> return lst
>>>>>>> else:
>>>>>>> try:
>>>>>>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>>>>>> except TypeError:
>>>>>>> return [lst[0]] + flatten(lst[1:])
>>>>>>> except IndexError:
>>>>>>> return flatten(lst[1:])
>>>>>>>
>>>>>>> def flattenAgain(lst):
>>>>>>> newList = lst[:]
>>>>>>> while newList != flatten(newList):
>>>>>>> newList = flatten(newList)
>>>>>>> return newList
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>
>>>
>>>
>>> _______________________________________________
>>> 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
>>
>>
>
> _______________________________________________
> 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/20160217/934e3b0c/attachment-0001.html>

From d-lewit at neiu.edu  Thu Feb 18 00:21:54 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Wed, 17 Feb 2016 23:21:54 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
Message-ID: <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>

Hey Massimo,

That one-liner is so cool!  Thanks!  Simple and gets the job done.  Thanks
for sharing.

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]
>
>
>
> On Feb 17, 2016, at 9:30 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
> d-lewit at neiu.edu>> wrote:
>
> Hi Mark,
>
> Thanks for those links.  Yes, Linus Torvalds is quite a legend in his own
> time.  I'll be content to become 1% of the programmer that he is!   :-)
>
> My original question was simple, "Does Python have a builtin function for
> flattening lists?"  It was a very simple question that provoked a very
> strange and hostile thread!  I'm not sure why that is.  Anyhow, someone
> mentioned itertools.chain( ).  Can someone provide a concrete example of
> how that function works?  Or is that question inappropriate?  And please,
> I'm just asking about itertools.chain( ).  I am not asking for any other
> type of reply, okay?  Thank you.
>
>
>
> On Wed, Feb 17, 2016 at 2:52 PM, Mark Graves <mgraves87 at gmail.com<mailto:
> mgraves87 at gmail.com>> wrote:
> I don't mean to be argumentative or add to this discussion in a negative
> way.
>
> Could we have a little direction from a higher up around the code of
> conduct here?  For reference, this is the only one I found:
>
> http://www.chipy.org/pages/conduct/
>
> I am in support of Doug asking his questions and agree with Adam on this.
> I've met Doug, and sometimes his humor is lost on people through the
> mailing list.  If you are bothered, you can always create an email filter.
>
> FWIW, imagine if the developer at the top of this list had been
> discouraged from asking questions about his "unusual" implementation?
>
>
> https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ
>
> https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D
>
>
>
>
>
>
>
> On Wed, Feb 17, 2016 at 11:50 AM, Mike Tamillow <
> mikaeltamillow96 at gmail.com<mailto:mikaeltamillow96 at gmail.com>> wrote:
> Yeah, but I generally agree that this list shouldn't be used for help with
> personal programming problems. There is a website called stack overflow as
> well as much documentation that can be consulted for this.
>
> What I like best is when messages come out exposing me to some open source
> tool I have yet to hear about that may be useful.
>
> I'm sure there's other great discussions but I don't think code by email
> is quite a good thing to send out to hundreds of people.
>
> Sent from my iPhone
>
> On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net<mailto:
> adam at adamforsyth.net>> wrote:
>
> Hey everyone,
>
> Please remember that intentions can be hard to judge on the mailing list.
> I've met Douglas in person and he's a nice guy. Please don't assign motives
> just because there are issues communicating.
>
> Adam Forsyth
> Sponsorship Director, ChiPy
>
>
> On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com
> <mailto:foresmac at gmail.com>> wrote:
> Honestly, Douglas, you come to the list all the time asking for help or
> opinions and then you precede to generally be a jerk to people that respond
> to you. The fact is your solution is sloppy, confusing, and doesn?t work at
> least as far as you originally explained it was supposed to work. Brad
> pointed all this out and suggested a vastly better alternative, and did so
> in an extremely polite way. Your response was just acerbic and doltish.
> Please consider either accepting constructive criticism with humility or
> just stop asking for help.
>
>
> Regards,
> Chris Foresman
> chris at chrisforesman.com<mailto:chris at chrisforesman.com>
>
>
>
> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
> d-lewit at neiu.edu>> wrote:
>
> Use flattenAgain.... which calls flatten repeatedly until there's no
> change in the list.  You have to use BOTH functions!
>
> Sarcasm?  What's that?
>
>
> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <
> bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
> Douglas, I don't know if that was supposed to be sarcastic or what.
>
> In fact, your code does not work.
>
> >>> flatten([[[1, 2], 3], 4])
> [[1, 2], 3, 4]
>
> Looks like it fails to fully flatten the list.
>
> I assumed from your original email you were interested in other
> approaches, so I gave one that looks to me like it's much less complex (no
> need for try/except, no need for indexing, 1 recursive call instead of 3).
> Less complex code is usually easier to reason about and less prone to bugs.
>
> In purely functional languages there is no for loop, so if you want to
> iterate over a list, you have to do it with recursive function calls.
> Recursion stops when there's nothing left in the list, so the base case is
> the empty list. Since iterating over a list is so common in programming, it
> can start to feel like this is the way recursion and lists go together.
>
> But a good rule of thumb is only good if it doesn't trip you up when you
> com across an exception to the rule. In the problem of flattening a list,
> the recursion is down the depth of nesting, not across the list. In this
> case, you can stop flattening when you hit a non-list object, so that's
> your base case.
>
> Brad
>
> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
> d-lewit at neiu.edu>> wrote:
> Whether it looks pythonic or not Joshua, it works!  Try it before you
> criticize it!!!   ;-)   In implementing recursive functions on lists, one
> of the base cases is almost always whether the list is empty or not.  A
> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
> languages for sure, but they made me a stronger programmer when it comes to
> the dreaded "R" ( Recursion ).   ;-)
>
>
> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <bradley.marts at gmail.com
> <mailto:bradley.marts at gmail.com>> wrote:
> > you can get almost there with itertools.chain.from_iterable
>
> It's tempting, but it fails in a lot of ways. It successfully flattens a
> list of lists, but doesn't go any deeper than that and fails completely on
> a list composed of some lists and some non-list objects. You can also get
> the same behavior out of a list comprehension.
>
> Douglas, you have written a recursive function, but I think you've missed
> on what the base case is. The base case is not whether or not you've been
> passed an empty list, but rather whether an element is a list or not (if
> it's not, you don't need any further flattening. Also, all those indices
> don't look very pythonic.
>
> Here is a recursive flatten function that will handle any depth and mixed
> depths at different elements (no indexing required)
>
> def flatten(lst):
>     new_list = []
>     for element in lst:
>         if isinstance(element, list):
>             new_list.extend(flatten(element))
>         else:
>             # This is the base case where the recursion ends
>             new_list.append(element)
>
>     return new_list
>
> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>
> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com
> <mailto:zitterbewegung at gmail.com>> wrote:
> The idea of flattening a object or datatype is a functional programming
> technique and not just a part of Ruby and Mathematica According to this
> answer on the programming stack exchange there is no method / function that
> implements flatten for build in Python functions but you can get almost
> there with itertools.chain.from_iterable . See
> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
> .
> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
> d-lewit at neiu.edu>> wrote:
>
> Hi everyone,
>
> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
> some time to just relax and mess around.  So I'm at my computer playing
> around with Python and wondering how to resolve the issue of multiple lists
> embedded within other lists.  I came up with two functions that I think
> solve the problem.  But I was wondering if Guido or someone else added a
> builtin function or method that does this automatically for the
> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
> wondering why I called the function "flatten" it's because I know from
> experience that Wolfram Mathematica and Ocaml have these "flatten"
> functions.  I think Ruby has something similar, but I haven't played with
> Ruby in a while so I'm not really sure. )  The try: except block is
> important because you can't subscript non-list data structures in Python.
> The IndexError is what you get when you try to index an empty list.  So I
> ****think**** my try: except block covers most commonly encountered
> exceptions when working with lists embedded within other lists.
>
> Best,
>
> Douglas.
>
> def flatten(lst):
> if lst == [ ]:
> return lst
> else:
> try:
> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
> except TypeError:
> return [lst[0]] + flatten(lst[1:])
> except IndexError:
> return flatten(lst[1:])
>
> def flattenAgain(lst):
> newList = lst[:]
> while newList != flatten(newList):
> newList = flatten(newList)
> return newList
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto: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/20160217/a14f315c/attachment.html>

From joe.jasinski at gmail.com  Thu Feb 18 01:15:41 2016
From: joe.jasinski at gmail.com (Joe Jasinski)
Date: Thu, 18 Feb 2016 00:15:41 -0600
Subject: [Chicago] ChiPy Design T-Shirt Contest
In-Reply-To: <CACdfcwUhjb0iuuvwVt+aaHRBVo9g6_-QLmXokPie43fUupr25A@mail.gmail.com>
References: <CACdfcwXB_TcCQLKYzLU12+PsiT-svrfeODTJRRkDrdbCNOj4Ow@mail.gmail.com>
 <CACdfcwUhjb0iuuvwVt+aaHRBVo9g6_-QLmXokPie43fUupr25A@mail.gmail.com>
Message-ID: <CACdfcwXbRu23E9EOGOVtnAQ6qVS27CLwfKbG5_DVSeOhDzZyXA@mail.gmail.com>

Hey ChiPy,

As you know, we were looking to the ChiPy membership to submit designs that
can be voted on  for our new ChiPy T-shirt.

We finally have enough T-shirt designs to have a vote!  Please vote for
your favorite designs via the form linked.

https://docs.google.com/forms/d/135bRwZgyIIiEoAusGpfmyn9yIeY7_ovZuAuO4BjBX3s/viewform

I look forward to seeing the results!

Joe


On Tue, Oct 13, 2015 at 9:27 PM, Joe Jasinski <joe.jasinski at gmail.com>
wrote:

> Hey all,
>
> ChiPy is still looking for submissions for a ChiPy T-shirt design. I've
> also created a page <http://www.chipy.org/pages/tshirts/> on the ChiPy
> website so you can easily share the details of the competition with your
> friends.
>
> To submit, I've created a dropbox location to upload files to. Note: you
> do not need a Dropbox account to submit.
>
> https://www.dropbox.com/request/V7UapyG5u7CoQGeXB2US
>
> If you are looking for inspiration, see some of the examples below from
> recent Python-related T-shirts.
>
>
>    - Djangocon 2015
>    <https://twitter.com/djangocon/status/642439235207741440>
>    - OpenStack T-Shirt Contest
>    <http://www.openstack.org/blog/2014/04/openstack-2014-t-shirt-design-winner/>
>    - Django 1.7 Release Shirt <https://teespring.com/django17-v2>
>    - Django 1.8 Release Shirt
>    <https://fabrily.com/django18>
>
>
> We look forward to seeing your designs!
>
>
> On Sun, Sep 13, 2015 at 11:06 PM, Joe Jasinski <joe.jasinski at gmail.com>
> wrote:
>
>> Hi All,
>>
>> ChiPy is planning on creating an official ChiPy T-shirt, and we are
>> looking for your help!
>>
>> We'd like to open up the T-shirt design process to the ChiPy community
>> (and friends) and make a contest of T-shirt design submissions.  Once we
>> have enough artwork submissions, we as a ChiPy community will vote on the
>> design that we'd like to print.
>>
>> The winner of the vote will win 2 free T-shirts with the design!   The
>> winning design will be printed on the front of a white T-shirt.
>>
>> Here are the requirements for the artwork.  The artwork...
>>
>>  - should relate to the Python and ChiPy community (with the ChiPy name
>> or logo)
>>  - can use any number of colors
>>  - should be in PDF or PNG file format at 300DPI. (EPS or AI file format
>> would also work)
>>  - should fit within a 12x12 inch print region
>>
>> Please email me your artwork submission and I look forward to seeing some
>> creative ChiPy T-shirt designs!
>>
>> Joe
>>
>>
>> --
>> Joe J. Jasinski
>> www.joejasinski.com
>>
>
>
>
> --
> Joe J. Jasinski
> www.joejasinski.com
>



-- 
Joe J. Jasinski
www.joejasinski.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160218/301d4ef9/attachment.html>

From mikaeltamillow96 at gmail.com  Thu Feb 18 07:48:33 2016
From: mikaeltamillow96 at gmail.com (Mike Tamillow)
Date: Thu, 18 Feb 2016 06:48:33 -0600
Subject: [Chicago] The list
Message-ID: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>

Figured I'd start a new thread about what this listserve is for.

Anything python related is a good place to start. But that is pretty general, and there are many other resources out there that serve a purpose that I believe this listserve should not fill.

For example, I considered using this as a version control system and just sending out mass emails to every commit I made. But then I found Github and it just seemed more efficient to do it that way. 

What would people like to see on here, what is most beneficial to you? I found hackillinois through this listserve and will be volunteering there so I can say that has added value to my learning experience and development in Python.

Any thoughts?


Mike

From lane at strapr.com  Thu Feb 18 07:52:29 2016
From: lane at strapr.com (Lane Campbell)
Date: Thu, 18 Feb 2016 06:52:29 -0600
Subject: [Chicago] The list
In-Reply-To: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
Message-ID: <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>

Mike,

I'd like to see more resources for early stage education about Python
specifically for web and mobile developers who are learning and building up
their skills.  Also, if the group isn't aware there is a new slack for tech
folks in Chicago.  Seems like a great group if you aren't already on there.
 http://chicagotech.herokuapp.com/


Regards,
Lane Campbell
(312) 775-2632

On Thu, Feb 18, 2016 at 6:48 AM, Mike Tamillow <mikaeltamillow96 at gmail.com>
wrote:

> Figured I'd start a new thread about what this listserve is for.
>
> Anything python related is a good place to start. But that is pretty
> general, and there are many other resources out there that serve a purpose
> that I believe this listserve should not fill.
>
> For example, I considered using this as a version control system and just
> sending out mass emails to every commit I made. But then I found Github and
> it just seemed more efficient to do it that way.
>
> What would people like to see on here, what is most beneficial to you? I
> found hackillinois through this listserve and will be volunteering there so
> I can say that has added value to my learning experience and development in
> Python.
>
> Any thoughts?
>
>
> Mike
> _______________________________________________
> 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/20160218/5d4aacee/attachment.html>

From kirby.urner at gmail.com  Thu Feb 18 13:42:54 2016
From: kirby.urner at gmail.com (kirby urner)
Date: Thu, 18 Feb 2016 10:42:54 -0800
Subject: [Chicago] The list
In-Reply-To: <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
 <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
Message-ID: <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>

I'm a lurker who's been on this list a long time.

By "lurker" I don't mean I'm completely quiet, but rather that I'm nowhere
near Chicago, though I was born there and went to a Djangocon in some swank
hotel along the river (where I led a workshop before taking off on a
pilgrimage to the home town of our O'Reilly School of Technology [1]).

I'm interested in "code schools" both in cyberspace, in actual physical
digs, and in combination.  You'll find me through PDX Code Guild here in
Portland [2], however I have other gigs as well.

The connecting thread though is I'm focused on a full stack that features
Python (even though I totally get why some would work in Clojure and
React).

How does one best teach and learn to navigate and get work done in this
ecosystem?  I scan Chipy for ideas.

And I find them, in abundance.

The recent thread on flattening deeply nested data structures was pure gold
and I'm gonna turn around and teach it as a perfect example of how we use
itertools.

No complaints then, about the quality so far!  I'm getting what a lurk for.
:-D

Kirby Urner
Portland, OR


[1]  the 3.5 minute movie named Leveraging Python in this public DropBox
documents my experience:
https://www.dropbox.com/home/PDX%20Code%20Guild
(I probably also have it on Youtube somewhere)

[2]  <guild /> in pictures:
https://www.flickr.com/photos/kirbyurner/albums/72157664250599655
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160218/f4571364/attachment.html>

From bob.haugen at gmail.com  Thu Feb 18 13:55:31 2016
From: bob.haugen at gmail.com (Bob Haugen)
Date: Thu, 18 Feb 2016 12:55:31 -0600
Subject: [Chicago] The list
In-Reply-To: <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
 <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
 <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>
Message-ID: <CA+Svw0UVq5BjEfuLewYZTrS08dmeMhhZhQ+t+CK24XfeWX0o_Q@mail.gmail.com>

On Thu, Feb 18, 2016 at 12:42 PM, kirby urner <kirby.urner at gmail.com> wrote:
> By "lurker" I don't mean I'm completely quiet, but rather that I'm nowhere
> near Chicago, though I was born there and went to a Djangocon in some swank
> hotel along the river (where I led a workshop before taking off on a
> pilgrimage to the home town of our O'Reilly School of Technology [1]).

Hey! I went to that workshop. It was my introduction to Python. Helped
enormously! Thanks a lot, Kirby Urner!

From elmq0022 at umn.edu  Thu Feb 18 14:43:36 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Thu, 18 Feb 2016 13:43:36 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
Message-ID: <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>

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



On Wed, Feb 17, 2016 at 11:21 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:

> Hey Massimo,
>
> That one-liner is so cool!  Thanks!  Simple and gets the job done.  Thanks
> for sharing.
>
> 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]
>>
>>
>>
>> On Feb 17, 2016, at 9:30 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>> d-lewit at neiu.edu>> wrote:
>>
>> Hi Mark,
>>
>> Thanks for those links.  Yes, Linus Torvalds is quite a legend in his own
>> time.  I'll be content to become 1% of the programmer that he is!   :-)
>>
>> My original question was simple, "Does Python have a builtin function for
>> flattening lists?"  It was a very simple question that provoked a very
>> strange and hostile thread!  I'm not sure why that is.  Anyhow, someone
>> mentioned itertools.chain( ).  Can someone provide a concrete example of
>> how that function works?  Or is that question inappropriate?  And please,
>> I'm just asking about itertools.chain( ).  I am not asking for any other
>> type of reply, okay?  Thank you.
>>
>>
>>
>> On Wed, Feb 17, 2016 at 2:52 PM, Mark Graves <mgraves87 at gmail.com<mailto:
>> mgraves87 at gmail.com>> wrote:
>> I don't mean to be argumentative or add to this discussion in a negative
>> way.
>>
>> Could we have a little direction from a higher up around the code of
>> conduct here?  For reference, this is the only one I found:
>>
>> http://www.chipy.org/pages/conduct/
>>
>> I am in support of Doug asking his questions and agree with Adam on this.
>> I've met Doug, and sometimes his humor is lost on people through the
>> mailing list.  If you are bothered, you can always create an email filter.
>>
>> FWIW, imagine if the developer at the top of this list had been
>> discouraged from asking questions about his "unusual" implementation?
>>
>>
>> https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ
>>
>>
>> https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D
>>
>>
>>
>>
>>
>>
>>
>> On Wed, Feb 17, 2016 at 11:50 AM, Mike Tamillow <
>> mikaeltamillow96 at gmail.com<mailto:mikaeltamillow96 at gmail.com>> wrote:
>> Yeah, but I generally agree that this list shouldn't be used for help
>> with personal programming problems. There is a website called stack
>> overflow as well as much documentation that can be consulted for this.
>>
>> What I like best is when messages come out exposing me to some open
>> source tool I have yet to hear about that may be useful.
>>
>> I'm sure there's other great discussions but I don't think code by email
>> is quite a good thing to send out to hundreds of people.
>>
>> Sent from my iPhone
>>
>> On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net<mailto:
>> adam at adamforsyth.net>> wrote:
>>
>> Hey everyone,
>>
>> Please remember that intentions can be hard to judge on the mailing list.
>> I've met Douglas in person and he's a nice guy. Please don't assign motives
>> just because there are issues communicating.
>>
>> Adam Forsyth
>> Sponsorship Director, ChiPy
>>
>>
>> On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com
>> <mailto:foresmac at gmail.com>> wrote:
>> Honestly, Douglas, you come to the list all the time asking for help or
>> opinions and then you precede to generally be a jerk to people that respond
>> to you. The fact is your solution is sloppy, confusing, and doesn?t work at
>> least as far as you originally explained it was supposed to work. Brad
>> pointed all this out and suggested a vastly better alternative, and did so
>> in an extremely polite way. Your response was just acerbic and doltish.
>> Please consider either accepting constructive criticism with humility or
>> just stop asking for help.
>>
>>
>> Regards,
>> Chris Foresman
>> chris at chrisforesman.com<mailto:chris at chrisforesman.com>
>>
>>
>>
>> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>> d-lewit at neiu.edu>> wrote:
>>
>> Use flattenAgain.... which calls flatten repeatedly until there's no
>> change in the list.  You have to use BOTH functions!
>>
>> Sarcasm?  What's that?
>>
>>
>> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <
>> bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
>> Douglas, I don't know if that was supposed to be sarcastic or what.
>>
>> In fact, your code does not work.
>>
>> >>> flatten([[[1, 2], 3], 4])
>> [[1, 2], 3, 4]
>>
>> Looks like it fails to fully flatten the list.
>>
>> I assumed from your original email you were interested in other
>> approaches, so I gave one that looks to me like it's much less complex (no
>> need for try/except, no need for indexing, 1 recursive call instead of 3).
>> Less complex code is usually easier to reason about and less prone to bugs.
>>
>> In purely functional languages there is no for loop, so if you want to
>> iterate over a list, you have to do it with recursive function calls.
>> Recursion stops when there's nothing left in the list, so the base case is
>> the empty list. Since iterating over a list is so common in programming, it
>> can start to feel like this is the way recursion and lists go together.
>>
>> But a good rule of thumb is only good if it doesn't trip you up when you
>> com across an exception to the rule. In the problem of flattening a list,
>> the recursion is down the depth of nesting, not across the list. In this
>> case, you can stop flattening when you hit a non-list object, so that's
>> your base case.
>>
>> Brad
>>
>> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>> d-lewit at neiu.edu>> wrote:
>> Whether it looks pythonic or not Joshua, it works!  Try it before you
>> criticize it!!!   ;-)   In implementing recursive functions on lists, one
>> of the base cases is almost always whether the list is empty or not.  A
>> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
>> languages for sure, but they made me a stronger programmer when it comes to
>> the dreaded "R" ( Recursion ).   ;-)
>>
>>
>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <
>> bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
>> > you can get almost there with itertools.chain.from_iterable
>>
>> It's tempting, but it fails in a lot of ways. It successfully flattens a
>> list of lists, but doesn't go any deeper than that and fails completely on
>> a list composed of some lists and some non-list objects. You can also get
>> the same behavior out of a list comprehension.
>>
>> Douglas, you have written a recursive function, but I think you've missed
>> on what the base case is. The base case is not whether or not you've been
>> passed an empty list, but rather whether an element is a list or not (if
>> it's not, you don't need any further flattening. Also, all those indices
>> don't look very pythonic.
>>
>> Here is a recursive flatten function that will handle any depth and mixed
>> depths at different elements (no indexing required)
>>
>> def flatten(lst):
>>     new_list = []
>>     for element in lst:
>>         if isinstance(element, list):
>>             new_list.extend(flatten(element))
>>         else:
>>             # This is the base case where the recursion ends
>>             new_list.append(element)
>>
>>     return new_list
>>
>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>
>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com
>> <mailto:zitterbewegung at gmail.com>> wrote:
>> The idea of flattening a object or datatype is a functional programming
>> technique and not just a part of Ruby and Mathematica According to this
>> answer on the programming stack exchange there is no method / function that
>> implements flatten for build in Python functions but you can get almost
>> there with itertools.chain.from_iterable . See
>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>> .
>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>> d-lewit at neiu.edu>> wrote:
>>
>> Hi everyone,
>>
>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
>> some time to just relax and mess around.  So I'm at my computer playing
>> around with Python and wondering how to resolve the issue of multiple lists
>> embedded within other lists.  I came up with two functions that I think
>> solve the problem.  But I was wondering if Guido or someone else added a
>> builtin function or method that does this automatically for the
>> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
>> wondering why I called the function "flatten" it's because I know from
>> experience that Wolfram Mathematica and Ocaml have these "flatten"
>> functions.  I think Ruby has something similar, but I haven't played with
>> Ruby in a while so I'm not really sure. )  The try: except block is
>> important because you can't subscript non-list data structures in Python.
>> The IndexError is what you get when you try to index an empty list.  So I
>> ****think**** my try: except block covers most commonly encountered
>> exceptions when working with lists embedded within other lists.
>>
>> Best,
>>
>> Douglas.
>>
>> def flatten(lst):
>> if lst == [ ]:
>> return lst
>> else:
>> try:
>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>> except TypeError:
>> return [lst[0]] + flatten(lst[1:])
>> except IndexError:
>> return flatten(lst[1:])
>>
>> def flattenAgain(lst):
>> newList = lst[:]
>> while newList != flatten(newList):
>> newList = flatten(newList)
>> return newList
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto:Chicago at python.org>
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org<mailto: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/20160218/b9f5945a/attachment.html>

From randy7771026 at gmail.com  Thu Feb 18 14:56:21 2016
From: randy7771026 at gmail.com (Randy Baxley)
Date: Thu, 18 Feb 2016 13:56:21 -0600
Subject: [Chicago] Too much fun?
Message-ID: <CAMqL=igEK5f7uVsP6BN8J34F94+iwWQs8ePwkmHK4qr5MgmT1Q@mail.gmail.com>

https://www.bellingcat.com/resources/how-tos/2015/09/11/follow-the-money-with-python/

Randy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160218/1f2fcec9/attachment.html>

From d-lewit at neiu.edu  Thu Feb 18 15:01:55 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Thu, 18 Feb 2016 14:01:55 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
Message-ID: <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>

Aaron,

That is really cool!  I didn't try the code yet, but just traced through
the logic of it.  I really like it.  I'm guessing that with your second
example you would need to use something like:

try:
    print( next(y) )
except StopIteration:
    pass

because eventually "next" just "runs out" and then Python raises its
StopIteration Error.  ( Although I'm kind of wondering if there's a way to
make "next" circular so that when it "runs out" it just goes right back to
the original yield statement.  I remember doing that once and it worked,
but.... I kind of forgot how to do that. )

Aaron, you mentioned that recursion is not one of Python's strong points.
Why is that the case and what could the developers do to enhance Python's
capabilities for implementing recursive algorithms.  Thanks for sharing.

Best,

Douglas.



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))
> .
> .
> .
>
>
>
> On Wed, Feb 17, 2016 at 11:21 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:
>
>> Hey Massimo,
>>
>> That one-liner is so cool!  Thanks!  Simple and gets the job done.
>> Thanks for sharing.
>>
>> 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]
>>>
>>>
>>>
>>> On Feb 17, 2016, at 9:30 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>>> d-lewit at neiu.edu>> wrote:
>>>
>>> Hi Mark,
>>>
>>> Thanks for those links.  Yes, Linus Torvalds is quite a legend in his
>>> own time.  I'll be content to become 1% of the programmer that he is!   :-)
>>>
>>> My original question was simple, "Does Python have a builtin function
>>> for flattening lists?"  It was a very simple question that provoked a very
>>> strange and hostile thread!  I'm not sure why that is.  Anyhow, someone
>>> mentioned itertools.chain( ).  Can someone provide a concrete example of
>>> how that function works?  Or is that question inappropriate?  And please,
>>> I'm just asking about itertools.chain( ).  I am not asking for any other
>>> type of reply, okay?  Thank you.
>>>
>>>
>>>
>>> On Wed, Feb 17, 2016 at 2:52 PM, Mark Graves <mgraves87 at gmail.com
>>> <mailto:mgraves87 at gmail.com>> wrote:
>>> I don't mean to be argumentative or add to this discussion in a negative
>>> way.
>>>
>>> Could we have a little direction from a higher up around the code of
>>> conduct here?  For reference, this is the only one I found:
>>>
>>> http://www.chipy.org/pages/conduct/
>>>
>>> I am in support of Doug asking his questions and agree with Adam on
>>> this. I've met Doug, and sometimes his humor is lost on people through the
>>> mailing list.  If you are bothered, you can always create an email filter.
>>>
>>> FWIW, imagine if the developer at the top of this list had been
>>> discouraged from asking questions about his "unusual" implementation?
>>>
>>>
>>> https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ
>>>
>>>
>>> https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Feb 17, 2016 at 11:50 AM, Mike Tamillow <
>>> mikaeltamillow96 at gmail.com<mailto:mikaeltamillow96 at gmail.com>> wrote:
>>> Yeah, but I generally agree that this list shouldn't be used for help
>>> with personal programming problems. There is a website called stack
>>> overflow as well as much documentation that can be consulted for this.
>>>
>>> What I like best is when messages come out exposing me to some open
>>> source tool I have yet to hear about that may be useful.
>>>
>>> I'm sure there's other great discussions but I don't think code by email
>>> is quite a good thing to send out to hundreds of people.
>>>
>>> Sent from my iPhone
>>>
>>> On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net<mailto:
>>> adam at adamforsyth.net>> wrote:
>>>
>>> Hey everyone,
>>>
>>> Please remember that intentions can be hard to judge on the mailing
>>> list. I've met Douglas in person and he's a nice guy. Please don't assign
>>> motives just because there are issues communicating.
>>>
>>> Adam Forsyth
>>> Sponsorship Director, ChiPy
>>>
>>>
>>> On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com
>>> <mailto:foresmac at gmail.com>> wrote:
>>> Honestly, Douglas, you come to the list all the time asking for help or
>>> opinions and then you precede to generally be a jerk to people that respond
>>> to you. The fact is your solution is sloppy, confusing, and doesn?t work at
>>> least as far as you originally explained it was supposed to work. Brad
>>> pointed all this out and suggested a vastly better alternative, and did so
>>> in an extremely polite way. Your response was just acerbic and doltish.
>>> Please consider either accepting constructive criticism with humility or
>>> just stop asking for help.
>>>
>>>
>>> Regards,
>>> Chris Foresman
>>> chris at chrisforesman.com<mailto:chris at chrisforesman.com>
>>>
>>>
>>>
>>> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>>> d-lewit at neiu.edu>> wrote:
>>>
>>> Use flattenAgain.... which calls flatten repeatedly until there's no
>>> change in the list.  You have to use BOTH functions!
>>>
>>> Sarcasm?  What's that?
>>>
>>>
>>> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <
>>> bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
>>> Douglas, I don't know if that was supposed to be sarcastic or what.
>>>
>>> In fact, your code does not work.
>>>
>>> >>> flatten([[[1, 2], 3], 4])
>>> [[1, 2], 3, 4]
>>>
>>> Looks like it fails to fully flatten the list.
>>>
>>> I assumed from your original email you were interested in other
>>> approaches, so I gave one that looks to me like it's much less complex (no
>>> need for try/except, no need for indexing, 1 recursive call instead of 3).
>>> Less complex code is usually easier to reason about and less prone to bugs.
>>>
>>> In purely functional languages there is no for loop, so if you want to
>>> iterate over a list, you have to do it with recursive function calls.
>>> Recursion stops when there's nothing left in the list, so the base case is
>>> the empty list. Since iterating over a list is so common in programming, it
>>> can start to feel like this is the way recursion and lists go together.
>>>
>>> But a good rule of thumb is only good if it doesn't trip you up when you
>>> com across an exception to the rule. In the problem of flattening a list,
>>> the recursion is down the depth of nesting, not across the list. In this
>>> case, you can stop flattening when you hit a non-list object, so that's
>>> your base case.
>>>
>>> Brad
>>>
>>> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu
>>> <mailto:d-lewit at neiu.edu>> wrote:
>>> Whether it looks pythonic or not Joshua, it works!  Try it before you
>>> criticize it!!!   ;-)   In implementing recursive functions on lists, one
>>> of the base cases is almost always whether the list is empty or not.  A
>>> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
>>> languages for sure, but they made me a stronger programmer when it comes to
>>> the dreaded "R" ( Recursion ).   ;-)
>>>
>>>
>>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <
>>> bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
>>> > you can get almost there with itertools.chain.from_iterable
>>>
>>> It's tempting, but it fails in a lot of ways. It successfully flattens a
>>> list of lists, but doesn't go any deeper than that and fails completely on
>>> a list composed of some lists and some non-list objects. You can also get
>>> the same behavior out of a list comprehension.
>>>
>>> Douglas, you have written a recursive function, but I think you've
>>> missed on what the base case is. The base case is not whether or not you've
>>> been passed an empty list, but rather whether an element is a list or not
>>> (if it's not, you don't need any further flattening. Also, all those
>>> indices don't look very pythonic.
>>>
>>> Here is a recursive flatten function that will handle any depth and
>>> mixed depths at different elements (no indexing required)
>>>
>>> def flatten(lst):
>>>     new_list = []
>>>     for element in lst:
>>>         if isinstance(element, list):
>>>             new_list.extend(flatten(element))
>>>         else:
>>>             # This is the base case where the recursion ends
>>>             new_list.append(element)
>>>
>>>     return new_list
>>>
>>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>>
>>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <zitterbewegung at gmail.com
>>> <mailto:zitterbewegung at gmail.com>> wrote:
>>> The idea of flattening a object or datatype is a functional programming
>>> technique and not just a part of Ruby and Mathematica According to this
>>> answer on the programming stack exchange there is no method / function that
>>> implements flatten for build in Python functions but you can get almost
>>> there with itertools.chain.from_iterable . See
>>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>>> .
>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>>> d-lewit at neiu.edu>> wrote:
>>>
>>> Hi everyone,
>>>
>>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
>>> some time to just relax and mess around.  So I'm at my computer playing
>>> around with Python and wondering how to resolve the issue of multiple lists
>>> embedded within other lists.  I came up with two functions that I think
>>> solve the problem.  But I was wondering if Guido or someone else added a
>>> builtin function or method that does this automatically for the
>>> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
>>> wondering why I called the function "flatten" it's because I know from
>>> experience that Wolfram Mathematica and Ocaml have these "flatten"
>>> functions.  I think Ruby has something similar, but I haven't played with
>>> Ruby in a while so I'm not really sure. )  The try: except block is
>>> important because you can't subscript non-list data structures in Python.
>>> The IndexError is what you get when you try to index an empty list.  So I
>>> ****think**** my try: except block covers most commonly encountered
>>> exceptions when working with lists embedded within other lists.
>>>
>>> Best,
>>>
>>> Douglas.
>>>
>>> def flatten(lst):
>>> if lst == [ ]:
>>> return lst
>>> else:
>>> try:
>>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>> except TypeError:
>>> return [lst[0]] + flatten(lst[1:])
>>> except IndexError:
>>> return flatten(lst[1:])
>>>
>>> def flattenAgain(lst):
>>> newList = lst[:]
>>> while newList != flatten(newList):
>>> newList = flatten(newList)
>>> return newList
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto:Chicago at python.org>
>>> https://mail.python.org/mailman/listinfo/chicago
>>>
>>>
>>> _______________________________________________
>>> Chicago mailing list
>>> Chicago at python.org<mailto: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
>>
>>
>
> _______________________________________________
> 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/20160218/ac251230/attachment-0001.html>

From elmq0022 at umn.edu  Thu Feb 18 16:13:08 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Thu, 18 Feb 2016 15:13:08 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
Message-ID: <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>

I can't think of a good reason to call "next" explicitly (beside priming a
coroutine, I think.  Not my strong point).  I just included the use of
"next" to drive home the point that this function returns a generator.

As far as recursion, CPython does not implement true "tail calls".  I've
read a quote from the BDFL that he has a preference for stack traces vs
true tail calls.

On Thu, Feb 18, 2016 at 2:01 PM, Lewit, Douglas <d-lewit at neiu.edu> wrote:

> Aaron,
>
> That is really cool!  I didn't try the code yet, but just traced through
> the logic of it.  I really like it.  I'm guessing that with your second
> example you would need to use something like:
>
> try:
>     print( next(y) )
> except StopIteration:
>     pass
>
> because eventually "next" just "runs out" and then Python raises its
> StopIteration Error.  ( Although I'm kind of wondering if there's a way to
> make "next" circular so that when it "runs out" it just goes right back to
> the original yield statement.  I remember doing that once and it worked,
> but.... I kind of forgot how to do that. )
>
> Aaron, you mentioned that recursion is not one of Python's strong points.
> Why is that the case and what could the developers do to enhance Python's
> capabilities for implementing recursive algorithms.  Thanks for sharing.
>
> Best,
>
> Douglas.
>
>
>
> 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))
>> .
>> .
>> .
>>
>>
>>
>> On Wed, Feb 17, 2016 at 11:21 PM, Lewit, Douglas <d-lewit at neiu.edu>
>> wrote:
>>
>>> Hey Massimo,
>>>
>>> That one-liner is so cool!  Thanks!  Simple and gets the job done.
>>> Thanks for sharing.
>>>
>>> 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]
>>>>
>>>>
>>>>
>>>> On Feb 17, 2016, at 9:30 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>>>> d-lewit at neiu.edu>> wrote:
>>>>
>>>> Hi Mark,
>>>>
>>>> Thanks for those links.  Yes, Linus Torvalds is quite a legend in his
>>>> own time.  I'll be content to become 1% of the programmer that he is!   :-)
>>>>
>>>> My original question was simple, "Does Python have a builtin function
>>>> for flattening lists?"  It was a very simple question that provoked a very
>>>> strange and hostile thread!  I'm not sure why that is.  Anyhow, someone
>>>> mentioned itertools.chain( ).  Can someone provide a concrete example of
>>>> how that function works?  Or is that question inappropriate?  And please,
>>>> I'm just asking about itertools.chain( ).  I am not asking for any other
>>>> type of reply, okay?  Thank you.
>>>>
>>>>
>>>>
>>>> On Wed, Feb 17, 2016 at 2:52 PM, Mark Graves <mgraves87 at gmail.com
>>>> <mailto:mgraves87 at gmail.com>> wrote:
>>>> I don't mean to be argumentative or add to this discussion in a
>>>> negative way.
>>>>
>>>> Could we have a little direction from a higher up around the code of
>>>> conduct here?  For reference, this is the only one I found:
>>>>
>>>> http://www.chipy.org/pages/conduct/
>>>>
>>>> I am in support of Doug asking his questions and agree with Adam on
>>>> this. I've met Doug, and sometimes his humor is lost on people through the
>>>> mailing list.  If you are bothered, you can always create an email filter.
>>>>
>>>> FWIW, imagine if the developer at the top of this list had been
>>>> discouraged from asking questions about his "unusual" implementation?
>>>>
>>>>
>>>> https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ
>>>>
>>>>
>>>> https://groups.google.com/forum/#!topic/comp.os.minix/wlhw16QWltI%5B1-25%5D
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, Feb 17, 2016 at 11:50 AM, Mike Tamillow <
>>>> mikaeltamillow96 at gmail.com<mailto:mikaeltamillow96 at gmail.com>> wrote:
>>>> Yeah, but I generally agree that this list shouldn't be used for help
>>>> with personal programming problems. There is a website called stack
>>>> overflow as well as much documentation that can be consulted for this.
>>>>
>>>> What I like best is when messages come out exposing me to some open
>>>> source tool I have yet to hear about that may be useful.
>>>>
>>>> I'm sure there's other great discussions but I don't think code by
>>>> email is quite a good thing to send out to hundreds of people.
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Feb 17, 2016, at 10:05 AM, Adam Forsyth <adam at adamforsyth.net
>>>> <mailto:adam at adamforsyth.net>> wrote:
>>>>
>>>> Hey everyone,
>>>>
>>>> Please remember that intentions can be hard to judge on the mailing
>>>> list. I've met Douglas in person and he's a nice guy. Please don't assign
>>>> motives just because there are issues communicating.
>>>>
>>>> Adam Forsyth
>>>> Sponsorship Director, ChiPy
>>>>
>>>>
>>>> On Wed, Feb 17, 2016 at 10:02 AM, Chris Foresman <foresmac at gmail.com
>>>> <mailto:foresmac at gmail.com>> wrote:
>>>> Honestly, Douglas, you come to the list all the time asking for help or
>>>> opinions and then you precede to generally be a jerk to people that respond
>>>> to you. The fact is your solution is sloppy, confusing, and doesn?t work at
>>>> least as far as you originally explained it was supposed to work. Brad
>>>> pointed all this out and suggested a vastly better alternative, and did so
>>>> in an extremely polite way. Your response was just acerbic and doltish.
>>>> Please consider either accepting constructive criticism with humility or
>>>> just stop asking for help.
>>>>
>>>>
>>>> Regards,
>>>> Chris Foresman
>>>> chris at chrisforesman.com<mailto:chris at chrisforesman.com>
>>>>
>>>>
>>>>
>>>> On Feb 16, 2016, at 10:44 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>>>> d-lewit at neiu.edu>> wrote:
>>>>
>>>> Use flattenAgain.... which calls flatten repeatedly until there's no
>>>> change in the list.  You have to use BOTH functions!
>>>>
>>>> Sarcasm?  What's that?
>>>>
>>>>
>>>> On Tue, Feb 16, 2016 at 10:37 PM, Brad Martsberger <
>>>> bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
>>>> Douglas, I don't know if that was supposed to be sarcastic or what.
>>>>
>>>> In fact, your code does not work.
>>>>
>>>> >>> flatten([[[1, 2], 3], 4])
>>>> [[1, 2], 3, 4]
>>>>
>>>> Looks like it fails to fully flatten the list.
>>>>
>>>> I assumed from your original email you were interested in other
>>>> approaches, so I gave one that looks to me like it's much less complex (no
>>>> need for try/except, no need for indexing, 1 recursive call instead of 3).
>>>> Less complex code is usually easier to reason about and less prone to bugs.
>>>>
>>>> In purely functional languages there is no for loop, so if you want to
>>>> iterate over a list, you have to do it with recursive function calls.
>>>> Recursion stops when there's nothing left in the list, so the base case is
>>>> the empty list. Since iterating over a list is so common in programming, it
>>>> can start to feel like this is the way recursion and lists go together.
>>>>
>>>> But a good rule of thumb is only good if it doesn't trip you up when
>>>> you com across an exception to the rule. In the problem of flattening a
>>>> list, the recursion is down the depth of nesting, not across the list. In
>>>> this case, you can stop flattening when you hit a non-list object, so
>>>> that's your base case.
>>>>
>>>> Brad
>>>>
>>>> On Tue, Feb 16, 2016 at 2:50 PM, Lewit, Douglas <d-lewit at neiu.edu
>>>> <mailto:d-lewit at neiu.edu>> wrote:
>>>> Whether it looks pythonic or not Joshua, it works!  Try it before you
>>>> criticize it!!!   ;-)   In implementing recursive functions on lists, one
>>>> of the base cases is almost always whether the list is empty or not.  A
>>>> little lesson I learned from studying lists in Haskell and Ocaml.  Hard
>>>> languages for sure, but they made me a stronger programmer when it comes to
>>>> the dreaded "R" ( Recursion ).   ;-)
>>>>
>>>>
>>>> On Tue, Feb 16, 2016 at 1:13 PM, Brad Martsberger <
>>>> bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
>>>> > you can get almost there with itertools.chain.from_iterable
>>>>
>>>> It's tempting, but it fails in a lot of ways. It successfully flattens
>>>> a list of lists, but doesn't go any deeper than that and fails completely
>>>> on a list composed of some lists and some non-list objects. You can also
>>>> get the same behavior out of a list comprehension.
>>>>
>>>> Douglas, you have written a recursive function, but I think you've
>>>> missed on what the base case is. The base case is not whether or not you've
>>>> been passed an empty list, but rather whether an element is a list or not
>>>> (if it's not, you don't need any further flattening. Also, all those
>>>> indices don't look very pythonic.
>>>>
>>>> Here is a recursive flatten function that will handle any depth and
>>>> mixed depths at different elements (no indexing required)
>>>>
>>>> def flatten(lst):
>>>>     new_list = []
>>>>     for element in lst:
>>>>         if isinstance(element, list):
>>>>             new_list.extend(flatten(element))
>>>>         else:
>>>>             # This is the base case where the recursion ends
>>>>             new_list.append(element)
>>>>
>>>>     return new_list
>>>>
>>>> >>> flatten([[1, 1.1], 2, 3, [4, 5, [6, 7, 8]]])
>>>> [1, 1.1, 2, 3, 4, 5, 6, 7, 8]
>>>>
>>>> On Mon, Feb 15, 2016 at 9:09 PM, Joshua Herman <
>>>> zitterbewegung at gmail.com<mailto:zitterbewegung at gmail.com>> wrote:
>>>> The idea of flattening a object or datatype is a functional programming
>>>> technique and not just a part of Ruby and Mathematica According to this
>>>> answer on the programming stack exchange there is no method / function that
>>>> implements flatten for build in Python functions but you can get almost
>>>> there with itertools.chain.from_iterable . See
>>>> http://programmers.stackexchange.com/questions/254279/why-doesnt-python-have-a-flatten-function-for-lists
>>>> .
>>>> On Feb 15, 2016, at 4:12 PM, Lewit, Douglas <d-lewit at neiu.edu<mailto:
>>>> d-lewit at neiu.edu>> wrote:
>>>>
>>>> Hi everyone,
>>>>
>>>> Well it's President's Day and I've got the day off!  Hooray!!!  Finally
>>>> some time to just relax and mess around.  So I'm at my computer playing
>>>> around with Python and wondering how to resolve the issue of multiple lists
>>>> embedded within other lists.  I came up with two functions that I think
>>>> solve the problem.  But I was wondering if Guido or someone else added a
>>>> builtin function or method that does this automatically for the
>>>> programmer.  Or is there an easier way?  Okay.... thanks.  ( In case you're
>>>> wondering why I called the function "flatten" it's because I know from
>>>> experience that Wolfram Mathematica and Ocaml have these "flatten"
>>>> functions.  I think Ruby has something similar, but I haven't played with
>>>> Ruby in a while so I'm not really sure. )  The try: except block is
>>>> important because you can't subscript non-list data structures in Python.
>>>> The IndexError is what you get when you try to index an empty list.  So I
>>>> ****think**** my try: except block covers most commonly encountered
>>>> exceptions when working with lists embedded within other lists.
>>>>
>>>> Best,
>>>>
>>>> Douglas.
>>>>
>>>> def flatten(lst):
>>>> if lst == [ ]:
>>>> return lst
>>>> else:
>>>> try:
>>>> return [lst[0][0]] + flatten(lst[0][1:] + lst[1:])
>>>> except TypeError:
>>>> return [lst[0]] + flatten(lst[1:])
>>>> except IndexError:
>>>> return flatten(lst[1:])
>>>>
>>>> def flattenAgain(lst):
>>>> newList = lst[:]
>>>> while newList != flatten(newList):
>>>> newList = flatten(newList)
>>>> return newList
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto:Chicago at python.org>
>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>
>>>>
>>>> _______________________________________________
>>>> Chicago mailing list
>>>> Chicago at python.org<mailto: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
>>>
>>>
>>
>> _______________________________________________
>> 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/20160218/de4c3553/attachment.html>

From daniel.galtieri at gmail.com  Thu Feb 18 16:31:07 2016
From: daniel.galtieri at gmail.com (Daniel Galtieri)
Date: Thu, 18 Feb 2016 15:31:07 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
Message-ID: <CAJgjJzQejxUKbS=EmYLPfC5wAbLszYkknccRS5q3KNhPh18W1g@mail.gmail.com>

Guido has a couple blog posts about tail recursion in python, for those
interested:

http://neopythonic.blogspot.com.au/2009/04/tail-recursion-elimination.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160218/bcbf9726/attachment.html>

From qholness at gmail.com  Thu Feb 18 17:41:18 2016
From: qholness at gmail.com (Quentin Holness)
Date: Thu, 18 Feb 2016 16:41:18 -0600
Subject: [Chicago] Too much fun?
In-Reply-To: <CAMqL=igEK5f7uVsP6BN8J34F94+iwWQs8ePwkmHK4qr5MgmT1Q@mail.gmail.com>
References: <CAMqL=igEK5f7uVsP6BN8J34F94+iwWQs8ePwkmHK4qr5MgmT1Q@mail.gmail.com>
Message-ID: <CA+Oer46nJ_RLqBhtq0+gSvy_Ba01TOoupFZMJTCnn=uuEBiM4g@mail.gmail.com>

Oooh. This is promising.

Quentin Holness, MS. Economics

Northwestern University

Gmail <qholness at gmail.com> |LinkedIn <http://linkedin.com/in/qholness> | Hit
Points <http://www.thehitpoint.com>

On Thu, Feb 18, 2016 at 1:56 PM, Randy Baxley <randy7771026 at gmail.com>
wrote:

>
> https://www.bellingcat.com/resources/how-tos/2015/09/11/follow-the-money-with-python/
>
> Randy
>
> _______________________________________________
> 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/20160218/4e8caa76/attachment.html>

From proba at allstate.com  Thu Feb 18 19:48:19 2016
From: proba at allstate.com (Robare, Phillip (TEKSystems))
Date: Fri, 19 Feb 2016 00:48:19 +0000
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
Message-ID: <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>

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<mailto: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<mailto: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]


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160219/72fb55b6/attachment.html>

From mgraves87 at gmail.com  Thu Feb 18 18:42:26 2016
From: mgraves87 at gmail.com (Mark Graves)
Date: Thu, 18 Feb 2016 17:42:26 -0600
Subject: [Chicago] The list
In-Reply-To: <CA+Svw0UVq5BjEfuLewYZTrS08dmeMhhZhQ+t+CK24XfeWX0o_Q@mail.gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
 <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
 <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>
 <CA+Svw0UVq5BjEfuLewYZTrS08dmeMhhZhQ+t+CK24XfeWX0o_Q@mail.gmail.com>
Message-ID: <CABs1gexsTrnYAiaHDUnAqEXknn1jbAt9e3PA9bZDzUYWUKY7Rw@mail.gmail.com>

I echo all of the above sentiments and these are all things I'm interested
in.

I am personally here to learn from other's mistakes.  In my career (if you
can call it that), its been less painful than re-creating them myself.

I often code-shame
<https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/507935737f65dff5244388bd1603388d/hn.algolia.com/?query=code%20shame&sort=byPopularity&prefix&page=0&dateRange=all&type=story>
myself and typically suffer from impostor syndrome
<https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/b62037f86be97711a2e7dec23600b63c/hn.algolia.com/?query=impostor%20syndrome&sort=byPopularity&prefix&page=0&dateRange=all&type=story>
especially
when people talk about the zen of python.  This has led me to contribute
less to the open source community than I would have liked because I'm
afraid people will ridicule my code.  I have even gone so far as to create
fake github/bitbucket accounts and send pull requests.  Yep.  I'm that
wierd.

Python is such a fantastic and beautiful language, and I usually feel like
my code doesn't live up to being called "pythonic".

In that sense, I truly enjoy civil discussions around real world problems
and how others approach them.  Seeing anti-patterns and how they are
corrected to work is really useful to me as I try to grow my skills.

While I find stack overflow / documentation / tutorials useful, there is
just something useful about hearing feedback where the solution isn't
posted.
In particular, I don't have a formal computer science background, so topics
of python's internals and effective memory management are particularly
interesting to me.

Similar to this:

http://neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html
<http://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/c2e535ff606622773d047be7e9fc61eb/neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html>



On Thu, Feb 18, 2016 at 12:55 PM, Bob Haugen <bob.haugen at gmail.com> wrote:

> On Thu, Feb 18, 2016 at 12:42 PM, kirby urner <kirby.urner at gmail.com>
> wrote:
> > By "lurker" I don't mean I'm completely quiet, but rather that I'm
> nowhere
> > near Chicago, though I was born there and went to a Djangocon in some
> swank
> > hotel along the river (where I led a workshop before taking off on a
> > pilgrimage to the home town of our O'Reilly School of Technology [1]).
>
> Hey! I went to that workshop. It was my introduction to Python. Helped
> enormously! Thanks a lot, Kirby Urner!
> _______________________________________________
> 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/20160218/f0da2064/attachment.html>

From elmq0022 at umn.edu  Thu Feb 18 20:43:27 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Thu, 18 Feb 2016 19:43:27 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
Message-ID: <CAPrZ9unOQdPuAWR=Sd=TUwYeypdFhx-fov9HWrHq0X4Pzrq1pg@mail.gmail.com>

That's true.

I was thinking that it might be beneficial if the routine handled any
nested iterable besides strings which only has __getitem__ implemented.

That may not be a good idea.

Using Brad's isinstance(elment,list) should be better.

Thanks for the feedback.
On Feb 18, 2016 7:22 PM, "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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160218/0cc87dcd/attachment-0001.html>

From adam at adamforsyth.net  Thu Feb 18 20:55:39 2016
From: adam at adamforsyth.net (Adam Forsyth)
Date: Thu, 18 Feb 2016 19:55:39 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
Message-ID: <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160218/f5f8b32c/attachment.html>

From mgraves87 at gmail.com  Thu Feb 18 22:29:02 2016
From: mgraves87 at gmail.com (Mark Graves)
Date: Thu, 18 Feb 2016 21:29:02 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
Message-ID: <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160218/e70d820a/attachment.html>

From elmq0022 at umn.edu  Fri Feb 19 07:59:36 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Fri, 19 Feb 2016 06:59:36 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
Message-ID: <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>

Here's one last approach that is stack based.  There is some clean up to do
here for sure (I'm mutating the original list for one), but the point is to
illustrate an approach that is not recursive.

def flatten_big_list(lst):
    stack = []
    while(lst):
        top = lst.pop(0)
        while(isinstance(top,list)):
            temp = top.pop(0)
            if top:
                lst.insert(0,top)
            top = temp
        stack.append(top)
    return stack


def flatten_big_list_gen(lst):
    while(lst):
        top = lst.pop(0)
        while(isinstance(top,list)):
            temp = top.pop(0)
            if top:
                lst.insert(0,top)
            top = temp
        yield top


print(flatten_big_list([1, [2, [3, [4, 5]]]]))
print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))

Feedback is always welcome.


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/4c2ca927/attachment.html>

From adam at adamforsyth.net  Fri Feb 19 10:11:45 2016
From: adam at adamforsyth.net (Adam Forsyth)
Date: Fri, 19 Feb 2016 09:11:45 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
Message-ID: <CABrs+N-ASvN3MevRJuBuNH2oosAMFDWrkp+hU-upK=2R9Wt9aw@mail.gmail.com>

The problem with those solutions would be performance. Both pop(0) and
insert(0, item) are O(n) (they take an amount of time proportional to the
length of the list), so the resulting time complexity is quadratic instead
of linear.

To fix that, you could use a collections.deque for temporary storage, then
convert it to a list at the end.
Here's one last approach that is stack based.  There is some clean up to do
here for sure (I'm mutating the original list for one), but the point is to
illustrate an approach that is not recursive.

def flatten_big_list(lst):
    stack = []
    while(lst):
        top = lst.pop(0)
        while(isinstance(top,list)):
            temp = top.pop(0)
            if top:
                lst.insert(0,top)
            top = temp
        stack.append(top)
    return stack


def flatten_big_list_gen(lst):
    while(lst):
        top = lst.pop(0)
        while(isinstance(top,list)):
            temp = top.pop(0)
            if top:
                lst.insert(0,top)
            top = temp
        yield top


print(flatten_big_list([1, [2, [3, [4, 5]]]]))
print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))

Feedback is always welcome.


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

_______________________________________________
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/a0da99d9/attachment.html>

From elmq0022 at umn.edu  Fri Feb 19 10:24:38 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Fri, 19 Feb 2016 09:24:38 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABrs+N-ASvN3MevRJuBuNH2oosAMFDWrkp+hU-upK=2R9Wt9aw@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CABrs+N-ASvN3MevRJuBuNH2oosAMFDWrkp+hU-upK=2R9Wt9aw@mail.gmail.com>
Message-ID: <CAPrZ9u=3M_ALpn5JhtcDhUgt2zmHZH2LoY_n2j6+7ateskp+HQ@mail.gmail.com>

Thanks Adam.  I was knew pushing to the front of a list is generally a bad
(horrible) idea and would not scale.  Using collections.deque as you
suggest is definitely a much better idea.  Thanks for point that out.

So, now that we had all this discussion, has anyone encountered this issue
in the real world, or is this discussion just academic?

On Fri, Feb 19, 2016 at 9:11 AM, Adam Forsyth <adam at adamforsyth.net> wrote:

> The problem with those solutions would be performance. Both pop(0) and
> insert(0, item) are O(n) (they take an amount of time proportional to the
> length of the list), so the resulting time complexity is quadratic instead
> of linear.
>
> To fix that, you could use a collections.deque for temporary storage, then
> convert it to a list at the end.
> Here's one last approach that is stack based.  There is some clean up to
> do here for sure (I'm mutating the original list for one), but the point is
> to illustrate an approach that is not recursive.
>
> def flatten_big_list(lst):
>     stack = []
>     while(lst):
>         top = lst.pop(0)
>         while(isinstance(top,list)):
>             temp = top.pop(0)
>             if top:
>                 lst.insert(0,top)
>             top = temp
>         stack.append(top)
>     return stack
>
>
> def flatten_big_list_gen(lst):
>     while(lst):
>         top = lst.pop(0)
>         while(isinstance(top,list)):
>             temp = top.pop(0)
>             if top:
>                 lst.insert(0,top)
>             top = temp
>         yield top
>
>
> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>
> Feedback is always welcome.
>
>
> 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
>>
>>
>
> _______________________________________________
> 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/31099816/attachment-0001.html>

From bob.haugen at gmail.com  Fri Feb 19 10:25:17 2016
From: bob.haugen at gmail.com (Bob Haugen)
Date: Fri, 19 Feb 2016 09:25:17 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABrs+N-ASvN3MevRJuBuNH2oosAMFDWrkp+hU-upK=2R9Wt9aw@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CABrs+N-ASvN3MevRJuBuNH2oosAMFDWrkp+hU-upK=2R9Wt9aw@mail.gmail.com>
Message-ID: <CA+Svw0W=zTxnb=YreaO-8O7eqG0_HbjHn+c-GaAb1Zs2pB=2=A@mail.gmail.com>

Adam, do you have a sense of the performance tradeoffs between the
stack-based and recursive approaches, given that recursion in Python was
named as a performance problem earlier in this thread?

On Fri, Feb 19, 2016 at 9:11 AM, Adam Forsyth <adam at adamforsyth.net> wrote:

> The problem with those solutions would be performance. Both pop(0) and
> insert(0, item) are O(n) (they take an amount of time proportional to the
> length of the list), so the resulting time complexity is quadratic instead
> of linear.
>
> To fix that, you could use a collections.deque for temporary storage, then
> convert it to a list at the end.
> Here's one last approach that is stack based.  There is some clean up to
> do here for sure (I'm mutating the original list for one), but the point is
> to illustrate an approach that is not recursive.
>
> def flatten_big_list(lst):
>     stack = []
>     while(lst):
>         top = lst.pop(0)
>         while(isinstance(top,list)):
>             temp = top.pop(0)
>             if top:
>                 lst.insert(0,top)
>             top = temp
>         stack.append(top)
>     return stack
>
>
> def flatten_big_list_gen(lst):
>     while(lst):
>         top = lst.pop(0)
>         while(isinstance(top,list)):
>             temp = top.pop(0)
>             if top:
>                 lst.insert(0,top)
>             top = temp
>         yield top
>
>
> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>
> Feedback is always welcome.
>
>
> 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
>>
>>
>
> _______________________________________________
> 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/e00e8491/attachment.html>

From bradley.marts at gmail.com  Fri Feb 19 10:34:27 2016
From: bradley.marts at gmail.com (Brad Martsberger)
Date: Fri, 19 Feb 2016 09:34:27 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
Message-ID: <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>

Aaron, Thanks for your example. One thing to point out is that popping from
the front of a list is expensive because the entire list has to be copied.
Some options are to flatten the list from the back (popping off the end of
the list is cheap), or copying the list into a deque (from collections
import deque).

Here is another example of a non recursive version of flatten. It's not
nearly as elegant as the recursive version. It's longer than Aaron's
iterative version, but avoids hand manipulating the iteration over the
lists (no popping or inserting).

def press(lst):
    """
    Flattens nested lists one level

    Returns a tuple (new_list, changed) where changed is a boolean
indicating
    whether new_list is different from lst.
    """
    changed = False
    new_list = []
    for element in lst:
        if isinstance(element, list):
            new_list.extend(element)
            changed = True
        else:
            new_list.append(element)

    return new_list, changed


def flatten(lst):
    """
    Fully flattens nested lists into a list with no sublists
    """
    new_list = lst
    changed = True
    while changed:
        new_list, changed = press(new_list)
    return new_list

On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:

> Here's one last approach that is stack based.  There is some clean up to
> do here for sure (I'm mutating the original list for one), but the point is
> to illustrate an approach that is not recursive.
>
> def flatten_big_list(lst):
>     stack = []
>     while(lst):
>         top = lst.pop(0)
>         while(isinstance(top,list)):
>             temp = top.pop(0)
>             if top:
>                 lst.insert(0,top)
>             top = temp
>         stack.append(top)
>     return stack
>
>
> def flatten_big_list_gen(lst):
>     while(lst):
>         top = lst.pop(0)
>         while(isinstance(top,list)):
>             temp = top.pop(0)
>             if top:
>                 lst.insert(0,top)
>             top = temp
>         yield top
>
>
> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>
> Feedback is always welcome.
>
>
> 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
>>
>>
>
> _______________________________________________
> 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/f53d7eb6/attachment.html>

From elmq0022 at umn.edu  Fri Feb 19 10:40:46 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Fri, 19 Feb 2016 09:40:46 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
Message-ID: <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>

Brad, that's a really cool approach and very readable.  Thanks!

On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <bradley.marts at gmail.com>
wrote:

> Aaron, Thanks for your example. One thing to point out is that popping
> from the front of a list is expensive because the entire list has to be
> copied. Some options are to flatten the list from the back (popping off the
> end of the list is cheap), or copying the list into a deque (from
> collections import deque).
>
> Here is another example of a non recursive version of flatten. It's not
> nearly as elegant as the recursive version. It's longer than Aaron's
> iterative version, but avoids hand manipulating the iteration over the
> lists (no popping or inserting).
>
> def press(lst):
>     """
>     Flattens nested lists one level
>
>     Returns a tuple (new_list, changed) where changed is a boolean
> indicating
>     whether new_list is different from lst.
>     """
>     changed = False
>     new_list = []
>     for element in lst:
>         if isinstance(element, list):
>             new_list.extend(element)
>             changed = True
>         else:
>             new_list.append(element)
>
>     return new_list, changed
>
>
> def flatten(lst):
>     """
>     Fully flattens nested lists into a list with no sublists
>     """
>     new_list = lst
>     changed = True
>     while changed:
>         new_list, changed = press(new_list)
>     return new_list
>
> On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:
>
>> Here's one last approach that is stack based.  There is some clean up to
>> do here for sure (I'm mutating the original list for one), but the point is
>> to illustrate an approach that is not recursive.
>>
>> def flatten_big_list(lst):
>>     stack = []
>>     while(lst):
>>         top = lst.pop(0)
>>         while(isinstance(top,list)):
>>             temp = top.pop(0)
>>             if top:
>>                 lst.insert(0,top)
>>             top = temp
>>         stack.append(top)
>>     return stack
>>
>>
>> def flatten_big_list_gen(lst):
>>     while(lst):
>>         top = lst.pop(0)
>>         while(isinstance(top,list)):
>>             temp = top.pop(0)
>>             if top:
>>                 lst.insert(0,top)
>>             top = temp
>>         yield top
>>
>>
>> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
>> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>>
>> Feedback is always welcome.
>>
>>
>> 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
>>>
>>>
>>
>> _______________________________________________
>> 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/c6a27a72/attachment.html>

From elmq0022 at umn.edu  Fri Feb 19 11:05:20 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Fri, 19 Feb 2016 10:05:20 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
Message-ID: <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>

That's still potentially a lot of list copying though, isn't it?

On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:

> Brad, that's a really cool approach and very readable.  Thanks!
>
> On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <bradley.marts at gmail.com
> > wrote:
>
>> Aaron, Thanks for your example. One thing to point out is that popping
>> from the front of a list is expensive because the entire list has to be
>> copied. Some options are to flatten the list from the back (popping off the
>> end of the list is cheap), or copying the list into a deque (from
>> collections import deque).
>>
>> Here is another example of a non recursive version of flatten. It's not
>> nearly as elegant as the recursive version. It's longer than Aaron's
>> iterative version, but avoids hand manipulating the iteration over the
>> lists (no popping or inserting).
>>
>> def press(lst):
>>     """
>>     Flattens nested lists one level
>>
>>     Returns a tuple (new_list, changed) where changed is a boolean
>> indicating
>>     whether new_list is different from lst.
>>     """
>>     changed = False
>>     new_list = []
>>     for element in lst:
>>         if isinstance(element, list):
>>             new_list.extend(element)
>>             changed = True
>>         else:
>>             new_list.append(element)
>>
>>     return new_list, changed
>>
>>
>> def flatten(lst):
>>     """
>>     Fully flattens nested lists into a list with no sublists
>>     """
>>     new_list = lst
>>     changed = True
>>     while changed:
>>         new_list, changed = press(new_list)
>>     return new_list
>>
>> On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:
>>
>>> Here's one last approach that is stack based.  There is some clean up to
>>> do here for sure (I'm mutating the original list for one), but the point is
>>> to illustrate an approach that is not recursive.
>>>
>>> def flatten_big_list(lst):
>>>     stack = []
>>>     while(lst):
>>>         top = lst.pop(0)
>>>         while(isinstance(top,list)):
>>>             temp = top.pop(0)
>>>             if top:
>>>                 lst.insert(0,top)
>>>             top = temp
>>>         stack.append(top)
>>>     return stack
>>>
>>>
>>> def flatten_big_list_gen(lst):
>>>     while(lst):
>>>         top = lst.pop(0)
>>>         while(isinstance(top,list)):
>>>             temp = top.pop(0)
>>>             if top:
>>>                 lst.insert(0,top)
>>>             top = temp
>>>         yield top
>>>
>>>
>>> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
>>> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>>>
>>> Feedback is always welcome.
>>>
>>>
>>> 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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/29d0eaa7/attachment-0001.html>

From hundredpercentjuice at gmail.com  Fri Feb 19 11:39:25 2016
From: hundredpercentjuice at gmail.com (JS Irick)
Date: Fri, 19 Feb 2016 10:39:25 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
 <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
Message-ID: <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>

I think we can agree that there is only one true solution:

>>> my_list

[1, 2, [1, 2, 3, [1, 2, 3, 4], 5], 4, 5]

>>> json.loads("["+re.sub('[\[\]]','',json.dumps(my_list))+"]")

[1, 2, 1, 2, 3, 1, 2, 3, 4, 5, 4, 5]

On Fri, Feb 19, 2016 at 10:05 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:

> That's still potentially a lot of list copying though, isn't it?
>
> On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:
>
>> Brad, that's a really cool approach and very readable.  Thanks!
>>
>> On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <
>> bradley.marts at gmail.com> wrote:
>>
>>> Aaron, Thanks for your example. One thing to point out is that popping
>>> from the front of a list is expensive because the entire list has to be
>>> copied. Some options are to flatten the list from the back (popping off the
>>> end of the list is cheap), or copying the list into a deque (from
>>> collections import deque).
>>>
>>> Here is another example of a non recursive version of flatten. It's not
>>> nearly as elegant as the recursive version. It's longer than Aaron's
>>> iterative version, but avoids hand manipulating the iteration over the
>>> lists (no popping or inserting).
>>>
>>> def press(lst):
>>>     """
>>>     Flattens nested lists one level
>>>
>>>     Returns a tuple (new_list, changed) where changed is a boolean
>>> indicating
>>>     whether new_list is different from lst.
>>>     """
>>>     changed = False
>>>     new_list = []
>>>     for element in lst:
>>>         if isinstance(element, list):
>>>             new_list.extend(element)
>>>             changed = True
>>>         else:
>>>             new_list.append(element)
>>>
>>>     return new_list, changed
>>>
>>>
>>> def flatten(lst):
>>>     """
>>>     Fully flattens nested lists into a list with no sublists
>>>     """
>>>     new_list = lst
>>>     changed = True
>>>     while changed:
>>>         new_list, changed = press(new_list)
>>>     return new_list
>>>
>>> On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu>
>>> wrote:
>>>
>>>> Here's one last approach that is stack based.  There is some clean up
>>>> to do here for sure (I'm mutating the original list for one), but the point
>>>> is to illustrate an approach that is not recursive.
>>>>
>>>> def flatten_big_list(lst):
>>>>     stack = []
>>>>     while(lst):
>>>>         top = lst.pop(0)
>>>>         while(isinstance(top,list)):
>>>>             temp = top.pop(0)
>>>>             if top:
>>>>                 lst.insert(0,top)
>>>>             top = temp
>>>>         stack.append(top)
>>>>     return stack
>>>>
>>>>
>>>> def flatten_big_list_gen(lst):
>>>>     while(lst):
>>>>         top = lst.pop(0)
>>>>         while(isinstance(top,list)):
>>>>             temp = top.pop(0)
>>>>             if top:
>>>>                 lst.insert(0,top)
>>>>             top = temp
>>>>         yield top
>>>>
>>>>
>>>> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
>>>> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>>>>
>>>> Feedback is always welcome.
>>>>
>>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>


-- 
====
JS Irick
312-307-8904
Consultant: truqua.com
Coach: atlascrossfit.com
Programmer: juicetux.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160219/17c56d80/attachment.html>

From elmq0022 at umn.edu  Fri Feb 19 11:42:40 2016
From: elmq0022 at umn.edu (Aaron Elmquist)
Date: Fri, 19 Feb 2016 10:42:40 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
 <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
 <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
Message-ID: <CAPrZ9unYxejwJy_rV7aw6OsUrOORZhSe2KRdDMR5fWDN1qWLqg@mail.gmail.com>

Okay, that made my jaw drop.

On Fri, Feb 19, 2016 at 10:39 AM, JS Irick <hundredpercentjuice at gmail.com>
wrote:

> I think we can agree that there is only one true solution:
>
> >>> my_list
>
> [1, 2, [1, 2, 3, [1, 2, 3, 4], 5], 4, 5]
>
> >>> json.loads("["+re.sub('[\[\]]','',json.dumps(my_list))+"]")
>
> [1, 2, 1, 2, 3, 1, 2, 3, 4, 5, 4, 5]
>
> On Fri, Feb 19, 2016 at 10:05 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:
>
>> That's still potentially a lot of list copying though, isn't it?
>>
>> On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:
>>
>>> Brad, that's a really cool approach and very readable.  Thanks!
>>>
>>> On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <
>>> bradley.marts at gmail.com> wrote:
>>>
>>>> Aaron, Thanks for your example. One thing to point out is that popping
>>>> from the front of a list is expensive because the entire list has to be
>>>> copied. Some options are to flatten the list from the back (popping off the
>>>> end of the list is cheap), or copying the list into a deque (from
>>>> collections import deque).
>>>>
>>>> Here is another example of a non recursive version of flatten. It's not
>>>> nearly as elegant as the recursive version. It's longer than Aaron's
>>>> iterative version, but avoids hand manipulating the iteration over the
>>>> lists (no popping or inserting).
>>>>
>>>> def press(lst):
>>>>     """
>>>>     Flattens nested lists one level
>>>>
>>>>     Returns a tuple (new_list, changed) where changed is a boolean
>>>> indicating
>>>>     whether new_list is different from lst.
>>>>     """
>>>>     changed = False
>>>>     new_list = []
>>>>     for element in lst:
>>>>         if isinstance(element, list):
>>>>             new_list.extend(element)
>>>>             changed = True
>>>>         else:
>>>>             new_list.append(element)
>>>>
>>>>     return new_list, changed
>>>>
>>>>
>>>> def flatten(lst):
>>>>     """
>>>>     Fully flattens nested lists into a list with no sublists
>>>>     """
>>>>     new_list = lst
>>>>     changed = True
>>>>     while changed:
>>>>         new_list, changed = press(new_list)
>>>>     return new_list
>>>>
>>>> On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu>
>>>> wrote:
>>>>
>>>>> Here's one last approach that is stack based.  There is some clean up
>>>>> to do here for sure (I'm mutating the original list for one), but the point
>>>>> is to illustrate an approach that is not recursive.
>>>>>
>>>>> def flatten_big_list(lst):
>>>>>     stack = []
>>>>>     while(lst):
>>>>>         top = lst.pop(0)
>>>>>         while(isinstance(top,list)):
>>>>>             temp = top.pop(0)
>>>>>             if top:
>>>>>                 lst.insert(0,top)
>>>>>             top = temp
>>>>>         stack.append(top)
>>>>>     return stack
>>>>>
>>>>>
>>>>> def flatten_big_list_gen(lst):
>>>>>     while(lst):
>>>>>         top = lst.pop(0)
>>>>>         while(isinstance(top,list)):
>>>>>             temp = top.pop(0)
>>>>>             if top:
>>>>>                 lst.insert(0,top)
>>>>>             top = temp
>>>>>         yield top
>>>>>
>>>>>
>>>>> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
>>>>> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>>>>>
>>>>> Feedback is always welcome.
>>>>>
>>>>>
>>>>> 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>
>>
>
>
> --
> ====
> JS Irick
> 312-307-8904
> Consultant: truqua.com
> Coach: atlascrossfit.com
> Programmer: juicetux.com
>
> _______________________________________________
> 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/e4f4aa5b/attachment.html>

From MDiPierro at cs.depaul.edu  Fri Feb 19 11:47:54 2016
From: MDiPierro at cs.depaul.edu (DiPierro, Massimo)
Date: Fri, 19 Feb 2016 16:47:54 +0000
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
 <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
 <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
Message-ID: <FF98504D-0DB9-4199-8A1A-0347A222D130@cs.depaul.edu>

LOL

vulnerable to square brackets injection attacks! [1, 2, [1, 2, 3, [1, 2, ?[9,1,9]', 4], 5], 4, 5]

On Feb 19, 2016, at 10:39 AM, JS Irick <hundredpercentjuice at gmail.com<mailto:hundredpercentjuice at gmail.com>> wrote:

I think we can agree that there is only one true solution:

>>> my_list

[1, 2, [1, 2, 3, [1, 2, 3, 4], 5], 4, 5]

>>> json.loads("["+re.sub('[\[\]]','',json.dumps(my_list))+"]")

[1, 2, 1, 2, 3, 1, 2, 3, 4, 5, 4, 5]

On Fri, Feb 19, 2016 at 10:05 AM, Aaron Elmquist <elmq0022 at umn.edu<mailto:elmq0022 at umn.edu>> wrote:
That's still potentially a lot of list copying though, isn't it?

On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist <elmq0022 at umn.edu<mailto:elmq0022 at umn.edu>> wrote:
Brad, that's a really cool approach and very readable.  Thanks!

On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <bradley.marts at gmail.com<mailto:bradley.marts at gmail.com>> wrote:
Aaron, Thanks for your example. One thing to point out is that popping from the front of a list is expensive because the entire list has to be copied. Some options are to flatten the list from the back (popping off the end of the list is cheap), or copying the list into a deque (from collections import deque).

Here is another example of a non recursive version of flatten. It's not nearly as elegant as the recursive version. It's longer than Aaron's iterative version, but avoids hand manipulating the iteration over the lists (no popping or inserting).

def press(lst):
    """
    Flattens nested lists one level

    Returns a tuple (new_list, changed) where changed is a boolean indicating
    whether new_list is different from lst.
    """
    changed = False
    new_list = []
    for element in lst:
        if isinstance(element, list):
            new_list.extend(element)
            changed = True
        else:
            new_list.append(element)

    return new_list, changed


def flatten(lst):
    """
    Fully flattens nested lists into a list with no sublists
    """
    new_list = lst
    changed = True
    while changed:
        new_list, changed = press(new_list)
    return new_list

On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu<mailto:elmq0022 at umn.edu>> wrote:
Here's one last approach that is stack based.  There is some clean up to do here for sure (I'm mutating the original list for one), but the point is to illustrate an approach that is not recursive.

def flatten_big_list(lst):
    stack = []
    while(lst):
        top = lst.pop(0)
        while(isinstance(top,list)):
            temp = top.pop(0)
            if top:
                lst.insert(0,top)
            top = temp
        stack.append(top)
    return stack


def flatten_big_list_gen(lst):
    while(lst):
        top = lst.pop(0)
        while(isinstance(top,list)):
            temp = top.pop(0)
            if top:
                lst.insert(0,top)
            top = temp
        yield top


print(flatten_big_list([1, [2, [3, [4, 5]]]]))
print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))

Feedback is always welcome.


On Thu, Feb 18, 2016 at 9:29 PM, Mark Graves <mgraves87 at gmail.com<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago


_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago



_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago



_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago



_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago




_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago




--
====
JS Irick
312-307-8904
Consultant: truqua.com<http://truqua.com/>
Coach: atlascrossfit.com<http://atlascrossfit.com/>
Programmer: juicetux.com<http://juicetux.com/>
_______________________________________________
Chicago mailing list
Chicago at python.org<mailto:Chicago at python.org>
https://mail.python.org/mailman/listinfo/chicago


From adam at adamforsyth.net  Fri Feb 19 11:49:46 2016
From: adam at adamforsyth.net (Adam Forsyth)
Date: Fri, 19 Feb 2016 10:49:46 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9unYxejwJy_rV7aw6OsUrOORZhSe2KRdDMR5fWDN1qWLqg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
 <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
 <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
 <CAPrZ9unYxejwJy_rV7aw6OsUrOORZhSe2KRdDMR5fWDN1qWLqg@mail.gmail.com>
Message-ID: <CABrs+N830DKnk2HrAdY=Z=JAs_AEfXtwz6FT5tNq3v7MSabCyQ@mail.gmail.com>

If you're looking for a single-pass iterative solution, you can emulate
recursion with a stack:

Start with a basic recursive implementation:

def flatten(lst):
    result = []
    for item in lst:
        if isinstance(item, list):
            for item in flatten(item):
                result.append(item)
        else:
            result.append(item)
    return result

Replace the for loops with while loops, and it's straightforward to replace
the recursion with a stack that does the same thing:

def iterative_flatten(lst):
    result = []
    stack = [(lst, 0)]

    while stack:
        lst, index = stack.pop()
        while index < len(lst):
            item = lst[index]
            if isinstance(item, list):
                stack.append((lst, index + 1))
                lst, index = item, 0
            else:
                result.append(item)
                index += 1

    return result

This is very, very close to what Python is doing internally when you use a
recursive solution.


On Fri, Feb 19, 2016 at 10:42 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:

> Okay, that made my jaw drop.
>
> On Fri, Feb 19, 2016 at 10:39 AM, JS Irick <hundredpercentjuice at gmail.com>
> wrote:
>
>> I think we can agree that there is only one true solution:
>>
>> >>> my_list
>>
>> [1, 2, [1, 2, 3, [1, 2, 3, 4], 5], 4, 5]
>>
>> >>> json.loads("["+re.sub('[\[\]]','',json.dumps(my_list))+"]")
>>
>> [1, 2, 1, 2, 3, 1, 2, 3, 4, 5, 4, 5]
>>
>> On Fri, Feb 19, 2016 at 10:05 AM, Aaron Elmquist <elmq0022 at umn.edu>
>> wrote:
>>
>>> That's still potentially a lot of list copying though, isn't it?
>>>
>>> On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist <elmq0022 at umn.edu>
>>> wrote:
>>>
>>>> Brad, that's a really cool approach and very readable.  Thanks!
>>>>
>>>> On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <
>>>> bradley.marts at gmail.com> wrote:
>>>>
>>>>> Aaron, Thanks for your example. One thing to point out is that popping
>>>>> from the front of a list is expensive because the entire list has to be
>>>>> copied. Some options are to flatten the list from the back (popping off the
>>>>> end of the list is cheap), or copying the list into a deque (from
>>>>> collections import deque).
>>>>>
>>>>> Here is another example of a non recursive version of flatten. It's
>>>>> not nearly as elegant as the recursive version. It's longer than Aaron's
>>>>> iterative version, but avoids hand manipulating the iteration over the
>>>>> lists (no popping or inserting).
>>>>>
>>>>> def press(lst):
>>>>>     """
>>>>>     Flattens nested lists one level
>>>>>
>>>>>     Returns a tuple (new_list, changed) where changed is a boolean
>>>>> indicating
>>>>>     whether new_list is different from lst.
>>>>>     """
>>>>>     changed = False
>>>>>     new_list = []
>>>>>     for element in lst:
>>>>>         if isinstance(element, list):
>>>>>             new_list.extend(element)
>>>>>             changed = True
>>>>>         else:
>>>>>             new_list.append(element)
>>>>>
>>>>>     return new_list, changed
>>>>>
>>>>>
>>>>> def flatten(lst):
>>>>>     """
>>>>>     Fully flattens nested lists into a list with no sublists
>>>>>     """
>>>>>     new_list = lst
>>>>>     changed = True
>>>>>     while changed:
>>>>>         new_list, changed = press(new_list)
>>>>>     return new_list
>>>>>
>>>>> On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu>
>>>>> wrote:
>>>>>
>>>>>> Here's one last approach that is stack based.  There is some clean up
>>>>>> to do here for sure (I'm mutating the original list for one), but the point
>>>>>> is to illustrate an approach that is not recursive.
>>>>>>
>>>>>> def flatten_big_list(lst):
>>>>>>     stack = []
>>>>>>     while(lst):
>>>>>>         top = lst.pop(0)
>>>>>>         while(isinstance(top,list)):
>>>>>>             temp = top.pop(0)
>>>>>>             if top:
>>>>>>                 lst.insert(0,top)
>>>>>>             top = temp
>>>>>>         stack.append(top)
>>>>>>     return stack
>>>>>>
>>>>>>
>>>>>> def flatten_big_list_gen(lst):
>>>>>>     while(lst):
>>>>>>         top = lst.pop(0)
>>>>>>         while(isinstance(top,list)):
>>>>>>             temp = top.pop(0)
>>>>>>             if top:
>>>>>>                 lst.insert(0,top)
>>>>>>             top = temp
>>>>>>         yield top
>>>>>>
>>>>>>
>>>>>> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
>>>>>> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>>>>>>
>>>>>> Feedback is always welcome.
>>>>>>
>>>>>>
>>>>>> 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
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>
>>>
>>
>>
>> --
>> ====
>> JS Irick
>> 312-307-8904
>> Consultant: truqua.com
>> Coach: atlascrossfit.com
>> Programmer: juicetux.com
>>
>> _______________________________________________
>> 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/118cc603/attachment-0001.html>

From hundredpercentjuice at gmail.com  Fri Feb 19 12:05:02 2016
From: hundredpercentjuice at gmail.com (JS Irick)
Date: Fri, 19 Feb 2016 11:05:02 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <FF98504D-0DB9-4199-8A1A-0347A222D130@cs.depaul.edu>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
 <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
 <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
 <FF98504D-0DB9-4199-8A1A-0347A222D130@cs.depaul.edu>
Message-ID: <CAKVqkSmOPF3LOiHv7_JHjCLOwtATcyzOJ00NT3yYq06YFxE4ng@mail.gmail.com>

Massimo-

I gave up making the same joke when I couldn't come up with as awesome a
term as "square bracket injection attacks"


On Fri, Feb 19, 2016 at 10:47 AM, DiPierro, Massimo <MDiPierro at cs.depaul.edu
> wrote:

> LOL
>
> vulnerable to square brackets injection attacks! [1, 2, [1, 2, 3, [1, 2,
> ?[9,1,9]', 4], 5], 4, 5]
>
> On Feb 19, 2016, at 10:39 AM, JS Irick <hundredpercentjuice at gmail.com
> <mailto:hundredpercentjuice at gmail.com>> wrote:
>
> I think we can agree that there is only one true solution:
>
> >>> my_list
>
> [1, 2, [1, 2, 3, [1, 2, 3, 4], 5], 4, 5]
>
> >>> json.loads("["+re.sub('[\[\]]','',json.dumps(my_list))+"]")
>
> [1, 2, 1, 2, 3, 1, 2, 3, 4, 5, 4, 5]
>
> On Fri, Feb 19, 2016 at 10:05 AM, Aaron Elmquist <elmq0022 at umn.edu<mailto:
> elmq0022 at umn.edu>> wrote:
> That's still potentially a lot of list copying though, isn't it?
>
> On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist <elmq0022 at umn.edu<mailto:
> elmq0022 at umn.edu>> wrote:
> Brad, that's a really cool approach and very readable.  Thanks!
>
> On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <bradley.marts at gmail.com
> <mailto:bradley.marts at gmail.com>> wrote:
> Aaron, Thanks for your example. One thing to point out is that popping
> from the front of a list is expensive because the entire list has to be
> copied. Some options are to flatten the list from the back (popping off the
> end of the list is cheap), or copying the list into a deque (from
> collections import deque).
>
> Here is another example of a non recursive version of flatten. It's not
> nearly as elegant as the recursive version. It's longer than Aaron's
> iterative version, but avoids hand manipulating the iteration over the
> lists (no popping or inserting).
>
> def press(lst):
>     """
>     Flattens nested lists one level
>
>     Returns a tuple (new_list, changed) where changed is a boolean
> indicating
>     whether new_list is different from lst.
>     """
>     changed = False
>     new_list = []
>     for element in lst:
>         if isinstance(element, list):
>             new_list.extend(element)
>             changed = True
>         else:
>             new_list.append(element)
>
>     return new_list, changed
>
>
> def flatten(lst):
>     """
>     Fully flattens nested lists into a list with no sublists
>     """
>     new_list = lst
>     changed = True
>     while changed:
>         new_list, changed = press(new_list)
>     return new_list
>
> On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu<mailto:
> elmq0022 at umn.edu>> wrote:
> Here's one last approach that is stack based.  There is some clean up to
> do here for sure (I'm mutating the original list for one), but the point is
> to illustrate an approach that is not recursive.
>
> def flatten_big_list(lst):
>     stack = []
>     while(lst):
>         top = lst.pop(0)
>         while(isinstance(top,list)):
>             temp = top.pop(0)
>             if top:
>                 lst.insert(0,top)
>             top = temp
>         stack.append(top)
>     return stack
>
>
> def flatten_big_list_gen(lst):
>     while(lst):
>         top = lst.pop(0)
>         while(isinstance(top,list)):
>             temp = top.pop(0)
>             if top:
>                 lst.insert(0,top)
>             top = temp
>         yield top
>
>
> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>
> Feedback is always welcome.
>
>
> On Thu, Feb 18, 2016 at 9:29 PM, Mark Graves <mgraves87 at gmail.com<mailto:
> 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
> <mailto: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
> <mailto: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<mailto:
> 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<mailto: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<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto:Chicago at python.org>
> https://mail.python.org/mailman/listinfo/chicago
>
>
>
>
> --
> ====
> JS Irick
> 312-307-8904
> Consultant: truqua.com<http://truqua.com/>
> Coach: atlascrossfit.com<http://atlascrossfit.com/>
> Programmer: juicetux.com<http://juicetux.com/>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org<mailto: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
>



-- 
====
JS Irick
312-307-8904
Consultant: truqua.com
Coach: atlascrossfit.com
Programmer: juicetux.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160219/8b9c0959/attachment.html>

From jjhelmus at gmail.com  Fri Feb 19 11:47:04 2016
From: jjhelmus at gmail.com (Jonathan Helmus)
Date: Fri, 19 Feb 2016 10:47:04 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CAPrZ9unYxejwJy_rV7aw6OsUrOORZhSe2KRdDMR5fWDN1qWLqg@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
 <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
 <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
 <CAPrZ9unYxejwJy_rV7aw6OsUrOORZhSe2KRdDMR5fWDN1qWLqg@mail.gmail.com>
Message-ID: <56C74708.8000900@gmail.com>

Or just use build-ins, cause who has time for the standard library.

eval('['+str(my_list).replace('[', '').replace(']', '')+']')

Cheers,

    - Jonathan Helmus

On 02/19/2016 10:42 AM, Aaron Elmquist wrote:
> Okay, that made my jaw drop. 
>
> On Fri, Feb 19, 2016 at 10:39 AM, JS Irick
> <hundredpercentjuice at gmail.com <mailto:hundredpercentjuice at gmail.com>>
> wrote:
>
>     I think we can agree that there is only one true solution:
>
>     >>> my_list
>
>     [1, 2, [1, 2, 3, [1, 2, 3, 4], 5], 4, 5]
>
>     >>> json.loads("["+re.sub('[\[\]]','',json.dumps(my_list))+"]")
>
>     [1, 2, 1, 2, 3, 1, 2, 3, 4, 5, 4, 5]
>
>
>     On Fri, Feb 19, 2016 at 10:05 AM, Aaron Elmquist <elmq0022 at umn.edu
>     <mailto:elmq0022 at umn.edu>> wrote:
>
>         That's still potentially a lot of list copying though, isn't it?
>
>         On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist
>         <elmq0022 at umn.edu <mailto:elmq0022 at umn.edu>> wrote:
>
>             Brad, that's a really cool approach and very readable. 
>             Thanks!
>
>             On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger
>             <bradley.marts at gmail.com <mailto:bradley.marts at gmail.com>>
>             wrote:
>
>                 Aaron, Thanks for your example. One thing to point out
>                 is that popping from the front of a list is expensive
>                 because the entire list has to be copied. Some options
>                 are to flatten the list from the back (popping off the
>                 end of the list is cheap), or copying the list into a
>                 deque (from collections import deque).
>
>                 Here is another example of a non recursive version of
>                 flatten. It's not nearly as elegant as the recursive
>                 version. It's longer than Aaron's iterative version,
>                 but avoids hand manipulating the iteration over the
>                 lists (no popping or inserting).
>
>                 def press(lst):
>                     """
>                     Flattens nested lists one level
>
>                     Returns a tuple (new_list, changed) where changed
>                 is a boolean indicating
>                     whether new_list is different from lst.
>                     """
>                     changed = False
>                     new_list = []
>                     for element in lst:
>                         if isinstance(element, list):
>                             new_list.extend(element)
>                             changed = True
>                         else:
>                             new_list.append(element)
>
>                     return new_list, changed
>
>
>                 def flatten(lst):
>                     """
>                     Fully flattens nested lists into a list with no
>                 sublists
>                     """
>                     new_list = lst
>                     changed = True
>                     while changed:
>                         new_list, changed = press(new_list)
>                     return new_list
>
>                 On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist
>                 <elmq0022 at umn.edu <mailto:elmq0022 at umn.edu>> wrote:
>
>                     Here's one last approach that is stack based. 
>                     There is some clean up to do here for sure (I'm
>                     mutating the original list for one), but the point
>                     is to illustrate an approach that is not recursive. 
>
>                     def flatten_big_list(lst):
>                         stack = []
>                         while(lst):
>                             top = lst.pop(0)
>                             while(isinstance(top,list)):
>                                 temp = top.pop(0)
>                                 if top:
>                                     lst.insert(0,top)
>                                 top = temp
>                             stack.append(top)
>                         return stack
>
>
>                     def flatten_big_list_gen(lst):
>                         while(lst):
>                             top = lst.pop(0)
>                             while(isinstance(top,list)):
>                                 temp = top.pop(0)
>                                 if top:
>                                     lst.insert(0,top)
>                                 top = temp
>                             yield top
>
>
>                     print(flatten_big_list([1, [2, [3, [4, 5]]]]))
>                     print(list(flatten_big_list_gen([1, [2, [3, [4,
>                     5]]]])))
>
>                     Feedback is always welcome. 
>
>
>                     On Thu, Feb 18, 2016 at 9:29 PM, Mark Graves
>                     <mgraves87 at gmail.com <mailto: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
>                         <mailto: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
>                             <mailto: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
>                                     <mailto: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
>                                             <mailto: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
>                                 <mailto:Chicago at python.org>
>                                 https://mail.python.org/mailman/listinfo/chicago
>
>
>                             _______________________________________________
>                             Chicago mailing list
>                             Chicago at python.org <mailto:Chicago at python.org>
>                             https://mail.python.org/mailman/listinfo/chicago
>
>
>
>                         _______________________________________________
>                         Chicago mailing list
>                         Chicago at python.org <mailto:Chicago at python.org>
>                         https://mail.python.org/mailman/listinfo/chicago
>
>
>
>                     _______________________________________________
>                     Chicago mailing list
>                     Chicago at python.org <mailto:Chicago at python.org>
>                     https://mail.python.org/mailman/listinfo/chicago
>
>
>
>                 _______________________________________________
>                 Chicago mailing list
>                 Chicago at python.org <mailto:Chicago at python.org>
>                 https://mail.python.org/mailman/listinfo/chicago
>
>
>
>
>         _______________________________________________
>         Chicago mailing list
>         Chicago at python.org <mailto:Chicago at python.org>
>         https://mail.python.org/mailman/listinfo/chicago
>
>
>
>
>     -- 
>     ====
>     JS Irick
>     312-307-8904 <tel:312-307-8904>
>     Consultant: truqua.com <http://truqua.com>
>     Coach: atlascrossfit.com <http://atlascrossfit.com>
>     Programmer: juicetux.com <http://juicetux.com>
>
>     _______________________________________________
>     Chicago mailing list
>     Chicago at python.org <mailto: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/0871b072/attachment-0001.html>

From d-lewit at neiu.edu  Fri Feb 19 13:03:25 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Fri, 19 Feb 2016 12:03:25 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
Message-ID: <CAPdZZGypa8x78Ocez9imhHJW0xYxrcAwWYNZ1t=4YM+-yZnjYw@mail.gmail.com>

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>

From shekay at pobox.com  Fri Feb 19 13:22:37 2016
From: shekay at pobox.com (sheila miguez)
Date: Fri, 19 Feb 2016 12:22:37 -0600
Subject: [Chicago] help with pip and python-keystoneclient
Message-ID: <CAHCs_rYwHxPAksYzMHL_jZ5e_BdOryhdF28sC_23O9Ljbm9D4w@mail.gmail.com>

I've been struggling with this trying to figure out why pip can't find a
dependency when it tries to install python-keystoneclient. Our django app
has a requirements file with pinned versions. Recently we updated
python-keystoneclient to 2.1.1. It depends on pbr>=1.8.

When I try to deploy our project, the step where it installs dependencies
fails when it gets to python-keystoneclient because it cannot find a
version of pbr that satisfies >=1.8.

Pip is invoked this way in a Makefile that was passed down to me.
/path/to/third-party has tarballs of all the dependencies. It contains pbr
1.8.0:

pip install -r requirements.txt --fine-links file:///path/to/third-party
--no-index --index-url=file:///dev/null

The stack trace from pip

Downloading/unpacking python-keystoneclient==2.1.1 (from -r
requirements.txt (line 28))
  Running setup.py
(path:/srv/mojo/c3test/trusty/c3local-workspace1/build/application/build/python-keystoneclient/setup.py)
egg_info for package python-keystoneclient
    Download error on https://pypi.python.org/simple/pbr/: [Errno -2] Name
or service not known -- Some packages may not be found!
    Couldn't find index page for 'pbr' (maybe misspelled?)
    Download error on https://pypi.python.org/simple/: [Errno -2] Name or
service not known -- Some packages may not be found!
    No local packages or download links found for pbr>=1.8

Why is it trying to hit pypi?

I've experimented with adding pbr>=1.8 to the top of my requirements.txt
file explicitly. That works fine.

I've checked that this ancient version of pip treats 1.8.0 as >= 1.8.

Is there something in pip 1.5.4 that ignores --no-index and --index?

I'm going to look in to python-keystoneclient to see if they are doing
anything weird with setuptools. It doesn't look weird to me:

https://github.com/openstack/python-keystoneclient/blob/f5fb643f7c75ecf415cdbfc5a3bc4b01176d3e89/setup.py

(I've rubberducked and chatted and whatnot already with Carl and #chipy.
help me, mailinglist)

-- 
shekay at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160219/d4d81fa3/attachment.html>

From bradley.marts at gmail.com  Fri Feb 19 13:28:11 2016
From: bradley.marts at gmail.com (Brad Martsberger)
Date: Fri, 19 Feb 2016 12:28:11 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <CABrs+N830DKnk2HrAdY=Z=JAs_AEfXtwz6FT5tNq3v7MSabCyQ@mail.gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <3D4170E6-2FA8-4ED1-A10A-92712C5DB038@gmail.com>
 <CACvivO909Ng4oofzd-BWTuom4c7ygfFJ-KtD9n6habUVtzh8JQ@mail.gmail.com>
 <CAPdZZGzPzqFq+7vieEaWVe5wWkUCBEF5ThEUru+ouOopNLq0Xg@mail.gmail.com>
 <CACvivO_wt8ePoBnfQLhWt46hrcammY+xPR2eawRd307jP76kRA@mail.gmail.com>
 <CAPdZZGwJHioP5oWOkVvJFkWkdiPQuiPArkKpbYUL98kvouy6Tg@mail.gmail.com>
 <60838C58-0183-409B-8857-010688DE8D5E@gmail.com>
 <CABrs+N88-Rs8cEC5g7vuOT9p5nYZK+ugHVWhq_pGa7BMst6Gnw@mail.gmail.com>
 <D31683F3-0F67-4FF7-BCE3-DAB8C2E31C63@gmail.com>
 <CABs1geyFtAnpuB+FyWtU0x+Zs+CJFe_S6b7nbgCKn1ZYw4W0Cw@mail.gmail.com>
 <CAPdZZGyyjsVLg089mgXOJuMn06y=xwTMEOnyAYKGrFbK7OcLXg@mail.gmail.com>
 <86B652BB-90DA-479B-8216-080D982D045B@cs.depaul.edu>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
 <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
 <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
 <CAPrZ9unYxejwJy_rV7aw6OsUrOORZhSe2KRdDMR5fWDN1qWLqg@mail.gmail.com>
 <CABrs+N830DKnk2HrAdY=Z=JAs_AEfXtwz6FT5tNq3v7MSabCyQ@mail.gmail.com>
Message-ID: <CACvivO9ghgBOqEE387aO8eavWMYK04UxyfcHDbu9i=WAZ2L8dA@mail.gmail.com>

Adam, that's awesome, thanks.

On Fri, Feb 19, 2016 at 10:49 AM, Adam Forsyth <adam at adamforsyth.net> wrote:

> If you're looking for a single-pass iterative solution, you can emulate
> recursion with a stack:
>
> Start with a basic recursive implementation:
>
> def flatten(lst):
>     result = []
>     for item in lst:
>         if isinstance(item, list):
>             for item in flatten(item):
>                 result.append(item)
>         else:
>             result.append(item)
>     return result
>
> Replace the for loops with while loops, and it's straightforward to
> replace the recursion with a stack that does the same thing:
>
> def iterative_flatten(lst):
>     result = []
>     stack = [(lst, 0)]
>
>     while stack:
>         lst, index = stack.pop()
>         while index < len(lst):
>             item = lst[index]
>             if isinstance(item, list):
>                 stack.append((lst, index + 1))
>                 lst, index = item, 0
>             else:
>                 result.append(item)
>                 index += 1
>
>     return result
>
> This is very, very close to what Python is doing internally when you use a
> recursive solution.
>
>
> On Fri, Feb 19, 2016 at 10:42 AM, Aaron Elmquist <elmq0022 at umn.edu> wrote:
>
>> Okay, that made my jaw drop.
>>
>> On Fri, Feb 19, 2016 at 10:39 AM, JS Irick <hundredpercentjuice at gmail.com
>> > wrote:
>>
>>> I think we can agree that there is only one true solution:
>>>
>>> >>> my_list
>>>
>>> [1, 2, [1, 2, 3, [1, 2, 3, 4], 5], 4, 5]
>>>
>>> >>> json.loads("["+re.sub('[\[\]]','',json.dumps(my_list))+"]")
>>>
>>> [1, 2, 1, 2, 3, 1, 2, 3, 4, 5, 4, 5]
>>>
>>> On Fri, Feb 19, 2016 at 10:05 AM, Aaron Elmquist <elmq0022 at umn.edu>
>>> wrote:
>>>
>>>> That's still potentially a lot of list copying though, isn't it?
>>>>
>>>> On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist <elmq0022 at umn.edu>
>>>> wrote:
>>>>
>>>>> Brad, that's a really cool approach and very readable.  Thanks!
>>>>>
>>>>> On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <
>>>>> bradley.marts at gmail.com> wrote:
>>>>>
>>>>>> Aaron, Thanks for your example. One thing to point out is that
>>>>>> popping from the front of a list is expensive because the entire list has
>>>>>> to be copied. Some options are to flatten the list from the back (popping
>>>>>> off the end of the list is cheap), or copying the list into a deque (from
>>>>>> collections import deque).
>>>>>>
>>>>>> Here is another example of a non recursive version of flatten. It's
>>>>>> not nearly as elegant as the recursive version. It's longer than Aaron's
>>>>>> iterative version, but avoids hand manipulating the iteration over the
>>>>>> lists (no popping or inserting).
>>>>>>
>>>>>> def press(lst):
>>>>>>     """
>>>>>>     Flattens nested lists one level
>>>>>>
>>>>>>     Returns a tuple (new_list, changed) where changed is a boolean
>>>>>> indicating
>>>>>>     whether new_list is different from lst.
>>>>>>     """
>>>>>>     changed = False
>>>>>>     new_list = []
>>>>>>     for element in lst:
>>>>>>         if isinstance(element, list):
>>>>>>             new_list.extend(element)
>>>>>>             changed = True
>>>>>>         else:
>>>>>>             new_list.append(element)
>>>>>>
>>>>>>     return new_list, changed
>>>>>>
>>>>>>
>>>>>> def flatten(lst):
>>>>>>     """
>>>>>>     Fully flattens nested lists into a list with no sublists
>>>>>>     """
>>>>>>     new_list = lst
>>>>>>     changed = True
>>>>>>     while changed:
>>>>>>         new_list, changed = press(new_list)
>>>>>>     return new_list
>>>>>>
>>>>>> On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist <elmq0022 at umn.edu>
>>>>>> wrote:
>>>>>>
>>>>>>> Here's one last approach that is stack based.  There is some clean
>>>>>>> up to do here for sure (I'm mutating the original list for one), but the
>>>>>>> point is to illustrate an approach that is not recursive.
>>>>>>>
>>>>>>> def flatten_big_list(lst):
>>>>>>>     stack = []
>>>>>>>     while(lst):
>>>>>>>         top = lst.pop(0)
>>>>>>>         while(isinstance(top,list)):
>>>>>>>             temp = top.pop(0)
>>>>>>>             if top:
>>>>>>>                 lst.insert(0,top)
>>>>>>>             top = temp
>>>>>>>         stack.append(top)
>>>>>>>     return stack
>>>>>>>
>>>>>>>
>>>>>>> def flatten_big_list_gen(lst):
>>>>>>>     while(lst):
>>>>>>>         top = lst.pop(0)
>>>>>>>         while(isinstance(top,list)):
>>>>>>>             temp = top.pop(0)
>>>>>>>             if top:
>>>>>>>                 lst.insert(0,top)
>>>>>>>             top = temp
>>>>>>>         yield top
>>>>>>>
>>>>>>>
>>>>>>> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
>>>>>>> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>>>>>>>
>>>>>>> Feedback is always welcome.
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>
>>>>
>>>
>>>
>>> --
>>> ====
>>> JS Irick
>>> 312-307-8904
>>> Consultant: truqua.com
>>> Coach: atlascrossfit.com
>>> Programmer: juicetux.com
>>>
>>> _______________________________________________
>>> 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/0f919828/attachment.html>

From shekay at pobox.com  Fri Feb 19 13:40:29 2016
From: shekay at pobox.com (sheila miguez)
Date: Fri, 19 Feb 2016 12:40:29 -0600
Subject: [Chicago] help with pip and python-keystoneclient
In-Reply-To: <CAHCs_rYwHxPAksYzMHL_jZ5e_BdOryhdF28sC_23O9Ljbm9D4w@mail.gmail.com>
References: <CAHCs_rYwHxPAksYzMHL_jZ5e_BdOryhdF28sC_23O9Ljbm9D4w@mail.gmail.com>
Message-ID: <CAHCs_rYA5sat-bgUqivb2AFg58tb610+fpEXO4EWxRs_HyzxrQ@mail.gmail.com>

Oh, I forgot to mention.

I can reproduce this by running my mojo spec which does all the magic and
runs things in a container it creates. I cannot reproduce this with a
vanilla trusty container (this app gets deployed to a trusty container), or
on my wiley laptop (pip 8.x).

(I haven't figured out exactly what is different with the container the
deployment stuff creates yet).


-- 
shekay at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160219/8611687a/attachment.html>

From mgraves87 at gmail.com  Fri Feb 19 12:54:38 2016
From: mgraves87 at gmail.com (Mark Graves)
Date: Fri, 19 Feb 2016 11:54:38 -0600
Subject: [Chicago] Resolving lists within lists within lists within .....
In-Reply-To: <56C74708.8000900@gmail.com>
References: <CAPdZZGyNevvX_-QTAkeBWaX-YGpzibLkVY72n_wLxd2RRf9mDg@mail.gmail.com>
 <CAPdZZGzHjMxMRktx9MtfR9v=4JmsiZ4am6J7h-+izVPiev41VA@mail.gmail.com>
 <CAPrZ9um1iHG1usCkXcT2QYRVnv20KcX2QvCmrROD_OfuqYLBcg@mail.gmail.com>
 <CAPdZZGyx-wdeXV=hrOf-5Be3EbfqNo1Q8Bmu1kVPyiugU-U1VQ@mail.gmail.com>
 <CAPrZ9un=zeKf90H-R3EiFR6sBrSnRbnsRs0-zdsABimhCKYmdw@mail.gmail.com>
 <50869A74BA4F07468AD797C9BFF1FE3E0D9C2260@A0185-XPO1026-C.ad.allstate.com>
 <CABrs+N9AooDA3h8FcxgqeH=WZWn2Z6RAH-mY8kuSBwn3UnhWFw@mail.gmail.com>
 <CABs1gewTupx6HGmO9FyiU-q3nTSwEzz7EW_f+RaCyotcn=Pf0A@mail.gmail.com>
 <CAPrZ9ukZgFss16WvAbJO+zYR8V4nejfW4RxsYGrjTLJ_RZPeCQ@mail.gmail.com>
 <CACvivO8BtV_-frOCaDE_x8jztEn66CFrxEbyZykgwAOjTHJ2kA@mail.gmail.com>
 <CAPrZ9um7wzZ2YOnc25coA1YUw7RNydY9Pc=cX_3T3c-NDjPWFg@mail.gmail.com>
 <CAPrZ9u=NY-v7v_52dA_NtjfYiYn88taR-QCg2Wfoj-oSvQ_bJA@mail.gmail.com>
 <CAKVqkSkX422Vi3wqYGHGpbXch82Tu_h7EX5FCakvMvinEDYCeg@mail.gmail.com>
 <CAPrZ9unYxejwJy_rV7aw6OsUrOORZhSe2KRdDMR5fWDN1qWLqg@mail.gmail.com>
 <56C74708.8000900@gmail.com>
Message-ID: <CABs1geyf=L0AbCxW_iK66xQE8ahviDE+5LuFC26jkpT5Nbhwaw@mail.gmail.com>

I have seen this issue a number of times parsing XML.

I just wanted to flatten and aggregate the text nodes inside.  However,
sometimes they were lists, other times they were dicts, other times they
were strings.

=(

On Fri, Feb 19, 2016 at 10:47 AM, Jonathan Helmus <jjhelmus at gmail.com>
wrote:

> Or just use build-ins, cause who has time for the standard library.
>
> eval('['+str(my_list).replace('[', '').replace(']', '')+']')
>
> Cheers,
>
>     - Jonathan Helmus
>
>
> On 02/19/2016 10:42 AM, Aaron Elmquist wrote:
>
> Okay, that made my jaw drop.
>
> On Fri, Feb 19, 2016 at 10:39 AM, JS Irick <hundredpercentjuice at gmail.com>
> wrote:
>
>> I think we can agree that there is only one true solution:
>>
>> >>> my_list
>>
>> [1, 2, [1, 2, 3, [1, 2, 3, 4], 5], 4, 5]
>>
>> >>> json.loads("["+re.sub('[\[\]]','',json.dumps(my_list))+"]")
>>
>> [1, 2, 1, 2, 3, 1, 2, 3, 4, 5, 4, 5]
>>
>> On Fri, Feb 19, 2016 at 10:05 AM, Aaron Elmquist < <elmq0022 at umn.edu>
>> elmq0022 at umn.edu> wrote:
>>
>>> That's still potentially a lot of list copying though, isn't it?
>>>
>>> On Fri, Feb 19, 2016 at 9:40 AM, Aaron Elmquist <elmq0022 at umn.edu>
>>> wrote:
>>>
>>>> Brad, that's a really cool approach and very readable.  Thanks!
>>>>
>>>> On Fri, Feb 19, 2016 at 9:34 AM, Brad Martsberger <
>>>> <bradley.marts at gmail.com>bradley.marts at gmail.com> wrote:
>>>>
>>>>> Aaron, Thanks for your example. One thing to point out is that popping
>>>>> from the front of a list is expensive because the entire list has to be
>>>>> copied. Some options are to flatten the list from the back (popping off the
>>>>> end of the list is cheap), or copying the list into a deque (from
>>>>> collections import deque).
>>>>>
>>>>> Here is another example of a non recursive version of flatten. It's
>>>>> not nearly as elegant as the recursive version. It's longer than Aaron's
>>>>> iterative version, but avoids hand manipulating the iteration over the
>>>>> lists (no popping or inserting).
>>>>>
>>>>> def press(lst):
>>>>>     """
>>>>>     Flattens nested lists one level
>>>>>
>>>>>     Returns a tuple (new_list, changed) where changed is a boolean
>>>>> indicating
>>>>>     whether new_list is different from lst.
>>>>>     """
>>>>>     changed = False
>>>>>     new_list = []
>>>>>     for element in lst:
>>>>>         if isinstance(element, list):
>>>>>             new_list.extend(element)
>>>>>             changed = True
>>>>>         else:
>>>>>             new_list.append(element)
>>>>>
>>>>>     return new_list, changed
>>>>>
>>>>>
>>>>> def flatten(lst):
>>>>>     """
>>>>>     Fully flattens nested lists into a list with no sublists
>>>>>     """
>>>>>     new_list = lst
>>>>>     changed = True
>>>>>     while changed:
>>>>>         new_list, changed = press(new_list)
>>>>>     return new_list
>>>>>
>>>>> On Fri, Feb 19, 2016 at 6:59 AM, Aaron Elmquist < <elmq0022 at umn.edu>
>>>>> elmq0022 at umn.edu> wrote:
>>>>>
>>>>>> Here's one last approach that is stack based.  There is some clean up
>>>>>> to do here for sure (I'm mutating the original list for one), but the point
>>>>>> is to illustrate an approach that is not recursive.
>>>>>>
>>>>>> def flatten_big_list(lst):
>>>>>>     stack = []
>>>>>>     while(lst):
>>>>>>         top = lst.pop(0)
>>>>>>         while(isinstance(top,list)):
>>>>>>             temp = top.pop(0)
>>>>>>             if top:
>>>>>>                 lst.insert(0,top)
>>>>>>             top = temp
>>>>>>         stack.append(top)
>>>>>>     return stack
>>>>>>
>>>>>>
>>>>>> def flatten_big_list_gen(lst):
>>>>>>     while(lst):
>>>>>>         top = lst.pop(0)
>>>>>>         while(isinstance(top,list)):
>>>>>>             temp = top.pop(0)
>>>>>>             if top:
>>>>>>                 lst.insert(0,top)
>>>>>>             top = temp
>>>>>>         yield top
>>>>>>
>>>>>>
>>>>>> print(flatten_big_list([1, [2, [3, [4, 5]]]]))
>>>>>> print(list(flatten_big_list_gen([1, [2, [3, [4, 5]]]])))
>>>>>>
>>>>>> Feedback is always welcome.
>>>>>>
>>>>>>
>>>>>> On Thu, Feb 18, 2016 at 9:29 PM, Mark Graves < <mgraves87 at gmail.com>
>>>>>> 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>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>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>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>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>Chicago at python.org
>>>>>>>>> <https://mail.python.org/mailman/listinfo/chicago>
>>>>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>>>>
>>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Chicago mailing list
>>>>>>>> <Chicago at python.org>Chicago at python.org
>>>>>>>> <https://mail.python.org/mailman/listinfo/chicago>
>>>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Chicago mailing list
>>>>>>> <Chicago at python.org>Chicago at python.org
>>>>>>> <https://mail.python.org/mailman/listinfo/chicago>
>>>>>>> https://mail.python.org/mailman/listinfo/chicago
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Chicago mailing list
>>>>>> <Chicago at python.org>Chicago at python.org
>>>>>> <https://mail.python.org/mailman/listinfo/chicago>
>>>>>> 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
>>>
>>>
>>
>>
>> --
>> ====
>> JS Irick
>> 312-307-8904
>> Consultant: truqua.com
>> Coach: atlascrossfit.com
>> Programmer: juicetux.com
>>
>> _______________________________________________
>> Chicago mailing list
>> Chicago at python.org
>> https://mail.python.org/mailman/listinfo/chicago
>>
>>
>
>
> _______________________________________________
> Chicago mailing listChicago at python.orghttps://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/d63a2bb1/attachment-0001.html>

From shekay at pobox.com  Fri Feb 19 15:37:10 2016
From: shekay at pobox.com (sheila miguez)
Date: Fri, 19 Feb 2016 14:37:10 -0600
Subject: [Chicago] help with pip and python-keystoneclient
In-Reply-To: <CAHCs_rYwHxPAksYzMHL_jZ5e_BdOryhdF28sC_23O9Ljbm9D4w@mail.gmail.com>
References: <CAHCs_rYwHxPAksYzMHL_jZ5e_BdOryhdF28sC_23O9Ljbm9D4w@mail.gmail.com>
Message-ID: <CAHCs_rZuQSceKLs5ixGoYmVCQy_zyVYYTzXPi=KKbLpXsfrifQ@mail.gmail.com>

A clue! I managed to hit on a search that pulled up a helpful issue thread.
This looks like a likely suspect.

https://github.com/pypa/pip/issues/410

https://pip.pypa.io/en/latest/reference/pip_install/#controlling-setup-requires

setup_requires does not honor --no-index and other flags from pip.


On Fri, Feb 19, 2016 at 12:22 PM, sheila miguez <shekay at pobox.com> wrote:

> I've been struggling with this trying to figure out why pip can't find a
> dependency when it tries to install python-keystoneclient. Our django app
> has a requirements file with pinned versions. Recently we updated
> python-keystoneclient to 2.1.1. It depends on pbr>=1.8.
>
> When I try to deploy our project, the step where it installs dependencies
> fails when it gets to python-keystoneclient because it cannot find a
> version of pbr that satisfies >=1.8.
>
> Pip is invoked this way in a Makefile that was passed down to me.
> /path/to/third-party has tarballs of all the dependencies. It contains pbr
> 1.8.0:
>
> pip install -r requirements.txt --fine-links file:///path/to/third-party
> --no-index --index-url=file:///dev/null
>
> The stack trace from pip
>
> Downloading/unpacking python-keystoneclient==2.1.1 (from -r
> requirements.txt (line 28))
>   Running setup.py
> (path:/srv/mojo/c3test/trusty/c3local-workspace1/build/application/build/python-keystoneclient/setup.py)
> egg_info for package python-keystoneclient
>     Download error on https://pypi.python.org/simple/pbr/: [Errno -2]
> Name or service not known -- Some packages may not be found!
>     Couldn't find index page for 'pbr' (maybe misspelled?)
>     Download error on https://pypi.python.org/simple/: [Errno -2] Name or
> service not known -- Some packages may not be found!
>     No local packages or download links found for pbr>=1.8
>
> Why is it trying to hit pypi?
>
> I've experimented with adding pbr>=1.8 to the top of my requirements.txt
> file explicitly. That works fine.
>
> I've checked that this ancient version of pip treats 1.8.0 as >= 1.8.
>
> Is there something in pip 1.5.4 that ignores --no-index and --index?
>
> I'm going to look in to python-keystoneclient to see if they are doing
> anything weird with setuptools. It doesn't look weird to me:
>
>
> https://github.com/openstack/python-keystoneclient/blob/f5fb643f7c75ecf415cdbfc5a3bc4b01176d3e89/setup.py
>
> (I've rubberducked and chatted and whatnot already with Carl and #chipy.
> help me, mailinglist)
>
> --
> shekay at pobox.com
>



-- 
shekay at pobox.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160219/7f3f6c46/attachment.html>

From zitterbewegung at gmail.com  Sat Feb 20 00:45:26 2016
From: zitterbewegung at gmail.com (Joshua Herman)
Date: Fri, 19 Feb 2016 23:45:26 -0600
Subject: [Chicago] Pydash: Lodash for python (Functional programming library
 for python)
Message-ID: <CAB3V1znWkZuC35dDo44QhuhkMNxDGXtjFgksP7One2pNmW6HAA@mail.gmail.com>

After thinking about the flattening list discussion I found a library
called pydash which is a functional programming library for python or
if you are familiar with lodash its like lodash but for python.

See https://github.com/dgilland/pydash and
http://pydash.readthedocs.org/en/latest/#

From d-lewit at neiu.edu  Sat Feb 20 01:26:57 2016
From: d-lewit at neiu.edu (Lewit, Douglas)
Date: Sat, 20 Feb 2016 00:26:57 -0600
Subject: [Chicago] Pydash: Lodash for python (Functional programming
 library for python)
In-Reply-To: <CAB3V1znWkZuC35dDo44QhuhkMNxDGXtjFgksP7One2pNmW6HAA@mail.gmail.com>
References: <CAB3V1znWkZuC35dDo44QhuhkMNxDGXtjFgksP7One2pNmW6HAA@mail.gmail.com>
Message-ID: <CAPdZZGxmN2xoAcVDFj=ZEOaBvrmeL_VM1__YRNpM81Y+kdomvw@mail.gmail.com>

Thanks Joshua, I'll be sure to check it out.  Enjoy your weekend.

On Fri, Feb 19, 2016 at 11:45 PM, Joshua Herman <zitterbewegung at gmail.com>
wrote:

> After thinking about the flattening list discussion I found a library
> called pydash which is a functional programming library for python or
> if you are familiar with lodash its like lodash but for python.
>
> See https://github.com/dgilland/pydash and
> http://pydash.readthedocs.org/en/latest/#
> _______________________________________________
> 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/20160220/ea34c15a/attachment.html>

From johnstoner2 at gmail.com  Sun Feb 21 10:41:27 2016
From: johnstoner2 at gmail.com (John Stoner)
Date: Sun, 21 Feb 2016 15:41:27 +0000
Subject: [Chicago] Pydash: Lodash for python (Functional programming
 library for python)
In-Reply-To: <CAPdZZGxmN2xoAcVDFj=ZEOaBvrmeL_VM1__YRNpM81Y+kdomvw@mail.gmail.com>
References: <CAB3V1znWkZuC35dDo44QhuhkMNxDGXtjFgksP7One2pNmW6HAA@mail.gmail.com>
 <CAPdZZGxmN2xoAcVDFj=ZEOaBvrmeL_VM1__YRNpM81Y+kdomvw@mail.gmail.com>
Message-ID: <CAMXtMFAnmo+PJGwAEhS63Gi5cuQOO+a28YC7icT1oCmZyjvMgg@mail.gmail.com>

Interesting. I looked at pydash a bit. I like the idea of having more
functional programming facilities in Python, but pydash... some of it seems
duplicative, some of it is unnecessarily verbose... meh. It seems more
idiomatic to Javascript than Python.

So I looked around a bit. Check out fn.py. Again borrows idioms from
another language, but this time it's Scala. If I'm going to bend my Python,
I'd much rather bend it in that direction.

On Sat, Feb 20, 2016, 12:27 AM Lewit, Douglas <d-lewit at neiu.edu> wrote:

> Thanks Joshua, I'll be sure to check it out.  Enjoy your weekend.
>
> On Fri, Feb 19, 2016 at 11:45 PM, Joshua Herman <zitterbewegung at gmail.com>
> wrote:
>
>> After thinking about the flattening list discussion I found a library
>> called pydash which is a functional programming library for python or
>> if you are familiar with lodash its like lodash but for python.
>>
>> See https://github.com/dgilland/pydash and
>> http://pydash.readthedocs.org/en/latest/#
>> _______________________________________________
>> 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/20160221/b5202d23/attachment.html>

From wirth.jason at gmail.com  Sun Feb 21 11:10:15 2016
From: wirth.jason at gmail.com (Jason Wirth)
Date: Sun, 21 Feb 2016 10:10:15 -0600
Subject: [Chicago] Pydash: Lodash for python (Functional programming
 library for python)
In-Reply-To: <CAMXtMFAnmo+PJGwAEhS63Gi5cuQOO+a28YC7icT1oCmZyjvMgg@mail.gmail.com>
References: <CAB3V1znWkZuC35dDo44QhuhkMNxDGXtjFgksP7One2pNmW6HAA@mail.gmail.com>
 <CAPdZZGxmN2xoAcVDFj=ZEOaBvrmeL_VM1__YRNpM81Y+kdomvw@mail.gmail.com>
 <CAMXtMFAnmo+PJGwAEhS63Gi5cuQOO+a28YC7icT1oCmZyjvMgg@mail.gmail.com>
Message-ID: <CAEwvNMj=KJLJH3TPdBNB8RM=0ivCsLOc0LEX8ALQBb8M1rjVWQ@mail.gmail.com>

I haven't looked at PyDash but Matthew Rocklin developed the functionally
inspired Toolz library (I think there's some cython speed enhancements
too). Something to checkout if you are doing a survey of functional
libraries.



-- 
    Jason Wirth
    wirth.jason at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160221/fd7e2ad1/attachment.html>

From robkapteyn at gmail.com  Sun Feb 21 21:08:48 2016
From: robkapteyn at gmail.com (Rob Kapteyn)
Date: Sun, 21 Feb 2016 20:08:48 -0600
Subject: [Chicago] The list
In-Reply-To: <CABs1gexsTrnYAiaHDUnAqEXknn1jbAt9e3PA9bZDzUYWUKY7Rw@mail.gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
 <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
 <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>
 <CA+Svw0UVq5BjEfuLewYZTrS08dmeMhhZhQ+t+CK24XfeWX0o_Q@mail.gmail.com>
 <CABs1gexsTrnYAiaHDUnAqEXknn1jbAt9e3PA9bZDzUYWUKY7Rw@mail.gmail.com>
Message-ID: <CABdKVNhxMNg0e0+jUbFFTHvgwU63jBTWyWiwBsfG_v2uFCP0_A@mail.gmail.com>

I know what you are feeling -- code-shame and the impostor syndrome -- but
that is NOT how Python became the center of a strong and vibrant community.

Read the Zen of Python again.
It is NOT a guide to some fictional pure "idiomatic" python.
It says:  "practicality beats purity."

I've been involved with python long enough to remember the "old days" of
python 2.1.
Back then, the Perl people would criticize Python because they could do
stuff in 10 characters that we needed 3 lines for,
the Ruby people would criticize Python because functions weren't first
class objects (they are today),  functional programming people criticized
the lack of "tail call optimization", and almost every other kind of
programmer hated the white-space requirement.

I loved python because it was clean, easy to understand and it let me get
things done.

It is telling that a lot of Python's most popular tools were NOT created by
computer scientists and were certainly NOT created
using the latest pythonic "idioms".  matplotlib and django come to mind.

Today, it looks to me like Perl and Ruby are slowly disappearing and a lot
of those people are coming to Python with their ultra-nerdy
greater-than-thou "right-way" attitude.

Ignore these people and just focus on getting something done.

It is good to know what is efficient and what isn't, but that is rarely a
real factor in any real project.
The "Zen" says nothing about efficiency and "idioms".

"Idioms" are good to know and are often very nice, but sometimes they
impose patterns that are not actually good for your project.

Sometimes, I knowingly write inefficient code -- think of to no-no of
"premature optimization" -- and smile ;)
That is closer to "the Python way" than this phony "idiomatic" fad that
seems to be hitting the Python world lately.

Just my opinion ;)
Rob







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

> I echo all of the above sentiments and these are all things I'm interested
> in.
>
> I am personally here to learn from other's mistakes.  In my career (if you
> can call it that), its been less painful than re-creating them myself.
>
> I often code-shame
> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/507935737f65dff5244388bd1603388d/hn.algolia.com/?query=code%20shame&sort=byPopularity&prefix&page=0&dateRange=all&type=story>
> myself and typically suffer from impostor syndrome
> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/b62037f86be97711a2e7dec23600b63c/hn.algolia.com/?query=impostor%20syndrome&sort=byPopularity&prefix&page=0&dateRange=all&type=story> especially
> when people talk about the zen of python.  This has led me to contribute
> less to the open source community than I would have liked because I'm
> afraid people will ridicule my code.  I have even gone so far as to create
> fake github/bitbucket accounts and send pull requests.  Yep.  I'm that
> wierd.
>
> Python is such a fantastic and beautiful language, and I usually feel like
> my code doesn't live up to being called "pythonic".
>
> In that sense, I truly enjoy civil discussions around real world problems
> and how others approach them.  Seeing anti-patterns and how they are
> corrected to work is really useful to me as I try to grow my skills.
>
> While I find stack overflow / documentation / tutorials useful, there is
> just something useful about hearing feedback where the solution isn't
> posted.
> In particular, I don't have a formal computer science background, so
> topics of python's internals and effective memory management are
> particularly interesting to me.
>
> Similar to this:
>
>
> http://neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html
> <http://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/c2e535ff606622773d047be7e9fc61eb/neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html>
>
>
>
> On Thu, Feb 18, 2016 at 12:55 PM, Bob Haugen <bob.haugen at gmail.com> wrote:
>
>> On Thu, Feb 18, 2016 at 12:42 PM, kirby urner <kirby.urner at gmail.com>
>> wrote:
>> > By "lurker" I don't mean I'm completely quiet, but rather that I'm
>> nowhere
>> > near Chicago, though I was born there and went to a Djangocon in some
>> swank
>> > hotel along the river (where I led a workshop before taking off on a
>> > pilgrimage to the home town of our O'Reilly School of Technology [1]).
>>
>> Hey! I went to that workshop. It was my introduction to Python. Helped
>> enormously! Thanks a lot, Kirby Urner!
>> _______________________________________________
>> 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/20160221/b3f6f241/attachment.html>

From jeremy.mcmillan at gmail.com  Mon Feb 22 09:48:57 2016
From: jeremy.mcmillan at gmail.com (Jeremy McMillan)
Date: Mon, 22 Feb 2016 14:48:57 +0000
Subject: [Chicago] The list
In-Reply-To: <CABdKVNhxMNg0e0+jUbFFTHvgwU63jBTWyWiwBsfG_v2uFCP0_A@mail.gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
 <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
 <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>
 <CA+Svw0UVq5BjEfuLewYZTrS08dmeMhhZhQ+t+CK24XfeWX0o_Q@mail.gmail.com>
 <CABs1gexsTrnYAiaHDUnAqEXknn1jbAt9e3PA9bZDzUYWUKY7Rw@mail.gmail.com>
 <CABdKVNhxMNg0e0+jUbFFTHvgwU63jBTWyWiwBsfG_v2uFCP0_A@mail.gmail.com>
Message-ID: <CADbRpAwKwjtx3L5Ff2sSpJUzpOryc-UVcEi-D1fZ-03yF9eLpA@mail.gmail.com>

Nice manifesto! I will only disagree about the missing attribution of the
"premature optimization" quote, and the stuff that seems to draw us-vs-them
distinctions between the Python community and Computer Scientists. I
remember the "premature optimizations" thing being a Donald Knuth quote
about the spring from which all of the worst kinds of bugs flow.

I guess that means I also disagree with the "just my opinion" equivocation.
I agree Rob, but I developed my sympathies from one of the seminally
greatest computer scientists to ever speak or write about solving problems
with computers. It takes big shoes to argue against a fundamental principle
from someone with that level of insight and experience.

Please disagree with me if you want, but I think a key part of the
community is about gently putting down feelings of pride and it's uglier
twin shame; I think we do great things with humility and determination. Go
watch some of the videos of The Don doing his guest lectures at Stanford,
listen for his humility and determination, and try to catch his dry humor.

If Guido is the father of Python, Donald Knuth is a grandfather, and both
have way more to teach than just syntax and algorithms. When you stand on
the shoulders of giants, it's ironic and inappropriate to engage in self
deprecation or to be self effacing.

I was trying to think of ways that we could engage our community to promote
the communitarian participatory science attitude at the existential core of
groups like ChiPy. Maybe this list should be open to discussing bugs
(errors or omissions) we find in others' code, and the best community
response to fixing them, ergo getting the original problem solved in the
most general way practical? Maybe mentors and mentees could make a special
point to participate? Then we can have side adventures together, actively
improving open source Python software?

On Sun, Feb 21, 2016, 20:09 Rob Kapteyn <robkapteyn at gmail.com> wrote:

> I know what you are feeling -- code-shame and the impostor syndrome -- but
> that is NOT how Python became the center of a strong and vibrant community.
> [... Snip ...]
> Sometimes, I knowingly write inefficient code -- think of to no-no of
> "premature optimization" -- and smile ;)
> That is closer to "the Python way" than this phony "idiomatic" fad that
> seems to be hitting the Python world lately.
>
> Just my opinion ;)
> Rob
>
>
> On Thu, Feb 18, 2016 at 5:42 PM, Mark Graves <mgraves87 at gmail.com> wrote:
>
>> I echo all of the above sentiments and these are all things I'm
>> interested in.
>>
>> I am personally here to learn from other's mistakes.  In my career (if
>> you can call it that), its been less painful than re-creating them myself.
>>
>> I often code-shame
>> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/507935737f65dff5244388bd1603388d/hn.algolia.com/?query=code%20shame&sort=byPopularity&prefix&page=0&dateRange=all&type=story>
>> myself and typically suffer from impostor syndrome
>> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/b62037f86be97711a2e7dec23600b63c/hn.algolia.com/?query=impostor%20syndrome&sort=byPopularity&prefix&page=0&dateRange=all&type=story> especially
>> when people talk about the zen of python.  This has led me to contribute
>> less to the open source community than I would have liked because I'm
>> afraid people will ridicule my code.  I have even gone so far as to create
>> fake github/bitbucket accounts and send pull requests.  Yep.  I'm that
>> wierd.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160222/54922715/attachment.html>

From bob.haugen at gmail.com  Mon Feb 22 10:04:29 2016
From: bob.haugen at gmail.com (Bob Haugen)
Date: Mon, 22 Feb 2016 09:04:29 -0600
Subject: [Chicago] The list
In-Reply-To: <CADbRpAwKwjtx3L5Ff2sSpJUzpOryc-UVcEi-D1fZ-03yF9eLpA@mail.gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
 <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
 <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>
 <CA+Svw0UVq5BjEfuLewYZTrS08dmeMhhZhQ+t+CK24XfeWX0o_Q@mail.gmail.com>
 <CABs1gexsTrnYAiaHDUnAqEXknn1jbAt9e3PA9bZDzUYWUKY7Rw@mail.gmail.com>
 <CABdKVNhxMNg0e0+jUbFFTHvgwU63jBTWyWiwBsfG_v2uFCP0_A@mail.gmail.com>
 <CADbRpAwKwjtx3L5Ff2sSpJUzpOryc-UVcEi-D1fZ-03yF9eLpA@mail.gmail.com>
Message-ID: <CA+Svw0VtcGzDczx4a+htQiqyAcprbo6hfg-zJRnwi9yOdAy0-A@mail.gmail.com>

As a self-taught programmer, I think the Python community has a nice
balance of respect for the giants upon whose shoulders we ride and
welcome and help for the noob. *Both* are necessary for a good
software community.

Thank you all, forever.

On Mon, Feb 22, 2016 at 8:48 AM, Jeremy McMillan
<jeremy.mcmillan at gmail.com> wrote:
> Nice manifesto! I will only disagree about the missing attribution of the
> "premature optimization" quote, and the stuff that seems to draw us-vs-them
> distinctions between the Python community and Computer Scientists. I
> remember the "premature optimizations" thing being a Donald Knuth quote
> about the spring from which all of the worst kinds of bugs flow.
>
> I guess that means I also disagree with the "just my opinion" equivocation.
> I agree Rob, but I developed my sympathies from one of the seminally
> greatest computer scientists to ever speak or write about solving problems
> with computers. It takes big shoes to argue against a fundamental principle
> from someone with that level of insight and experience.
>
> Please disagree with me if you want, but I think a key part of the community
> is about gently putting down feelings of pride and it's uglier twin shame; I
> think we do great things with humility and determination. Go watch some of
> the videos of The Don doing his guest lectures at Stanford, listen for his
> humility and determination, and try to catch his dry humor.
>
> If Guido is the father of Python, Donald Knuth is a grandfather, and both
> have way more to teach than just syntax and algorithms. When you stand on
> the shoulders of giants, it's ironic and inappropriate to engage in self
> deprecation or to be self effacing.
>
> I was trying to think of ways that we could engage our community to promote
> the communitarian participatory science attitude at the existential core of
> groups like ChiPy. Maybe this list should be open to discussing bugs (errors
> or omissions) we find in others' code, and the best community response to
> fixing them, ergo getting the original problem solved in the most general
> way practical? Maybe mentors and mentees could make a special point to
> participate? Then we can have side adventures together, actively improving
> open source Python software?
>
> On Sun, Feb 21, 2016, 20:09 Rob Kapteyn <robkapteyn at gmail.com> wrote:
>>
>> I know what you are feeling -- code-shame and the impostor syndrome -- but
>> that is NOT how Python became the center of a strong and vibrant community.
>> [... Snip ...]
>> Sometimes, I knowingly write inefficient code -- think of to no-no of
>> "premature optimization" -- and smile ;)
>> That is closer to "the Python way" than this phony "idiomatic" fad that
>> seems to be hitting the Python world lately.
>>
>> Just my opinion ;)
>> Rob
>>
>>
>> On Thu, Feb 18, 2016 at 5:42 PM, Mark Graves <mgraves87 at gmail.com> wrote:
>>>
>>> I echo all of the above sentiments and these are all things I'm
>>> interested in.
>>>
>>> I am personally here to learn from other's mistakes.  In my career (if
>>> you can call it that), its been less painful than re-creating them myself.
>>>
>>> I often code-shame myself and typically suffer from impostor syndrome
>>> especially when people talk about the zen of python.  This has led me to
>>> contribute less to the open source community than I would have liked because
>>> I'm afraid people will ridicule my code.  I have even gone so far as to
>>> create fake github/bitbucket accounts and send pull requests.  Yep.  I'm
>>> that wierd.
>
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago
>

From randy7771026 at gmail.com  Mon Feb 22 11:36:45 2016
From: randy7771026 at gmail.com (Randy Baxley)
Date: Mon, 22 Feb 2016 10:36:45 -0600
Subject: [Chicago] The list
In-Reply-To: <CABdKVNhxMNg0e0+jUbFFTHvgwU63jBTWyWiwBsfG_v2uFCP0_A@mail.gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
 <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
 <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>
 <CA+Svw0UVq5BjEfuLewYZTrS08dmeMhhZhQ+t+CK24XfeWX0o_Q@mail.gmail.com>
 <CABs1gexsTrnYAiaHDUnAqEXknn1jbAt9e3PA9bZDzUYWUKY7Rw@mail.gmail.com>
 <CABdKVNhxMNg0e0+jUbFFTHvgwU63jBTWyWiwBsfG_v2uFCP0_A@mail.gmail.com>
Message-ID: <CAMqL=iiPSKvd-iasN-=SZ=PP6xDMa3BYttrDs7=7G8t03CG_=Q@mail.gmail.com>

Go Rob.  Get things done.  You need to put this out as a miniblog that can
be tweeted and otherwise socialized

On Sun, Feb 21, 2016 at 8:08 PM, Rob Kapteyn <robkapteyn at gmail.com> wrote:

> I know what you are feeling -- code-shame and the impostor syndrome -- but
> that is NOT how Python became the center of a strong and vibrant community.
>
> Read the Zen of Python again.
> It is NOT a guide to some fictional pure "idiomatic" python.
> It says:  "practicality beats purity."
>
> I've been involved with python long enough to remember the "old days" of
> python 2.1.
> Back then, the Perl people would criticize Python because they could do
> stuff in 10 characters that we needed 3 lines for,
> the Ruby people would criticize Python because functions weren't first
> class objects (they are today),  functional programming people criticized
> the lack of "tail call optimization", and almost every other kind of
> programmer hated the white-space requirement.
>
> I loved python because it was clean, easy to understand and it let me get
> things done.
>
> It is telling that a lot of Python's most popular tools were NOT created
> by computer scientists and were certainly NOT created
> using the latest pythonic "idioms".  matplotlib and django come to mind.
>
> Today, it looks to me like Perl and Ruby are slowly disappearing and a lot
> of those people are coming to Python with their ultra-nerdy
> greater-than-thou "right-way" attitude.
>
> Ignore these people and just focus on getting something done.
>
> It is good to know what is efficient and what isn't, but that is rarely a
> real factor in any real project.
> The "Zen" says nothing about efficiency and "idioms".
>
> "Idioms" are good to know and are often very nice, but sometimes they
> impose patterns that are not actually good for your project.
>
> Sometimes, I knowingly write inefficient code -- think of to no-no of
> "premature optimization" -- and smile ;)
> That is closer to "the Python way" than this phony "idiomatic" fad that
> seems to be hitting the Python world lately.
>
> Just my opinion ;)
> Rob
>
>
>
>
>
>
>
> On Thu, Feb 18, 2016 at 5:42 PM, Mark Graves <mgraves87 at gmail.com> wrote:
>
>> I echo all of the above sentiments and these are all things I'm
>> interested in.
>>
>> I am personally here to learn from other's mistakes.  In my career (if
>> you can call it that), its been less painful than re-creating them myself.
>>
>> I often code-shame
>> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/507935737f65dff5244388bd1603388d/hn.algolia.com/?query=code%20shame&sort=byPopularity&prefix&page=0&dateRange=all&type=story>
>> myself and typically suffer from impostor syndrome
>> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/b62037f86be97711a2e7dec23600b63c/hn.algolia.com/?query=impostor%20syndrome&sort=byPopularity&prefix&page=0&dateRange=all&type=story> especially
>> when people talk about the zen of python.  This has led me to contribute
>> less to the open source community than I would have liked because I'm
>> afraid people will ridicule my code.  I have even gone so far as to create
>> fake github/bitbucket accounts and send pull requests.  Yep.  I'm that
>> wierd.
>>
>> Python is such a fantastic and beautiful language, and I usually feel
>> like my code doesn't live up to being called "pythonic".
>>
>> In that sense, I truly enjoy civil discussions around real world problems
>> and how others approach them.  Seeing anti-patterns and how they are
>> corrected to work is really useful to me as I try to grow my skills.
>>
>> While I find stack overflow / documentation / tutorials useful, there is
>> just something useful about hearing feedback where the solution isn't
>> posted.
>> In particular, I don't have a formal computer science background, so
>> topics of python's internals and effective memory management are
>> particularly interesting to me.
>>
>> Similar to this:
>>
>>
>> http://neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html
>> <http://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/c2e535ff606622773d047be7e9fc61eb/neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html>
>>
>>
>>
>> On Thu, Feb 18, 2016 at 12:55 PM, Bob Haugen <bob.haugen at gmail.com>
>> wrote:
>>
>>> On Thu, Feb 18, 2016 at 12:42 PM, kirby urner <kirby.urner at gmail.com>
>>> wrote:
>>> > By "lurker" I don't mean I'm completely quiet, but rather that I'm
>>> nowhere
>>> > near Chicago, though I was born there and went to a Djangocon in some
>>> swank
>>> > hotel along the river (where I led a workshop before taking off on a
>>> > pilgrimage to the home town of our O'Reilly School of Technology [1]).
>>>
>>> Hey! I went to that workshop. It was my introduction to Python. Helped
>>> enormously! Thanks a lot, Kirby Urner!
>>> _______________________________________________
>>> 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/20160222/a3875d59/attachment.html>

From randy7771026 at gmail.com  Mon Feb 22 11:44:49 2016
From: randy7771026 at gmail.com (Randy Baxley)
Date: Mon, 22 Feb 2016 10:44:49 -0600
Subject: [Chicago] The list
In-Reply-To: <CAMqL=iiPSKvd-iasN-=SZ=PP6xDMa3BYttrDs7=7G8t03CG_=Q@mail.gmail.com>
References: <5680906D-67C6-48F4-A96B-7E46F553628C@gmail.com>
 <CADQXWrVjU1RQPkJSM4onJieaXPW0gp4+7qDDKef24tcsZftQ8A@mail.gmail.com>
 <CAPJgG3Q2escD8ThwZRbtsMhJHGrTaJNS1EkCzxrqtB8DE7v=Kw@mail.gmail.com>
 <CA+Svw0UVq5BjEfuLewYZTrS08dmeMhhZhQ+t+CK24XfeWX0o_Q@mail.gmail.com>
 <CABs1gexsTrnYAiaHDUnAqEXknn1jbAt9e3PA9bZDzUYWUKY7Rw@mail.gmail.com>
 <CABdKVNhxMNg0e0+jUbFFTHvgwU63jBTWyWiwBsfG_v2uFCP0_A@mail.gmail.com>
 <CAMqL=iiPSKvd-iasN-=SZ=PP6xDMa3BYttrDs7=7G8t03CG_=Q@mail.gmail.com>
Message-ID: <CAMqL=ihcSskrmOwW4JE+0xy6vK6GhRX9N7Vssf2BeqSbRZhzbw@mail.gmail.com>

And by the way Knuth had a lisp ( there is no dot on my keyboard (((((
language }}}}}} on purpose that made him hard to understand.(apply polish)

Nothing to do with my own lisp when I was young and also stuttered which I
still do often.  Speech Therapy

On Mon, Feb 22, 2016 at 10:36 AM, Randy Baxley <randy7771026 at gmail.com>
wrote:

> Go Rob.  Get things done.  You need to put this out as a miniblog that can
> be tweeted and otherwise socialized
>
> On Sun, Feb 21, 2016 at 8:08 PM, Rob Kapteyn <robkapteyn at gmail.com> wrote:
>
>> I know what you are feeling -- code-shame and the impostor syndrome --
>> but that is NOT how Python became the center of a strong and vibrant
>> community.
>>
>> Read the Zen of Python again.
>> It is NOT a guide to some fictional pure "idiomatic" python.
>> It says:  "practicality beats purity."
>>
>> I've been involved with python long enough to remember the "old days" of
>> python 2.1.
>> Back then, the Perl people would criticize Python because they could do
>> stuff in 10 characters that we needed 3 lines for,
>> the Ruby people would criticize Python because functions weren't first
>> class objects (they are today),  functional programming people criticized
>> the lack of "tail call optimization", and almost every other kind of
>> programmer hated the white-space requirement.
>>
>> I loved python because it was clean, easy to understand and it let me get
>> things done.
>>
>> It is telling that a lot of Python's most popular tools were NOT created
>> by computer scientists and were certainly NOT created
>> using the latest pythonic "idioms".  matplotlib and django come to mind.
>>
>> Today, it looks to me like Perl and Ruby are slowly disappearing and a
>> lot of those people are coming to Python with their ultra-nerdy
>> greater-than-thou "right-way" attitude.
>>
>> Ignore these people and just focus on getting something done.
>>
>> It is good to know what is efficient and what isn't, but that is rarely a
>> real factor in any real project.
>> The "Zen" says nothing about efficiency and "idioms".
>>
>> "Idioms" are good to know and are often very nice, but sometimes they
>> impose patterns that are not actually good for your project.
>>
>> Sometimes, I knowingly write inefficient code -- think of to no-no of
>> "premature optimization" -- and smile ;)
>> That is closer to "the Python way" than this phony "idiomatic" fad that
>> seems to be hitting the Python world lately.
>>
>> Just my opinion ;)
>> Rob
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Feb 18, 2016 at 5:42 PM, Mark Graves <mgraves87 at gmail.com> wrote:
>>
>>> I echo all of the above sentiments and these are all things I'm
>>> interested in.
>>>
>>> I am personally here to learn from other's mistakes.  In my career (if
>>> you can call it that), its been less painful than re-creating them myself.
>>>
>>> I often code-shame
>>> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/507935737f65dff5244388bd1603388d/hn.algolia.com/?query=code%20shame&sort=byPopularity&prefix&page=0&dateRange=all&type=story>
>>> myself and typically suffer from impostor syndrome
>>> <https://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/b62037f86be97711a2e7dec23600b63c/hn.algolia.com/?query=impostor%20syndrome&sort=byPopularity&prefix&page=0&dateRange=all&type=story> especially
>>> when people talk about the zen of python.  This has led me to contribute
>>> less to the open source community than I would have liked because I'm
>>> afraid people will ridicule my code.  I have even gone so far as to create
>>> fake github/bitbucket accounts and send pull requests.  Yep.  I'm that
>>> wierd.
>>>
>>> Python is such a fantastic and beautiful language, and I usually feel
>>> like my code doesn't live up to being called "pythonic".
>>>
>>> In that sense, I truly enjoy civil discussions around real world
>>> problems and how others approach them.  Seeing anti-patterns and how they
>>> are corrected to work is really useful to me as I try to grow my skills.
>>>
>>> While I find stack overflow / documentation / tutorials useful, there is
>>> just something useful about hearing feedback where the solution isn't
>>> posted.
>>> In particular, I don't have a formal computer science background, so
>>> topics of python's internals and effective memory management are
>>> particularly interesting to me.
>>>
>>> Similar to this:
>>>
>>>
>>> http://neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html
>>> <http://t.yesware.com/tt/6640a48a14dbdef70b47105ac6b72156559fc5a6/a1b00eac366e80f663deff964c4123a2/c2e535ff606622773d047be7e9fc61eb/neopythonic.blogspot.com/2008/10/sorting-million-32-bit-integers-in-2mb.html>
>>>
>>>
>>>
>>> On Thu, Feb 18, 2016 at 12:55 PM, Bob Haugen <bob.haugen at gmail.com>
>>> wrote:
>>>
>>>> On Thu, Feb 18, 2016 at 12:42 PM, kirby urner <kirby.urner at gmail.com>
>>>> wrote:
>>>> > By "lurker" I don't mean I'm completely quiet, but rather that I'm
>>>> nowhere
>>>> > near Chicago, though I was born there and went to a Djangocon in some
>>>> swank
>>>> > hotel along the river (where I led a workshop before taking off on a
>>>> > pilgrimage to the home town of our O'Reilly School of Technology [1]).
>>>>
>>>> Hey! I went to that workshop. It was my introduction to Python. Helped
>>>> enormously! Thanks a lot, Kirby Urner!
>>>> _______________________________________________
>>>> 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/20160222/2dd62d67/attachment.html>

From noah_schultz at oxfordcorp.com  Tue Feb 23 09:40:35 2016
From: noah_schultz at oxfordcorp.com (Noah Schultz)
Date: Tue, 23 Feb 2016 14:40:35 +0000
Subject: [Chicago] Contract Python Developer Opportunity in Chicago
Message-ID: <0EB0613E60C1934881C6B149B4E1C8DC01DA30E94A@PRD-MSG-MBX-001.oaifield.onasgn.com>

Greetings! I have a contract Python Developer opportunity with a client in Chicago (Near O'Hare). The job details are listed below. If you are interested, or know of anyone who may be, please reach out to me directly.


Start:                     ASAP
Location:              Chicago, IL (near O'Hare, I90/Cumberland area)
Contract:             6-9+ Months

Project:
Oxford client is working on a next generation product for the IoT (Internet of Things) market and needs an additional software engineer who is familiar with building web enabled front end applications. The software will interact with the embedded system (Linux RTOS, C/C++ Code) that controls a new product they are developing.

Required Skills:
Tornado Web Application Framework,
Python, Javascript, HTML

Bonus Skills:
C/C++ applications for embedded real time operating systems or embedded Linux experience is a big plus
Working knowledge of build environment on a Linux system.
Knowledge of pre-emptive multitasking environments and CPU configurations, boot loaders, debuggers, and memory management in an embedded space is also as strong plus



__________________________________
Noah Schultz
Chicago Market Manager, Software & Hardware
Oxford International
1515 E. Woodfield Road Suite 850
Schaumburg, IL 60173

847.619.0169 Office
847.445.5283 Cell
847.619.7335 FAX
noah_schultz at oxfordcorp.com<mailto:noah_schultz at oxfordcorp.com>

NYSE: ASGN

oxfordcorp.com<http://www.oxfordcorp.com> | LinkedIn<https://www.linkedin.com/company/oxfordinternational> | facebook<https://www.facebook.com/OxfordOGR> | twitter<https://twitter.com/oxfordindex> | Oxford Index Blog<http://info.oxfordcorp.com/oxfordindexblog>





The Right Talent. Right Now.

The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this e-mail in error, please notify the sender immediately by replying to the message and deleting the material from your computer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160223/e2dcf089/attachment.html>

From davidkunio at gmail.com  Wed Feb 24 00:50:28 2016
From: davidkunio at gmail.com (David Matsumura)
Date: Wed, 24 Feb 2016 05:50:28 +0000
Subject: [Chicago] Finance SIG - Meeting this Thursday
Message-ID: <CA+SrYEcUL23gs09ckWOr1zyaL_j=a9SXQba-7tnqyg85dOdP0g@mail.gmail.com>

Hi Chipy,

Come out Thursday 25th @ 6:30 to we will talk technical analysis based
trading strategies. Tom Johnson will share his talk "Technical Analysis
that Works" and highlight some factors he has researched. Then we will get
out the laptops and build some basic technical factors from the ground up.
The practical example section will cover some basics in pandas as well as
some general visualization techniques.

Special thanks to IIT for hosting the event and to First Recruiting for
picking up the pizza.

Here is the link.
http://www.meetup.com/_ChiPy_/events/228993623/

Thanks
David and Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160224/431d8ab3/attachment.html>

From vecano at gmail.com  Wed Feb 24 14:25:10 2016
From: vecano at gmail.com (Vicente Cano)
Date: Wed, 24 Feb 2016 13:25:10 -0600
Subject: [Chicago] Contract Python Developer Opportunity in Chicago
In-Reply-To: <0EB0613E60C1934881C6B149B4E1C8DC01DA30E94A@PRD-MSG-MBX-001.oaifield.onasgn.com>
References: <0EB0613E60C1934881C6B149B4E1C8DC01DA30E94A@PRD-MSG-MBX-001.oaifield.onasgn.com>
Message-ID: <CAB33X0+5dUUScG7nFx5OHmRFG_XuTSGy-nub8rMSi-MLwRPZVw@mail.gmail.com>

Hi Noah,

Can you tell me more about this position? For example, compensation, some
more info about the company, any other specific info on the project, etc.

Thanks,
- Vicente


On Tue, Feb 23, 2016 at 8:40 AM, Noah Schultz <noah_schultz at oxfordcorp.com>
wrote:

> Greetings! I have a contract Python Developer opportunity with a client in
> Chicago (Near O?Hare). The job details are listed below. If you are
> interested, or know of anyone who may be, please reach out to me directly.
>
>
>
>
>
> Start:                     ASAP
> Location:              Chicago, IL (near O?Hare, I90/Cumberland area)
> Contract:             6-9+ Months
>
> *Project:*
> Oxford client is working on a next generation product for the IoT
> (Internet of Things) market and needs an additional software engineer who
> is familiar with building web enabled front end applications. The software
> will interact with the embedded system (Linux RTOS, C/C++ Code) that
> controls a new product they are developing.
>
> * Required Skills:*
> Tornado Web Application Framework,
> Python, Javascript, HTML
>
> *Bonus Skills:*
> C/C++ applications for embedded real time operating systems or embedded
> Linux experience is a big plus
> Working knowledge of build environment on a Linux system.
> Knowledge of pre-emptive multitasking environments and CPU configurations,
> boot loaders, debuggers, and memory management in an embedded space is also
> as strong plus
>
>
>
>
> __________________________________
>
> *Noah Schultz*
>
> *Chicago Market Manager*, *Software & Hardware*
>
> *Oxford International*
>
> 1515 E. Woodfield Road Suite 850
>
> Schaumburg, IL 60173
>
>
>
> 847.619.0169 Office
>
> 847.445.5283 Cell
>
> 847.619.7335 FAX
>
> noah_schultz at oxfordcorp.com
>
>
>
> NYSE: ASGN
>
>
> * oxfordcorp.com <http://www.oxfordcorp.com> | LinkedIn
> <https://www.linkedin.com/company/oxfordinternational> | facebook
> <https://www.facebook.com/OxfordOGR> | twitter
> <https://twitter.com/oxfordindex> | Oxford Index Blog
> <http://info.oxfordcorp.com/oxfordindexblog>*
>
>
>
>
>
> The Right Talent.* Right Now.*
>
> The information transmitted, including attachments, is intended only for
> the person or entity to which it is addressed and may contain confidential
> and/or privileged material. Any review, retransmission, dissemination or
> other use of, or taking of any action in reliance upon this information by
> persons or entities other than the intended recipient is prohibited. If you
> received this e-mail in error, please notify the sender immediately by
> replying to the message and deleting the material from your computer.
>
> _______________________________________________
> 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/20160224/a911636b/attachment.html>

From noah_schultz at oxfordcorp.com  Wed Feb 24 14:27:46 2016
From: noah_schultz at oxfordcorp.com (Noah Schultz)
Date: Wed, 24 Feb 2016 19:27:46 +0000
Subject: [Chicago] Contract Python Developer Opportunity in Chicago
In-Reply-To: <CAB33X0+5dUUScG7nFx5OHmRFG_XuTSGy-nub8rMSi-MLwRPZVw@mail.gmail.com>
References: <0EB0613E60C1934881C6B149B4E1C8DC01DA30E94A@PRD-MSG-MBX-001.oaifield.onasgn.com>
 <CAB33X0+5dUUScG7nFx5OHmRFG_XuTSGy-nub8rMSi-MLwRPZVw@mail.gmail.com>
Message-ID: <0EB0613E60C1934881C6B149B4E1C8DC01DC66D7C2@PRD-MSG-MBX-002.oaifield.onasgn.com>

Sure, send me your email address and I can reply directly.

From: Chicago [mailto:chicago-bounces+noah_schultz=oxfordcorp.com at python.org] On Behalf Of Vicente Cano
Sent: Wednesday, February 24, 2016 1:25 PM
To: The Chicago Python Users Group <chicago at python.org>
Subject: Re: [Chicago] Contract Python Developer Opportunity in Chicago

Hi Noah,

Can you tell me more about this position? For example, compensation, some more info about the company, any other specific info on the project, etc.

Thanks,
- Vicente


On Tue, Feb 23, 2016 at 8:40 AM, Noah Schultz <noah_schultz at oxfordcorp.com<mailto:noah_schultz at oxfordcorp.com>> wrote:
Greetings! I have a contract Python Developer opportunity with a client in Chicago (Near O?Hare). The job details are listed below. If you are interested, or know of anyone who may be, please reach out to me directly.


Start:                     ASAP
Location:              Chicago, IL (near O?Hare, I90/Cumberland area)
Contract:             6-9+ Months

Project:
Oxford client is working on a next generation product for the IoT (Internet of Things) market and needs an additional software engineer who is familiar with building web enabled front end applications. The software will interact with the embedded system (Linux RTOS, C/C++ Code) that controls a new product they are developing.

Required Skills:
Tornado Web Application Framework,
Python, Javascript, HTML

Bonus Skills:
C/C++ applications for embedded real time operating systems or embedded Linux experience is a big plus
Working knowledge of build environment on a Linux system.
Knowledge of pre-emptive multitasking environments and CPU configurations, boot loaders, debuggers, and memory management in an embedded space is also as strong plus


__________________________________
Noah Schultz
Chicago Market Manager, Software & Hardware
Oxford International
1515 E. Woodfield Road Suite 850
Schaumburg, IL 60173

847.619.0169<tel:847.619.0169> Office
847.445.5283<tel:847.445.5283> Cell
847.619.7335<tel:847.619.7335> FAX
noah_schultz at oxfordcorp.com<mailto:noah_schultz at oxfordcorp.com>

NYSE: ASGN

oxfordcorp.com<http://www.oxfordcorp.com> | LinkedIn<https://www.linkedin.com/company/oxfordinternational> | facebook<https://www.facebook.com/OxfordOGR> | twitter<https://twitter.com/oxfordindex> | Oxford Index Blog<http://info.oxfordcorp.com/oxfordindexblog>





The Right Talent. Right Now.

The information transmitted, including attachments, is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this e-mail in error, please notify the sender immediately by replying to the message and deleting the material from your computer.

_______________________________________________
Chicago mailing list
Chicago at python.org<mailto: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/20160224/45a79007/attachment.html>

From skip.montanaro at gmail.com  Sun Feb 28 15:37:38 2016
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Sun, 28 Feb 2016 14:37:38 -0600
Subject: [Chicago] Looking for some OAUTH2/Google API help
Message-ID: <CANc-5Uxo+KxGuCivN=HmHbPiRyJoQNm4Kvz0xyrkvSjMOgZD6Q@mail.gmail.com>

Has anyone here who used OAUTH2 to validate applications with any of
the Google APIs? I'm sure the Python APIs themselves are no big deal,
but I have had zero luck getting the proper credentials to use.

The application is to pump a bunch of email messages from one or more
defunct mailing list archives into Google Groups via the Groups
Migration API so the archives are indexable and searchable by people
on the net. This will not use any web interface. The plan (once I can
authorize) is to just pump thousands of mail messages into one or more
Google Groups using a console (terminal-based) application.

Even if you have no experience with this stuff and are willing to
"pair program" this with the intent of figuring out how this is done
and creating the raw material for a soup-to-nuts blog on the process
(I'd be happy to write the blog post, with due credit given), let me
know. Perhaps there is a non-presentation ChiPy hack session coming
up. I see no topics given for the March 10 meeting.

Thx,

Skip Montanaro

From carl at personnelware.com  Sun Feb 28 18:54:13 2016
From: carl at personnelware.com (Carl Karsten)
Date: Sun, 28 Feb 2016 17:54:13 -0600
Subject: [Chicago] Looking for some OAUTH2/Google API help
In-Reply-To: <CANc-5Uxo+KxGuCivN=HmHbPiRyJoQNm4Kvz0xyrkvSjMOgZD6Q@mail.gmail.com>
References: <CANc-5Uxo+KxGuCivN=HmHbPiRyJoQNm4Kvz0xyrkvSjMOgZD6Q@mail.gmail.com>
Message-ID: <CADmzSSifnyLEUYLh30tfsZEVGy=d7xLSh3jVpkbxdy54RJvN2Q@mail.gmail.com>

I think I can help.

I use the api to upload 1000's of videos to youtube from the CLI.  same
thing, right?

Here is the blocker I ran into trying to help someone else use my code:

2. Get a client ID (defines who is running this code)
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#creatinganaccount

The code is here:

https://github.com/CarlFK/veyepar/blob/master/dj/lib/youtube_v3_uploader.py#L135

I floundered around writing it, so I would love to spend some time with you
writing different code so maybe my code will get cleaned up a bit.

What's next?


On Sun, Feb 28, 2016 at 2:37 PM, Skip Montanaro <skip.montanaro at gmail.com>
wrote:
>
> Has anyone here who used OAUTH2 to validate applications with any of
> the Google APIs? I'm sure the Python APIs themselves are no big deal,
> but I have had zero luck getting the proper credentials to use.
>
> The application is to pump a bunch of email messages from one or more
> defunct mailing list archives into Google Groups via the Groups
> Migration API so the archives are indexable and searchable by people
> on the net. This will not use any web interface. The plan (once I can
> authorize) is to just pump thousands of mail messages into one or more
> Google Groups using a console (terminal-based) application.
>
> Even if you have no experience with this stuff and are willing to
> "pair program" this with the intent of figuring out how this is done
> and creating the raw material for a soup-to-nuts blog on the process
> (I'd be happy to write the blog post, with due credit given), let me
> know. Perhaps there is a non-presentation ChiPy hack session coming
> up. I see no topics given for the March 10 meeting.
>
> Thx,
>
> Skip Montanaro
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago




--
Carl K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160228/e3488530/attachment.html>

From cfkarsten at gmail.com  Sun Feb 28 19:12:47 2016
From: cfkarsten at gmail.com (Carl Karsten)
Date: Sun, 28 Feb 2016 18:12:47 -0600
Subject: [Chicago] Looking for some OAUTH2/Google API help
In-Reply-To: <CADmzSSifnyLEUYLh30tfsZEVGy=d7xLSh3jVpkbxdy54RJvN2Q@mail.gmail.com>
References: <CANc-5Uxo+KxGuCivN=HmHbPiRyJoQNm4Kvz0xyrkvSjMOgZD6Q@mail.gmail.com>
 <CADmzSSifnyLEUYLh30tfsZEVGy=d7xLSh3jVpkbxdy54RJvN2Q@mail.gmail.com>
Message-ID: <CADmzSSgXhpb8-nukggkZQA3FpE2+qGEm2NT6Zd4CCUEFRjsEvA@mail.gmail.com>

On Feb 28, 2016 5:54 PM, "Carl Karsten" <carl at personnelware.com> wrote:
>
> I think I can help.
>
> I use the api to upload 1000's of videos to youtube from the CLI.  same
thing, right?
>
> Here is the blocker I ran into trying to help someone else use my code:
>
> 2. Get a client ID (defines who is running this code)
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#creatinganaccount
>

Oh yeah, getting the -right- key is what trips me up.  Getting the wrong
key is easy.  I think the process is optimized for web sites that let some
random user with a goog account comment on cat vids.

> The code is here:
>
>
https://github.com/CarlFK/veyepar/blob/master/dj/lib/youtube_v3_uploader.py#L135
>
> I floundered around writing it, so I would love to spend some time with
you writing different code so maybe my code will get cleaned up a bit.
>
> What's next?
>
>
> On Sun, Feb 28, 2016 at 2:37 PM, Skip Montanaro <skip.montanaro at gmail.com>
wrote:
> >
> > Has anyone here who used OAUTH2 to validate applications with any of
> > the Google APIs? I'm sure the Python APIs themselves are no big deal,
> > but I have had zero luck getting the proper credentials to use.
> >
> > The application is to pump a bunch of email messages from one or more
> > defunct mailing list archives into Google Groups via the Groups
> > Migration API so the archives are indexable and searchable by people
> > on the net. This will not use any web interface. The plan (once I can
> > authorize) is to just pump thousands of mail messages into one or more
> > Google Groups using a console (terminal-based) application.
> >
> > Even if you have no experience with this stuff and are willing to
> > "pair program" this with the intent of figuring out how this is done
> > and creating the raw material for a soup-to-nuts blog on the process
> > (I'd be happy to write the blog post, with due credit given), let me
> > know. Perhaps there is a non-presentation ChiPy hack session coming
> > up. I see no topics given for the March 10 meeting.
> >
> > Thx,
> >
> > Skip Montanaro
> > _______________________________________________
> > Chicago mailing list
> > Chicago at python.org
> > https://mail.python.org/mailman/listinfo/chicago
>
>
>
>
> --
> Carl K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160228/5f26d91f/attachment.html>

From joe.jasinski at gmail.com  Sun Feb 28 22:18:47 2016
From: joe.jasinski at gmail.com (Joe Jasinski)
Date: Sun, 28 Feb 2016 21:18:47 -0600
Subject: [Chicago] ChiPy Call for March 10th Speakers
Message-ID: <CACdfcwUJgF8bs9H4=eCk23nERCyV+HC1oRZUfuCf-pc_eNMskg@mail.gmail.com>

Hi all,

ChiPy is looking for speakers for the March 10th Meeting. ChiPy is eager to
hear talks from both new and veteran speakers.

This month, in addition to our normal talks, we'd like to have one 5-10 min
lightning talk about a useful Python module or module feature that others
might not be aware of. Please reply if you have ideas for a full-length
talk or a module lightning talk.

If you'd like to speak, keep in mind:

   - Talks typically range between 10 and 45 min (including question time)
   - Talks should be Python-related.

To submit a talk:

   - Please send your talk idea to this list.
   - We'll need you to fill out the talk proposal form to get you on the
   schedule.
      - http://www.chipy.org/meetings/topics/propose

Let me know if you have any questions, and hope to hear from you soon!

If you'd like to attend the next meeting, you can rsvp at chipy.org or via
our Meetup <http://www.meetup.com/_ChiPy_/> group.



-- 
Joe J. Jasinski
www.joejasinski.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160228/f0c72bbe/attachment.html>

From skip.montanaro at gmail.com  Sun Feb 28 23:14:07 2016
From: skip.montanaro at gmail.com (Skip Montanaro)
Date: Sun, 28 Feb 2016 22:14:07 -0600
Subject: [Chicago] Looking for some OAUTH2/Google API help
In-Reply-To: <CADmzSSifnyLEUYLh30tfsZEVGy=d7xLSh3jVpkbxdy54RJvN2Q@mail.gmail.com>
References: <CANc-5Uxo+KxGuCivN=HmHbPiRyJoQNm4Kvz0xyrkvSjMOgZD6Q@mail.gmail.com>
 <CADmzSSifnyLEUYLh30tfsZEVGy=d7xLSh3jVpkbxdy54RJvN2Q@mail.gmail.com>
Message-ID: <CANc-5Uz6jpaNrQoUMR0v4cx-_+LfPjv511xneOD_FzbQSCMyZg@mail.gmail.com>

Carl> I think I can help.

Carl> I use the api to upload 1000's of videos to youtube from the CLI.
 same thing, right?

Yeah, pretty much.

Carl> Here is the blocker I ran into trying to help someone else use my
code:

Carl> 2. Get a client ID (defines who is running this code)
https://developers.google.com/identity/protocols/OAuth2ServiceAccount#creatinganaccount
...
Thanks, that's a new entry into developers.google.com for me. I hadn't seen
that before.

Carl> The code is here:

I'll check that out as well.

Carl> I floundered around writing it, ...

Seems to me that the whole OAUTH2 thing should be pretty much boiler plate.
Ought to be able to whittle it down to a straightforward function call or
class instantiation. Of course, at this point, I have no experience with
actual working code, so what do I know? :-/

Carl> What's next?

Let me check out that URL and your code. I'll post back here in a day or
three. Well you be at the March 10 meeting? Perhaps we can connect then.

Carl> Oh yeah, getting the -right- key is what trips me up.  Getting the
wrong key is easy.

I can assure anyone who questions the veracity of this statement that Carl
speaks the truth. I have plenty of experience with the second option at
this point.

Skip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160228/51978460/attachment.html>

From carl at personnelware.com  Mon Feb 29 14:23:57 2016
From: carl at personnelware.com (Carl Karsten)
Date: Mon, 29 Feb 2016 13:23:57 -0600
Subject: [Chicago] Looking for some OAUTH2/Google API help
In-Reply-To: <CANc-5Uz6jpaNrQoUMR0v4cx-_+LfPjv511xneOD_FzbQSCMyZg@mail.gmail.com>
References: <CANc-5Uxo+KxGuCivN=HmHbPiRyJoQNm4Kvz0xyrkvSjMOgZD6Q@mail.gmail.com>
 <CADmzSSifnyLEUYLh30tfsZEVGy=d7xLSh3jVpkbxdy54RJvN2Q@mail.gmail.com>
 <CANc-5Uz6jpaNrQoUMR0v4cx-_+LfPjv511xneOD_FzbQSCMyZg@mail.gmail.com>
Message-ID: <CADmzSSiZiW_vCE7-dX3WmqmXESA0gwD3soKsL=dKUvjrX1O+-Q@mail.gmail.com>

Here is what mine looks like:
$ jsonlint -f client_secrets.json

{ "installed" : {
      "auth_provider_x509_cert_url" : "
https://www.googleapis.com/oauth2/v1/certs",
      "auth_uri" : "https://accounts.google.com/o/oauth2/auth",
      "client_email" : "",
      "client_id" : "
999999999999-aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.apps.googleusercontent.com",
      "client_secret" : "aaaaaaaaaaaaaaaaaaaaaaaa",
      "client_x509_cert_url" : "",
      "redirect_uris" : [
          "urn:ietf:wg:oauth:2.0:oob",
          "oob"
        ],
      "token_uri" : "https://accounts.google.com/o/oauth2/token"
    } }


See, I did it.  Once, on Apr  3  2014.




On Sun, Feb 28, 2016 at 10:14 PM, Skip Montanaro <skip.montanaro at gmail.com>
wrote:

>
> Carl> I think I can help.
>
> Carl> I use the api to upload 1000's of videos to youtube from the CLI.
>  same thing, right?
>
> Yeah, pretty much.
>
> Carl> Here is the blocker I ran into trying to help someone else use my
> code:
>
> Carl> 2. Get a client ID (defines who is running this code)
> https://developers.google.com/identity/protocols/OAuth2ServiceAccount#creatinganaccount
> ...
> Thanks, that's a new entry into developers.google.com for me. I hadn't
> seen that before.
>
> Carl> The code is here:
>
> I'll check that out as well.
>
> Carl> I floundered around writing it, ...
>
> Seems to me that the whole OAUTH2 thing should be pretty much boiler
> plate. Ought to be able to whittle it down to a straightforward function
> call or class instantiation. Of course, at this point, I have no experience
> with actual working code, so what do I know? :-/
>
> Carl> What's next?
>
> Let me check out that URL and your code. I'll post back here in a day or
> three. Well you be at the March 10 meeting? Perhaps we can connect then.
>
> Carl> Oh yeah, getting the -right- key is what trips me up.  Getting the
> wrong key is easy.
>
> I can assure anyone who questions the veracity of this statement that Carl
> speaks the truth. I have plenty of experience with the second option at
> this point.
>
> Skip
>
> _______________________________________________
> Chicago mailing list
> Chicago at python.org
> https://mail.python.org/mailman/listinfo/chicago
>
>


-- 
Carl K
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/chicago/attachments/20160229/e334fca2/attachment.html>