date:20201215

Re: [Django] #32273: Document AdminSite.unregister().

2020-12-15 Thread Django

#32273: Document AdminSite.unregister().
-+-
 Reporter:  Adam (Chainz)|Owner:  Hasan
  Johnson|  Ramezani
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Mariusz Felisiak ):

 In [changeset:"da42df9378ce012d72747fbf1160a6afdf5f5095" da42df93]:
 {{{
 #!CommitTicketReference repository=""
 revision="da42df9378ce012d72747fbf1160a6afdf5f5095"
 [3.1.x] Fixed #32273 -- Doc'd AdminSite.unregister().

 Backport of bebd4cfa8f5e0d2dff2de5e50d86e849a40f4bb2 from master
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.9bca825376c054356b17379121759f49%40djangoproject.com.

Re: [Django] #32273: Document AdminSite.unregister().

2020-12-15 Thread Django

#32273: Document AdminSite.unregister().
-+-
 Reporter:  Adam (Chainz)|Owner:  Hasan
  Johnson|  Ramezani
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by GitHub ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"bebd4cfa8f5e0d2dff2de5e50d86e849a40f4bb2" bebd4cfa]:
 {{{
 #!CommitTicketReference repository=""
 revision="bebd4cfa8f5e0d2dff2de5e50d86e849a40f4bb2"
 Fixed #32273 -- Doc'd AdminSite.unregister().
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.6945179a89da4a806bebb193c9baf48c%40djangoproject.com.

Re: [Django] #32267: Unable to unapply a branch of migrations

2020-12-15 Thread Django

Comment (by Mariusz Felisiak):

> Can we at the very least add something like `manage.py migrate
--unapply-one ` that would unapply one migration, having
ensured that no currently applied migrations depend on it? This will solve
the use case I outlined and maybe some others while not being able to
corrupt the DB state.

Migrations can be reversed, see
[https://docs.djangoproject.com/en/3.1/topics/migrations/#reversing-
migrations docs]. However adding an option to reverse a specific migration
doesn't sound like a good idea, we will not be able to ensure that a
database state is not corrupted. Migrations history must be continuous.
You're talking about reversing migrations in a database but without
continuous changes reflected in migrations. So you would like to drop a
feature branch, reverse its migrations and have a clear path without
migrations from the feature branch, and yes you can do this but outside of
Django migrations. The proper way do this in Django is to reverse code
changes from the feature branch and run `makemigrations` that will create
a new migration reversing db changes.

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.d9487533eea9d2405be0a44569f924ba%40djangoproject.com.

Re: [Django] #32273: Document AdminSite.unregister().

2020-12-15 Thread Django

#32273: Document AdminSite.unregister().
-+-
 Reporter:  Adam (Chainz)|Owner:  Hasan
  Johnson|  Ramezani
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Adam (Chainz) Johnson):

 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.3fb9eae31877ade8d0d23a6ba7773272%40djangoproject.com.

Re: [Django] #32267: Unable to unapply a branch of migrations

2020-12-15 Thread Django

#32267: Unable to unapply a branch of migrations
---+--
 Reporter:  Roman Odaisky  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Migrations |  Version:  3.1
 Severity:  Normal |   Resolution:  invalid
 Keywords: | Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by Roman Odaisky):

 By the way, do I understand correctly that if this code:
 
https://github.com/django/django/blob/stable/3.1.x/django/db/migrations/executor.py#L43
 is modified so instead of the loop
 {{{
 for node in next_in_app:
 for migration in self.loader.graph.backwards_plan(node):
 }}}
 it simply performs `self.loader.graph.backwards_plan(target)` it will do
 exactly what I want, that is, migrate back to the specified migration and
 then unapply that migration as well?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.e63cfe661ba63cfa0a8b95813aaa8823%40djangoproject.com.

Re: [Django] #32267: Unable to unapply a branch of migrations

2020-12-15 Thread Django

Comment (by Roman Odaisky):

Replying to [comment:1 Mariusz Felisiak]:

> Working with migrations on feature branches is difficult and each
situation is different, I don't see a way to add an option to the
`migrate` command that can decide for you. Personally I would recommend
using a separate db for each feature that can be abandoned if not needed.

Can we at the very least add something like `manage.py migrate --unapply-
one ` that would unapply one migration, having ensured
that no currently applied migrations depend on it? This will solve the use
case I outlined and maybe some others while not being able to corrupt the
DB state.

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/065.bda3d3fa93a3207737b87e422e53368b%40djangoproject.com.

Re: [Django] #28333: Filter and subquery for window expressions

2020-12-15 Thread Django

#28333: Filter and subquery for window expressions
-+-
 Reporter:  Mads Jensen  |Owner:  Manav
 |  Agarwal
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  window orm filter| Triage Stage:  Accepted
  subquery GSoC  |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Manav Agarwal):

 * owner:  nobody => Manav Agarwal
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.7743bc087ffa930f7e900413b456ef5e%40djangoproject.com.

Re: [Django] #32273: Document AdminSite.unregister().

2020-12-15 Thread Django

#32273: Document AdminSite.unregister().
-+-
 Reporter:  Adam (Chainz)|Owner:  Hasan
  Johnson|  Ramezani
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * has_patch:  0 => 1


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.2f0d9e5c59e3bc4371acc96b05b6f5ef%40djangoproject.com.

Re: [Django] #32273: Document AdminSite.unregister().

2020-12-15 Thread Django

#32273: Document AdminSite.unregister().
-+-
 Reporter:  Adam (Chainz)|Owner:  Hasan
  Johnson|  Ramezani
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Hasan Ramezani):

 * owner:  nobody => Hasan Ramezani
 * status:  new => assigned


Comment:

 [https://github.com/django/django/pull/13780 PR]

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.6b897ff06244ea45146fa6dde980a11f%40djangoproject.com.

Re: [Django] #32273: Document AdminSite.unregister().

2020-12-15 Thread Django

#32273: Document AdminSite.unregister().
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Adam (Chainz) Johnson):

 Huh. I guess `unregister()` was missed at that time.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.6de744ea4a1576394938a471348401b1%40djangoproject.com.

Re: [Django] #26602: Provide a way to manage grouping with RawSQL

2020-12-15 Thread Django

#26602: Provide a way to manage grouping with RawSQL
-+-
 Reporter:  Jamie Cockburn   |Owner:  Manav
 |  Agarwal
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Manav Agarwal):

 Replying to [comment:2 Josh Smeaton]:
 > This happens because RawSQL defines:
 >
 > {{{
 > def get_group_by_cols(self):
 > return [self]
 > }}}
 >
 > It'd be helpful if there was a way to disable grouping in an easy way.
 For the moment, you should be able to do something like:
 >
 > {{{
 > window = RawSQL("SUM(amount) OVER (ORDER BY created)", [])
 > window.get_group_by_cols = lambda: []
 > qs = A.objects.annotate(total=window)
 > qs.count()
 >
 > # Or..
 >
 > RawAggregate(RawSQL):
 > contains_aggregate = True  # may not be necessary in newer django
 versions
 > def get_group_by_cols(self):
 > return []
 >
 > qs = A.objects.annotate(total=RawAggregate("SUM(amount) OVER (ORDER BY
 created)", []))
 > }}}
 >
 > Can you let me know if this workaround helps you?
 >
 > In the meantime, I think it's worth figuring out how we want to treat
 RawSQL when it should not be doing group bys, so I'm accepting on that
 basis.
 >
 > Two options I see. First, we can define a whole new class as I've done
 above - like RawAggregate. Second, we could use a kwarg to RawSQL to tweak
 whether or not it contains aggregate code.
 >
 > {{{
 > RawSQL('SELECT SUM() ..', [], grouping=False)
 > }}}

 I think we may use Josh's suggestion of adding a kwarg to RawSQL to tweak
 whether or not it contains aggregate code. Please update if this is fine
 so that I may submit a patch.
 Regards

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.a2a897fdcf2dead02a6a2e9ccbf5edfa%40djangoproject.com.

Re: [Django] #26602: Provide a way to manage grouping with RawSQL

2020-12-15 Thread Django

#26602: Provide a way to manage grouping with RawSQL
-+-
 Reporter:  Jamie Cockburn   |Owner:  Manav
 |  Agarwal
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  QuerySet.extra   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Manav Agarwal):

 * owner:  nobody => Manav Agarwal
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.7ca10be111930259266427996ff058dc%40djangoproject.com.

