Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.freenet.ag!takemy.news.telefonica.de!telefonica.de!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'python.': 0.02; 'python,': 0.02; 'tutorial': 0.03; '(even': 0.05; 'anyway.': 0.05; 'django.': 0.05; 'tree': 0.05; 'bootstrap': 0.07; 'context': 0.07; 'referring': 0.07; 'beginners': 0.09; 'created,': 0.09; "django's": 0.09; 'django,': 0.09; 'framework.': 0.09; 'hierarchical': 0.09; 'imported': 0.09; 'mess': 0.09; 'orm': 0.09; 'quiet': 0.09; 'things,': 0.09; 'turbogears': 0.09; 'tutorials,': 0.09; 'url:github': 0.09; 'url:roundup': 0.09; 'xml.': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; 'django': 0.11; 'project,': 0.12; '<>.': 0.14; 'anyway': 0.14; 'creates': 0.14; 'template': 0.14; 'books': 0.15; '>>': 0.16; '(before': 0.16; '->': 0.16; 'aiming': 0.16; 'backend.': 0.16; 'blacklist': 0.16; 'dislike': 0.16; 'fine).': 0.16; 'html/css,': 0.16; 'mainstream': 0.16; 'modules.': 0.16; 'perfect.': 0.16; 'ported': 0.16; 'rdbms': 0.16; 'ressources': 0.16; 'sqlalchemy': 0.16; 'sqlalchemy,': 0.16; 'stuff,': 0.16; 'template,': 0.16; 'think.': 0.16; 'validation.': 0.16; 'apps': 0.16; 'subject: ?': 0.16; 'language': 0.16; 'library': 0.18; 'year,': 0.18; 'trying': 0.19; 'basically': 0.19; 'implementing': 0.19; 'projects,': 0.19; 'version.': 0.19; 'work,': 0.20; 'written': 0.21; 'seems': 0.21; 'appears': 0.22; 'code,': 0.22; 'input': 0.22; 'example': 0.22; 'import': 0.22; 'email addr:gmail.com>': 0.22; 'previously': 0.22; 'cc:addr:python.org': 0.22; 'documented': 0.24; 'exists': 0.24; 'instance,': 0.24; 'cc:2**0': 0.24; 'source': 0.25; '>': 0.26; 'compare': 0.26; 'query': 0.26; 'tutorials': 0.26; 'header :In-Reply-To:1': 0.27; 'idea': 0.28; 'point': 0.28; 'xml': 0.29; 'related': 0.29; "doesn't": 0.30; 'bigger': 0.30; 'direction': 0.30; 'said,': 0.30; 'especially': 0.30; 'message- id:@mail.gmail.com': 0.30; "i'm": 0.30; 'getting': 0.31; 'easier': 0.31; 'equivalent.': 0.31; 'extensively': 0.31; 'gather': 0.31; 'relational': 0.31; 'writes:': 0.31; 'file': 0.32; 'class': 0.32; 'probably': 0.32; 'checked': 0.32; 'know.': 0.32; 'stuff': 0.32; 'option': 0.32; 'another': 0.32; 'nobody': 0.68; 'production.': 0.68; 'skill': 0.68; 'video,': 0.68; 'integrated': 0.69; 'saving': 0.69; 'system)': 0.69; 'marketing': 0.70; 'online': 0.71; '8bit%:27': 0.74; 'obvious': 0.74; 'paper': 0.75; 'potentially': 0.81; 'url:search': 0.81; 'business,': 0.83; 'discovered': 0.83; 'comparable': 0.84; 'cream': 0.84; 'ideas.': 0.84; 'journalist': 0.84; 'loose': 0.84; 'menus,': 0.84; 'much,': 0.84; 'newbie,': 0.84; 'newspaper,': 0.84; 'particular:': 0.84; 'seldom': 0.84; 'updated,': 0.84; 'url:video': 0.84; 'url:videos': 0.84; 'whitelist': 0.84; 'articles,': 0.91; 'hate': 0.91; 'url:mozilla': 0.91; 'choice.': 0.93; 'package:': 0.93; 'url:fr': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Bz7ExQFLbWeFT0gLQ2JzkyumGOzmJa71sEe3Cy1nnPk=; b=R6o/yjH7C07khGzSiPX8tQtUMfKZqHrcTIglyv19a80CxlKVKDqU7LTPlOuiwHpofo q+27EW/ouu3f/42TUt90Je5OExC7VewuVSEr2Z6f2D9k0TK2/LKTGO9ERNDHY24/aefy Hqmux/gr8cUcXR6DdqcLdM6PMYbgKLq6nLEgRO7vZBBWctu0li3jjfmbIWjlBTTKuvtE vRkl4hVjnT589FTh83++ouTIOvKX/rg7pFORUelej14g2C8mCBVc+lz8+ix3bcZseFov FESoAw6YYFbCHYO27eScCvf7H058fWnLOz2L0uuIUHZKUvB3lRmnSuRzR4TCcSmf9UTa PXFg== X-Received: by 10.236.50.229 with SMTP id z65mr6945473yhb.120.1400849310989; Fri, 23 May 2014 05:48:30 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <17149f49-bb71-4c97-9d07-d80766b93865@googlegroups.com> References: <17149f49-bb71-4c97-9d07-d80766b93865@googlegroups.com> From: Amirouche Boubekki Date: Fri, 23 May 2014 14:48:10 +0200 Subject: Re: SQLAlchemy - web framework ? To: flebber Content-Type: multipart/alternative; boundary=089e01634d8a90e68004fa10a551 Cc: python-list X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 357 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1400849319 news.xs4all.nl 2948 [2001:888:2000:d::a6]:54868 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:71926 --089e01634d8a90e68004fa10a551 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable H=C3=A9llo, 2014-05-13 1:34 GMT+02:00 flebber : > If I want to use SQLAlchemy as my ORM what would be the best option for a web framework? 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 =C2=ABgood intentions=C2=BB = (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 date. > 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 new projects. > 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 =3D=3D lot of ressources of different kind code, video= , articles, books =3D=3D lot of people from different background and interest= s =3D=3D 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 =C2=ABtranslation=C2=BB 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 . > 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 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=C3=A9ration (a french national newspaper, kind of the fre= nch 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 website - 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 django-swallow . 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 readercont= ent 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: django-carrier-pigeonw= hich 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=3Dimport 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 update... 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 aimlessly maybe. 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: - https://www.djangopackages.com/ - http://lincolnloop.com/django-best-practices/ - http://roundup.lincolnloop.com/ - http://pyvideo.org/search?models=3Dvideos.video&q=3DDjango Happy python-ing! --089e01634d8a90e68004fa10a551 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
- This year, I was working on non-web related stuff, so I&= #39;m not fully up to date.

> It appears the general advice regarding Django= is to do it the Django way and use the django ORM and change it out for SQ= LAlchemy.

You will loose a lot of the benefits of using D= jango. My point of view is that removing one thing in Django (even the temp= late system) will lead me to remove *a lot of things*... writing a new fram= ework. 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 new projects.

> Is this true? I have completed the TG2 intro tutorial a= nd have built several small things with flask although I feel offput by doi= ng 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 wh= ere I can do useful things, good knowledge of web HTML/CSS, built a few sma= ll projects in flask to get an idea for python web, completed django tutori= als, turogears tutorials and now looking to design out a bigger project I w= ant 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 k= now.

The thing that, again, goes in the direction of choosing Dja= ngo, is that it's a big noosphere =3D=3D lot of ressources of different= kind code, video, articles, books =3D=3D lot of people from different back= ground and interests =3D=3D 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 s= tarting Python, it will be easier to avoid this extra step of translation. = Even if =C2=ABtranslation=C2=BB 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 projec= ts?


> So at this point I know I want SQLAlchemy, will use pos= tgres(although mysql/maria would work fine).

SQLAlchemy i= s better than Django's equivalent. Like said I don't fully know SQL= Alchemy. But the SQL language mapping in Python is nicer in SQLAlchemy. The= project is dedicated to supporting RDBMS so there is better support, tooli= ng, I think.

Some people will say it's a matter of taste, look'n&= #39;feel and compare it to "ice cream flavors". IMO it's not = comparable to "ice cream flavor" but different people have differ= ent needs, background and context so favor one library instead of another w= ithout strong engineering or scientific grounds. Money, business, HR & = marketing will have more significance.

flebber <flebber.crue@= 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 o= f 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=C3=A9ration (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:

- F= rontend: 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 conten= t of the website
- Automatic processing: this needs little hu= man interventions but are still fully part of the CMS

The CMS import stuff, many kind among which articles bundled in XML. A &quo= t;django application", a python package integrated with django that cr= eates a mini-framework for implementing "import rules" called django-swallow.
This can do simple thing like: an XML file -> Python clas= s -> a RDBMS row.

Or more complex stuff like:

= - blacklist or whitelist input documents
- create several Pyt= hon class (model instances)
- update row if it already exists

And probably other stuf= fs, I think it is kind of documented.

It's not perfec= t, but was good enough to be put into production. For instance, the onlin= e reader content 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 Dja= ngo forms for input and "output" (before saving in the database) = validation.

It has a sibling package: django-carrier-pig= eon which 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=3Dimpor= t

I discovered recently in a PHP project a RDBMS tree structur= e for menus, I can recall the name right now. Basically, even if RDBMS is n= ot good at trees. You make it good at the particular query that requires pe= rformance by duplicating informations... for instance a hierarchical menu i= s seldom updated, but quiet often queried, so make it easy to query and but= slow to update...

I can't help talking about graph databases, c= heck them out if you have time :)

> Any pratical advic= e warmly welcomed, I think I am thining too much aimlessly maybe.

Like I said, previously IMO Django is less than perfect. There i= s 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 *fi= rst*.

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


Happy python-ing!
--089e01634d8a90e68004fa10a551--