Mailman 3 August 2017 - Python-Dev

Python's Windows code-signing certificate
by Steve Dower 10 Aug '17

10 Aug '17

Just a heads-up, primarily for Marc-Andre, but letting everyone know for awareness. Next time we need to renew the PSF code signing certificate used for Windows releases, we will need to use a different CA. Our current certificate is from StartCom, who are losing their status as a trusted CA on Windows, which means any of their certificates issued after the 26th of September this year will be treated as invalid: https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wos… The certificate we have right now is valid through February 2019, so there's no urgency to change (unless we want to avoid the risk of "accidental certificate revocation", which is one of the reasons Microsoft has lost trust in StartCom). Because the revocation of the root CA has a start date, all of our current releases and future releases with the current certificate will be fine. Since this will likely harm StartCom's business, it's very likely that they will get their act together and by the time we come to renew they'll be acceptable again. But we probably do want to be planning ahead to switch CA regardless. And for our macOS and Linux friends who may be uncertain what I'm referring to: this is the certificate embedded in the installer and every executable binary in our Windows distributions. It has nothing to do with GPG or the signature files you can download from python.org (these are still associated with my personal and completely unverified key, which is fine since nobody on Windows actually cares about GPG :) ). Cheers, Steve

1 0

Py_Main() seems to be a NOOP
by Patrick Rutkowski 10 Aug '17

10 Aug '17

I'm working on Windows with Python 3.6. I'm trying to make a wWinMain() GUI application that uses an embedded python interpreter. I'm having various issues with being unable to load extension modules, but I won't go into that now because I've tracked my issue down to a much simpler test case. To begin, consider the source code of pythonw.exe: /* Minimal main program -- everything is loaded from the library. */ #include "Python.h" #define WIN32_LEAN_AND_MEAN #include <windows.h> int WINAPI wWinMain( HINSTANCE hInstance, /* handle to current instance */ HINSTANCE hPrevInstance, /* handle to previous instance */ LPWSTR lpCmdLine, /* pointer to command line */ int nCmdShow /* show state of window */ ) { return Py_Main(__argc, __wargv); } Now consider a simple python script, which I save in source.py f = open('C:\\Users\\rutski\\Desktop\\hello.txt', 'w') f.write('Hello World!\n') f.flush() f.close() and run with > pythonw.exe source.py This produces the file `hello.txt` with the expected output. Now I create a new Visual Studio solution. I make it Win32 project, choose "Windows Application" and "Empty Project." I create a new source file main.c and I copy-paste the source code of from pythonw (with Py_Main and all that). Now I add the following settings: C:\Users\rutski\Documents\python\PCbuild\amd64 --- Library Search Directory C:\Users\rutski\Documents\python\Include --- Include Directory C:\Users\rutski\Documents\python\PC --- Include Directory (for pyconfig.h) I choose "Debug | x64" and hit build. I pop open cmd.exe, browse to where mything.exe is, and execute > mything.exe source.py But this time nothing happens. No hello.txt gets created. I get no crash window or error message. I do not get thrown into a debugger. I just get no result. Am I missing some build flags here or something? I'm running the __exact__ same C code that pythonw.exe is, but mine isn't working. What gives? I can't even seem to get Py_Main() to execute some python code from within my own application, so trying to write my own embed code is basically hopeless. If anybody could shed any light on this it would be much appreciated! -Patrick

2 2

bugs.python.org appears down
by Terry Reedy 09 Aug '17

09 Aug '17

And not just for me, for last couple of hours. http://downforeveryoneorjustme.com/bugs.python.org --- Terry Jan Reedy

1 0

first post introduction and question regarding lto
by Soldea, Octavian 09 Aug '17

09 Aug '17

Hello This is my first post after I just have subscribed to the Python-Dev mailing list. In this context, the welcome confirmation message suggested to introduce myself. My name is Octavian Soldea and I am with the Python optimization team in DSLOT group in Intel, Santa Clara, California. In the past I have received a PhD in Computer Science from the Technion, Israel Institute of Technology in Computer Vision. I would like to ask regarding the possibility of compiling Python with lto only. My question is if is the community interested to enable the possibility of compiling Python with lto only, i.e. without pgo? I have followed https://bugs.python.org/issue29243 and https://bugs.python.org/issue29641 however, it is not clear if the separate compilation is already implemented. In my opinion this is a good option since pgo is not always desired. Best regards, Octavian

6 13

Interrupt thread.join() with Ctrl-C / KeyboardInterrupt on Windows
by Jonathan Slenders 09 Aug '17

09 Aug '17

Hi all, Is it possible that thread.join() cannot be interrupted on Windows, while it can be on Linux? Would this be a bug, or is it by design? import threading, time def wait(): time.sleep(1000) t = threading.Thread(target=wait) t.start() t.join() # Press Control-C now. It stops on Linux, while it hangs on Windows. Tested on Python 3.6. Thanks, Jonathan

4 6

[RELEASED] Python 3.4.7 is now available
by Larry Hastings 09 Aug '17

09 Aug '17

On behalf of the Python development community and the Python 3.4 release team, I'm pleased to announce the availability of Python 3.4.7. Python 3.4 is now in "security fixes only" mode. This is the final stage of support for Python 3.4. Python 3.4 now only receives security fixes, not bug fixes, and Python 3.4 releases are source code only--no more official binary installers will be produced. You can find Python 3.4.7 here: https://www.python.org/downloads/release/python-347/ Happy Pythoning, //arry/

