Implements Request class in Python SDK.

[dom96]

Implements a Python native Request class based on https://developer.mozilla.org/en-US/docs/Web/API/Request/Request.

The API tries to match the Response API as closely as possible.

Test Plan

$ bazel run @workerd//src/workerd/server/tests/python:sdk_development@

[anonrig]

Without running web-platform tests (where @npaun can help), I don't think we should land this, as it is. It would be extremely hard to review how compliant we are to the spec.

Tests can be found at: https://github.com/web-platform-tests/wpt/tree/983adc74e3c0a2faa1f3e3275f45c05aa5419c53/fetch/api/request

[jasnell]

@anonrig ... given that this is a Python implementation of the class, conformance with the wpt is a bit secondary.

[anonrig]

@anonrig ... given that this is a Python implementation of the class, conformance with the wpt is a bit secondary.

Even if it's a Python implementation we might introduce a major behavior difference between the spec and our implementation that I'm afraid we might have to live with for a really long time.

[dom96]

Admittedly I don't have a lot of context on WPT, but my understanding is that they are all JS tests for the browser (or other web platform), so I don't think they can be run on a Python worker easily. But the Python code is mostly wrapping the JS anyway, so behaviour should be spec compliant in those cases, where we don't simply wrap we try to make the API more idiomatic to Python which WPT wouldn't have test coverage for.

In the long-term we'll probably want to create standards for Python on the web platform and create a test suite specifically for it, maybe that can even become part of WPT, but for now I don't think we should worry about it.

[hoodmane]

I made some comments but it generally looks good to me.

[anonrig]

Admittedly I don't have a lot of context on WPT, but my understanding is that they are all JS tests for the browser (or other web platform), so I don't think they can be run on a Python worker easily. But the Python code is mostly wrapping the JS anyway, so behaviour should be spec compliant in those cases, where we don't simply wrap we try to make the API more idiomatic to Python which WPT wouldn't have test coverage for.

In the long-term we'll probably want to create standards for Python on the web platform and create a test suite specifically for it, maybe that can even become part of WPT, but for now I don't think we should worry about it.

We can at least port the tests from WPT to Python to ensure we are compliant.

[dom96]

We can do so, but I don't think that will give us much signal. We should focus on testing where we diverge from the JS and let the existing JS tests verify that the underlying platform that we wrap is compliant.

[anonrig]

We can do so, but I don't think that will give us much signal. We should focus on testing where we diverge from the JS and let the existing JS tests verify that the underlying platform that we wrap is compliant.

For correction: I'm not blocking, but I still think we should have some of test (preferably from WPT) to validate the Request class API surface is same as the web spec dictates. It is fine if we do it later, but I strongly believe we should do it.

It is also fine not to do it, and don't be spec compliant even though we implement a web spec.

I approved the PR because it is in a good state that I'm comfortable with approving.

[danlapid]

I think we might be better off conforming to Python standards instead, how about https://requests.readthedocs.io/en/latest/api/#requests.Request ?
@hoodmane wdyt?

[anonrig]

@danlapid thats a really good solution and a path forward in my honest opinion.