Re: [Django] #32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings

[Django]

#32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings
-+-
 Reporter:  Ryan Siemens |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (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 Mariusz Felisiak):

 * owner:  nobody => Mariusz Felisiak
 * 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/066.29e59412164322471fcc68e10e9ab9ec%40djangoproject.com.

Re: [Django] #32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings

[Django]

#32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings
-+-
 Reporter:  Ryan Siemens |Owner:  nobody
 Type:  Bug  |   Status:  new
Component:  Database layer   |  Version:  3.1
  (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 Mariusz Felisiak):

 * cc: Claude Paroz (added)
 * status:  closed => new
 * resolution:  invalid =>
 * stage:  Unreviewed => Accepted


Comment:

 There seems to be no easy way to fix this in `mysqlclient` at least for
 now, see [discussion](https://github.com/PyMySQL/mysqlclient/issues/489).
 I'm going to add a workaround in the MySQL backend.

-- 
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.6e4bc74ad989a4867a4c0e267a50c8bf%40djangoproject.com.

Re: [Django] #32597: generic inline formsets: object has no attribute 'fk'

[Django]

#32597: generic inline formsets: object has no attribute 'fk'
-+-
 Reporter:  Éric Tanter  |Owner:  nobody
 Type:  Bug  |   Status:  closed
Component:  Forms|  Version:  2.2
 Severity:  Normal   |   Resolution:  needsinfo
 Keywords:  generic field,   | Triage Stage:
  inline formset |  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:   => needsinfo


-- 
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.4864833dac5dac0d1d3aa66c453dc9df%40djangoproject.com.

Re: [Django] #32588: Exception handling in contrib.postgres

[Django]

#32588: Exception handling in contrib.postgres
--+--
 Reporter:  Jan Holas |Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:
 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 Mariusz Felisiak):

 >  I will try but it's gonna take me a couple of days.

 Many 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/066.c06e57ec35073b196ce6ea51f826e35d%40djangoproject.com.

Re: [Django] #31487: Add support for precision argument to Round

[Django]

#31487: Add support for precision argument to Round
-+-
 Reporter:  Baptiste Mispelon|Owner:  Nick Pope
 Type:  New feature  |   Status:  closed
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  database function,   | Triage Stage:  Ready for
  round, precision, decimal places   |  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:"2f13c476abe4ba787b6cb71131818341911f43cc" 2f13c476]:
 {{{
 #!CommitTicketReference repository=""
 revision="2f13c476abe4ba787b6cb71131818341911f43cc"
 Fixed #31487 -- Added precision argument to Round().
 }}}

-- 
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/067.9c0c7936cec5d11db82d715643551dc5%40djangoproject.com.

Re: [Django] #32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings

[Django]

#32595: mysql DatabaseSchemaEditor can't `quote_value` on byte strings
-+-
 Reporter:  Ryan Siemens |Owner:  Mariusz
 |  Felisiak
 Type:  Bug  |   Status:  assigned
Component:  Database layer   |  Version:  3.1
  (models, ORM)  |
 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 Mariusz Felisiak):

 * has_patch:  0 => 1


Comment:

 [https://github.com/django/django/pull/14196 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/066.c4701a7fe6b190911cc313c8af903d88%40djangoproject.com.

Re: [Django] #31487: Add support for precision argument to Round

[Django]

#31487: Add support for precision argument to Round
-+-
 Reporter:  Baptiste Mispelon|Owner:  Nick Pope
 Type:  New feature  |   Status:  assigned
Component:  Database layer   |  Version:  dev
  (models, ORM)  |
 Severity:  Normal   |   Resolution:
 Keywords:  database function,   | Triage Stage:  Ready for
  round, precision, decimal places   |  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/067.cd5fb3c6a3c715a9b9c1e84d8813614c%40djangoproject.com.

Re: [Django] #32588: Exception handling in contrib.postgres

[Django]

#32588: Exception handling in contrib.postgres
--+--
 Reporter:  Jan Holas |Owner:  (none)
 Type:  Bug   |   Status:  closed
Component:  contrib.postgres  |  Version:
 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 Jan Holas):

 Replying to [comment:3 Mariusz Felisiak]:
 > Jan, Can you share a small project with database configuration?

 I will try but it's gonna take me a couple of days.

