The Synapse Python client contains:
REST API Python bindings
Synapse object representation
Client logic for Python client usability
It seems like in Synapse Python client, the data objects are not the same as the Synapse DTO in other components (backend/Java client/ Web client). For example: File in the Synapse Python client contains more information than FileEntity, but less information than EntityBundle. This is one way to representing the data that comes back from Synapse REST services.
Having a core package that purely wrap Synapse REST API, and do not try to represent Synapse data adds the following benefits:
Allows higher level package to define the representation of the data (whether to follow Synapse DTO, or having different DTO that adds convenience to Python users.) Allowing party like Gate to make use of request signing, tracking creds, but doesn't tie down to the synapseclient's data representation in their Python packages. (If we decided that the object model in the current Python client doesn't make sense, it allows us to develop new package without effecting the users of the current package.)
Allows Python client developers to refactor the client and add tests without effecting the "main" Synapse Python client. The refactor can happens in multiple steps where eventually, the synapseclient can be rewritten to depends on the core package.
Separating the responsibilities of each package, making it simple to decide how to add new features in each package. The core package new features go together with Synapse backend new features (that are useful for Python client users.) The higher level package features will requires more design for usability. Preventing new REST API exposed in the client to become "public" functions in the synapse client.