indigophox commented on issue #34016: URL: https://github.com/apache/arrow/issues/34016#issuecomment-1453050734
The middleware is part of the application-level connection state logic (albeit a helper). Arrow is explicitly the transport below this, so the middleware logic is part of the application. Accordingly a Python app developer should have ownership of this data and behaviour, but if we wrap the C++ black box and save the FFI hop, then: How will a Python developer understand (reading the code), debug, extend, learn from, etc. the provided middleware class? This does not seem to me to provide a good developer experience for Python folks, while also creating more complicated maintenance around a dummy Python/Cython object that purports to implement the Python middleware class (which is already a defined interface) but then simply injects a native C++ class in a fairly nonstandard way. As before I can see providing this type of native-code middleware binding as an option if it's seen to be a performance bottleneck for some high TPS Arrow users' use cases, but in any other circumstance (and as a default implementation) it seems to be a detriment to the Python app developer's experience. -- 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]
