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

Issue:
RECENT_DATE needs to be bumped
Test suite started failing, as RECENT_DATE is not recent enough:

```
[   62s]     def test_recent_date(self):
[   62s]         # This test is to make sure that the RECENT_DATE value
[   62s]         # doesn't get too far behind what the current date is.
[   62s]         # When this test fails update urllib3.connection.RECENT_DATE
[   62s]         # according to the rules defined in that file.
[   62s]         two_years = datetime.timedelta(days=365 * 2)
[   62s] >       assert RECENT_DATE > (datetime.datetime.today() - two_years).date()
[   62s] E       AssertionError: assert datetime.date(2016, 1, 1) > datetime.date(2016, 1, 1)
[   62s] E        +  where datetime.date(2016, 1, 1) = <built-in method date of datetime.datetime object at 0x7fb6899be198>()
[   62s] E        +    where <built-in method date of datetime.datetime object at 0x7fb6899be198> = (datetime.datetime(2017, 12, 31, 10, 16, 14, 472906) - datetime.timedelta(730)).date
[   62s] E        +      where datetime.datetime(2017, 12, 31, 10, 16, 14, 472906) = <built-in method today of type object at 0x7fb68e948d20>()
[   62s] E        +        where <built-in method today of type object at 0x7fb68e948d20> = <class 'datetime.datetime'>.today
[   62s] E        +          where <class 'datetime.datetime'> = datetime.datetime
```


Discussion:
https://github.com/shazow/urllib3/blob/da05fe2497e18b367cab159195a1ace9a74119e3/urllib3/connection.py#L59..L62

Resolving patch:
diff --git a/urllib3/connection.py b/urllib3/connection.py
--- a/urllib3/connection.py
+++ b/urllib3/connection.py
@@ -56,10 +56,11 @@ class ConnectionError(Exception):
     'https': 443,
 }
 
-# When updating RECENT_DATE, move it to
-# within two years of the current date, and no
-# earlier than 6 months ago.
-RECENT_DATE = datetime.date(2016, 1, 1)
+# When updating RECENT_DATE, move it to within two years of the current date,
+# and not less than 6 months ago.
+# Example: if Today is 2018-01-01, then RECENT_DATE should be any date on or
+# after 2016-01-01 (today - 2 years) AND before 2017-07-01 (today - 6 months)
+RECENT_DATE = datetime.date(2017, 6, 30)
 
 
 class DummyConnection(object):


Test patch:
Repository: urllib3/urllib3

Issue:
Custom LifoQueue
During some profiling, I found out one slow operation is `self.pool.get()` in `_get_conn()`.

In urllib3, in `connectionpool.ConnectionPool`, it uses `LifoQueue`:
https://github.com/shazow/urllib3/blob/master/urllib3/connectionpool.py#L65

Which uses a list instead of a much faster deque:
https://github.com/python/cpython/blob/master/Lib/queue.py#L237

My suggestion is one could use a custom LifoQueue that uses the underlying deque, as:
```python
class LifoQueue(Queue):
    def _get(self):
        return self.queue.pop()
```



Discussion:
Can you provide a benchmark of the two implementations side-by-side to demonstrate the performance difference, please?
As a further suggestion, there doesn't seem to be any reason the standard library can't use a deque instead of a list. I suggest if there is a performance advantage in this change that you propose the change upstream as well.
I came across this issue today, and looking around found this benchmark and it seems there are real gains in the switch https://stackoverflow.com/a/20330499/454332

Resolving patch:
diff --git a/urllib3/connectionpool.py b/urllib3/connectionpool.py
--- a/urllib3/connectionpool.py
+++ b/urllib3/connectionpool.py
@@ -41,11 +41,7 @@
 from .util.retry import Retry
 from .util.timeout import Timeout
 from .util.url import get_host, Url
-
-
-if six.PY2:
-    # Queue is imported for side effects on MS Windows
-    import Queue as _unused_module_Queue  # noqa: F401
+from .util.queue import LifoQueue
 
 xrange = six.moves.xrange
 
