[Develop] app.py, util.py and global functions

[will]

Sorry my reply is so late.

I like this idea.  Similarly, I think that util.py should contain helper 
functions that are easily testable and that all of them should have unit 
tests.  So these functions would use Python library functions and they 
would operate only on their arguments and return values--no global state 
manipulation.

/will


Ben Dean-Kawamura wrote:
> Currently we have a couple modules that contain a bunch of global functions
> that are called in lots of places.  app.py, contains things like
> migrateMoviesDirectory(), while util.py contains things like unicodify().
> 
> Importing these modules is a bit tricky because there's lots of circular
> dependancies going around.  util.py avoids problems by defering imports until
> inside the actual module (for example gatherVideos()).  app.py doesn't really
> avoid the problem at all and if you import things in the wrong order you get
> errors.
> 
> Seems like this could be improved.  How about this:
> 
> util.py shouldn't depend on any Miro modules.  It should only contain
> functions like unicodify() that only depend on python libraries.  This means
> you can import util anywhere (and call the functions anytime, which isn't true
> currently).
> 
> app.py is kind of a mess.  I propose we make a new module called miro.py.  It
> contains functions application-level functions that the frontend might want to
> use like gatherVideos() and migrateMoviesDirectory().  It will import a bunch
> of other miro modules, but it only will be imported by the frontend so there
> shouldn't be circular dependancies.
> 
> We should also move frontend code out of app.py.  Hopefully after that app.py
> will be empty and we delete it :)
> 
> In a special category is util.failed().  It is used lots of places and is
> depended upon in lots of places.  I think we can split it up into 2 parts:
> 
>   - signals.system.failed().  This handles formatting the bug report and
>     emitting the failed signal.  It's up to the frontend to handle it.
> 
>   - miro.sendBugReport().  Frontends can use this to send the bug report as an
>     HTTP POST.
> 
> One nice side-effect is that we can handle failures in the downloader better.
> Instead of a clunky if statement, we just connect to the "error" signal in the
> downloader and forward it to the main Miro process.
> 
> Sorry for all these emails about architecture stuff, I just want to make sure
> that what I'm doing makes sense to others.
> _______________________________________________
> Develop mailing list
> Develop at pculture.org
> http://participatoryculture.org/mailman/listinfo/develop
>