internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: adamchainz/django-cors-headers

Issue:
Add "vary origin" header
See http://stackoverflow.com/a/27990162/345876

It looks like caching might be broken if the vary header isn't set on ALL requests, even when not concerning cores-enabled urls.



Discussion:
I don't know about _all_, but according to https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS the Vary: Origin header should at least be set whenever the Access-Control-Allow-Origin is set to an explicit domain.

Yes this should be added!


Resolving patch:
diff --git a/corsheaders/middleware.py b/corsheaders/middleware.py
--- a/corsheaders/middleware.py
+++ b/corsheaders/middleware.py
@@ -2,6 +2,7 @@
 
 from django import http
 from django.apps import apps
+from django.utils.cache import patch_vary_headers
 from django.utils.six.moves.urllib.parse import urlparse
 
 from .conf import conf
@@ -124,6 +125,7 @@ def process_response(self, request, response):
                 response[ACCESS_CONTROL_ALLOW_ORIGIN] = "*"
             else:
                 response[ACCESS_CONTROL_ALLOW_ORIGIN] = origin
+                patch_vary_headers(response, ['Origin'])
 
             if len(conf.CORS_EXPOSE_HEADERS):
                 response[ACCESS_CONTROL_EXPOSE_HEADERS] = ', '.join(conf.CORS_EXPOSE_HEADERS)


Test patch:
diff --git a/tests/test_middleware.py b/tests/test_middleware.py
--- a/tests/test_middleware.py
+++ b/tests/test_middleware.py
@@ -255,6 +255,21 @@ def test_middleware_integration_get(self):
         response = self.client.get('/test-view/', HTTP_ORIGIN='http://foobar.it')
         assert response.status_code == 200
         assert response[ACCESS_CONTROL_ALLOW_ORIGIN] == 'http://foobar.it'
+        assert response['Vary'] == 'Origin'
+
+    @override_settings(
+        CORS_ALLOW_CREDENTIALS=True,
+        CORS_ORIGIN_ALLOW_ALL=True,
+    )
+    def test_middleware_integration_options(self):
+        response = self.client.options(
+            '/test-view/',
+            HTTP_ORIGIN='http://foobar.it',
+            HTTP_ACCESS_CONTROL_REQUEST_METHOD='value',
+        )
+        assert response.status_code == 200
+        assert response[ACCESS_CONTROL_ALLOW_ORIGIN] == 'http://foobar.it'
+        assert response['Vary'] == 'Origin'
 
     @override_settings(
         CORS_ALLOW_CREDENTIALS=True,
Repository: adamchainz/django-cors-headers

Issue:
Cover uncovered return statement
The following return in `corsheaders.middleware` isn't covered in tests, and was just ignored with `# pragma: no cover` to get the coverage to a nice round 100%. We should add a test, probably after #124 is done.

``` python
if not conf.CORS_ORIGIN_ALLOW_ALL and self.origin_not_found_in_white_lists(origin, url):
    return  # pragma: no cover
```



Discussion:

Resolving patch:
diff --git a/corsheaders/middleware.py b/corsheaders/middleware.py
--- a/corsheaders/middleware.py
+++ b/corsheaders/middleware.py
@@ -58,8 +58,9 @@ def _https_referer_replace(self, request):
         if request.is_secure() and origin and 'ORIGINAL_HTTP_REFERER' not in request.META:
 
             url = urlparse(origin)
+            print(self.origin_not_found_in_white_lists(origin, url))
             if not conf.CORS_ORIGIN_ALLOW_ALL and self.origin_not_found_in_white_lists(origin, url):
-                return  # pragma: no cover
+                return
 
             try:
                 http_referer = request.META['HTTP_REFERER']


Test patch:
diff --git a/tests/test_middleware.py b/tests/test_middleware.py
--- a/tests/test_middleware.py
+++ b/tests/test_middleware.py
@@ -315,7 +315,7 @@ def test_works_if_view_deletes_is_enabled(self):
 
 @override_settings(
     CORS_REPLACE_HTTPS_REFERER=True,
-    CORS_ORIGIN_REGEX_WHITELIST=r'.*example.*',
+    CORS_ORIGIN_REGEX_WHITELIST=(r'.*example.*',),
 )
 class RefererReplacementCorsMiddlewareTests(TestCase):
 
@@ -383,3 +383,15 @@ def test_get_does_not_fail_in_referer_replacement_when_host_missing(self):
         )
         assert resp.wsgi_request.META['HTTP_REFERER'] == 'https://example.org/foo'
         assert 'ORIGINAL_HTTP_REFERER' not in resp.wsgi_request.META
