Let's say I want to group a number of shortuuids into several non-overlapping partitions and use a string-based comparison that defines each partition, e.g. "aaa" <= shortuuid < "bbb". Since shortuuids are LSB-first, this isn't possible, since 0 corresponds to '2222222222222222222222' and 1 corresponds to '3222222222222222222222'. With UUIDs generated with str(uuid.uuid4()) this would be '00000000-0000-0000-0000-000000000000' for 0 and '00000000-0000-0000-0000-000000000001' for 1, which is useable for lexicographic ordering based on their integer representation. Is there a specific reason why shortuuids are LSB-first? In my case it complicates things, but are there advantages I'm ignoring?

I am attempting to convert a shortuuid generated using node.js and the Flicker base 58 alphabet:

shortid = 'apECAPA6RdHB6HB51FwsdN'
FLICKR_BASE58 = '123456789abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ'
uuid = shortuuid.ShortUUID(alphabet=FLICKR_BASE58).decode(shortid)

Unfortunately this doesn't work:

Traceback (most recent call last):
  File "<ipython-input-54-88d3ac3dd885>", line 3, in <module>
    uuid = shortuuid.ShortUUID(alphabet=FLICKR_BASE58).decode(shortid)
  File "/Users/scotts/.pyenv/versions/python38/lib/python3.8/site-packages/shortuuid/main.py", line 79, in decode
    return _uu.UUID(int=string_to_int(string, self._alphabet))
  File "/Users/scotts/.pyenv/versions/3.8.7/lib/python3.8/uuid.py", line 205, in __init__
    raise ValueError('int is out of range (need a 128-bit value)')
ValueError: int is out of range (need a 128-bit value)

It turns out that ShortUUID is sorting the alphabet before using it. This is incorrect and leads to this failure. It is possible to correctly decode the id like this:

import uuid as _uu
uuid = _uu.UUID(int=string_to_int(shortid, FLICKR_BASE58))

This is a backwards compatibility issue, so switching to an unsorted implementation will probably require a compatibility flag similar to legacy.

I'm calling shortuuid.uuid() in our unit test which run regularly and I'm seeing it generate some invalid UUIDs

Such as 5vHqLc9etTWW3AVrEJvBez.

The library seems to think this is a valid UUID

>>> shortuuid.decode("5vHqLc9etTWW3AVrEJvBez")
UUID('160427e7-f28e-40ee-9f7a-d473721488c8')

But your website does not: https://shortuuid.com/

I'm also validating this with some Elixir libraries and they are reporting that it's invalid as well.

Any help would be greatly appreciated.

Small enough UUID integers can create shorter uuid strings (21 character strings are generated ~1-2% of the time with the default alphabet). When you want a fixed length ID generated, use this PaddedShortUUID class instead.

I'm not sure how is the owner of https://shortuuid.com/, but I think this is the right place to post the request.

I'm heavly using shortuuid in the system, so I'm using https://shortuuid.com/ to convert UUID<->shortuuid. However, I'm using shortuuid v1.0.9 which has MSB-first decoding while the site use legacy decoding, so I'm using string reverse tool to get the MSB shortuuid.

It would be great if you can add a new field for MSB or a radio button to switch to MSB decoding to https://shortuuid.com/

Thanks!

I was playing with our Java UUID shortner I wrote several years ago and I decided to see what other folks are doing and came across library.

Anyway I have few critiques.

The algorithm as I understand turns the UUID into one giant 128 bit integer and divmods appending the remainder to a string. The most significant part of the UUID is appended first but the contents of the most significant has the most significant right most. For example base10 a "100" would be 001 or in base57 m3.

There are two problems to this approach:

• Sorting is no longer the same. That is if you have a list of UUIDs and list of corresponding shortuuids the sort order will not be same. This is because it follows the bit order which makes since for a generic encoding algorithm but I don't think its good for a UUID shortner.
• The algorithm is very slow on Java. Or at least this implementation which appears to be a clone of the golang https://github.com/hsingh/java-shortuuid and mostly follows the python version.

An easy replacement for the Java one is to use Bitcoin's Base58 and just change the alphabet which is originally what I used to use for UUID shortening. However Base58 divmods byte by byte and does not construct a full 128 bit integer.

Still Base58 is actually still not that fast compared to say Base64 and that is obviously because of power of 2 division.

My algorithm is almost as fast as base 64. My algorithm works by divmoding longs (64 bit numbers in java) one at a time. This is fine because a UUID is two 64 bit numbers. Secondly there are tricks divmoding 64 bit numbers super fast even if they are not powers of 2 divisors. Secondly it appends the most significant left to write to preserve lexicographical sort order. Padding is required but based on my tests only like ~2% of UUIDs have less than 22 characters (I was too lazy to do the math).

Anyway before I go set an opensource repository and try to port it to python I wanted to get some feedback. Is this a bad idea?

Heya, this change really hurts package loading times 😬 https://github.com/skorokithakis/shortuuid/blob/bcd01ceaf2419d874b8543e6d7c28e2c56da7a91/shortuuid/init.py#L13

For example, with our CLI this change has meant an increase in load time from ~0.3 seconds to ~0.8 seconds!

pkg_resources is essentially deprecated, in part, for this very reason; replaced by https://docs.python.org/3/library/importlib.metadata.html and the https://github.com/python/importlib_metadata backport

I'm using shortuuid.ShortUUID().random(length=22) for generating short-uuids in a django application on Heroku.

In already 2 cases I found a duplicated uuid. I haven't been able to reproduce whenever I want the error yet.

Thanks for shortuuid!

This PR:

• [x] updates MANIFEST.in so that the py.typed file is included in the sdist on PyPI, useful for downstream re-builders.
• [x] populates __all__ in __init__.py to avoid some mypy warnings
  • [x] allows removing the noqa comments

My understanding of UUID v5 is you can provide a namespace and a value to get a deterministic hash for that namespace + value.

I see you can provide shortuuid.uuid a name argument, and I see in the code how that maps to uuid5 in the code... but it's unclear to me what to do from there.

I see that providing the same name argument produces the same output (as expected!). How do you now combine a namespace and value to get a deterministic output, such that func(namespace, value) produces the same output every time (where namespace remains the same and value changes)?

Perhaps I'm misunderstanding something. Thanks.

I store UUIDs in my database and render to short UUIDs in the UI, especially in URLs. Last week's new releases have broken all my existing URLs because of the MSB issue.

While the legacy=True flag is available, the promise that it will go away in future is not comforting. There is absolutely nothing I can do to withdraw the thousands of existing URLs I have in circulation (as will be the case for anyone who has used ShortUUID in production).

I'd like the option to continue generating legacy short UUIDs forever. The MSB order is irrelevant anyway in a rendered string.