2014-05-13 1:34 GMT+02:00 flebber <flebber.c...@gmail.com>:
> If I want to use SQLAlchemy as my ORM what would be the best option for a
I think the best option would be Pyramid but I don't know SQLAchemy or
Pyramid that much, but:
- Django doesn't support SQLAlchemy as is
- I don't recommend Flask, even if it has some «good intentions» (Jinja2 >>
Django Template, Web Browser Debugger)
- I don't know web.py, turbogears
- I only know that tornado is an async framework and *it seems to me *that
Python+Async is still not mainstream
- This year, I was working on non-web related stuff, so I'm not fully up to
> It appears the general advice regarding Django is to do it the Django way
and use the django ORM and change it out for SQLAlchemy.
You will loose a lot of the benefits of using Django. My point of view is
that removing one thing in Django (even the template system) will lead me
to remove *a lot of things*... writing a new framework. Not necessarily
because they are coupled, but because there is kind of a lot of stuff I
dislike in Django... But I still use Django, trying to avoid land mines and
working around inefficiencies...
> That to me limited knowledge leaves flask, pyramid and turbogears 2. So
if I wanted to not build it all myself as with flask then potentially
pyramid, turbogears is the best option?
Like I said, I don't recommend flask and I know nobody using turbogears for
> Is this true? I have completed the TG2 intro tutorial and have built
several small things with flask although I feel offput by doing anything
bigger in flask.
They are templates projects that help bootstrap bigger projects. But
anyway, last time I checked Flask has less resources (documentation,
example code, example project, coobooks, documented pratices...)
> See what I have done is got my python knowledge to a fair point where I
can do useful things, good knowledge of web HTML/CSS, built a few small
projects in flask to get an idea for python web, completed django
tutorials, turogears tutorials and now looking to design out a bigger
project I want to set myself and i am trying to compile the parts so I can
see what I will need to use and gather info to cover what othe things I
will need to know.
The thing that, again, goes in the direction of choosing Django, is that
it's a big noosphere == lot of ressources of different kind code, video,
articles, books == lot of people from different background and interests ==
lot of ideas. Getting to learn things is easier in this conditions.
If you choose another framework, you will invest extra time while referring
to documentation written for Django. Since you seem to be starting Python,
it will be easier to avoid this extra step of translation. Even if
«translation» is a very common pratice of programming, so working on that
skill is interesting.
> Do I have a false fear of flask and doing bigger projects?
Many people claim they use Flask on big projects, but AFAIK there is no big
open source projects written with Flask. So you can't be sure about what it
means to use Flask in big project anyway. Mozilla use extensively Django,
checkout mozilla@github <https://github.com/mozilla>.
> So at this point I know I want SQLAlchemy, will use postgres(although
mysql/maria would work fine).
SQLAlchemy is better than Django's equivalent. Like said I don't fully know
SQLAlchemy. But the SQL language mapping in Python is nicer in SQLAlchemy.
The project is dedicated to supporting RDBMS so there is better support,
tooling, I think.
Some people will say it's a matter of taste, look'n'feel and compare it to
"ice cream flavors". IMO it's not comparable to "ice cream flavor" but
different people have different needs, background and context so favor one
library instead of another without strong engineering or scientific
grounds. Money, business, HR & marketing will have more significance.
flebber <flebber.c...@gmail.com> writes:
> > One of the main parts that is tripping myself up is that I need to
> > consistently import xml files into my database.
> XML documents represent a hierarchical tree of data. Relational
> databases are not good at representing hierarchical documents.
- It's not always hierarchical data.
- RDBMS can handle hierarchical data anyway especially PostgresSQL
When I was at Libération (a french national newspaper, kind of the french
Guardian). We ported the previous CMS based on a custom PHP framework to
Django. Basically there was 3 parts:
- Frontend: main website, mainly for reading digital articles or articles
from paper version. There is several frontends for the same backend.
- Backend: forms and whatnot for journalist to manage the content of the
- Automatic processing: this needs little human interventions but are still
fully part of the CMS
The CMS import stuff, many kind among which articles bundled in XML. A
"django application", a python package integrated with django that creates
a mini-framework for implementing "import rules" called
This can do simple thing like: an XML file -> Python class -> a RDBMS row.
Or more complex stuff like:
- blacklist or whitelist input documents
- create several Python class (model instances)
- update row if it already exists
And probably other stuffs, I think it is kind of documented.
It's not perfect, but was good enough to be put into production. For
instance, the online
was fully imported by a django-swallow based modules. It was the
most complex import. It's fully integrated (search & co). It was the main
objective of django-swallow: make it easy to import paper version of the
newspaper with minimal human needed to mess around ;)
One thing it was missing, is integration with Django forms for input and
"output" (before saving in the database) validation.
It has a sibling package:
is dedicated to create "export rules".
I don't know if those are the best apps today, but when they were created,
nothing matched. See https://www.djangopackages.com/search/?q=import
I discovered recently in a PHP project a RDBMS tree structure for menus, I
can recall the name right now. Basically, even if RDBMS is not good at
trees. You make it good at the particular query that requires performance
by duplicating informations... for instance a hierarchical menu is seldom
updated, but quiet often queried, so make it easy to query and but slow to
I can't help talking about graph databases, check them out if you have time
> Any pratical advice warmly welcomed, I think I am thining too much
Like I said, previously IMO Django is less than perfect. There is hope, I
read on the ML that Django 2 is coming ;) (with no ETA of course). Anyway,
especially for beginners it's the obvious choice. And I think that if you
are a newbie, it's always better to go for the obvious *first*.
At my new company, we are aiming to move to Python. I'm not confident
pushing something else than Django. Not only because it means "extra" work,
but also, even if I hate it, because of marketing...
(free) links regarding Django in particular: