Mailman 3 February 2016 - Python-Dev

[ANNOUNCE] fuzzpy
by Brian Cain Feb. 29, 2016

Feb. 29, 2016

################################################################## *---------------------------------------------------* * fuzzpy: CPython fuzz tester is now available * * * * Version 0.8 * * https://bitbucket.org/ebadf/fuzzpy/ * *---------------------------------------------------* I am pleased to announce the creation of a coverage-guided fuzz tester for CPython. It's a pretty small wrapper around LLVM's libFuzzer that enables some powerful testing logic. AFL (American Fuzzy Lop) is another popular fuzzer lately -- libFuzzer is very similar in concept to AFL. From what I've read on list archives, Victor Stinner had previously done some good fuzz testing on CPython using fusil. This project should expand on that concept. I'd love to get feedback, suggestions, patches and anything else the list can offer. Q: What is fuzzpy for? A: It's primarily for testing CPython itself, but could also be used for individual python projects too. Pure-python projects will be the simplest to integrate at this point. Also, interesting test cases output by fuzzpy may end up being useful in testing others such as pypy, pyston, etc. Q: What is a fuzz tester? A: It modifies inputs to a test case in order to find unique/rare failures. Q: What does "coverage-guided" mean? A: It means that libFuzzer is able to witness the specific code executed as a result of a given test case. It feeds this information back into an engine to modify the test cases to optimize for coverage. Q: How can I help? A1: donate cycles: build the project and crank away on one of the existing tests. Relative to other common fuzzing, it's awfully slow, so consider throwing as many cycles as you can afford to. A2: contribute tests: write a ~10-line python script that exercises a feature that you think could benefit from fuzz testing. A3: if there's interest, I can accept cryptocoin donations to purchase cycles on a cloud server. ################################################################## -- -Brian

1 0

Very old git mirror under github user "python-git"
by John Mark Vandenberg Feb. 29, 2016

Feb. 29, 2016

Does anyone know who controls this mirror, which is attracting pull requests? https://github.com/python-git/python/pulls Can it be pulled down to avoid confusion, since it is using Python's logo? https://github.com/python-git -- John Vandenberg

13 14

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW
by Alexander Walters Feb. 28, 2016

Feb. 28, 2016

Theoretically yes. Practically, I think, but do not know for sure, it would have the same annoying issues as other SDK builds (of which, the most annoying is just different paths for the tools). Making that a supported build would require some of the same effort as supporting any other compiler though (a build bot configured to compile python this way). I also think, but am not sure, that what you linked is in fact the leaner meaner toolchain that Steve was referring to. On 2/27/2016 16:49, Chris Krycho wrote: > > Outsider/observer here; but is it not possible to build Python using > the VS *toolchain* (compiler, linker, etc.) outside of VS itself—i.e. > using MSBuild[1] and so on? That would remove the need for the full VS > install, and is *much* smaller (~800MB after installation, rather than > 9GB). A lean and mean VS will be a great improvement regardless, but > it seems like that would be a good intermediate solution if it’s possible. > > [1]: https://www.microsoft.com/en-us/download/details.aspx?id=49983 > > – Chris > > On February 27, 2016 at 4:36:54 PM, Alexander Walters > (tritium-list(a)sdamon.com <mailto:tritium-list@sdamon.com>) wrote: > >> The 9 gig initial download is not the only problem. Visual studio is >> very bandwidth hungry in day to day operations (between polling >> websites and vcs remotes, near constant updating, integration with >> the VS web service, etc.). You can of course shut all of that off, >> but it's a pain. It's my understanding from Steve's post that a >> leaner, meaner edition of VS is in the works, so waiting for that >> might just be an overall better solution. >> >> On 2/27/2016 16:27, Franklin? Lee wrote: >>> >>> For this particular case, is there someone generous enough (or, can >>> someone apply for a PSF grant) to ship Mathieu a DVD/two/flash drive? >>> >>> On Feb 26, 2016 12:18 PM, "Mathieu Dupuy" <deronnax(a)gmail.com >>> <mailto:deronnax@gmail.com>> wrote: >>> >>> Hi. >>> I am currently working on adding some functionality on a standard >>> library module (http://bugs.python.org/issue15873). The Python part >>> went fine, but now I have to do the C counterpart, and I have >>> ran into >>> in several problems, which, stacked up, are a huge obstacle to >>> easily >>> contribute further. Currently, despite I could work, I can't go >>> further >>> on my patch. >>> >>> I am currently working in very limited network, CPU and time >>> ressources* which are quite uncommon in the western world, but are >>> much less in the rest of the world. I have a 2GB/month mobile data >>> plan and a 100KB/s speed. For the C part of my patch, I should >>> download Visual Studio. The Express Edition 2015 is roughly 9GB. I >>> can't afford that. >>> >>> I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and >>> Fedora 23). Shortly, I couldn't get something working quickly and >>> simply (quickly = less than 2 hours, downloading time NOT included, >>> which is anyway way too already much). What went wrong and why >>> it went >>> wrong could be a whole new thread and is outside of the scope of >>> this >>> message. >>> Let me precise this : at my work I use many virtualbox instances >>> automatically fired and run in parallel to test new deployments and >>> run unittests. I like this tool, >>> but despite its simple look, it (most of the time) can not be used >>> simply by a profane. The concepts it requires you to understand are >>> not intuitive at first sight and there is *always* a thing that go >>> wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox >>> shipped for a moment a broken version of mount.vboxsf, preventing >>> sharing folder to mount. Despite it's fixed, the broken releases >>> spread everywhere and you may encounter them a lot in various Ubuntu >>> and Virtualbox version. I downloaded the last versions of both and I >>> am yet infected. https://www.virtualbox.org/ticket/12879). I >>> could do >>> whole new thread on why you can't ask newcomers to use Virtualbox >>> (currently, at least). >>> >>> I ran into is a whole patch set to make CPython compile on MinGW >>> (https://bugs.python.org/issue3871#msg199695). But it is not denying >>> it's very experimental, and I know I would again spent useless hours >>> trying to get it work rather than joyfully improving Python, and >>> that's exactly what I do not want to happen. >>> >>> Getting ready to contribute to CPython pure python modules from an >>> standard, average mr-everyone Windows PC for a beginner-to-medium >>> contributor only require few megabytes of internet and few >>> minutes of his >>> time: getting a tarball of CPython sources (or cloning the >>> github CPython >>> mirror)**, a basic text editor and msys-git. The step further, >>> if doing >>> some -even basic- C code is required, implies downloading 9GB of >>> Visual >>> Studio and countless hours for it to be ready to use. >>> I think downloading the whole Visual Studio suite is a huge >>> stopper to >>> contribute further for an average medium-or-below-contributor. >>> >>> I think (and I must not be the only one since CPython is to be moved >>> to github), that barriers to contribute to CPython should be set to >>> the lowest. >>> Of course my situation is a bit special but I think it represents >>> daily struggle of a *lot* of non-western programmer (at least for >>> limited internet)(even here in Australia, landline limited internet >>> connections are very common). >>> It's not a big deal if the MinGW result build is twenty time >>> slower or >>> if some of the most advanced modules can't be build. But everyone >>> programmer should be able to easily make some C hacks and get >>> them to >>> work. >>> >>> Hoping you'll be receptive to my pleas, >>> Cheers >>> >>> >>> * I am currently picking fruits in the regional Australia. I >>> live in a van >>> and have internet through with smartphone through an EDGE >>> connection. I can >>> plug the laptop in the farm but not in the van. >>> ** No fresh programmer use mercurial unless he has a gun pointed >>> on his >>> head. >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev(a)python.org <mailto:Python-Dev@python.org> >>> https://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe: >>> https://mail.python.org/mailman/options/python-dev/leewangzhong%2Bpython%40… >>> >>> >>> >>> _______________________________________________ >>> Python-Dev mailing list >>> Python-Dev(a)python.org >>> https://mail.python.org/mailman/listinfo/python-dev >>> Unsubscribe:https://mail.python.org/mailman/options/python-dev/tritium-list… >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev(a)python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/chris%40chriskrycho.com

