Reading the code I found that you're probably set up to encounter the length vs. dupes problem once your service becomes more popular.
The retry without feedback (ln 85 post()) with fixed identifier length (ln 21 new_id()) will become slow (even infinite at 62^4 ≈ 14M) and drain your randomness pool.
Minor other stuff:
Depending on how good python optimizes, you might gain some performance by defining the symbols (ln 20, new_id()) only once upfront.
Unnamed magic number (ln 22, new_id())
As mentioned in #29, you can save the end index and thus the + 1 addition (ln 22, new_id()), and then also save the allocation and assignment for n.
Since my suggested solutions turned out to all be more about generic random ID generators and not really project-specific, instead of a PR, I made the lib linked above so you can use it in all related projects if you like to, and anyone else, too. I cannot release it under WTFPL becuase of warranty and liability, but I grant you permission (in addition to those of ISC) to republish derivates of make-random-id-python under WTFPL.
Thanks for hosting this very efficient pastebin!
Reading the code I found that you're probably set up to encounter the length vs. dupes problem once your service becomes more popular. The retry without feedback (ln 85
post()) with fixed identifier length (ln 21new_id()) will become slow (even infinite at 62^4 ≈ 14M) and drain your randomness pool.Minor other stuff:
new_id()) only once upfront.new_id())+ 1addition (ln 22,new_id()), and then also save the allocation and assignment forn.Since my suggested solutions turned out to all be more about generic random ID generators and not really project-specific, instead of a PR, I made the lib linked above so you can use it in all related projects if you like to, and anyone else, too. I cannot release it under WTFPL becuase of warranty and liability, but I grant you permission (in addition to those of ISC) to republish derivates of make-random-id-python under WTFPL.