Re: [Django] #32273: Document AdminSite.unregister(). (was: Document AdminSite.unregister())

2020-12-15 Thread Django

#32273: Document AdminSite.unregister().
-+-
 Reporter:  Adam (Chainz)|Owner:  nobody
  Johnson|
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  contrib.admin|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 #27076

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.14957ab051637d7b4d7f723a2f951ca3%40djangoproject.com.

[Django] #32273: Document AdminSite.unregister()

2020-12-15 Thread Django

#32273: Document AdminSite.unregister()
-+
   Reporter:  Adam (Chainz) Johnson  |  Owner:  nobody
   Type:  Cleanup/optimization   | Status:  new
  Component:  contrib.admin  |Version:  master
   Severity:  Normal |   Keywords:
   Triage Stage:  Unreviewed |  Has patch:  0
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+
 As suggested by Muskan Vaswan [https://groups.google.com/forum/#!msg
 /django-developers/Q8I-0-2Sn4M/LyQP7AaiAQAJ on django-developers]. Several
 snippets in the documentation use this function, but it's not documented.
 It should be covered next to AdminSite.register().

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.1366889d2f56a4fe802c8eb781d3b27c%40djangoproject.com.

[Django] #32272: gettext_lazy inconsistent error when nested

2020-12-15 Thread Django

