How will SQLAlchemy's implementation of an async extension affect this project?

[brian-farrell]

I'm curious as to how closely this project intends to conform with SQLAlchemy, and whether there is an intention to carry this project forward once SQLAlchemy has fully implemented its async extension.

I'm asking this because I ran into an issue with the Deprecation Warnings in the backends.postgres.Record class. (For the keys() and values() methods. My own code was was instantiating a new class object by unpacking the Record object.
i.e.: Class(**record). The deprecation warnings showed up during unit testing, and the cause was not readily apparent, which caused me to dig into this code, as well as into some of the SQLAlchemy code.

The Deprecation Warnings indicate that, for instance, "The Row.keys() method is deprecated to mimic SQLAlchemy behaviour, use Row._mapping.keys() instead." In my case, I refactored my code to Class(**dict(record._mapping.items())). This is acceptable, but less than optimal.

In looking through the code, I noticed several significant differences between the Databases Record class and the SQLAlchemy Row class. I'm happy to submit a Pull Request that would get the Record class to behave more like the SQLAlchemy Row class, but I am not sure if that work is desired or particularly useful, depending on the direction of this project.

If there is a desire for help with this work, please let me know, and I will be happy to contribute.

References:
Databases version: 0.5.5
SQLAlchemy version: 1.4.35
Python version: 3.9.12
OS: Debian 10.12

SQLAlchemy Row Documentation
SQLAlchemy Asynchronous I/O Documentation