> 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 just
The Django test client exposes the Context used to render the returned
response, so that unit tests can inspect that Context and verify that
it contained what it was expected to contain. This is all well and
good, except that there is no consistent way to write tests which do
this.
When an inheri
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 this:
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 acce
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
> acce
