internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: falconry/falcon

Issue:
WebDAV methods not supported
Falcon defines supported HTTP methods in `falcon/constants.py`: supported are "usual" `HTTP_METHODS` and, in addition to that, `WEBDAV_METHODS`. However, only WebDAV versioning extension methods from RFC 3253 are supported, but not the "ordinary" WebDAV ones (i.e. from RFCs 2518 & 4918) like `COPY`, `LOCK`, `MKCOL`, `MOVE` etc.

Supporting only an extension, but not the core upon which that extension builds looks somewhat inconsistent.


Discussion:
working on this 

Resolving patch:
diff --git a/falcon/constants.py b/falcon/constants.py
--- a/falcon/constants.py
+++ b/falcon/constants.py
@@ -13,12 +13,19 @@
     'TRACE',
 ]
 
-# RFC 3253 methods
+# RFC 2518 and 4918 methods
 WEBDAV_METHODS = [
     'CHECKIN',
     'CHECKOUT',
+    'COPY',
+    'LOCK',
+    'MKCOL',
+    'MOVE',
+    'PROPFIND',
+    'PROPPATCH',
     'REPORT',
     'UNCHECKIN',
+    'UNLOCK'
     'UPDATE',
     'VERSION-CONTROL',
 ]
@@ -63,7 +70,6 @@
 # contrary to the RFCs.
 MEDIA_XML = 'application/xml'
 
-
 # NOTE(kgriffs): RFC 4329 recommends application/* over text/.
 # futhermore, parsers are required to respect the Unicode
 # encoding signature, if present in the document, and to default


Test patch:
diff --git a/tests/test_http_method_routing.py b/tests/test_http_method_routing.py
--- a/tests/test_http_method_routing.py
+++ b/tests/test_http_method_routing.py
@@ -17,12 +17,18 @@
     'PATCH'
 )
 
-
 WEBDAV_METHODS = (
     'CHECKIN',
     'CHECKOUT',
+    'COPY',
+    'LOCK',
+    'MKCOL',
+    'MOVE',
+    'PROPFIND',
+    'PROPPATCH',
     'REPORT',
     'UNCHECKIN',
+    'UNLOCK'
     'UPDATE',
     'VERSION-CONTROL',
 )
Repository: falconry/falcon

Issue:
Official support for CPython 3.8
CPython 3.8.0 was [released Oct 14, 2019](https://www.python.org/downloads/release/python-380/).

Make Falcon offically support CPython 3.8:
- [ ] README
- [ ] Docker images
- [ ] Docs
- [ ] Tox
- [ ] Travis
- [ ] setup.py


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -133,6 +133,7 @@ def load_description():
         'Programming Language :: Python :: 3.5',
         'Programming Language :: Python :: 3.6',
         'Programming Language :: Python :: 3.7',
+        'Programming Language :: Python :: 3.8',
     ],
     keywords='wsgi web api framework rest http cloud',
     author='Kurt Griffiths',


Test patch:
Repository: falconry/falcon

Issue:
Setup.py uses the imp module that is deprecated
while trying to run `python setup.py test` I get the warning
`DeprecationWarning: the imp module is deprecated in favour of importlib; see the module's documentation for alternative uses`

Since python 2 is no longer supported I think we can migrate to `importlib`


Discussion:
Hi :wave:,

Thanks for using Falcon. The large amount of time and effort needed to
maintain the project and develop new features is not sustainable without
the generous financial support of community members like you.

Please consider helping us secure the future of the Falcon framework with a
one-time or recurring donation.

Thank you for your support!

I can try to fix it @nZac 

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -1,5 +1,5 @@
 import glob
-import imp
+import importlib
 import io
 import os
 from os import path
@@ -10,7 +10,7 @@
 
 MYDIR = path.abspath(os.path.dirname(__file__))
 
-VERSION = imp.load_source('version', path.join('.', 'falcon', 'version.py'))
+VERSION = importlib.import_module('falcon.version')
 VERSION = VERSION.__version__
 
 REQUIRES = []


