TypeError: 'int' object is not callable (probably SSL issue)

[RamonGiovane]

Hi, I keep getting this weird error: TypeError: 'int' object is not callable
It happens arbitrarily when calling httpx.post, httpx.get or httpx.patch (those are the methods which I witnessed this issue so far).
Most of the time, it works like a charm.
But, sometimes, specially when a breakpoint is around, this error occurs.

• Python version: 3.10.4
• httpx version: 0.22.0

Traceback (most recent call last):
  File "/home/ramon/backend/./bgc/services.py", line 90, in get_services_list
    response = httpx.get(url, headers=headers)
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_api.py", line 189, in get
    return request(
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_api.py", line 92, in request
    with Client(
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_client.py", line 673, in __init__
    self._transport = self._init_transport(
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_client.py", line 721, in _init_transport
    return HTTPTransport(
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_transports/default.py", line 126, in __init__
    ssl_context = create_ssl_context(verify=verify, cert=cert, trust_env=trust_env)
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_config.py", line 49, in create_ssl_context
    return SSLConfig(
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_config.py", line 73, in __init__
    self.ssl_context = self.load_ssl_context()
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_config.py", line 85, in load_ssl_context
    return self.load_ssl_context_verify()
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_config.py", line 122, in load_ssl_context_verify
    context = self._create_default_ssl_context()
  File "/home/ramon/.cache/pypoetry/virtualenvs/lfeVqQy7-py3.10/lib/python3.10/site-packages/httpx/_config.py", line 163, in _create_default_ssl_context
    context.set_alpn_protocols(alpn_idents)
  File "/home/ramon/.asdf/installs/python/3.10.4/lib/python3.10/ssl.py", line 565, in set_alpn_protocols
    if len(b) == 0 or len(b) > 255:
TypeError: 'int' object is not callable

[lovelydinosaur]

I can't see how that line can raise that exception.
Are you able to reproduce this reliably? What are you setting a breakpoint with?

This example seemed like a good candidate for why you might be seeing that error... https://www.stechies.com/typeerror-int-object-is-not-callable/ ...but I can figure how you'd get it to reproduce in that particular context.

[RamonGiovane]

Thanks for the reply, sorry for the late response.
I'm using the builtin breakpoint() method.
I'm not even passing any integer 😄 it's crazy.

I think it's related to some certificate issue. Today it was happenning while calling the constructor httpx.Client().
Setting httpx.Client(verify=False) seems to mitigate it, but I'm really really not sure.

It always happen while I'm debugging a FastApi application (webhook response code that calls other APIs), maybe the connection is hanging out too much time and it brokes something someway.

[luiz-agostini]

I am having the same problem here, in the same line. Did you find a solution?

[RamonGiovane]

Sorry, not yet 😕

[shlyopin]

I have a similar problem when using debug mode (Apple M1)
Python version: 3.10.6
httpx version: 0.23.0

[shlyopin]

I found this issue: https://youtrack.jetbrains.com/issue/PY-52654/TypeError-NoneType-object-is-not-callable-when-building-plots-with-the-debugger-using-Python-310

[Whatislove118]

Same problem with Apple M1

[RamonGiovane]

It seems to be a problem with Cython.
Some people faced it with Pandas and NumPy as well.
pandas-dev/pandas#47429
numpy/numpy#21008
I believe it's a matter for the httpx maintainers, to use the newest version of Cython in the next release.

[tkrawczykspoton]

Got the same error in code that has been previously working (not while debugging).
HTTPX 0.23.0
Python 3.10

Seems like it fails for some specific certificates (?).

[tkrawczykspoton]

I have a FastAPI application running from docker image (python:3.10-slim-buster) with uvicorn (0.17.6) and uvloop (0.16.0) in kubernetes cluster.
In a request an HTTP call is made to another service running in the same cluster which fails on this error.

Restarting the deployment in kubernetes (replacing pod with new one from the same image) fixed the issue for a few minutes, then it started to fail again.

No debugging enabled.

I can't share the full code since it's proprietary, but maybe you have ideas what info would be helpful to you?

[lovelydinosaur]

Could you include the traceback you're seeing?

Are you able to edit the stdlib ssl.py module that's raising that error? If so there's some things we could do to track this down more completely. If so, then I'd probably start by editing the set_alpn_protocols() method (if you're able to do so?) to include a dumb print(len) statement or something similar, just to help figure out if the built-in it really has been overridden.

Also are you able to reproduce this within your docket image by just directly making an HTTP call with httpx, rather than having to spin up your whole framework?

I can see how we can work around this on our side by calling into Private API, so I think we can make some progress here...

[jtwillis92]

I was able to reproduce this same issue. Looks like something in httpx is setting len to an integer:

Python 3.10.8
httpx 0.23.0

[jtwillis92]

Actually, looks like it might be coming from the ssl module in the standard lib:

https://github.com/python/cpython/blob/main/Lib/ssl.py#L850

[theY4Kman]

☝️ so, that call to SSLObject.read is where the exception begins its life. For whatever reason, the frame's locals are exactly the ssl module's dict (AKA globals)

You'll find that buffer is also defined globally when the exception is raised, but only len causes issues.

[cp-weng]

Same here. Any progress?

[daniil-dn]

I have found the ssl.py and changed all local vars: 'len' to 'blen'

[lovelydinosaur]

Okay. It might be worth someone raising an issue on CPython to get this changed.

It's unclear to me how we're seeing this behaviour... "For whatever reason, the frame's locals are exactly the ssl module's dict" ...My guess would be that it's some kind of hacky performance optimisation that the debugger or runtime environment is using that subtly breaks the stack behaviour, perhaps.

Either way, changing that code so it doesn't use a Python built-in as a variable name would be a reasonable change.