Re: first() and last(), earliest() and latest()

[Alex Ogier]

Significantly better. The latter method loads every single model in the
queryset into Python, potentially the whole database!
On May 15, 2013 9:24 PM, "Lee Trout"  wrote:

> Is qs[:1][0] better form than list(qs)[0]?
>
>
> On Wed, May 15, 2013 at 7:48 AM, Selwin Ong  wrote:
>
>> I've updated the first() and last() to not accept any arguments. Please
>> review it and let me know if there's anything else I need to change.
>> Hopefully this can get merged in during the sprints and make it into 1.6 :).
>>
>> The pull request is here: https://github.com/django/django/pull/1056
>>
>> Best,
>> Selwin
>>
>> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>>>
>>> > > I initially modeled "first()" and "last()"'s behaviors to mimic
>>> > > "latest()", but in this new pull request, you can pass multiple
>>> field names
>>> > > into "first()" and "last()" so it behaves like "order_by()". It's
>>> more
>>> > > flexible and requires less typing, but I wonder if we should just
>>> get rid
>>> > > of the optional field arguments and rely on "order_by" for ordering.
>>> "There
>>> > > should be one-- and preferably only one --obvious way to do it".
>>> >
>>> > Considering "There should be one-- and preferably only one --obvious
>>> way to
>>> > do it", I definitely prefer to rely on order_by to do the ordering,
>>> not on
>>> > first.
>>> >
>>> > .order_by('name').first()
>>> >
>>> > is clear and readable in my opinion.
>>>
>>> My thoughts exactly, we already have one method that does ordering, I
>>> don't think it is necessary to make these methods incorporate that
>>> functionality. If we did, we might argue that other QuerySet
>>> operations could be supported as well and that would just result in a
>>> bloated API. Especially if there's no performance gain (the QuerySet
>>> would be cloned anyway), and it only saves a few lines of code.
>>>
>>> Also, skimming through this thread, I think there was a consensus on
>>> first() and last() not taking any ordering arguments, i.e. the first
>>> proposed syntax:
>>>
>>> .filter(last_name__startswith=**'b').order_by('last_name').**first()
>>>
>>>
>>> Michal
>>>
>>  --
>> 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.
>
>
>

-- 
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: first() and last(), earliest() and latest()

[Lee Trout]

Is qs[:1][0] better form than list(qs)[0]?


On Wed, May 15, 2013 at 7:48 AM, Selwin Ong  wrote:

> I've updated the first() and last() to not accept any arguments. Please
> review it and let me know if there's anything else I need to change.
> Hopefully this can get merged in during the sprints and make it into 1.6 :).
>
> The pull request is here: https://github.com/django/django/pull/1056
>
> Best,
> Selwin
>
> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>>
>> > > I initially modeled "first()" and "last()"'s behaviors to mimic
>> > > "latest()", but in this new pull request, you can pass multiple field
>> names
>> > > into "first()" and "last()" so it behaves like "order_by()". It's
>> more
>> > > flexible and requires less typing, but I wonder if we should just get
>> rid
>> > > of the optional field arguments and rely on "order_by" for ordering.
>> "There
>> > > should be one-- and preferably only one --obvious way to do it".
>> >
>> > Considering "There should be one-- and preferably only one --obvious
>> way to
>> > do it", I definitely prefer to rely on order_by to do the ordering, not
>> on
>> > first.
>> >
>> > .order_by('name').first()
>> >
>> > is clear and readable in my opinion.
>>
>> My thoughts exactly, we already have one method that does ordering, I
>> don't think it is necessary to make these methods incorporate that
>> functionality. If we did, we might argue that other QuerySet
>> operations could be supported as well and that would just result in a
>> bloated API. Especially if there's no performance gain (the QuerySet
>> would be cloned anyway), and it only saves a few lines of code.
>>
>> Also, skimming through this thread, I think there was a consensus on
>> first() and last() not taking any ordering arguments, i.e. the first
>> proposed syntax:
>>
>> .filter(last_name__startswith=**'b').order_by('last_name').**first()
>>
>> Michal
>>
>  --
> 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: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

On May 15, 2013, at 9:01 PM, Jacob Kaplan-Moss  wrote:

> Hi folks --
> 
> Does anyone have some clever thoughts on how to solve #16650?
> 
> https://code.djangoproject.com/ticket/16550#comment:7 is a good
> summary of the problem: if you're using extensions, you need a way to
> run some custom SQL in tests after the DB gets created by the test
> harness but before syncdb runs.
> 
> The current patch and suggested solution on the ticket won't work (see
> the thread), but I think it's a legit need and I'd like to come up
> with a good solution and possibly reopen the ticket.
> 
> 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.
> 
> 

pre_syncdb signal? syncdb is still called in tests right?

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Perception of attitude in tickets

[Cal Leeming [Simplicity Media Ltd]]

The fact that one of the core founders of Django has responded to say
"Consider it done", is probably about as official as it can get.

I have gone ahead and written up a section explaining how the 5-for-1
system works, any amendments or additions would be welcomed.

https://code.djangoproject.com/wiki/UsingTheMailingList#a5-for-1

The more people that know about this, the better.. if everyone could try
and mention it in passing conversations on IRC, or on stale
tickets/discussions etc.

Hope this helps

Cal

On Thu, May 16, 2013 at 1:56 AM, Jacob Kaplan-Moss wrote:

> On Tue, May 14, 2013 at 5:41 PM, Cal Leeming [Simplicity Media Ltd]
>  wrote:
> > * Make the 5-for-1 (or 10-for-1) system official, not many people seem to
> > realise this exists. This will give incentive to core devs to spend a bit
> > longer on a ticket, maybe even throwing in a pleasentry or two
> (optional). I
> > often found that if I assisted with other tickets and showed myself to be
> > proactive on the ML, then my tickets would usually get the attention of a
> > core dev faster and/or with more detailed response.
>
> Consider it done - I'll take any and all 5:1 requests personally, and
> I'll shame uh... *encourage* other core devs to do the same.
>
> What do you think we should do to make it more "official"? Add it to
> the contribution docs? Put it on the code.d.c somewhere?
>
> 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.
>
>
>

-- 
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.

Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Jacob Kaplan-Moss]

Hi folks --

Does anyone have some clever thoughts on how to solve #16650?

https://code.djangoproject.com/ticket/16550#comment:7 is a good
summary of the problem: if you're using extensions, you need a way to
run some custom SQL in tests after the DB gets created by the test
harness but before syncdb runs.

The current patch and suggested solution on the ticket won't work (see
the thread), but I think it's a legit need and I'd like to come up
with a good solution and possibly reopen the ticket.

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

[Jacob Kaplan-Moss]

On Tue, May 14, 2013 at 5:41 PM, Cal Leeming [Simplicity Media Ltd]
 wrote:
> * Make the 5-for-1 (or 10-for-1) system official, not many people seem to
> realise this exists. This will give incentive to core devs to spend a bit
> longer on a ticket, maybe even throwing in a pleasentry or two (optional). I
> often found that if I assisted with other tickets and showed myself to be
> proactive on the ML, then my tickets would usually get the attention of a
> core dev faster and/or with more detailed response.

Consider it done - I'll take any and all 5:1 requests personally, and
I'll shame uh... *encourage* other core devs to do the same.

What do you think we should do to make it more "official"? Add it to
the contribution docs? Put it on the code.d.c somewhere?

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

[Jacob Kaplan-Moss]

As suggested to me (privately) by Tom Evans, I've started trying to
keep an eye on tickets that bounce back and forth between open and
wontfix. If a ticket "bounces" a few times it's probably a sign that
there's something going on, and we may want to proactively start a
mailing list thread rather than waiting for "someone" to do it.

https://www.djangoproject.com/trac/bouncing/ is that view; I hope
you'll help me keep an eye on it and bring stuff here if it needs
bringing.

Thanks again for the suggestion, Tom.

Jacob