-- 
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.10a889a3271ef60938cc8892d7595450%40djangoproject.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 Keywords:   | 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 Chris Jerdonek:

Old description:

> Currently, there are some places in the docs, code, and code comments
> that aren't quite clear or right in the way they talk about parallel
> testing as it relates to test cases versus test case classes.
>
> For example, here in the docs:
> https://docs.djangoproject.com/en/3.1/topics/testing/advanced/#django.test.runner.DiscoverRunner
> it says:
>
> > If there are fewer test cases than configured processes, Django will
> reduce the number of processes accordingly.
>
> But it should say, "If there are fewer test case ''classes'' than
> configured processes."
>
> Similarly, this code comment:
> https://github.com/django/django/blob/41850eec99366a51f98123f7c51e5bc5a8b2798c/django/test/runner.py#L653-L654
> should say:
>
> {{{#!python
> # Since tests are distributed across processes on a per-TestCase
> # *class* basis, there's no need for more processes than TestCase
> # *classes*.
> }}}
>
> And also, `partition_suite_by_case()`:
> https://github.com/django/django/blob/41850eec99366a51f98123f7c51e5bc5a8b2798c/django/test/runner.py#L845
> should really be called something like `partition_suite_by_class()` or
> `partition_suite_by_test_class()` since it groups by `type`, and the
> docstring updated accordingly.
>
> I think this is subtle but important because, without being clear, it's
> easy for people to mistakenly think that the parallel test runner is
> parallelizing individual test cases, when it's really distributing out
> the test cases grouped by class.

New description:

 Currently, there are some places in the docs, code, and code comments that
 aren't quite clear or right in the way they talk about parallel testing as
 it relates to test cases versus test case classes.

 For example, here in the docs:
 
https://docs.djangoproject.com/en/3.1/topics/testing/advanced/#django.test.runner.DiscoverRunner
 it says:

 > If there are fewer test cases than configured processes, Django will
 reduce the number of processes accordingly.

 But it should say, "If there are fewer test case ''classes'' than
 configured processes."

 Here is similar language elsewhere in the docs:
 https://docs.djangoproject.com/en/3.1/ref/django-admin/#envvar-
 DJANGO_TEST_PROCESSES

 Similarly, this code comment:
 
https://github.com/django/django/blob/41850eec99366a51f98123f7c51e5bc5a8b2798c/django/test/runner.py#L653-L654
 should say:

 {{{#!python
 # Since tests are distributed across processes on a per-TestCase
 # *class* basis, there's no need for more processes than TestCase
 # *classes*.
 }}}

 And also, `partition_suite_by_case()`:
 
https://github.com/django/django/blob/41850eec99366a51f98123f7c51e5bc5a8b2798c/django/test/runner.py#L845
 should really be called something like `partition_suite_by_class()` or
 `partition_suite_by_test_class()` since it groups by `type`, and the
 docstring updated accordingly.

 I think this is subtle but important because, without being clear, it's
 easy for people to mistakenly think that the parallel test runner is
 parallelizing individual test cases, when it's really distributing out the
 test cases grouped by class.

--

