> I'm not familiar with this test. Me neither, but Brett C should be. :-) > In a debug build: > > """ > C:\Code\python\PCbuild>python_d ../lib/test/test_urllibnet.py > testURLread (__main__.URLTimeoutTest) ... ok > test_bad_address (__main__.urlopenNetworkTests) ... ok > test_basic (__main__.urlopenNetworkTests) ... ok > test_fileno (__main__.urlopenNetworkTests) ... > """ > > and there it dies with an assertion error in the bowels of Microsoft's > fdopen.c. That's called by Python's posix_fdopen, here: > > fp = fdopen(fd, mode); > > At this point, fd is 436. MS's fdopen is unhappy because only 32 > handles actually exist at this point, and 436 is bigger than that. > In the release build, the MS assert doesn't (of course) trigger; > instead, that 436 >= 32 causes MS's fdopen to return NULL. The test assumes that the fileno() from a socket object can be passed to os.fdopen(). That works on Unix. But on Windows it cannot, the small ints used to refer to open files are chosen from a different (though potentially overlapping) space than the small ints used to refer to open sockets, and the two cannot be mixed. So the test should be disabled on Windows. I don't know if we can protect os.fdopen() from crashing when passed an out of range number. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4