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
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
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/
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
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/
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
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/