On Wed, May 15, 2013 at 11:36 AM, ptone  wrote:
>
>
> On Wednesday, May 15, 2013 3:20:41 AM UTC-7, Luke Plant wrote:
>>
>> Hi Joe,
>>
>>
>> On 14/05/13 00:55, Joe Tennies wrote:
>> > As a fellow lurker (sorry I've been using Flask more recently), I think
>> > this could simply be fixed via a form response. Here's a simple example:
>> >
>> > This bug is being marked as "WONTFIX" because 
>> >
>> > Please realize that every API/feature added to Django needs to be
>> > maintained across several versions. The more public APIs that are
>> > exposed to users, the more difficult it is to refactor and add other
>> > features. This request currently lacks enough merit to exceed the cost
>> > it will add to the maintenance of Django.
>> >
>> > ...
>>
>> I think we need something shorter that developers can remember, i.e.
>> that we can type ourselves without resorting to a canned response,
>> 1which can be off-putting, especially if some of it doesn't apply.
>>
>> So I've gone ahead and created a wiki page, which can be longer and more
>> friendly, and require a shorter response on the actual ticket, something
>> like this:
>>
>>   Closing as WONTFIX because ...
>>
>>   If you want to persuade us otherwise, please bring it up on the
>>   DevelopersMailingList
>>
>> The page:
>>
>> https://code.djangoproject.com/wiki/DevelopersMailingList
>>
>> That's my draft, feel free to edit. We don't want it too long, as that
>> is intimidating by itself, but some of the points you make might would
>> be good additions
>>
>> What do people think?
>
>
> Luke,
>
> Thanks for taking a stab at improving things, I think one thing is not in
> question - everyone is willing to make improvements best we can.
>
> I wonder if a slightly more concise version of this should be added to the
> triaging docs instead of a wiki page (fine place to draft it though).
>
> https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#closing-tickets
>
> I feel that the wiki pages aren't very discoverable, and unless we are
> talking about patching trac to include this, such a comment won't carry the
> official weight of being in the project docs.
>
> One line I do feel needs a tweak:
>
> "while the suggestion is good in theory, it lacks enough merit to exceed the
> cost it will add to the maintenance of Django"
>
> The truth is, there are some suggestions that are just flat out
> incompatible. I'm fine to be gracious and thankful for the time someone
> takes to offer a suggestion, but that doesn't mean that all suggestions are
> automatically meritorious.
>
> Saying that in as kind a way as possible is tough - but only fair.
>
> -Preston
>
>
>>
>>
>> Luke
>>
>> --
>> "I asked mom if I was a gifted child. She said they certainly
>> wouldn't have paid for me." (Calvin and Hobbes)
>>
>> Luke Plant || http://lukeplant.me.uk/
>
> --
> 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: Reminder: pending Oracle fixes and issues

[Shai Berger]

Hi,

Resurrecting a 4-month-old thread:

On Sunday 20 January 2013 10:05:16 Anssi Kääriäinen wrote:
> On 20 tammi, 02:52, Shai Berger  wrote:
> > Which still leaves two issues -- PR #393 (faster processign of numbers; I
> > think I forgot to mention earlier -- it is just some fixes on work by Ian
> > Kelly), and PR #411 (named parameters).
> > 
> > Per Jani's PR#650 (which I just went to review and found already
> > accepted), I note that the fix in #393 requires cx_Oracle 5.0.1; if it
> > is accepted, the check for cx_Oracle major version >=5 can be removed
> > (the requirement change comes from Ian's modifications, so it is
> > apparently acceptable at least to one core developer).
> 
> It would be nice to get the named parameters addition for every
> backend, this would mean we can actually document that you can use
> named parameters and expect it to work cross-db.
> 

So -- does this mean that a patch adding named parameters on Oracle needs to 
also include tests and documentation of the "new feature" (it exists, 
undocumented, for other backends...)? Or is it just a "nice-to-have"? I'm 
asking because I have limited time to work on Oracle issues, and I suspect the 
current failing tests are higher priority.

> For the faster processing of numbers... [...] if you want a patch to be seen
> by me, then trac ticket + review is the way to go. I occasionally do commit
> patches from other sources, but Trac ORM RFC queue is the main way.
> 
Ticket #20414[0] and PR #1071[1]. Based on the fact that the code is based on 
Ian's patch, and the work[2] you (Anssi) and me have done on this together (as 
PR #393, last september), can I mark this ready-for-commit?

Thanks,
Shai.

[0] https://code.djangoproject.com/ticket/20414
[1] https://github.com/django/django/pull/1071
[2] https://groups.google.com/d/topic/django-developers/4BNkJyGez9A/discussion

-- 
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: Ticket 13978: Allow inline js/css in forms.Media

[Donald Stufft]

Re CSP

It's more or less fine to start using it. It needs a clean API for configuring 
it still but it's pretty solid. 

However a newish feature that has been added is the ability to allow _some_ 
inline scripts but not all. This feature doesn't have widespread support yet 
sadly though.

The other thing about CSP is that policies are defined per response. So a page 
that uses inline scripts could be allowed them while another page doesn't.

On May 15, 2013, at 6:28 PM, Aymeric Augustin 
 wrote:

> On 14 mai 2013, at 02:36, Derek Payton  wrote:
> 
>> I have a working patch with tests and docs for #13978, which would add the 
>> ability to have inline JS and CSS in forms.Media. I feel that this ticket is 
>> a much better solution than, e.g., scattering the required inline media 
>> throughout your templates. However the issue was raised that this goes 
>> against the W3C's Content Security Policy. Per Julian's recommendation, I am 
>> bringing this here for consideration.
>> 
>> Ticket: https://code.djangoproject.com/ticket/13978
> 
> 
> 
> Disclaimer: I'm certainly not the most qualified person when it comes to 
> frontend, but since this message didn't get an answer, here's one.
> 
> 
> Hi Derek,
> 
> https://github.com/dmpayton/django/commit/a676b609004863dd726332df865b9ead7487767e
>  looks fairly reasonable to me. 
> 
> CSP doesn't look ready for general consumption just yet, at least judging by 
> the two first lines of django-csp's docs:
>> Content-Security-Policy is a complicated header. There are many values you 
>> may need to tweak here.
> 
>> It’s worth reading the latest CSP spec and making sure you understand it 
>> before configuring django-csp.
> Different sites have different security requirements, for instance a site 
> where only admins can edit stuff is generally immune to XSS.   I don't think 
> the existence of CSP in its current state is a sufficient reason to reject 
> this ticket.
> 
> A minor suggestion: InlineJS/CSS sounds even more explicit than 
> EmbeddedJS/CSS.
> 
> I left a few other questions on GitHub. I don't expect a long answer, I just 
> want to make sure you've considered them.
> 
> -- 
> 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.
>  
>  

-- 
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: Ticket 13978: Allow inline js/css in forms.Media

[Aymeric Augustin]

On 14 mai 2013, at 02:36, Derek Payton  wrote:

> I have a working patch with tests and docs for #13978, which would add the 
> ability to have inline JS and CSS in forms.Media. I feel that this ticket is 
> a much better solution than, e.g., scattering the required inline media 
> throughout your templates. However the issue was raised that this goes 
> against the W3C's Content Security Policy. Per Julian's recommendation, I am 
> bringing this here for consideration.
> 
> Ticket: https://code.djangoproject.com/ticket/13978



Disclaimer: I'm certainly not the most qualified person when it comes to 
frontend, but since this message didn't get an answer, here's one.


Hi Derek,

https://github.com/dmpayton/django/commit/a676b609004863dd726332df865b9ead7487767e
 looks fairly reasonable to me. 

CSP doesn't look ready for general consumption just yet, at least judging by 
the two first lines of django-csp's docs:
> Content-Security-Policy is a complicated header. There are many values you 
> may need to tweak here.

> It’s worth reading the latest CSP spec and making sure you understand it 
> before configuring django-csp.
> 

Different sites have different security requirements, for instance a site where 
only admins can edit stuff is generally immune to XSS.   I don't think the 
existence of CSP in its current state is a sufficient reason to reject this 
ticket.

A minor suggestion: InlineJS/CSS sounds even more explicit than EmbeddedJS/CSS.

I left a few other questions on GitHub. I don't expect a long answer, I just 
want to make sure you've considered them.

-- 
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: Remote participation in sprints

[Łukasz Rekucki]

On 15 May 2013 20:29, Shai Berger  wrote:

> On Wednesday 15 May 2013, ptone wrote:
> > On Wednesday, May 15, 2013 10:31:36 AM UTC-7, Daniele Procida wrote:
> > > On Wed, May 15, 2013, Shai Berger 
> > > >
> > > >Will there be an effective way to do this while communicating with the
> > > >developers present at the sprint? IRC? Google hangout? IM?
> > >
> > > #djangocon and #django-sprint on irc.freenode.net
> > >
>
> Thanks,
>
> >
> > Indeed, note that the bulk of the sprinting will be during Central
> European
> > Time, UTC +1,
>
> Aren't they using Daylight Saving Time? That would put them at UTC+2,
> wouldn't
> it?
>

Yes, we are ;) CEST is the correct time zone.

-- 
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

[ptone]