1 0

[ANN] Daily Windows builds of Python 3.x
by Steve Dower 08 Aug '17

08 Aug '17

Hi all As part of a deal with Zach Ware at PyCon, I agreed that if he removed the Subversion dependency from our builds, I would set up daily Windows builds of Python. Zach did an excellent job, and so I am now following through on my half of the deal :) For a while I've been uploading the official releases to nuget.org. These packages can be installed with nuget.exe (latest version always available at https://aka.ms/nugetclidl), which is quickly becoming a standard tool in Microsoft's build toolsets. It's very much a CI-focused package manager, rather than a user-focused one, and CI on Windows was previously an area where it was difficult to use Python. See the official feed at https://www.nuget.org/packages/python, and related packages pythonx86, python2 and python2x86. For people looking for an official "no installer" version of Python for Windows, this is it. And since all the infrastructure was there already, I decided to publish daily builds in a similar way to myget.org: https://www.myget.org/feed/python/package/nuget/pythondaily To install the latest daily build, run nuget.exe with this command: nuget.exe pythondaily -Source https://www.myget.org/F/python/api/v3/index.json (Note that if you already have a "pythondaily" package in that directory, nuget will consider the requirement satisfied. As I said, it's meant for reproducible CI builds rather than users who want to update things in the least amount of keystrokes :) ) The sys.version string contains the short commit hash. Please include this string when reporting bugs in these builds. Also, only the amd64 Release build is available pre-built. >>> sys.version '3.7.0a0 (remotes/origin/master:733d0f63c, Aug 8 2017, 15:56:14) [MSC v.1900 64 bit (AMD64)]' Hopefully this is valuable for people who want to include daily builds in their own test runs or validate recent bug fixes. Cheers, Steve

4 3

[RELEASED] Python 3.5.4 is now available
by Larry Hastings 08 Aug '17

08 Aug '17

On behalf of the Python development community and the Python 3.5 release team, I'm pleased to announce the availability of Python 3.5.4. Python 3.5.4 is the final 3.5 release in "bug fix" mode. The Python 3.5 branch has now transitioned into "security fixes mode"; all future improvements in the 3.5 branch will be security fixes only, and no conventional bug fixes will be merged. You can find Python 3.5.4 here: https://www.python.org/downloads/release/python-354/ Python 3.4.7 final will be released later today. Happy Pythoning, //arry/

2 1

PyThreadState_GET() returns NULL from within PyImport_GetModuleDict()
by Patrick Rutkowski 08 Aug '17

08 Aug '17

I'm working on Windows. I have the following dead simple embedding code that I'm using to test out the python interpreter: ============================================================ Py_SetProgramName(L"MyApp"); Py_SetPath( L"C:\\Users\\rutski\\Documents\\python\\PCBuild\\amd64\\python36.zip;" L"C:\\Users\\rutski\\Documents\\python\\DLLs;" L"C:\\Users\\rutski\\Documents\\python\\lib;" L"C:\\Users\\rutski\\Documents\\python\\PCBuild\\amd64;" L"C:\\Users\\rutski\\Documents\\python;" L"C:\\Users\\rutski\\Documents\\python\\lib\\site-packages"); Py_Initialize(); PyRun_SimpleString( "from time import time,ctime\n" "print('Today is', ctime(time()))\n"); ============================================================ This code crashes trying to access address 0x00000010 from within PyRun_SimpleString(). The sequence of event's is this: 1) PyRun_SimpleString() tries to do AddModule("__main__") 2) AddModule tries to do PyImport_GetModuleDict() 3) PyImport_GetModuleDict() tries to doPyThreadState_GET()->interp 4) PyThreadState_GET() returns NULL, so the ->interp part crashes. The weird thing is that calling PyImport_GetModuleDict() from within my application directly works just fine. Weirder still is that the whole thing actually executes fine if I build a windows command line application with the embed code in main(), and execute it from a terminal. The crash only happens when building a Windows GUI application and calling the embed code in WinMain(). This is a python interpreter that I built from source on windows using PCbuild\build.bat, so that I could track the crash. However, the exact same crash was happening with the stock interpreter provided by the python windows installer. Does anyone have any ideas here? -Patrick

3 4

Python 3.5 has now transitioned to "security fixes only" mode
by Larry Hastings 08 Aug '17

08 Aug '17

The Python 3.5 branch has now entered "security fixes only" mode. No more bugfixes will be accepted into the 3.5 branch. In keeping with our modern workflow, I have changed the permissions on the 3.5 branch on Github so that only release managers can accept PRs into the branch. Please add me to your 3.5 security fix PRs, as I'm the one responsible for accepting them. (This was already true for the 3.4 branch, too.) I neglected to mention it in the release announcement, but this transition also means no more binary installers for 3.5 releases. This signals the end of my interactions with macOS Platform Expert Ned Deily and Windows Platform Expert Steve Dower when making releases. I just wanted to mention what a pleasure it has been working with those two gentlemen for the two Python releases I've RM'd for. They've made me look good every time. Cheers, //arry/

1 0