@@ -62,7 +58,7 @@ class ConnectionPool(object):
     """
 
     scheme = None
-    QueueCls = queue.LifoQueue
+    QueueCls = LifoQueue
 
     def __init__(self, host, port=None):
         if not host:
diff --git a/urllib3/util/queue.py b/urllib3/util/queue.py
new file mode 100644
--- /dev/null
+++ b/urllib3/util/queue.py
@@ -0,0 +1,21 @@
+import collections
+from ..packages import six
+from ..packages.six.moves import queue
+
+if six.PY2:
+    # Queue is imported for side effects on MS Windows. See issue #229.
+    import Queue as _unused_module_Queue  # noqa: F401
+
+
+class LifoQueue(queue.Queue):
+    def _init(self, _):
+        self.queue = collections.deque()
+
+    def _qsize(self, len=len):
+        return len(self.queue)
+
+    def _put(self, item):
+        self.queue.append(item)
+
+    def _get(self):
+        return self.queue.pop()


Test patch:
Repository: urllib3/urllib3

Issue:
Can no longer create a context with specific ciphers
The recent change to remove support for Python 2.6 has made it so that the "ciphers" parameter of the create_urllib3_context function in ssl_.py no longer has any effect.  The parameter is unused for the rest of the function.

This was working properly in Python 3.6, so I don't know why it was tagged as being Python 2.6 specific.



Discussion:
I see what happened here, the branch for that piece of code was incorrectly marked as being for Python 2.6 only but actually was for Python 2.6+. See: https://github.com/urllib3/urllib3/commit/cb2159878f8b47c5b4bc6d159ae2857b85c0a197#diff-7c9a38cd64066636d0e73a2449a28640L294

Resolving patch:
diff --git a/src/urllib3/util/ssl_.py b/src/urllib3/util/ssl_.py
--- a/src/urllib3/util/ssl_.py
+++ b/src/urllib3/util/ssl_.py
@@ -263,6 +263,8 @@ def create_urllib3_context(ssl_version=None, cert_reqs=None,
     """
     context = SSLContext(ssl_version or ssl.PROTOCOL_SSLv23)
 
+    context.set_ciphers(ciphers or DEFAULT_CIPHERS)
+
     # Setting the default here, as we may have no ssl module on import
     cert_reqs = ssl.CERT_REQUIRED if cert_reqs is None else cert_reqs
 


