As mentioned by others, wanting "best of breed" and stable are
somewhat mutually exclusive.
OTOH, my own web framework has been stable for nearly a year and a
half at the application level, and AFIK so has TurboGears 2.0, and TG
1.1 for even longer. (I still have applications in production running
various flavours of 1.x.)
I'm ignoring, for the most part, the dichotomy here. Stability (via
consistent API, documentation, backwards compatibility, etc.) is a
noble goal, and a fundamentally modular and well-thought-out
underlying design should accommodate that in -addition- to allowing
experimentation with more bleeding-edge features.
On 2011-01-20 05:50:55 -0800, Tamas Hegedus said:
> I do not think that "claiming" and "complaining" are the things to discuss. I
> think it should be evaluated what made other projects/frameworks popular and
> easy-to-use.
This is something I've been looking for for quite some time. ;) (And
is ever more important as I continue to refine PEP 444.)
My personal opinion is that a bigger (mega) project needs more rules
compared to a smaller sized project.
IMHO, everything, great and small, requires a clear structure,
organization, and workflow ("rules") in order to be useful,
maintainable, and enjoyable. This ranges from style guidelines (i.e.
PEP 8) through to consistent naming of API calls, even all the way up
to following standard programming idioms.
As an example, everyone expects a sprintf to be available in their
language of choice. Python's overloading of the modulus operation was
fairly creative, I thought. ;)
> I have not seen a "stable" python framework. Most likely since it is
> extremely easy to rewrite the code - since Python rocks :-)
TurboGears seems to be a vivid example of "rapid evolution".
Unfortunately, this means point releases (x.Y) have tended towards
breakage. OTOH, this also means that as the exact definition of "best
of breed" changes over time, TurboGears keeps up. (Reference: KID-
>Genshi->Mako->Jinja2->… and SQLObject->SQLAlchemy->…, etc.)
This form of [in]stability (specifically multiple regressions during
between beta releases of 2.1) is part of the reason I stopped using
TurboGears.
> I think the ultimate task should be to standardize. Not TG. But the
> components of a framework. OK, and also standards, how to glue the components
> together.
I fully agree. There should be, almost, micro-PEPs surrounding the
various components common to all frameworks: sessions, authentication,
authorization, transactional handling, etc. These should all be
written up with consistent APIs (for the most part as extensions to
WSGI itself), and contain the same separation of server
responsibilities and application responsibilities as WSGI has.
As an example, the method of session data handling that Beaker uses is
pretty much ideal; a dict-like object with a .save() method. If the
session could be made available via environ['ewsgi.session']
('enhanced' WSGI, eh? ;) that would greatly simplify portability
across solutions. You wouldn't need monolithic session handling
systems that combine every possible use case.
> Example #1 if CherryPy invent a new feature or makes an existing feature more
> stable then I would like replace Pylons with CherryPy by a changing one word
> in the TG configuration file.
In theory, you can do this at certain levels; you can grab the WSGI
application created within your code and use an HTTP server other than
Paste's (I use Flup FastCGI), you can roll your own templating, use
your own database setup/teardown code, etc. Unfortunately, for a
large number of fundamental code paths, you can not replace Pylons
completely.
> Example #2 in order to try different form solutions, I do not want to learn
> tosca and etc.
Unfortunately, Tosca /is/ a form solution. I have my own as a WIP.
Using basic HTML templates (in your engine of choice) and raw
FormEncode (or other validation solution) is another option. These
are not interchangeable in the same way as "basic" services.
> I think you have the respect to talk to other frameworks (widget, database,
> webserver) and guide the process of creating and implementing standards.
There is a general mailing list for the Python Web Special-Interest
Group (Web-SIG). Traffic there is sporadic at best, but this
certainly is something worthy of broader discussion.
> A standard may be enough: if somebody does not follow it, [it] will suck.
The wonderful thing about standards is that there's so many to choose
from. ;)
> However, interface objects could be easily implemented (python rocks :-)) -
> however, I think it would be significant overhead - could be turned off in a
> production system.
Interfaces aren't "Pythonic" in the same way that duck typing is.
Python has a philosophy that if it walks like a duck (stores data,
somehow, in a way that maps to dictionaries), and talks like a duck
(implements __getitem__, etc.), than it is a duck (it's a dict!), even
if it does not directly subclass dict.
This is important for standards as abstract standards should not
impose upstream requirements (e.g. the presence of an ISession
interface class) on software which utilizes the standard. This ideal
is one of the factors behind the adoption and proliferation of WSGI
middleware.
> I know, it would be a big pain for developers to rewrite their code according
> to a new standard. But this is the short term. On the long term it could be
> extremely beneficial.
+1
Now to cover some of the other discussion from this thread:
On 2011-01-21 13:03:22 -0800, Christoph Zwerschke said:
> Should we for the sake of stability and not creating confusion stick with TG2
> and forget about TG3?
Excellent rhetorical flair. :)
> But since the classic Pylons seems to be a dead end, we need to switch sooner
> or later anyway.
This is a fundamental problem of creating a megaframework based on
another underlying technology. While this is less of a problem for /
consumed/ components such as WebOb, WebError, etc. (as these can be
amalgamated into the megaframework if abandoned) it's a far more
substantial problem for the underlying technology to go away.
There was debate of absorbing Pylons into TurboGears in order to
provide ongoing support for 2.x users. I'm unsure if any "final
decision" was made on that, though.
On 2011-01-21 15:00:59 -0800, Alessandro Molina said:
> Nothing prevents the TG dev team to create a fork of pylons and maintain it
> for the sole purpose of being the TG foundation. It has been stated that the
> two projects will be maintained as siblings this should really not be
> necessary :)
I agree.
TurboGears (or equiv.) should be a layer on top of WSGI itself. That
solves minor portability issues (it's all WSGI in the end) and solves
the major "one package upstream" issue for long-term support. To
accomplish this, scrap TurboGears as the name and focus all efforts on
adding to Pyramid what makes TurboGears distinct. /That/ should be
TurboGears 3, and would combine the efforts of the developers as well
as the mind space of the target audience (other developers), in the
densest way possible. To summarize:
:: Drop the TurboGears name, with appropriate 302s scattered about.
:: Integrate completely into Pyramid, and make Pyramid = TurboGears 3.
In fact, why shouldn't the "TurboGears-ification" of Pyramid continue
to take place the way it has so far, with multiple small glue
packages? (Key word: small - 'simple' and 'complete' are other
possible adjectives for "good glue".)
"TurboGears" could fairly easily be a meta-package pulling in
appropriate external packages at that point. (And concentrating the
documentation / support of the diverse components to a singular team
more aware of the interrelationships between components?)
My 2¢.
— Alice.
--
You received this message because you are subscribed to the Google Groups
"TurboGears" 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/turbogears?hl=en.
