Re: first() and last(), earliest() and latest()
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: Anyone have ideas on #16550 - custom SQL before/after syncdb?
On May 16, 2013 1: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 > > Jacob, going back a couple of levels, if its true that; - sqlite creates the db for you, and the testdb is created for you - sqlite could be considered to set permissions for you (ie set the owner of the db file) - mysql does *not* create the db, but the testdb *is* created for you - mysql requires you to issue a "grant all priv on..." on the db, but not the testdb - i have no idea about postgresql or oracle. and ... - the various db backends know how to craft db specific DDL then... - would it be logical for the db backend to create the db for you *if* it doesn't already exist. If the above are true, then why can't the same code that creates the testdb also create the db if it doesn't exist, and that would be the logical place to hook any post-create-db code such as user-defined data types etc? This would/could also nullify some questions that new users have when they get tangled up at the syncdb point of the tutorial if they have not granted their usercode (from settings) access to the db. D -- 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()
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?
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
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?
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
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
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
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
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
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
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
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
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? > 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. Thanks again, 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: Remote participation in sprints
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
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
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
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()
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
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
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.