Re: Small decision needed on #15025

If we can, I would be in favour of treating the old behaviour as a bug and not having to support it while it follows a deprecation path. However, either way, if the new behaviour stays (and I definitely think it should) I think we should update the docs to clarify that there was a change in

Re: Small decision needed on #15025

Hi Don, > Prior to r14992 (which is the fix for #7153), the way a callable > context variable was resolved depended on where it was in the lookup > chain. Sometimes it was invoked, other times it was treated as a > first-class function. r14992 changed that behavior so that the > callable is

Re: Small decision needed on #15025

I just discussed this with Don on IRC. An example of the use case described is at: http://djangosnippets.org/snippets/1016/ The fix for this use case is easy. Pass a list of `(button.func_name, button.short_description)` tuples as `buttons` in the context instead of passing a list of callables.

Re: Customizable Separator for slugify

I did actually just come up with two problems involved in having a customizable separator for slugify: 1) SlugField would also have to take a parameter to define the separator so that there wouldn't be inconsistencies in the output of SlugField and slugify. This seems like it would be a big

Re: Customizable Separator for slugify

Adding Yet Another Setting doesn't seem like much of a solution here. To the original poster's question I'd say that using anything but dashes for slugify would be very uncommon, but I don't see any reason why the slugify filter *couldn't* take an optional parameter to define what token should

Re: contrib 's FormWizard needs a lot of work

I would like to discuss my pull request comments with you Stephan, I don't consider writing anything before clarifying somethings I comment there. Thanks, regards Miguel Araujo @maraujop 2011/1/6 David Durham > On Thu, Jan 6, 2011 at 4:22 PM, Stephan Jäkel

Re: RFC #12823

Just wanted to bump on this issue. The join is indeed a bit weird to the human eye (extra related__pk__isnull = False added) but that's just eye candy. This is true of many queries generated by django anyway, all that matters for the time being is correctness. I would mark ready for checkin but I

Small decision needed on #15025

Hi django-devs, Prior to r14992 (which is the fix for #7153), the way a callable context variable was resolved depended on where it was in the lookup chain. Sometimes it was invoked, other times it was treated as a first-class function. r14992 changed that behavior so that the callable is

Re: Customizable Separator for slugify

It will be much more useful to have customizable slugify function et all, because django's builtin sligify does not support russian symbols. It would be nice to have optional 'SLUGIFY_FUNC' setting to override the default function. It'll allow me to use slugify from pyutils module, for example.