Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #5859 > unrolled thread

Why did Quora choose Python for its development?

Back to article view | Back to comp.lang.python

Contents

  Why did Quora choose Python for its development? Beliavsky <beliavsky@aol.com> - 2011-05-20 09:39 -0700
    Re: Why did Quora choose Python for its development? Dotan Cohen <dotancohen@gmail.com> - 2011-05-20 23:47 +0300
    Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-22 15:01 +1000
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-22 10:44 +0300
      Re: Why did Quora choose Python for its development? Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2011-05-23 12:56 +0200
        Re: Why did Quora choose Python for its development? Duncan Booth <duncan.booth@invalid.invalid> - 2011-05-23 11:28 +0000
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 08:25 +0300
      Re: Why did Quora choose Python for its development? Kevin Walzer <kw@codebykevin.com> - 2011-05-24 10:09 -0400
        Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 00:43 +1000
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:11 +0300
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-22 19:20 +1100
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-22 15:47 +0300
    Re: Why did Quora choose Python for its development? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-22 12:09 -0700
    Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-22 18:01 -0400
      Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-22 18:55 -0500
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 10:42 +1100
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 08:31 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 09:06 +0300
    Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-23 16:37 +1000
      Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-23 10:26 -0500
    Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-23 02:37 -0400
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 19:05 +1100
    Re: Why did Quora choose Python for its development? Aleksandar Radulovic <alex@a13x.net> - 2011-05-23 08:52 +0000
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 11:49 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 12:01 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 12:41 +0300
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 20:58 +1100
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 21:16 +1100
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 14:17 +0300
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-23 22:32 +1100
    Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-23 13:08 -0400
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 22:05 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-23 14:10 +0300
      Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 00:17 -0500
        Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-24 06:09 -0400
          Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 11:52 -0500
            Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-24 13:39 -0400
              Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 13:17 -0500
                Re: Why did Quora choose Python for its development? Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2011-05-27 15:48 +1200
                  Re: Why did Quora choose Python for its development? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-26 23:53 -0700
                  Re: Why did Quora choose Python for its development? Roy Smith <roy@panix.com> - 2011-05-27 09:47 -0400
                    Re: Why did Quora choose Python for its development? Karim <karim.liateni@free.fr> - 2011-05-27 22:10 +0200
              Re: Why did Quora choose Python for its development? "thegist@nospam.net" <thegist@nospam.net> - 2011-05-25 17:30 -0400
                Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-25 23:52 +0000
                  Re: Why did Quora choose Python for its development? "thegist@nospam.net" <thegist@nospam.net> - 2011-05-26 11:05 -0400
            Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 08:01 +1000
              Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 18:16 -0500
                Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 09:38 +1000
                  Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 20:48 -0500
              Re: Why did Quora choose Python for its development? Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-05-25 09:31 +0200
                Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-25 07:01 -0500
                  Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-25 12:54 -0400
                  Re: Why did Quora choose Python for its development? Ethan Furman <ethan@stoneleaf.us> - 2011-05-25 10:17 -0700
                    Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-25 14:14 -0500
                      Re: Why did Quora choose Python for its development? Matty Sarro <msarro@gmail.com> - 2011-05-25 17:19 -0400
                        Re: Why did Quora choose Python for its development? Neil Cerutti <neilc@norwich.edu> - 2011-05-26 12:44 +0000
                          Re: Why did Quora choose Python for its development? Roy Smith <roy@panix.com> - 2011-05-26 08:51 -0400
                            Re: Why did Quora choose Python for its development? Ben Finney <ben+python@benfinney.id.au> - 2011-05-26 23:11 +1000
                          Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-26 13:35 +0000
                      Re: Why did Quora choose Python for its development? RainyDay <andrei.avk@gmail.com> - 2011-05-25 17:15 -0700
                  Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-25 23:01 +0000
                    Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-25 22:00 -0500
                      Re: Why did Quora choose Python for its development? Ben Finney <ben@benfinney.id.au> - 2011-05-26 14:25 +1000
                        Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-26 10:36 -0500
                          Re: Why did Quora choose Python for its development? Terry Reedy <tjreedy@udel.edu> - 2011-05-26 16:03 -0400
                            Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-27 03:07 +0000
                              Re: Why did Quora choose Python for its development? Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-05-27 10:10 +0200
                                Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-27 09:31 +0000
                                Re: Why did Quora choose Python for its development? Ethan Furman <ethan@stoneleaf.us> - 2011-05-27 10:12 -0700
                          Re: Why did Quora choose Python for its development? Karim <karim.liateni@free.fr> - 2011-05-26 22:27 +0200
                      Re: Why did Quora choose Python for its development? Ethan Furman <ethan@stoneleaf.us> - 2011-05-26 09:18 -0700
                  Re: Why did Quora choose Python for its development? Thorsten Kampe <thorsten@thorstenkampe.de> - 2011-05-26 10:24 +0200
              Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-25 23:25 +0000
            Re: Why did Quora choose Python for its development? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2011-05-24 23:00 -0700
              Re: Why did Quora choose Python for its development? Roy Smith <roy@panix.com> - 2011-05-25 07:36 -0400
                Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 21:55 +1000
                  Re: Why did Quora choose Python for its development? Roy Smith <roy@panix.com> - 2011-05-25 08:25 -0400
                Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-25 10:23 -0400
                  Re: Why did Quora choose Python for its development? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-25 14:56 +0000
                    Re: Why did Quora choose Python for its development? Matty Sarro <msarro@gmail.com> - 2011-05-25 11:43 -0400
                Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-26 00:26 +1000
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:10 +0300
        Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-24 13:22 -0400
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 11:08 +0300
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-24 14:34 +1100
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 08:39 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 09:00 +0300
    Re: Why did Quora choose Python for its development? Stefan Behnel <stefan_ml@behnel.de> - 2011-05-24 08:23 +0200
      Re: Why did Quora choose Python for its development? Kevin Walzer <kw@codebykevin.com> - 2011-05-24 10:50 -0400
        Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:18 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 11:10 +0300
    Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-24 18:20 +1000
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-24 19:55 +1100
    Re: Why did Quora choose Python for its development? "D'Arcy J.M. Cain" <darcy@druid.net> - 2011-05-24 06:05 -0400
      Re: Why did Quora choose Python for its development? Teemu Likonen <tlikonen@iki.fi> - 2011-05-24 16:18 +0300
        Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 11:50 -0500
          Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 03:30 +1000
            Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 12:56 -0500
              Re: Why did Quora choose Python for its development? Chris Angelico <rosuav@gmail.com> - 2011-05-25 07:53 +1000
                Re: Why did Quora choose Python for its development? John Bokma <john@castleamber.com> - 2011-05-24 17:00 -0500
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:10 +0300
    Re: Why did Quora choose Python for its development? "Octavian Rasnita" <orasnita@gmail.com> - 2011-05-24 19:10 +0300
    Re: Why did Quora choose Python for its development? "thegist@nospam.net" <thegist@nospam.net> - 2011-05-26 11:52 -0400
    Re: Why did Quora choose Python for its development? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-27 08:33 +1100
      Re: Why did Quora choose Python for its development? RainyDay <andrei.avk@gmail.com> - 2011-05-26 16:41 -0700

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

#6042

On 5/23/2011 1:31 AM, Octavian Rasnita wrote:


> 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}

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#6048

On Mon, May 23, 2011 at 5:06 PM, Octavian Rasnita <orasnita@gmail.com> wrote:
> 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.
>>> from sadt import Test, Session
>>> import datetime
>>> Test(1)
<Test(1, 1, 2011-05-23 18:53:39.459054)>
>>> Test(2)
<Test(2, 2, 2011-05-23 18:53:51.859754)>
>>> t1 = Session.query(Test).filter(Test.val == 1).one()
>>> t1
<Test(1, 1, 2011-05-23 18:53:39.459054)>
>>> t1.date
datetime.datetime(2011, 5, 23, 18, 53, 39, 459054)
>>> t1.date.year
2011
>>> t1.date.month
5
>>> print Session.query(Test).filter(Test.date == datetime.datetime(2011, 5, 23, 18, 53, 39, 459054)).one()
<Test(1, 1, 2011-05-23 18:53:39.459054)>
>>> print Session.query(Test).filter(Test.date > datetime.date(2010, 1, 1)).all()
[<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:
>>> ...
>>> Session.query(Test).from_self().all()
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.


-- 
With best regards,
Daniel Kluev

[toc] | [prev] | [next] | [standalone]

#6050

Hi,

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

On Sun, May 22, 2011 at 7:44 AM, Octavian Rasnita <orasnita@gmail.com> wrote:
> 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.

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.



-- 
a lex 13 x
http://www.a13x.info

[toc] | [prev] | [next] | [standalone]

#6053

From: "Terry Reedy" <tjreedy@udel.edu>
> On 5/23/2011 1:31 AM, Octavian Rasnita wrote:
>
>
>> 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

[toc] | [prev] | [next] | [standalone]

#6054

From: "Chris Angelico" <rosuav@gmail.com>
> On Mon, May 23, 2011 at 3:31 PM, Octavian Rasnita <orasnita@gmail.com> 
> wrote:
>> From: "Dennis Lee Bieber" <wlfraed@ix.netcom.com>
>>>
>>> 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?
>
> 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

[toc] | [prev] | [next] | [standalone]

#6055

From: "Daniel Kluev" <dan.kluev@gmail.com>

> On Mon, May 23, 2011 at 5:06 PM, Octavian Rasnita <orasnita@gmail.com> 
> wrote:
>> 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?

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.

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

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.

>> 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:
>>>> t1.date.month
> 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?

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

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

[toc] | [prev] | [next] | [standalone]

#6056

On Mon, May 23, 2011 at 7:49 PM, Octavian Rasnita <orasnita@gmail.com> wrote:
> 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}


