samredai commented on pull request #3952:
URL: https://github.com/apache/iceberg/pull/3952#issuecomment-1019549170
@rdblue I meant that both the following are true in built-in types:
- calling `type` on a literal value returns the class used to instantiate
the literal
- checking the type of a literal value is done using `isinstance`, the
literal, and that same class returned by `type`
```py
def type_and_literal(literal):
python_type = type(literal) # calling type(5) returns int
new_instance = python_type(literal) # int(5) returns another literal
instance
# int is used in both isinstance and == so all of the below is True for
all built-ins
assert isinstance(new_instance, python_type)
assert type(new_instance) == python_type
assert isinstance(literal, python_type)
assert type(literal) == python_type
# Confirm the assertions for all built-in types
for literal in "foo", 1, 1.1, True, {"foo": "bar"}, ("foo", "bar", 0, 1),
b'foo':
type_and_literal(literal)
```
So there's no differentiation between a type object and a literal object or
at least that's how the api makes it seem.
> But there is no need to make the type and the literal share a class.
I see, so there could be an `IntegerType` class that can create an
`IntegerLiteral` and `IntegerLiteral` would return it's type as `IntegerType`.
Would it be useful to wrap them both in a top-level `Integer` class to match
the api in the snippet above? Or is that just getting us back to having the
logic mixed?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
