Is this a bug or not? Hex and octal int

Moving forward
#1

I have not created an issue for this because I am curious to hear what you have to say about this.

Suppose I have a route like this:

@bp.get("/<uid:int>")
async def foobar(request, uid):

The idea being that I will query it like this:

/291

But, what if I want to query it as a hexadecimal:

/0x123

HTTP/1.1 404 Not Found

Bummer.

I feel like this should be acceptable. This happens because the router is just using regex:

REGEX_TYPES = {
    ...
    'int': (int, r'\d+'),
    ...
}

What do you think? is this a bug? Do we need more discussion? Should I make it an issue?

#2

I mean it would be pretty cool but instinct is that it would be unintuitive so that should be custom functionality.

I think we talked about url params recently in this issue, I’m left wondering is if their is a best practices for serializing non string types in a url.

#3

I don’t think it is a bug. The only problem in here is that int("0x123" [, base=10]) would not handle this value, even if the regex would allow it. int("0x123", base=16) works, so basically a “custom parser” and a matching regex pattern would be needed, exactly as I’ve provided for bool values in the referenced issue:

from sanic.router import REGEX_TYPES

def parse_b16int(value):
    value = value.lower()
    return int(value, base=16)

b16int_regexp = r("(0[xX][0-9a-fA-F]+)")

REGEX_TYPES['b16int'] = (parse_b16int, b16int_regexp)

# example handler

@app.get("/<uid:b16int>")
async def foobar(request, uid):
    # ...
2 Likes