mdomke / python-ulid Goto Github PK

When using ULID in Pydantic Models within a FastAPI app with using default of None to make the field optional, the generated JSON schema is only generated with "group_id": {"type": "null"} rather than "group_id": {"anyOf": [{"type": "string"}, {"type": "null"}]}.

Pydantic Schema:

class UserUpdateRequest(BaseModel):
    first_name: str | None = Field(max_length=128, default=None)
    last_name: str | None = Field(max_length=128, default=None)
    is_active: bool | None = None
    is_admin: bool | None = None
    email: EmailStr | None = Field(max_length=128, default=None)
    password: str | None = Field(max_length=128, default=None)
    group_id: ULID | None = None
    employee_id: str | None = Field(max_length=16, default=None)

I believe this can be fixed by modifying core_schema.union_schema() in init.py to include core_schema.str_schema() like so:

    @classmethod
    def __get_pydantic_core_schema__(cls, source: Any, handler: GetCoreSchemaHandler) -> CoreSchema:
        from pydantic_core import core_schema

        return core_schema.no_info_wrap_validator_function(
            cls._pydantic_validate,
            core_schema.union_schema(
                [
                    core_schema.is_instance_schema(ULID),
                    core_schema.no_info_plain_validator_function(ULID),
                ]
            ),
            serialization=core_schema.to_string_ser_schema(
                when_used="json-unless-none",
            ),
        )

to

    @classmethod
    def __get_pydantic_core_schema__(cls, source: Any, handler: GetCoreSchemaHandler) -> CoreSchema:
        from pydantic_core import core_schema

        return core_schema.no_info_wrap_validator_function(
            cls._pydantic_validate,
            core_schema.union_schema(
                [
                    core_schema.is_instance_schema(ULID),
                    core_schema.no_info_plain_validator_function(ULID),
                    core_schema.str_schema(),
                ]
            ),
            serialization=core_schema.to_string_ser_schema(
                when_used="json-unless-none",
            ),
        )

I'm not familiar enough with Pydantic to know if this has unintended effects or not but it appears to work correctly in my app and allows for correct generation of types with a typescript generator from the generated OpenAPI JSON. Any feedback is appreciated.

Like so:

$ python -m ulid
01BTGNYV6HRNK8K8VKZASZCFPE

I guess implementing a __main__ which returns ULID.from_datetime(datetime.now()) by default.

It would ease the generation when calling from a Makefile for instance. My current alternative is the less elegant:

$ python -c 'from ulid import ULID;print(str(ULID()))'

Hello,
I see this package has support for Pydantic. I want to use the model_dump_json so I could serialize my model to json in my webserver. But I can't serialize ULID. It seems like an implementation error.

How to reproduce:

• Pip freeze:

  annotated-types==0.6.0
  pydantic==2.6.4
  pydantic_core==2.16.3
  python-ulid==2.3.0
  typing_extensions==4.10.0

• Code:

  from pydantic import BaseModel
  from pydantic_core import PydanticSerializationError
  from ulid import ULID
  
  
  class MyModel(BaseModel):
      my_id: ULID
  
  my_test = MyModel(my_id=ULID())
  
  try:
      print(f"{my_test.model_dump_json()=}")
  except PydanticSerializationError as e:
      print(f"{e=}")
  
  print(f"{my_test.model_dump()=}")

  The output would be:

  e=PydanticSerializationError(Error serializing to JSON: PydanticSerializationError: Unable to serialize unknown type: <class 'ulid.ULID'>)
  my_test.model_dump()={'my_id': ULID(01HT4RBZKNQ9DFXZQ8DW02Z27Y)}

  We can see ha model dump is supported, but not model dump json.

To verify whether a received string conforms to a valid ULID, I use the ULID.from_str method:

    try:
        return ULID.from_str(value)
    except ValueError:
        return None

Occasionally, a string of 26 characters may not be a valid ULID but may match the ULID length. I initially assumed such values would trigger a ValueError. However, it seems that any string consisting of 26 ASCII chars is accepted by from_str, resulting in ULID instances created from random data, i.e.:

>>> ULID.from_str('notavalidulidnotavalidulid')
ULID(7ZTAVFZZFZZZDQZTAVFZZFZZZD)

