Re: 1.1 feature: unify access to response.context in test client

2008-11-08 Thread oggie rob
> 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 -

Re: 1.1 feature: unify access to response.context in test client

2008-11-08 Thread James Bennett
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

Re: 1.1 feature: unify access to response.context in test client

2008-11-08 Thread Russell Keith-Magee
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 >

Re: 1.1 feature: unify access to response.context in test client

2008-11-08 Thread Russell Keith-Magee
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

Re: 1.1 feature: unify access to response.context in test client

2008-11-08 Thread Eric Holscher
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:

1.1 feature: unify access to response.context in test client

2008-11-08 Thread James Bennett
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

Re: Ticket 9483

2008-11-08 Thread varikin
> 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