Test patch:
diff --git a/test/test_ssl.py b/test/test_ssl.py
--- a/test/test_ssl.py
+++ b/test/test_ssl.py
@@ -70,3 +70,21 @@ def test_sni_missing_warning_with_ip_addresses(monkeypatch, has_sni, server_host
         assert SNIMissingWarning in warnings
     else:
         assert warn.call_count == 0
+
+
+@pytest.mark.parametrize(
+    ["ciphers", "expected_ciphers"],
+    [(None, ssl_.DEFAULT_CIPHERS),
+     ("ECDH+AESGCM:ECDH+CHACHA20", "ECDH+AESGCM:ECDH+CHACHA20")]
+)
+def test_create_urllib3_context_set_ciphers(monkeypatch, ciphers, expected_ciphers):
+
+    context = mock.create_autospec(ssl_.SSLContext)
+    context.set_ciphers = mock.Mock()
+    context.options = 0
+    monkeypatch.setattr(ssl_, "SSLContext", lambda *_, **__: context)
+
+    assert ssl_.create_urllib3_context(ciphers=ciphers) is context
+
+    assert context.set_ciphers.call_count == 1
+    assert context.set_ciphers.call_args == mock.call(expected_ciphers)
Repository: urllib3/urllib3

Issue:
setup.py lacks appropriate metadata for differing python versions
Please see this issue for the full context: https://github.com/NixOS/nixpkgs/issues/46318

Basically, it appears the METADATA in the resulting installation differs depending on the installation method.

I've done some minimal patching to `setup.py` to include the same `python_version` constraints that appear in `setup.cfg` and it appears to fix the issues with regards to METADATA.

However, I'm not very experienced in python packaging and am surprised that no one else has run into this issue before me.

Can anyone confirm that there is a mismatch here and that adding additional constraints to `setup.py` would be appropriate? I'll go ahead and get a PR together in the meantime.


Discussion:
There definitely looks to be a discrepency between `setup.cfg` and `setup.py`. I will look into this more, thanks for reporting this.
Any update? I can try my hand at a patch...
You're free to do so if you'd like. I'm saving this issue as part of a larger set of packaging updates I'm going to be working on.

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -65,11 +65,11 @@
       test_suite='test',
       extras_require={
           'secure': [
-              'pyOpenSSL >= 0.14',
+              'pyOpenSSL>=0.14',
               'cryptography>=1.3.4',
               'idna>=2.0.0',
               'certifi',
-              "ipaddress",
+              "ipaddress; python_version=='2.7'",
           ],
           'socks': [
               'PySocks>=1.5.6,<2.0,!=1.5.7',


Test patch:
Repository: urllib3/urllib3

Issue:
Update our SOCKS documentation
- `socks4a://` is useless, all DNS queries are resolved client-side for SOCKS4.
- `socks5://` should have a warning about DNS queries being resolved client-side and that `socks5h://` is recommended for secure use (Should have been the default on our end).
- PySocks supports IPv6 connections to the SOCKS proxy.
- Need to check all our other assumptions in those docs.


Discussion:

Resolving patch:
diff --git a/src/urllib3/contrib/socks.py b/src/urllib3/contrib/socks.py
--- a/src/urllib3/contrib/socks.py
+++ b/src/urllib3/contrib/socks.py
@@ -1,25 +1,38 @@
 # -*- coding: utf-8 -*-
 """
 This module contains provisional support for SOCKS proxies from within
-urllib3. This module supports SOCKS4 (specifically the SOCKS4A variant) and
+urllib3. This module supports SOCKS4, SOCKS4A (an extension of SOCKS4), and
 SOCKS5. To enable its functionality, either install PySocks or install this
 module with the ``socks`` extra.
 
 The SOCKS implementation supports the full range of urllib3 features. It also
 supports the following SOCKS features:
 
-- SOCKS4
-- SOCKS4a
-- SOCKS5
+- SOCKS4A (``proxy_url='socks4a://...``)
+- SOCKS4 (``proxy_url='socks4://...``)
+- SOCKS5 with remote DNS (``proxy_url='socks5h://...``)
+- SOCKS5 with local DNS (``proxy_url='socks5://...``)
 - Usernames and passwords for the SOCKS proxy
 
-Known Limitations:
+ .. note::
+    It is recommended to use ``socks5h://`` or ``socks4a://`` schemes in
+    your ``proxy_url`` to ensure that DNS resolution is done from the remote
+    server instead of client-side when connecting to a domain name.
+
+SOCKS4 supports IPv4 and domain names with the SOCKS4A extension. SOCKS5
+supports IPv4, IPv6, and domain names.
+
+When connecting to a SOCKS4 proxy the ``username`` portion of the ``proxy_url``
+will be sent as the ``userid`` section of the SOCKS request::
+
+    proxy_url="socks4a://<userid>@proxy-host"
+
+When connecting to a SOCKS5 proxy the ``username`` and ``password`` portion
+of the ``proxy_url`` will be sent as the username/password to authenticate
+with the proxy::
+
+    proxy_url="socks5h://<username>:<password>@proxy-host"
 
-- Currently PySocks does not support contacting remote websites via literal
-  IPv6 addresses. Any such connection attempt will fail. You must use a domain
-  name.
-- Currently PySocks does not support IPv6 connections to the SOCKS proxy. Any
-  such connection attempt will fail.
 """
 from __future__ import absolute_import
 


Test patch:
Repository: urllib3/urllib3

Issue:
Upgrade packaged rfc3986
Upgrade to v1.3.2


Discussion:

Resolving patch:
diff --git a/src/urllib3/packages/rfc3986/__init__.py b/src/urllib3/packages/rfc3986/__init__.py
--- a/src/urllib3/packages/rfc3986/__init__.py
+++ b/src/urllib3/packages/rfc3986/__init__.py
@@ -36,7 +36,7 @@
 __author_email__ = 'graffatcolmingov@gmail.com'
 __license__ = 'Apache v2.0'
 __copyright__ = 'Copyright 2014 Rackspace'
-__version__ = '1.3.1'
+__version__ = '1.3.2'
 
 __all__ = (
     'ParseResult',
diff --git a/src/urllib3/packages/rfc3986/misc.py b/src/urllib3/packages/rfc3986/misc.py
--- a/src/urllib3/packages/rfc3986/misc.py
+++ b/src/urllib3/packages/rfc3986/misc.py
@@ -110,28 +110,6 @@
              abnf_regexp.PORT_RE), re.UNICODE)
 
 
-IHOST_MATCHER = re.compile('^' + abnf_regexp.IHOST_RE + '$', re.UNICODE)
-
-IPATH_MATCHER = re.compile(abnf_regexp.IPATH_RE, re.UNICODE)
-
-IQUERY_MATCHER = re.compile(abnf_regexp.IQUERY_RE, re.UNICODE)
-
-IFRAGMENT_MATCHER = re.compile(abnf_regexp.IFRAGMENT_RE, re.UNICODE)
-
-
-RELATIVE_IRI_MATCHER = re.compile(u'^%s(?:\\?%s)?(?:%s)?$' % (
-    abnf_regexp.IRELATIVE_PART_RE,
-    abnf_regexp.IQUERY_RE,
-    abnf_regexp.IFRAGMENT_RE
-), re.UNICODE)
-
-ABSOLUTE_IRI_MATCHER = re.compile(u'^%s:%s(?:\\?%s)?$' % (
-    abnf_regexp.COMPONENT_PATTERN_DICT['scheme'],
-    abnf_regexp.IHIER_PART_RE,
-    abnf_regexp.IQUERY_RE[1:-1]
-), re.UNICODE)
-
-
 # Path merger as defined in http://tools.ietf.org/html/rfc3986#section-5.2.3
 def merge_paths(base_uri, relative_path):
     """Merge a base URI's path with a relative URI's path."""


Test patch:
Repository: urllib3/urllib3

Issue:
Add explicit support for Python 3.9
Start testing on 3.9, add testing on Python 3.8 where there is finally support.


Discussion:

Resolving patch:
diff --git a/noxfile.py b/noxfile.py
--- a/noxfile.py
+++ b/noxfile.py
@@ -39,7 +39,7 @@ def tests_impl(session, extras="socks,secure,brotli"):
     session.run("coverage", "report", "-m")
 
 
-@nox.session(python=["2.7", "3.5", "3.6", "3.7", "3.8", "pypy"])
+@nox.session(python=["2.7", "3.5", "3.6", "3.7", "3.8", "3.9", "pypy"])
 def test(session):
     tests_impl(session)
 
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -41,6 +41,7 @@
         "Programming Language :: Python :: 3.6",
         "Programming Language :: Python :: 3.7",
         "Programming Language :: Python :: 3.8",
+        "Programming Language :: Python :: 3.9",
         "Programming Language :: Python :: Implementation :: CPython",
         "Programming Language :: Python :: Implementation :: PyPy",
         "Topic :: Internet :: WWW/HTTP",


Test patch:
Repository: urllib3/urllib3

Issue:
iterating a closed response improperly produces data
Consider the following script:
```
import urllib3

http = urllib3.PoolManager()
resp = http.request("GET", "https://www.python.org")
resp.close()
for d in resp:
    print(repr(d))
```
With urllib3 1.25.7, this program prints `b''`. With urllib3 1.24.3, one sees:
```
Traceback (most recent call last):
  File "example.py", line 6, in <module>
    for d in resp:
ValueError: I/O operation on closed file.
```
The latter is in line with what I expect.


Discussion:
Great catch, the iteration behavior is new and hasn't been flexed enough. Would you be willing to submit a patch to fix this issue?

Resolving patch:
diff --git a/src/urllib3/response.py b/src/urllib3/response.py
--- a/src/urllib3/response.py
+++ b/src/urllib3/response.py
@@ -792,7 +792,7 @@ def geturl(self):
             return self._request_url
 
     def __iter__(self):
-        buffer = [b""]
+        buffer = []
         for chunk in self.stream(decode_content=True):
             if b"\n" in chunk:
                 chunk = chunk.split(b"\n")


Test patch:
diff --git a/test/test_response.py b/test/test_response.py
--- a/test/test_response.py
+++ b/test/test_response.py
@@ -859,8 +859,9 @@ def test_geturl_retries(self):
     @pytest.mark.parametrize(
         ["payload", "expected_stream"],
         [
-            (b"", [b""]),
+            (b"", []),
             (b"\n", [b"\n"]),
+            (b"\n\n\n", [b"\n", b"\n", b"\n"]),
             (b"abc\ndef", [b"abc\n", b"def"]),
             (b"Hello\nworld\n\n\n!", [b"Hello\n", b"world\n", b"\n", b"\n", b"!"]),
         ],
Repository: urllib3/urllib3

Issue:
Raw HTML in README.rst causing problems with uploading dists
See: https://travis-ci.org/github/urllib3/urllib3/builds/675807537

For now I've manually uploaded the dists.

We should strip this section from our `long_description` field and maybe run `twine check` within our CI to make sure we don't run into this issue on release time in the future.


Discussion:
Not sure if its related, but just in case  - having just run a poetry lock on dependencies it picked up the new version 1.25.9 - but that new version hasn't been picked up/appeared on our pypi mirror.  
@reillys Probably not related, I released 1.25.9 about an hour ago you mirror may be out of date?
@sethmlarson quite likely, will check again our end, just saw the issue here and thought worth a mention just in case  :)

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -16,7 +16,18 @@
 
 
 with codecs.open("README.rst", encoding="utf-8") as fp:
-    readme = fp.read()
+    # remove reST raw directive from README
+    mode = None
+    lines = []
+    for line in fp:
+        if line.startswith(".. raw"):
+            mode = "ignore_raw"
+        elif line == "\n":
+            mode = None
+
+        if mode != "ignore_raw":
+            lines.append(line)
+    readme = "".join(lines)
 
 with codecs.open("CHANGES.rst", encoding="utf-8") as fp:
     changes = fp.read()
@@ -28,6 +39,7 @@
     version=version,
     description="HTTP library with thread-safe connection pooling, file post, and more.",
     long_description=u"\n\n".join([readme, changes]),
+    long_description_content_type="text/x-rst",
     classifiers=[
         "Environment :: Web Environment",
         "Intended Audience :: Developers",


Test patch:
Repository: urllib3/urllib3

Issue:
Established connections are replaced by None values
Hello!

When pool is in blocking mode, there is no connections in pool, and getting connection from pool is timed out.

https://github.com/urllib3/urllib3/pull/1759


Discussion:

Resolving patch:
diff --git a/src/urllib3/connectionpool.py b/src/urllib3/connectionpool.py
--- a/src/urllib3/connectionpool.py
+++ b/src/urllib3/connectionpool.py
@@ -698,9 +698,11 @@ def urlopen(
             # Everything went great!
             clean_exit = True
 
-        except queue.Empty:
-            # Timed out by queue.
-            raise EmptyPoolError(self, "No pool connections are available.")
+        except EmptyPoolError:
+            # Didn't get a connection from the pool, no need to clean up
+            clean_exit = True
+            release_this_conn = False
+            raise
 
         except (
             TimeoutError,


Test patch:
diff --git a/test/test_connectionpool.py b/test/test_connectionpool.py
--- a/test/test_connectionpool.py
+++ b/test/test_connectionpool.py
@@ -2,6 +2,7 @@
 
 import ssl
 import pytest
+from mock import Mock
 
 from urllib3.connectionpool import (
     connection_from_url,
@@ -279,7 +280,6 @@ def _test(exception, expect, reason=None):
 
             # Make sure that all of the exceptions return the connection
             # to the pool
-            _test(Empty, EmptyPoolError)
             _test(BaseSSLError, MaxRetryError, SSLError)
             _test(CertificateError, MaxRetryError, SSLError)
 
@@ -292,6 +292,15 @@ def _test(exception, expect, reason=None):
                 pool.request("GET", "/", retries=1, pool_timeout=SHORT_TIMEOUT)
             assert pool.pool.qsize() == POOL_SIZE
 
+    def test_empty_does_not_put_conn(self):
+        """Do not put None back in the pool if the pool was empty"""
+
+        with HTTPConnectionPool(host="localhost", maxsize=1, block=True) as pool:
+            pool._get_conn = Mock(side_effect=EmptyPoolError(pool, "Pool is empty"))
+            pool._put_conn = Mock(side_effect=AssertionError("Unexpected _put_conn"))
+            with pytest.raises(EmptyPoolError):
+                pool.request("GET", "/")
+
     def test_assert_same_host(self):
         with connection_from_url("http://google.com:80") as c:
             with pytest.raises(HostChangedError):
Repository: urllib3/urllib3

Issue:
Add additional documentation for HTTPSConnection parameters
I'm not sure if this is intentional or not, but the reference doc for connection objects ( https://urllib3.readthedocs.io/en/latest/reference/index.html#urllib3.connection.VerifiedHTTPSConnection ) seems a little bit spare on details about the parameters accepted.

In particular, I was looking at using `server_hostname`, and I didn't find it anywhere in the reference doc.
I did eventually find it (I assume with the same meaning) documented on [this utility function](https://urllib3.readthedocs.io/en/latest/reference/urllib3.util.html#urllib3.util.ssl_wrap_socket).

Coming to these docs having very rarely needed to work directly with urllib3 (it's usually the transport used by some higher-level library I'm using, like `requests`), it seemed like the docs for the connection object were missing bits. If I were to open a PR adding a line to the docstring for each parameter, would it be welcome? Or are these params meant to be covered elsewhere in the docs?


Discussion:
`HTTPSConnection` is a thin wrapper over `util.ssl_wrap_socket`, which creates a `SSLContext`, loads certificates, and wraps the socket. All the accepted parameters are thoroughly documented in https://docs.python.org/3/library/ssl.html, which is probably why we did not feel the need to expand too much on this.

I don't know what the right course of action would be here. I'm not sure we want to duplicate the documentation, but there is certainly room for improvement. There is a tension here, though: this documentation is generated from our source code, and is used both by urllib3 developers and users. For developers, it's better to have the utility function documented, but for users it make more sense to document `HTTPSConnection`.

Here is a possible plan:

 1. Mention in `HTTPSConnection` that the parameters are documented in `util.ssl_wrap_socket`
 2. Extend the advanced docs to document missing parameters like `server_hostname`

Would that help?
I think that course of action would be perfect! If I can find time (and remember to do it) I'll work up a PR to add a reference from HTTPSConnection to util.ssl_wrap_socket and add a segment to the advanced doc which shows how to use `server_hostname` and `assert_hostname` to connect to an SNI host by IP address.

Resolving patch:
diff --git a/src/urllib3/connection.py b/src/urllib3/connection.py
--- a/src/urllib3/connection.py
+++ b/src/urllib3/connection.py
@@ -251,6 +251,11 @@ def request_chunked(self, method, url, body=None, headers=None):
 
 
 class HTTPSConnection(HTTPConnection):
+    """
+    Many of the parameters to this constructor are passed to the underlying SSL
+    socket by means of :py:func:`util.ssl_wrap_socket`.
+    """
+
     default_port = port_by_scheme["https"]
 
     cert_reqs = None


Test patch:
Repository: urllib3/urllib3

Issue:
Refresh the ConnectionPool.urlopen docstring
- Missing the `url` parameter from docs
- Mentions non-existing `post_url`?
- I'm sure there's more, likely good to put eyeballs on it :)


Discussion:
Hi, I'm interested in working on this.
@matthewhughes934 Sounds good, submit a PR and I'll review

Resolving patch:
diff --git a/src/urllib3/connectionpool.py b/src/urllib3/connectionpool.py
--- a/src/urllib3/connectionpool.py
+++ b/src/urllib3/connectionpool.py
@@ -551,10 +551,12 @@ def urlopen(
         :param method:
             HTTP request method (such as GET, POST, PUT, etc.)
 
+        :param url:
+            The URL to perform the request on.
+
         :param body:
-            Data to send in the request body (useful for creating
-            POST requests, see HTTPConnectionPool.post_url for
-            more convenience).
+            Data to send in the request body, either :class:`str`, :class:`bytes`,
+            an iterable of :class:`str`/:class:`bytes`, or a file-like object.
 
         :param headers:
             Dictionary of custom headers to send, such as User-Agent,


Test patch: