The custom uuid implementation of asyncpg causes errors in my api

• asyncpg version: asyncpg==0.20.0
• PostgreSQL version: PostgreSQL 11.5 on x86_64-pc-linux-musl, compiled by gcc (Alpine 8.3.0) 8.3.0, 64-bit
• Do you use a PostgreSQL SaaS? If so, which? Can you reproduce the issue with a local PostgreSQL install?: no
• Python version: 3.8.0
• Platform: linux
• Do you use pgbouncer?: no
• Did you install asyncpg with pip?: yes
• If you built asyncpg locally, which version of Cython did you use?:
• Can the issue be reproduced under both asyncio and uvloop?: yes

I am using asyncpg to build a simple api using the library fastapi, the asyncpg implementation of uuid causes an error when I read a uuid from the database.

The uuid implementation of asynpg is not properly picked up by fastapi because they use type(obj) instead of instance(obj, uuid.UUID). Basically there is a defined list of types with their jsonification methods and asyncpg.pgproto.pgproto.UUID is not in that list. This piece of code demonstrates the issue:

import uuid
from asyncpg.pgproto import pgproto


def demonstrate_uuid_issue():
    asyncpg_uuid = pgproto.UUID("a10ff360-3b1e-4984-a26f-d3ab460bdb51")
    regular_uuid = uuid.UUID("a10ff360-3b1e-4984-a26f-d3ab460bdb51")

    print(regular_uuid == asyncpg_uuid)  # True
    print(isinstance(asyncpg_uuid, type(regular_uuid)))  # True
    print(type(asyncpg_uuid) == type(regular_uuid))  # False

The pgproto.UUID implementation does a pretty good job hiding it’s true colors but unfortunately it is still of a different type than the regular uuid.UUID. This basically throws an error in my api and forces me to use the regular uuid type like so:

await connection.set_type_codec('uuid',
                                encoder=str,
                                decoder=uuid.UUID,
                                schema='pg_catalog')

Someone already suggested to push your new uuid implementation upstream: https://github.com/MagicStack/py-pgproto/blob/484e3520d8cb0514b7596a8f9eaa80f3f7b79d0c/uuid.pyx#L324-L328 I think that would be an ideal solution to the problem. Are there any other steps I can take to resolve this issue on the asyncpg side of things?

[lowercase00]

Experiencing the same problem while dumping with orjson. Considering some libs in the wild do use type(val), would it make sense to account for third party libraries? It can be the case that those libs are doing it wrong, but perhaps making a change in only one place instead of making PR for N different libraries could help.

[elprans]

This looks to me like a fastapi bug. Using type(foo) == for type checks is almost always wrong.