#32272: gettext_lazy inconsistent error when nested
--+
   Reporter:  John Bazik  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Utilities   |Version:  3.1
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 When gettext_lazy is called with a lazy object, it returns a nested lazy
 object which has inconsistent behavior, depending on whether USE_I18N is
 set or not.


 {{{
 >>> from django import __version__
 >>> print(__version__)
 3.1
 >>> from django.utils.functional import lazy
 >>> from django.utils.translation.trans_real import gettext as
 gettext_real
 >>> from django.utils.translation.trans_null import gettext as
 gettext_noop
 >>> gettext_lazy_real = lazy(gettext_real, str)
 >>> gettext_lazy_noop = lazy(gettext_noop, str)
 >>> r1 = gettext_lazy_real('Real')
 >>> r2 = gettext_lazy_real(r1)
 >>> n1 = gettext_lazy_noop('Noop')
 >>> n2 = gettext_lazy_noop(n1)
 >>> print(str(r1))
 Real
 >>> print(str(r2))
 Real
 >>> print(str(n1))
 Noop
 >>> print(str(n2))
 Traceback (most recent call last):
   File "", line 1, in 
 TypeError: __str__ returned non-string (type __proxy__)
 }}}

 I discovered this problem while working with version 2.2.

 I've run across this twice now.  The first time, I created a pull request
 for another project to avoid the nesting.  However, now that I've seen it
 again, I think that because it works in the case of USE_I18N=True, it's
 easy for developers to miss the problem, especially so since testing
 USE_I18N has some quirks.  Here's my pull request:

 https://github.com/django-cms/django-cms/pull/6896

 I think the best fix would be to disallow nesting by simply returning
 already-nested objects, but I'm not sure of all the subtleties in that
 code.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/049.2d748f132a631f91e51b0418ce1c06d4%40djangoproject.com.

Re: [Django] #32270: Changing Django’s default test runner to be more robust

2020-12-15 Thread Django

#32270: Changing Django’s default test runner to be more robust
---+--
 Reporter:  Diptesh Choudhuri  |Owner:  nobody
 Type:  New feature|   Status:  closed
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:  duplicate
 Keywords:  testing| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Mariusz Felisiak):

 * status:  new => closed
 * resolution:   => duplicate


Comment:

 > Anyone who has used pytest with django will immediately agree that it is
 much more pleasurable to work with, ...

 We shouldn't generalize, I've used `pytest` but I don't agree that it's
 much better then Django's test runner.

 I think it's basically a duplicate of #25707.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.1a5bdbcbf5261f87aba5f1c04d8fb39f%40djangoproject.com.

[Django] #32271: Documentation consistency between display views and edit views

2020-12-15 Thread Django

#32271: Documentation consistency between display views and edit views
+
   Reporter:  Carles Pina Estany|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Documentation |Version:  3.1
   Severity:  Normal|   Keywords:
   Triage Stage:  Unreviewed|  Has patch:  0
Needs documentation:  0 |Needs tests:  0
Patch needs improvement:  0 |  Easy pickings:  0
  UI/UX:  0 |
+
 In the "generic display views" (https://docs.djangoproject.com/en/3.1/ref
 /class-based-views/generic-
 display/#django.views.generic.detail.DetailView) the example is:

 {{{
 class ArticleDetailView(DetailView):
 }}}

 In the "Generic editing views" (https://docs.djangoproject.com/en/3.1/ref
 /class-based-views/generic-
 editing/#django.views.generic.edit.CreateView.template_name_suffix) the
 example is:

 {{{
 class AuthorCreate(CreateView):
 }}}

 (note that there is no `View` after `AuthorCreate`, like it was in the
 `ArticleDetailView` example)

 I was expecting it to be either:


 {{{
 class ArticleDetailView(DetailView)

 class AuthorCreateView(CreateView)
 }}}

 or:
 {{{
 class ArticleDetail(DetailView)

 class AuthorCreate(CreateView)
 }}}

 I'm happy to do a PR of any of the options. I'm slightly inclined for the
 second one to keep it short and because usually these classes are in
 `views.py`.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/048.b85ed2afa5a000412e3bb4c69d0404c0%40djangoproject.com.

Re: [Django] #25707: Use py.test for internal testing

2020-12-15 Thread Django

#25707: Use py.test for internal testing
-+-
 Reporter:  Olivier Le Thanh |Owner:  nobody
  Duong  |
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Petr Přikryl):

 * cc: Petr Přikryl (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.06a9bca734d0630e86101a394efb7d04%40djangoproject.com.

Re: [Django] #25707: Use py.test for internal testing

2020-12-15 Thread Django

#25707: Use py.test for internal testing
-+-
 Reporter:  Olivier Le Thanh |Owner:  nobody
  Duong  |
 Type:  New feature  |   Status:  new
Component:  Testing framework|  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:
 |  Someday/Maybe
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by אורי):

 * cc: אורי (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/066.a254d03e333f22258b56a6340adfb528%40djangoproject.com.

Re: [Django] #32226: QuerySet.explain(format='json') outputs repr'd JSON on PostgreSQL

2020-12-15 Thread Django

#32226: QuerySet.explain(format='json') outputs repr'd JSON on PostgreSQL
-+-
 Reporter:  Adam (Chainz)|Owner:
  Johnson|  ankitdawadi
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.0
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by ankitdawadi):

 * owner:  kosc => ankitdawadi


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.7b3d63ba1f60dae8584576f5c8523b55%40djangoproject.com.

Re: [Django] #31932: Unique checking in formsets should exclude forms marked for deletion.

2020-12-15 Thread Django

#31932: Unique checking in formsets should exclude forms marked for deletion.
-+-
 Reporter:  Marco Beri   |Owner:  Aditya
 |  parashar
 Type:  New feature  |   Status:  assigned
Component:  Forms|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  formset, inline, | Triage Stage:  Accepted
  unique_together|
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Aditya parashar):

 * owner:  (none) => Aditya parashar
 * status:  new => assigned


Comment:

 I think the solution may be use a clean method

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/063.e9f1915490f94127ebefbd47ce940277%40djangoproject.com.

Re: [Django] #32270: Changing Django’s default test runner to be more robust

2020-12-15 Thread Django

#32270: Changing Django’s default test runner to be more robust
---+--
 Reporter:  Diptesh Choudhuri  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  testing| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--

Comment (by ADI33352):

 yes you can there are many good advantages that I see by viewing  through
 There are a lot more features overall, but I think one major reason people
 use nose/djano_nose is that it allows you to very easily do code coverage.
 nose comes with a number of builtin plugins to help you with output
 capture, error introspection etc . So sure you can do it I Don't know
 pytest much

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.80e00d26c4219b36ae2ec6e61c1e8fed%40djangoproject.com.

Re: [Django] #32263: squashmigrations produces incorrect result with a RenameModel on a ForeignKey target.

2020-12-15 Thread Django

