Re: Help review tickets, get a prize!

[Russell Keith-Magee]

The problem is that we aren't in a position to guarantee that we have
the resources to do this all the time. Rather than set the formal
expectation that the 5-for-1 deal will always be available, I'd rather
keep it as a "Sale now on!" feature that a core developer can announce
when they find themselves with some spare time.

Yours,
Russ Magee %-)

On Sat, Aug 18, 2012 at 3:06 AM, charettes  wrote:
> What do you guys think of mentioning this in the Triaging tickets
> documentation?
>
> Should I open a ticket?
>
> Le mercredi 20 avril 2011 17:25:58 UTC-4, Jacob Kaplan-Moss a écrit :
>>
>> Hi folks --
>>
>> We have a chronic problem: our new ticket review queue. We get roughly
>> 50 new tickets each week, and we typically don't keep up with this
>> flow very well. Eventually, someone (Hi, Russ!) takes it on himself to
>> review the massive backlog, but that's damned painful.
>>
>> Right now we only have 60 unreviewed tickets in the queue, so now's a
>> great time to get on top of this problem for once and for all.
>> Everyone on this list is qualified to help. Please read on to see how,
>> and the "prize" bit is at the bottom.
>>
>> For the most part, reviewing these types tickets is an easy process.
>> Reviewers need to do the following:
>>
>> * Verify that the reported problem is actually a bug or feature
>> request. Sometimes people end up at the ticket system when they should
>> be asking for help on django-users, so they need to be pointed in that
>> direction. Other times there's not enough information on the ticket to
>> reproduce it. But most of the time, it's really a bug or feature
>> request, and a quick comment saying "I can confirm this is a bug"
>> *really* helps when it comes time to try to fix the problem.
>>
>> * Make sure the ticket's not a duplicate by searching the tracker for
>> existing tickets of the same nature.
>>
>> * Make sure the metadata (ticket type, component, etc.) is correct.
>>
>> * Move the ticket along the process (probably into into the "accepted"
>> or "design decision" stages).
>>
>> It takes me about 5 minutes to review most unreviewed tickets. A few
>> take longer, but most are pretty quick. Again, this is totally
>> something anyone here can do. Yeah, you might run into a ticket you
>> just don't get, and it's fine to skip in and move along. Remember that
>> there's help in IRC (#django-dev) nearly all the time, though.
>>
>> Of course, I'd be lying if I said that this was a whole lot of fun, so
>> here's where the prize bit comes in:
>>
>> Starting right now, I'm offering a 5-for-1 deal on reviews. If you
>> have a ticket, patch, or feature request that you'd like *me* to
>> review, simply review 5 unreviewed tickets then post your review
>> request on this list with "[5-for-1]" in the subject. I'll prioritize
>> *your* request the next time I work on Django.
>>
>> Of course, I encourage other core developers, and anyone else who's
>> capable, to join me in prioritizing these "5-for-1" requests, but this
>> isn't a BDFL action or anything -- just my way of trying to keep the
>> unreviewed queue as low as possible.
>>
>> Jacob
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/tBPUKD3Q0msJ.
>
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.

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

Re: ModelForm.Meta.overrides

[Tai Lee]

Overall, I like this patch. I think it's a little unbalanced that we 
provide `Meta.widgets` but no clearly documented way to override other 
properties on fields without replacing entire fields.

I think the doc changes are pretty helpful to users who are looking for a 
way to do this, and it is a good thing to treat all field attributes 
equally instead of special casing widgets.

I also think a class with overrides defined this way will be easier to read 
visually and easier to detect and manipulate programmatically than hacking 
`self.fields` inside `__init__()`, which people do now (myself included).

My only concern is the suggestion to use a callback as the key. I can see 
that this provides more flexibility for users who want to apply a single 
set of overrides to multiple fields, but I can see it being misused and 
abused. If people really need to do that, I think they can just construct 
their overrides dict programmatically and assign it to `Meta.overrides`.

Cheers.
Tai.


