From: "Daniel Kluev" <dan.kl...@gmail.com>
On Sun, May 22, 2011 at 11:47 PM, Octavian Rasnita <orasn...@gmail.com>
wrote:
From: "Daniel Kluev" <dan.kl...@gmail.com>
I am talking about that flexibility which was criticized in the previous
messages telling that this flexibility allows any programmer to use his
own way.
Perl doesn't force anyone to indent the code, don't force the programmer
to define a hash element before using it, allow the programmer to
interpret the variables in strings directly. These things should be not
used always, but if in some cases if the programmer wants to use them, he
can use them with no problems. And this means flexibility.
This is syntax-level flexibility, which, IMHO, does not affect
'advanceness' of modules at all. At language level, python is far more
flexible than perl with its magic methods and hooks, allowing to
overload any underlying language principles and protocols.
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.
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.
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).
> 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.
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.
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.
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.
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.
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
--
http://mail.python.org/mailman/listinfo/python-list