>>> ULID.from_str('DHCKWI*$HF$%MCNSKDW(#@_SCK')
ULID(5HCKZZZZHFZZMCNSKDZZZZZSCK)

Is this the intended behavior?

Additionally in some cases, the year part of the timestamp extracted from such values surpasses the maximum allowed by the datetime class, leading to a year is out of range error when inspecting the datetime:

>>> ULID.from_str('notavalidulidnotavalidulid').datetime
ValueError: year 10883 is out of range

>>> ULID.from_str("".join(random.choices(string.ascii_letters, k=26))).datetime
ValueError: year 10889 is out of range

>>> ULID.from_str('Z' * 26).datetime
ValueError: year 10889 is out of range

Perhaps the decoded timestamp part could be validated whether it exceeds the maximum value accepted by datetime.datetime?

Both this project and https://github.com/oklog/ulid/ build executables called ulid. The purpose of this issue is to open a discussion about possibly renaming one or both of them so that they can co-exist without workarounds.

This is motivated by the Fedora Linux case; we already have a golang-github-oklog-ulid package that installs /usr/bin/ulid, and since https://github.com/pydantic/pydantic-extra-types added a dependency on https://github.com/mdomke/python-ulid/, we are now working on a python-python-ulid package as well. A quick survey suggests that we may be the first Linux distribution to package both projects. We have some guidelines about how to deal with binary name conflicts, and approaching the relevant upstreams about a possible renaming is the first step.

Ideally, one or both projects would rename the ulid binary to something more unique, so that distributions don’t have to deal with conflicting packages or choose their own way to rename binaries. The issue #13 may or may not also be relevant, depending on the response.

Is this library maintained? Should we switch to another python ULID library? This PR has been open for almost a year without any feedback.

I'd be willing help out with maintaining this.

In the __init__ description, it says

by calling the default constructor with now arguments

instead of

by calling the default constructor with no arguments

I'm creating UUIDs with ULID for use in an application. As part of some data validation libraries in that application, these UUIDs must be RFC_4122 compliant.

However, some of the UUIDs created with ULID fail this check:

import uuid
from ulid import ULID


ulid = ULID.from_str('01GJMN8DEMHMCJKXM3MADM3J45')
uuid_value = ulid.to_uuid()
print(uuid_value.variant == uuid.RFC_4122)  # False
for uuid_created_with_uuid in (uuid.uuid1(), uuid.uuid3(uuid.NAMESPACE_DNS, 'python.org'), uuid.uuid4(),
                               uuid.uuid5(uuid.NAMESPACE_DNS, 'python.org')):
    print(uuid_created_with_uuid.variant == uuid.RFC_4122)  # True for all of them

This bit uuid_value.variant == uuid.RFC_4122 is what the data validation library does to check that a UUID is RFC_4122 compliant. It would be great to have that supported with ULID if possible.

Since

• the canonical name of the package is python-ulid
• the importable module name is ulid
• there exists a different package with canonical name ulid

there is the possibility of user confusion.

Is there a possibility of finding a truly unique name for this library in order to reduce the possibility of confusion?

The Fedora Linux packaging guidelines say:

If the importable module name and the project name do not match, users frequently end up confused. In this case, packagers SHOULD ensure that upstream is aware of the problem and (especially for new packages where renaming is feasible) strive to get the package renamed. The Python SIG is available for assistance.

https://pypi.org/project/python-ulid/#description currently:

No links back to GitHub, I had to Google to find the source code.

It is faster and without floating point. Just time.clock_gettime_ns() // 1000000 to get milliseconds.

Suggest you implement hash to allow use as a dictionary key.

I am getting the following issue using ULID as a custom type in a SqlAlchemy Model.

if key not in self._dict:
  TypeError: unhashable type: 'ULID'

Maybe add something like this?

def __hash__(self):
  return hash(self.bytes)

or

def __hash__(self):
  return int(self)

Though, that might be a longer integer than expected for a hash value?

ULID spec now calls out entropy monotonicity for subsequent ULIDs generated in the same millisecond. It wasn't immediately clear to me how to approach that here, but I spent a few minutes looking at it. Seems like an API change might be required, or globals like I wound up trying for ulid2.

Bit of discussion at ahawker/ulid#306.