On Friday, 3 August 2012 17:04:56 UTC+10, DrMeers wrote:
>
> A couple of months ago Jannis closed #/17924 [1] as wontfix, stating "I'm 
> violently -1 on the whole topic "meta programming form fields after they've 
> been instantiated", it's a mess. Yes it would be more DRY, but also much 
> harder to know how the hell the form fields are composed as. Just override 
> the form field, it's not a huge deal code wise and much easier to grok." This 
> has since been contested [2] (though for invalid reasons in my opinion).
>
> I'm not sure that Jannis and I were talking about the same thing; the 
> solution I had in mind did not involve changing form-fields after their 
> instantiation, but rather providing a more elegant and flexible mechanism 
> that works in a similar way to ModelForm.Meta.widgets and 
> formfield_callback.
>
> I've put a draft patch together and attached it to [1] which should give a 
> better indication of the intended approach and its flexibility and 
> benefits. There are still a few details to iron out in evolving the ideal 
> implementation, but this at least demonstrates the gist of it. Does anyone 
> else think this is worth exploring?
>
> Simon
>
> [1] https://code.djangoproject.com/ticket/17924
> [2] *
> https://groups.google.com/d/msg/django-developers/x_nJ5epfG18/ZSKcPW0_DvAJ
> *
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/V-9BdhvaeKwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Django Sprint at PyCon Australia 2012 -- Monday 20th August

[DrMeers]

On Monday, 6 August 2012 15:29:04 UTC+10, DrMeers wrote:
>
> Monday 20th August 0900-2359 AEST at PyCon Australia 2012 (Hobart) [1] 
>
> The Interaction Consortium [2] have kindly offered to provide pizza 
> and beer (presumably only for those physically present ;) 
>
> Join us via the #django-sprint IRC channel on Freenode; see [3] for 
> more information. 
>
> [1] http://2012.pycon-au.org/programme/sprints 
> [2] http://interaction.net.au 
> [3] https://code.djangoproject.com/wiki/Sprints 
>

This is kicking off now. 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/s0_Fy3KyvqAJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Draft branch: Swappable User models in contrib.auth

[Russell Keith-Magee]

On Sun, Aug 19, 2012 at 5:23 PM, Marc Tamlyn  wrote:
> I believe changes to auth (and several other things) are waiting for
> contrib.migrations. It will be some time...

Incorrect. The strategy that was approved for trunk won't require
migrations unless you want to change an existing project, which means
it will be entirely opt-in. There was an extensive django-dev
discussion about 6 months ago about this; the redux is on the wiki:

https://code.djangoproject.com/wiki/ContribAuthImprovements

Yours,
Russ Magee %-)

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

Re: Draft branch: Swappable User models in contrib.auth

[Russell Keith-Magee]

On Sun, Aug 19, 2012 at 10:02 AM, Victor Hooi  wrote:
> Hi,
>
> I'm just wondering, has there been any updates on the User model refactor?
>
> My understanding is that this is the official way of handling Users going
> forward.
>
> Is there any roadmap on when it might hit trunk? I didn't see any reference
> to User models in the 1.5 release notes.

The precise answer? Soon. Ish. :-)

There's a draft branch which works [1], but requires some more testing
and documentation. It also hasn't been updated to reflect the recent
py3k changes.

I'm sprinting at PyCon AU this year, so I'm hoping to at least get the
branch up to date. I might also be able to convince someone to work on
the documentation issue.

I still want to get this in for 1.5; it's just a matter of find the spare time.

[1] https://github.com/freakboy3742/django/tree/t3011

Yours,
Russ Magee %-)

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

Re: Need Django experts to explain some of my questions in bay Area, CA

[Karen Tracey]

Please ask for help like this on django-users, not here. The topic of this
list is the development of Django itself.

Thanks,
Karen

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

Need Django experts to explain some of my questions in bay Area, CA

[Nirmal Sharma]

Hi,

I am building a website for non-profit work using Django but i got stuck at one 
place.
It would be great if somebody help me in resolving some of my question.

I need only an hr of you.

Regards
~Nirmal

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/7J1aw4zildoJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django 1.5 incompatibility at TemplateView

[Bernardo]

So as long as I don't use the `params` thing (which I don't) there will be 
no problem with my views? 
Reading this and the other commit done at the same time, looks like the 
function calls behave the way I expect :)

Bernardo

