Re: reconsider re-opening ticket 901

[Russell Keith-Magee]

On Sun, May 12, 2013 at 9:36 AM, Anssi Kääriäinen
wrote:

> On 12 touko, 02:55, Russell Keith-Magee 
> wrote:
> > To that end - I want to make sure that we're clear about what we're
> talking
> > about here.
> >
> > What is on the table is essentially adding a refresh() call on an object
> > instance that is an API analog of ".get(id=self.id)" (although the
> > implementation will need to do a bit more than that).
>
> Concrete API proposal: Model.refresh() reloads all non-deferred local
> field values (that is, all fields in the current model which have a
> database column). In addition refresh() will make sure that cached
> values dependent of the reloaded values will be cleared. That is, if
> you do foo.refresh(), then when foo.user_id is reloaded foo.user will
> be cleared (assuming the reloaded user_id is different from the
> original value). This is to ensure that next access to foo.user will
> reload the related object, too.
>
> The refresh() method makes sure descriptors are honored, for example
> custom field's to_python() method will be called for refreshed values.
>
> The refresh() method accepts *args, so that one can specify which
> fields to reload. This is useful so that deferred attribute loading
> can use refresh(), and by overriding refresh() it will be possible to
> customize how deferred loading happens.
>
> Deferred field loading is altered to use .refresh().
>
> It might be useful to add model.deferred_fields property. The property
> returns a set of currently deferred fields in the instance. If this
> was available it would be easy to force reload of all currently
> deferred fields, but no reload of other fields. This would also be
> useful for loading all deferred fields when any deferred field is
> accessed. But this can wait for later...
>
> Does the proposal look acceptable?


+1 from me.

The use case for .refresh(*args) being used to pull back multiple deferred
fields is the real deal-maker for me, because it dovetails really nicely
with something Adrian posted about a month ago:

https://groups.google.com/d/msg/django-developers/C3qoHEfeeUg/cwBNV5snQPMJ

It seems to me that ".refresh()" is remarkably close to the "get everything
that was deferred" behaviour that Adrian was looking to add. The fact that
it can also be used to update an instance to the current database state is
a nice side effect in this case.

Russ %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Russell Keith-Magee]

On Sun, May 12, 2013 at 9:02 AM, Alex Ogier  wrote:

> On Sat, May 11, 2013 at 7:55 PM, Russell Keith-Magee <
> russ...@keith-magee.com> wrote:
>
>> I'm sure I understand this argument. Python objects are passed around by
>> reference, not by value, so if you've passed in a Django object deep into
>> another library, that library will be pointing at the same instance. If the
>> instance is changed, everywhere holding a handle to that reference will be
>> updated.
>>
>
> Yes, but that is not what foo = MyObj.objects.get(id=foo.id) does. That
> assigns a new reference to a new object to the name foo. Other references,
> even references to the same instance as foo, are not refreshed. This is
> precisely why a .reload() method is useful -- what is wanted is to mutate
> the instance that is referred to, not to create a new reference and assign
> it to the old name.
>

Understood - I was just using ".get(id=self.id)" as a shorthand for what
the underlying method will effectively be doing. I know the implementation
will be a bit more subtle than that.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Russell Keith-Magee]

On Mon, May 13, 2013 at 2:03 AM, Jason Reethisma wrote:

> @Russell
>
> "can't compel anyone to do anything"... you can compel people to NOT do
> something, such as, "don't close a ticket as won't-fix without giving a
> detailed explanation of why it should be closed".
>
> Saying that people cannot be compelled is an excuse to not take action.
>

My apologies if I wasn't clear - that wasn't what I was saying at all. What
I meant is that we can't institute a process like "Every core developer
must spend 4 hours per week triaging tickets or they will lose their core
developer status". This would be a completely reasonable course of action
if you were a paid employee -- your employer is just telling you what you
have to do to get paid -- but that dynamic doesn't exist in a volunteer
project. In a volunteer project the only reason the "hard" stuff gets done
is because people volunteer to do it.

