After talking with Ian Bicking a bit tonight, I'm finally fully sold
on retiring the one-letter variable names from Pylons. The most likely
replacement names:
c -> context
g -> ??? (as globals/global is already taken)
h -> GONE (import the modules you need, most ppl want similar
functions an
On Dec 18, 2007, at 12:12 AM, Ben Bangert wrote:
In controllers, I think we can do away with the 'from ... import *'.
While this works nicely for awhile, it almost always tends to leave
a bad taste on people's mouth. The default controller template could
instead come with the only necessary
On Dec 18, 2007 12:12 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> After talking with Ian Bicking a bit tonight, I'm finally fully sold
> on retiring the one-letter variable names from Pylons. The most likely
> replacement names:
> c -> context
> g -> ??? (as globals/global is already taken)
> h -
On Dec 18, 2007 12:26 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007, at 12:12 AM, Ben Bangert wrote:
> > In controllers, I think we can do away with the 'from ... import *'.
> > While this works nicely for awhile, it almost always tends to leave
> > a bad taste on people's mouth. Th
On Dec 18, 2007 12:26 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> I'm also looking at some of the locations for things, and since beaker
> handles its own stacked object proxy, I'm thinking it might be cleaner
> and less confusing if projects imported the session object from where
> the package t
s.
Cheers,
James
Original Message:
-
From: Ben Bangert [EMAIL PROTECTED]
Date: Tue, 18 Dec 2007 00:12:52 -0800
To: pylons-devel@googlegroups.com
Subject: Cleaning some house of imports and one letters
After talking with Ian Bicking a bit tonight, I'm finally fully sold
on r
On Tue, Dec 18, 2007 at 01:07:50AM -0800, Mike Orr wrote:
>
> On Dec 18, 2007 12:26 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> > I'm also looking at some of the locations for things, and since beaker
> > handles its own stacked object proxy, I'm thinking it might be cleaner
> > and less confusi
On Dec 18, 2007 1:40 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hi Ben,
>
> I wholeheartedly agree and I like the idea of explicit session imports from
> things like Beaker too so everything is explicit. The less work the user
> has to do to find out what is actually going on the better
Mike Orr wrote:
> On Dec 18, 2007 1:40 AM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Hi Ben,
>>
>> I wholeheartedly agree and I like the idea of explicit session imports from
>> things like Beaker too so everything is explicit. The less work the user
>> has to do to find out what is actually
Hi Mike,
Mike Orr wrote:
> Ugh, you really expect people to want to memorize this? Sessions are
> supposed to be built into megaframeworks, not require some obscure
> import. "I think I'll just use Rails instead; it's more
> straightforward."
The problem at the moment is worse, people start us
On Dec 18, 2007 3:12 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> After talking with Ian Bicking a bit tonight, I'm finally fully sold
> on retiring the one-letter variable names from Pylons. The most likely
> replacement names:
> c -> context
> g -> ??? (as globals/global is already taken)
> h ->
Ben Bangert wrote:
> After talking with Ian Bicking a bit tonight, I'm finally fully sold
> on retiring the one-letter variable names from Pylons. The most likely
> replacement names:
>
> c -> context
> g -> ??? (as globals/global is already taken)
Awesome. I am so glad you have seen the light
Mike Orr wrote:
>> When you want sessions, you'd add: from beaker.middleware import
>> beaker_session as session
>
> Ugh, you really expect people to want to memorize this? Sessions
> are supposed to be built into megaframeworks, not require some
> obscure import. "I think I'll just use Rails i
Ben Bangert wrote:
> On Dec 18, 2007, at 12:12 AM, Ben Bangert wrote:
>> In controllers, I think we can do away with the 'from ... import *'.
>> While this works nicely for awhile, it almost always tends to leave a
>> bad taste on people's mouth. The default controller template could
>> instead
Ben Bangert wrote:
> When you want sessions, you'd add:
> from beaker.middleware import beaker_session as session
After thinking about it overnight, I'm beginning to think this is the
least objectionable part of the whole proposal. Sessions are not
universally used, and having the word "beaker"
Mike Orr wrote:
> Ben Bangert wrote:
>> When you want sessions, you'd add:
>> from beaker.middleware import beaker_session as session
>
> After thinking about it overnight, I'm beginning to think this is the
> least objectionable part of the whole proposal. Sessions are not
> universally used, a
On Dec 18, 2007 11:33 AM, Ian Bicking <[EMAIL PROTECTED]> wrote:
> h.url_for always reads weird to me. url_for is a first-class function,
> why not just put it at the top level for templates? That said, I
> generally like h.
I've found this function very useful in templates, and would like to
s
Ian Bicking wrote:
>> There's a reason controllers have "from myapp.lib.base import *".
>> It's to ensure that every controller has a certain baseline of
>> objects
>> available. Better than importing 30 symbols into every controller
>> and
>> then you have to look at the import stanzas care
On Tue, 2007-18-12 at 07:41 -0500, Mark Ramm wrote:
> On Dec 18, 2007 3:12 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> > After talking with Ian Bicking a bit tonight, I'm finally fully sold
> > on retiring the one-letter variable names from Pylons. The most likely
> > replacement names:
> > c ->
On Tue, 2007-18-12 at 00:26 -0800, Ben Bangert wrote:
> On Dec 18, 2007, at 12:12 AM, Ben Bangert wrote:
> > In controllers, I think we can do away with the 'from ... import *'.
> > While this works nicely for awhile, it almost always tends to leave
> > a bad taste on people's mouth. The defau
Quoth Jonathan LaCour (2007-12-19 06:54):
> pylons.c -> pylons.request.state
> pylons.session -> pylons.request.session
> pylons.g -> pylons.request.app_globals
Excuse my ignorance, but why can't all these just be attributes of
the controller instance? An abstract base
On Dec 18, 2007 2:46 PM, avdd <[EMAIL PROTECTED]> wrote:
>
> Quoth Jonathan LaCour (2007-12-19 06:54):
> > pylons.c -> pylons.request.state
> > pylons.session -> pylons.request.session
> > pylons.g -> pylons.request.app_globals
>
> Excuse my ignorance, but why can't all
Mike Orr wrote:
>> g should be renamed persist. The interesting thing about g isn't that it is
>> global, rather that the variables attached to it persist across requests.
>
> The interesting thing about 'g' is, um... is there anything
> interesting about it?
> I've found two rare cases for it.
On Dec 18, 2007, at 1:07 AM, Mike Orr wrote:
Ugh, you really expect people to want to memorize this? Sessions are
supposed to be built into megaframeworks, not require some obscure
import. "I think I'll just use Rails instead; it's more
straightforward."
No, I expect someone using sessions t
On Dec 18, 2007, at 1:44 AM, Christoph Haas wrote:
+1 on that. Please provide the "session" by default. Pylons may be
re-using other components but IMHO that should be hidden from the
user.
Yea, the thing is, it isn't really re-using the other components, its
just putting their WSGI app in
On Dec 18, 2007 4:06 PM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> Pylons is not a megaframework, its the
> opposite, its a lightweight framework, that loosly couples some WSGI
> components into a WSGI stack and puts the stack under your control.
Well, it depends on your definition. I call it a m
On Dec 18, 2007 4:06 PM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> Consider how simple sessions and the WSGI layer can be explained:
>
> Beaker has middleware that sets up and handles sessions for you, by
> adding the SessionMiddleware to your stack, you can now use sessions
> in your controllers.
On Dec 18, 2007 3:21 PM, James Gardner <[EMAIL PROTECTED]> wrote:
> Personally I like it but in hindsight I
> think Global is misleading and persistent is a better description.
Well, its essential characteristic is being appinstance_local, it
sounds like. 'persistent' generally means "saved acros
> pylons.c -> pylons.request.state
> pylons.session -> pylons.request.session
> pylons.g -> pylons.request.app_globals
I don't think session belongs in request personally, isn't the whole
point of the session that it persists _across_ requests.
I think app_local is be
> h.url_for always reads weird to me. url_for is a first-class function,
> why not just put it at the top level for templates? That said, I
> generally like h.
TurboGears 1 had a registry of things that ought to be automatically
imported into the template namespace as top level variables.
And
> I think everything that is a SOP right now could hang off a single
> request SOP. I personally would prefer that; I think it makes all this
> stuff much more clear. It's easy to remember that the request object is
> per-request -- heck, it's obvious once you write it down.
I agree that it mak
On Dec 18, 2007 6:30 PM, Mark Ramm <[EMAIL PROTECTED]> wrote:
>
> > pylons.c -> pylons.request.state
> > pylons.session -> pylons.request.session
> > pylons.g -> pylons.request.app_globals
>
> I don't think session belongs in request personally, isn't the whole
> point o
On 12/18/07, Mike Orr <[EMAIL PROTECTED]> wrote:
>
> I've found two rare cases for it. One was for a reference object
> that's built on application startup, which I could just have easily
> put into a module global. The other was for the SQLAlchemy engine,
> which also worked better as a module g
On 12/18/07, Ben Bangert <[EMAIL PROTECTED]> wrote:
>
> After talking with Ian Bicking a bit tonight, I'm finally fully sold
> on retiring the one-letter variable names from Pylons. The most likely
> replacement names:
> c -> context
> g -> ??? (as globals/global is already taken)
> h -> GONE (impo
On 12/18/07, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
>
> I hadn't thought of any of this before, but I really like the concept.
> It seems to me that `context` is certainly better than `c` but you
> are right that it doesn't really convey the fact that its essentially
> request local state. My
On Dec 19, 2007 4:31 AM, Max Ischenko <[EMAIL PROTECTED]> wrote:
>
>
>
> On 12/18/07, Mike Orr <[EMAIL PROTECTED]> wrote:
> > I've found two rare cases for it. One was for a reference object
> > that's built on application startup, which I could just have easily
> > put into a module global. The
On Dec 19, 2007 4:58 AM, Max Ischenko <[EMAIL PROTECTED]> wrote:
>
>
>
> On 12/18/07, Jonathan LaCour <[EMAIL PROTECTED]> wrote:
> > I hadn't thought of any of this before, but I really like the concept.
> > It seems to me that `context` is certainly better than `c` but you
> > are right that it d
Mike Orr wrote:
> There are three arguments, not all made by the same people.
>
> 1) 1-letter variables are bad because they're not self-documenting.
> Ben and some others are pushing this,
>
> 2) "import *" is ugly, do anything to get rid of it. Ben has proposed
> reducing imports
> to the min
On Dec 19, 2007 8:37 AM, Ian Bicking <[EMAIL PROTECTED]> wrote:
> pylons.c is just a little odd -- if we could change the render function
> to just take substitution variables as keyword arguments then I
> personally would just stop using pylons.c, and probably be happier for
> it. Right now I g
Mike Orr wrote:
> On Dec 19, 2007 8:37 AM, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>> pylons.c is just a little odd -- if we could change the render function
>> to just take substitution variables as keyword arguments then I
>> personally would just stop using pylons.c, and probably be happier f
On Dec 19, 2007 9:10 AM, Ian Bicking <[EMAIL PROTECTED]> wrote:
>
>
> Mike Orr wrote:
> > On Dec 19, 2007 8:37 AM, Ian Bicking <[EMAIL PROTECTED]> wrote:
> >
> >> pylons.c is just a little odd -- if we could change the render function
> >> to just take substitution variables as keyword arguments t
On Dec 19, 2007, at 8:37 AM, Ian Bicking wrote:
My concern here has actually been the reactions I've gotten from
people
experienced with Python when they first look at Pylons. Several
different people have mentioned this -- not as a horrible thing, but
as
something that stuck out to them,
So, a few summaries of things I'm ready to decide on based on the
conversation so far.
pylons.g -> pylons.app_globals (it definitely needs to self-document
better)
The 'h' name is fine as is.
Instead of context, it'd be self-documenting if it was tmpl_context,
yes, I know, even longer. T
On Dec 18, 2007, at 1:44 AM, Christoph Haas wrote:
It's bad enough that I have to copy the "SQLAlchemy in a hurry"
article
for every project. I wouldn't mind if Pylons came with a tighter
integration of SQLAlchemy just like we had with pylons.database.
And be it that the "in a hurry" setup is
On Dec 19, 2007 11:49 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> On Dec 18, 2007, at 1:44 AM, Christoph Haas wrote:
>
> > It's bad enough that I have to copy the "SQLAlchemy in a hurry"
> > article
> > for every project. I wouldn't mind if Pylons came with a tighter
> > integration of SQLAlchemy
On Dec 19, 2007 10:53 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> On Dec 19, 2007, at 8:37 AM, Ian Bicking wrote:
> > pylons.c is just a little odd -- if we could change the render
> > function
> > to just take substitution variables as keyword arguments then I
> > personally would just stop usin
On Dec 19, 2007 11:21 AM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> from pylons import render, request, response, session
Is that a move of pylons.template.render ?
--
Mike Orr <[EMAIL PROTECTED]>
--~--~-~--~~~---~--~~
You received this message because you are s
On Dec 19, 2007, at 1:32 PM, Mike Orr wrote:
from pylons import render, request, response, session
Is that a move of pylons.template.render ?
Not intentionally, my bad:
from pylons.templating import render
Should be in there.
Cheers,
Ben
smime.p7s
Description: S/MIME cryptographic signatu
On Dec 19, 2007 1:29 PM, Mike Orr <[EMAIL PROTECTED]> wrote:
> > > Besides being hard to understand, they are a pain to debug. That's
> > > actually my concern with them. Oh, and they have weird performance
> > > characteristics that have frequently caught people.
> >
> > I don't see any way to
On Dec 19, 2007, at 1:11 PM, Mike Orr wrote:
That looks cool except I'd like the template to have
init_model(engine) rather than the pylons.g.engine.
I'm adding it right now with pylons.g.engine, we can take a look then
and review.
That makes it easier to import the model anytime, and to
Can somebody take a look at the blog tutorial and figure out why
url_for and redirect_to are returning None? I've asked before about
this but gotten no feedback.
http://wiki.pylonshq.com/display/pylonscookbook/Making+a+Pylons+Blog
--
Mike Orr <[EMAIL PROTECTED]>
--~--~-~--~~--
I just committed an update to pylons-dev that now includes an option
to toggle the inclusion of SQLAlchemy setup. Running paster create for
a new Pylons project will ask you whether to include sqlalchemy, along
with prompting if you want to change the template language. Choosing
genshi will
On Dec 19, 2007 4:26 PM, Ben Bangert <[EMAIL PROTECTED]> wrote:
> I just committed an update to pylons-dev that now includes an option
> to toggle the inclusion of SQLAlchemy setup. Running paster create for
> a new Pylons project will ask you whether to include sqlalchemy, along
> with prompting
Ben,
On 12/19/07, Ben Bangert <[EMAIL PROTECTED]> wrote:
>
>
> So for the new controller template:
>
> import pylons.tmpl_context as c
> from pylons import render, request, response, session
> # from pylons.controllers.util import abort, redirect_to, url_for
>
> from yourproj.lib.base import BaseC
54 matches
Mail list logo
