Why did Quora choose Python for its development?

[Beliavsky]

I thought this essay on why one startup chose Python was interesting.

http://www.quora.com/Why-did-Quora-choose-Python-for-its-development

PHP was out of the question. Facebook is stuck on that for legacy
reasons, not because it's the best choice right now.[1] Our main
takeaway from that experience is that programming language choice is
very important and is extremely costly to change.

Python was a language that Charlie and I both knew reasonably well
(though I know it a lot better now than I did when we started). We
also briefly considered C#, Java, and Scala. The biggest issues with
Python are speed and the lack of typechecking.

C# seemed pretty promising. As a programming language, it's great,
but:

•We didn't want to be on the Microsoft stack. We were up for learning
something new, and MS SQL Server actually seemed pretty good, but we
knew we'd need to integrate with lots of open source code that has
only second-class support for .NET, if it supports it at all. Also,
most of the best engineers these days are used to open source stuff.
•We didn't want to take the risk of being on Mono (an open source
implementation of C#/.NET). It's not clear how long funding will be
around for that project, and I'd heard of various performance
problems. Plus, it seemed like everything else in the C# ecosystem
would assume we were on the Microsoft stack.

For a lot of little reasons, Java programs end up being longer and
more painful to write than the equivalent Python programs. It's also
harder to interoperate with non-Java stuff. Scala had a lot of the
downsides of Java and the JVM, although it wasn't quite as bad. The
language seemed a little too new and like it would bring some
unnecessary risk (for example, who knows how good will support be in
10 years).

Two other languages we very briefly thought about were OCaml and
Haskell (neither had big enough ecosystems or good enough standard
libraries, and both were potentially too hard for some designers/data
analysts/non-engineers who might need to write code).

We decided that Python was fast enough for most of what we need to do
(since we push our performance-critical code to backend servers
written in C++ whenever possible). As far as typechecking, we ended up
writing very thorough unit tests which are worth writing anyway, and
achieve most of the same goals. We also had a lot of confidence that
Python would continue to evolve in a direction that would be good for
the life of our codebase, having watched it evolve over the last 5
years.

So far, we've been pretty happy with the choice. There's a small
selection bias, but all of the employees who'd been working with other
languages in the past have been happy to transition to Python,
especially those coming from PHP. Since starting the following things
have happened:


•Python 2.6 got to the point where enough of the libraries we used
were compatible with it, and we made a very easy transition to it.
•Tornado (web framework) was released as open source, and we moved our
live updating web service to that.
•PyPy got to the point where it looks like it will eventually be
usable and will give us a significant speedup.

All together, these give us confidence that the language and ecosystem
is moving in a good direction.

[1] What are the horrors of PHP? and Do Facebook engineers enjoy
programming in PHP? and Why hasn't Facebook migrated away from PHP?
and What are some of the advantages of PHP over other programming
languages? for more on that.
Via Nizameddin HaÅŸim Ordulu and JR Ignacio.

 

[Chris Angelico]

Perl is like 10 languages smushed together.  To write it, you need only
learn one of the 10.   To read someone else's, you don't know what subset of
those 10 they've used until you get deep into the code.

+1 QOTW.

Perl: The Swiss Army Knife of programming languages, including the bit
where you can never find the right blade to open up.

Chris Angelico

 

[Octavian Rasnita]

i think we should end our butchering of perl on a light note (you may have
already read this):
EXTERIOR: DAGOBAH -- DAY
With Yoda strapped to his back, Luke climbs up one of
the many thick vines that grow in the swamp until he
reaches the Dagobah statistics lab. Panting heavily, he
continues his exercises -- grepping, installing new
packages, logging in as root, and writing replacements for
two-year-old shell scripts in Python.

YODA: Code! Yes. A programmer's strength flows from code
maintainability. But beware of Perl. Terse syntax... more
than one way to do it... default variables. The dark side
of code maintainability are they. Easily they flow, quick
to join you when code you write. If once you start down the
dark path, forever will it dominate your destiny, consume
you it will.

LUKE: Is Perl better than Python?

YODA: No... no... no. Quicker, easier, more seductive.

LUKE: But how will I know why Python is better than Perl?

YODA: You will know. When your code you try to read six months
from now.

I've noticed that on many Perl mailing lists the list members talk very rarely about Python, but only on this Python mailing list I read many discussions about Perl, in which most of the participants use to agree that yes, Python is better, as it shouldn't be obvious that most of the list members prefer Python.

If Python would be so great, you wouldn't talk so much about how bad are other languages, or if these discussions are not initiated by envy, you would be also talking about how bad is Visual Basic, or Pascal, or Delphi, or who knows other languages.

A few months ago I have asked how can I create a dictionary from a list, and there were so many techniques that I think that it is just a buzzword that in Perl there are many ways to do it, while in Python there is a single way. In Python I found from the messages I received on this mailing list that there are a lot of ways, without even beeing a "recommended" way, while in Perl there is a single way, of course much shorter and clearer.

A bad program can be written in any language, no matter if it is so strict and forces the programmer to use spaces as a way of defining the blocks of code, so the fact that Perl is very flexible is an advantage for the programmer who writes the code.

Perl offers the module Perl::Critic which offers a command line that checks the code for different levels of syntax errors which don't respect the good practices (which are also published in a book) so if the program has to be used by more programmers, it is very simple to bring it to a very standard syntax.

Perl also has Perl::Tidy that offers another command line which re-arrange the code to a standard way, including the indentation type, the placement of parenthesis, spacing and other things, so the programs can look visually the same.

And these are advantages for those that need to read the code by others also.

Because of its flexibility, Perl offers more advanced modules and libraries which are not available for Python. For example, Catalyst web framework is much powerful and flexible than any other Python framework, because it can be used with any ORM, with any templating system, with any form processor, with any type of configuration files (Apache style, ini, JSON, XML, perl data structures, yaml), and it can run with its own web server, or with mod_perl, FastCGI, cgi, psgi without any change, and it has a very clean and flexible URL dispatcher that doesn't need to do (and maintain) the URL mapping in a distinct module made only for this.
A Catalyst based application is very easy to maintain because it has a very clean structure and the command lines that can be used to automaticly generate the base for controllers, models or views also generate the base test files and also create a few basic tests for the created modules, beeing very easy to add new tests.

And DBIx::Class ORM is a very powerful ORM and Template-Toolkit a great templating system, and Moose can be used to create a very powerful object model, and there are a lot of other very good modules which are not available for other languages.

It can be hard to find the good quality Perl code while you don't know where to look for though. This is right, because the web is full of old-style Perl code since the era of Matt's Perl script archive, and the web is also full of pirated books about using CGI, but talking about that bad style code shows just that you are talking about something you don't know.

Somebody told that C# and Objective C are good languages. They might be good, but they are proprietary, and not only that they are proprietary, but they need to be ran under platforms that cannot be used freely, so from the freedom point of view, Perl, Ruby, Python and Java are the ways to go.

Octavian

 

[Daniel Kluev]

Because of its flexibility, Perl offers more advanced modules and libraries which are not available for Python.

What 'flexibility' are you talking about? This seem to be very biased
statement, based on lack of according python experience.

There are many python web frameworks which allow you to use w/e
interfaces, template languages and ORMs you want - Pyramid/Pylons is
good example.
'Very powerful' and 'great' are 'very useless' descriptions of these
modules. Please, show us what exactly is so 'advanced' about them
which cannot be done in python.

 

[Octavian Rasnita]

What 'flexibility' are you talking about? This seem to be very biased
statement, based on lack of according python experience.

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.

There are many python web frameworks which allow you to use w/e
interfaces, template languages and ORMs you want - Pyramid/Pylons is
good example.
'Very powerful' and 'great' are 'very useless' descriptions of these
modules. Please, show us what exactly is so 'advanced' about them
which cannot be done in python.

Every language can do almost anything, so this is not important, because the Python programmers didn't chose Python because it can do what other languages cannot do.

It is important how easy is to create an app with it, and while Python offers helpful features for creating desktop apps, for creating web apps Perl is better.

Here is a text from the documentation of Pyramid/Pylons:

"We finally need to add some routing elements to our application configuration if we want our view functions to be matched to application URLs.
....
# routes setup
config.add_route('list', '/')
config.add_route('new', '/new')
config.add_route('close', '/close/{id}')
"
....