+
+    @override_settings(CORS_ORIGIN_REGEX_WHITELIST=())
+    def test_get_does_not_replace_referer_when_not_valid_request(self):
+        resp = self.client.get(
+            '/',
+            HTTP_FAKE_SECURE='true',
+            HTTP_HOST='example.com',
+            HTTP_ORIGIN='https://example.org',
+            HTTP_REFERER='https://example.org/foo',
+        )
+        assert resp.wsgi_request.META['HTTP_REFERER'] == 'https://example.org/foo'
+        assert 'ORIGINAL_HTTP_REFERER' not in resp.wsgi_request.META
Repository: adamchainz/django-cors-headers

Issue:
Support "null" origin
A PR for this (#101) was recently rejected with the comment "I couldn't find a source that said setting `Origin` to `null` is part of the standard". I want to at least document that this is indeed a first-class part of the standard.

The syntax for the `Origin` header is defined in [Section 7.1 of RFC 6454](https://tools.ietf.org/html/rfc6454#section-7.1). The ABNF there specifies the header's value as either the string `null` or a list of origins. Sections 4 and 6 define the circumstances under which this value should be set to `null`, which include using a `file://` origin.

Similarly, the W3C CORS specification [explicitly notes](https://www.w3.org/TR/cors/#resource-sharing-check-0) that the matching algorithm "also functions when the ASCII serialization of an origin is the string `null`".

In practical terms this isn't a very pressing concern, since you can just use `CORS_ORIGIN_REGEX_WHITELIST = (r"^null$",)`. That said, I think it would make sense to allow the value to be used in the whitelist directly.


Discussion:
Thanks for looking this up, I agree we should accept it. Could you open a PR to add it? 👍 

Resolving patch:
diff --git a/corsheaders/middleware.py b/corsheaders/middleware.py
--- a/corsheaders/middleware.py
+++ b/corsheaders/middleware.py
@@ -145,6 +145,7 @@ def process_response(self, request, response):
     def origin_found_in_white_lists(self, origin, url):
         return (
             url.netloc in conf.CORS_ORIGIN_WHITELIST or
+            (origin == 'null' and origin in conf.CORS_ORIGIN_WHITELIST) or
             self.regex_domain_match(origin)
         )
 


Test patch:
diff --git a/tests/test_middleware.py b/tests/test_middleware.py
--- a/tests/test_middleware.py
+++ b/tests/test_middleware.py
@@ -35,6 +35,11 @@ def test_get_in_whitelist(self):
         resp = self.client.get('/', HTTP_ORIGIN='http://example.org')
         assert resp[ACCESS_CONTROL_ALLOW_ORIGIN] == 'http://example.org'
 
+    @override_settings(CORS_ORIGIN_WHITELIST=['example.com', 'null'])
+    def test_null_in_whitelist(self):
+        resp = self.client.get('/', HTTP_ORIGIN='null')
+        assert resp[ACCESS_CONTROL_ALLOW_ORIGIN] == 'null'
+
     @override_settings(
         CORS_ORIGIN_ALLOW_ALL=True,
         CORS_EXPOSE_HEADERS=['accept', 'origin', 'content-type'],
Repository: adamchainz/django-cors-headers

Issue:
CORS_HEADER value is set to regex match object
The `CORS_ENABLED` response header is set to the regex match object in line 82 of `middleware.py` as returned by `CorsPostCsrfMiddleware.is_enabled`

I am not aware of the best practice here, but I would assume a boolean response makes more sense.

![image](https://cloud.githubusercontent.com/assets/1830169/21987339/26b7ccb2-dc29-11e6-948c-fb810e6587e8.png)



Discussion:
I don't see the code creating the CORS_ENABLED header even in https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py#L82 ? Is that the current version you're looking at?
This probably happens because the `is_enabled` method [here](https://github.com/ottoyiu/django-cors-headers/blob/master/corsheaders/middleware.py#L159-L163) short circuits and returns the result of `re.match`, which is a regex match object. I think wrapping the expression in `bool()` would fix it.
I can see that it short-circuits and gets attached to `request._cors_enabled`, but we don't have any code that creates the headers `CORS_ENABLED`, `CORS_ORIGIN`, or `CORS_URL` headers, which is what is shown in the screenshot. I'm going to presume they are custom for debugging, since @rtindru didn't reply, and wrap with `bool()` and consider this issue closed.

Resolving patch:
diff --git a/corsheaders/middleware.py b/corsheaders/middleware.py
--- a/corsheaders/middleware.py
+++ b/corsheaders/middleware.py
@@ -158,7 +158,7 @@ def origin_found_in_model(self, url):
 
     def is_enabled(self, request):
         return (
-            re.match(conf.CORS_URLS_REGEX, request.path) or
+            bool(re.match(conf.CORS_URLS_REGEX, request.path)) or
             self.check_signal(request)
         )
 


Test patch:
diff --git a/tests/test_middleware.py b/tests/test_middleware.py
--- a/tests/test_middleware.py
+++ b/tests/test_middleware.py
@@ -322,10 +322,21 @@ def test_get_no_origin_not_enabled(self):
         assert ACCESS_CONTROL_ALLOW_ORIGIN not in resp
 
     @override_settings(CORS_ORIGIN_WHITELIST=['example.com'])
-    def test_works_if_view_deletes_is_enabled(self):
+    def test_cors_enabled_is_attached_and_bool(self):
+        """
+        Ensure that request._cors_enabled is available - although a private API
+        someone might use it for debugging
+        """
+        resp = self.client.get('/', HTTP_ORIGIN='http://example.com')
+        request = resp.wsgi_request
+        assert isinstance(request._cors_enabled, bool)
+        assert request._cors_enabled
+
+    @override_settings(CORS_ORIGIN_WHITELIST=['example.com'])
+    def test_works_if_view_deletes_cors_enabled(self):
         """
         Just in case something crazy happens in the view or other middleware,
-        check that get_response doesn't fall over if `is_enabled` is removed
+        check that get_response doesn't fall over if `_cors_enabled` is removed
         """
         resp = self.client.get(
             '/delete-is-enabled/',
Repository: adamchainz/django-cors-headers

Issue:
ABCs collections DeprecationWarning under Python 3.7
Hi

With `DeprecationWarning`s enabled, under Python 3.7 I get:

```
.../site-packages/corsheaders/checks.py:4: DeprecationWarning: Using or importing the ABCs from
'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working
```


Discussion:

Resolving patch:
diff --git a/corsheaders/checks.py b/corsheaders/checks.py
--- a/corsheaders/checks.py
+++ b/corsheaders/checks.py
@@ -1,7 +1,6 @@
 from __future__ import absolute_import
 
 import re
-from collections import Sequence
 from numbers import Integral
 
 from django.core import checks
@@ -9,6 +8,11 @@
 
 from .conf import conf
 
+try:
+    from collections.abc import Sequence  # Python 3.3+
+except ImportError:  # pragma: no cover
+    from collections import Sequence
+
 re_type = type(re.compile(''))
 
 


Test patch:
Repository: adamchainz/django-cors-headers

Issue:
Allow 'null' in CORS_ORIGIN_WHITELIST check
The check added in #397 didn't special-case `null` which it should, as reported in #403 by @subodhjena.


Discussion:

Resolving patch:
diff --git a/corsheaders/checks.py b/corsheaders/checks.py
--- a/corsheaders/checks.py
+++ b/corsheaders/checks.py
@@ -64,6 +64,8 @@ def check_settings(app_configs, **kwargs):
         )
     else:
         for origin in conf.CORS_ORIGIN_WHITELIST:
+            if origin == 'null':
+                continue
             parsed = urlparse(origin)
             if parsed.scheme == '' or parsed.netloc == '':
                 errors.append(checks.Error(


Test patch:
diff --git a/tests/test_checks.py b/tests/test_checks.py
--- a/tests/test_checks.py
+++ b/tests/test_checks.py
@@ -68,6 +68,10 @@ def test_cors_origin_whitelist_non_sequence(self):
     def test_cors_origin_whitelist_non_string(self):
         self.check_error_codes(['corsheaders.E006'])
 
+    @override_settings(CORS_ORIGIN_WHITELIST=['http://example.com', 'null'])
+    def test_cors_origin_whitelist_allowed(self):
+        self.check_error_codes([])
+
     @override_settings(CORS_ORIGIN_WHITELIST=['example.com'])
     def test_cors_origin_whitelist_no_scheme(self):
         self.check_error_codes(['corsheaders.E013'])
Repository: adamchainz/django-cors-headers

Issue:
Allow 'null' in CORS_ORIGIN_WHITELIST check
The check added in #397 didn't special-case `null` which it should, as reported in #403 by @subodhjena.


Discussion:
+1

Resolving patch:
diff --git a/corsheaders/checks.py b/corsheaders/checks.py
--- a/corsheaders/checks.py
+++ b/corsheaders/checks.py
@@ -71,6 +71,8 @@ def check_settings(app_configs, **kwargs):
         )
     else:
         for origin in conf.CORS_ORIGIN_WHITELIST:
+            if origin == 'null':
+                continue
             parsed = urlparse(origin)
             if parsed.scheme == '' or parsed.netloc == '':
                 errors.append(checks.Error(


Test patch:
diff --git a/tests/test_checks.py b/tests/test_checks.py
--- a/tests/test_checks.py
+++ b/tests/test_checks.py
@@ -70,6 +70,10 @@ def test_cors_origin_whitelist_non_sequence(self):
     def test_cors_origin_whitelist_non_string(self):
         self.check_error_codes(['corsheaders.E006'])
 
+    @override_settings(CORS_ORIGIN_WHITELIST=['http://example.com', 'null'])
+    def test_cors_origin_whitelist_allowed(self):
+        self.check_error_codes([])
+
     @override_settings(CORS_ORIGIN_WHITELIST=['example.com'])
     def test_cors_origin_whitelist_no_scheme(self):
         self.check_error_codes(['corsheaders.E013'])
Repository: adamchainz/django-cors-headers

Issue:
Cannot whitelist `file://`, which means I cannot work around a Chrome bug
Chrome on Android isn't letting some people login to our app. There's the [bug in chrome on Android](https://bugs.chromium.org/p/chromium/issues/detail?id=991107) that I'm trying to work around. The workaround, however, requires whitelisting "file://" in CORS.

 Tried adding 'file://' as whitelisted origin, but it gives me the error:

```
(corsheaders.E013) Origin 'file://' in CORS_ORIGIN_WHITELIST is missing  scheme or netloc
	HINT: Add a scheme (e.g. https://) or netloc (e.g. example.com).
```

I tried adding "file://* and django starts up, but the CORS preflight result doesn't include the needed Access-Control-Allow-Origin line (which it does successful for null).

Any ideas how to get this to work?




Discussion:
Actually, figured out how to do it: `CORS_ORIGIN_REGEX_WHITELIST = r"^file://$"`
Reopening it because the library shouldn't force you to create two problems with a regex!

Resolving patch:
diff --git a/corsheaders/checks.py b/corsheaders/checks.py
--- a/corsheaders/checks.py
+++ b/corsheaders/checks.py
@@ -67,8 +67,15 @@ def check_settings(app_configs, **kwargs):
             )
         )
     else:
+        special_origin_values = (
+            # From 'security sensitive' contexts
+            "null",
+            # From files on Chrome on Android
+            # https://bugs.chromium.org/p/chromium/issues/detail?id=991107
+            "file://",
+        )
         for origin in conf.CORS_ORIGIN_WHITELIST:
-            if origin == "null":
+            if origin in special_origin_values:
                 continue
             parsed = urlparse(origin)
             if parsed.scheme == "" or parsed.netloc == "":


Test patch:
diff --git a/tests/test_checks.py b/tests/test_checks.py
--- a/tests/test_checks.py
+++ b/tests/test_checks.py
@@ -67,7 +67,7 @@ def test_cors_origin_whitelist_non_sequence(self):
     def test_cors_origin_whitelist_non_string(self):
         self.check_error_codes(["corsheaders.E006"])
 
-    @override_settings(CORS_ORIGIN_WHITELIST=["http://example.com", "null"])
+    @override_settings(CORS_ORIGIN_WHITELIST=["http://example.com", "file://", "null"])
     def test_cors_origin_whitelist_allowed(self):
         self.check_error_codes([])
 
diff --git a/tests/test_middleware.py b/tests/test_middleware.py
--- a/tests/test_middleware.py
+++ b/tests/test_middleware.py
@@ -54,6 +54,15 @@ def test_null_in_whitelist(self):
         resp = self.client.get("/", HTTP_ORIGIN="null")
         assert resp[ACCESS_CONTROL_ALLOW_ORIGIN] == "null"
 
+    @override_settings(CORS_ORIGIN_WHITELIST=["http://example.com", "file://"])
+    def test_file_in_whitelist(self):
+        """
+        'file://' should be allowed as an origin since Chrome on Android
+        mistakenly sends it
+        """
+        resp = self.client.get("/", HTTP_ORIGIN="file://")
+        assert resp[ACCESS_CONTROL_ALLOW_ORIGIN] == "file://"
+
     @override_settings(
         CORS_ORIGIN_ALLOW_ALL=True,
         CORS_EXPOSE_HEADERS=["accept", "origin", "content-type"],
Repository: adamchainz/django-cors-headers

Issue:
unhandled invalid HTTP_ORIGIN
### Understanding CORS

- [X] I have read the resources.

### Python Version

3.9.7

### Django Version

3.2.8

### Package Version

3.10.0

### Description

it seems that an unparsable, invalid `HTTP_ORIGIN` header is a trivial way to exception/mail spam a django instance:

```
Internal Server Error: /

ValueError at /
Invalid IPv6 URL
...
HTTP_ORIGIN = 'https://example.com].evil.com'
HTTP_REFERER = 'https://example.com].evil.com'
```

https://github.com/adamchainz/django-cors-headers/blob/main/src/corsheaders/middleware.py#L135

this was generated by a security scanner btw.

i think in this case `HTTP_ORIGIN` should be simply ignored and the library should behave as if there was no header at all.


Discussion:

Resolving patch:
diff --git a/src/corsheaders/middleware.py b/src/corsheaders/middleware.py
--- a/src/corsheaders/middleware.py
+++ b/src/corsheaders/middleware.py
@@ -131,8 +131,10 @@ def process_response(
         if not origin:
             return response
 
-        # todo: check hostname from db instead
-        url = urlparse(origin)
+        try:
+            url = urlparse(origin)
+        except ValueError:
+            return response
 
         if conf.CORS_ALLOW_CREDENTIALS:
             response[ACCESS_CONTROL_ALLOW_CREDENTIALS] = "true"


Test patch:
diff --git a/tests/test_middleware.py b/tests/test_middleware.py
--- a/tests/test_middleware.py
+++ b/tests/test_middleware.py
@@ -32,6 +32,10 @@ def test_get_origin_vary_by_default(self):
         resp = self.client.get("/")
         assert resp["Vary"] == "Origin"
 
+    def test_get_invalid_origin(self):
+        resp = self.client.get("/", HTTP_ORIGIN="http://example.com]")
+        assert ACCESS_CONTROL_ALLOW_ORIGIN not in resp
+
     @override_settings(CORS_ALLOWED_ORIGINS=["http://example.com"])
     def test_get_not_in_allowed_origins(self):
         resp = self.client.get("/", HTTP_ORIGIN="http://example.org")
Repository: adamchainz/django-cors-headers

Issue:
Listing Origin, DNT, or Accept-Encoding as allowed request headers is never necessary
### Understanding CORS

- [X] I have read the resources.

### Python Version

_No response_

### Django Version

_No response_

### Package Version

_No response_

### Description

The [README](https://github.com/adamchainz/django-cors-headers#cors_allow_headers-sequencestr) explicitly lists `"accept-encoding"`, `"dnt"`, and `"origin"` in the `CORS_ALLOW_HEADERS` list:

```python
CORS_ALLOW_HEADERS = [
    # omitted
    "accept-encoding",
    # omitted
    "dnt",
    "origin",
    # omitted
]
```

However, contrary to popular belief and according to the Fetch standard, allowing those request headers is never necessary. As so-called [_forbidden request headers_](https://fetch.spec.whatwg.org/#forbidden-request-header), they're indeed handled by the browser, not by the client.

You can safely drop those three elements from that list.


Discussion:

Resolving patch:
diff --git a/src/corsheaders/defaults.py b/src/corsheaders/defaults.py
--- a/src/corsheaders/defaults.py
+++ b/src/corsheaders/defaults.py
@@ -2,11 +2,8 @@
 
 default_headers = (
     "accept",
-    "accept-encoding",
     "authorization",
     "content-type",
-    "dnt",
-    "origin",
     "user-agent",
     "x-csrftoken",
     "x-requested-with",


Test patch:
Repository: onnx/sklearn-onnx

Issue:
SelectFromModel converted model with threshold such that no features selected give error
SelectFromModel model in Scikit with threshold such that no features are selected returns an array of shape (M, 0), where M is the number of test instances, onnx converter however can't handle it.

RuntimeError: [ONNXRuntimeError] : 1 : GENERAL ERROR : Load model from pca1.onnx failed:[ShapeInferenceError] Shape input must be a one-dimensional tensor. 


Discussion:

Resolving patch:
diff --git a/skl2onnx/operator_converters/feature_selection.py b/skl2onnx/operator_converters/feature_selection.py
--- a/skl2onnx/operator_converters/feature_selection.py
+++ b/skl2onnx/operator_converters/feature_selection.py
@@ -14,6 +14,11 @@ def convert_sklearn_feature_selection(scope, operator, container):
     op = operator.raw_operator
     # Get indices of the features selected
     index = op.get_support(indices=True)
+    if len(index) == 0:
+        raise RuntimeError(
+            "Model '{}' did not select any feature. "
+            "This model cannot be converted into ONNX."
+            "".format(op.__class__.__name__))
     needs_cast = not isinstance(operator.inputs[0].type,
                                 (FloatTensorType, FloatType))
     if needs_cast:


Test patch:
diff --git a/tests/test_sklearn_feature_selection_converters.py b/tests/test_sklearn_feature_selection_converters.py
--- a/tests/test_sklearn_feature_selection_converters.py
+++ b/tests/test_sklearn_feature_selection_converters.py
@@ -396,6 +396,20 @@ def test_select_from_model_float(self):
                           " <= StrictVersion('0.2.1')",
         )
 
+    def test_select_from_model_float_nomodel(self):
+        model = SelectFromModel(
+            estimator=SVR(kernel="linear"), threshold=1e5)
+        X = np.array(
+            [[1, 2, 3, 1], [0, 3, 1, 4], [3, 5, 6, 1], [1, 2, 1, 5]],
+            dtype=np.float32,
+        )
+        y = np.array([0, 1, 0, 1])
+        model.fit(X, y)
+        with self.assertRaises(RuntimeError):
+            convert_sklearn(
+                model, "select from model",
+                [("input", FloatTensorType([None, X.shape[1]]))])
+
     def test_select_fwe_float(self):
         model = SelectFwe()
         X, y = load_breast_cancer(return_X_y=True)
Repository: onnx/sklearn-onnx

Issue:
CalibratedClassifier fails for scikit-learn 0.24



Discussion:

Resolving patch:
diff --git a/skl2onnx/operator_converters/calibrated_classifier_cv.py b/skl2onnx/operator_converters/calibrated_classifier_cv.py
--- a/skl2onnx/operator_converters/calibrated_classifier_cv.py
+++ b/skl2onnx/operator_converters/calibrated_classifier_cv.py
@@ -3,7 +3,7 @@
 # Licensed under the MIT License. See License.txt in the project root for
 # license information.
 # --------------------------------------------------------------------------
-
+import pprint
 import numpy as np
 from ..proto import onnx_proto
 from ..common._apply_operation import (
@@ -116,12 +116,14 @@ def _transform_isotonic(scope, container, model, T, k):
         atX, atY = '_X_', '_y_'
     elif hasattr(model.calibrators_[k], '_necessary_X_'):
         atX, atY = '_necessary_X_', '_necessary_y_'
+    elif hasattr(model.calibrators_[k], 'X_thresholds_'):
+        atX, atY = 'X_thresholds_', 'y_thresholds_'
     else:
         raise AttributeError(
             "Unable to find attribute '_X_' or '_necessary_X_' "
             "for type {}\n{}."
             "".format(type(model.calibrators_[k]),
-                      dir(model.calibrators_[k])))
+                      pprint.pformat(dir(model.calibrators_[k]))))
 
     container.add_initializer(
         calibrator_x_name, onnx_proto.TensorProto.FLOAT,


Test patch: