On Sun, Nov 7, 2010 at 9:28 AM, Ev Kontsevoy <[email protected]> wrote:
> Mike, my background is very heavy on Rails
That's wonderful, we need a Rails-experienced advisor in the
community. Ben has studied rails (and everything else, he's amazing),
but as I said I haven't looked at it directly. Ruby's syntax reminds
me unfavorably of Perl. So that's my bias. But there are ppl in my
local Python group who like Ruby, and they've shown me that it has
ingenious methods for looking and the like, so I know it's not all
bad. Here's what I know about Rails:
1) Pylons, TurboGears, and Django were all based on it conceptually.
I'm not sure how closely they followed the syntax.
2) Routes is modeled on Rails. Routes had two magical constructs,
minimization and implicit defaults, which sucked big time. Presumably
these came from Rails? The routes manual focused on "short URLs",
meaning maximum minimization. This led to the wrong routes
accidentally matching a URL (e.g., "/help/:action", where 'action' is
optional, so it matches "/help" even when another route below was
supposed to match it.) It was hard to predict exactly which URLs a
route would match, which made debugging difficult. This was deprecated
in 0.9.7 and removed in Pyramid, so now you have to explicitly list
all URL patterns with separate routes. This was one direction change
we had to force on the userbase, which is why some ppl have difficulty
upgrading their apps to 1.0
3) Routes also had a singleton to implement url_for(). Again I assume
this came from Rails. Singletons are arguably bad programming
practice, like SOPs and magic variables (threadlocal globals). It
makes the framework more complex, making users fear that it may one
day give the wrong answer in an unanticipated situation. For
developers, it's hard to guarantee logically that it will always be
correct. The worst problem is when somebody tries to use 'config' or
'app_globals' or 'url' outside of a request (especially in unit test
initialization), and they get the "No object has been registered for
this process or thread" error. Pylons has had to make workarounds for
these cases. Anyway, Pylons 1 uses a new Routes feature to bypass the
singleton, by creating a URL generator in the WSGI environment, which
then gets put on to ``pylons.url``. That's why users had to switch
from url_for() to url(), another Rails-inspired trauma.
4) map.connect() and url_for() were polymorphic. In map.connect, the
route path moved from the first arg to the second arg if a route name
preceded it. url_for() did route selection by variable matching, which
again is ambiguous and leads to the wrong route matching. url_for
sometimes had a positional arg for the route name, and sometimes not.
Sometimes it chose the route corresponding to the current URL, again
with an ambiguous syntax. The new URL generator (pylons.url) has a
separate method for the current route. Routes now encourages naming
all routes, and allows None in the map.connect(name) arg to explicitly
specify an unnamed route. Again, I assume all these ambiguities were
based on Rails precedents?
5) Paginate (webhelpers.paginate) used url_for() internally. This was
a mistake on our part, because WebHelpers was not supposed to depend
on Pylons or Routes, but a lot of url_for()'s snuck in to the rails
helpers and tests and Paginate, so it de facto did. So these all
depended on the singleton. We patched Paginate to work with
pylons.url, deprecated the rails helpers, and left Routes as a test
dependency rather than rewriting all the tests.
6) The rails helpers did literal string concatenation, embedding HTML
markup characters in the format string, with opening and closing
constructs spanning string literals or even code lines. The helper
args were overly string-based (unpythonic), and sometimes in reverse
order (select tag builder). Some helpers took args which it internally
passed to url_for() [meaning the args were ambiguous]. Again, I
suppose these were based closely on rails? We had to port a new tag
builder that treated attributes and children distinctly, and create a
new suite of pythonic helpers. The rails helpers also depended on two
Javascript libraries which were included (Prototype and
Scriptaculous). Over time these lagged behind other Javascript
libraries, and we had to update them from the Rails source whenever
the originals changed. That's why Javascript libraries were dropped
from WebHelpers.
7) Ruby gems are superior to Python eggs+PyPI. Ruby also has a
debugging feature Python lacks and can't adopt for
structural/philosophical reasons, (I saw a talk on this but don't
remember the details.)
8) Ruby borrowed the WSGI concept from Python due to widespread
dissatisfaction with Rails as "the only framework", and now has
several frameworks similar to the Python situation.
9) The Rails (or Ruby) community has a reputation for flamewars and
letting personal disputes interfere with development. An Rails
developer came to PyCon one year and participated in the WSGI sprint,
after leaving the Rails community due to flamewars. I and the main
WSGI developers I know (Ben, Ian, Steve Holden) have a personal
commitment to not be insulting or exclusive or let our communities be
so, and to keep all criticism at a practical, constructive level.
comp.lang.python used to be like that too, but has unfortunately
acquired its share of newbie-insulters ("RTFM, dammit! Quit bothering
us with simple questions.") [Of course, the questions are simple for
you because you know where to look in the docs or source, but newbies
don't, or they can't comprehend what is written.]
> With the release of Rails-3 it has fallen behind in terms of speed of
> development and ease of use. Pyramid is substantially lower level, and
> seems like its done on purpose because you're suggesting other
> frameworks to be built on top of it. But again, I wanted Pylons to
> follow Rails, i.e. be more opinionated, offer more powerful routes,
> require eve less code for typical CRUD, have powerful default RESTful
> routes and controller/view defaults, etc...
Again, please post a list of Rails-3 features that Pylons/Pyramid
lack, and we'll see what we can do about them. Maybe some of them can
go into Pyramid, and others can go into TurboGears or a new high-level
framework.
--
Mike Orr <[email protected]>
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
