This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: test suite intentionally avoids referring to localhost, destroying abstraction away from IPv6 vs IPv4
Type: Stage: commit review
Components: Tests Versions: Python 3.7, Python 3.6, Python 2.7
Status: closed Resolution: out of date
Dependencies: Superseder:
Assigned To: gregory.p.smith Nosy List: brian.curtin, gregory.p.smith, paul.moore, pitrou, r.david.murray, steve.dower, tim.golden, vstinner, zach.ware
Priority: normal Keywords: patch

Created on 2017-02-24 01:34 by gregory.p.smith, last changed 2022-04-11 14:58 by admin. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 3465 merged gregory.p.smith, 2017-09-08 22:13
Messages (11)
msg288498 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2017-02-24 01:34
I am working on fixing our test suite to run on IPv6 only hosts (which are becoming a reality).  Many failures today occur because of hard coded values.

This is wrong.  We should refer to "localhost"

The "solution" to moved us backwards towards hard coding IP version type specific addresses claiming that windows cannot handle resolving localhost reliably.

On any windows system where that is the case we should declare the system broken and simply not run any networking related tests.
msg288628 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2017-02-27 10:13
I'm not sure how much of the original analysis was right.  I've just fired up a network-less Windows VM and 'localhost' seems to resolve just fine:

>>> socket.gethostbyname('localhost')
>>> socket.getaddrinfo('localhost', 80, socket.AF_UNSPEC, socket.SOCK_STREAM)

[(<AddressFamily.AF_INET6: 23>,
  <SocketKind.SOCK_STREAM: 1>,
  ('::1', 80, 0, 0)),
 (<AddressFamily.AF_INET: 2>,
  <SocketKind.SOCK_STREAM: 1>,
  ('', 80))]

But we should defer to our Windows experts on this.

(also, perhaps we should simply mandate that buildbots have at least basic DNS functionality. This would lighten the maintenance load on the test suite slightly.)
msg288638 - (view) Author: Paul Moore (paul.moore) * (Python committer) Date: 2017-02-27 12:11
I have a vague recollection of once working on a (Windows) system that mis-resolved localhost. But it was a long time ago, and I'm 100% OK with calling such a system broken.

+1 on using localhost
msg288640 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2017-02-27 13:07
I echo Paul. I think the last time I would have seen a problem was on Windows 2000, which is unsupported per PEP-11.

+1 to using localhost
msg288652 - (view) Author: Steve Dower (steve.dower) * (Python committer) Date: 2017-02-27 17:31
As far as I recall, there's a hosts file that resolves localhost to on Windows, which means a user could break their own configuration if they so desired. Definitely on all supported versions we should be able to assume localhost can be resolved.

I haven't checked out how it deals with IPv6, but presumably there's a priority or another hosts file that will cover it.
msg288682 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2017-02-27 23:46
great! that makes me feel much less bad about fixing this in the way i desire. :)
msg301763 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2017-09-09 07:30
New changeset efb1d0a3c001a6153211063ba439b9847aa03509 by Gregory P. Smith in branch 'master':
bpo-29639: change to "localhost"
msg301787 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2017-09-09 18:25
Users on linux can and do screw this up too.  I believe we also had a case where a distro screwed up the defaults for, I think, the reverse resolve?  Not sure which test that was, and the test may since been fixed to not depend on that.  The point is this may break in unexpected ways but hopefully they will all be either fixable or legitimately "your system is broken".

I'll review the test_smtplib changes soonish (so ping me if I don't :)
msg302087 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2017-09-13 16:16
I would like to share a short story with you.

I'm working on fixing *all* bugs on our 3 CI (buildbots, Travis CI, AppVeyor). I fixed almost all random test failures.

Right now, I'm trying to fix all "dangling thread" warnings: bpo-31234.

I was sure that I was done, but no, test_ssl failed on Travis CI and AppVeyor. Hum. The failure doesn't make sense. The code is perfectly fine. The thread is supposed to be gone for a long time, but not, it's still here for some reason.

After one day of debugging, I found that the thread is kept alive by a variable of a frame. The frame is kept alive from an traceback object of an Exception. The exception is ConnectionRefusedError. I continue to follow links, I see that the exception comes from socket.create_connection()... Interesting.

socket.create_connection() tries to be nice and keeps the last exception to re-raise it if no connection succeed.

The code seems correct: it stores the exception in the variable "err", and "return sock" is used to exit on succeed.


It seems like the exception stored in "err" is part of a reference cycle, so indirectly, a lot of frames are kept alive because of this cycle.

So, I wanted to share this story with you because test_ssl only started to fail recently. The reason is that support.HOST was modified from "" to "localhost". So if the name resolution first returns an IPv6 address, we may get the ConnectionRefusedError error, stored in "err", and then the connection succeed with IPv4... but you get the reference cycle mess.

Modifying support.HOST to "localhost" triggered a reference cycle!? Strange story.

I'm working on a quick fix:
msg302090 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2017-09-13 16:27
LOL. That is a very strange story and the last thing i'd have expected to fall out from changing one string to another. :)
msg393914 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2021-05-19 01:22
I'm making progress on and related IPv6-only issues, the changes of which tend to shake out improper uses of hardcoded.

I'm closing this issue as there aren't specific needs that the rest won't cover.
Date User Action Args
2022-04-11 14:58:43adminsetgithub: 73825
2021-05-19 01:22:22gregory.p.smithsetstatus: open -> closed
resolution: out of date
messages: + msg393914

stage: patch review -> commit review
2017-09-13 16:27:30gregory.p.smithsetmessages: + msg302090
2017-09-13 16:16:11vstinnersetnosy: + vstinner
messages: + msg302087
2017-09-09 18:25:19r.david.murraysetnosy: + r.david.murray
messages: + msg301787
2017-09-09 07:30:17gregory.p.smithsetmessages: + msg301763
2017-09-08 22:13:36gregory.p.smithsetkeywords: + patch
stage: patch review
pull_requests: + pull_request3457
2017-03-16 00:38:26gregory.p.smithsetassignee: gregory.p.smith
2017-02-27 23:46:13gregory.p.smithsetmessages: + msg288682
2017-02-27 17:31:36steve.dowersetmessages: + msg288652
2017-02-27 13:07:42brian.curtinsetnosy: + brian.curtin
messages: + msg288640
2017-02-27 12:11:25paul.mooresetmessages: + msg288638
2017-02-27 10:13:57pitrousetnosy: + paul.moore, pitrou, tim.golden, zach.ware, steve.dower
messages: + msg288628
2017-02-24 01:34:57gregory.p.smithcreate