#32263: squashmigrations produces incorrect result with a RenameModel on a
ForeignKey target.
--+
 Reporter:  InvalidInterrupt  |Owner:  nobody
 Type:  Bug   |   Status:  new
Component:  Migrations|  Version:  3.1
 Severity:  Normal|   Resolution:
 Keywords:| Triage Stage:  Accepted
Has patch:  0 |  Needs documentation:  0
  Needs tests:  0 |  Patch needs improvement:  0
Easy pickings:  0 |UI/UX:  0
--+

Comment (by ADI33352):

 You'll have to change the order of your save and assignment operations, or
 do the extra assignment. it might help

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/074.108e334664e93874d4546147e29f8ec2%40djangoproject.com.

Re: [Django] #32270: Changing Django’s default test runner to be more robust

2020-12-15 Thread Django

#32270: Changing Django’s default test runner to be more robust
---+--
 Reporter:  Diptesh Choudhuri  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  testing| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Description changed by Diptesh Choudhuri:

Old description:

> The default django test runner gets the job done, but it (and the entire
> django codebase) can benefit from a more robust runner, like **pytest**
> or **nose**. I will take the example of **pytest** because I am familiar
> with it and it is more widely used.
>
> Anyone who has used **pytest** with django will immediately agree that it
> is much more pleasurable to work with, albeit a bit more intimidating. I
> intend   work on the intimidating part and make it easier by adding a lot
> of documentation.
>
> Please let me know your opinions on this topic. If it gets traction, I
> will work on compiling a list of what **pytest** has over the default
> runner, and what I intend to do to solve all of this.
>
> **NOTE**: If accepted, this will be my proposal for GSoC 2021 to the
> Django Organization.
>
> Best,
> Diptesh

