Re: Should user passwords be more strict?

Attached is a post that requires all passwords to be: 'correct horse battery staple' :) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit

Re: django test-runner annoyances

On Sep 14, 4:16 pm, Carl Meyer wrote: > > I'm generally in favor of updating Django's test runner to be more > consistent with what the rest of the Python testing world does. Being > able to reference test files, suites, and tests by > fully-qualified-dotted-path rather than

Re: CSRF protection and cookies

> The applications I have in mind (where the "subdomain can set cookies > for other subdomains" could hurt) use django.contrib.auth and thus > sessions as well. Thus, they already have to do a session lookup for the > auth check, haven't they? Could that be reused for the CSRF check? Yes.

Re: RFC: "universal" view decorators

On 15 September 2011 23:27, Donald Stufft wrote: > Gonna add this in here as well as ticket #14512 > I think using decorators to modify the way a CBV behaves is the wrong way to > go about it, my reasoning is: > 1) Decorators on functions make sense, since the only way to

Re: RFC: "universal" view decorators

2011/9/16 Łukasz Rekucki : > Hi, >> I believe, however, I've figured out a different technique to make >> this work: don't try to detect bound versus unbound methods, but >> instead look for the HttpRequest object. It'll either be args[0] if >> the view's a function, or args[1]

Re: RFC: "universal" view decorators

Hi, On 15 September 2011 22:44, Jacob Kaplan-Moss wrote: > > #14512 proposes a adding another view-decorator-factory for decorating > class-based views, which would turn the above into:: > >    @class_view_decorator(login_required) >    class MyView(View): >        ... > >

Re: RFC: "universal" view decorators

Gonna add this in here as well as ticket #14512 I think using decorators to modify the way a CBV behaves is the wrong way to go about it, my reasoning is: 1) Decorators on functions make sense, since the only way to modify a function is to wrap it, so decorators provide a shortcut to do so.

RFC: "universal" view decorators

Hi folks -- I'd like to convert all the view decorators built into Django to be "universal" -- so they'll work to decorate *any* view, whether a function, method, or class. I believe I've figured out a technique for this, but I'd like some feedback on the approach before I dive in too deep.

Re: Should I split ticket #16502 in three tickets or not?

Hello, Yes, I think ticket #16502 should focus on the problem of CreateView: why doesn't it have a default template and does it need one? The other issues you discovered while investigating that problem should go into separate tickets. Best regards, -- Aymeric Augustin. On 15 sept. 2011,

Re: CSRF protection and cookies

Paul, thanks for your reply! Comments inline: Paul McMillan writes: >> Would it not be possible to move the second instance of the nonce (that >> will be compared to the form field) from a cookie to a session variable >> (at least when a session is available)?  Would that

Re: Python 3 and you

I'm not going to rehash everything Vernon says below, but I will say that as someone who maintains a module which installs and runs on Python 2.4 - 3.2, Vernon's comments are spot on. We first started supporting Python 3.0 almost immediately after its release and we had a few misconceptions going

Re: django test-runner annoyances

Like Carl and Travis said, Django's test runner supports the notion that a Django app has all it's test cases collected in the `models` and `tests` module. Most of the time, If your app's `tests` module gets too crowded, fracturing the app into smaller apps works. However, if you have to go

Should I split ticket #16502 in three tickets or not?

There is a comment to ticket ticket #16502 from *ptone*. He recommends to create two new tickets, one for get_model patch and one for select_template patch. In my opinion separating

Re: Python 3 and you

> One assumption of the strategy I outlined was the fact that Django is > as close to 3.X as possible. Django 1.4 will require Python 2.5 or > higher, but I'm not sure how quick we can do the jump to 2.6, which > is recommended by the Python porting docs [1]. > Don't confuse "recommended" with

Re: class based views: object instead of dictionary as context?

On Sep 13, 2011, at 9:28 PM, Reinout van Rees wrote: On 13-09-11 20:33, Tobias McNulty wrote: I love it when problems solve themselves :-) That's a good point. Are there *any* methods in the CBVs that don't take arguments, that also modify data? The only one that I found in the list