On 14 January 2011 16:22, Marco Paolini wrote:
>
> then maybe a new special attribute like "dont_call_me" or
> "i_will_call_you_if_needed" (way more polite)
>
> could be handy in this situations? What do you think?
I think it's too much of a corner case to justify another check in lookup.
When I
bpeschier ha scritto:
what if you add an alters_data class attribute to your ModelForm subclass?
class MyForm(ModelForm):
alters_data = True
this way __call__ is not going to get called...
No, but it will be replaced with settings.TEMPLATE_STRING_IF_INVALID.
See:
http://code.djan
> what if you add an alters_data class attribute to your ModelForm subclass?
> class MyForm(ModelForm):
> alters_data = True
>
>
> this way __call__ is not going to get called...
No, but it will be replaced with settings.TEMPLATE_STRING_IF_INVALID.
See:
http://code.djangoproject.com/brows
bpeschier ha scritto:
I am agreeing with the changes as made in [14992] as they make things
more consistent. The snag I run into was a flexible filter for making
ModelForm-instances which took a form-class as an argument via a
Variable. Since classes are callable (their constructor), suddenly I
h
I am agreeing with the changes as made in [14992] as they make things
more consistent. The snag I run into was a flexible filter for making
ModelForm-instances which took a form-class as an argument via a
Variable. Since classes are callable (their constructor), suddenly I
had a bunch of instances
On Jan 13, 7:05 am, Luke Plant wrote:
>
> In conclusion, I'm going to leave [14992] in. Due to the backwards
> incompatibility discovered, it's not a good idea to backport to 1.2.X.
> But since it is cleaning up an inconsistency/ambiguity, I'm happy to
> leave it in, and say that code that was r
On Thu, 2011-01-13 at 01:37 +0100, Marco Paolini wrote:
> +1 for [14992] and the proposed documentation change
>
> the guys that don't want the dict-item-funcion to be called, could set
> the alters_data attribute, no?
In this case, they will just get settings.TEMPLATE_STRING_IF_INVALID,
not an
Don Spaulding ha scritto:
On Jan 12, 4:23 pm, Tai Lee wrote:
On Jan 13, 5:06 am, Don Spaulding wrote:
I will say that the debug template has been
"relying on the bug" since 2005. By my estimation, that makes nearly
every template ever created a candidate for relying on the old
beh
Bah. Premature send. That was supposed to say:
On Jan 12, 6:08 pm, Don Spaulding wrote:
> On Jan 12, 4:23 pm, Tai Lee wrote:
> > On Jan 13, 5:06 am, Don Spaulding wrote:
>
> > This feels too magical to me, and it still leaves the possibility for
> > ambiguous behaviour as you note. Without kn
On Jan 12, 4:23 pm, Tai Lee wrote:
> On Jan 13, 5:06 am, Don Spaulding wrote:
>
>
>
> > I will say that the debug template has been
> > "relying on the bug" since 2005. By my estimation, that makes nearly
> > every template ever created a candidate for relying on the old
> > behavior.
>
> Not
On Wed, 2011-01-12 at 10:06 -0800, Don Spaulding wrote:
> The use case Tai linked was the first (and really, only) bug I ran
> into when porting to SVN trunk. I understand the "usable for
> designers" mantra, and I don't pretend that 'mycallable.func_name' is
> elegant, but frankly, I don't care.
On Jan 13, 5:06 am, Don Spaulding wrote:
>
> I can't speak to the number of templates actually in the wild that
> rely on the old behavior. I will say that the debug template has been
> "relying on the bug" since 2005. By my estimation, that makes nearly
> every template ever created a candida
On Jan 11, 8:31 pm, Luke Plant wrote:
>
> So we then have to think about what is sensible behaviour, and I think
> the new behaviour is much simpler and saner, and much more consistent
> with itself.
I agree.
> Also, given the nature of the Django's template system
> (i.e. usable for designers
On Tue, 2011-01-11 at 20:19 -0800, Tai Lee wrote:
> 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
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 behavi
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 alwa
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. B
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 always
18 matches
Mail list logo