-- 
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/067.1d729bb292d98864d966a6327bc56cc4%40djangoproject.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 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 Tim Graham):

 Maybe I have a faulty understanding of what you're trying to say, but for
 example:
 {{{ #!python
 class TestStringMethods(unittest.TestCase):
 def test_upper(self):
 self.assertEqual('foo'.upper(), 'FOO')
 }}}
 I would call `TestStringMethods` a test case and `test_upper` a test
 method. My impression is that you would call `test_upper` a test case? (If
 so, what's a test method?)

 Under my definitions, I do think the unittest docs are confusing because a
 test method seems more like an "individual unit of testing" than a test
 case.

-- 
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/067.bb982127623a03a8fb9c45c1544faf3f%40djangoproject.com.

[Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
+
   Reporter:  Chris Jerdonek|  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |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 |
+
 Currently, there are some places in the docs, code, and code comments that
 aren't quite clear or right in the way they talk about parallel testing as
 it relates to test cases versus test case classes.

 For example, here in the docs:
 
https://docs.djangoproject.com/en/3.1/topics/testing/advanced/#django.test.runner.DiscoverRunner
 it says:

 > If there are fewer test cases than configured processes, Django will
 reduce the number of processes accordingly.

 But it should say, "If there are fewer test case ''classes'' than
 configured processes."

 Similarly, this code comment:
 
https://github.com/django/django/blob/41850eec99366a51f98123f7c51e5bc5a8b2798c/django/test/runner.py#L653-L654
 should say:

 {{{#!python
 # Since tests are distributed across processes on a per-TestCase
 # *class* basis, there's no need for more processes than TestCase
 # *classes*.
 }}}

 And also, `partition_suite_by_case()`:
 
https://github.com/django/django/blob/41850eec99366a51f98123f7c51e5bc5a8b2798c/django/test/runner.py#L845
 should really be called something like `partition_suite_by_class()` or
 `partition_suite_by_test_class()` since it groups by `type`, and the
 docstring updated accordingly.

 I think this is subtle but important because, without being clear, it's
 easy for people to mistakenly think that the parallel test runner is
 parallelizing individual test cases, when it's really distributing out the
 test cases grouped by class.

-- 
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/052.246a0c09a2e624ab2ded8c8d9e8c464c%40djangoproject.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 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 Chris Jerdonek):

 It says right at the top of the page you linked to:

 > test case. A ''test case'' is the individual unit of testing. It checks
 for a specific response to a particular set of inputs. `unittest` provides
 a base class, `TestCase`, which may be used to create new test cases.

 Its definition of test suite is consistent with that, too:

 > test suite. A ''test suite'' is a collection of test cases, test suites,
 or both. It is used to aggregate tests that should be executed together.

 A test suite is made up of `TestCase` ''instances''. It's not a collection
 of test classes.

-- 
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/067.64088395f3fa2fbf5ff5c7ab7e47ecd2%40djangoproject.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 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 Chris Jerdonek):

 Also, from the "Organizing test code" section:
 https://docs.python.org/3/library/unittest.html#organizing-test-code

 > The basic building blocks of unit testing are ''test cases'' — single
 scenarios that must be set up and checked for correctness. In `unittest`,
 test cases are represented by `unittest.TestCase` instances. To make your
 own test cases you must write subclasses of TestCase or use
 FunctionTestCase.

 > ... If the test fails, an exception will be raised with an explanatory
 message, and `unittest` will identify the test case as a ''failure''.

