[RELEASED] Python 3.5.0a4 is now available
On behalf of the Python development community and the Python 3.5 release team, I'm thrilled to announce the availability of Python 3.5.0a4. Python 3.5.0a4 is the fourth and alpha release of Python 3.5, which will be the next major release of Python. Python 3.5 is still under development, and is not yet complete. This is a preview release, and its use is not recommended for production settings. The next release of Python 3.5 will be 3.5.0b1, the first beta release. Python 3.5 will enter "feature freeze" at this time; no new features will be added to 3.5 after this point. Python 3.5.0b1 is scheduled to be released May 22, 2015. Three important notes for Windows users about Python 3.5.0a4: * If you have previously installed Python 3.5.0a1, you may need to manually uninstall it before installing Python 3.5.0a4 (issue23612). * If installing Python 3.5.0a4 as a non-privileged user, you may need to escalate to administrator privileges to install an update to your C runtime libraries. * There is now a third type of Windows installer for Python 3.5. In addition to the conventional installer and the web-based installer, Python 3.5 now has an embeddable installer designed to be run as part of a larger application's installer for apps using or extending Python. You can find Python 3.5.0a4 here: https://www.python.org/downloads/release/python-350a4/ Happy hacking, //arry/
On 20 April 2015 at 09:16, Larry Hastings <larry@hastings.org> wrote:
Probably a question for Steve mostly, but how does this work, exactly? I see it's an exe - I was sort of expecting a zip file. Specifically, I was considering using this to make a build of Vim, with Python support, using a copy of Python included with Vim (so no reliance on there being a "system" install of Python). As Vim is open source, "build it yourself", I typically just compile vim and then zip up the application directory. So I'm not clear how an exe "embeddable" installer fits into that scheme. Apologies if the exe is just a self-extracting archive, and the answer is just "run it and tell it where to dump the files". I've not even had a chance to get to somewhere I can download the installer to try it yet :-) Paul
Paul Moore wrote:
I made it a self-extracting RAR file so it could be signed, but I've already had multiple people query it so the next release will probably just be a plain ZIP file. I just need to figure out some reliable way of validating the download other than GPG, since I'd like installers to be able to do the download transparently and ideally without hard-coding hash values. I might add a CSV of SHA hashes to the zip too.
It is indeed just a run-and-dump extractor. I haven't had a chance to write up any docs for it yet, but there are some open bugs I want to fix first (specifically http://bugs.python.org/issue23955) before this becomes too formalized. Cheers, Steve
Paul
On 21 April 2015 at 23:05, Steve Dower <Steve.Dower@microsoft.com> wrote:
It is indeed just a run-and-dump extractor. I haven't had a chance to write up any docs for it yet, but there are some open bugs I want to fix first (specifically http://bugs.python.org/issue23955) before this becomes too formalized.
Thanks. See, I should have just run the random code I found on the internet and everything would have worked out alright :-) But seriously, thanks for doing this. I can see it being *really* useful. Paul
Donald Stufft wrote:
Is this version statically linked by any chance?
No, there's no change to the compilation process, so you can get exactly the same result by using the regular installer and copying the files around. Not sure if this is what you're referring to, but on Windows DLLs are always loaded from alongside the executable before searching in other locations. I learned at PyCon that some platforms embed full paths for .so's (I'd always just assumed that there was a similar resolution process), but this is not the case here. Dropping all the DLLs and PYDs in the same location is sufficient to make sure you always load the right files, unless sys.path has been filled in with incorrect registry values (the bug I referenced). Cheers, Steve
My use case is using PyInstaller to attempt to create a single file executable. Doing it on Windows was giving a strange error message about mscrvt or something so I thought maybe I needed to statically compile Python. I was hoping maybe this thing would have done that for me so I didn’t need to figure out how. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 21 April 2015 at 23:05, Steve Dower <Steve.Dower@microsoft.com> wrote:
I made it a self-extracting RAR file so it could be signed, but I've already had multiple people query it so the next release will probably just be a plain ZIP file. I just need to figure out some reliable way of validating the download other than GPG, since I'd like installers to be able to do the download transparently and ideally without hard-coding hash values. I might add a CSV of SHA hashes to the zip too.
You could probably just leave it as is (or make it a self-extracting zip file) and just describe it on the web page as "Windows amd64 embeddable self-extracting archive". People are (I think) pretty used to the idea that they can open a self-extracting archive in tools like 7-zip, so those who didn't want to run the exe could do that (and would know they could). Obviously extracting that way you don't get the signature check, but that's to be expected. Paul
On 22 April 2015 at 13:45, Paul Moore <p.f.moore@gmail.com> wrote:
Whoops, no - I changed my mind. If you double click on the downloaded file (which I just did) it unpacks it into the directory you downloaded the exe to, with no option to put it anywhere else, and no UI telling you what it's doing. That's going to annoy people badly. Better make it a simple zipfile in that case. Paul (off to tidy up his download directory :-()
Whoops, sorry. Yeah, I knew about that behavior, but in hindsight it's obviously going to be a surprise for others :) One plain zip file coming up for the next release. All the binaries will be signed and paranoid people can check the GPG sig and embed their own hashes if not the files themselves. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Paul Moore<mailto:p.f.moore@gmail.com> Sent: 4/22/2015 5:48 To: Steve Dower<mailto:Steve.Dower@microsoft.com> Cc: Larry Hastings<mailto:larry@hastings.org>; Python Dev<mailto:python-dev@python.org> Subject: Re: [python-committers] [RELEASED] Python 3.5.0a4 is now available On 22 April 2015 at 13:45, Paul Moore <p.f.moore@gmail.com> wrote:
Whoops, no - I changed my mind. If you double click on the downloaded file (which I just did) it unpacks it into the directory you downloaded the exe to, with no option to put it anywhere else, and no UI telling you what it's doing. That's going to annoy people badly. Better make it a simple zipfile in that case. Paul (off to tidy up his download directory :-()
On 20 April 2015 at 09:16, Larry Hastings <larry@hastings.org> wrote:
Probably a question for Steve mostly, but how does this work, exactly? I see it's an exe - I was sort of expecting a zip file. Specifically, I was considering using this to make a build of Vim, with Python support, using a copy of Python included with Vim (so no reliance on there being a "system" install of Python). As Vim is open source, "build it yourself", I typically just compile vim and then zip up the application directory. So I'm not clear how an exe "embeddable" installer fits into that scheme. Apologies if the exe is just a self-extracting archive, and the answer is just "run it and tell it where to dump the files". I've not even had a chance to get to somewhere I can download the installer to try it yet :-) Paul
Paul Moore wrote:
I made it a self-extracting RAR file so it could be signed, but I've already had multiple people query it so the next release will probably just be a plain ZIP file. I just need to figure out some reliable way of validating the download other than GPG, since I'd like installers to be able to do the download transparently and ideally without hard-coding hash values. I might add a CSV of SHA hashes to the zip too.
It is indeed just a run-and-dump extractor. I haven't had a chance to write up any docs for it yet, but there are some open bugs I want to fix first (specifically http://bugs.python.org/issue23955) before this becomes too formalized. Cheers, Steve
Paul
On 21 April 2015 at 23:05, Steve Dower <Steve.Dower@microsoft.com> wrote:
It is indeed just a run-and-dump extractor. I haven't had a chance to write up any docs for it yet, but there are some open bugs I want to fix first (specifically http://bugs.python.org/issue23955) before this becomes too formalized.
Thanks. See, I should have just run the random code I found on the internet and everything would have worked out alright :-) But seriously, thanks for doing this. I can see it being *really* useful. Paul
Donald Stufft wrote:
Is this version statically linked by any chance?
No, there's no change to the compilation process, so you can get exactly the same result by using the regular installer and copying the files around. Not sure if this is what you're referring to, but on Windows DLLs are always loaded from alongside the executable before searching in other locations. I learned at PyCon that some platforms embed full paths for .so's (I'd always just assumed that there was a similar resolution process), but this is not the case here. Dropping all the DLLs and PYDs in the same location is sufficient to make sure you always load the right files, unless sys.path has been filled in with incorrect registry values (the bug I referenced). Cheers, Steve
My use case is using PyInstaller to attempt to create a single file executable. Doing it on Windows was giving a strange error message about mscrvt or something so I thought maybe I needed to statically compile Python. I was hoping maybe this thing would have done that for me so I didn’t need to figure out how. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 21 April 2015 at 23:05, Steve Dower <Steve.Dower@microsoft.com> wrote:
I made it a self-extracting RAR file so it could be signed, but I've already had multiple people query it so the next release will probably just be a plain ZIP file. I just need to figure out some reliable way of validating the download other than GPG, since I'd like installers to be able to do the download transparently and ideally without hard-coding hash values. I might add a CSV of SHA hashes to the zip too.
You could probably just leave it as is (or make it a self-extracting zip file) and just describe it on the web page as "Windows amd64 embeddable self-extracting archive". People are (I think) pretty used to the idea that they can open a self-extracting archive in tools like 7-zip, so those who didn't want to run the exe could do that (and would know they could). Obviously extracting that way you don't get the signature check, but that's to be expected. Paul
On 22 April 2015 at 13:45, Paul Moore <p.f.moore@gmail.com> wrote:
Whoops, no - I changed my mind. If you double click on the downloaded file (which I just did) it unpacks it into the directory you downloaded the exe to, with no option to put it anywhere else, and no UI telling you what it's doing. That's going to annoy people badly. Better make it a simple zipfile in that case. Paul (off to tidy up his download directory :-()
Whoops, sorry. Yeah, I knew about that behavior, but in hindsight it's obviously going to be a surprise for others :) One plain zip file coming up for the next release. All the binaries will be signed and paranoid people can check the GPG sig and embed their own hashes if not the files themselves. Cheers, Steve Top-posted from my Windows Phone ________________________________ From: Paul Moore<mailto:p.f.moore@gmail.com> Sent: 4/22/2015 5:48 To: Steve Dower<mailto:Steve.Dower@microsoft.com> Cc: Larry Hastings<mailto:larry@hastings.org>; Python Dev<mailto:python-dev@python.org> Subject: Re: [python-committers] [RELEASED] Python 3.5.0a4 is now available On 22 April 2015 at 13:45, Paul Moore <p.f.moore@gmail.com> wrote:
Whoops, no - I changed my mind. If you double click on the downloaded file (which I just did) it unpacks it into the directory you downloaded the exe to, with no option to put it anywhere else, and no UI telling you what it's doing. That's going to annoy people badly. Better make it a simple zipfile in that case. Paul (off to tidy up his download directory :-()
participants (4)
-
Donald Stufft -
Larry Hastings -
Paul Moore -
Steve Dower