-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Manual changes of Any
union to Incomplete
in stubs folder
#9566
Changes from 1 commit
4ead531
16f7851
9c087e5
843b077
d3f6f09
f83d5d3
27b9a2b
4c692e6
9f3db1f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -17,8 +17,8 @@ class TomlEncoder(Generic[_MappingT]): | |
def __init__(self: TomlEncoder[dict[str, Any]], _dict: type[dict[str, Any]] = ..., preserve: bool = ...) -> None: ... | ||
def get_empty_table(self) -> _MappingT: ... | ||
def dump_list(self, v: Iterable[object]) -> str: ... | ||
def dump_inline_table(self, section: dict[str, Any] | Any) -> str: ... | ||
def dump_value(self, v: Any) -> str: ... | ||
def dump_inline_table(self, section: object) -> str: ... | ||
def dump_value(self, v: object) -> str: ... | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Are you sure this should be There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. From what I can see of the implementation, and from trying it, if it doesn't specifically handle an object it just stringifies it. >>> TomlEncoder().dump_inline_table(object())
'"<object object at 0x000001FF99FF85A0>"'
>>> TomlEncoder().dump_value(object())
'"<object object at 0x000001FF99FF85A0>"'
>>> TomlEncoder().dump_value(dict())
'[]'
>>> TomlEncoder().dump_value([object()])
'[ "<object object at 0x000001FF99FF85A0>",]'
>>> TomlEncoder().dump_inline_table([object()])
'[ "<object object at 0x000001FF99FF85B0>",]'
>>> TomlEncoder().dump_inline_table({"aaa": object()})
'{ aaa = "<object object at 0x000001FF99FF85A0>" }\n'
>>> TomlEncoder().dump_value({"aaa": object()})
'[ "aaa",]' There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. While technically it can handle all objects, in that it doesn't throw an exception, not all objects are correct arguments. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. And trying to represent intended values, we kindof hit the same issue as JSON. To be consistent though, how about the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. That's why Any makes sense here: the type annotation we'd ideally want isn't representable in the type system. |
||
def dump_sections(self, o: _MappingT, sup: str) -> tuple[str, _MappingT]: ... | ||
|
||
class TomlPreserveInlineDictEncoder(TomlEncoder[_MappingT]): | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This kind of looks like it's using the
| Any
trick for when the type is almost always one particular type (like we do forre.match
). If so,Any
is right.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those attributes are directly assigned from the parameters, so they should be the same.
If it's possible, and intended to be anything else than
Mark | None
, with an arbitrary type, or if it's to avoid having to check for a None mark when you know you instantiated it not-None. And that's a common use-case/pattern. That can be represented using generics. Since it's feasible within the current typing system,Incomplete
(could be done but we didn't bothered) seems preferable overAny
(can't be done, we tried)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's an argument to be made here for either permissive unions or default generics. Which both aren't part of the type system atm. I've changed the type to
Mark | None | Any
Mark | Any
and added a comment to explain.