I've been able to use curly brackets in regexes, though this should be clarified in the documentation

could anyone create PR?

Ans also, can anyone explain how route parsing is done ? regexps from sources are very complex. I can't prove that they don't have bugs.

I don't really know, @asvetlov wrote this part.

@asvetlov could you review this?

Doing some research, it looks like the two examples given in the original report produce invalid route errors -- e.g. the default aiohttp router refuses to build the route map. However, a route like {id:\d{4}} builds just fine.

Edit: Looks like the the ROUTE_RE pattern on the UrlDispatcher is what needs examining: r'(\{[_a-zA-Z][^{}]*(?:\{[^{}]*\}[^{}]*)*\})')

Any unmatched { or } in a routing regex will cause the build error -- the error message is a little cryptic though: ValueError: Invalid path '/'['+}']

I'm inclining to forbidding curved brackets inside embedded regexps.

I think that's a move too far, though I could be bias since I have date based routes that use the {m,n} matching. I could move the actual matching groups inside the handler, but if the router can ward off unnecessary matches for me I'd rather use that.

Maybe, we should invent some escaping? if so, any regexp can be used.

For example, in sed, regexp borders may be specified by ANY symbol. for example, /regexp/ or |regexp| or even @regexp@. Additionally, if same (as border one) symbol should be used in regexp, it should be escaped using backslash, i.e. @some\@regexp@ is exactly the same as |some@regexp|

Is there any good routing open source libraries? I would replace our own implementation with some good library

I don't think there is a reason to do that for current router. It has own flaws, but afaik it was never pretended to be very fast, optimal and featured. Just the one that works in most of cases and easy to be implemented.

Instead of making it more complicated and slower, may be take a look on possible alternatives?

P.S. As for this issue, it seems to be possible solved by working with path segments instead of whole path and few more stringy work to decouple identifier and regexp matching. Curved brackets there are just a marker to strip and go.

@fafhrd91
Few from my bookmarks:
https://github.com/c9s/r3
https://github.com/nitely/kua

Though, not sure about good.

I prefer c-library.

Aiohttp supports only simple regexps and disallow to implement own router with different matching behavior. One of issue is to match for example UUID (/[a-f0-9]{8}-[a-f0-9]{4}-4[a-f0-9]{3}-[89aAbB][a-f0-9]{3}-[a-f0-9]{12}/) which is not possible now. With introduction of f-strings very complex regex could be presented in very simple manner. For example:

uuid = "[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}"

which could be used:

test_uuid_1 = f"(?P<test_uuid_1>{uuid})"
test_uuid_2 = f"(?P<test_uuid_2>{uuid})"

router.add_route("*", f'/test/{test_uuid_1}/{test_uuid_2}', test_handler)

To recreate reverse url:

def reverse_regex(compiled: Pattern) -> str:
          reversed = []
          indexes_names = {value:key for key, value in compiled.groupindex.items()}
     
          for part in sre_parse.parse(compiled.pattern):
              code, data = part
              if code == sre_constants.SUBPATTERN:
                  index, *_ = data
                  reversed.append(f"{{{indexes_names[index]}}}")
              elif code == sre_constants.LITERAL:
                  reversed.append(chr(data))
          return "".join(reversed)

Example: '/test/(?P<test_uuid_1>[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})/(?P<test_uuid_2>[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})' reversed to '/test/{test_uuid_1}/{test_uuid_2}'. Inner capture groups are ignored.

This doesn't cover all regex possibilites, but allow to define more complex scenarios.

I prefer keeping simple regexps only