Em domingo, 19 de agosto de 2012 06h44min03s UTC-3, Marc Tamlyn escreveu:
>
> Hi Bernado,
>
> Template view passing params into the context rather than just passing the 
> kwargs from the urlconf directly is actally somewhat older, and is kept as 
> legacy from django.views.generic.simple.direct_to_template. The changes you 
> refer to do actually introduce a subtle backwards incompatibility with 
> TemplateView - but yesterday we made a new commit[1], fixing the *real* 
> problem, which is that the params variable was inconsistent with how the 
> rest of the CBVs worked. This actually introduces a slightly different 
> backwards incompatibility, which is that the params variable no longer 
> exists. This has been documented in the release notes.
>
> There is perhaps a case for removing this passing of urlconf kwargs to the 
> context all together, as it seems a little odd to me and only applies to 
> TemplateView, but for the moment it's at least been made a bit more 
> consistent with how other CBVs work.
>
> Marc
>
> [1] 
> https://github.com/django/django/commit/f04bb6d798b07aa5e7c1d99d700fa6ddc7d39e62
>
> On Saturday, 18 August 2012 08:21:28 UTC+1, Bernardo wrote:
>>
>> Hi, I was trying my project on django 1.5 alpha and a change on 
>> TemplateViews made some code break. 
>> The `get` method changed how `get_context_data` is called from (**kwargs)to 
>> (params=kwargs). Link: 
>> https://github.com/django/django/blob/master/django/views/generic/base.py
>>
>> I traced the change and found a ticket saying the TemplateView could not 
>> be used with FormView because the get_context_data is in a different 
>> layout. Ticket: https://code.djangoproject.com/ticket/16074
>>
>> I don't know how popular are classed based views among other django 
>> developers, but I only use them. So, this change could be added in the 
>> release notes to warn people about breaking some code.
>> For me, I had the habit of writing:
>>
>> With e.g. this url:   url(r'^ref/(?P\d+?)/?$', 
>> views.ref.Show.as_view())
>>
>> def get_context_data(self, id, **kw):
>> pass #do something with id
>>
>> Now, the only way I find to keep the code compatible with both 1.4 and 
>> 1.5 is doing:
>>
>> def get_context_data(self, **kw):
>> id = kw.get('params', kw)['id']
>>
>> which is just a little bit more code but could crash in django 1.4 if 
>> somehow there's a "params" argument
>>
>> Could this be avoided?
>>
>> Thanks,
>> Bernardo
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/uA4mKpt0NZ0J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: django 1.5 incompatibility at TemplateView

[Marc Tamlyn]

Hi Bernado,

Template view passing params into the context rather than just passing the 
kwargs from the urlconf directly is actally somewhat older, and is kept as 
legacy from django.views.generic.simple.direct_to_template. The changes you 
refer to do actually introduce a subtle backwards incompatibility with 
TemplateView - but yesterday we made a new commit[1], fixing the *real* 
problem, which is that the params variable was inconsistent with how the 
rest of the CBVs worked. This actually introduces a slightly different 
backwards incompatibility, which is that the params variable no longer 
exists. This has been documented in the release notes.

There is perhaps a case for removing this passing of urlconf kwargs to the 
context all together, as it seems a little odd to me and only applies to 
TemplateView, but for the moment it's at least been made a bit more 
consistent with how other CBVs work.

Marc

[1] 
https://github.com/django/django/commit/f04bb6d798b07aa5e7c1d99d700fa6ddc7d39e62

On Saturday, 18 August 2012 08:21:28 UTC+1, Bernardo wrote:
>
> Hi, I was trying my project on django 1.5 alpha and a change on 
> TemplateViews made some code break. 
> The `get` method changed how `get_context_data` is called from (**kwargs)to 
> (params=kwargs). Link: 
> https://github.com/django/django/blob/master/django/views/generic/base.py
>
> I traced the change and found a ticket saying the TemplateView could not 
> be used with FormView because the get_context_data is in a different 
> layout. Ticket: https://code.djangoproject.com/ticket/16074
>
> I don't know how popular are classed based views among other django 
> developers, but I only use them. So, this change could be added in the 
> release notes to warn people about breaking some code.
> For me, I had the habit of writing:
>
> With e.g. this url:   url(r'^ref/(?P\d+?)/?$', 
> views.ref.Show.as_view())
>
> def get_context_data(self, id, **kw):
> pass #do something with id
>
> Now, the only way I find to keep the code compatible with both 1.4 and 1.5 
> is doing:
>
> def get_context_data(self, **kw):
> id = kw.get('params', kw)['id']
>
> which is just a little bit more code but could crash in django 1.4 if 
> somehow there's a "params" argument
>
> Could this be avoided?
>
> Thanks,
> Bernardo
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/M48ifovMmXwJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: Draft branch: Swappable User models in contrib.auth

