add support for returning type of urllib.parse.ParseResult

[albertedwardson]

Could resolve #2

Performance impact:
Yes, using namedtuple + acquiring scheme, netloc, path, params, query, fragment at creation time reduces performance slightly, but this implementation is still significantly faster than urllib.parse.

Benchmark results:

------------------------------------------------------------------------------------------- benchmark: 6 tests ------------------------------------------------------------------------------------------
Name (time in ms)                        Min                 Max                Mean             StdDev              Median                IQR            Outliers      OPS            Rounds  Iterations
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
test_can_ada_parse                   57.3908 (1.0)       62.2309 (1.0)       58.4877 (1.0)       1.1529 (1.98)      58.0684 (1.0)       1.2236 (1.76)          1;1  17.0976 (1.0)          17           1
test_can_ada_parse_compat_str       141.7206 (2.47)     143.7067 (2.31)     142.6291 (2.44)      0.7624 (1.31)     142.4888 (2.45)      1.2296 (1.77)          2;0   7.0112 (0.41)          7           1
test_can_ada_parse_compat_bytes     164.3448 (2.86)     166.5037 (2.68)     165.4089 (2.83)      0.7394 (1.27)     165.3725 (2.85)      0.6938 (1.0)           2;0   6.0456 (0.35)          6           1
test_ada_python_parse               206.6783 (3.60)     208.2201 (3.35)     207.5097 (3.55)      0.5824 (1.0)      207.6722 (3.58)      0.7733 (1.11)          2;0   4.8191 (0.28)          5           1
test_yarl_parse                     404.2029 (7.04)     407.9433 (6.56)     405.3153 (6.93)      1.5074 (2.59)     404.9309 (6.97)      1.3562 (1.95)          1;1   2.4672 (0.14)          5           1
test_urllib_parse                   461.2165 (8.04)     532.0046 (8.55)     487.2195 (8.33)     29.4771 (50.61)    481.3736 (8.29)     45.2719 (65.25)         1;0   2.0525 (0.12)          5           1
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

TODOs:

• add ParseResultBytes
• Add tests to ensure parse_compat matches urllib.parse.urlparse results

[albertedwardson]

@TkTech pinging :^)

[TkTech]

Heyo, this was reviewed as part of v3 and I added a test for it, but as I was doing so I started having Qs about how compatible we should be. For example WHATWG includes : in the schema and ? in the path, but urllib does not. Do we just care about the structure and not the contents?

[albertedwardson]

Heyo, this was reviewed as part of v3 and I added a test for it

Oh, ok, thanks :) Reopening it then

Do we just care about the structure and not the contents?
Well, if we aim compatibility, I think we should be close to urllib.parse as close as possible

If user wants correctness and compliance to the WHATWG spec, one should not use urllib.parse in the first place.

I think this compatibility layer is for scenarios where end user wants speedups, not spec compliance

[albertedwardson]

Will add bytes type parse result and them mark as ready for review

[TkTech]

Will add bytes type parse result and them mark as ready for review

As an aside, I tried supporting the buffer interface with nanobind's ndarray and directly supporting bytes, and oddly both were significantly slower, with more time being taking by nanobind glue than I'd expect. So ParseResultBytes is great for completeness but probably not going to be great for performance until we can figure out what's going on there.

[albertedwardson]

compatibility tests fails with mismatched path part handling