However, in this case, Jacob *did* give a detailed explanation:

"This seems like a needless function; it's already possible to just
re-look-up the object from the database."

It was rejected because the need wasn't clear. Simon then reopened the
ticket, and gave a detailed use case, to which Jacob responded:

"I'm really not convinced by Simon's use case -- adding "reload()" only
saves you a single line of code. Let's do our best to keep Django as svelte
as possible."

What more detail should Jacob have provided? The feature isn't that
complex. It's not like he's got an opportunity to present a PhD thesis in
relational algebra. It's a simple feature, which has been rejected because
in Jacob's opinion, it can be achieved in other ways.

Jacob didn't explicitly call for a discussion on the mailing list. Perhaps
he should have. However, when the ticket was reopened for the second time,
James Bennett (ubernostrum) pointed at project policy to have these
discussions on the mailing list.

What should James have done instead?

Ignoring the 3 outlined problems in the post you replied to while
> pretending to ask for suggestions from the community is just a form of
> equivocation. Politicians do it all the time...


Sure, but Wim highlighted problems - he didn't suggest solutions.

I agree that in this example, and in some others, the three problems
described by Wim exist.

The core team has implemented a process that we think works. It has changed
over time, and is something that we feel is practical to implement, and
achieves the goals we're aiming to achieve. However, it's clearly failing
in some respects. We need the community to guides us on the *concrete*
improvements we can make.

This isn't political equivocating. Its a genuine call to the community to
tell us how we can make things better.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Triaging: Close as needsinfo

[Carl Meyer]

On 05/11/2013 06:01 PM, Shai Berger wrote:
> On Sunday 12 May 2013, Łukasz Rekucki wrote:
>> Hi,
>>
>> On 11 May 2013 22:58, Shai Berger  wrote:
>>> In
>>> other communities, I have usually seen "needsinfo" as a ticket state,
>>> rather
>>> than a reason for closing; such tickets are then closed later, if enough
>>> time
>>> has passed and no further info is received.
>>
>> To me that's just giving false hope for people viewing that ticket. If the
>> ticket is open, there's a reasonable expectation that there is some action
>> you can take to make it progress, but you most likely you can't as only the
>> reporter has the needed info. 
> 
> I disagree; every person who encounters a problem consistent with the 
> existing 
> description, can provide more info. This is, IMO, the only real (rather than 
> perceived) difference between closing as "needsinfo" and keeping the ticket 
> in 
> some sort of open limbo -- if someone else runs into the same problem, I'd 
> rather they enhance an existing report than start a new one; and nobody looks 
> at closed tickets.