[Marc Tamlyn]

I believe changes to auth (and several other things) are waiting for 
contrib.migrations. It will be some time...

On Sunday, 19 August 2012 03:02:51 UTC+1, Victor Hooi wrote:
>
> Hi,
>
> I'm just wondering, has there been any updates on the User model refactor?
>
> My understanding is that this is the official way of handling Users going 
> forward.
>
> Is there any roadmap on when it might hit trunk? I didn't see any 
> reference to User models in the 1.5 release notes.
> Cheers,
> Victor
>
> On Wednesday, 6 June 2012 21:34:42 UTC+10, Andrew Ingram wrote:
>>
>> On 4 June 2012 16:12, Russell Keith-Magee  
>> wrote: 
>> >  * The swapping mechanic is set up using a new Meta option on models 
>> > called 'swappable' that defines the setting where an alternate model 
>> > can be defined. Technically, the swappable option *could* be used for 
>> > any model; however, I'm not proposing that we actually document this. 
>> > I've implemented it as a generic approach purely to make the internals 
>> > cleaner -- mostly to avoid needing to make references to auth.User in 
>> > the model syncdb code, and to make testing possible (i.e., we can do 
>> > validation tests on a dummy 'swappable' model, rather than trying to 
>> > munge a validation test for auth.User specifically). 
>>
>> I like the idea of a 'swappable' option, but I can see some potential 
>> issues with the implementation. I'm one of the developers of Oscar 
>> (https://github.com/tangentlabs/django-oscar/) and providing a clean 
>> method to for overriding models has been a major pain point. One of 
>> our key requirements is that any model in Oscar may be overridden, to 
>> that end every model has both abstract and concrete versions (much 
>> like your implementation of AbstractBaseUser and User). 
>>
>> Our current way of handling overrides is for every reference to a 
>> model in Oscar to use get_model rather than the explicit classname. 
>> But this does end up causing some ugly things like this: 
>>
>> from oscar.apps.catalogue.abstract_models import AbstractProduct 
>>
>> class Product(AbstractProduct): 
>> # stuff 
>>
>> from oscar.apps.catalogue.models import * 
>>
>>
>> Issues: 
>> 1) The override model HAS to have the same name as the default model, 
>> otherwise get_model('catalogue', 'Product') won't work. 
>> 2) We have to import all the remaining default models after we declare 
>> our overrides. But this only works because Django's model metaclass 
>> prevents the default Product replacing the one we've just defined. I 
>> don't like this because it's a little bit magic. 
>> 3) You have to remove Oscar's version of the app from INSTALLED_APPS 
>> and replace it with your own. Actually, technically you don't. If you 
>> leave Oscar's app installed but put your own one ('foo.catalogue') in 
>> front of it, you can even get rid of the nasty import * thing - but 
>> again, more magic. (Aside: you can actually use this approach already 
>> to override Django's User model, because the metaclass means any 
>> references to Django's User will be replaced with references to your 
>> own. ) 
>>
>> I had investigated using a class decorator to handle overrides: 
>>
>> @replace_model('catalogue.Product') 
>> class MyProduct(AbstractProduct): 
>> # foo 
>>
>> But this got seriously complicated because the metaclass modifies the 
>> class before the decorator can be applied, so I was looking into ways 
>> to sever all the ties with the app cache before I went insane and gave 
>> up. 
>>
>> Back to my main points... Your swappable option would solve quite a 
>> lot, in the case of the User model it's ideal. But I'm concerned that 
>> if people start using it more widely we'd end up having dozens of new 
>> settings that would get quite silly in the case of a large project 
>> like Oscar. I think it's important that overrides can be defined in 
>> the settings file, but I'd also like to see it possible at model 
>> definition time, either using a decorator (like above) or a Meta 
>> option like 'replaces'. The risk, of course, is that it means any 
>> third-party app could override any other model without you necessarily 
>> being aware of it, not sure how this would be mitigated. 
>>
>> If I've not made much sense let me know, I've always found it hard to 
>> articulate on this particular topic. 
>>
>>
>> Regards, 
>> Andrew Ingram 
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/VkctqktqAxMJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.