-- 
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/067.98362f3243d8836b44be1e38eea3f685%40djangoproject.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 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 Tim Graham):

 I disagree with your definitions. In my interpretation of
 [https://docs.python.org/3/library/unittest.html unittest's docs], what
 you call is "test case class" is a "test case" and what you call a "test
 case" is a "test 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/067.22d87842fdc5edcfd9db35286312b4cc%40djangoproject.com.

Re: [Django] #31840: Add Support for Cross-Origin Opener Policy header

[Django]

#31840: Add Support for Cross-Origin Opener Policy header
-+-
 Reporter:  meggles711   |Owner:
 |  meggles711
 Type:  New feature  |   Status:  assigned
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  COOP, security,  | Triage Stage:  Ready for
  headers|  checkin
Has patch:  1|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-
Changes (by Tim Graham):

 * stage:  Accepted => Ready for checkin


Comment:

 Reviewed by Adam Johnson and myself (I didn't author most of the 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.712b98b3f4f89b9f6cfb0e9c43bed369%40djangoproject.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  new
  Cleanup/optimization   |
Component:  Testing framework|  Version:  3.1
 Severity:  Normal   |   Resolution:
 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 Chris Jerdonek):

 In your example, `TestStringMethods` is a test case class. `unittest`
 creates test cases from test methods, so test cases are in one-to-one
 correspondence with test methods. (That's why the id of a test case
 includes the method name.)

 For example, if you read the docs for `loadTestsFromModule()`:
 
https://docs.python.org/3/library/unittest.html#unittest.TestLoader.loadTestsFromModule
 it says:

 > Return a suite of all ''test cases'' (my emphasis) contained in the
 given module. This method searches ''module'' for classes derived from
 `TestCase` and creates an instance of the class for each test method
 defined for the class.

 You can view test methods as the way to define the test cases that will
 run.

-- 
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/067.dacde30b057c22fec8119a56e01c61e8%40djangoproject.com.

Re: [Django] #32601: Optimize split_domain_port() by leveraging the regex

[Django]

#32601: Optimize split_domain_port() by leveraging the regex
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
  split_domain_port,regex|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 Thanks for the pointer. That PR doesn't contain all the optimizations I
 had in mind, though. There is more pure Python that can be removed.

-- 
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/067.b4a1295e4cdc695cc1b84f27fe560389%40djangoproject.com.

Re: [Django] #32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.

[Django]

#32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  dev
 Severity:  Normal   |   Resolution:  fixed
 Keywords:  __repr__ | 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:"41850eec99366a51f98123f7c51e5bc5a8b2798c" 41850eec]:
 {{{
 #!CommitTicketReference repository=""
 revision="41850eec99366a51f98123f7c51e5bc5a8b2798c"
 Fixed #32572 -- Improved ResolverMatch.__repr__().

 When a partial function was passed as the view, the __repr__() would
 show the `func` argument as `functools.partial` which isn't very
 helpful, especially as it doesn't reveal the underlying function or
 arguments provided.
 }}}

-- 
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.2cbbef73d11a874bba0f293091c6c8b9%40djangoproject.com.

Re: [Django] #32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.

[Django]

#32572: ResolverMatch.__repr__() doesn't handle functools.partial() nicely.
-+-
 Reporter:  Nick Pope|Owner:  Nick Pope
 Type:   |   Status:  assigned
  Cleanup/optimization   |
Component:  Core (URLs)  |  Version:  dev
 Severity:  Normal   |   Resolution:
 Keywords:  __repr__ | 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):

 * 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/065.63e5c4b9a64797bb10ea96d7a0699bec%40djangoproject.com.

Re: [Django] #32601: Optimize split_domain_port() by leveraging the regex

[Django]

#32601: Optimize split_domain_port() by leveraging the regex
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
  split_domain_port,regex|  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:

 Thanks for the suggestion, this optimization has already been proposed as
 a part of #31354, see [https://github.com/django/django/pull/12844 PR]. I
 think we can keep it there and merge it before the main fix.

-- 
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/067.30724698d4fac88616e36d5fecb4b91d%40djangoproject.com.

Re: [Django] #32601: Optimize split_domain_port() by leveraging the regex

[Django]

#32601: Optimize split_domain_port() by leveraging the regex
-+-
 Reporter:  Chris Jerdonek   |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  HTTP handling|  Version:  dev
 Severity:  Normal   |   Resolution:  duplicate
 Keywords:   | Triage Stage:
  split_domain_port,regex|  Unreviewed
Has patch:  0|  Needs documentation:  0
  Needs tests:  0|  Patch needs improvement:  0
Easy pickings:  0|UI/UX:  0
-+-

Comment (by Chris Jerdonek):

 I was also going to add more tests as part of my change because currently
 there is only one test case (testing dot removal):
 
https://github.com/django/django/blob/2f13c476abe4ba787b6cb71131818341911f43cc/tests/requests/tests.py#L813-L816

-- 
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/067.3ff5183d91dea9825fba67cbfae21fb4%40djangoproject.com.

[Django] #32601: Optimize split_domain_port() by leveraging the regex

[Django]