On Wednesday, May 15, 2013 3:20:41 AM UTC-7, Luke Plant wrote:
>
> Hi Joe, 
>
>
> On 14/05/13 00:55, Joe Tennies wrote: 
> > As a fellow lurker (sorry I've been using Flask more recently), I think 
> > this could simply be fixed via a form response. Here's a simple example: 
> > 
> > This bug is being marked as "WONTFIX" because  
> > 
> > Please realize that every API/feature added to Django needs to be 
> > maintained across several versions. The more public APIs that are 
> > exposed to users, the more difficult it is to refactor and add other 
> > features. This request currently lacks enough merit to exceed the cost 
> > it will add to the maintenance of Django. 
> > 
> > ... 
>
> I think we need something shorter that developers can remember, i.e. 
> that we can type ourselves without resorting to a canned response, 
> 1which can be off-putting, especially if some of it doesn't apply. 
>
> So I've gone ahead and created a wiki page, which can be longer and more 
> friendly, and require a shorter response on the actual ticket, something 
> like this: 
>
>   Closing as WONTFIX because ... 
>
>   If you want to persuade us otherwise, please bring it up on the 
>   DevelopersMailingList 
>
> The page: 
>
> https://code.djangoproject.com/wiki/DevelopersMailingList 
>
> That's my draft, feel free to edit. We don't want it too long, as that 
> is intimidating by itself, but some of the points you make might would 
> be good additions 
>
> What do people think? 
>

Luke,

Thanks for taking a stab at improving things, I think one thing is not in 
question - everyone is willing to make improvements best we can.

I wonder if a slightly more concise version of this should be added to the 
triaging docs instead of a wiki page (fine place to draft it though).

https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#closing-tickets

I feel that the wiki pages aren't very discoverable, and unless we are 
talking about patching trac to include this, such a comment won't carry the 
official weight of being in the project docs.

One line I do feel needs a tweak:

"while the suggestion is good in theory, it lacks enough merit to exceed 
the cost it will add to the maintenance of Django"

The truth is, there are some suggestions that are just flat out 
incompatible. I'm fine to be gracious and thankful for the time someone 
takes to offer a suggestion, but that doesn't mean that all suggestions are 
automatically meritorious.

Saying that in as kind a way as possible is tough - but only fair.

-Preston

 

>
> Luke 
>
> -- 
> "I asked mom if I was a gifted child. She said they certainly 
> wouldn't have paid for me." (Calvin and Hobbes) 
>
> Luke Plant || http://lukeplant.me.uk/ 
>

-- 
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: Remote participation in sprints

[ptone]

On Wednesday, May 15, 2013 10:31:36 AM UTC-7, Daniele Procida wrote:
>
> On Wed, May 15, 2013, Shai Berger  
> wrote: 
>
> >Hi all, 
> > 
> >This saturday and sunday there are supposed to be sprints in DjangoCon EU 
> in 
> >Warsaw. To my regret, I could not be present at the conference. However, 
> >I may 
> >be able to set aside the two days and participate in the sprint remotely. 
> > 
> >Will there be an effective way to do this while communicating with the 
> >developers present at the sprint? IRC? Google hangout? IM? 
>
> #djangocon and #django-sprint on irc.freenode.net 
>
> Daniele 
>
>
Indeed, note that the bulk of the sprinting will be during Central European 
Time, UTC +1, also a reminder that #django-dev is another IRC channel that 
is always available to seek feedback on for contributions to Django - not 
just during conferences and sprints.

-Preston

 

-- 
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: Remote participation in sprints

[Daniele Procida]

On Wed, May 15, 2013, Shai Berger  wrote:

>Hi all,
>
>This saturday and sunday there are supposed to be sprints in DjangoCon EU in 
>Warsaw. To my regret, I could not be present at the conference. However,
>I may 
>be able to set aside the two days and participate in the sprint remotely.
>
>Will there be an effective way to do this while communicating with the 
>developers present at the sprint? IRC? Google hangout? IM?

#djangocon and #django-sprint on irc.freenode.net

Daniele

-- 
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.

Remote participation in sprints

[Shai Berger]

Hi all,

This saturday and sunday there are supposed to be sprints in DjangoCon EU in 
Warsaw. To my regret, I could not be present at the conference. However, I may 
be able to set aside the two days and participate in the sprint remotely.

Will there be an effective way to do this while communicating with the 
developers present at the sprint? IRC? Google hangout? IM?

Thanks in advance,

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: Perception of attitude in tickets

[Aymeric Augustin]

On 15 mai 2013, at 12:20, Luke Plant  wrote:

> So I've gone ahead and created a wiki page, which can be longer and more
> friendly, and require a shorter response on the actual ticket, something
> like this:
> 
>  Closing as WONTFIX because ...
> 
>  If you want to persuade us otherwise, please bring it up on the
>  DevelopersMailingList
> 
> The page:
> 
> https://code.djangoproject.com/wiki/DevelopersMailingList
> 
> That's my draft, feel free to edit. We don't want it too long, as that
> is intimidating by itself, but some of the points you make might would
> be good additions
> 
> What do people think?


That's very helpful.

Actually we already have a few wiki pages for this purpose:
https://code.djangoproject.com/wiki/TicketClosingReasons

They have varying levels of detail, and some could use an
update. I suggest moving the page you just created there,
so it's easier to locate it in the future.

This is also a reminder to triagers that these answers exist.
I agree with Luke that they should be used in combination
with a short and specific explanation.

-- 
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: first() and last(), earliest() and latest()

[Selwin Ong]

I've updated the first() and last() to not accept any arguments. Please 
review it and let me know if there's anything else I need to change. 
Hopefully this can get merged in during the sprints and make it into 1.6 :).

