Any improvements on Werkzeug?

[pgjones]

Hello,

I've done quite a bit of work on Werkzeug's multipart parser, so I recognize this code :). Are there improvements that can be incorporated back in to Werkzeug?

Have you considered Starlite depending on Werkzeug? What puts you off?

Thanks

[Goldziher]

Hi there,

Well - werkzeug is huge, we dont need most of it, we just needed the multiparser, and I think we got everything else pretty much covered on our own end. I looked into Baize, which apparently has an uncredited port of the werkzeug multpart parser, and decided to simply make our own port.

Frankly, if werkzeug was modularized in a way that allowed us to simply incorporate some parts of it - I would have opted for that option for sure.

As for improvements - the code has updated typing, as you will note there isn't a single type: ignore comment in the repo, and some code has been refactored etc. to achieve this.

I also added slots, comments and simplified some stuff + added the async parser (https://github.com/starlite-api/starlite-multipart/blob/main/starlite_multipart/parser.py) and glued this to a datastructure I borrowed from Starlette (see datastructures).

Saying that, the core of the code is pretty much the same. I dont think it will be hard to extract my improvements out of it, with a simple git diff.

Can I invite you to checkout Starlite itself and perhaps join us?

[pgjones]

Thanks, I'll take a look at the typing. Does using slots show a noticeable improvement here?

Can I invite you to checkout Starlite itself and perhaps join us?

I'm too busy with Pallets and Quart :p. However it is interesting to see what others are doing. You may be interested in Werkzeug's router as well. It won't perform as well as a radix tree, but will support all the features users expect.