> You try making an implementation of the actual English title casing
> rules, and let me know how that goes. :P
I would prefer not, though that sounds like a challenge:)
>
> str.title is a very simple title casing function, and there's a
> reason for that.
I completely understand.
I was
Note also, that sometimes the context that you are looking for isn't always
in [0]. I ran into this when I was writing testmaker, and had to hack around
it. Luckily all of my templates used inheritance, so I didn't get bitten by
the dictionary or list of dictionary part.
I did something like
On Sun, Nov 9, 2008 at 5:56 AM, James Bennett <[EMAIL PROTECTED]> wrote:
>
> For 1.1, could we look into unifying the interface to
> ``response.context`` to avoid this sort of problem? Unless I'm
> thinking about this the wrong way, it shouldn't be too hard to
> differentiate dictionary-style
On Sun, Nov 9, 2008 at 6:40 AM, Eric Holscher <[EMAIL PROTECTED]> wrote:
> For my pony request, it would be really nice to have a way to get "user
> defined" context. This being things that were passed from views, set in
> template tags, (and maybe other places?). That is what the above code is
>
> I'd prefer backwards compatibility. The way I'm envisioning it would
> complicate the code a bit, but I think preserving compatibility is
> worth it:
It would be nice to keep backwards compat, for the sole reason that
the quickest way to test your code against a django upgrade is to run
tests
On Sat, Nov 8, 2008 at 5:34 PM, Russell Keith-Magee
<[EMAIL PROTECTED]> wrote:
> However, to clarify - are you talking about a backwards incompatible
> change, or are you talking about putting a backwards compatible layer
> in place that tries to tell the difference between the two modes of
>