It seems this is the only argument for not having "needsinfo" as a
closed state, and it rests on a premise ("nobody looks at closed
tickets") that is contradicted by the significant activity we regularly
see on closed tickets. Most people find tickets via Google or links on
e.g. Stack Overflow, and these do not discriminate between closed and
open tickets. I also have not observed a pattern of needsinfo tickets
collecting more dupes than any other type of ticket.

>> Of course, there are people who will take everything personal. Even if it's
>> getting your ticket closed by a stranger on a public bug tracker.
> 
> When people have already taken the trouble to file a ticket, if it is closed 
> and the closure seems arbitrary and off-handed, they will be offended. I 
> would 
> be. Then again, I would actually read the comments on the ticket...

In every case where I've seen a ticket closed as needsinfo, it came with
an explicit "please reopen if you can provide more info." This seems
good enough to me; I haven't observed a problem of people responding
poorly to a "needsinfo" closing (the issues are always around "wontfix"
closings). Making the change you are suggesting means introducing a new
tracker-gardening task, "closing old needsinfo tickets." Needsinfo was
added as a "closed" state precisely in order to get rid of the need for
this.

(And FWIW, community triagers like yourself should feel entirely free to
close tickets needsinfo. I think the only reason that isn't clearer in
the contributing guide is that the needsinfo status was added relatively
recently.)

Carl



signature.asc
Description: OpenPGP digital signature

Re: Perception of attitude in tickets

[Nick Phillips]

On Sun, 2013-05-12 at 11:03 -0700, Jason Reethisma wrote: 
> @Russell
> 
> "can't compel anyone to do anything"... you can compel people to NOT do 
> something, such as, "don't close a ticket as won't-fix without giving a 
> detailed explanation of why it should be closed". 
> 
> Saying that people cannot be compelled is an excuse to not take action.
> 
> Ignoring the 3 outlined problems in the post you replied to while pretending 
> to ask for suggestions from the community is just a form of equivocation. 
> Politicians do it all the time...
> 

As someone who uses Django, and lurks (mostly) on this list, I have to
say that I think you have got completely the wrong end of the stick.

The tone of your mail is not constructive, and is provoking a negative
reaction even in me (and I am not one who has been putting massive
amounts of time into building Django, keeping the tracker in order, and
trying to keep the community running smoothly). I don't want to think
about how such posts must make the likes of Russell, Jacob & co react -
I can only say that in the years I've been here they've done a superb
job keeping the frustration in check.

This community, to me, is notable for the professional and courteous
manner in which people making demands are directed toward what they need
to do to have a chance of getting what they want. I'm not saying it's
perfect, but it deserves rather more credit than you appear to be
giving.

If there is little to no chance that a particular feature will be
implemented, it seems to me that is better for all concerned to close
down the discussion fairly sharplish - the submitter then doesn't waste
time thinking they're going to get something done about it, and the
developers don't waste time explaining again and again and again why the
submitter's latest rehash of the same argument is not going to make any
difference (submitter wrong, bad fit for Django, philosophical issues,
whatever - some people just don't seem to get the message).

I suggest you take Russell's post at face value, by the way. "Looking
for a positive outcome".

Well, perhaps face value plus a head of frustration that he's hiding
fairly well.

Thanks again to all of you who are making it happen.


Cheers,


Nick
-- 
Nick Phillips / nick.phill...@otago.ac.nz / 03 479 4195
# These statements are mine, not those of the University of Otago

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Luke Sneeringer]

In MyModelB, at least, the subclass' refresh method would win, since it's the 
subclass.

I'm not sure about MyModelA, since I am not quite sure how the metaclass' 
processing would intersect.

That said, if there's demand for the feature, it's probably worth this cost. 
(Bias: I would use it if it existed, although my use case differs from the 
discussion here.)

Sent from my iPad

On May 12, 2013, at 2:13 PM, Tim Chase  wrote:

> On 2013-05-11 18:36, Anssi Kääriäinen wrote:
>> On 12 touko, 02:55, Russell Keith-Magee 
>>> What is on the table is essentially adding a refresh() call on an
>>> object instance that is an API analog of
>>> ".get(id=self.id)"
> 
> I guess my minor quibble is about the name itself and possible
> clashes with existing fields/methods:
> 
>  class MyModelA(Model):
># ...
>refresh = BooleanField(...)
># ...
>  class MyModelB(Model):
># ...
>def refresh(...): do_something_refreshing()
># ...
> 
>  a = MyModelA.objects.get(pk=some_id)
>  b = MyModelB.objects.get(pk=other_id)
>  # ...
>  if a.refresh: # legacy code expects a BooleanField
># whoops, what happens here under this proposal?
>  if b.refresh(): # legacy code expects local logic, not Django logic
># or what gets called here?
> 
> I wouldn't want to see any breakage when upgrading between versions.
> I don't have a good proposal, other than perhaps _refresh() or
> __refresh__(), or cramming it into Meta (I don't know if that would
> even work).
> 
> -tkc
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Django developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to django-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-developers?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Tim Chase]

On 2013-05-11 18:36, Anssi Kääriäinen wrote:
> On 12 touko, 02:55, Russell Keith-Magee 
> > What is on the table is essentially adding a refresh() call on an
> > object instance that is an API analog of
> > ".get(id=self.id)"

I guess my minor quibble is about the name itself and possible
clashes with existing fields/methods:

  class MyModelA(Model):
