[All Rails stuff moved to a separate thread.]
On Sun, Nov 7, 2010 at 9:28 AM, Ev Kontsevoy <[email protected]> wrote:
>> No previous framework has provided built-in primitives for all the
>> programming styles that have emerged among the various post-2005 frameworks
>> (traversal vs
>
> I understand. The issue is that soon we'll need a "Bible of Pyramid"
> to get started using it.
The Pyramid book already feels bible-like. I wish there was a manual
as extensive without the BFGisms which distract/confuse Pylons users,
but it's what we have. And it's much more extensive documentation than
Pylons ever had. It was going to be an immense project to integrate
all the dependency docs into the Pylons manual, but adopting BFG and
its book obviates the need for all that.
> I am
> just sad that this thing has eaten my favorite framework :))
Nice metaphor. But it's like Python 2 -> 3. If people are majorly
dissatisfied with Pyramid, they can continue using and helping to
develop Pylons 1. A separate "Pylons 2" is possible if somebody
outlines the goals for it and convinces the rest of us of the need for
it. Perhaps another team can take over Pylons development at that
point, the way Ian handed SQLObject maintenance to Oleg when he
switched to SQLAlchemy.
> 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...
After years of requests for alternate APIs by users, and a few users
subclassing PylonsApp, and our own discovered needs as we built apps,
we generally came to the conclusion that Pylons was a bit too rigid.
Just a bit, mind you. We can still keep the opinionated vision in the
docs, while providing more hooks in Pylons for alternatives. Pyramid
adds those hooks. Those mandatory dependencies (FormEncode,
WebHelpers) are a nuisance if you're not using them, and a practical
problem in space-challenged deployments (Google App Engine).
The framework you want can be built on top of Pyramid. Maybe
TurboGears 3 will be it , or maybe a new framework. If Pyramid has
inefficiencies (excess overhead), this may be a problem. But first we
have to identify what the overhead is and whether it actually exists.
Unused ZCML parsers and threadlocal modules are insignificant in this
regard. If they are always active and draining CPU cycles and
burgeoning call-stack levels, then we can address those problems
directly.
(Note: the BFG/Zope dependencies are of course numerous compared to
Pylons, and that will be an intrinsic issue for space-challenged
deployments. But most users are not running on platforms where it
matters. I also mentioned Pylons' unexpectedly-high memory usage, and
how it does best on 1 GB servers. I don't know how Pyramid compares in
this regard, whether it's more frugal or prodigal. That's another
issue to focus on someday.)
BTW, there is an ambiguity between Pyramid the meta-framework, and
Pyramid the top-level framework (Pylons style or BFG style). I wish
these had remained distinct in the branding, with the meta-framework
under one name and in a separate package, and the top-level framework
with its own name. But others felt differently about this, that
Pyramid should simultaneously be a complete Pylons-style framework,
and a meta-framework (like Paste). That it would be easier to market a
single framework than a dichotomy.
>> XML is a tool. It's ugly but it can do some things better than other
> tools.
>
> XML is a tool for data
> exchange between systems written by different vendors.
That is one of its unique strengths, that the widest variety of
programmers have XML experience and tools. Another is marked-up text.
There's XHTML, but YAML/HTML or JSON/HTML would be ridiculous and
unreadable. But XML has its downsides, which is why JSON and YAML have
become popular.
Re Python configuration format, I have worked with several frameworks
and programs that have a variety of configuration formats: Python,
INI, XML, CSV, etc. There are three general Python formats: simple
variable assignments in a module, nested dicts in a module, and
classes-attributes-subclasses in a module. All of these are limited in
different ways. The simple variable-assignment approach doesn't have
sections (unless you use a custom preprocessor), and it supports
nesting only in the sense that objects can contain objects, not at the
top level. The syntax can be overly verbose for a config file,
depending on the target data types. It presents a barrier if the app
maintainer is not familiar with Python syntax rules. (He may be a
generic sysadmin.)
The nested dict approach is rather ugly and has too many "{" and "}".
The first line is a single "{", which is rather useless for the human
maintainer.
The class-attribute-subclass approach is overly verbose due to the
"class" keyword. Some systems use a preprocessor to add it in, but
then you've strayed from the simple "execfile()" model.
Python format can be a security vulnerability if you don't trust the
user, because there is no effective way to ban imports or
introspection tricks in Python. The right attribute-subattribute
incantations can let you access everything. The user can also
accidentally cause the program to malfunction if he gets too elaborate
with imports and assignments, which is then a tech-support headache.
So Python format has its advantages and disadvantages, but it's not
always superior in every situation. There were debates in TurboGears
and Pylons and Pypes which format to use, and they went back and forth
several times before deciding to adopt the Paste INI format.
> Let me disagree. I simply observed the fact that dealing with forms
> has been the most popular topic to bitch about (in my opinion) on
> pylons-discuss, while nobody ever complained about magic globals or
> plugins.
People have complained about it all over the place, as they want to be
reassured their application won't blow up or misbehave in some edge
case. And the second-most popular bitch topic after forms is Auth
systems, the lack of it in Pylons, and the controversial AuthKit which
is recommended in the Pylons book.
> Also, just to make a dent, I want to vote *for* magic globals
> one more time! :)
Noted. But be aware that they will intentionally not be implemented in
Pyramid. You can mount a Pylons app in Pyramid that uses magic
globals, or wait for a higher-level framework that has them.
>> Routes already has this: ``map.resource("cars", "car")``. Ben is currently
>> adding all Routes features to Pyramid. He says that this gives the chance to
>> greatly simplify (shrink) the code, and to refactor its internal structure
>> based on the long-planned "Routes 2" branch. So there will probably be some
>> kind of ``config.add_resource_hander`` method for this.
>
> That's great news! Thanks.
I should have said, "paster restcontroller" is what gives you the
controller corresponding to a resource route. I don't think Pyramid
has this yet but it should. (At least, the pre-Pyramid code I tried
recently didn't have it.)
> Also, Mike, thanks for spending so much time answering my questions
> and addressing my frustrations. This wasn't the first time this group
> blows my mind with the quality of posts from regular contributors.
Thanks. :) As I said in the Rails thread, this is a personal goal of
mine, to keep the Pylons lists friendly and inclusive, and to not
shout at newbies when they don't RTFM or don't understand it.
--
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.