2 1

Python should be easily compilable on Windows with MinGW
by Mathieu Dupuy Feb. 28, 2016

Feb. 28, 2016

Hi. I am currently working on adding some functionality on a standard library module (http://bugs.python.org/issue15873). The Python part went fine, but now I have to do the C counterpart, and I have ran into in several problems, which, stacked up, are a huge obstacle to easily contribute further. Currently, despite I could work, I can't go further on my patch. I am currently working in very limited network, CPU and time ressources* which are quite uncommon in the western world, but are much less in the rest of the world. I have a 2GB/month mobile data plan and a 100KB/s speed. For the C part of my patch, I should download Visual Studio. The Express Edition 2015 is roughly 9GB. I can't afford that. I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and Fedora 23). Shortly, I couldn't get something working quickly and simply (quickly = less than 2 hours, downloading time NOT included, which is anyway way too already much). What went wrong and why it went wrong could be a whole new thread and is outside of the scope of this message. Let me precise this : at my work I use many virtualbox instances automatically fired and run in parallel to test new deployments and run unittests. I like this tool, but despite its simple look, it (most of the time) can not be used simply by a profane. The concepts it requires you to understand are not intuitive at first sight and there is *always* a thing that go wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox shipped for a moment a broken version of mount.vboxsf, preventing sharing folder to mount. Despite it's fixed, the broken releases spread everywhere and you may encounter them a lot in various Ubuntu and Virtualbox version. I downloaded the last versions of both and I am yet infected. https://www.virtualbox.org/ticket/12879). I could do whole new thread on why you can't ask newcomers to use Virtualbox (currently, at least). I ran into is a whole patch set to make CPython compile on MinGW (https://bugs.python.org/issue3871#msg199695). But it is not denying it's very experimental, and I know I would again spent useless hours trying to get it work rather than joyfully improving Python, and that's exactly what I do not want to happen. Getting ready to contribute to CPython pure python modules from an standard, average mr-everyone Windows PC for a beginner-to-medium contributor only require few megabytes of internet and few minutes of his time: getting a tarball of CPython sources (or cloning the github CPython mirror)**, a basic text editor and msys-git. The step further, if doing some -even basic- C code is required, implies downloading 9GB of Visual Studio and countless hours for it to be ready to use. I think downloading the whole Visual Studio suite is a huge stopper to contribute further for an average medium-or-below-contributor. I think (and I must not be the only one since CPython is to be moved to github), that barriers to contribute to CPython should be set to the lowest. Of course my situation is a bit special but I think it represents daily struggle of a *lot* of non-western programmer (at least for limited internet)(even here in Australia, landline limited internet connections are very common). It's not a big deal if the MinGW result build is twenty time slower or if some of the most advanced modules can't be build. But everyone programmer should be able to easily make some C hacks and get them to work. Hoping you'll be receptive to my pleas, Cheers * I am currently picking fruits in the regional Australia. I live in a van and have internet through with smartphone through an EDGE connection. I can plug the laptop in the farm but not in the van. ** No fresh programmer use mercurial unless he has a gun pointed on his head.

10 11

Re: [Python-Dev] Python should be easily compilable on Windows with MinGW
by Alexander Walters Feb. 27, 2016

Feb. 27, 2016

You mean honestly pointing out what would happen with a suggestion? It is a horrifically bad idea. I didn't say they were bad people. On 2/26/2016 13:14, Brian Curtin wrote: > The attitude in these responses is counter productive and not really > how it works on this list. > > On Fri, Feb 26, 2016 at 1:10 PM, Alexander Walters > <tritium-list(a)sdamon.com> wrote: >> Ok, fine. Bring a windows build bot online. And also take on the support >> burden of guiding people to which version of which compiler you use for each >> of the currently supported python versions. And go ahead and write the pep >> to change how wheel distributions work (which will effectively kill them, so >> yeah, good side benefit there.) >> >> Want to kill python on windows for anything that needs a c extension? go >> ahead, release one version of python with 2 ABIs. >> >> What do I know. >> >> >> On 2/26/2016 13:05, Dan Stromberg wrote: >>> But what do you really think? >>> >>> IMO, windows builds probably should do both visual studio and mingw. >>> That is, there probably should be two builds on windows, since there's >>> no clear consensus about which to use. >>> >>> I certainly prefer mingw over visual studio - and I have adequate >>> bandwidth for either. >>> >>> >>> On Fri, Feb 26, 2016 at 9:55 AM, Alexander Walters >>> <tritium-list(a)sdamon.com> wrote: >>>> No. >>>> >>>> Visual Studio is a solid compiler suit, mingw is a jenky mess, especially >>>> when you try and move to 64bit (where I don't think there is one true >>>> version of mingw). I'm sorry that Visual Studio makes it very hard for >>>> you >>>> to contribute, but changing THE compiler of the distribution from the >>>> platform compiler, especially when we FINALLY got a stable abi with it, >>>> is >>>> going to be a non starter. >>>> >>>> Compiling on MinGW for your own edification is fine, but that's not the >>>> build platform for windows python, nor should it be. Contributions are, >>>> and >>>> should continue to be, tested against Visual Studio. >>>> >>>> >>>> On 2/26/2016 05:12, Mathieu Dupuy wrote: >>>>> Hi. >>>>> I am currently working on adding some functionality on a standard >>>>> library module (http://bugs.python.org/issue15873). The Python part >>>>> went fine, but now I have to do the C counterpart, and I have ran into >>>>> in several problems, which, stacked up, are a huge obstacle to easily >>>>> contribute further. Currently, despite I could work, I can't go >>>>> further >>>>> on my patch. >>>>> >>>>> I am currently working in very limited network, CPU and time >>>>> ressources* which are quite uncommon in the western world, but are >>>>> much less in the rest of the world. I have a 2GB/month mobile data >>>>> plan and a 100KB/s speed. For the C part of my patch, I should >>>>> download Visual Studio. The Express Edition 2015 is roughly 9GB. I >>>>> can't afford that. >>>>> >>>>> I downloaded Virtualbox and two Linux netinstall (Ubuntu 15.10 and >>>>> Fedora 23). Shortly, I couldn't get something working quickly and >>>>> simply (quickly = less than 2 hours, downloading time NOT included, >>>>> which is anyway way too already much). What went wrong and why it went >>>>> wrong could be a whole new thread and is outside of the scope of this >>>>> message. >>>>> Let me precise this : at my work I use many virtualbox instances >>>>> automatically fired and run in parallel to test new deployments and >>>>> run unittests. I like this tool, >>>>> but despite its simple look, it (most of the time) can not be used >>>>> simply by a profane. The concepts it requires you to understand are >>>>> not intuitive at first sight and there is *always* a thing that go >>>>> wrong (guest additions, mostly).(for example : Ubuntu and Virtualbox >>>>> shipped for a moment a broken version of mount.vboxsf, preventing >>>>> sharing folder to mount. Despite it's fixed, the broken releases >>>>> spread everywhere and you may encounter them a lot in various Ubuntu >>>>> and Virtualbox version. I downloaded the last versions of both and I >>>>> am yet infected. https://www.virtualbox.org/ticket/12879). I could do >>>>> whole new thread on why you can't ask newcomers to use Virtualbox >>>>> (currently, at least). >>>>> >>>>> I ran into is a whole patch set to make CPython compile on MinGW >>>>> (https://bugs.python.org/issue3871#msg199695). But it is not denying >>>>> it's very experimental, and I know I would again spent useless hours >>>>> trying to get it work rather than joyfully improving Python, and >>>>> that's exactly what I do not want to happen. >>>>> >>>>> Getting ready to contribute to CPython pure python modules from an >>>>> standard, average mr-everyone Windows PC for a beginner-to-medium >>>>> contributor only require few megabytes of internet and few minutes of >>>>> his >>>>> time: getting a tarball of CPython sources (or cloning the github >>>>> CPython >>>>> mirror)**, a basic text editor and msys-git. The step further, if doing >>>>> some -even basic- C code is required, implies downloading 9GB of Visual >>>>> Studio and countless hours for it to be ready to use. >>>>> I think downloading the whole Visual Studio suite is a huge stopper to >>>>> contribute further for an average medium-or-below-contributor. >>>>> >>>>> I think (and I must not be the only one since CPython is to be moved >>>>> to github), that barriers to contribute to CPython should be set to >>>>> the lowest. >>>>> Of course my situation is a bit special but I think it represents >>>>> daily struggle of a *lot* of non-western programmer (at least for >>>>> limited internet)(even here in Australia, landline limited internet >>>>> connections are very common). >>>>> It's not a big deal if the MinGW result build is twenty time slower or >>>>> if some of the most advanced modules can't be build. But everyone >>>>> programmer should be able to easily make some C hacks and get them to >>>>> work. >>>>> >>>>> Hoping you'll be receptive to my pleas, >>>>> Cheers >>>>> >>>>> >>>>> * I am currently picking fruits in the regional Australia. I live in a >>>>> van >>>>> and have internet through with smartphone through an EDGE connection. I >>>>> can >>>>> plug the laptop in the farm but not in the van. >>>>> ** No fresh programmer use mercurial unless he has a gun pointed on his >>>>> head. >>>>> _______________________________________________ >>>>> Python-Dev mailing list >>>>> Python-Dev(a)python.org >>>>> https://mail.python.org/mailman/listinfo/python-dev >>>>> Unsubscribe: >>>>> >>>>> https://mail.python.org/mailman/options/python-dev/tritium-list%40sdamon.com >>>> >>>> _______________________________________________ >>>> Python-Dev mailing list >>>> Python-Dev(a)python.org >>>> https://mail.python.org/mailman/listinfo/python-dev >>>> Unsubscribe: >>>> https://mail.python.org/mailman/options/python-dev/drsalists%40gmail.com >> >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev(a)python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/brian%40python.org

2 1

Summary of Python tracker Issues
by Python tracker Feb. 26, 2016

Feb. 26, 2016

ACTIVITY SUMMARY (2016-02-19 - 2016-02-26) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 5437 ( +5) closed 32764 (+46) total 38201 (+51) Open issues with patches: 2378 Issues opened (25) ================== #26393: random.shuffled http://bugs.python.org/issue26393 opened by palaviv #26394: Have argparse provide ability to require a fallback value be p http://bugs.python.org/issue26394 opened by quabla #26396: Create json.JSONType http://bugs.python.org/issue26396 opened by brett.cannon #26403: Catch FileNotFoundError in socketserver.DatagramRequestHandler http://bugs.python.org/issue26403 opened by desbma #26404: socketserver context manager http://bugs.python.org/issue26404 opened by palaviv #26407: csv.writer.writerows masks exceptions from __iter__ http://bugs.python.org/issue26407 opened by Ilja Everilä #26410: "incompatible pointer type" while compiling Python3.5.1 http://bugs.python.org/issue26410 opened by Devyn Johnson #26414: os.defpath too permissive http://bugs.python.org/issue26414 opened by jbeck #26415: Out of memory, trying to parse a 35MB dict http://bugs.python.org/issue26415 opened by A. Skrobov #26418: multiprocessing.pool.ThreadPool eats up memories http://bugs.python.org/issue26418 opened by renlifeng #26420: IDEL for Python 3.5.1 for x64 Windows exits when pasted a stri http://bugs.python.org/issue26420 opened by tats.u. #26421: string_richcompare invalid check Py_NotImplemented http://bugs.python.org/issue26421 opened by yuriy_levchenko #26423: Integer overflow in wrap_lenfunc() on 64-bit build of Windows http://bugs.python.org/issue26423 opened by Dave Hibbitts #26425: 'TypeError: object of type 'NoneType' has no len()' in 'splitd http://bugs.python.org/issue26425 opened by Konrad #26432: Add partial.kwargs http://bugs.python.org/issue26432 opened by serhiy.storchaka #26433: urllib.urlencode() does not explain how to handle unicode http://bugs.python.org/issue26433 opened by Thomas Güttler #26434: multiprocessing cannot spawn grandchild from a Windows service http://bugs.python.org/issue26434 opened by schlamar #26436: Add the regex-dna benchmark http://bugs.python.org/issue26436 opened by serhiy.storchaka #26437: asyncio create_server() not always accepts the 'port' paramete http://bugs.python.org/issue26437 opened by xdegaye #26439: ctypes.util.find_library fails when ldconfig/glibc not availab http://bugs.python.org/issue26439 opened by Michael.Felt #26440: tarfile._FileInFile.seekable is broken in stream mode http://bugs.python.org/issue26440 opened by Bill Lee #26441: email.charset: to_splittable and from_splittable are not there http://bugs.python.org/issue26441 opened by martin.panter #26442: Doc refers to xmlrpc.client but means xmlrpc.server http://bugs.python.org/issue26442 opened by Valentin.Lorentz #26443: cross building extensions picks up host headers http://bugs.python.org/issue26443 opened by hundeboll #26444: Fix 2 typos on ElementTree docs http://bugs.python.org/issue26444 opened by Ismail s Most recent 15 issues with no replies (15) ========================================== #26444: Fix 2 typos on ElementTree docs http://bugs.python.org/issue26444 #26443: cross building extensions picks up host headers http://bugs.python.org/issue26443 #26442: Doc refers to xmlrpc.client but means xmlrpc.server http://bugs.python.org/issue26442 #26441: email.charset: to_splittable and from_splittable are not there http://bugs.python.org/issue26441 #26433: urllib.urlencode() does not explain how to handle unicode http://bugs.python.org/issue26433 #26432: Add partial.kwargs http://bugs.python.org/issue26432 #26418: multiprocessing.pool.ThreadPool eats up memories http://bugs.python.org/issue26418 #26396: Create json.JSONType http://bugs.python.org/issue26396 #26393: random.shuffled http://bugs.python.org/issue26393 #26391: Specialized sub-classes of Generic never call __init__ http://bugs.python.org/issue26391 #26383: benchmarks (perf.py): number of decimal places in csv output http://bugs.python.org/issue26383 #26373: asyncio: add support for async context manager on streams? http://bugs.python.org/issue26373 #26363: __builtins__ propagation is misleading described in exec and e http://bugs.python.org/issue26363 #26359: CPython build options for out-of-the box performance http://bugs.python.org/issue26359 #26358: mmap.mmap.__iter__ is broken (yields bytes instead of ints) http://bugs.python.org/issue26358 Most recent 15 issues waiting for review (15) ============================================= #26444: Fix 2 typos on ElementTree docs http://bugs.python.org/issue26444 #26443: cross building extensions picks up host headers http://bugs.python.org/issue26443 #26436: Add the regex-dna benchmark http://bugs.python.org/issue26436 #26432: Add partial.kwargs http://bugs.python.org/issue26432 #26423: Integer overflow in wrap_lenfunc() on 64-bit build of Windows http://bugs.python.org/issue26423 #26414: os.defpath too permissive http://bugs.python.org/issue26414 #26404: socketserver context manager http://bugs.python.org/issue26404 #26403: Catch FileNotFoundError in socketserver.DatagramRequestHandler http://bugs.python.org/issue26403 #26393: random.shuffled http://bugs.python.org/issue26393 #26388: Disabling changing sys.argv[0] with runpy.run_module(...alter_ http://bugs.python.org/issue26388 #26387: Crash calling sqlite3_close with invalid pointer http://bugs.python.org/issue26387 #26386: tkinter - Treeview - .selection_add and selection_toggle http://bugs.python.org/issue26386 #26385: the call of tempfile.NamedTemporaryFile fails and leaves a fil http://bugs.python.org/issue26385 #26384: UnboundLocalError in socket._sendfile_use_sendfile http://bugs.python.org/issue26384 #26382: List object memory allocator http://bugs.python.org/issue26382 Top 10 most discussed issues (10) ================================= #26423: Integer overflow in wrap_lenfunc() on 64-bit build of Windows http://bugs.python.org/issue26423 15 msgs #26221: awaiting asyncio.Future swallows StopIteration http://bugs.python.org/issue26221 11 msgs #26385: the call of tempfile.NamedTemporaryFile fails and leaves a fil http://bugs.python.org/issue26385 9 msgs #26415: Out of memory, trying to parse a 35MB dict http://bugs.python.org/issue26415 8 msgs #19475: Add timespec optional flag to datetime isoformat() to choose t http://bugs.python.org/issue19475 7 msgs #26376: Tkinter root window won't close if packed. http://bugs.python.org/issue26376 7 msgs #26039: More flexibility in zipfile interface http://bugs.python.org/issue26039 6 msgs #26281: Clear sys.path_importer_cache from importlib.invalidate_caches http://bugs.python.org/issue26281 6 msgs #26323: Add assert_called() and assert_called_once() methods for mock http://bugs.python.org/issue26323 6 msgs #21042: ctypes.util.find_library() should return full pathname instead http://bugs.python.org/issue21042 5 msgs Issues closed (44) ================== #1429: FD leak in SocketServer when request handler throws exception http://bugs.python.org/issue1429 closed by martin.panter #5824: SocketServer.DatagramRequestHandler Broken under Linux http://bugs.python.org/issue5824 closed by martin.panter #21996: gettarinfo method does not handle files without text string na http://bugs.python.org/issue21996 closed by martin.panter #22088: base64 module still ignores non-alphabet characters http://bugs.python.org/issue22088 closed by martin.panter #22468: Tarfile using fstat on GZip file object http://bugs.python.org/issue22468 closed by martin.panter #23430: socketserver.BaseServer.handle_error() should not catch exitin http://bugs.python.org/issue23430 closed by martin.panter #24229: pathlib.Path should have a copy() method http://bugs.python.org/issue24229 closed by serhiy.storchaka #25080: The example-code for making XML-RPC requests through proxy, fa http://bugs.python.org/issue25080 closed by berker.peksag #25136: Python doesn't find Xcode 7 SDK stub libraries http://bugs.python.org/issue25136 closed by ned.deily #25139: socketserver.ThreadingMixIn exception handler: Just a little r http://bugs.python.org/issue25139 closed by martin.panter #25801: ResourceWarning in test_zipfile64 http://bugs.python.org/issue25801 closed by SilentGhost #25913: base64.a85decode adobe flag incorrectly utilizes <~ as a marke http://bugs.python.org/issue25913 closed by serhiy.storchaka #26261: NamedTemporaryFile documentation is vague about the `name` att http://bugs.python.org/issue26261 closed by martin.panter #26302: cookies module allows commas in keys http://bugs.python.org/issue26302 closed by jason.coombs #26366: Use “.. versionadded” over “.. versionchanged” where a http://bugs.python.org/issue26366 closed by rhettinger #26367: importlib.__import__ does not fail for invalid relative import http://bugs.python.org/issue26367 closed by brett.cannon #26390: hashlib's pbkdf2_hmac documentation "rounds" does not match so http://bugs.python.org/issue26390 closed by martin.panter #26392: socketserver.BaseServer.close_server should stop serve_forever http://bugs.python.org/issue26392 closed by palaviv #26395: asyncio does not support yielding from recvfrom (socket/udp) http://bugs.python.org/issue26395 closed by Simon Bernier St-Pierre #26397: Tweak importlib Example of importlib.import_module() to use im http://bugs.python.org/issue26397 closed by brett.cannon #26398: cgi.escape() Can Lead To XSS and HTML Vulnerabilities http://bugs.python.org/issue26398 closed by gregory.p.smith #26399: CSV Injection Vulnerability http://bugs.python.org/issue26399 closed by maciej.szulik #26400: SyntaxError when running Python 2.7 interpreter with subproces http://bugs.python.org/issue26400 closed by giumas #26401: Error in documentation for "compile" built-in function http://bugs.python.org/issue26401 closed by berker.peksag #26402: Regression in Python 3.5 xmlrpc.client, raises RemoteDisconnec http://bugs.python.org/issue26402 closed by martin.panter #26405: tkinter askopenfilename doubleclick issue on windows http://bugs.python.org/issue26405 closed by serhiy.storchaka #26406: getaddrinfo is thread-safe on NetBSD and OpenBSD http://bugs.python.org/issue26406 closed by ned.deily #26408: pep-8 requires a few corrections http://bugs.python.org/issue26408 closed by python-dev #26409: Support latest Tcl/Tk on future versions of Mac installer http://bugs.python.org/issue26409 closed by ned.deily #26411: Suggestion concerning compile-time warnings http://bugs.python.org/issue26411 closed by brett.cannon #26412: Segmentation Fault: 11 http://bugs.python.org/issue26412 closed by christian.heimes #26413: python 3.5.1 uses wrong registry in system-wide installation http://bugs.python.org/issue26413 closed by eryksun #26416: Deprecate the regex_v8, telco, and spectral_norm benchmarks http://bugs.python.org/issue26416 closed by brett.cannon #26417: Default IDLE 2.7.11 configuration files are out-of-sync on OS http://bugs.python.org/issue26417 closed by ned.deily #26422: printing 1e23 and up is incorrect http://bugs.python.org/issue26422 closed by eric.smith #26424: QPyNullVariant http://bugs.python.org/issue26424 closed by haypo #26426: email examples: incorrect use of email.headerregistry.Address http://bugs.python.org/issue26426 closed by berker.peksag #26427: w* format in PyArg_ParseTupleAndKeywords for optional argument http://bugs.python.org/issue26427 closed by serhiy.storchaka #26428: The range for xrange() is too narrow on Windows 64-bit http://bugs.python.org/issue26428 closed by serhiy.storchaka #26429: os.path.dirname returns empty string instead of "." when file http://bugs.python.org/issue26429 closed by serhiy.storchaka #26430: quote marks problem on loaded file http://bugs.python.org/issue26430 closed by SilentGhost #26431: string template substitute tests http://bugs.python.org/issue26431 closed by serhiy.storchaka #26435: Fix versionadded/versionchanged documentation directives http://bugs.python.org/issue26435 closed by python-dev #26438: Complete your registration to Python tracker -- key4g5ti2VWPYC http://bugs.python.org/issue26438 closed by christian.heimes

1 0

PEP 493: HTTPS verification migration tools for Python 2.7
by Nick Coghlan Feb. 25, 2016

Feb. 25, 2016

Hi folks, Since the last discussion back in November (just after the RHEL 7.2 release), I've rewritten PEP 493 to be a standards track PEP targeting Python 2.7.12. Barry also kindly volunteered to serve as BDFL-Delegate, so we have a clear path to pronouncement if nobody notices any new problems or concerns that didn't come up in previous discussions :) The PEP now focuses on adding two new configuration mechanisms to the PEP 476 backport in Python 2.7: * turning off default certificate verification through a Python API * turning off default certificate verification through an environment variable Both of these are defined in such a way that if backported to a version where default verification is still off by default, they can be used to turn it *on*. The original file based configuration proposal to change the default behaviour of older versions is also still covered, but moved to a clearly optional section. (The gist of that section is now "If you backport this capability, aim to stay consistent with already existing backports of it") Regards, Nick. ========================================== PEP: 493 Title: HTTPS verification migration tools for Python 2.7 Version: $Revision$ Last-Modified: $Date$ Author: Nick Coghlan <ncoghlan(a)gmail.com>, Robert Kuska <rkuska(a)redhat.com>, Marc-André Lemburg <mal(a)lemburg.com> BDFL-Delegate: Barry Warsaw Status: Draft Type: Standards Track Content-Type: text/x-rst Created: 10-May-2015 Python-Version: 2.7.12 Post-History: 06-Jul-2015, 11-Nov-2015, 24-Nov-2015, 24-Feb-2016 Abstract ======== PEP 476 updated Python's default handling of HTTPS certificates in client modules to align with certificate handling in web browsers, by validating that the certificates received belonged to the server the client was attempting to contact. The Python 2.7 long term maintenance series was judged to be in scope for this change, with the new behaviour introduced in the Python 2.7.9 maintenance release. This has created a non-trivial barrier to adoption for affected Python 2.7 maintenance releases, so this PEP proposes additional Python 2.7 specific features that allow system administrators and other users to more easily decouple the decision to verify server certificates in HTTPS client modules from the decision to update to newer Python 2.7 maintenance releases. Rationale ========= PEP 476 changed Python's default behaviour to align with expectations established by web browsers in regards to the semantics of HTTPS URLs: starting with Python 2.7.9 and 3.4.3, HTTPS clients in the standard library validate server certificates by default. However, it is also the case that this change *does* cause problems for infrastructure administrators operating private intranets that rely on self-signed certificates, or otherwise encounter problems with the new default certificate verification settings. To manage these kinds of situations, web browsers provide users with "click through" warnings that allow the user to add the server's certificate to the browser's certificate store. Network client tools like ``curl`` and ``wget`` offer options to switch off certificate checking entirely (by way of ``curl --insecure`` and ``wget --no-check-certificate``, respectively). At a different layer of the technology stack, Linux security modules like `SELinux` and `AppArmor`, while enabled by default by distribution vendors, offer relatively straightforward mechanisms for turning them off. At the moment, no such convenient mechanisms exist to disable Python's default certificate checking for a whole process. PEP 476 did attempt to address this question, by covering how to revert to the old settings process wide by monkeypatching the ``ssl`` module to restore the old behaviour. Unfortunately, the ``sitecustomize.py`` based technique proposed to allow system administrators to disable the feature by default in their Standard Operating Environment definition has been determined to be insufficient in at least some cases. The specific case that led to the initial creation of this PEP is the one where a Linux distributor aims to provide their users with a `smoother migration path < https://bugzilla.redhat.com/show_bug.cgi?id=1173041>`__ than the standard one provided by consuming upstream CPython 2.7 releases directly, but other potential challenges have also been pointed out with updating embedded Python runtimes and other user level installations of Python. Rather than allowing a plethora of mutually incompatibile migration techniques to bloom, this PEP proposes an additional feature to be added to Python 2.7.12 to make it easier to revert a process to the past behaviour of skipping certificate validation in HTTPS client modules. It also provides additional recommendations to redistributors backporting these features to versions of Python prior to Python 2.7.9. Alternatives ------------ In the absence of clear upstream guidance and recommendations, commercial redistributors will still make their own design decisions in the interests of their customers. The main approaches available are: * Continuing to rebase on new Python 2.7.x releases, while providing no additional assistance beyond the mechanisms defined in PEP 476 in migrating from unchecked to checked hostnames in standard library HTTPS clients * Gating availability of the changes in default handling of HTTPS connections on upgrading from Python 2 to Python 3 * For Linux distribution vendors, gating availability of the changes in default handling of HTTPS connections on upgrading to a new operating system version * Implementing one or both of the backport suggestions described in this PEP, regardless of the formal status of the PEP Scope Limitations ================= These changes are being proposed purely as tools for helping to manage the transition to the new default certificate handling behaviour in the context of Python 2.7. They are not being proposed as new features for Python 3, as it is expected that the vast majority of client applications affected by this problem without the ability to update the application itself will be Python 2 applications. It would likely be desirable for a future version of Python 3 to allow the default certificate handling for secure protocols to be configurable on a per-protocol basis, but that question is beyond the scope of this PEP. Requirements for capability detection ===================================== As the proposals in this PEP aim to facilitate backports to earlier Python versions, the Python version number cannot be used as a reliable means for detecting them. Instead, they are designed to allow the presence or absence of the feature to be determined using the following technique:: python -c "import ssl; ssl.<_relevant_attribute>" This will fail with `AttributeError` (and hence a non-zero return code) if the relevant capability is not available. The feature detection attributes defined by this PEP are: * ``ssl._https_verify_certificates``: runtime configuration API * ``ssl._https_verify_envvar``: environment based configuration * ``ssl._cert_verification_config``: file based configuration (PEP 476 opt-in) The marker attributes are prefixed with an underscore to indicate the implementation dependent and security sensitive nature of these capabilities. Feature: Configuration API ========================== This change is proposed for inclusion in CPython 2.7.12 and later CPython 2.7.x releases. It consists of a new ``ssl._https_verify_certificates()`` to specify the default handling of HTTPS certificates in standard library client libraries. It is not proposed to forward port this change to Python 3, so Python 3 applications that need to support skipping certificate verification will still need to define their own suitable security context. Feature detection ----------------- The marker attribute on the ``ssl`` module related to this feature is the ``ssl._https_verify_certificates`` function itself. Specification ------------- The ``ssl._https_verify_certificates`` function will work as follows:: def _https_verify_certificates(enable=True): """Verify server HTTPS certificates by default?""" global _create_default_https_context if enable: _create_default_https_context = create_default_context else: _create_default_https_context = _create_unverified_context If called without arguments, or with ``enable`` set to a true value, then standard library client modules will subsequently verify HTTPS certificates by default, otherwise they will skip verification. If called with ``enable`` set to a false value, then standard library client modules will subsequently skip verifying HTTPS certificates by default. Security Considerations ----------------------- The inclusion of this feature will allow security sensitive applications to include the following forward-compatible snippet in their code:: if hasattr(ssl, "_https_verify_certificates"): ssl._https_verify_certificates() Some developers may also choose to opt out of certificate checking using ``ssl._https_verify_certificates(enable=False)``. This doesn't introduce any major new security concerns, as monkeypatching the affected internal APIs was already possible. Feature: environment based configuration ======================================== This change is proposed for inclusion in CPython 2.7.12 and later CPython 2.7.x releases. It consists of a new ``PYTHONHTTPSVERIFY`` environment variable that can be set to ``'0'`` to disable the default verification without modifying the application source code (which may not even be available in cases of bytecode-only application distribution) It is not proposed to forward port this change to Python 3, so Python 3 applications that need to support skipping certificate verification will still need to define their own suitable security context. Feature detection ----------------- The marker attribute on the ``ssl`` module related to this feature is: * the ``ssl._https_verify_envvar`` attribute, giving the name of environment variable affecting the default behaviour This not only makes it straightforward to detect the presence (or absence) of the capability, it also makes it possible to programmatically determine the relevant environment variable name. Specification ------------- Rather than always defaulting to the use of ``ssl.create_default_context``, the ``ssl`` module will be modified to: * read the ``PYTHONHTTPSVERIFY`` environment variable when the module is first imported into a Python process * set the ``ssl._create_default_https_context`` function to be an alias for ``ssl._create_unverified_context`` if this environment variable is present and set to ``'0'`` * otherwise, set the ``ssl._create_default_https_context`` function to be an alias for ``ssl.create_default_context`` as usual Example implementation ---------------------- :: _https_verify_envvar = 'PYTHONHTTPSVERIFY' def _get_https_context_factory(): if not sys.flags.ignore_environment: config_setting = os.environ.get(_https_verify_envvar) if config_setting == '0': return _create_unverified_context return create_default_context _create_default_https_context = _get_https_context_factory() Security Considerations ----------------------- Relative to the behaviour in Python 3.4.3+ and Python 2.7.9->2.7.11, this approach does introduce a new downgrade attack against the default security settings that potentially allows a sufficiently determined attacker to revert Python to the default behaviour used in CPython 2.7.8 and earlier releases. However, such an attack requires the ability to modify the execution environment of a Python process prior to the import of the ``ssl`` module, and any attacker with such access would already be able to modify the behaviour of the underlying OpenSSL implementation. Interaction with Python virtual environments -------------------------------------------- The default setting is read directly from the process environment, and hence works the same way regardless of whether or not the interpreter is being run inside an activated Python virtual environment. Reference Implementation ======================== A patch for Python 2.7 implementing the above two features is attached to the `relevant tracker issue <http://bugs.python.org/issue23857>`__. Backporting this PEP to earlier Python versions =============================================== If this PEP is accepted, then commercial Python redistributors may choose to backport the per-process configuration mechanisms defined in this PEP to base versions older than Python 2.7.9, *without* also backporting PEP 476's change to the default behaviour of the overall Python installation. Such a backport would differ from the mechanism proposed in this PEP solely in the default behaviour when ``PYTHONHTTPSVERIFY`` was not set at all: it would continue to default to skipping certificate validation. In this case, if the ``PYTHONHTTPSVERIFY`` environment variable is defined, and set to anything *other* than ``'0'``, then HTTPS certificate verification should be enabled. Feature detection ----------------- There's no specific attribute indicating that this situation applies. Rather, it is indicated by the ``ssl._https_verify_certificates`` and ``ssl._https_verify_envvar`` attributes being present in a Python version that is nominally older than Python 2.7.12. Specification ------------- Implementing this backport involves backporting the changes in PEP 466, 476 and this PEP, with the following change to the handling of the ``PYTHONHTTPSVERIFY`` environment variable in the ``ssl`` module: * read the ``PYTHONHTTPSVERIFY`` environment variable when the module is first imported into a Python process * set the ``ssl._create_default_https_context`` function to be an alias for ``ssl.create_default_context`` if this environment variable is present and set to any value other than ``'0'`` * otherwise, set the ``ssl._create_default_https_context`` function to be an alias for ``ssl._create_unverified_context`` Example implementation ---------------------- :: _https_verify_envvar = 'PYTHONHTTPSVERIFY' def _get_https_context_factory(): if not sys.flags.ignore_environment: config_setting = os.environ.get(_https_verify_envvar) if config_setting != '0': return create_default_context return _create_unverified_context _create_default_https_context = _get_https_context_factory() def _disable_https_default_verification(): """Skip verification of HTTPS certificates by default""" global _create_default_https_context _create_default_https_context = _create_unverified_context Security Considerations ----------------------- This change would be a strict security upgrade for any Python version that currently defaults to skipping certificate validation in standard library HTTPS clients. The technical trade-offs to be taken into account relate largely to the magnitude of the PEP 466 backport also required rather than to anything security related. Interaction with Python virtual environments -------------------------------------------- The default setting is read directly from the process environment, and hence works the same way regardless of whether or not the interpreter is being run inside an activated Python virtual environment. Backporting PEP 476 to earlier Python versions ============================================== The backporting approach described above leaves the default HTTPS certificate verification behaviour of a Python 2.7 installation unmodified: verifying certificates still needs to be opted into on a per-connection or per-process basis. To allow the default behaviour of the entire installation to be modified without breaking backwards compatibility, Red Hat designed a configuration mechanism for the system Python 2.7 installation in Red Hat Enterprise Linux 7.2+ that provides: * an opt-in model that allows the decision to enable HTTPS certificate verification to be made independently of the decision to upgrade to the operating system version where the feature was first backported * the ability for system administrators to set the default behaviour of Python applications and scripts run directly in the system Python installation * the ability for the redistributor to consider changing the default behaviour of *new* installations at some point in the future without impacting existing installations that have been explicitly configured to skip verifying HTTPS certificates by default As it only affects backports to earlier releases of Python 2.7, this change is not proposed for inclusion in upstream CPython, but rather is offered as a recommendation to other redistributors that choose to offer a similar feature to their users. This PEP doesn't take a position on whether or not this particular change is a good idea - rather, it suggests that *if* a redistributor chooses to go down the path of making the default behaviour configurable in a version of Python older than Python 2.7.9, then maintaining a consistent approach across redistributors would be beneficial for users. However, this approach SHOULD NOT be used for any Python installation that advertises itself as providing Python 2.7.9 or later, as most Python users will have the reasonable expectation that all such environments will verify HTTPS certificates by default. Feature detection ----------------- The marker attribute on the ``ssl`` module related to this feature is:: _cert_verification_config = '<path to configuration file>' This not only makes it straightforward to detect the presence (or absence) of the capability, it also makes it possible to programmatically determine the relevant configuration file name. Recommended modifications to the Python standard library -------------------------------------------------------- The recommended approach to backporting the PEP 476 modifications to an earlier point release is to implement the following changes relative to the default PEP 476 behaviour implemented in Python 2.7.9+: * modify the ``ssl`` module to read a system wide configuration file when the module is first imported into a Python process * define a platform default behaviour (either verifying or not verifying HTTPS certificates) to be used if this configuration file is not present * support selection between the following three modes of operation: * ensure HTTPS certificate verification is enabled * ensure HTTPS certificate verification is disabled * delegate the decision to the redistributor providing this Python version * set the ``ssl._create_default_https_context`` function to be an alias for either ``ssl.create_default_context`` or ``ssl._create_unverified_context`` based on the given configuration setting. Recommended file location ------------------------- As the PEP authors are not aware of any vendors providing long-term support releases targeting Windows, Mac OS X or \*BSD systems, this approach is currently only specifically defined for Linux system Python installations. The recommended configuration file name on Linux systems is ``/etc/python/cert-verification.cfg``. The ``.cfg`` filename extension is recommended for consistency with the ``pyvenv.cfg`` used by the ``venv`` module in Python 3's standard library. Recommended file format ----------------------- The configuration file should use a ConfigParser ini-style format with a single section named ``[https]`` containing one required setting ``verify``. The suggested section name is taken from the "https" URL schema passed to affected client APIs. Permitted values for ``verify`` are: * ``enable``: ensure HTTPS certificate verification is enabled by default * ``disable``: ensure HTTPS certificate verification is disabled by default * ``platform_default``: delegate the decision to the redistributor providing this particular Python version If the ``[https]`` section or the ``verify`` setting are missing, or if the ``verify`` setting is set to an unknown value, it should be treated as if the configuration file is not present. Example implementation ---------------------- :: _cert_verification_config = '/etc/python/cert-verification.cfg' def _get_https_context_factory(): # Check for a system-wide override of the default behaviour context_factories = { 'enable': create_default_context, 'disable': _create_unverified_context, 'platform_default': _create_unverified_context, # For now :) } import ConfigParser config = ConfigParser.RawConfigParser() config.read(_cert_verification_config) try: verify_mode = config.get('https', 'verify') except (ConfigParser.NoSectionError, ConfigParser.NoOptionError): verify_mode = 'platform_default' default_factory = context_factories.get('platform_default') return context_factories.get(verify_mode, default_factory) _create_default_https_context = _get_https_context_factory() Security Considerations ----------------------- The specific recommendations for this backporting case are designed to work for privileged, security sensitive processes, even those being run in the following locked down configuration: * run from a locked down administrator controlled directory rather than a normal user directory (preventing ``sys.path[0]`` based privilege escalation attacks) * run using the ``-E`` switch (preventing ``PYTHON*`` environment variable based privilege escalation attacks) * run using the ``-s`` switch (preventing user site directory based privilege escalation attacks) * run using the ``-S`` switch (preventing ``sitecustomize`` based privilege escalation attacks) The intent is that the *only* reason HTTPS verification should be getting turned off installation wide when using this approach is because: * an end user is running a redistributor provided version of CPython rather than running upstream CPython directly * that redistributor has decided to provide a smoother migration path to verifying HTTPS certificates by default than that being provided by the upstream project * either the redistributor or the local infrastructure administrator has determined that it is appropriate to retain the default pre-2.7.9 behaviour (at least for the time being) Using an administrator controlled configuration file rather than an environment variable has the essential feature of providing a smoother migration path, even for applications being run with the ``-E`` switch. Interaction with Python virtual environments -------------------------------------------- This setting is scoped by the interpreter installation and affects all Python processes using that interpreter, regardless of whether or not the interpreter is being run inside an activated Python virtual environment. Origins of this recommendation ------------------------------ This recommendation is based on the backporting approach adopted for Red Hat Enterprise Linux 7.2, as published in the original July 2015 draft of this PEP and described in detail in `this KnowledgeBase article <https://access.redhat.com/articles/2039753>`__. Red Hat's patches implementing this backport for Python 2.7.5 can be found in the `CentOS git repository <https://git.centos.org/commit/rpms!python.git/refs!heads!c7>`__. Recommendation for combined feature backports ============================================= If a redistributor chooses to backport the environment variable based configuration setting from this PEP to a modified Python version that also implements the configuration file based PEP 476 backport, then the environment variable should take precedence over the system-wide configuration setting. This allows the setting to be changed for a given user or application, regardless of the installation-wide default behaviour. Example implementation ---------------------- :: _https_verify_envvar = 'PYTHONHTTPSVERIFY' _cert_verification_config = '/etc/python/cert-verification.cfg' def _get_https_context_factory(): # Check for an environmental override of the default behaviour if not sys.flags.ignore_environment: config_setting = os.environ.get(_https_verify_envvar) if config_setting is not None: if config_setting == '0': return _create_unverified_context return create_default_context # Check for a system-wide override of the default behaviour context_factories = { 'enable': create_default_context, 'disable': _create_unverified_context, 'platform_default': _create_unverified_context, # For now :) } import ConfigParser config = ConfigParser.RawConfigParser() config.read(_cert_verification_config) try: verify_mode = config.get('https', 'verify') except (ConfigParser.NoSectionError, ConfigParser.NoOptionError): verify_mode = 'platform_default' default_factory = context_factories.get('platform_default') return context_factories.get(verify_mode, default_factory) _create_default_https_context = _get_https_context_factory() Copyright ========= This document has been placed into the public domain. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

3 6

Thank you.
by Alexander Walters Feb. 23, 2016

Feb. 23, 2016

I don't know if it is appropriate for this list, or not. I don't exactly care. As much as I might disagree with some of you... Thank you. Your work on Python has made a notable difference in how happy my life is.

4 3

Disabling changing sys.argv[0] with runpy.run_module(...alter_sys=True)
by Mike Kaplinskiy Feb. 22, 2016

Feb. 22, 2016

Hey folks, I hope this is the right list for this sort of thing (python-ideas seemed more far-fetched). For some context: there is currently a issue with pex that causes sys.modules lookups to stop working for __main__. In turns this makes unittest.run() & pkg_resources.resource_* fail. The root cause is that pex uses runpy.run_module with alter_sys=False. The fix should be to just pass alter_sys=True, but that changes sys.argv[0] and various existing pex files depend on that being the pex file. You can read more at https://github.com/pantsbuild/pex/pull/211 . Conservatively, I'd like to propose adding an argument to disable this behavior. The current behavior breaks a somewhat reasonable invariant that you can restart your program via `os.execv([sys.executable] + sys.argv)`. Moreover it might be user-friendly to add a `argv=sys.argv[1:]` argument to set & restore the full arguments to the module, where `argv=None` disables argv[0] switching. What do you think? Mike.

4 5

Python 3.2.7 and 3.3.7
by Georg Brandl Feb. 21, 2016

Feb. 21, 2016

Hi all, I'm planning to release 3.2.7 and 3.3.7 at the end of February. There will be a release candidate on Feb 20, and the final on Feb 27, if there is no holdup. These are both security (source-only) releases. 3.2.7 will be the last release from the 3.2 series. If you know of any patches that should go in, make sure to commit them in time or notify me. Thanks, Georg

1 1