Attached patch modifies Lib/test/test_ssl.py to use "with socket:" instead of "try: ... finally: socket.close()" or similar patterns.

Our PPC64 AIX 3.x buildbot has a broken ssl module. A lot of tests logs ResourceWarning on unclosed sockets, because errors occur before the test closes a socket.

http://buildbot.python.org/all/builders/PPC64%20AIX%203.x/builds/4714/steps/test/logs/stdio

test_connect_ex_error (test.test_ssl.NetworkedTests) ... ok
test_connect_with_context (test.test_ssl.NetworkedTests) ... FAIL
/home/shager/cpython-buildarea/3.x.edelsohn-aix-ppc64/build/Lib/unittest/case.py:628: ResourceWarning: unclosed <ssl.SSLSocket fd=7, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=('140.211.15.154', 60379), raddr=('23.253.148.168', 443)>
  outcome.errors.clear()

Wouldn’t it be better to fix the underlying problem with the test cases? As I understand it, that would also avoid the warnings :)

Also, you can often use self.addCleanup(s.close), which saves a level of indentation (and associated noise in the annotate history). I used this technique in my remaining patch for Issue 25940.

Also remember that sockets don’t do context management in Python 2, so this would bring more incompatibilies when merging tests between the two branches.

Martin Panter added the comment:
> Wouldn’t it be better to fix the underlying problem with the test cases?

I don't feel able to fix AIX issues, and I don't think that we can fix
all issues. You still get ResourceWarning if you interrupt the test
with CTRL+c which is not a bug.

> Also, you can often use self.addCleanup(s.close), which saves a level of indentation (and associated noise in the annotate history).

It may work on some cases, but not all of them. And I like controlling
when a socket is closed: I prefer to close it inside the test, and not
sometime later with unittest magic features.

> Also remember that sockets don’t do context management in Python 2, so this would bring more incompatibilies when merging tests between the two branches.

Since this issue is not really a blocker bug, I suggest to only modify
Python 3.6.

It's a follow-up of all work on ResourceWarning (on Python 3.6) last days:
https://docs.python.org/dev/whatsnew/3.6.html#warnings

My point about Python 2 was that this might add an annoying difference between the two branches. Even if you don’t apply this to Py 2, the next person adding or updating a test might be inclined to do it.

Looking closer at your patch I admit that addCleanup() wouldn’t be appropriate except for the first change.

Maybe it would be okay to leave the “try / finally” cases as they are? Moving connect() inside is good though IMO.

Anyway, I’m only mildly against this. I don’t see much benefit, but I could tolerate the downsides. I guess it’s up to you.

"try: ... finally: s.close()" are "with s: ..." do the same thing, but I prefer "with" (context-manager). IMO it's more "pythonic". I prefer to see the "cleanup block" at the beginning, rather than at the end.

> My point about Python 2 was that this might add an annoying difference between the two branches. Even if you don’t apply this to Py 2, the next person adding or updating a test might be inclined to do it.

Well, there are 3 choices:

(1) Do nothing. The code rotten slowly (technical debt)
(2) Modify all actively development branches (2.7, 3.5, default)
(3) Only modify Python 3.6

Mofiying all branches means taking the (low) risk of introducing regressions. IMHO regressions occur, all the time.

I prefer the option (3) because it allows to enhance the code without taking any risk on regression.

Yeah, the code diverge, it's a natural fact.

Then you write that my changes replacing try/finally with "with" are not worth. Well, maybe you are true. Since 5 years, I convert all the code to "with" because I really like context managers. IMHO they make the code stronger and easier to read.

In many cases I prefer “with” over “try / finally”. But Python 2’s sockets do not support “with” statements, so choice (2) is not possible for 2.7.

I found one potential technical problem, and maybe some redundant close() calls in the review.

Victor, are you still interested to fix this issue?

Sorry, I lost track of this issue. ResourceWarning only occurs on a bug, so it don't think that the issue is really important. I just close it.