refactor(java): set class attribute constants#1
Merged
cesarcoatl merged 1 commit into17from Dec 6, 2025
Merged
Conversation
drop classproperty decorator
Contributor
Reviewer's GuideRefactors java.util.Locale to replace a custom classproperty-based pattern with concrete class-level constants and updates type stubs accordingly, simplifying attribute access and removing the bespoke descriptor. Class diagram for refactored java.util.Locale constantsclassDiagram
class Object
class Locale {
+str country
+str language
+Optional_str variant
+Locale CANADA
+Locale CANADA_FRENCH
+Locale CHINA
+Locale CHINESE
+Locale ENGLISH
+Locale FRANCE
+Locale FRENCH
+Locale GERMAN
+Locale GERMANY
+Locale ITALIAN
+Locale ITALY
+Locale JAPAN
+Locale JAPANESE
+Locale KOREA
+Locale KOREAN
+Locale PRC
+Locale SIMPLIFIED_CHINESE
+Locale TAIWAN
+Locale TRADITIONAL_CHINESE
+Locale UK
+Locale US
+__init__(language, country, variant)
+__str__()
+__repr__()
}
class classproperty {
-__get__(cls, owner)
}
Locale --|> Object
%% classproperty is removed in this refactor and no longer used by Locale
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Hey there - I've reviewed your changes - here's some feedback:
- Switching from
@classpropertymethods that returned newLocaleinstances on each access to shared class attributes changes semantics around mutability; if callers mutate these constants (e.g.,Locale.CANADA.language = ...), it will now be global state instead of per-access copies, so consider either makingLocaleeffectively immutable or returning defensive copies from accessors.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Switching from `@classproperty` methods that returned new `Locale` instances on each access to shared class attributes changes semantics around mutability; if callers mutate these constants (e.g., `Locale.CANADA.language = ...`), it will now be global state instead of per-access copies, so consider either making `Locale` effectively immutable or returning defensive copies from accessors.
## Individual Comments
### Comment 1
<location> `java-api-stubs/stubs/java/util/__init__.pyi:459-468` </location>
<code_context>
country: Optional[str]
language: str
variant: Optional[str]
+ CANADA: Locale
+ CANADA_FRENCH: Locale
+ CHINA: Locale
+ CHINESE: Locale
+ ENGLISH: Locale
+ FRANCE: Locale
+ FRENCH: Locale
+ GERMAN: Locale
+ GERMANY: Locale
+ ITALIAN: Locale
+ ITALY: Locale
+ JAPAN: Locale
+ JAPANESE: Locale
+ KOREA: Locale
+ KOREAN: Locale
+ PRC: Locale
+ SIMPLIFIED_CHINESE: Locale
+ TAIWAN: Locale
+ TRADITIONAL_CHINESE: Locale
+ UK: Locale
+ US: Locale
def __init__(
self, language: str, country: Optional[str] = ..., variant: Optional[str] = ...
</code_context>
<issue_to_address>
**suggestion:** These Locale constants in the stub are class-level and probably should be annotated as ClassVar[Locale] rather than instance attributes.
Because these names are declared in the class body, type checkers treat them as instance attributes, even though they’re used as class-level constants (e.g., `Locale.CANADA`). Annotating them as `ClassVar[Locale]` (e.g., `CANADA: ClassVar[Locale]`) will align the stub with actual usage and give static analysis tools the correct class-level semantics.
Suggested implementation:
```
CANADA: ClassVar[Locale]
CANADA_FRENCH: ClassVar[Locale]
CHINA: ClassVar[Locale]
CHINESE: ClassVar[Locale]
ENGLISH: ClassVar[Locale]
FRANCE: ClassVar[Locale]
FRENCH: ClassVar[Locale]
GERMAN: ClassVar[Locale]
GERMANY: ClassVar[Locale]
ITALIAN: ClassVar[Locale]
ITALY: ClassVar[Locale]
JAPAN: ClassVar[Locale]
JAPANESE: ClassVar[Locale]
KOREA: ClassVar[Locale]
KOREAN: ClassVar[Locale]
PRC: ClassVar[Locale]
SIMPLIFIED_CHINESE: ClassVar[Locale]
TAIWAN: ClassVar[Locale]
TRADITIONAL_CHINESE: ClassVar[Locale]
UK: ClassVar[Locale]
US: ClassVar[Locale]
```
Ensure `ClassVar` is imported in this stub file, e.g.:
- If there is an existing `from typing import ...` line, add `ClassVar` to it:
`from typing import Any, Optional, ClassVar` (adjust to match the actual list).
- If there is no typing import yet, add:
`from typing import Any, Optional, ClassVar`
near the top of the file, consistent with existing import style.
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+459
to
+468
| CANADA: Locale | ||
| CANADA_FRENCH: Locale | ||
| CHINA: Locale | ||
| CHINESE: Locale | ||
| ENGLISH: Locale | ||
| FRANCE: Locale | ||
| FRENCH: Locale | ||
| GERMAN: Locale | ||
| GERMANY: Locale | ||
| ITALIAN: Locale |
Contributor
There was a problem hiding this comment.
suggestion: These Locale constants in the stub are class-level and probably should be annotated as ClassVar[Locale] rather than instance attributes.
Because these names are declared in the class body, type checkers treat them as instance attributes, even though they’re used as class-level constants (e.g., Locale.CANADA). Annotating them as ClassVar[Locale] (e.g., CANADA: ClassVar[Locale]) will align the stub with actual usage and give static analysis tools the correct class-level semantics.
Suggested implementation:
CANADA: ClassVar[Locale]
CANADA_FRENCH: ClassVar[Locale]
CHINA: ClassVar[Locale]
CHINESE: ClassVar[Locale]
ENGLISH: ClassVar[Locale]
FRANCE: ClassVar[Locale]
FRENCH: ClassVar[Locale]
GERMAN: ClassVar[Locale]
GERMANY: ClassVar[Locale]
ITALIAN: ClassVar[Locale]
ITALY: ClassVar[Locale]
JAPAN: ClassVar[Locale]
JAPANESE: ClassVar[Locale]
KOREA: ClassVar[Locale]
KOREAN: ClassVar[Locale]
PRC: ClassVar[Locale]
SIMPLIFIED_CHINESE: ClassVar[Locale]
TAIWAN: ClassVar[Locale]
TRADITIONAL_CHINESE: ClassVar[Locale]
UK: ClassVar[Locale]
US: ClassVar[Locale]
Ensure ClassVar is imported in this stub file, e.g.:
-
If there is an existing
from typing import ...line, addClassVarto it:
from typing import Any, Optional, ClassVar(adjust to match the actual list). -
If there is no typing import yet, add:
from typing import Any, Optional, ClassVar
near the top of the file, consistent with existing import style.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
drop classproperty decorator
Summary by Sourcery
Replace dynamic Locale classproperty-based constants with static class attributes initialized after class definition.
Enhancements: