jorisvandenbossche commented on PR #13454: URL: https://github.com/apache/arrow/pull/13454#issuecomment-1177603279
> that sounds to me like the question whether it will ever make sense that an `ExtensionScalar` has a state Indeed, as you mention, a scalar object will not have state (since it is just created (when needed) from the actual array). But I think there are other reasons one _could_ want to add things to the scalar class. Similarly as for example StructScalar has struct-specific methods, one could have custom methods or properties to make it easier to access certain information on the extension scalar (in addition to customizing the repr, as David mentioned) > It would be consistent to allow ExtensionScalar subclasses (you could imagine overriding `__repr__` or operators or things) though I'm not sure how useful that actually would be. Indeed, `__repr__` is another example that could be overridden, but I am also not sure how often this would be needed / useful. I suppose for debugging purposes that could actually be useful to have a custom scalar class / repr. I don't think it is needed to revert this, we can do a follow-up PR adjusting the approach if there is any agreement (eg the tests are still useful, as those should still pass (after adapting the actual tested extension subclass)). I would definitely make the method private (if we keep the approach of the method on the type class), and maybe move towards making ExtensionScalar subclassable. > Do we risk breaking backwards compatibility if we choose to change this later? We could add the subclassable ExtensionScalar class later without breaking compatibility, only at that point it would give two ways to achieve the same thing specifically for controlling `as_py()`, which is not fully ideal. -- 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]
