iain duncan wrote:
>> Please no. Bringing those variables into the tg namespace is a lot
>> more convenient, and brings us much easier to understand variable
>> names. The barrier here is simply documentation, in my opinion.
>
> In the case of tg, that is a very big and very easy to underestimate
> barrier. And what about the users we want to have come *from* pylons?
> Imagine being one of them for a moment, what is your reaction going to
> be to a layer that is supposed to provide sane defaults but renames a
> lot of stuff you already know how to use? I don't think it will be a
> good one and I think that is a very important potential user base.
Those people can continue to use `pylons.c` with no ill effects.
> Plus Mike Orr and James Garder have been doing a lot of good docs, we
> should leverage those.
If someone reads in the Pylons docs that they can use `pylons.c` and do
this in TurboGears 2.0, it'll work just fine. If they prefer to import
`context` from `tg` it'll also work just fine, and the TurboGears 2.0
documentation can clearly state:
For your convenience, we have aliased pylons.c, pylons.g,
pylons.request, and pylons.session to tg.context, tg.globals,
tg.request, and tg.session.
We can have nice, easy to understand names, *and* leverage the Pylons
documentation without any problems, IMO. I personally have always found
the single character global names in Pylons to be a terrible wart, and
we have an opportunity to fix it here, so I say "lets do it!"
--
Jonathan LaCour
http://cleverdevil.org
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" 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-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
