py-unicode-golf:

Basically, this is a code golf challenge to represent each unicode character in a weird way, in python.

More specifically, this site builds unicode characters from python's built-in functions, like: len(), str(), not(), chr(), etc. Also, it follows these rules:

• Each character must be a composition of functions — just one line.
• The innermost function must take no parameters, like not().
• Each function can only take one argument; pow(a,b) isn't allowed.

Just nested function calls.

For example, chr(max(range(ord(min(str(bytes())))))) evaluates to '&'. Try pasting it into a Python console.

To try this out, enter a character into the "type here" input (or click random for a random one).

After that, the visualize button walks you through the evaluation step by step.
The "use optimized database" toggle switches between a an optimized expression from the database, or the expression we get through the psuedo-base-3 algorithm, (read the appropriate tabs for more information).

Also, I expanded this beyond single characters:
Strings: by allowing multiple arguments, this works for entire strings too (try the strings tab).
Arbitrary code: by also allowing methods, you can compile entire Python scripts (try the exec() tab).

After you understand how the optimizations work, you can interactively view the underlying graph, that we end up running Dijkstra on: graph visualization.

Right around the whole among us era, it was gaining traction that chr(sum(range(ord(min(str(not())))))) in Python evaluates to 'ඞ', a unicode character that looks suspiciously like the among us crewmate.
This was an amazing discovery. But (unfortunately), I immediately tried to generalize it.
Could any Unicode character (there's ~160,000) be represented like this?

Since we only aim to find the Unicode value of the character and then apply chr() to it, the struggle is essentially to find a neat representation for each number 1–160,000.

And the representation MUST be neat, in a sense, since Python won't let you have more than 200 nested parentheses. It seemed like a cool challenge idk

* Technically, not is an OPERATOR in python, not a function. But since the among us guy used it I'm using it too.

The base-3 algorithm works for everything but isn't always the shortest. Besides that first algorithm, we actually found a lot of other strategies to jump between numbers.

str(bytes(2))         = "b'\x00\x00'"          len = 11
ascii(that)           = "\"b'\\x00\\x00'\""     len = 15
ascii(ascii(that))    = ...                      len = 23

Finding the shortest paths

Initially, to optimize this whole thing, I would run a script to loop over every number and check all possibilities for other numbers to reach it. For example, to see if we can find a shorter representation from the triple strategy for n=150, we would check how long it would be to do triple(best_representation_for_50). If it was an improvement, we'd keep it. It worked, but it was clunky and required running multiple passes until things stopped getting shorter.

But as I was practicing algorithms exams, I realized — we can represent this as a directed graph!

We can treat each number 0...200,000 as a node, and each strategy is just a set of edges connecting them. For example, the strategy decrement gives us a directed edge from each node n to n-1, and the triple strategy is an edge from n to 3n. In this model, every representation is simply a path through this graph.

So instead of guessing and checking backwards, we use Dijkstra's Algorithm. To do this, we create a starting node s with an edge to all the base anchors according to the base anchors' length of representation. Our goal is then reduced to finding the shortest path from s to every other node in the set {0, 1, ..., 200000}.

We can actually weight the edges differently — by length or depth — depending on what we want:

• Depth: The number of function calls in the representation.
• Length: The character count of the representation string.

For instance, each directed edge n -> n-1 from decrement (max(range(n))) has a depth of 2 and a length of 12. Additionally, we can use a mix of both to break up ties between two representations with the same depth but different lengths, or vice versa. Dijkstra guarantees that we find the absolute shortest paths from our list of strategies. :)

If you're curious about how this graph ends up looking:

I built that with Cytoscape.js: You can click a neighbor node to move to it, and walk around the graph.
Hovering over an edge will tell you what strategy it's using.
Also, you can trace the shortest path from s to any other node (int or character). And it plays a chord for each edge you move from which I think is fun :)

Full list of strategies (many are useless): strategies.py · Base anchors: anchors.py
If you can think of any I'm missing: Submit them on GithHub!

A SQLite database stores the shortest known expression for each integer from 0 to 200,000. Each entry records which strategy produced it and which parent number it was derived from. The whole database is built in one shot by running Dijkstra's algorithm over the integer graph — each strategy is a set of directed edges, and Dijkstra guarantees the globally shortest path to every node.

Current stats

Strategy breakdown

Optimization history

Each row shows the database state at a snapshot in time. Minimal = base-3 algorithm seeded with only 0 and 1. Full algorithm = base-3 with all 44 base anchors. Optimizer / deep search = the old iterative DP approach (now replaced). Dijkstra = current method — single forward-search pass, globally optimal for the strategy set. Each Dijkstra run appears twice: depth optimizes for fewest function calls (parens), length optimizes for shortest expression string — both are stored in the database.