The pull request is here: https://github.com/django/django/pull/1056 

Best,
Selwin

On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
>
> > > I initially modeled "first()" and "last()"'s behaviors to mimic 
> > > "latest()", but in this new pull request, you can pass multiple field 
> names 
> > > into "first()" and "last()" so it behaves like "order_by()". It's more 
> > > flexible and requires less typing, but I wonder if we should just get 
> rid 
> > > of the optional field arguments and rely on "order_by" for ordering. 
> "There 
> > > should be one-- and preferably only one --obvious way to do it". 
> > 
> > Considering "There should be one-- and preferably only one --obvious way 
> to 
> > do it", I definitely prefer to rely on order_by to do the ordering, not 
> on 
> > first. 
> > 
> > .order_by('name').first() 
> > 
> > is clear and readable in my opinion. 
>
> My thoughts exactly, we already have one method that does ordering, I 
> don't think it is necessary to make these methods incorporate that 
> functionality. If we did, we might argue that other QuerySet 
> operations could be supported as well and that would just result in a 
> bloated API. Especially if there's no performance gain (the QuerySet 
> would be cloned anyway), and it only saves a few lines of code. 
>
> Also, skimming through this thread, I think there was a consensus on 
> first() and last() not taking any ordering arguments, i.e. the first 
> proposed syntax: 
>
> .filter(last_name__startswith='b').order_by('last_name').first() 
>
> Michal 
>

-- 
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

[Shai Berger]

On Wednesday 15 May 2013, Luke Plant wrote:
> 
> So I've gone ahead and created a wiki page, which can be longer and more
> friendly, and require a shorter response on the actual ticket, something
> like this:
> 
>   Closing as WONTFIX because ...
> 
>   If you want to persuade us otherwise, please bring it up on the
>   DevelopersMailingList
> 
> The page:
> 
> https://code.djangoproject.com/wiki/DevelopersMailingList
> 
> What do people think?
> 
> Luke

+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: Perception of attitude in tickets

[Luke Plant]

Hi Joe,


On 14/05/13 00:55, Joe Tennies wrote:
> As a fellow lurker (sorry I've been using Flask more recently), I think
> this could simply be fixed via a form response. Here's a simple example:
> 
> This bug is being marked as "WONTFIX" because 
> 
> Please realize that every API/feature added to Django needs to be
> maintained across several versions. The more public APIs that are
> exposed to users, the more difficult it is to refactor and add other
> features. This request currently lacks enough merit to exceed the cost
> it will add to the maintenance of Django.
>
> ...

I think we need something shorter that developers can remember, i.e.
that we can type ourselves without resorting to a canned response,
1which can be off-putting, especially if some of it doesn't apply.

So I've gone ahead and created a wiki page, which can be longer and more
friendly, and require a shorter response on the actual ticket, something
like this:

  Closing as WONTFIX because ...

  If you want to persuade us otherwise, please bring it up on the
  DevelopersMailingList

The page:

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

That's my draft, feel free to edit. We don't want it too long, as that
is intimidating by itself, but some of the points you make might would
be good additions

What do people think?

Luke

-- 
"I asked mom if I was a gifted child. She said they certainly
wouldn't have paid for me." (Calvin and Hobbes)

Luke Plant || http://lukeplant.me.uk/

-- 
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.