#32601: Optimize split_domain_port() by leveraging the regex
-+-
   Reporter:  Chris  |  Owner:  nobody
  Jerdonek   |
   Type: | Status:  new
  Cleanup/optimization   |
  Component:  HTTP   |Version:  dev
  handling   |   Keywords:
   Severity:  Normal |  split_domain_port,regex
   Triage Stage: |  Has patch:  0
  Unreviewed |
Needs documentation:  0  |Needs tests:  0
Patch needs improvement:  0  |  Easy pickings:  0
  UI/UX:  0  |
-+-
 I noticed that almost all of the pure Python can be removed from Django's
 `split_domain_port()` function:
 
https://github.com/django/django/blob/2f13c476abe4ba787b6cb71131818341911f43cc/django/http/request.py#L643-L650
 by modifying the `host_validation_re` regex slightly and then accessing it
 via its groups:
 
https://github.com/django/django/blob/2f13c476abe4ba787b6cb71131818341911f43cc/django/http/request.py#L26
 Currently, the function uses the regex to determine if there's a match,
 and then uses pure Python to reparse out the components (work which the
 regex has already done for the most part).

 I can do this once accepted.

-- 
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/052.f6d039305a1a5e6d03b9d536cb2790a0%40djangoproject.com.

[Django] #32603: Changelist view in admin is missing transaction

[Django]

#32603: Changelist view in admin is missing transaction
--+
   Reporter:  Vlastimil Zíma  |  Owner:  nobody
   Type:  Bug | Status:  new
  Component:  contrib.admin   |Version:  dev
   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   |
--+
 It seems that `changelist_view` in Django admin is missing a transaction.
 Since the view may change data in database, it should be wrapped in a
 transaction to prevent unexpected states in case of errors.

-- 
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.810839b41c999288316cc36ff451aafe%40djangoproject.com.

Re: [Django] #32602: Clarify wording re: parallel testing and test case vs. test case class

[Django]

#32602: Clarify wording re: parallel testing and test case vs. test case class
--+
 Reporter:  Chris Jerdonek|Owner:  nobody
 Type:  Cleanup/optimization  |   Status:  new
Component:  Testing framework |  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 Tim Graham):

 * stage:  Unreviewed => Accepted


Comment:

 OK. I think there's confusion about this distinction across the ecosystem.
 For example, [https://docs.python-guide.org/writing/tests/ The
 Hitchhiker's Guide to Python] says, "Learn your tools and learn how to run
 a single test or a test case" (where test case seems to mean all the tests
 in a class).

 In Django's comment, I think `per-TestCase` isn't confusing because the
 casing implies a class. My guess is that most people read "test case" as
 pertaining to classes, but it seems that being more precise won't hurt.

-- 
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/067.759698b04301e13c142b4e0da52a79bb%40djangoproject.com.

[Django] #32604: File uploads larger than FILE_UPLOAD_MAX_MEMORY_SIZE get wrong unix group based on setgid

[Django]

#32604: File uploads larger than FILE_UPLOAD_MAX_MEMORY_SIZE get wrong unix 
group
based on setgid
-+
   Reporter:  Gavin Wahl |  Owner:  nobody
   Type:  Uncategorized  | Status:  new
  Component:  Uncategorized  |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  |
-+
 My MEDIA_ROOT directory has setgid set to force the group of newly created
 files. For file uploads less than FILE_UPLOAD_MAX_MEMORY_SIZE, django
 creates a file inside MEDIA_ROOT and the group is set as expected. For
 larger files, django creates a temporary file in another directory, then
 moves it to MEDIA_ROOT. Since the file was created in a temporary
 directory, it doesn't get the correct group. I expect uploaded media files
 to get the group from MEDIA_ROOT, despite whatever magic django internals
 are doing.

 This can not be fixed with FILE_UPLOAD_PERMISSIONS, because that only sets
 permissions, not the group of the file.

 The permissions form of this bug is referenced here: https://github.com
 /django-cms/django-filer/issues/1031

-- 
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/052.c147308e62fdc444a7d15edf863b47b1%40djangoproject.com.