Test patch:
Repository: falconry/falcon

Issue:
Improve docs re suffixed responders
- [x] Add an example to the `suffix` kwarg docstring for `add_route()`
- [x] Add a section about suffixed responders to the [routing](https://falcon.readthedocs.io/en/stable/api/routing.html) page
Improve docs re suffixed responders
- [x] Add an example to the `suffix` kwarg docstring for `add_route()`
- [x] Add a section about suffixed responders to the [routing](https://falcon.readthedocs.io/en/stable/api/routing.html) page


Discussion:
I can take this one if you still need someone to
That would be awesome @MinesJA !
Go ahead!
I can take this one if you still need someone to
That would be awesome @MinesJA !
Go ahead!

Resolving patch:
diff --git a/falcon/app.py b/falcon/app.py
--- a/falcon/app.py
+++ b/falcon/app.py
@@ -524,7 +524,21 @@ class can use suffixed responders to distinguish requests
                 for a single item vs. a collection of those same items.
                 Another class might use a suffixed responder to handle
                 a shortlink route in addition to the regular route for the
-                resource.
+                resource. For example::
+
+                    class Baz(object):
+
+                        def on_get_foo(self, req, resp):
+                            pass
+
+                        def on_get_bar(self, req, resp):
+                            pass
+
+                    baz = Baz()
+                    app = falcon.App()
+                    app.add_route('/foo', baz, suffix='foo')
+                    app.add_route('/bar', baz, suffix='bar')
+
             compile (bool): Optional flag that can be provided when using the default
                 :class:`.CompiledRouter` to compile the routing logic on this call,
                 since it will otherwise delay compilation until the first request


Test patch:
Repository: falconry/falcon

Issue:
Fix unresolved Python object links in news fragments for 3.0
As witnessed on https://falcon.readthedocs.io/en/3.0.0b1/changes/3.0.0.html, some links to Python objects are not resolved (shown as dark bold text instead). Revise and improve the affected news fragments.

An easy way to build the preview version is:
```
tox -e towncrier
```

- [ ] Fix Towncrier fragments
- [ ] Explore Sphinx options if there is a flag to emit a warning in this scenario


Discussion:
don't we have an action gate for this?
We do, but apparently this does not generate _any_ warning in Sphinx. (Maybe there are Sphinx flags for that we could explore?)
I think sphinx should have a flag for it. I definitely saw them sometimes, but I'm far from being an expert, so I may be mistaken
Sphinx warns about broken `:ref:`s, and similar, but AFAICT not about unresolved Python links.

Resolving patch:
diff --git a/falcon/app_helpers.py b/falcon/app_helpers.py
--- a/falcon/app_helpers.py
+++ b/falcon/app_helpers.py
@@ -26,6 +26,9 @@
 def prepare_middleware(middleware, independent_middleware=False, asgi=False):
     """Check middleware interfaces and prepare the methods for request handling.
 
+    Note:
+        This method is only applicable to WSGI apps.
+
     Arguments:
         middleware (iterable): An iterable of middleware objects.
 
diff --git a/falcon/util/uri.py b/falcon/util/uri.py
--- a/falcon/util/uri.py
+++ b/falcon/util/uri.py
@@ -179,7 +179,7 @@ def encoder(uri):
 RFC 3986 defines a set of "unreserved" characters as well as a
 set of "reserved" characters used as delimiters. This function escapes
 all other "disallowed" characters by percent-encoding them unless they
-appear to have been previously encoded. For example, '%26' will not be
+appear to have been previously encoded. For example, ``'%26'`` will not be
 encoded again as it follows the format of an encoded value.
 
 Note:
@@ -203,7 +203,7 @@ def encoder(uri):
 RFC 3986 defines a set of "unreserved" characters as well as a
 set of "reserved" characters used as delimiters. Disallowed characters
 are percent-encoded in a way that models ``urllib.parse.quote(safe="~")``
-unless they appear to have been previously encoded. For example, '%26'
+unless they appear to have been previously encoded. For example, ``'%26'``
 will not be encoded again as it follows the format of an encoded value.
 
 All reserved characters are lumped together into a single set of


Test patch:
Repository: falconry/falcon

Issue:
Unannounced breaking change in renaming falcon.api_helpers
The `falcon.api_helpers` module used to contain several semi-public (not documented, but not underscored either) utilities, that people may be relying on.

During the 3.0 release cycle, `falcon.api_helpers` was renamed to `falcon.app_helpers` in order to reflect the `API` :arrow_right: `App` renaming.
However, the old name disappeared without any deprecation notice, and without any information in the 3.0 changelog notes. This is a bug.

In the spirit of SemVer, we cannot afford marking the change as deprecation in 3.0.1 either.
Let us make the name available as-is in 3.0.1, and mark as deprecated in 3.1; remove in 4.0.



Discussion:
This is used by [Sentry's Falcon integration plugin](https://docs.sentry.io/platforms/python/guides/falcon/), so we need to make sure the coming fix re-enables that plugin at least on the import level.

Resolving patch:
diff --git a/falcon/api_helpers.py b/falcon/api_helpers.py
new file mode 100644
--- /dev/null
+++ b/falcon/api_helpers.py
@@ -0,0 +1,7 @@
+from .app_helpers import * # NOQA
+
+# TODO deprecate
+# import warnings
+# from .util.deprecation import DeprecatedWarning
+
+# warnings.warn('The api_helpers module was renamed to app_helpers.', DeprecatedWarning)
diff --git a/falcon/app_helpers.py b/falcon/app_helpers.py
--- a/falcon/app_helpers.py
+++ b/falcon/app_helpers.py
@@ -22,6 +22,13 @@
 from falcon.errors import CompatibilityError
 from falcon.util.sync import _wrap_non_coroutine_unsafe
 
+__all__ = (
+    'prepare_middleware',
+    'prepare_middleware_ws',
+    'default_serialize_error',
+    'CloseableStreamIterator'
+)
+
 
 def prepare_middleware(middleware, independent_middleware=False, asgi=False):
     """Check middleware interfaces and prepare the methods for request handling.


Test patch:
diff --git a/tests/test_deprecations.py b/tests/test_deprecations.py
--- a/tests/test_deprecations.py
+++ b/tests/test_deprecations.py
@@ -1,6 +1,30 @@
-from falcon import request_helpers, stream
+import pytest
+
+from falcon import app_helpers, request_helpers, stream
+
+# from _util import has_cython
 
 
 def test_bounded_stream():
     assert request_helpers.Body is stream.Body
     assert request_helpers.BoundedStream is stream.BoundedStream
+
+
+class TestApiHelpers:
+    @pytest.mark.filterwarnings('ignore:The api_helpers')
+    def test_imports(self):
+        from falcon import api_helpers
+
+        for name in app_helpers.__all__:
+            assert getattr(api_helpers, name) is getattr(app_helpers, name)
+
+    # TODO enable test of deprecation
+    # @pytest.mark.skipif(has_cython, reason='Reloading modules on Cython does not work')
+    # def test_warning(self):
+    #     import importlib
+
+    #     from falcon.util.deprecation import DeprecatedWarning
+
+    #     with pytest.warns(DeprecatedWarning, match='The api_helpers'):
+    #         from falcon import api_helpers
+    #         importlib.reload(api_helpers)
Repository: falconry/falcon

Issue:
Deprecate falcon.api_helpers
See https://github.com/falconry/falcon/issues/1902.

Starting with 3.1, mark `falcon.api_helpers` as deprecated. We could employ module-level `__getattr__` or redecorate re-imported functions.


Discussion:
I think 3.1 is already open, so this can be done right?
Yup, I think so.

Even if we decide to do 3.0.2, we could ship that in a separate bugfix branch.

Resolving patch:
diff --git a/falcon/api_helpers.py b/falcon/api_helpers.py
--- a/falcon/api_helpers.py
+++ b/falcon/api_helpers.py
@@ -1,7 +1,6 @@
-from .app_helpers import *  # NOQA
+import warnings
 
-# TODO deprecate
-# import warnings
-# from .util.deprecation import DeprecatedWarning
+from .app_helpers import *  # NOQA
+from .util.deprecation import DeprecatedWarning
 
-# warnings.warn('The api_helpers module was renamed to app_helpers.', DeprecatedWarning)
+warnings.warn('The api_helpers module was renamed to app_helpers.', DeprecatedWarning)


Test patch:
diff --git a/tests/test_deprecations.py b/tests/test_deprecations.py
--- a/tests/test_deprecations.py
+++ b/tests/test_deprecations.py
@@ -2,7 +2,7 @@
 
 from falcon import app_helpers, request_helpers, stream
 
-# from _util import has_cython
+from _util import has_cython  # NOQA
 
 
 def test_bounded_stream():
@@ -18,17 +18,16 @@ def test_imports(self):
         for name in app_helpers.__all__:
             assert getattr(api_helpers, name) is getattr(app_helpers, name)
 
-    # TODO enable test of deprecation
-    # @pytest.mark.skipif(
-    #     has_cython,
-    #     reason='Reloading modules on Cython does not work',
-    # )
-    # def test_warning(self):
-    #     import importlib
+    @pytest.mark.skipif(
+        has_cython,
+        reason='Reloading modules on Cython does not work',
+    )
+    def test_warning(self):
+        import importlib
 
-    #     from falcon.util.deprecation import DeprecatedWarning
+        from falcon.util.deprecation import DeprecatedWarning
 
-    #     with pytest.warns(DeprecatedWarning, match='The api_helpers'):
-    #         from falcon import api_helpers
+        with pytest.warns(DeprecatedWarning, match='The api_helpers'):
+            from falcon import api_helpers
 
-    #         importlib.reload(api_helpers)
+            importlib.reload(api_helpers)
Repository: falconry/falcon

Issue:
Code listing for app.py in "look” Tutorial has a bug
In the [Serving images](https://falcon.readthedocs.io/en/stable/user/tutorial.html#serving-images) section, the code listing for `app.py` tries to import the `images` module as `import images`. I believe this should be `from look import images` or depending on one's preferences `import look.images` and refactor references to `images` as `look.images`. I prefer the former:

```python
import os

import falcon

from look import images


def create_app(image_store):
    api = falcon.API()
    api.add_route('/images', images.Collection(image_store))
    api.add_route('/images/{name}', images.Item(image_store))
    return api


def get_app():
    storage_path = os.environ.get('LOOK_STORAGE_PATH', '.')
    image_store = images.ImageStore(storage_path)
    return create_app(image_store)
```



Discussion:
Hi :wave:,

Thanks for using Falcon. The large amount of time and effort needed to
maintain the project and develop new features is not sustainable without
the generous financial support of community members like you.

Please consider helping us secure the future of the Falcon framework with a
one-time or recurring donation.

Thank you for your support!

Indeed, well spotted!
Depending on the circumstances, the current form still works, but it is not the recommended way to import inside a package.
(It's probably better to use `from .images import ImageStore, Resource` etc just to stay consistent with the rest of the WSGI tutorial.)

Resolving patch:
diff --git a/falcon/media/validators/jsonschema.py b/falcon/media/validators/jsonschema.py
--- a/falcon/media/validators/jsonschema.py
+++ b/falcon/media/validators/jsonschema.py
@@ -18,7 +18,7 @@ def validate(req_schema=None, resp_schema=None, is_async=False):
     by ``jsonschema.FormatChecker``.
 
     Note:
-        The `jsonschema`` package must be installed separately in order to use
+        The ``jsonschema`` package must be installed separately in order to use
         this decorator, as Falcon does not install it by default.
 
         See `json-schema.org <http://json-schema.org/>`_ for more


Test patch:
Repository: falconry/falcon

Issue:
Unclear which `HTTPError` was instantiated from `deprecated_args()` warnings
In Falcon 3.0.x, instantiating `HTTPError` or its subclasses with positional arguments (of course except the allowed ones) generates a `DeprecatedWarning` via the `deprecated_args()` decorator.

However, it is unclear from the warning which class/function was invoked, it just says "calls [with more than N] positional args are deprecated". Brought up by @laurent-chriqui (see the linked PR).

Ideally, as a developer, I would like the warning to read along the lines of
```
DeprecatedWarning: Calls to HTTPNotFound.__init__(...) with positional args are deprecated. Please specify them as keyword arguments instead.
```


Discussion:

Resolving patch:
diff --git a/falcon/util/deprecation.py b/falcon/util/deprecation.py
--- a/falcon/util/deprecation.py
+++ b/falcon/util/deprecation.py
@@ -85,11 +85,11 @@ def deprecated_args(*, allowed_positional, is_method=True):
     """
 
     template = (
-        'Calls with{} positional args are deprecated.'
+        'Calls to {{fn}}(...) with{arg_text} positional args are deprecated.'
         ' Please specify them as keyword arguments instead.'
     )
     text = ' more than {}'.format(allowed_positional) if allowed_positional else ''
-    warn_text = template.format(text)
+    warn_text = template.format(arg_text=text)
     if is_method:
         allowed_positional += 1
 
@@ -97,7 +97,11 @@ def deprecated_args(fn):
         @functools.wraps(fn)
         def wraps(*args, **kwargs):
             if len(args) > allowed_positional:
-                warnings.warn(warn_text, DeprecatedWarning, stacklevel=2)
+                warnings.warn(
+                    warn_text.format(fn=fn.__qualname__),
+                    DeprecatedWarning,
+                    stacklevel=2,
+                )
             return fn(*args, **kwargs)
 
         return wraps


Test patch:
diff --git a/tests/test_utils.py b/tests/test_utils.py
--- a/tests/test_utils.py
+++ b/tests/test_utils.py
@@ -1321,6 +1321,7 @@ def a_method(self, a=1, b=2):
         assert len(recwarn) == 0
         C().a_method(1, b=2)
         assert len(recwarn) == 1
+        assert 'C.a_method(...)' in str(recwarn[0].message)
 
     def test_function(self, recwarn):
         @deprecation.deprecated_args(allowed_positional=0, is_method=False)
@@ -1331,6 +1332,7 @@ def a_function(a=1, b=2):
         assert len(recwarn) == 0
         a_function(1, b=2)
         assert len(recwarn) == 1
+        assert 'a_function(...)' in str(recwarn[0].message)
 
 
 @pytest.mark.skipif(
Repository: falconry/falcon

Issue:
How to configure MultipartParseOptions?
### Discussed in https://github.com/falconry/falcon/discussions/2019

<div type='discussions-op-text'>

<sup>Originally posted by **rogerrohrbach** February 11, 2022</sup>
I'd like to set `falcon.media.multipart.MultipartParseOptions.max_body_part_count` to something other than the default value.  There's no documentation for how to do that, and I can't for the life of me figure it out.</div>


Discussion:

Resolving patch:
diff --git a/falcon/media/multipart.py b/falcon/media/multipart.py
--- a/falcon/media/multipart.py
+++ b/falcon/media/multipart.py
@@ -81,8 +81,8 @@ class BodyPart:
     """Represents a body part in a multipart form.
 
     Note:
-        `BodyPart` is meant to be instantiated directly only by the
-        `MultipartForm` parser.
+        :class:`BodyPart` is meant to be instantiated directly only by the
+        :class:`MultipartFormHandler` parser.
 
     Attributes:
         content_type (str): Value of the Content-Type header, or the multipart
@@ -506,6 +506,13 @@ class MultipartFormHandler(BaseHandler):
        over the media object.
 
     For examples on parsing the request form, see also: :ref:`multipart`.
+
+    Attributes:
+        parse_options (MultipartParseOptions):
+            Configuration options for the multipart form parser and instances
+            of :class:`~falcon.media.multipart.BodyPart` it yields.
+
+            See also: :ref:`multipart_parser_conf`.
     """
 
     _ASGI_MULTIPART_FORM = None
@@ -563,6 +570,14 @@ def serialize(self, media, content_type):
 class MultipartParseOptions:
     """Defines a set of configurable multipart form parser options.
 
+    An instance of this class is exposed via the
+    :attr:`MultipartFormHandler.parse_options
+    <falcon.media.MultipartFormHandler.parse_options>` attribute.
+    The handler's options are also passed down to every :class:`BodyPart`
+    it instantiates.
+
+    See also: :ref:`multipart_parser_conf`.
+
     Attributes:
         default_charset (str): The default character encoding for
             :meth:`text fields <BodyPart.get_text>` (default: ``utf-8``).


Test patch:
Repository: great-expectations/great_expectations

Issue:
SqlAlchemyDataset does not use the correct engine to connect if engine=None.
If `engine` is `None` but the user provides `connection_string`, `SqlAlchemyDataset.__init__` instantiates an engine but then ignores it when trying to introspect.

[Think this part right here](https://github.com/great-expectations/great_expectations/blob/master/great_expectations/dataset/sqlalchemy_dataset.py#L207) should be `self.engine`.

I'm trying to get a fix to you. Hoping to have that soon.


Discussion:
I think you're exactly right--happy to merge a PR right away, and thanks for catching that.

FYI, we've opened up a slack channel now too, so feel free to jump in there and reach the team. Open invite is available on the main project README

Resolving patch:
diff --git a/great_expectations/dataset/sqlalchemy_dataset.py b/great_expectations/dataset/sqlalchemy_dataset.py
--- a/great_expectations/dataset/sqlalchemy_dataset.py
+++ b/great_expectations/dataset/sqlalchemy_dataset.py
@@ -186,7 +186,6 @@ def __init__(self, table_name=None, engine=None, connection_string=None,
 
         if engine is not None:
             self.engine = engine
-
         else:
             try:
                 self.engine = sa.create_engine(connection_string)
@@ -204,7 +203,7 @@ def __init__(self, table_name=None, engine=None, connection_string=None,
 
 
         try:
-            insp = reflection.Inspector.from_engine(engine)
+            insp = reflection.Inspector.from_engine(self.engine)
             self.columns = insp.get_columns(table_name, schema=schema)
         except KeyError:
             # we will get a KeyError for temporary tables, since


Test patch:
diff --git a/tests/sqlalchemy_dataset/test_sqlalchemydataset.py b/tests/sqlalchemy_dataset/test_sqlalchemydataset.py
--- a/tests/sqlalchemy_dataset/test_sqlalchemydataset.py
+++ b/tests/sqlalchemy_dataset/test_sqlalchemydataset.py
@@ -96,6 +96,10 @@ def test_missing_engine_error():
         assert "Engine or connection_string must be provided." in str(err)
 
 
+def test_only_connection_string():
+    SqlAlchemyDataset('test_engine', connection_string='sqlite://')
+
+
 def test_schema_custom_sql_error():
     engine = sa.create_engine('sqlite://')
Repository: great-expectations/great_expectations

Issue:
Great Expectations is still marked as Python 2 compatible
It looks like running `pip install great_expectations==0.9.7` in a Python 2 environment starts working, before failing when pulling `marshmallow`. This is expected since this PR: https://github.com/great-expectations/great_expectations/pull/1187 but on PyPI, GE is still marked as Python 2 compatible because of the `setup.py` file.

I'm opening a PR that fixes this in a sec, but feel free to close if I'm missing something! :)


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -42,8 +42,6 @@
         'Topic :: Software Development',
         'Topic :: Software Development :: Testing',
         'License :: OSI Approved :: Apache Software License',
-        'Programming Language :: Python :: 2',
-        'Programming Language :: Python :: 2.7',
         'Programming Language :: Python :: 3',
         'Programming Language :: Python :: 3.6',
         'Programming Language :: Python :: 3.7',


Test patch: