Awesome - the Python cartridge needs some love.
* take away the versions of Python (2.6, 2.7, 3.3) as a
selection of a type of cartridge when creating an app, and
make one default (I'd suggest 2.7). Then, if a user wants a
different version, then:
User locally creates a `openshift.yml` or like-file with a
variable in it: `runtime: python-3.3` or `runtime:
The git push triggers a search for a `openshift.yml` then uses
the appropriate python (system, /opt/python-3.3, etc)
Activates the virtualenv
examples that already do this: dotcloud , Heroku 
* The creation or activation of the virtual environment be
triggered by the presence of requirements.txt with something
like the following steps:
if first time, `$ virtualenv PYTHON_APP`
then do a `(PYTHON_APP) $ pip freeze` to see what is currently
installed, and compare it with requirements.txt, or just look at
the git diff.
if there's a difference, install/uninstall the missing/added
* Allow choices of the default server within some apps, like
Django's run_server (while not web scalable now, there are core
development plans in the works), gunicorn, etc as well as wsgi.
Something defined in the openshift.yml file to declare what
type to use, e.g. `server: django_gunicorn`. Example: gondor.io
* Maybe this is more of a pull request - but for our examples
we give, don't suggest folks to declare a django app like
"django>=1.3" - that will break with django 1.4, 1.5 etc
available. Django apps made on 1.3 are _not_ compatible with 1.4
+. If a user codes in 1.3, follows instructions as our examples
show , when a git push happens, you pull down the latest
Django release, not necessarily 1.3. This would be mitigated
with a requirements.txt but please don't suggest "at least",
encourage folks to pin them hard. Heroku  does suggest this
too, and is reflected in Gondor's  example.
* Do we support Python packages that contain C extensions?
Like PIL, lxml, numpy, matplotlib, etc?
* Python community is really embracing PyPy. I'd highly
suggest supporting a cartridge like that.
* My pain-point for Django is setting up the environment with
the DJANGO_SETTINGS_MODULE. With Heroku, it's quite easy to set
environment variables . This may be more of a general RHC
command, but it would be ideal to do something like `rhc
config:add DJANGO_SETTINGS_MODULE=mydjangoapp.settings` and that
translates to an `export` statement within bash on the Node.