ResourceWarning: unclosed socket.socket when I run a unittest？

requests show me following warning when I run a unittest:
```python
ResourceWarning: unclosed <socket.socket fd=5, family=AddressFamily.AF_INET, 
type=SocketKind.SOCK_STREAM, proto=6, laddr=('219.82.68.148', 36006), raddr=('125.46.22.55', 80)>
```

But this warning won't happen if I don't run the code in a unittest environment.

Is there somebody who can tell me why this warning happen?

This warning happens because Requests uses a keep-alive model that means we try not to explicitly close sockets in many cases. Exactly why this is happening is likely due to you either using a Session object that you don't explicitly close at the end of your test, or using an older version of Requests.

@Lukasa 
Thanks for answering. But why this warning won't happen if I I don't run the code in a unittest environment?

It's hard to know. Depends if they change the warning filter, depends if anything else changes the warnings filter, depends on how your code is written.

Does it mean I must call `session.close()` if I want to use the `requests.Session()`?

You don't *have* to. The warning is just that: a warning. No error occurs when you see it, and it is not an indication of the program doing the wrong thing. It's entirely expected behaviour, and this is working as designed. However, if you're concerned about them, you *may* call `close`.

> You don't have to. The warning is just that: a warning. No error occurs when you see it, and it is not an indication of the program doing the wrong thing. It's entirely expected behaviour, and this is working as designed. However, if you're concerned about them, you may call close.

I find this advice contrary to Python's typical approach to resource handling. Python encourages deterministic resource handling. For example, the stdlib produces warnings when files are mismanaged in a non-deterministic way to help guide developers. Developers _should_ take action on the warnings produced by stdlib. See the following Python bug where core developers discuss warnings during destructors:

https://bugs.python.org/issue28867

Additionally, Python [docs](https://docs.python.org/3/reference/datamodel.html#object.__del__) warn against relying on `__del__` for resource management:

>  It is not guaranteed that `__del__()` methods are called for objects that still exist when the interpreter exits.

And, exceptions occurring during `__del__` are ignored and can't be handled:

> Due to the precarious circumstances under which `__del__()` methods are invoked, exceptions that occur during their execution are ignored, and a warning is printed to `sys.stderr` instead.

I run all my tests and environments with warnings enabled to help catch _real_ bugs and upgrade paths. If this warning really should be ignored as suggested here, then maybe it shouldn't be logged. As it is now, people are taking this advice of not calling close and this results in lots of (ignorable?) noise in my output.

Hi!
I've same problem with my test only they never end because this error (?)

Could you provide an example of how to solve this issue?

> If this warning really should be ignored as suggested here, then maybe it shouldn't be logged.

@jdufresne I don't believe Requests is actually logging this at all. That's the interpreter logging it. Also, I'm rather confident that Requests doesn't rely on `__del__` so I'm confused as to why you're mentioning that here. It seems you're arguing against an invisible person and I'm not sure why you're doing that here.

>  I've same problem with my test only they never end because this error (?)

@Garito, this is not StackOverflow - the designated Q&A resource for Requests - so please post your question there with code snippets. As a hint, this is likely something to do with your code and not the ResourceWarning. An unclosed socket *should not* cause your tests to hang so there's likely something else going on with your code.

---

Given the shear amount of off-topic discussion on this issue, I'm locking it.