Closed gnprice closed 11 months ago
Benjamin noticed in reviewing python/cpython#59763 (for bpo-37966) several points where the existing code around Unicode normalization can be improved:
on the QuickcheckResult
enum:
Maybe
makeunicodedata.py
should output this enum (with better name namespacing)
merging
test_normalization
into this file [i.e.test_unicodedata.py
] for clarity
These "boolean int" parameters could be actual
bool
s. [sc. thenfc
andk
parameters tois_normalized_quickcheck
]
None of these are super hard, so good to knock them out while we're thinking of them.
New changeset 7669cb8b21c7c9cef758609c44017c09d1ce4658 by Benjamin Peterson (Greg Price) in branch 'master':
bpo-38043: Use bool
for boolean flags on is_normalized_quickcheck. (GH-15711)
https://github.com/python/cpython/commit/7669cb8b21c7c9cef758609c44017c09d1ce4658
New changeset 1ad0c776cb640be9f19c8019bbf34bb4aba312ad by Benjamin Peterson (Greg Price) in branch 'master': bpo-38043: Move unicodedata.normalize tests into test_unicodedata. (GH-15712) https://github.com/python/cpython/commit/1ad0c776cb640be9f19c8019bbf34bb4aba312ad
This is mostly harmless but I'm concerned that we're encouraging a new Python developer to:
churn code in mostly minor ways, irrelevant to users
altering code long known to be stable, increasing the risk of introducing new bugs or performance changes
altering code in ways that are atypical for our code base (i.e. the bool type isn't a norm in our code, we mostly use int for that)
altering code without communicating with the developer who originally wrote that code (if they are still active)
consuming the time of reviewers when they could be working on known bugs, legitimate feature requests, or documentation
one-off or drive-by code alterations rather that what Guido calls "holistic refactoring" where we do clean-ups while understanding and thinking about the module as a whole and focusing on the user experience.
unfortunately, making lots of random, minor changes to a code base in a major project is an addictive experience and IMO it would be best to re-channel it early, particularly if the changes are motivated by "I like my style of coding more than that of the original contributor". Style changes are highly subjective and usually we defer to the original contributor who was closest to the problem being solved.
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields: ```python assignee = None closed_at = None created_at =
labels = ['3.9', 'expert-unicode']
title = 'small cleanups in Unicode normalization code'
updated_at =
user = 'https://github.com/gnprice'
```
bugs.python.org fields:
```python
activity =
actor = 'rhettinger'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = ['Unicode']
creation =
creator = 'Greg Price'
dependencies = []
files = []
hgrepos = []
issue_num = 38043
keywords = ['patch']
message_count = 4.0
messages = ['351229', '351373', '351600', '351740']
nosy_count = 4.0
nosy_names = ['rhettinger', 'benjamin.peterson', 'ezio.melotti', 'Greg Price']
pr_nums = ['15711', '15712', '15558']
priority = 'normal'
resolution = None
stage = 'patch review'
status = 'open'
superseder = None
type = None
url = 'https://bugs.python.org/issue38043'
versions = ['Python 3.9']
```