[Python-Dev] New hash algorithms: SHA3, SHAKE, BLAKE2, truncated SHA512
Hi everybody, I have three hashing-related patches for Python 3.6 that are waiting for review. Altogether the three patches add ten new hash algorithms to the hashlib module: SHA3 (224, 256, 384, 512), SHAKE (SHA3 XOF 128, 256), BLAKE2 (blake2b, blake2s) and truncated SHA512 (224, 256). SHA-3 / SHAKE: https://bugs.python.org/issue16113 BLAKE2: https://bugs.python.org/issue26798 SHA512/224 / SHA512/256: https://bugs.python.org/issue26834 I like to push the patches during the sprints at PyCon. Please assist with reviews. Regards, Christian ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devinabox has moved to GitHub
Should these notes come with version requirements/minimums? "OS X users should be told to download XCode from the Apple App Store ahead of time." "If new contributors think they may be doing C development, suggest the use of LLVM + clang as this provides better error reporting than gcc." "For Windows users, ask them to download and install Visual Studio Community edition ahead of time." On Sun, May 8, 2016 at 4:41 PM, Brett Cannon wrote: > https://github.com/python/devinabox > > The single issue for devinabox has moved to its own issue tracker, so > there's no need to worry about those issues cluttering b.p.o in the future. > I have made the Python core team I created on GitHub last week have write > privileges and Nick and I as admins on the repository. I have also turned on > the CLA bot for the repository (FYI > https://github.com/python/the-knights-who-say-ni has that bot's code). > > I've asked Georg, Antoine, and Benjamin to tell me what I need to do to shut > off -- either by making it read-only or just deleting -- > hg.python.org/devinabox. > > Now that the migration has seriously begun, the next repos will be the peps > and devguide (slightly more complicated thanks to needing to update commands > for building their online versions). There's also the benchmarks repo, but > that might not get migrated if we start from scratch (see the speed@ ML > about that). > > As for cpython, I've been asked to talk about it at the language summit > where I will start a conversation about what the minimal feature set will > need to be to migrate. Once we have settled on what has to be in place to > migrate the cpython repo then we can start working on that TODO list. > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/leewangzhong%2Bpython%40gmail.com > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devinabox has moved to GitHub
On Wed, 25 May 2016 at 10:24 Franklin? Lee wrote: > Should these notes come with version requirements/minimums? > > "OS X users should be told to download XCode from the Apple App Store > ahead of time." > "If new contributors think they may be doing C development, suggest > the use of LLVM + clang as this provides better error reporting than > gcc." > "For Windows users, ask them to download and install Visual Studio > Community edition ahead of time." > If you want to submit a PR to say "the latest" that's fine, but I don't know if any of those tools really promote downloading older versions such that one has to worry about it. > > On Sun, May 8, 2016 at 4:41 PM, Brett Cannon wrote: > > https://github.com/python/devinabox > > > > The single issue for devinabox has moved to its own issue tracker, so > > there's no need to worry about those issues cluttering b.p.o in the > future. > > I have made the Python core team I created on GitHub last week have write > > privileges and Nick and I as admins on the repository. I have also > turned on > > the CLA bot for the repository (FYI > > https://github.com/python/the-knights-who-say-ni has that bot's code). > > > > I've asked Georg, Antoine, and Benjamin to tell me what I need to do to > shut > > off -- either by making it read-only or just deleting -- > > hg.python.org/devinabox. > > > > Now that the migration has seriously begun, the next repos will be the > peps > > and devguide (slightly more complicated thanks to needing to update > commands > > for building their online versions). There's also the benchmarks repo, > but > > that might not get migrated if we start from scratch (see the speed@ ML > > about that). > > > > As for cpython, I've been asked to talk about it at the language summit > > where I will start a conversation about what the minimal feature set will > > need to be to migrate. Once we have settled on what has to be in place > to > > migrate the cpython repo then we can start working on that TODO list. > > > > ___ > > Python-Dev mailing list > > Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > > https://mail.python.org/mailman/options/python-dev/leewangzhong%2Bpython%40gmail.com > > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devinabox has moved to GitHub
It's just that I don't know whether any of them require particular versions. If you say the latest is fine, then okay. On Wed, May 25, 2016 at 1:37 PM, Brett Cannon wrote: > > > On Wed, 25 May 2016 at 10:24 Franklin? Lee > wrote: >> >> Should these notes come with version requirements/minimums? >> >> "OS X users should be told to download XCode from the Apple App Store >> ahead of time." >> "If new contributors think they may be doing C development, suggest >> the use of LLVM + clang as this provides better error reporting than >> gcc." >> "For Windows users, ask them to download and install Visual Studio >> Community edition ahead of time." > > > If you want to submit a PR to say "the latest" that's fine, but I don't know > if any of those tools really promote downloading older versions such that > one has to worry about it. > >> >> >> On Sun, May 8, 2016 at 4:41 PM, Brett Cannon wrote: >> > https://github.com/python/devinabox >> > >> > The single issue for devinabox has moved to its own issue tracker, so >> > there's no need to worry about those issues cluttering b.p.o in the >> > future. >> > I have made the Python core team I created on GitHub last week have >> > write >> > privileges and Nick and I as admins on the repository. I have also >> > turned on >> > the CLA bot for the repository (FYI >> > https://github.com/python/the-knights-who-say-ni has that bot's code). >> > >> > I've asked Georg, Antoine, and Benjamin to tell me what I need to do to >> > shut >> > off -- either by making it read-only or just deleting -- >> > hg.python.org/devinabox. >> > >> > Now that the migration has seriously begun, the next repos will be the >> > peps >> > and devguide (slightly more complicated thanks to needing to update >> > commands >> > for building their online versions). There's also the benchmarks repo, >> > but >> > that might not get migrated if we start from scratch (see the speed@ ML >> > about that). >> > >> > As for cpython, I've been asked to talk about it at the language summit >> > where I will start a conversation about what the minimal feature set >> > will >> > need to be to migrate. Once we have settled on what has to be in place >> > to >> > migrate the cpython repo then we can start working on that TODO list. >> > >> > ___ >> > Python-Dev mailing list >> > Python-Dev@python.org >> > https://mail.python.org/mailman/listinfo/python-dev >> > Unsubscribe: >> > >> > https://mail.python.org/mailman/options/python-dev/leewangzhong%2Bpython%40gmail.com >> > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] peps: Short subsection on annotating coroutines (Ivan L, #225).
On Tue, 24 May 2016 at 12:20 guido.van.rossum wrote: > https://hg.python.org/peps/rev/50c3f5aefbb7 > changeset: 6341:50c3f5aefbb7 > user:Guido van Rossum > date:Tue May 24 12:18:54 2016 -0700 > summary: > Short subsection on annotating coroutines (Ivan L, #225). > > files: > pep-0484.txt | 34 ++ > 1 files changed, 34 insertions(+), 0 deletions(-) > > > diff --git a/pep-0484.txt b/pep-0484.txt > --- a/pep-0484.txt > +++ b/pep-0484.txt > @@ -1015,6 +1015,40 @@ > ellipsis, i.e. the above example is literally what you would write. > > > +Annotating generator functions and coroutines > +- > + > +The return type of generator functions can be annotated by > +the generic type ``Generator[yield_type, send_type, > +return_type]`` provided by ``typing.py`` module:: > + > + def echo_round() -> Generator[int, float, str]: > + res = yield > + while res: > + res = yield round(res) > + return 'OK' > + > +Coroutines introduced in PEP 492 are annotated with the same syntax as > +ordinary functions. However, the return type annotation corresponds to the > +type of ``await`` expression, not to the coroutine type:: > + > + async def spam(ignored: int) -> str: > + return 'spam' > + > + async def foo(): > + bar = await spam(42) # type: str > If the coroutine has multiple await expressions that return different types then do you simply use a Union to express that? -Brett > + > +The ``typing.py`` module also provides generic ABCs ``Awaitable``, > +``AsyncIterable``, and ``AsyncIterator`` for situations where more precise > +types cannot be specified:: > + > + def op() -> typing.Awaitable[str]: > + if cond: > + return spam(42) > + else: > + return asyncio.Future(...) > + > + > Compatibility with other uses of function annotations > = > > > -- > Repository URL: https://hg.python.org/peps > ___ > Python-checkins mailing list > python-check...@python.org > https://mail.python.org/mailman/listinfo/python-checkins > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] runtime dlls on Windows
Hi folks, The standard build of Py3.5 for Windows is built with VS2015 (correct??) And it includes the runtime dlls it needs. However, we've found that wxPython wheels for win32 (not sure about win64) also need: MSVCP140.DLL So: wxPython could include that of course, But it looks like it's getting included with the Matplotlib wheels already (so folks with Matplotlib can run wx). I'm just guessing, but this looks like the standard run time for C++ with that compiler. Python itself doesn't use C++, of course, but maybe we should include that dll with Python anyway -- that way folks can build wheels of packages with C++ extensions in the normal way, and those wheels will "just work", and we don't have to have every individual package ship the same dll. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runtime dlls on Windows
Wouldn't downloading the Microsoft C++ Runtime 2015 also work? Many recent computers already have it pre-installed. -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On May 25, 2016 2:31 PM, "Chris Barker" wrote: > Hi folks, > > The standard build of Py3.5 for Windows is built with VS2015 (correct??) > And it includes the runtime dlls it needs. > > However, we've found that wxPython wheels for win32 (not sure about win64) > also need: > > MSVCP140.DLL > > So: wxPython could include that of course, But it looks like it's getting > included with the Matplotlib wheels already (so folks with Matplotlib can > run wx). I'm just guessing, but this looks like the standard run time > for C++ with that compiler. > > Python itself doesn't use C++, of course, but maybe we should include that > dll with Python anyway -- that way folks can build wheels of packages with > C++ extensions in the normal way, and those wheels will "just work", and > we don't have to have every individual package ship the same dll. > > -CHB > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R(206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com > > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runtime dlls on Windows
On Wed, May 25, 2016 at 12:37 PM, Ryan Gonzalez wrote: > Wouldn't downloading the Microsoft C++ Runtime 2015 also work? > I'm sure it would -- I know that installing the entire MSVC2015 Community Edition does... but the point here is that end users should be able to: pip install something and if there is a binary wheel for something, it should work without them having to install something else. (why MS doesn't ship ALL their runtimes with eh OS is beyond me...) As it stands now, there are two options: 1) users need to install something else themselves: the runtime, that particular dll, the compiler... 2) every package maintainer that uses C++ needs to ship that dll with the binary wheels. If we put the dll into the python binary, then it would "just work" -CHB > Many recent computers already have it pre-installed. > > -- > Ryan > [ERROR]: Your autotools build scripts are 200 lines longer than your > program. Something’s wrong. > http://kirbyfan64.github.io/ > On May 25, 2016 2:31 PM, "Chris Barker" wrote: > >> Hi folks, >> >> The standard build of Py3.5 for Windows is built with VS2015 (correct??) >> And it includes the runtime dlls it needs. >> >> However, we've found that wxPython wheels for win32 (not sure about >> win64) also need: >> >> MSVCP140.DLL >> >> So: wxPython could include that of course, But it looks like it's getting >> included with the Matplotlib wheels already (so folks with Matplotlib can >> run wx). I'm just guessing, but this looks like the standard run time >> for C++ with that compiler. >> >> Python itself doesn't use C++, of course, but maybe we should include >> that dll with Python anyway -- that way folks can build wheels of packages >> with C++ extensions in the normal way, and those wheels will "just work", >> and we don't have to have every individual package ship the same dll. >> >> -CHB >> >> >> -- >> >> Christopher Barker, Ph.D. >> Oceanographer >> >> Emergency Response Division >> NOAA/NOS/OR&R(206) 526-6959 voice >> 7600 Sand Point Way NE (206) 526-6329 fax >> Seattle, WA 98115 (206) 526-6317 main reception >> >> chris.bar...@noaa.gov >> >> ___ >> Python-Dev mailing list >> Python-Dev@python.org >> https://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com >> >> -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runtime dlls on Windows
On Thu, May 26, 2016 at 6:26 AM, Chris Barker wrote:
> the point here is that end users should be able to:
>
> pip install something
>
> and if there is a binary wheel for something, it should work without them
> having to install something else. (why MS doesn't ship ALL their runtimes
> with eh OS is beyond me...)
Agreed with that, but meh.
> As it stands now, there are two options:
>
> 1) users need to install something else themselves: the runtime, that
> particular dll, the compiler...
> 2) every package maintainer that uses C++ needs to ship that dll with the
> binary wheels.
>
> If we put the dll into the python binary, then it would "just work"
Counting your conclusion as option 3, you're offering the status quo
and two competing solutions to it. I agree that the status quo is
unideal; a binary wheel should either include or be able to fetch
everything necessary for a supported platform. But why should CPython
package a runtime that it doesn't use? Which is more common - someone
uses two C++ modules, or someone uses none of them?
I don't know how hard it is for the wheels to ship the DLL ("hard"
here including any licensing or versioning issues, as well as the
actual effort involved), but from a purely logical standpoint, it
seems the most sane option. So I'm in favour of your option 2.
ChrisA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runtime dlls on Windows
On 05/25/2016 04:37 PM, Ryan Gonzalez wrote: Wouldn't downloading the Microsoft C++ Runtime 2015 also work? Many recent computers already have it pre-installed. Even though the download seems to be only 14 MB (I don't have a Windows machine, so I cannot assure that just the file on MS website is enough), it is an inconvenience. Additionally, I don't know how clear it will be for the average Python user on Windows that a C++ runtime is missing. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runtime dlls on Windows
On Wed, May 25, 2016 at 12:29 PM, Chris Barker wrote: > > Hi folks, > > The standard build of Py3.5 for Windows is built with VS2015 (correct??) And > it includes the runtime dlls it needs. > > However, we've found that wxPython wheels for win32 (not sure about win64) > also need: > > MSVCP140.DLL > > So: wxPython could include that of course, But it looks like it's getting > included with the Matplotlib wheels already (so folks with Matplotlib can run > wx). I'm just guessing, but this looks like the standard run time for C++ > with that compiler. > > Python itself doesn't use C++, of course, but maybe we should include that > dll with Python anyway -- that way folks can build wheels of packages with > C++ extensions in the normal way, and those wheels will "just work", and we > don't have to have every individual package ship the same dll. The other challenge with this proposal is that Python 3.5.0 and 3.5.1 have already shipped without this .dll. So the most we could hope for is for it to be included in 3.5.2, and then wxPython and Matplotlib would either have to continue shipping it anyway, or else accept that their wheels actually require 3.5.2+ and will be broken if installed onto 3.5.0 or 3.5.1. And unfortunately there's no way in wheel metadata to express this kind of requirement -- wheels assume that all 3.5.x are both forwards and backwards compatible. So it would just be a weird unexplained breakage that some users would see. An alternative approach would be to stick MSVCP140.DLL into a tiny shim wheel and upload that to PyPI, and then wxPython and matplotlib's windows wheels could declare a dependency on this msvcp410 wheel. Basically this is the idea of my pynativelib proposal, though in this case you would only be using a small piece of the full proposal: https://mail.python.org/pipermail/wheel-builders/2016-April/90.html (I really need to get back to that... if anyone wants to help sprint on this at PyCon let me know :-)) -n -- Nathaniel J. Smith -- https://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] runtime dlls on Windows
On 25May2016 1229, Chris Barker wrote: Hi folks, The standard build of Py3.5 for Windows is built with VS2015 (correct??) And it includes the runtime dlls it needs. However, we've found that wxPython wheels for win32 (not sure about win64) also need: MSVCP140.DLL There are two different versions of this DLL for each architecture (same name). So: wxPython could include that of course, But it looks like it's getting included with the Matplotlib wheels already (so folks with Matplotlib can run wx). I'm just guessing, but this looks like the standard run time for C++ with that compiler. Python itself doesn't use C++, of course, but maybe we should include that dll with Python anyway -- that way folks can build wheels of packages with C++ extensions in the normal way, and those wheels will "just work", and we don't have to have every individual package ship the same dll. Unfortunately, it won't "just work". More often than not, it will break in weird and very difficult to diagnose ways, as the version of msvcp140.dll changes on a regular basis (there are at least four different version of it "in the wild" since VS 2015 released, not counting the preview releases before mid-last year). Importantly, it will break forward compatibility. We are already on the hook to keep shipping vcruntime140.dll for all 3.5 (and probably 3.6) releases, and if binary packages are built with later versions of VS then they'll need to include a (hypothetical) vcruntime150.dll (which distutils will already do, because I added that functionality). Other than that, every dependency of Python 3.5+ is forwards-compatible with new operating systems and compilers. There's also a slippery slope argument that would legitimately justify shipping all sorts of "common" dependencies with the core product. I chose to draw the line at "needed by the core Python product", rather than "created by Microsoft" or "used by many packages". (Hence vcruntime140.dll is included, despite not having forwards-compatibility, and I tried real hard to avoid including that one too.) Finally, unless we demand users are administrators for every install, we will quickly have many Python installs using versions of msvcp140.dll (or any other dependency) with security vulnerabilities, with no way to update them other than a full Python release. Installing the regular runtime (which is patched automatically) or as part of a package (which can be independently updated) is far more feasible. I really don't want to be doing security updates for 15 years just to keep an unused DLL secure. Hopefully that helps explain the position somewhat. I'm happy to go into more detail on any of these issues if anyone would like (potentially just linking to where I've previously discussed it either here, on bugs.p.o or on my blog). Cheers, Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] devinabox has moved to GitHub
On 26 May 2016 at 04:54, Franklin? Lee wrote: > It's just that I don't know whether any of them require particular > versions. If you say the latest is fine, then okay. For working on CPython trunk, the latest is fine. Things only have the potential to get trickier when building extensions for older Python versions (since you need to make sure the binaries are compatible), but that's not a topic devinabox concerns itself with. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