# ...
refresh = BooleanField(...)
# ...
  class MyModelB(Model):
# ...
def refresh(...): do_something_refreshing()
# ...

  a = MyModelA.objects.get(pk=some_id)
  b = MyModelB.objects.get(pk=other_id)
  # ...
  if a.refresh: # legacy code expects a BooleanField
# whoops, what happens here under this proposal?
  if b.refresh(): # legacy code expects local logic, not Django logic
# or what gets called here?

I wouldn't want to see any breakage when upgrading between versions.
I don't have a good proposal, other than perhaps _refresh() or
__refresh__(), or cramming it into Meta (I don't know if that would
even work).

-tkc



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Jacob Kaplan-Moss]

On Sat, May 11, 2013 at 6:36 PM, Anssi Kääriäinen
 wrote:
> Does the proposal look acceptable?

Yes. +1 from me.

Jacob

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Perception of attitude in tickets

[Jason Reethisma]

@Russell

"can't compel anyone to do anything"... you can compel people to NOT do 
something, such as, "don't close a ticket as won't-fix without giving a 
detailed explanation of why it should be closed". 

Saying that people cannot be compelled is an excuse to not take action.

Ignoring the 3 outlined problems in the post you replied to while pretending to 
ask for suggestions from the community is just a form of equivocation. 
Politicians do it all the time...

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Anssi Kääriäinen]

On 12 touko, 19:15, Aymeric Augustin
 wrote:
> > The refresh() method accepts *args, so that one can specify which
> > fields to reload. This is useful so that deferred attribute loading
> > can use refresh(), and by overriding refresh() it will be possible to
> > customize how deferred loading happens.
>
> > Deferred field loading is altered to use .refresh().
>
> I'm not totally following you here. I suppose it would make sense if I were
> more familiar with the implementation.

The deferred attribute implementation is as follows: all deferred
attributes have a DeferredAttribute descriptor (found from
models.query_utils IIRC), so on access of foo.somefield the
descriptor's __get__() is called. The __get__() checks if the value is
already found from the instance, if not it ends up fetching the value
from DB. The fetching of the value is equivalent to refresh() of
somefield (but of course not equivalent to full refresh).

So, if you override refresh() to do this:

def refresh(self, *fields):
 if set(fields).intersects(self.deferred_fields):
 fields.extend(self.deferred_fields)
 super().refresh(*fields)

Now, any time any deferred field is accessed (or refreshed manually),
then all of the deferred attributes are loaded in one go. This will
give a solution to Adrian's request of loading all deferred fields in
one go when one is accessed. Granted, there is no declarative way to
do this, nor is there per-queryset API. I think that cases where there
is need to customize deferred attribute loading are rare, so there is
no need for dedicated API.

In addition the DeferredAttribute implementation will be a little more
DRY.

 - Anssi

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Shai Berger]

On Sunday 12 May 2013, Aymeric Augustin wrote:
> On 12 mai 2013, at 10:24, Shai Berger  wrote:
> > Relatedly, we now cache back-references of 1-to-1 relations on the
> > instance
> 
> Django has cached them for a long time. It's just a bit more efficient and
> deterministic as of Django 1.5. :)
> 
> > those should probably be updated (on remote objects!) too, or else some
> > serious inconsistencies may be created (when the _id field changes, that
> > is).
> 
> Let's say model A has a one-to-one relation to model B — ie. a has a b_id.
> The reverse relation is b.a, and you're discussing b.refresh().
> 

No, I mean:

aa= A.objects.get(...)
bb= aa.b
(some other operation, changing aa.b_id in the database)
aa.refresh()

Now -- unless we do something about it -- bb.a is still aa, but aa.b is not bb 
and not even equal to it; thus, "bb.a.b == bb" is false, which currently 
cannot happen without serious meddling if I'm not mistaken.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Aymeric Augustin]

On 12 mai 2013, at 10:24, Shai Berger  wrote:

> Relatedly, we now cache back-references of 1-to-1 relations on the instance

Django has cached them for a long time. It's just a bit more efficient and
deterministic as of Django 1.5. :)

