Hi Guian,

I agree we should strip out those abstractions, they don't appear to be 
offering any value anymore. Go has already similarly stripped out the Transport 
and Protocol abstractions as part of the TP4 work, it makes sense for python to 
do the same.

Thanks,
Cole

On 2026/04/29 00:40:24 Guian Gumpac via dev wrote:
> Hi all,
> 
> I'd like to propose removing the AbstractBaseTransport and 
> AbstractBaseProtocol abstract base classes from gremlin-python and having the 
> driver use aiohttp directly.
> 
> 
> Background
> 
> These abstractions were introduced when gremlin-python supported multiple 
> transport backends — originally Tornado, then aiohttp. The transport/protocol 
> split mirrored Tornado's design. When Tornado was removed in favor of aiohttp 
> (discussed previously 
> https://lists.apache.org/thread/gs8mtlwdt2kdc55jskxb9q2dl0zxp5mj), the 
> abstractions remained.
> With the recent HTTP streaming work 
> (https://github.com/apache/tinkerpop/pull/3396), the protocol layer has been 
> further hollowed out and data_received() was removed from the ABC, 
> data_received_aggregate() and _decode_chunk() were removed from the 
> implementation, and the protocol now only handles request serialization and 
> writing. The receive path bypasses the protocol entirely, with 
> Connection._receive() deserializing GraphBinary directly from the transport 
> stream.
> 
> 
> Proposal
> 
> 1. Remove AbstractBaseTransport (transport.py) and AbstractBaseProtocol 
> (protocol.py)
> 2. Merge the remaining protocol write logic into Connection or directly into 
> the aiohttp transport
> 3. Have Connection use AiohttpHTTPTransport directly instead of through the 
> ABC
> 
> With aiohttp being the only transport implementation since Tornado was 
> removed, the codebase would be simplified if transport.py and protocol.py are 
> removed.
> 
> Thoughts or concerns?
> 
> Thanks,
> Guian
> 
> 

Reply via email to