Why did Quora choose Python for its development?

[Daniel Kluev]

From: "Daniel Kluev" <[email protected]>
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?

Did you actually read the code? SQL there is debug output of
SQLAlchemy for python code `Session.query(Test).from_self().all()`, I
left it there to just show you that it emits subquery to RDBMS.
All code in REPL is prefixed by `>>> `. Other lines are just output.

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?

There is separate module for date localization. You can pass datetime
object to it and it will give you needed value.

The ones that bash other languages on the mailing list for their prefered language should provide good comparisons and not just make false statements

That would be valid if I would 'bash other languages', but I just
responded to your claim that Perl has advanced modules which are not
available for Python, esp. in web frameworks, as I find it one of
areas where Python shines most.
Sure Python has drawbacks, esp. its performance and poor threads
support (GIL), but flexibility and modules of all flavors and types
are not among them. Introduction of parameter annotations should make
these modules even greater, once python 3.x is widely adopted.

 

[Ulrich Eckhardt]

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.

Ahem, is this Java the language that a certain, well-known service provider
is getting screwed over hard currently, because they forgot to read the
fineprint in the declaration of freedom? And this Objective C, isn't this
the language that GCC had support for since before it properly supported
C++, and that on a multitude of targets?

I'm probably just confusedly feeding flames here, but I like it snug and
warm.

Uli

 

[Octavian Rasnita]

From: "Daniel Kluev" <[email protected]>
a = [1,2]
dict([a])

Yes, but

d = dict([a])

is not so nice as

$d = @a;

because it has exactly those numerous number of params and brackets which is
used as a reason for bashing Perl and an aditional "dict" word.

Octavian

 

[Octavian Rasnita]

There is separate module for date localization. You can pass datetime
object to it and it will give you needed value.

Aha, so with other words that ORM doesn't have that feature.
DBIX::Class also use the DateTime module, but it can use it directly,
without needing to write more code for that, and it can also return
localized dates.

That would be valid if I would 'bash other languages', but I just
responded to your claim that Perl has advanced modules which are not

No you haven't responded because you haven't shown any thing that can be
done by the web framework and the ORM you are praising but can't be done by
Catalyst and DBIx::Class, however I have shown you that DBIx::Class can
return DateTime objects directly, without needing to load the DateTime
module manually and to initialize the DateTime object manually...

And don't take my words out of the context, because I have also answered to
another list member that was bashing Perl without offering other helpful
information than just that kind of jokes which are usually made by teenagers
under 30.

Octavian

 

[Daniel Kluev]

From: "Daniel Kluev" <[email protected]>
Aha, so with other words that ORM doesn't have that feature.
DBIX::Class also use the DateTime module, but it can use it directly,
without needing to write more code for that, and it can also return
localized dates.

Once again. ORMs return _python builtin type_. Localization is not
their responsibility, and plugging it there is code bloat, rather than
feature. Sure you may ask ORM to handle JSONRPC requests on its own,
but ORM responsibility is to map RDBMS features to language objects.
All good python packages limit their functionality to specific field,
so you could choose one you prefer for each different task
independently.

without needing to load the DateTime module manually and to initialize the DateTime object manually...

This is basically stating that you didn't read the code I posted.
Where did you ever find "initialize the DateTime object manually"?
Sorry, but its pointless to discuss anything if you don't want to even
read properly examples you receive.

 

[John Bokma]

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,

Use an editor that can with a single command comment out a selection
(and revert this), like Emacs.

 

[Terry Reedy]

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,

Agreed. The latter is simply incorrect for Python and I don't know why
people say that. The statement from the Zen of Python is as follows:
"There should be one-- and preferably only one --obvious way to do it."
where 'it' is some reasonable common operation. This is a statement of
*intent* that is opposed to "All possible ways of doing things should be
included". The key word that people too often omit is *obvious* (once
one learns Python). There are usually, of necessity, multiple ways to do
something, but for common operations, there should be one way that is
obvious to the experienced Python programmer.

For instance, if you want to process the items of a collections, you can
use normal recursion, tail recursion, while iteration, or for iteration.
For the first three, you can use explicit or implicit conditions for
flow control. (Implicit conditions are by try-except.) One can use
various access methods to get the items. However, the one obvious,
compact, and efficient way is 'for item in collection:'. This works with
*any* collection with a proper __iter__ method.\

People accustomed to using tail recursion for this in other languages
sometimes request that tail-call space optimization be added to make
tail recursion a second 'obvious' way. Guido has refused because 1)
there are real problems with the idea and 2) one obvious way is enough.

Similarly, the obvious way to define a function is a def statement. One
alternative, which Guido allowed to be added for the specific purpose of
passing simple functions as arguments in function calls, is a lambda
expression. Guido has rejected requests to expand lambda expressions to
general function definitions. Again, there are real problems and one
obvious way is enough.

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.

Here I disagree. As I replied before, you are either ignoring the
obvious Python way or talking about a rare need.

 

[Octavian Rasnita]

Agreed. The latter is simply incorrect for Python and I don't know why
people say that. The statement from the Zen of Python is as follows:
"There should be one-- and preferably only one --obvious way to do it."
where 'it' is some reasonable common operation. This is a statement of
*intent* that is opposed to "All possible ways of doing things should be
included". The key word that people too often omit is *obvious* (once
one learns Python). There are usually, of necessity, multiple ways to do
something, but for common operations, there should be one way that is
obvious to the experienced Python programmer.

Yes you are right. And it is exactly the same in case of experienced Perl programmers.

There is even a Perl book regarding the best practices, with many recommendations for the obvious way to do various things, and there is the module Perl::Critic with its command line percritic that follows those best practices very closely, so it is also just a buzzword that "there is more than one way to do it" for experienced Perl programmers.

Here I disagree. As I replied before, you are either ignoring the
obvious Python way or talking about a rare need.

I was talking about the method of creating a dictionary from an array which is much shorter and clear in Perl than in Python, and if you are using this very rarely, others might need to use it often.

Octavian

 

[Daniel Kluev]

is not so nice as

$d = @a;

It is 'not so nice' only in your perception. Python clearly defines
dict as container of (key, value) pairs, and therefore its constructor
expects such pairs. Adding unjustified arbitrary ways to guess such
pairs out of linear list is exactly what is being bashed here. Is is
considered to be wrong and bad.

Moreover, you are comparing apples to oranges here, and then
complaining that apples somehow turned out to be not oranges.
If we take python way of defining dicts and check it in perl, we find
that it is not supported, so obviously perl is non-intuitive and does
not support clear and easy way of defining hashes from list of
key-value pairs:

@l = ([1, 2], [3, 4],);
%d = @l;
for $k ( keys %d ) { print "$k\n"; }

which outputs single ARRAY(0x804e158) instead of proper 1, 3, as it
does in python:

dict([[1,2], [3,4]]).keys()

[1, 3]

This is yet another example that you are just trolling here, making
silly and unbacked claims, and ignoring any valid arguments you
receive.

 

[John Bokma]

From: "Daniel Kluev" <[email protected]>
a = [1,2]
dict([a])

Yes, but

d = dict([a])

is not so nice as

$d = @a;

That will give you the number of elements in @a. What you (probably)
mean is %hash = @array;

 

[Octavian Rasnita]

Ahem, is this Java the language that a certain, well-known service
provider
is getting screwed over hard currently, because they forgot to read the
fineprint in the declaration of freedom? And this Objective C, isn't this
the language that GCC had support for since before it properly supported
C++, and that on a multitude of targets?

Someone also said that C# can be used under Mono and even though this is
true, C# still remains a proprietary language that can be totally changed if
MS wants that, as well as Objective C can be changed if Apple wants that.
So what matters is if the most important developers for a specific
language/platform are releasing the code as open source or they keep it
proprietary and I don't see a big number of programmers developing code in
C# and Objective C.

About Java... you may be right.

Octavian

 

[Octavian Rasnita]

Once again. ORMs return _python builtin type_. Localization is not
their responsibility, and plugging it there is code bloat, rather than
feature. Sure you may ask ORM to handle JSONRPC requests on its own,
but ORM responsibility is to map RDBMS features to language objects.

Who said that? The ORM responsability is to map RDBMS to the objects you
need, not to the language objects.
If the ORM can do that directly by just adding a configuration instead of
needing to manually use of other modules, why is this bloat? You add that
configuration only if you need it, not always, and it is much more simple.

All good python packages limit their functionality to specific field,
so you could choose one you prefer for each different task
independently.

All the Perl modules do the same, but some of the Perl modules accept
plugins that make easier the collaboration of different modules which are
needed often, and the need of localizing the date is a feature used often.

This is basically stating that you didn't read the code I posted.
Where did you ever find "initialize the DateTime object manually"?
Sorry, but its pointless to discuss anything if you don't want to even
read properly examples you receive.

You told that you need to use another module for localizing the date because
the ORM returns just a language date object that doesn't do that.


Octavian

 

[Octavian Rasnita]

Moreover, you are comparing apples to oranges here, and then
complaining that apples somehow turned out to be not oranges.
If we take python way of defining dicts and check it in perl, we find
that it is not supported, so obviously perl is non-intuitive and does
not support clear and easy way of defining hashes from list of
key-value pairs:
@l = ([1, 2], [3, 4],);
%d = @l;
for $k ( keys %d ) { print "$k\n"; }

which outputs single ARRAY(0x804e158) instead of proper 1, 3, as it
does in python:

dict([[1,2], [3,4]]).keys()

[1, 3]

This is yet another example that you are just trolling here, making
silly and unbacked claims, and ignoring any valid arguments you
receive.

You are showing a code but tell another thing. If it would be as you said, I
should have said that if in Perl a dictionary is made from a list using
%d = @l;

then in Python it should be
l = d

because it would be more nice. But I didn't say that. I said that it would
be nice to be able to use something like
d = dict(l)

using the Python "dict" statement for creating dicts.

And OK, Python needs another pair of brackets for doing that and this is no
problem, but the result is that the Python's syntax is not as shorter and
nice as Perl's, for the same thing.
This is what that I said.

And you are telling that in Perl should be used an even more complicated and
ugly syntax just for beeing the same as in Python just for showing that I am
wrong, but I was comparing just the shortness and cleraness of the code.

So, again, in Perl is just:

%d = @l;

Please tell me if Python has a syntax which is more clear than this for
doing this thing.
It doesn't matter if it is different or if it follows another syntax.

And again, I am not trolling anything. I am just defending a language which
has a clearer syntax for doing some things, and a shorter code for other
things, and which uses less braces and brackets than Python for other
things, and which has a single-recommended way for doing some things, even
though other list members were trolling about Perl, but nobody said
something against.

Octavian

 

[Stefan Behnel]

Beliavsky, 20.05.2011 18:39:

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

Since everyone seems to be hot flaming at their pet languages in this
thread, let me quickly say this:

Thanks for sharing the link.

Stefan

 

[Octavian Rasnita]

From: "Daniel Kluev" <[email protected]>
a = [1,2]
dict([a])

Yes, but

d = dict([a])

is not so nice as

$d = @a;

That will give you the number of elements in @a. What you (probably)
mean is %hash = @array;

Of course. Thank you for correction.

Octavian

 

[Octavian Rasnita]

Beliavsky, 20.05.2011 18:39:

Since everyone seems to be hot flaming at their pet languages in this
thread, let me quickly say this:

Thanks for sharing the link.

Maybe I have missed a message, but if I didn't, please provide that link.
I am always interested to find the best solutions.

Thanks.

Octavian

 

[Chris Angelico]

Maybe I have missed a message, but if I didn't, please provide that link.
I am always interested to find the best solutions.

At the beginning of the thread, three days and forty-odd messages ago,
this was posted:

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

It's the reason for the thread title, regardless of the current thread
content

Chris Angelico

 

[Daniel Kluev]

And you are telling that in Perl should be used an even more complicated and
ugly syntax just for beeing the same as in Python just for showing that I am
wrong, but I was comparing just the shortness and cleraness of the code.

So, again, in Perl is just:

%d = @l;

Once again. Suppose we have array of key-value pairs (two-dimensional
array), `l`. In python, converting it to dict is as simple as d =
dict(l). In perl, %d = @l; produces meaningless value. Following your
logic, this means that perl has ugly syntax.

 

[D'Arcy J.M. Cain]

So, again, in Perl is just:

%d = @l;

Please tell me if Python has a syntax which is more clear than this for
doing this thing.

How is that clear? "Shorter" != "clearer." A Python programmer
looking at that sees line noise. A Perl programmer looking at "d = dict
([a])" (or even "d = dict(a,)") sees something that has something to do
with creating a dictionary. At least he would know in which section of
the manual to look for more information.

And again, I am not trolling anything. I am just defending a language which
has a clearer syntax for doing some things, and a shorter code for other

Are Perl programmers aware of some imminent worldwide shortage of
electrons that Python programmers are not? Why is there this obsession
with shortness?

 

[D'Arcy J.M. Cain]

That will give you the number of elements in @a. What you (probably)
mean is %hash = @array;

If I was even considering using Perl, this one exchange would send me
screaming in the opposite direction.