Develop Reference

How does flask's app pattern works?

I'm willing to understand how Flask's internal app pattern works. I'm not talking about blueprints.
Flask is working differently from eg. Django because you can instanciate any number of apps and give them config.
I'm wondering how Flask's handles config. How does it pass this object to all the parts of the app.
I'm wondering about that because I want to refactor the config of my application to follow this pattern, so I need to understand it.
Edit: I don't have any problem with the Config. I'm just trying to replicate the pattern used in Flask.
Thanks,
Alexis.

In Flask app.config is a dictionary. You can put your configuration data there. That's it.
Wherever you import of reference app it will come with it's config attribute which you can access.

How does a generic Python library manage settings?

I have an existing Django app. Part of it is specific to a Django web app of ours, but another part does a lot of complicated computation, and it may be useful to more of our products. I am busy splitting off this more generic part into a library that does not depend on Django.
The Django app has a few settings -- for instance, it needs to know the location of certain data files. In Django I find that location as the MYAPP_DATA_DIR setting in settings.py, and I use django-appconf to set defaults for such settings.
What's the most common way to handle settings for generic Python libraries? Should I have a configure() function that can be called to set up the library, look in environment variables, something else?

Flask project structure

I want to know what is the best folder structure to follow when using Flask. I want to achieve the following:
/myproject
runserver.py
/app1
...
/app2
....
And of course I want to share my database configuration with all my apps. How can I achieve this? In the documentation they always talk of ONE app
PD: I'm comming from django.
PD2: I've also read this: http://flask.pocoo.org/docs/blueprints/ and this: http://flask.pocoo.org/docs/patterns/packages/#modules-and-resources

I found myself that best for me is to divide an application into blueprints. That is, split the whole thing not into separate WSGI applications but rather into these Flask-like objects which get registered in the Flask app. They provide possibilities to register errorhandlers, template context processors, etc. for views registered as endpoints of blueprint or for whole application - your choice.
Sharing of database connection object can be done through use of class with name "request_globals_class" (it must be declared in your application class which of course inherits Flask). When you provide an attribute for this class it is then accessible for a view (or whatever runs in request handling context) as an attribute of flask.g object.

Saving entities in django-nonrel with google appengine

Update: I've noticed that entities are saved (and available at the Datastore Viewer) when I save them using views (and the create_object function). But when I use shell (manage.py shell) to create and save new entity it isn't commited to the storage (but still can be seen in Tes.objects.all()).
I started playing with the django-nonrel with google appengine and I am getting frustrated by thing as simple as saving Entities.
I've set up my environment as described in instruction. I managed to run sample application and it runs ok. I'd like to extend it so it saves my entity to the storage. To do so:
I added new django module with models.py:
from django.db import models
class Tes(models.Model):
name = models.CharField(max_length=150)
I created a script to save some data:
import os
import sys
sys.path.append("d:\\workspace\\project\\")
os.environ['DJANGO_SETTINGS_MODULE'] = 'settings'
from testmodule.models import Tes
t = Tes(name="test")
t.save()
tes = Tes.objects.all()
for t in tes:
print t.name
The script runs without errrors. When I run it few times one after another, it prints more and more "test" strings. But when I try running it after a minute break the Tes.objects.all() returns nothing. During that time the datastore file changes it size (but maybe that's just some kind of logs). When I look at the http://localhost:8000/_ah/admin/datastore I can select only AhAdminXrsfToken from select field.
Anyway, what am I missing? Where I can find some kind of logs which would tell me what's wrong?

This is a gotcha that causes a lot of confusion. From the djangoappengine docs:
Also, never run manage.py runserver together with other management
commands at the same time. The changes won't take effect. That's an
App Engine SDK limitation which might get fixed in a later release.
So you can't do manage.py runserver and manage.py shell at the same time. If you do, changes to the datastore in one will not be visible in the other. There's a lock on the local datastore enforced by the App Engine SDK. Make sure you have stopped the server before you start the shell.

Shoudn't it be t.put() if you are creating an entity rather than saving it? I use put() to create an entity and it works for me. And if you import django you may want to know that there are alternatives to django such as my choice GAE + Jinja2 + WTForms especially now that google.db.djangoforms is deprecated selecting a form framework for forms, a templating engine and perhaps a db framework and you do't have to import django which often results in forcing you to import much more than you need.
So my recommendation is to avoid import django... and instead use Jinja2 + WTForms. If you really want django on app engine then you might want to check in the project www.allbuttonspressed.com that enables all django for google app engine but be certain that you need this much django when I suspect all we need is a template engine and a form framework and we can do without django.

What is an "app" in Django?

According to the documentation:
An app is a Web application that does
something -- e.g., a weblog system, a
database of public records or a simple
poll app. A project is a collection of
configuration and apps for a
particular Web site. A project can
contain multiple apps. An app can be
in multiple projects.
However, what are other examples of what makes an "app"?

What makes an app (for us) is one thing:
An App Is The Unit Of Reuse
If we might want to split it off to use somewhere else, it's an app.
If it has a reusable data model, it's an app. User Profiles: App. Customers: App. Customer Statistical History (this is hard to explain without providing too many details): App. Reporting: App. Actuarial Analysis: App. Vendor API's for data gathering: App.
If it is unique and will never be reused (i.e., customer specific) it's an app that depends on other apps. Data Loads are customer specific. Each is an app that builds on an existing pair of apps (Batch Uploads, and Statistical History)

Django apps are bundles of reusable functionality. When starting off it's easy to just use one custom app for your project, but the "Django way" is to break it up into separate apps that each only do one thing. You can take a look at django.contrib for examples of really well made reusable apps.
A recent example of mine: a client needed a way to import CSV data into the Django models. The easiest way would be to just add a model with a FileField and write a quick parser for the specific format of what they are uploading. That would work fine until the format changed and I had to go make the parser match. But this is a commonly repeated task (importing data) and unrelated to the existing app (managing that data) so I broke it out on its own. This pluggable app can import data for any active model. Now the next time a client needs import functionality I just add this code to installed_apps and run syncdb.
It's a judgement call when to break out an app onto its own, but the rule of thumb for me is if I'm likely to do something again I'll take the extra time to make it a generic app. That means I've created some tiny apps (some just contain a template tag), but it's little overhead for the future gains.

User management could very well be an app, if you are not going to use Django's built in user framework.
It has user interfaces and defined models for stored data, and it is really separate from the Blog or the Wiki application (although the information will be shared).
As long as both applications are in the same 'project' they should use the same settings for the DB. You should be able to by just making sure the proper models are imported where you are trying to use them.
See this link for a little more information.