Re: Ticket #9321 -- Modelform widgets help text for ManyToMany fields
On Sat, May 18, 2013 at 11:38 PM, Ramiro Morales wrote: > Hi all, > > This is a proposal for fixing this small and old issue > (https://code.djangoproject.com/ticket/9321): > > [...] > > Django 1.7: > Simply stop forcing the hard-coded sentence. If users want to have it > set or added to their help text they should provide it by themselves > just like it happens with every other [model] form field. > These users are in a better position to know if it is relevant to the form > widget in use. > > This deprecation cycle won't be implemented using > [Pending]DeprecationWarning's, but rather by only documentation. The > release notes and backward incompatible timeline entry for 1.6 would > warn about the changes coming in 1.7 so they can act in advance. > > [...] > > Also, WIP PR: > https://github.com/ramiro/django/compare/master...9321-m2m-help_text > (only piece missing is the warnings described in the last two paragraphs.) I've updated the branch to add such documentation warnings. Also, changed the timeline to extend over two release cycles (1.6 - 1.8) instead of accelerating it to finish in 1.7. I've also created a second branch with the changes that would need to be performed before releasing 1.8: https://github.com/ramiro/django/compare/9321-m2m-help_text...9321-m2m-help_text-post-1.6 Apps now need to take care of the help text, the admin app is one of them and so does this patch by moving the logic there. Note how tests that check the HTML output of modelforms for models with m2m fields don't need to contain the non-relevant help text markup anymore. Regards, -- Ramiro Morales @ramiromorales -- 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: maintaining of new localflavor packages
On 19 mai 2013, at 22:37, Erik Romijn wrote: > The reason I ask, is that I'd like to volunteer for maintaining > django-localflavor-nl. Considering your track record of contributions to Django, that's a no brainer. You now have commit access to django-localflavor-nl, congratulations! -- 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.
maintaining of new localflavor packages
Hello all, With the separation of django-localflavor-* from Django core, one of the discussed advantages is that each localflavor package can have its own maintainer(s). Have we established a process for signing up for this? I couldn't find anything in docs or discussions. The reason I ask, is that I'd like to volunteer for maintaining django-localflavor-nl. As far as I could see there are currently no maintainers other than the Django core developers. Some immediate work I'd like to do is to make sure it gets on PyPI, and there's been a pull request open for months (which needs some local knowledge). cheers, Erik -- 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: Reopening/Refixing #20246
Le dimanche 19 mai 2013 09:40:25 UTC+2, Florian Apolloner a écrit : > > Hi, > > I don't think that the fix of #20246 [0] is correct. You started using > \xa0 while Wikipedia clearly suggests that we should use a narrow space > instead of a full-space (probably U+202F). This is something we learned > during our physics courses too, so it's in line with what science > departments do too. > > Any objections on refixing it? > > Cheers, > Florian > > 0: https://code.djangoproject.com/ticket/20246 > Hi Florian, I'm not completely sure. The narrow space should certainly be used between a number and its unit symbol (kg, cm, Mb, etc.). So your proposal is at least valid for a part of the patch. However, for "5 hours, 4 minutes", I'm not sure it's the same rule. I'd suggest you add references on the ticket and then fix the parts that need to be fixed. Claude -- 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: Making __repr__ safe by default
I agree with Anssi, repr should stay as-is. I do a lot of shell/pdb work and I can't recall ever encountering a problem with "unsafe" repr. I think many people would find it annoying if suddenly repr would tell you no more than the pk of the object. Karen -- 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.
History of datetime_cast_sql() in Oracle
Hi, In my quest to solve Oracle bugs, I found the function datetime_cast_sql() in the Oracle backend. It causes a problem these days, because it gets in the way of querying a date as string (mydate__startswith='2005'). It is a function that is defined as a no-op in the base backend, and overridden, among core backends, only in Oracle. Removing the override, currently, just makes one more test pass, and if we decide to remove it from the base, code in several other places may become simpler (will not need to special-case datetime values). I was able to track the history of this function, into the mists of time. In the beginning, code to cast strings into dates for Oracle was mixed in with the general querying code. Then came the boulder-oracle-sprint of 2006-2007, where, at some point, that piece of code was factored out to a module-level function get_datetime_cast_sql(), which was defined in all backends as a no-op except Oracle; this was later refactored into the DatabaseOperations class we know today. However, at about the same time that the DatabaseOperations was created, the Oracle backend made another change: It started setting the session's datetime format on login. This, as far as I understand, makes the special casting operation redundant -- and current test results support my understanding. So -- I want to fix, now, the thing that was, well, not broken, but bent, in 2007. And my question to you -- especially, those of you who participated in the boulder sprint -- can you think of any reason why I shouldn't? Thanks, Shai. PS: In the mainline commit history, the entire boulder-oracle-sprint shows up as one commit, but its detailed history is in the attic/boulder-oracle-sprint branch. -- 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: Making __repr__ safe by default
18 maj 2013 18:48, "Anssi Kääriäinen" napisał(a): > There was very similar discussion recently (maybe in some ticket, I > don't remember where) about QuerySet.__repr__(). IIRC the conclusion > was that executing SELECT queries as part of __repr__() is OK. I've been bitten by that one already. At least with postgresql if you invalidate the transaction executing any query other than rollback will raise an exception. It's not something you plan for ahead and it's a real pain to find the real cause. -- 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: ORA-01882 [was Re: looking up date as str (fails under Oracle, Ticket #20015)]
On 19 mai 2013, at 07:12, Shai Berger wrote: > Florian, Aymeric, or any Django/Oracle user in Kenya: How did you overcome > this? Install pytz. I recently skipped these tests on MySQL when pytz wasn't installed, I shall do the same for Oracle. -- 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: ORA-01882 [was Re: looking up date as str (fails under Oracle, Ticket #20015)]
Hi Shai On Sunday, May 19, 2013 7:12:12 AM UTC+2, Shai Berger wrote: > > Florian, Aymeric, or any Django/Oracle user in Kenya: How did you overcome > this? > I have no idea, I just bang my head against the CI till it works or falls completely apart (well not really, but you get the gist ;)). I'll ask Aymeric when he shows up and get back to you. Cheers, Florian -- 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.
Reopening/Refixing #20246
Hi, I don't think that the fix of #20246 [0] is correct. You started using \xa0 while Wikipedia clearly suggests that we should use a narrow space instead of a full-space (probably U+202F). This is something we learned during our physics courses too, so it's in line with what science departments do too. Any objections on refixing it? Cheers, Florian 0: https://code.djangoproject.com/ticket/20246 -- 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 #20429 - design decision needed
Currently second approach with update is implemented. W dniu niedziela, 19 maja 2013 09:34:18 UTC+2 użytkownik Karol Sikora napisał: > > Hi, > > At djangocon sprints I implemented update_or_create method on QuerySet, > Patch is ready to merge on: https://github.com/django/django/pull/1132 > But after some discussion with folks here and on bugtracker, we need > design decision. > First approach is to following get_or_create approach, passing update part > of this method through models instances and calling save method on object. > Second approach is to use update method from QuerySet, and use 'create' > part of this method as someting like fallback. It allow us to update > multiple objects at the same time, and is probablu faster, but not calling > save on object has side effect - signals like post_create and so on wouldnt > be called. > > We need design decision which approach implement in update_or_create > method. > > Karol > -- 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.
Ticket #20429 - design decision needed
Hi, At djangocon sprints I implemented update_or_create method on QuerySet, Patch is ready to merge on: https://github.com/django/django/pull/1132 But after some discussion with folks here and on bugtracker, we need design decision. First approach is to following get_or_create approach, passing update part of this method through models instances and calling save method on object. Second approach is to use update method from QuerySet, and use 'create' part of this method as someting like fallback. It allow us to update multiple objects at the same time, and is probablu faster, but not calling save on object has side effect - signals like post_create and so on wouldnt be called. We need design decision which approach implement in update_or_create method. Karol -- 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.