-- 
With best regards,
Daniel Kluev

[toc] | [prev] | [next] | [standalone]

#6058

On Mon, May 23, 2011 at 8:41 PM, Octavian Rasnita <orasnita@gmail.com> wrote:
> From: "Daniel Kluev" <dan.kluev@gmail.com>
> 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.

-- 
With best regards,
Daniel Kluev

[toc] | [prev] | [next] | [standalone]

#6066

From: "Daniel Kluev" <dan.kluev@gmail.com>
...
>> 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.


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.


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


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

[toc] | [prev] | [next] | [standalone]

#6068

On Mon, May 23, 2011 at 10:17 PM, Octavian Rasnita <orasnita@gmail.com> wrote:
> From: "Daniel Kluev" <dan.kluev@gmail.com>
> 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.


-- 
With best regards,
Daniel Kluev

[toc] | [prev] | [next] | [standalone]

#6082

On 5/23/2011 4:49 AM, Octavian Rasnita wrote:

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

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#6090

From: "Terry Reedy" <tjreedy@udel.edu>
> On 5/23/2011 4:49 AM, Octavian Rasnita wrote:
> 
>> 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.

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.


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


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

[toc] | [prev] | [next] | [standalone]

#6109

From: "Daniel Kluev" <dan.kluev@gmail.com>
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

[toc] | [prev] | [next] | [standalone]

#6113

"Octavian Rasnita" <orasnita@gmail.com> writes:

> From: "Daniel Kluev" <dan.kluev@gmail.com>
> 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;

-- 
John Bokma                                                               j3b

Blog: http://johnbokma.com/        Perl Consultancy: http://castleamber.com/
Perl for books:    http://johnbokma.com/perl/help-in-exchange-for-books.html

[toc] | [prev] | [next] | [standalone]

#6130

On Tue, 24 May 2011 00:17:55 -0500
John Bokma <john@castleamber.com> wrote:
> > $d = @a;
> 
> 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.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

[toc] | [prev] | [next] | [standalone]

#6159

"D'Arcy J.M. Cain" <darcy@druid.net> writes:

> On Tue, 24 May 2011 00:17:55 -0500
> John Bokma <john@castleamber.com> wrote:
>> > $d = @a;
>> 
>> 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.

To me as silly as all those people who give Python a wide berth because
of significant whitespace. I am glad that I am not so limited in that
respect. To me programming languages are like writing systems used by
humans; each has its short comings and each has its beauty.

-- 
John Bokma                                                               j3b

Blog: http://johnbokma.com/        Perl Consultancy: http://castleamber.com/
Perl for books:    http://johnbokma.com/perl/help-in-exchange-for-books.html

[toc] | [prev] | [next] | [standalone]

#6163

On Tue, 24 May 2011 11:52:39 -0500
John Bokma <john@castleamber.com> wrote:
> >> > $d = @a;
> >> 
> >> 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.
> 
> To me as silly as all those people who give Python a wide berth because
> of significant whitespace. I am glad that I am not so limited in that
> respect. To me programming languages are like writing systems used by
> humans; each has its short comings and each has its beauty.

My point was that even proponents of the language can make a
significant error based on the way the variable is named.  It's like
the old Fortran IV that I first learned where the name of the variable
determined whether it was an integer or a floating point.

One of my favorite quotes (not sure if it was about Perl or APL) is "I
refuse to use a programming language where the proponents of it stick
snippets under each other's nose and say 'I bet you can't guess what
this does.'"

When I first looked at Perl it looked like line noise.  When I first
looked at Python it looked like pseudo-code.

Look, I couldn't care less what other people use.  I just don't see any
reason for someone to come into a Python group and start proselytizing
about why their tool is better than ours any more than I would feel any
need to go to a Perl group and start trying to convert them.

Bottom line - they did a study once (sorry, can't point to it any more)
to determine the best tool for development.  Turns out that the most
productive tool was generally the one that the user believed was the
most productive.  In hindsight I think that that was rather obvious.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

[toc] | [prev] | [next] | [standalone]

#6166

"D'Arcy J.M. Cain" <darcy@druid.net> writes:

> On Tue, 24 May 2011 11:52:39 -0500
> John Bokma <john@castleamber.com> wrote:
>> >> > $d = @a;
>> >> 
>> >> 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.
>> 
>> To me as silly as all those people who give Python a wide berth because
>> of significant whitespace. I am glad that I am not so limited in that
>> respect. To me programming languages are like writing systems used by
>> humans; each has its short comings and each has its beauty.
>
> My point was that even proponents of the language can make a
> significant error based on the way the variable is named.

And someone can't misspell dict, for example? Are we now going to judge
a language on a typo someone just made?

> When I first looked at Perl it looked like line noise.  When I first
> looked at Python it looked like pseudo-code.

When people who are used to a latin alpabeth look at Devanagari they
probably see scratches make by chickens. I saw beauty (and still see
it). To someone fluent in Devanagari the latin alpabeth might look like
Perl ;-).

Anyway, I have been exposed to pseudo-code a lot before I picked up
Perl, and yet, Perl somehow stuck with me. I learned about Python a
little later (IIRC), and have tried to pick it up several times over the
years that followed. Last year I have been more serious about picking it
up; and I even did some paid for work in it. I /can/ program in Python,
I do /like/ Python, but somehow I like Perl more; even when I am fully
aware of its shortcommings each time I use it.

As for line noise: very often it turns out that people mean the regular
expressions by this. But a similar dialect is used by many other
programming languages that I know of. The difference is that Perl has
dedicated operators for it.

A Perl programmer will call this line noise:

double_word_re = re.compile(r"\b(?P<word>\w+)\s+(?P=word)(?!\w)",
                            re.IGNORECASE)
for match in double_word_re.finditer(text):
    print ("{0} is duplicated".format(match.group("word"))

(p500 of Programming in Python 3, 2nd edition, any typos by me).

> Look, I couldn't care less what other people use.

In that case you're an exception here. Or maybe the weekly Perl bashers
are way more vocal here and drown people like you out. One thing I hate
about comp.lang.perl.misc is the ivory tower attitude there. One thing I
hate about comp.lang.python is the weekly Perl bashing; to me it makes
those people look like extremists (Pythonistas, what's in a word), and
to be honest, it does affect how I view Python.

> I just don't see any reason for someone to come into a Python group
> and start proselytizing about why their tool is better than ours any
> more than I would feel any need to go to a Perl group and start trying
> to convert them.

Yet it seems to be accepted behavoir here to weekly bash Perl...

> Bottom line - they did a study once (sorry, can't point to it any more)
> to determine the best tool for development.  Turns out that the most
> productive tool was generally the one that the user believed was the
> most productive.  In hindsight I think that that was rather obvious.

Doesn't surprise me. I did switch to Emacs a few years back (used
Textpad for many years) but I don't think I now produce more code /
hour. But I am able to do some things way easier compared to using
Textpad, and that gives me pleasure.

-- 
John Bokma                                                               j3b

Blog: http://johnbokma.com/        Perl Consultancy: http://castleamber.com/
Perl for books:    http://johnbokma.com/perl/help-in-exchange-for-books.html

[toc] | [prev] | [next] | [standalone]

#6367

John Bokma wrote:

> A Perl programmer will call this line noise:
> 
> double_word_re = re.compile(r"\b(?P<word>\w+)\s+(?P=word)(?!\w)",
>                             re.IGNORECASE)
> for match in double_word_re.finditer(text):
>     print ("{0} is duplicated".format(match.group("word"))

Actually, Python programmers would tend to call the RE part
of that line noise, too.

It's for that reason that we tend to avoid using REs when
possible, reaching for them only as a tool of last resort.

-- 
Greg

[toc] | [prev] | [next] | [standalone]

#6373

On Fri, 27 May 2011 15:48:36 +1200, Gregory Ewing
<greg.ewing@canterbury.ac.nz> declaimed the following in
gmane.comp.python.general:

> 
> It's for that reason that we tend to avoid using REs when
> possible, reaching for them only as a tool of last resort.

	I STILL haven't reached for them... For my purposes, a 50 line
procedure is more legible and easier to modify.

	Uh... Well... Let me modify that -- I think I have few in Forte
Agent's filters...

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

Page 2 of 6 — ← Prev page 1 [2] 3 4 5 6  Next page →

Back to top | Article view | comp.lang.python

csiph-web