New description:

 The default django test runner gets the job done, but it (and the entire
 django codebase) can benefit from a more robust runner, like **pytest** or
 **nose**. I will take the example of **pytest** because I am familiar with
 it and it is more widely used.

 Anyone who has used **pytest** with django will immediately agree that it
 is much more pleasurable to work with, albeit a bit more intimidating. I
 intend   work on the intimidating part and make it easier by adding a lot
 of documentation.

 Please let me know your opinions on this topic. If it gets traction, I
 will work on compiling a list of what **pytest** has over the default
 runner, and what I intend to do to solve all of this.

 **NOTE**: If accepted, this will be my proposal for GSoC 2021 to the
 Django Organization.

 EDIT: I also made a post about this in the django developers google group
 (https://groups.google.com/g/django-developers) but for some reason, it
 said that it needs to be approved before being moade available to the
 public. If someone could look into that, it'd be great.

 Best,
 Diptesh

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.f74ab43597654f850a8a3f8037717efc%40djangoproject.com.

Re: [Django] #32270: Changing Django’s default test runner to be more robust

2020-12-15 Thread Django

#32270: Changing Django’s default test runner to be more robust
---+--
 Reporter:  Diptesh Choudhuri  |Owner:  nobody
 Type:  New feature|   Status:  new
Component:  Testing framework  |  Version:  master
 Severity:  Normal |   Resolution:
 Keywords:  testing| Triage Stage:  Unreviewed
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+--
Changes (by Diptesh Choudhuri):

 * version:  3.1 => master


Old description:

> The default django test runner gets the job done, but it (and the entire
> django codebase) can benefit from a more robust runner, like **pytest**
> or **nose**. I will take the example of **pytest** because I am familiar
> with it and it is more widely used.
>
> Anyone who has used **pytest** with django will immediately agree that it
> is much more pleasurable to work with, albeit a bit more intimidating. I
> intend   work on the intimidating part and make it easier by adding a lot
> of documentation.
>
> Please let me know your opinions on this topic. If it gets traction, I
> will work on compiling a list of what **pytest** has over the default
> runner, and what I intend to do to solve all of this.
>
> **NOTE**: If accepted, this will be my proposal for GSoC 2021.
>
> Best,
> Diptesh

New description:

 The default django test runner gets the job done, but it (and the entire
 django codebase) can benefit from a more robust runner, like **pytest** or
 **nose**. I will take the example of **pytest** because I am familiar with
 it and it is more widely used.

 Anyone who has used **pytest** with django will immediately agree that it
 is much more pleasurable to work with, albeit a bit more intimidating. I
 intend   work on the intimidating part and make it easier by adding a lot
 of documentation.

 Please let me know your opinions on this topic. If it gets traction, I
 will work on compiling a list of what **pytest** has over the default
 runner, and what I intend to do to solve all of this.

 **NOTE**: If accepted, this will be my proposal for GSoC 2021 to the
 Django Organization.

 Best,
 Diptesh

--

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/065.30a20a187950dc262fe81b6d7f6c709f%40djangoproject.com.

[Django] #32270: Changing Django’s default test runner to be more robust

2020-12-15 Thread Django

#32270: Changing Django’s default test runner to be more robust
-+-
Reporter: Diptesh Choudhuri | Owner: nobody
Type: New feature| Status: new
Component: Testing framework |Version: 3.1
Severity: Normal | Keywords: testing
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 |Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-+-
The default django test runner gets the job done, but it (and the entire
django codebase) can benefit from a more robust runner, like **pytest** or
**nose**. I will take the example of **pytest** because I am familiar with
it and it is more widely used.

Anyone who has used **pytest** with django will immediately agree that it
is much more pleasurable to work with, albeit a bit more intimidating. I
intend work on the intimidating part and make it easier by adding a lot
of documentation.

Please let me know your opinions on this topic. If it gets traction, I
will work on compiling a list of what **pytest** has over the default
runner, and what I intend to do to solve all of this.

**NOTE**: If accepted, this will be my proposal for GSoC 2021.

Best,
Diptesh

--
Ticket URL:
Django
The Web framework for perfectionists with deadlines.

--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/050.3d43c464c41b9fb823bb0bea8a055f44%40djangoproject.com.

Re: [Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

2020-12-15 Thread Django

#32269: parse_duration() ISO string sign is ignored when the timedelta only has
days
---+
 Reporter:  Hanno  |Owner:  Hanno
 Type:  Bug|   Status:  assigned
Component:  Utilities  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Hanno):

 * owner:  nobody => Hanno
 * status:  new => assigned


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.0192b02748e6f1cb2c29719e1e2e66a8%40djangoproject.com.

Re: [Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

2020-12-15 Thread Django

#32269: parse_duration() ISO string sign is ignored when the timedelta only has
days
---+
 Reporter:  Hanno  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+

Comment (by Hanno):

 I can try! Hopefully I can find the time.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.2bedcd47f212d885b71fa6499a9e1cc8%40djangoproject.com.

Re: [Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

2020-12-15 Thread Django

#32269: parse_duration() ISO string sign is ignored when the timedelta only has
days
---+
 Reporter:  Hanno  |Owner:  nobody
 Type:  Bug|   Status:  new
Component:  Utilities  |  Version:  3.1
 Severity:  Normal |   Resolution:
 Keywords: | Triage Stage:  Accepted
Has patch:  0  |  Needs documentation:  0
  Needs tests:  0  |  Patch needs improvement:  0
Easy pickings:  0  |UI/UX:  0
---+
Changes (by Mariusz Felisiak):

 * stage:  Unreviewed => Accepted


Comment:

 Great catch. Would you like to prepare a patch?

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.83f3b510aa53c2234395a0ba04fe511b%40djangoproject.com.

Re: [Django] #31007: Make it possible to change the default AutoField to BigAutoField.

2020-12-15 Thread Django

#31007: Make it possible to change the default AutoField to BigAutoField.
-+-
 Reporter:  Caio Ariede  |Owner:  Tom
 |  Forbes
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"b5e12d490af3debca8c55ab3c1698189fdedbbdb" b5e12d49]:
 {{{
 #!CommitTicketReference repository=""
 revision="b5e12d490af3debca8c55ab3c1698189fdedbbdb"
 Fixed #31007 -- Allowed specifying type of auto-created primary keys.

 This also changes the default type of auto-created primary keys
 for new apps and projects to BigAutoField.
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.69c3696f50a1c8a1835f840bec4f3f86%40djangoproject.com.

Re: [Django] #32261: Log exceptions handled in Signal.send_robust()

2020-12-15 Thread Django

#32261: Log exceptions handled in Signal.send_robust()
-+-
 Reporter:  Adam (Chainz)|Owner:  Ayush
  Johnson|  Bansal
 Type:  New feature  |   Status:  closed
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:  fixed
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak ):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 In [changeset:"b960e4ed722a04a9db0d35293f76e253eedf9126" b960e4e]:
 {{{
 #!CommitTicketReference repository=""
 revision="b960e4ed722a04a9db0d35293f76e253eedf9126"
 Fixed #32261 -- Added error logging to Signal.send_robust().
 }}}

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.92e67bf410d5991895b8cd38e1f54e78%40djangoproject.com.

Re: [Django] #7623: Multi-table inheritance: Add the ability create child instance from existing parent

2020-12-15 Thread Django

#7623: Multi-table inheritance: Add the ability create child instance from
existing parent
-+-
 Reporter:  brooks.travis@…  |Owner:  (none)
 Type:  New feature  |   Status:  new
Component:  Database layer   |  Version:  master
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  model-inheritance,   | Triage Stage:  Accepted
  multi-table-inheritance|
Has patch:  1|  Needs documentation:  0
  Needs tests:  1|  Patch needs improvement:  1
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Bel-Shazzar):

 * cc: Bel-Shazzar (added)


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/081.00c37068ba4bdc9681d9e1e530487a56%40djangoproject.com.

Re: [Django] #32261: Log exceptions handled in Signal.send_robust()

2020-12-15 Thread Django

#32261: Log exceptions handled in Signal.send_robust()
-+-
 Reporter:  Adam (Chainz)|Owner:  Ayush
  Johnson|  Bansal
 Type:  New feature  |   Status:  assigned
Component:  Core (Other) |  Version:  master
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Ready for
 |  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Mariusz Felisiak):

 * needs_better_patch:  1 => 0
 * stage:  Accepted => Ready for checkin


-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/068.df4ccdb57ad8f34e6cdd9e5ca782612b%40djangoproject.com.

Re: [Django] #32255: User.has_perm should forward **kwargs to allow more flexibility in authentication backends

2020-12-15 Thread Django

#32255: User.has_perm should forward **kwargs to allow more flexibility in
authentication backends
-+-
 Reporter:  Matteo Parrucci  |Owner:  (none)
 Type:  New feature  |   Status:  assigned
Component:  contrib.auth |  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:  auth,| Triage Stage:  Accepted
  django.contrib.auth,   |
  authentication, request,   |
  has_perm, has_perms, sites,|
  django.contrib.sites   |
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * stage:  Unreviewed => Accepted


Comment:

 Hey Matteo — could you put the proposed change into a PR so we can see the
 diff? Essentially, if it's not a breaking change then OK, otherwise it's
 difficult — much easier to see that in a PR. Thanks.

 Seems reasonable from the description. I'll provisionally Accept on that
 basis. (Can't immediately see how adding `**kwargs` would be breaking
 change so …)

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/064.422e38584ec1e23957677eaf0eec1dd5%40djangoproject.com.

Re: [Django] #32260: handler500 as a Class-based view raises SystemCheckError

2020-12-15 Thread Django

#32260: handler500 as a Class-based view raises SystemCheckError
-+-
 Reporter:  Daniyal Abbasi   |Owner:  Daniyal
 Type:   |  Abbasi
  Cleanup/optimization   |   Status:  assigned
Component:  Core (System |  Version:  3.1
  checks)|
 Severity:  Normal   |   Resolution:
 Keywords:   | Triage Stage:  Accepted
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Carlton Gibson):

 * has_patch:  0 => 1
 * type:  Bug => Cleanup/optimization
 * stage:  Unreviewed => Accepted


Comment:

 [https://github.com/django/django/pull/13766 PR]. OK, yes, using a CBV
 here is reasonable. It would be nice if the check handled that sensibly.
 Thanks.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/071.49c9ecea8ca18a7d16a4c7fa417757e1%40djangoproject.com.

[Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

2020-12-15 Thread Django

#32269: parse_duration() ISO string sign is ignored when the timedelta only has
days
--+
   Reporter:  wanaryytel  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  Utilities   |Version:  3.1
   Severity:  Normal  |   Keywords:
   Triage Stage:  Unreviewed  |  Has patch:  0
Needs documentation:  0   |Needs tests:  0
Patch needs improvement:  0   |  Easy pickings:  0
  UI/UX:  0   |
--+
 I'm pretty sure that this is a bug even though I'm not an expert on the
 ISO 8601 standard. The sign of a timedelta string will be ignored by
 `django.utils.dateparse.parse_duration` if the input string only contains
 days. Compare the following (notice the minus signs):



 {{{
 In [4]: timedelta(days=-1)
 Out[4]: datetime.timedelta(days=-1)

 In [5]: td = timedelta(days=-1)

 In [6]: duration_iso_string(td)
 Out[6]: '-P1DT00H00M00S'

 In [7]: parse_duration(duration_iso_string(td))
 Out[7]: datetime.timedelta(days=1)  # <-- Why is this 1 and not -1?

 In [8]: td = timedelta(days=-1, microseconds=1)

 In [9]: duration_iso_string(td)
 Out[9]: '-P0DT23H59M59.99S'

 In [10]: parse_duration(duration_iso_string(td))
 Out[10]: datetime.timedelta(days=-1, microseconds=1)

 }}}


 I guess the problem is in django/utils/dateparse.py line 147 that reads
 `return days + sign * datetime.timedelta(**kw)`.
 However, if `datetime.timedelta(**kw)` ends up being zero (`timedelta(0)`)
 then the sign multiplication ends up in zero, not `-0`. This is just a
 preliminary quick look though and maybe the problem is something else.

-- 
Ticket URL: 
Django 
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-updates+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-updates/053.9034ac730ad46cf96bad17e4357e1545%40djangoproject.com.

Re: [Django] #32273: Document AdminSite.unregister().

Re: [Django] #32273: Document AdminSite.unregister().

Re: [Django] #32267: Unable to unapply a branch of migrations

Re: [Django] #32273: Document AdminSite.unregister().

Re: [Django] #32267: Unable to unapply a branch of migrations

Re: [Django] #32267: Unable to unapply a branch of migrations

Re: [Django] #28333: Filter and subquery for window expressions

Re: [Django] #32273: Document AdminSite.unregister().

Re: [Django] #32273: Document AdminSite.unregister().

Re: [Django] #32273: Document AdminSite.unregister().

Re: [Django] #26602: Provide a way to manage grouping with RawSQL

Re: [Django] #26602: Provide a way to manage grouping with RawSQL

Re: [Django] #32273: Document AdminSite.unregister(). (was: Document AdminSite.unregister())

[Django] #32273: Document AdminSite.unregister()

[Django] #32272: gettext_lazy inconsistent error when nested

Re: [Django] #32270: Changing Django’s default test runner to be more robust

[Django] #32271: Documentation consistency between display views and edit views

Re: [Django] #25707: Use py.test for internal testing

Re: [Django] #25707: Use py.test for internal testing

Re: [Django] #32226: QuerySet.explain(format='json') outputs repr'd JSON on PostgreSQL

Re: [Django] #31932: Unique checking in formsets should exclude forms marked for deletion.

Re: [Django] #32270: Changing Django’s default test runner to be more robust

Re: [Django] #32263: squashmigrations produces incorrect result with a RenameModel on a ForeignKey target.

Re: [Django] #32270: Changing Django’s default test runner to be more robust

Re: [Django] #32270: Changing Django’s default test runner to be more robust

[Django] #32270: Changing Django’s default test runner to be more robust

Re: [Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

Re: [Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

Re: [Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

Re: [Django] #31007: Make it possible to change the default AutoField to BigAutoField.

Re: [Django] #32261: Log exceptions handled in Signal.send_robust()

Re: [Django] #7623: Multi-table inheritance: Add the ability create child instance from existing parent

Re: [Django] #32261: Log exceptions handled in Signal.send_robust()

Re: [Django] #32255: User.has_perm should forward **kwargs to allow more flexibility in authentication backends

Re: [Django] #32260: handler500 as a Class-based view raises SystemCheckError

[Django] #32269: parse_duration() ISO string sign is ignored when the timedelta only has days

36 matches

Site Navigation

Mail list logo

Footer information