Changes between Version 20 and Version 23 of Ticket #28628
- Timestamp:
- Jan 4, 2022, 11:33:26 PM (3 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #28628
- Property Triage Stage Accepted → Ready for checkin
- Property Patch needs improvement unset
-
Ticket #28628 – Description
v20 v23 19 19 || django.db.migrations.autodetector || Used to extract the number from a migration filename. Unlikely to contain non-ASCII unless intentionally changed by a dev.\\Changing to a more restrictive regex is unlikely to hurt any users, but doesn't add value either. || 20 20 || django.db.migrations.writer || Used to sort imports in migrations, tested in tests.migrations.test_writer, see test_sorted_imports. Unclear to me what the decimal portion of the regex represents, however I don't see value in restricting to more restrictive regex. || 21 || django.forms.widgets || Used by SelectDateWidget to match a "YYYY-MM-DD" date pattern. When matched integers are cast with `int(val)` and therefore correctly processed if input was in non-ASCII Unicode decimals. \\ **Changing** to a more restrictive regexp to match HTML5 validation rules, see https://html.spec.whatwg.org/#valid-date-string||21 || django.forms.widgets || Used by SelectDateWidget to match a "YYYY-MM-DD" date pattern. When matched integers are cast with `int(val)` and therefore correctly processed if input was in non-ASCII Unicode decimals. \\\\Changing to a more restrictive regex does not seem to be of much value, because values that don't much `date_re` are passed to the `datetime.datetime.strptime()` and will be accepted anyway. || 22 22 || django.http.request || Used in split_domain_port to split a domain name and port ("www.example.com:8080"). \\The port number should be cast to an int (in which case, no problem!) - however in reality isn't currently being used in any code path, and both domain and port are returned as str. **Changed** to match other components of the regex. || 23 23 || django.template.base || Used in FilterExpression regex to match filters in templates. Arguments are passed on to individual filters. Where an int is expected, filters will cast using `int(x)` regardless so would process correctly. Using a more restrictive regex could possibly hurt users inadvertently using non-ASCII decimals in filter parameters. **Do not change**. ||