> those should probably be updated (on remote objects!) too, or else some 
> serious inconsistencies may be created (when the _id field changes, that is).

Let's say model A has a one-to-one relation to model B — ie. a has a b_id.
The reverse relation is b.a, and you're discussing b.refresh().

Since b will be refreshed in-place, a.b will point to an updated instance of
b, without any special handling.

For consistency, the cached value of b.a could be cleared as well. However, it
doesn't really depend on b itself. It only depends on the PK, and PKs are
immutable (changing the PK makes a copy). If it turns out to be easier not to
clear that value, I'll happily leave this decision to the person who
implements the patch!

-- 
Aymeric.



-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Aymeric Augustin]

On 12 mai 2013, at 03:36, Anssi Kääriäinen  wrote:

> Concrete API proposal: Model.refresh() reloads all non-deferred local
> field values (that is, all fields in the current model which have a
> database column). In addition refresh() will make sure that cached
> values dependent of the reloaded values will be cleared. That is, if
> you do foo.refresh(), then when foo.user_id is reloaded foo.user will
> be cleared (assuming the reloaded user_id is different from the
> original value). This is to ensure that next access to foo.user will
> reload the related object, too.
> 
> The refresh() method makes sure descriptors are honored, for example
> custom field's to_python() method will be called for refreshed values.

That sounds good to me.

> The refresh() method accepts *args, so that one can specify which
> fields to reload. This is useful so that deferred attribute loading
> can use refresh(), and by overriding refresh() it will be possible to
> customize how deferred loading happens.
> 
> Deferred field loading is altered to use .refresh().

I'm not totally following you here. I suppose it would make sense if I were
more familiar with the implementation.

> It might be useful to add model.deferred_fields property. The property
> returns a set of currently deferred fields in the instance. If this
> was available it would be easy to force reload of all currently
> deferred fields, but no reload of other fields. This would also be
> useful for loading all deferred fields when any deferred field is
> accessed. But this can wait for later…

Yes, that would be an internal API anyway.

> Does the proposal look acceptable?

Yes.

My only objection to this ticket was the lack of a concrete proposal!

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: reconsider re-opening ticket 901

[Shai Berger]

Hi,

There's one minor issue that I'm not entirely clear of with this proposal:

On Sunday 12 May 2013, Anssi Kääriäinen wrote:
> 
> Concrete API proposal: Model.refresh() reloads all non-deferred local
> field values (that is, all fields in the current model which have a
> database column). In addition refresh() will make sure that cached
> values dependent of the reloaded values will be cleared. That is, if
> you do foo.refresh(), then when foo.user_id is reloaded foo.user will
> be cleared (assuming the reloaded user_id is different from the
> original value). This is to ensure that next access to foo.user will
> reload the related object, too.
> 

The limitation (assuming the reloaded user_id is different from the
original value) does make sense; removing it also makes sense -- then, after 
foo.refresh(), foo.user will always get the updated user  object (and always 
incur a database hit).

Relatedly, we now cache back-references of 1-to-1 relations on the instance; 
those should probably be updated (on remote objects!) too, or else some 
serious inconsistencies may be created (when the _id field changes, that is).

Other than that, +1.

Shai.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: Proposal for simplifying part of the GCBV API slightly.

[Tom Christie]

Right now that ticket's just got a cautious +0 against it.
I still think this would be a small step in the right direction of 
presenting a slightly simpler GCBV API, but unless there's any further 
support I'm inclined to give the ticket a few more days and then close it.