First, this is a bad style of mapping urls, because this list must be maintained every time the programmer changes something in a controller that makes the app need to use other urls.
Catalyst don't need this overhead and don't need to specify the url mapping in a separate module. If the controllers change, then the url dispatching also changes.

Second, this way of url dispatching is not so flexible, because it doesn't allow as many types of url mappings.
Catalyst allows to dispatch the urls to actions based on controllers and subroutines names, globally or locally (based on the current controller), it allows dispatching based on regular expressions, it allows a chained dispatch where more actions are executed in a certain order on a single request, and all these without typing code outside of the subroutines that do the actions.

The module DBIx::Class which is used usually as an ORM can create the class files for all the tables from a database (MySQL, Oracle, PostgreSQL, SQLite, 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 objects like DateTime objects and can also return those type of objects, and many 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.

HTML::FormFu form processor is one of the most used form processors in Catalyst applications and it can generate and parse forms created directly in the code of the application, or as external configuration files defined using 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 forms, for example the list of elements in a combo box can be taken directly from 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 programming 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 after the submit, the insertion in the database requiring just:

$form->model->create;
or
$form->model->update( $db_record );

....after that record was defined using just something like:

my $db_record = $c->model( 'DB::TableName' )->find( $record_id );

And HTML::FormFu can do filtering based on many conditions, impose the specified constraints, specify different inflators/deflators from the inserted strings to their corresponding object types, do a validation eventualy based on a database query that checks for duplicates or other things, transform the data automaticly after the form was processed, can use I18N for displaying the field labels or values translated in the active language, have its own rendering engine or can render custom form fields made using Template-Toolkit, etc.

Yes, for web apps I have seen more things which can be done much better in Perl, much easier and clear, with less code, and not because the programmer needs to do not-recommended tricks for shortening the code, but because there are very many modules on CPAN that do the hard work.
Octavian

 

[Dennis Lee Bieber]

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.

FORTRAN, Pascal, and Ada don't require indentation either -- but
other than my first year F-IV class(1976 -- we were limited to Hollerith
cards, and checking out drums to add tabbing columns was too painful to
use), once access to the Hazeltine terminals was permitted we always
used indentation to illustrate the logic. Since indentation seems so
crucial to easy comprehension of the logical structure of a program,
making it a mandatory syntactical structure becomes a desirable feature
for code that must be maintained (by others, in many cases).

As for the dictionary from list... Do not confuse /algorithms/
selected by the programmer from what is part of the native language.
Otherwise one could complain that there is more than one way to code a
spam-filter using Python...

 

[Terry Reedy]

I've noticed that on many Perl mailing lists the list members talk
very rarely about Python,

Interesting. I learned about Python on comp.lang.perl, but that was over
a decade ago.

but only on this Python mailing list I read
many discussions about Perl, in which most of the participants use to
agree that yes, Python is better, as it shouldn't be obvious that
most of the list members prefer Python.

This list really has very little other-language bashing.

A few months ago I have asked how can I create a dictionary from a
list, and there were so many techniques that I think that it is just
a buzzword that in Perl there are many ways to do it, while in Python
there is a single way. In Python I found from the messages I received
on this mailing list that there are a lot of ways, without even
beeing a "recommended" way, while in Perl there is a single way, of
course much shorter and clearer.

I forget the exact question you asked, but this list is not the doc. The
doc section on dicts gives dict(list_of_key_value_pairs) as the one true
way, given such an input. The Perl way cannot be clearer and can only be
shorted if it uses something shorter that dict().

If the list is a flat list of alternating keys and values, then yes,
they must be paired, and there are several ways to do that, partly
depending on the exact specifications, including allowed input and how
an odd key left over should be treated. In any case, unpaired keys and
values strikes me as an unusual input format for a dict. They typically
would have been paired as some point and in Python, should not need to
be unpaired.

 

[Daniel Kluev]

From: "Daniel Kluev" <[email protected]>
I am talking about that flexibility which was criticized in the previous messages telling that this flexibility allows any programmer to use his ownway.
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 interpretthe 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 maintained every time the programmer changes something in a controller that makes 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 class files for all the tables from a database (MySQL, Oracle, PostgreSQL, SQLite, 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 objects like DateTime objects and can also return those type of objects, and many other things, and most of the things it can do can be done without usingSQL 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 Catalyst applications and it can generate and parse forms created directly inthe code of the application, or as external configuration files defined using 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 forms, for example the list of elements in a combo box can be taken directly from a database by specifying just a few configuration elements. The resultsof a form submit can be also inserted in a database using a connector withDBIx::Class without specifying any database table column name in the programming 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 after 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 in Perl, much easier and clear, with less code, and not because the programmer 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.

 

[John Bokma]

I forget the exact question you asked, but this list is not the
doc. The doc section on dicts gives dict(list_of_key_value_pairs) as
the one true way, given such an input. The Perl way cannot be clearer
and can only be shorted if it uses something shorter that dict().

my %hash = @list_of_key_value_pairs;

 

[Octavian Rasnita]

Since indentation seems so crucial to easy comprehension of the logical
structure of a program,
making it a mandatory syntactical structure becomes a desirable feature
for code that must be maintained (by others, in many cases).

Why "in many cases"? I wrote hundreads of programs which are working fine
and which are maintained only by me. (But they would be very easy to
maintain by other people if it would be necessary).
So in that case, why to be forced to use a strict indentation?

As for the dictionary from list... Do not confuse /algorithms/
selected by the programmer from what is part of the native language.
Otherwise one could complain that there is more than one way to code a
spam-filter using Python...

Exactly, I am not talking about a complex task that can be done in many ways
in all programming languages.
I am talking about a simple way of creating a hash/dict from an array, which
is so simple that there should be really a single way to do it, or very few.

Octavian

 

[Octavian Rasnita]

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.

This means that you are forgetting Moose objects in Perl, right?
Moose is a very advanced object type system that will be the default type in
Perl 6, but which was also implemented in Perl 5, which offers a lot of
features for introspections in the object structure.

And the flexibility do offer the possibility of coding much easier and
offering more features.
There are more, but a single eloquent feature is the possibility of
interpreting variables in strings which cannot be done so nice in Python.

Explicit is better than implicit.

This is false. Explicit in this case means to write code in 2 places for
doing a certain thing, and maintaining means changing the code in 2 places,
which is harder and prone to errors.

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.

In Catalyst you can also define the url mappings in any way you need, not
only based on controller/actions locations, but you don't need to do this by
creating code in 2 places so it would be easier to maintain.
In Catalyst all the mappers are done "automaticly", but they can be done in
any way you like, even in more ways that under Pylons/Pyramid as I shown
(unless in Pylons/Pyramid can be also defined chained mappings and mappings
based on regular expressions).

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.

Yes, the single difference is that Catalyst supports all of them, and it
also supports using any templating system, and any ORM and any form
processor, while some of the Python web frameworks don't support absolutely
everything and you need to abandon some preferred modules for beeing able to
use some other modules which are supported.

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.

I've checked the documentation for some of them and I've seen that most of
them don't support sub-selects and some of them require using plain SQL code
in their construct for more complex queries.
Please tell me which of them supports sub-selects, and are able to return
objects for date and datetime fields that have methods for beeing able to
print just the year or day, or the months names in the specified locale
because it would be useful.

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.

Please tell me which of those ORMS can do what DBIx::Class can do as I asked
above, before calling it "trivial", and which are those aditional features
it can do but DBIx::Class cannot, because otherwise it would be very simple
for anyone to just say "go to read the documentation and see how great it
is".

Octavian

 

[Chris Angelico]

Why "in many cases"? I wrote hundreads of programs which are working fine
and which are maintained only by me. (But they would be very easy to
maintain by other people if it would be necessary).
So in that case, why to be forced to use a strict indentation?

The reason for clear code is maintenance, not maintenance-by-others.
If you come back to something in a year, you'll appreciate proper
variable names, indentation, etc.

That said, though, I still do not believe in Python's philosophy of
significant whitespace. I like to be able, if I choose, to put one
entire "logical unit" on one line, such that it can be commented out
with a single comment marker, or duplicated to another line and one
copy commented out, or whatever. To that end, I sometimes want to put
an if, its associated else, and sometimes a statement for both
branches, all in the one line. And that's not possible when whitespace
alone defines the end of an if/else block (the one-line form of a
Python 'if' can't have a non-conditional statement after it at all),
but is quite easy when things are delimited with braces.

Bug report: The "from __future__ import braces" statement isn't
working properly. Pls fix, kthxbye.

But I still like Python overall. There's no such thing as a perfect
language, and when it comes to syntax disagreements, I dislike
Python's significant whitespace far less than I dislike PHP's adorned
variable names. And Python, under the hood, is a very good engine for
doing what I need to do.

Chris Angelico

 

[Terry Reedy]

I am talking about a simple way of creating a hash/dict from an array,
which is so simple that there should be really a single way to do it, or
very few.

Again, Python has such:

dict([['one',1],['two', 2]])

{'two': 2, 'one': 1}

 

[Chris Angelico]

Sure we would.  Sometimes it's fun to sit on your lofty throne and scoff at the peasantry.

It's also fun, and sometimes productive, to sit on many different
lofty thrones, and then to have a Jedi Council meeting in which we
discuss which thrones are hard to climb onto, which ones are easy for
a child to sit on but hard to get any work done on, and which ones are
really comfortable and ergonomic, but have just that one little hard
bit to the right of where your arm wants to rest, but if you're
careful it won't jab into you too badly... and in those discussions,
Perl is a literal Swiss Army Knife.

I would suggest that envy isn't the reason, the reason is that Perl is just that much worse than Visual Basic, Pascal, and Delphi.  We only make fun of the really, really bad langauges.

I'm not sure that Perl deserves to be put alongside Visual Basic. I'm
not sure that ANY language deserves that...

Chris Angelico

 

[Daniel Kluev]

There are more, but a single eloquent feature is the possibility of
interpreting variables in strings which cannot be done so nice in Python.

I've should probably mentioned it earlier, but I'm not Perl expert,
not following its development and can't be bothered to read its docs.
Could you please provide examples of features you mention with
expected result, so I could suggest reasonable Python analogue?

This is false. Explicit in this case means to write code in 2 places for
doing a certain thing, and maintaining means changing the code in 2 places,
which is harder and prone to errors.

Not sure what do you mean by 'write code in 2 places'. All mapping
code is located in routes config, including all needed args
validation.
But if you want to couple it with controller code, there, as I said,
are numerous ways to do it. You can even do something like this:

class SomeController(BaseController):
...
@map(conditions=dict(method='GET'))
def some_method(self, arg1:int, arg2:str):
...

so it would be called via /somecontroller/some-method/1/blabla with
trivial decorator.

(unless in Pylons/Pyramid can be also defined chained mappings and mappings
based on regular expressions).

Not sure what do you mean by "based on regular expressions". Routes
paths ARE regular expressions. Conditions are regexes too.

As for chained mappings - no idea, never had the need in such thing.

Yes, the single difference is that Catalyst supports all of them, and it
also supports using any templating system, and any ORM and any form
processor, while some of the Python web frameworks don't support absolutely
everything and you need to abandon some preferred modules for beeing able to
use some other modules which are supported.

Pyramid and Pylons let you use pretty much any templating package and
ORM as well. There is nothing in them that would block such modules.

I've checked the documentation for some of them and I've seen that most of
them don't support sub-selects and some of them require using plain SQL code
in their construct for more complex queries.
Please tell me which of them supports sub-selects, and are able to return
objects for date and datetime fields that have methods for beeing able to
print just the year or day, or the months names in the specified locale
because it would be useful.

Python has builtin type for DateTime, and SQLAlchemy, for example,
returns exactly that:

#> python
Python 2.7.1 (r271:86832, May 17 2011, 19:31:41)
[GCC 4.4.5] on linux2
Type "help", "copyright", "credits" or "license" for more information.[<Test(1, 1, 2011-05-23 18:53:39.459054)>, <Test(2, 2, 2011-05-23
18:53:51.859754)>]

sadt sources here if interesting: http://pastebin.ca/2067372

So as you see, datetime is not only returned properly, but you can
also do queries with either date or datetime values, including
comparison and range.

Subqueries are fully supported too:2011-05-23 19:07:02,662 INFO sqlalchemy.engine.base.Engine.0x...552c
SELECT anon_1.test_id AS anon_1_test_id, anon_1.test_val AS
anon_1_test_val, anon_1.test_date AS anon_1_test_date
FROM (SELECT test.id AS test_id, test.val AS test_val, test.date AS test_date
FROM test) AS anon_1
2011-05-23 19:07:02,662 INFO sqlalchemy.engine.base.Engine.0x...552c ()
[<Test(1, 1, 2011-05-23 19:06:36.804128)>, <Test(2, 1, 2011-05-23
19:06:36.808022)>, <Test(3, 1, 2011-05-23 19:06:36.810698)>, <Test(4,
2, 2011-05-23 19:06:36.813357)>, <Test(5, 3, 2011-05-23
19:06:36.816373)>]

This is most trivial example of subqueries, since I'm too lazy to
produce proper tables to demonstrate it, but SQLAlchemy has very good
subquery support, as its typical way to deal with one-to-many
relations (but it does support other loading strategies as well,
including inner/outer joins or lazy loading).

it can do but DBIx::Class cannot, because otherwise it would be very simple
for anyone to just say "go to read the documentation and see how great it
is".

But "go to read the docs" argument works both ways - I have zero
knowledge of DBIx::Class, so obviously I cannot say what features it
lacks compared to SQLA.
However this is what I wanted to highlight - you cannot simply state
that "Perl offers more advanced modules and libraries which are not
available for Python" if you don't have reasonable experience with
according Python modules.

 

[Octavian Rasnita]

I am talking about a simple way of creating a hash/dict from an array,
which is so simple that there should be really a single way to do it, or
very few.

Again, Python has such:

dict([['one',1],['two', 2]])

{'two': 2, 'one': 1}

That is not an array, but a list. An array has a name and we can't do
something like the following simple statement in Python:

l = (1, 2)
d = dict(l)

While in Perl we can do:

@l = (1, 2);
%d = @l;

But let's remember from what this discussion started. This is not a Python
critique, because each language has its own ways.
I just wanted to show that the fact that "there is more than one way to do
it" in Perl and that "there is a single way" in Python are just buzzwords,
because this was an example where in Python there are many ways to do it
while in Perl there is a single way used usually, which is also more simple.

Octavian

 

[Aleksandar Radulovic]

Hi,

I'm going to skip the Perl vs. Python flame-bait and correct your one statement.

Somebody told that C# and Objective C are good languages. They might be good, but they are proprietary, and not only that they are proprietary, but they need to be ran under platforms that cannot be used freely, so from thefreedom point of view, Perl, Ruby, Python and Java are the ways to go.

Neither of those are proprietary and can, in fact, be used freely. GNU
compiler compiles objective-c code with no problem and then there's
Mono for C# and .NET development on multiple platforms.

But if by proprietary you mean the libraries and APIs that complement
those languages, the it's worth noting that Mono implements most of
..NET framework and it is free. If you want "free" Cocoa APIs (or other
Obj-C frameworks) look into GnuSTEP.

Best regards,
alex.

 

[Octavian Rasnita]

The reason for clear code is maintenance, not maintenance-by-others.
If you come back to something in a year, you'll appreciate proper
variable names, indentation, etc.

That said, though, I still do not believe in Python's philosophy of
significant whitespace. I like to be able, if I choose, to put one
entire "logical unit" on one line, such that it can be commented out
with a single comment marker, or duplicated to another line and one
copy commented out, or whatever. To that end, I sometimes want to put
an if, its associated else, and sometimes a statement for both
branches, all in the one line. And that's not possible when whitespace
alone defines the end of an if/else block (the one-line form of a
Python 'if' can't have a non-conditional statement after it at all),
but is quite easy when things are delimited with braces.

Yes I also agree with that, and I also prefer *in some cases* to write short
code in a single line like:

print "..." if $var;

print $var == 123 ? "abcd" : "cedf";

print $var =~ /foo/ ? "abc" : "cdef";

....instead of writing a few lines of code. These constructs are not
recommended for Perl either, and Perl::Critic would give a warning when it
will be used with a certain level of errors checking, but it is preferable
to be able to do what you want how you or your team want, not as the creator
of the programming language wants.

And I don't think that there are programmers that find the lines above hard
to understand or maintain.

Octavian

 

[Octavian Rasnita]

I've should probably mentioned it earlier, but I'm not Perl expert,
not following its development and can't be bothered to read its docs.
Could you please provide examples of features you mention with
expected result, so I could suggest reasonable Python analogue?

The ones that bash other languages on the mailing list for their prefered
language should provide good comparisons and not just make false statements,
considering that it is enough, since most of the list members will agree
because they like Python more than other languages anyway.

If they think that what they say is true, why don't they make those
statements on Perl mailing lists, but again, offering valid comparisons.

But if you want to couple it with controller code, there, as I said,
are numerous ways to do it. You can even do something like this:

class SomeController(BaseController):
...
@map(conditions=dict(method='GET'))
def some_method(self, arg1:int, arg2:str):
...
so it would be called via /somecontroller/some-method/1/blabla with
trivial decorator.

Is the url something like /some_controller/some_method? Or the underlines
are deleted from the name of the controller and replaced with "-" in the
name of the method?
Is it possible to also add a configuration here to call this some_method
when the url /some_controller/some-method-string is accessed?
(define another string than the name of the method)
Is it possible to configure it to access this subroutine only if a certain
number of parameters are sent in the URL?

If yes, it means that its dispatcher is better than I've seen in the short
tutorial on the web.

Not sure what do you mean by "based on regular expressions". Routes
paths ARE regular expressions. Conditions are regexes too.

As for chained mappings - no idea, never had the need in such thing.

The chained dispatcher is one of the best thing offered by Catalyst, because
with it the same code should not be used twice.

For example, one can define a subroutine in which a certain record is
selected from the DB and is placed in stash.
Then there may be other subroutines for different tasks, one for editing
that record, one for deleting that record and so on.
One chain can start with the base subroutine that makes the selection from
the DB then executes the subroutine that makes the deletion and another
chain can start with the base subroutine that makes the selection than
continues with the one that starts the editting.
Of course, the chain can have more links, not only 2, but this was just a
very short example.

Python has builtin type for DateTime, and SQLAlchemy, for example,
returns exactly that:
5

Can it also set the current locale, for example romanian, and print the name
of the current month?
....something like t1.date.set_locale('ro').month_name?

SELECT anon_1.test_id AS anon_1_test_id, anon_1.test_val AS
anon_1_test_val, anon_1.test_date AS anon_1_test_date
FROM (SELECT test.id AS test_id, test.val AS test_val, test.date AS
test_date
FROM test) AS anon_1

As I said, that ORM is not able to do those SQL constructs without using
literal SQL code, but only Python variables and data structures...
An ORM is usually prefered exactly because it doesn't force the programmer
to concatenate strings for generating the SQL code, but he/she can use just
standard Perl/Python code.
Or this is possible in another way without using SQL code?

But "go to read the docs" argument works both ways - I have zero
knowledge of DBIx::Class, so obviously I cannot say what features it
lacks compared to SQLA.

Yes you are perfectly right, but not those programmers that also use Perl
started to say that Perl can do this and Python can't, or that in Perl this
is shorter and nicer than in Python.
I just wanted to show that anything Python can do can be done in Perl also,
and in some fields Python is better, in other fields Perl is better, and we
should use whatever we like the most, and not say bad words about other
languages or about those who use other languages, especially in a
coward-way, on the group of programmers that prefer the praised language.

Octavian

 

[Daniel Kluev]

That is not an array, but a list. An array has a name and we can't do
something like the following simple statement in Python:

l = (1, 2)
d = dict(l)

An array has a name

What?
In python there is no difference whether your object has any names
mapped to it or not. Its all the same, and object itself does not even
know.
Moreover, (1, 2) is tuple rather than 'array'. If you mean array as
implemented as array, then list is what you want. If you mean array
literally, there is special type 'array' somewhere in stdlib.

As for "can't do":

a = [1,2]
dict([a]) {1: 2}
a = (1,2)
dict([a])

{1: 2}