TL;DR: this works for strings too, but we allow multiple argumets. While this tab is open, the input accepts strings as well.

So we've got single characters figured out. But what about whole strings? Python has no builtin concat(a, b). There's no way to join two strings without operators (+), methods (.join()), or syntax ([]). (at least, I really don't think so!)

The single-character system works nicely because it produces a linear AST (abstract syntax tree). Every expression is a straight line: each function wraps the previous one, flowing in one direction without any branches or merges. So, methods that take in no arguments would be better, since they at least keep the AST linear. And you can think of doing x.to_bytes() as basically just doing to_bytes(x). Just looks less nice. Multiple parameters, on the other hand, introduce branches in the AST :(

The giant integer problem

To keep the AST completely linear for a whole string, that would mean uniquely representing each string as a single number. There is a clear way to do this - write the string as a number in base 256, where each byte is a digit (basically, just write the string out as raw bytes and interpret it as an integer). For example, "hello" as a big-endian integer is about 448 billion.

But representing huge numbers with our restricted toolset doesn't scale. CPython physically cannot handle the execution:

• Memory wall: The base-3 algorithm uses len(str(list(bytes(n)))) for tripling. Python physically executes bytes(n). For billion-scale numbers, that means allocating gigabytes of RAM at runtime, resulting in an instant MemoryError.
• AST wall: Python's parser rejects expressions with more than 200 nested parentheses. Because we build numbers logarithmically, the parenthesis count grows linearly. Past ~8 characters, it hits the 200 limit and throws a SyntaxError.
• C-struct wall: Functions like len() and range() are capped at sys.maxsize (2⁶³ - 1). A 10-character string easily exceeds this, breaking any length-based math tricks.

The linear AST approach dies at ~8 characters. The numbers just get too big :(
I really doubt there's a different way to map between strings and integers in a one-to-one way.
There are other issues with this too: for example, you can't do x = b"ඞ" in Python, you get:
SyntaxError: bytes can only contain ASCII literal characters So you'd have to build the bytes one by one, which would require multiple parameters!
Also, to even decode the bytes back into a string, you'd need to specify that you are doing str(x, "u8"), which uses multiple parameters...

Forced to branch

Since massive numbers are impossible, we have to build each byte independently and pack them together. But merging independent branches requires either commas (multi-arg functions) or dot notation (methods). (And dunder methods like .__add__() are outright banned, as they are just operators in disguise).

Here are a few early attempts at merging that didn't make the cut:

• str().join([chr(a), chr(b)]) - Relies on [] list syntax. Rejected.
• str().join(Exception(chr(a), chr(b)).args) - Avoids [], but introduces both commas AND attribute access. Rejected.

The map(ord) pipeline

This led to horizontal packing using zip():

bytes(map(ord, next(zip(
  chr(b1), chr(b2), ...
)))).decode()

zip() on single-char strings produces a tuple. next() extracts it. map(ord, ...) converts back to integers, bytes() builds the byte string, and .decode() gives the final string.

This works. But passing ord as a bare reference into map() is basically cheating—it's an uncalled function identifier, not the evaluated result of a call. Plus, it still relies on a method (.decode()).

The final solution: the eval() literal pipeline

Instead of building a string and decoding it, we can build the Python source code for the string literal as raw bytes, and let eval() parse it. To get pure integers into zip() without using map(), we use reversed(range(N))—an iterator whose first element is exactly N-1.

eval(bytes(next(zip(
  reversed(range(40)),  # yields 39 (')
  reversed(range(113)), # yields 112 (p)
  reversed(range(122)), # yields 121 (y)
  reversed(range(40))   # yields 39 (')
))))

Step by step for "py":

1. repr("py") gives 'py'. Its UTF-8 bytes are 39, 112, 121, 39.
2. For each byte b, generate b+1 with the base-3 algorithm, and wrap it in reversed(range(...)). This yields b as its first element.
3. zip packs the iterators. next pulls the first element from each, creating the tuple: (39, 112, 121, 39).
4. bytes naturally consumes the tuple to build b"'py'".
5. eval accepts bytes natively in Python 3, parses the literal, and returns "py".

So yeah. We end up using multiple paramaters for zip. But no methods. And it still comes out looking pretty cool I think.

TL;DR: you can run arbitrary python code, but we allow both multiple arguments and methods. Paste it into the editor above and click "compile". Copy the output into any Python REPL or file and run it.

vars(vars().get("__builtins__")).get("exec")(b"print('payload')")

vars(vars().get(bytes(...).decode())).get(bytes(...).decode())(bytes(...))