On Thursday, 2 May 2013 08:58:56 UTC+1, Tom Christie wrote:
>
> I've created ticket #20432  for 
> this proposal.
> I don't know if it needs to go to 'design decision needed', but if it gets 
> approved I'll plan to work on it at the DjangoCon sprints, aiming for the 
> 1.6 alpha.
>
>   Tom
>
> On Monday, 22 April 2013 14:40:09 UTC+1, Andrew Ingram wrote:
>>
>> The original use case for pk_url_kwarg and slug_url_kwargs was something 
>> like this:
>>
>> /(?P[\w-]*)/ - DetailView
>> /(?P[\w-]*)/another-resource/ - Scoped ListView
>> /(?P[\w-]*)/another-resource/(?P[\w-]*) - Scoped 
>> DetailView
>>
>> In this case, the Scoped ListView and Scoped DetailView would both 
>> inherit a mixin that overrides get_queryset(), and the Scope DetailView 
>> would just set "slug_url_kwargs = 'another_slug'"
>>
>> I've used some variant of this pattern on almost every project I've been 
>> involved with that utilises class-based views, including some frameworks, 
>> so I don't think this edge case is quite as edgy as it might seem at first.
>>
>> However, I do agree that your simplification is an improvement. I've done 
>> a lot with CBVs since I first suggested the URL kwarg overrides, and I 
>> think it's better to have less configurable fields and focus instead on 
>> having good entry points into customising the classes through method 
>> overrides.
>>
>>
>> Andy
>>
>>
>>
>> On 22 April 2013 13:33, Tom Christie  wrote:
>>
>>> Hi Calvin,
>>>
>>> I can think of a few reasons.
 - you've changed models or fields internally through migrations, but 
 need to continue supporting old URLs.
 - you don't like the internal name to be exposed
 - you have different models but want to expose a consistent URL pattern.
>>>
>>>
>>> Those attributes control the URL kwargs that are used in the regex, 
>>> we're not talking about URL query parameters or anything else that's 
>>> visible to the end-user.  Internal names aren't being exposed anywhere, and 
>>> there'd be no issue with updating field names and continuing to support the 
>>> URLs that reference them.
>>>
>>> Having said that, you're probably correct that I've overstated point (1) 
>>> - There might be some circumstances where the developer would prefer to use 
>>> 'slug' as the regex kwarg, but look up against a differently named model 
>>> field.  I'd still think that there's a very strong argument to be made that 
>>> we could consider that a corner case that requires overriding `get_object`, 
>>> in exchange for having a simpler API for the standard case.
>>>
>>> There would of course be other alternatives such as using both 
>>> `lookup_field` and `lookup_kwarg` with the later defaulting to the same as 
>>> the former if unset, but I'm not wild about something like that given that 
>>> the intention of this proposal is to try to slightly slim down an aspect of 
>>> the API.
>>>
>>>
>>> On Monday, 22 April 2013 12:37:32 UTC+1, Calvin Spealman wrote:


 On Apr 22, 2013 7:15 AM, "Tom Christie"  wrote:
 >
 > I'd be interested to know what you folks think of this proposal.
 >
 > SingleObjectMixin currently exposes these three attributes and one 
 method all dealing with queryset filter arguments...
 >
 > * pk_url_kwarg = 'pk'
 > * slug_field = 'slug'
 > * slug_url_kwarg = 'slug'
 > * get_slug_field()
 >
 > I was wondering if it would be worth considering simplifying the API 
 somewhat, by moving those three attributes, and that method, into a 
 PendingDeprecation state, and replacing their usage with a single 
 attribute 
 instead, that is used both as the URL kwarg, and as the queryset filter.
 >
 > * lookup_field = 'pk'
 >
 > That'd (eventually) lead to a simpler get_object implementation 
 internally, and (immediately) present a slightly nicer, simpler API.
 >
 > It'd be marginally different in that slug based lookups would require 
 an explicit `lookup_field = 'slug'` to be added to the view,
 > and also in that it wouldn't handle the case of `slug_field` being 
 set to a different value from `slug_url_kwarg`.
 >
 > Personally I don't see the later being an issue as:
 >
 > 1. It's not clear to me why you'd ever *need* to use a URL kwarg 
 that's not the same as the filter arg.

 I can think of a few reasons.
 - you've changed models or fields internally through migrations, but 
 need to continue supporting old URLs.
 - you don't like the internal name to be exposed
 - you have different models but want to expose a consistent URL 
 pattern. 

 > 2. If it's really something