Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!feeder.news-service.com!newsfeed.xs4all.nl!newsfeed6.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=HuhUjPTxoifvNEzxWRBLx8Lw4q3pigZEZ7pFDkA61esj83OwNbleafgUvVFftBW6ko DGuqqwoZLZMl05YIa2HTpS1H15idf15ZmgsStf0TQzBh4R+lHktitl/wyyOnz1qEnzFL OYkha9kgZ7xYRkpv6g7H2mQzq7N24OxDWA9QI=
MIME-Version: 1.0
In-Reply-To: <12225671E9654FECB49613D915FAEC19@teddy>
References: <80d59383-36a3-4744-85c4-1a0577f1d3a6@dr5g2000vbb.googlegroups.com> <BANLkTinviKm4A232=niyBCsqpKeazyWm=g@mail.gmail.com> <BANLkTik+iBBgGBfZruE4BLoq0pz01sj9BQ@mail.gmail.com> <BANLkTi=dyW-ZW=bEfSZmsHDjzo34+3rHrA@mail.gmail.com> <BANLkTim0JVK-4yMxbjV+MC6TSh3k8tYPhg@mail.gmail.com> <9CDC4B2CD1F445E994119A50F65155DF@teddy> <BANLkTi=5RytpHpP1ausX9n064vkhDHz+FA@mail.gmail.com> <12225671E9654FECB49613D915FAEC19@teddy>
Date: Mon, 23 May 2011 10:42:50 +1100
Subject: Re: Why did Quora choose Python for its development?
From: Daniel Kluev <dan.kluev@gmail.com>
To: python-list@python.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Precedence: list
Newsgroups: comp.lang.python
Message-ID: <mailman.1943.1306107773.9059.python-list@python.org>
Lines: 80
NNTP-Posting-Host: 82.94.164.166
Xref: x330-a1.tempe.blueboxinc.net comp.lang.python:6026

On Sun, May 22, 2011 at 11:47 PM, Octavian Rasnita <orasnita@gmail.com> wro=
te:
> From: "Daniel Kluev" <dan.kluev@gmail.com>
> I am talking about that flexibility which was criticized in the previous =
messages telling that this flexibility allows any programmer to use his own=
 way.
> Perl doesn't force anyone to indent the code, don't force the programmer =
to define a hash element before using it, allow the programmer to interpret=
 the variables in strings directly. These things should be not used always,=
 but if in some cases if the programmer wants to use them, he can use them =
with no problems. And this means flexibility.

This is syntax-level flexibility, which, IMHO, does not affect
'advanceness' of modules at all. At language level, python is far more
flexible than perl with its magic methods and hooks, allowing to
overload any underlying language principles and protocols.

> First, this is a bad style of mapping urls, because this list must be mai=
ntained every time the programmer changes something in a controller that ma=
kes the app need to use other urls.

Explicit is better than implicit. One of reasons why I chose
Pylons/Pyramid as my standard toolkit is that it allowed me to define
mappers in any way I needed them to.
If you want automatically defined mappers, there are lots of other
python frameworks and modules which do exactly that. Moreover, even
Routes itself (module, which does url mapping in Pylons) allows you to
use automated mappers, via :controller/:action tokens. It allows
pretty much everything you listed as 'features' of catalyst mappings.
If you prefer to stuff routing logic into controllers and have default
routing based on controllers and method names, you can use TurboGears
framework, which has exactly that mindset, or you can use its mapping
modules in Pyramid application.

> The module DBIx::Class which is used usually as an ORM can create the cla=
ss files for all the tables from a database (MySQL, Oracle, PostgreSQL, SQL=
ite, MS SQL, etc), and it can be used to search using unions, sub-selects, =
can define views at ORM level, can accept to insert different types of obje=
cts like DateTime objects and can also return those type of objects, and ma=
ny other things, and most of the things it can do can be done without using=
 SQL code at all, but only standard Perl code and Perl data structures.

There are lots of Python modules which do exactly this and much more.
SQLAlchemy, SQLObject, Web2Py's DAL, and so on. They are integrated
into frameworks by default.

> HTML::FormFu form processor is one of the most used form processors in Ca=
talyst applications and it can generate and parse forms created directly in=
 the code of the application, or as external configuration files defined us=
ing JSON, or YAML, or Apache configuration style, or Perl data structures, =
or XML...
> The forms defined are very easy to create and the elements from those for=
ms, for example the list of elements in a combo box can be taken directly f=
rom a database by specifying just a few configuration elements. The results=
 of a form submit can be also inserted in a database using a connector with=
 DBIx::Class without specifying any database table column name in the progr=
amming code, and for doing this are required just a few lines of code that =
checks if the $form->submitted_and_valid() and that does the redirection af=
ter the submit, the insertion in the database requiring just:

Once again, there are dozens of such modules in python. FormAlchemy
integrates directly with SQLAlchemy, for example, and does all form
generation, parsing, validation, and instance updating/inserting for
you.

> Yes, for web apps I have seen more things which can be done much better i=
n Perl, much easier and clear, with less code, and not because the programm=
er needs to do not-recommended tricks for shortening the code, but because =
there are very many modules on CPAN that do the hard work.

I doubt you had enough experience with python frameworks like
Pyramid/Pylons or Web2Py. They have all features you listed, and code
is as trivial and clean, as it could ever be. Its surprising that you
present trivial ORM as 'advanced modules and libraries which are not
available for Python', while in fact it have been done long time ago
and in several flavors.

--=20
With best regards,
Daniel Kluev