Re: [Django] #33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags

[Django]

#33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags
-+-
 Reporter:  Keryn Knight |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 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 Adam Johnson):

 I would drop PYTHONOPTIMIZE from your environment, basically no one knows
 about its existence so most code assumes `assert` always works.

-- 
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.92e6c47ede8d8a7e204528be30d99f7a%40djangoproject.com.

Re: [Django] #33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags

[Django]

#33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags
-+-
 Reporter:  Keryn Knight |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 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):

 Replying to [comment:2 Jacob Walls]:
 > Keryn, your point about the second subtest of
 `test_get_version_invalid_version()` passing without testing what it
 claims to test looks valid to me. I would hazard that would be a welcome
 cleanup PR (and could ref this ticket number, even, maybe, to suggest how
 it was found).


 `get_version()` is an internal Django utility, so I'd not change this (see
 [https://github.com/django/django/pull/14114#discussion_r592669163
 comment]).

-- 
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.3f5adc5a768866255ada1f2334937d65%40djangoproject.com.

Re: [Django] #33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags

[Django]

#33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags
-+-
 Reporter:  Keryn Knight |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 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 Jacob Walls):

 Keryn, your point about the second subtest of
 `test_get_version_invalid_version()` passing without testing what it
 claims to test looks valid to me. I would hazard that would be a welcome
 cleanup PR (and could ref this ticket number, even, maybe, to suggest how
 it was found).

-- 
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.4e573f809138cdd8569812015458bef6%40djangoproject.com.

Re: [Django] #33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags

[Django]

#33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags
-+-
 Reporter:  Keryn Knight |Owner:  nobody
 Type:   |   Status:  closed
  Cleanup/optimization   |
Component:  Testing framework|  Version:  dev
 Severity:  Normal   |   Resolution:  wontfix
 Keywords:   | 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:   => wontfix


Comment:

 Raising specific errors instead of using `assert` was already discussed in
 #32508. We decided that remaining cases are valid and should remain as
 `assert`. I don't think it's worth changing other tests that fail with
 `-O`.

-- 
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.5863b301135204d4f603502b3e56fbfc%40djangoproject.com.

[Django] #33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags

[Django]

#33220: Test suite failures when using PYTHONOPTIMIZE or optimization CLI flags
+
   Reporter:  Keryn Knight  |  Owner:  nobody
   Type:  Cleanup/optimization  | Status:  new
  Component:  Testing framework |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 |
+
 I can't ''see'' any tickets for this, but searching for `assert`,
 `assertion`, `-OO`, `-O2` doesn't necessarily cover all the ways to talk
 about it, so apologies if this is covered elsewhere!

 For reasons entirely unrelated, a while back I added the following to my
 env:
 {{{
 export PYTHONDONTWRITEBYTECODE=true
 export PYTHONUNBUFFERED=true
 export PYTHONOPTIMIZE=2
 export PYTHONWARNINGS=default
 export PYTHONUTF8=1
 }}}
 Most of which have no effect, but to my consternation (because I'd
 entirely forgotten having done so!), using `./runtests.py` suddenly
 started throwing a lot of errors at me (because of `PYTHONOPTIMIZE=2`),
 the list of which follows further below.

 Most of the errors fall into either one of:
 - using `assert x ==y, 'error'` being blown away entirely (in one case,
 this cryptically results an `UnboundLocalError` instead)
 - checking `__doc__` values, which are replaced with `None`

 There are a handful of tests which fail at `-O`, and a bunch more which do
 so only when `-OO` is used. A sticky issue is that there's no great answer
 for CI:
 - running the base suite (`./runtests.py` with none of the optional deps,
 but with `-OO`) means some tests/bits won't be covered.
 - running each of the supported suite combos under normal + `-OO` is
 exhaustive for little benefit and many more suite executions.
 - not running `-OO` at all means at best, any PR will pass without
 incident (having not broken anything), but without demonstrating things
 work.

 The fix for `assert` would probably be to either `skipIf` them or fix the
 places they're used to raise an exception which is always present, like
 `ValueError` or `TypeError`, though this means changing the exceptions
 outside of `tests` in a couple of places :/
 The fix for `__doc__` is to either `skipIf` them or selectively test them
 based on `sys.flags.optimize`.
 I'd personally prefer not to `skipIf`, because many of the tests assert
 multiple things, only one of which breaks.

 At least one test is also, as far as I can tell, passing incorrectly
 currently:
 `FAIL: test_get_version_invalid_version (version.tests.VersionTests)
 (version=(3, 2, 0, 'gamma', 1, '2021031511'))`
 This is actually failing on the **length** assertion rather than the
 **alpha/beta/...** one.

 The complete list, then, first at `-O`:
 {{{
 ==
 ERROR: test_file_error_blocking (file_uploads.tests.FileUploadTests)
 The server should not block when there are upload errors (bug #8622).
 --
 Traceback (most recent call last):
   File "/django/tests/file_uploads/tests.py", line 584, in
 test_file_error_blocking
 self.client.post('/upload_errors/', post_data)
   File "/django/django/test/client.py", line 756, in post
 response = super().post(path, data=data, content_type=content_type,
 secure=secure, **extra)
   File "/django/django/test/client.py", line 407, in post
 return self.generic('POST', path, post_data, content_type,
   File "/django/django/test/client.py", line 473, in generic
 return self.request(**r)
   File "/django/django/test/client.py", line 721, in request
 self.check_exception(response)
   File "/django/django/test/client.py", line 582, in check_exception
 raise exc_value
   File "/django/django/core/handlers/exception.py", line 47, in inner
 response = get_response(request)
   File "/django/django/core/handlers/base.py", line 181, in _get_response
 response = wrapped_callback(request, *callback_args,
 **callback_kwargs)
   File "/django/tests/file_uploads/views.py", line 139, in
 file_upload_errors
 return file_upload_echo(request)
   File "/django/tests/file_uploads/views.py", line 76, in file_upload_echo
 r = {k: f.name for k, f in request.FILES.items()}
   File "/django/django/core/handlers/wsgi.py", line 116, in FILES
 self._load_post_and_files()
   File "/django/django/http/request.py", line 328, in _load_post_and_files
 self._post, self._files = self.parse_file_upload(self.META, data)
   File "/django/django/http/request.py", line 288, in parse_file_upload
 return parser.parse()
   File