Unfortunately this would break in subtle in confusing ways in inheritance
scenarios.
Say you've defined the following Manager subclass prior to Django 1.6 and
we're only raising a warning on Manager.get_query_set calls.:
class ActiveManager(models.Manager):
def get_query_set(self, *args,
On Wed, Mar 6, 2013 at 12:21 PM, charettes wrote:
> The use of the metaclass make sure you're not shooting yourself in the foot
> all and all the metaclass subclassing trouble should only concern a minority
> of users who most probably know what they're doing.
Ah, OK, that's the missing part I wa
There's a good, although non-obvious, reason.
Without the metaclass, a method overridden in the subclass with the old name
would be silently skipped.
--
Aymeric.
Le 6 mars 2013 à 16:30, Jacob Kaplan-Moss a écrit :
> Hm.
>
> I'm +1 on cleaning up the names but do we *really* have to use
Hm.
I'm +1 on cleaning up the names but do we *really* have to use a
metaclass for this? Seems to me this is "gratuitous use of a
metaclass" territory, especially given the shenanigans you have to go
through with subclassing the metaclass.
I'd be a lot happier with this patch if it just did t
Since the consensus as shifted toward not making a break-everything 2.0 I'm
planning to normalize the queryset methods name early in the 1.6
development cycle to spot any breakages.
The affected classes are the following:
- *django.contrib.admin.options.BaseModelAdmin* (*queryset* ->
