[Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
Hi,
It's no longer possible to merge any change in the 3.6 branch of
CPython, because the AppVeyor job fails:
https://bugs.python.org/issue34575
It seems like AppVeyor has a build cache and this cache is outdated. I
tried to use the REST API but I'm not allowed to invalidate the cache:
even the most basic REST API query (list my own roles) fails with:
{"message":"You do not have required permissions to perform this action."}
Who ows the "python" AppVeyor project? Can someone please give me the
administrator permission on this project, so I will be able to invalid
the build cache?
Moreover, would it be possible to give me the administrator permission
on the CPython GitHub project, so I would be able to mark the AppVeyor
as optional until the issue is solved (to unblock the workflow at
least)? I promise I will not mess up the Python project ;-)
Thanks in advance,
Victor
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Schedule of the Python 3.7.1 release?
Hi, Someone asked somewhere (oops, I forgot where!) when is Python 3.7.1 scheduled. I wanted to reply when I saw that it was scheduled for 2 months ago: "3.7.1: 2018-07-xx" https://www.python.org/dev/peps/pep-0537/#maintenance-releases Is there any blocker for 3.7.1? I fixed dozens of bugs in the 3.7 branch since 3.7.0 has been released. I'm ashamed of most of them, since I introduced regressions in 3.7. (If you insist, I can name them ;-)) Note: the latest Python activity of Ned Deily, our 3.7 release manager, was an email sent to python-committers mi-July. Victor ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote:
>
> Hi,
>
> It's no longer possible to merge any change in the 3.6 branch of
> CPython, because the AppVeyor job fails:
> https://bugs.python.org/issue34575
>
> It seems like AppVeyor has a build cache and this cache is outdated. I
> tried to use the REST API but I'm not allowed to invalidate the cache:
> even the most basic REST API query (list my own roles) fails with:
>
> {"message":"You do not have required permissions to perform this action."}
>
> Who ows the "python" AppVeyor project? Can someone please give me the
> administrator permission on this project, so I will be able to invalid
> the build cache?
>
> Moreover, would it be possible to give me the administrator permission
> on the CPython GitHub project, so I would be able to mark the AppVeyor
> as optional until the issue is solved (to unblock the workflow at
> least)? I promise I will not mess up the Python project ;-)
I don't appear to have admin rights on Appveyor either. Also, there
doesn't appear to be an appveyor.yml file in the CPython repository,
so I'm not clear how the build process has been configured. Does
anyone have that information? (And I'd strongly recommend that if
we're somehow configuring the builds via the Appveyor UI, we move to
using a config file like we do for Travis, so that diagnosis and fixes
can be done without needing to access the Appveyor admin interface...)
Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Comparisions for collections.Counters
Hello everyone, According to the [doc][1], `collections.Counter` convenience intersection and union functions are meant to help it represent multisets. However, it currently lacks comparisons, which would make sense and seems straightforward to implement. Am I missing something here or should I send a PR ASAP ? :-) Cheers, E [1]: https://docs.python.org/3/library/collections.html#collections.Counter ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Schedule of the Python 3.7.1 release?
On 2018-09-05 11:56, Victor Stinner wrote: > Hi, > > Someone asked somewhere (oops, I forgot where!) when is Python 3.7.1 > scheduled. I wanted to reply when I saw that it was scheduled for 2 > months ago: > > "3.7.1: 2018-07-xx" > https://www.python.org/dev/peps/pep-0537/#maintenance-releases > > Is there any blocker for 3.7.1? I fixed dozens of bugs in the 3.7 > branch since 3.7.0 has been released. I'm ashamed of most of them, > since I introduced regressions in 3.7. (If you insist, I can name them > ;-)) > > Note: the latest Python activity of Ned Deily, our 3.7 release > manager, was an email sent to python-committers mi-July. Hi, can we do a release after the core dev sprints, please? I have like to discuss and land some TLS 1.3 / OpenSSL 1.1.1 related changes and improvements first. Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, 5 Sep 2018 11:03:48 +0100
Paul Moore wrote:
> On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote:
> >
> > Hi,
> >
> > It's no longer possible to merge any change in the 3.6 branch of
> > CPython, because the AppVeyor job fails:
> > https://bugs.python.org/issue34575
> >
> > It seems like AppVeyor has a build cache and this cache is outdated. I
> > tried to use the REST API but I'm not allowed to invalidate the cache:
> > even the most basic REST API query (list my own roles) fails with:
> >
> > {"message":"You do not have required permissions to perform this action."}
> >
> > Who ows the "python" AppVeyor project? Can someone please give me the
> > administrator permission on this project, so I will be able to invalid
> > the build cache?
> >
> > Moreover, would it be possible to give me the administrator permission
> > on the CPython GitHub project, so I would be able to mark the AppVeyor
> > as optional until the issue is solved (to unblock the workflow at
> > least)? I promise I will not mess up the Python project ;-)
>
> I don't appear to have admin rights on Appveyor either. Also, there
> doesn't appear to be an appveyor.yml file in the CPython repository,
> so I'm not clear how the build process has been configured.
For some reason it seems to be located in a hidden directory
(".github/appveyor.yml"). Not the most intuitive decision IMHO.
Travis' own config file ".travis.yml" is still at repository root, which
makes things more confusing.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Schedule of the Python 3.7.1 release?
On 9/5/2018 6:22 AM, Christian Heimes wrote: On 2018-09-05 11:56, Victor Stinner wrote: Hi, Someone asked somewhere (oops, I forgot where!) when is Python 3.7.1 scheduled. I wanted to reply when I saw that it was scheduled for 2 months ago: "3.7.1: 2018-07-xx" https://www.python.org/dev/peps/pep-0537/#maintenance-releases Is there any blocker for 3.7.1? I fixed dozens of bugs in the 3.7 branch since 3.7.0 has been released. I'm ashamed of most of them, since I introduced regressions in 3.7. (If you insist, I can name them ;-)) Note: the latest Python activity of Ned Deily, our 3.7 release manager, was an email sent to python-committers mi-July. Hi, can we do a release after the core dev sprints, please? I have like to discuss and land some TLS 1.3 / OpenSSL 1.1.1 related changes and improvements first. Agreed. I have at least one dataclasses bug I'm planning on addressing, and I'd like to get some feedback on it at the sprints. Eric ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, 5 Sep 2018 at 12:24, Antoine Pitrou wrote:
> For some reason it seems to be located in a hidden directory
> (".github/appveyor.yml"). Not the most intuitive decision IMHO.
> Travis' own config file ".travis.yml" is still at repository root, which
> makes things more confusing.
Thanks, agreed that's confusing. I'd prefer appveyor.yml to be at the
project root, as that's what nearly all projects I deal with do. But
at least I know where it is now :-)
Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
I wrote some notes about our CIs. Link to AppVeyor notes:
https://pythondev.readthedocs.io/ci.html#appveyor
Victor
Le mer. 5 sept. 2018 à 12:04, Paul Moore a écrit :
>
> On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote:
> >
> > Hi,
> >
> > It's no longer possible to merge any change in the 3.6 branch of
> > CPython, because the AppVeyor job fails:
> > https://bugs.python.org/issue34575
> >
> > It seems like AppVeyor has a build cache and this cache is outdated. I
> > tried to use the REST API but I'm not allowed to invalidate the cache:
> > even the most basic REST API query (list my own roles) fails with:
> >
> > {"message":"You do not have required permissions to perform this action."}
> >
> > Who ows the "python" AppVeyor project? Can someone please give me the
> > administrator permission on this project, so I will be able to invalid
> > the build cache?
> >
> > Moreover, would it be possible to give me the administrator permission
> > on the CPython GitHub project, so I would be able to mark the AppVeyor
> > as optional until the issue is solved (to unblock the workflow at
> > least)? I promise I will not mess up the Python project ;-)
>
> I don't appear to have admin rights on Appveyor either. Also, there
> doesn't appear to be an appveyor.yml file in the CPython repository,
> so I'm not clear how the build process has been configured. Does
> anyone have that information? (And I'd strongly recommend that if
> we're somehow configuring the builds via the Appveyor UI, we move to
> using a config file like we do for Travis, so that diagnosis and fixes
> can be done without needing to access the Appveyor admin interface...)
>
> Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, Sep 5, 2018 at 12:55 PM Victor Stinner wrote:
>
> Hi,
>
> It's no longer possible to merge any change in the 3.6 branch of
> CPython, because the AppVeyor job fails:
> https://bugs.python.org/issue34575
>
> It seems like AppVeyor has a build cache and this cache is outdated. I
> tried to use the REST API but I'm not allowed to invalidate the cache:
> even the most basic REST API query (list my own roles) fails with:
>
> {"message":"You do not have required permissions to perform this action."}
>
> Who ows the "python" AppVeyor project? Can someone please give me the
> administrator permission on this project, so I will be able to invalid
> the build cache?
>
> Moreover, would it be possible to give me the administrator permission
> on the CPython GitHub project, so I would be able to mark the AppVeyor
> as optional until the issue is solved (to unblock the workflow at
> least)? I promise I will not mess up the Python project ;-)
I've just made the "continuous-integration/appveyor/pr" status check
optional on the 3.6 branch to unblock the development for now.
Indeed, AppVeyor's REST API doesn't work:
$ curl -H "Authorization: Bearer $APPVEYOR_TOKEN" -H "Content-Type:
application/json" -X DELETE
https://ci.appveyor.com/api/projects/python/cpython/buildcache
{"message":"You do not have required permissions to perform this action."}
I'm going to try to make you an admin on python/cpython, but I find
GitHub's user/team management UI a bit confusing, so no promise :)
--Berker
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, Sep 5, 2018 at 6:23 AM Antoine Pitrou wrote:
> On Wed, 5 Sep 2018 11:03:48 +0100
> Paul Moore wrote:
> > On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote:
> > > Who ows the "python" AppVeyor project?
That seems to have fallen to me for the most part.
> > > Can someone please give me the
> > > administrator permission on this project, so I will be able to invalid
> > > the build cache?
> >
> > I don't appear to have admin rights on Appveyor either.
I've attempted to make a change that should give you both more access;
even odds on whether it did anything :). I've never tried to use
their REST API, so I don't know whether it will help with that at all.
> For some reason it seems to be located in a hidden directory
> (".github/appveyor.yml"). Not the most intuitive decision IMHO.
> Travis' own config file ".travis.yml" is still at repository root, which
> makes things more confusing.
The idea there was to avoid proliferation of root-level dotfiles where
possible, but if we would rather keep it at the project root it's a
relatively simple change to make.
For the actual issue at hand, the problem arises from doing builds on
3.6 with both the VS2015 and VS2017 images. Apparently something
built in `/externals` by the VS2015 build gets cached, which then
breaks the VS2017 build; I haven't tracked down how exactly that is
happening. I think the preferred solution is probably to just drop
the VS2017 build on 3.6 on AppVeyor; VSTS runs on VS2017 and dropping
one of the builds from 3.6 will make AppVeyor significantly quicker on
that branch.
--
Zach
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
Le mer. 5 sept. 2018 à 15:47, Zachary Ware a écrit : > For the actual issue at hand, the problem arises from doing builds on > 3.6 with both the VS2015 and VS2017 images. Apparently something > built in `/externals` by the VS2015 build gets cached, which then > breaks the VS2017 build; I haven't tracked down how exactly that is > happening. I think the preferred solution is probably to just drop > the VS2017 build on 3.6 on AppVeyor; VSTS runs on VS2017 and dropping > one of the builds from 3.6 will make AppVeyor significantly quicker on > that branch. Do we have a VS2017 buildbot on the 3.6 branch? If yes, I vote to drop VS2017 in the pre-commit hook (AppVeyor) since it would make AppVeyor twice faster on 3.6! Victor ___ Python-Dev mailing list [email protected] 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 REPL doesn't work on Windows over remote powershell session (winrm)
On Sun, 26 Aug 2018 at 12:16, David Bolen wrote: > I'm not sure if there's any better way for Python to detect a remote > shell as being interactive under Windows that would cover such cases. > Perhaps some of the newer pty changes I read Microsoft is making might > help, assuming it flows through to the isatty() test. Based on https://blogs.msdn.microsoft.com/commandline/2018/08/02/windows-command-line-introducing-the-windows-pseudo-console-conpty/, that seems plausible to me, since they're adding a true pseudo-tty system, and mostly modeling it's behaviour on the *nix one. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, 5 Sep 2018 at 14:47, Zachary Ware wrote:
>
> On Wed, Sep 5, 2018 at 6:23 AM Antoine Pitrou wrote:
> > On Wed, 5 Sep 2018 11:03:48 +0100
> > Paul Moore wrote:
> > > On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote:
> > > > Who ows the "python" AppVeyor project?
>
> That seems to have fallen to me for the most part.
>
> > > > Can someone please give me the
> > > > administrator permission on this project, so I will be able to invalid
> > > > the build cache?
> > >
> > > I don't appear to have admin rights on Appveyor either.
>
> I've attempted to make a change that should give you both more access;
> even odds on whether it did anything :). I've never tried to use
> their REST API, so I don't know whether it will help with that at all.
I do indeed now seem to have admin access on Appveyor. Thanks for
that. I guess I should therefore say that if anyone needs help with
Appveyor stuff, feel free to ping me and save Zach from getting all
the work :-)
> > For some reason it seems to be located in a hidden directory
> > (".github/appveyor.yml"). Not the most intuitive decision IMHO.
> > Travis' own config file ".travis.yml" is still at repository root, which
> > makes things more confusing.
>
> The idea there was to avoid proliferation of root-level dotfiles where
> possible, but if we would rather keep it at the project root it's a
> relatively simple change to make.
When working via github on the web (which I was) rather than on a
local checkout where I can search, putting it in a subdiretory is a
bit less discoverable (made worse because there's nothing about the
name ".github" that suggests it would have Appveyor files in it :-))
I'd prefer it at the top level - but not enough to submit a PR for
that at the moment, so I'm fine with it staying where it is.
> For the actual issue at hand, the problem arises from doing builds on
> 3.6 with both the VS2015 and VS2017 images. Apparently something
> built in `/externals` by the VS2015 build gets cached, which then
> breaks the VS2017 build; I haven't tracked down how exactly that is
> happening. I think the preferred solution is probably to just drop
> the VS2017 build on 3.6 on AppVeyor; VSTS runs on VS2017 and dropping
> one of the builds from 3.6 will make AppVeyor significantly quicker on
> that branch.
Nice catch. I'd agree, it's probably not worth having both
(particularly as, if Victor says, we have buildbots for the one
Appveyor doesn't cover - but even if we don't I think VSTS has it
covered).
I presume you're suggesting keeping 2017 is so that we don't have
stray 2015-built artifacts in the cache, which makes sense to me, and
I have a mild preference for keeping the latest compiler, as that's
likely the one that people will find easier to get. But 2015 is
presumably the version the official 3.6 builds are made with, so
there's an argument for keeping that one (although if we do that I
guess we need to find a *different* way of fixing the cached artifact
issue).
tl; dr; I'm inclined to agree with you that just using VS2017 on
Appveyor is the simplest option.
Paul
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, Sep 5, 2018 at 9:30 AM Paul Moore wrote: > I presume you're suggesting keeping 2017 is so that we don't have > stray 2015-built artifacts in the cache, which makes sense to me, and > I have a mild preference for keeping the latest compiler, as that's > likely the one that people will find easier to get. But 2015 is > presumably the version the official 3.6 builds are made with, so > there's an argument for keeping that one (although if we do that I > guess we need to find a *different* way of fixing the cached artifact > issue). My fix was actually to keep VS2015 on AppVeyor and leave VS2017 to VSTS, that way we get pre-commit coverage on both compilers. There shouldn't be any caching issues between branches, since PCbuild is sufficiently different between each branch. I wish there was a cache per branch, but there doesn't seem to be. -- Zach ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, Sep 5, 2018 at 4:32 PM Paul Moore wrote:
>
> On Wed, 5 Sep 2018 at 14:47, Zachary Ware
> wrote:
> >
> > On Wed, Sep 5, 2018 at 6:23 AM Antoine Pitrou wrote:
> > > On Wed, 5 Sep 2018 11:03:48 +0100
> > > Paul Moore wrote:
> > > > On Wed, 5 Sep 2018 at 10:55, Victor Stinner wrote:
> > > > > Who ows the "python" AppVeyor project?
> >
> > That seems to have fallen to me for the most part.
> >
> > > > > Can someone please give me the
> > > > > administrator permission on this project, so I will be able to invalid
> > > > > the build cache?
> > > >
> > > > I don't appear to have admin rights on Appveyor either.
> >
> > I've attempted to make a change that should give you both more access;
> > even odds on whether it did anything :). I've never tried to use
> > their REST API, so I don't know whether it will help with that at all.
>
> I do indeed now seem to have admin access on Appveyor. Thanks for
> that. I guess I should therefore say that if anyone needs help with
> Appveyor stuff, feel free to ping me and save Zach from getting all
> the work :-)
>
> > > For some reason it seems to be located in a hidden directory
> > > (".github/appveyor.yml"). Not the most intuitive decision IMHO.
> > > Travis' own config file ".travis.yml" is still at repository root, which
> > > makes things more confusing.
> >
> > The idea there was to avoid proliferation of root-level dotfiles where
> > possible, but if we would rather keep it at the project root it's a
> > relatively simple change to make.
>
> When working via github on the web (which I was) rather than on a
> local checkout where I can search, putting it in a subdiretory is a
> bit less discoverable (made worse because there's nothing about the
> name ".github" that suggests it would have Appveyor files in it :-))
> I'd prefer it at the top level - but not enough to submit a PR for
> that at the moment, so I'm fine with it staying where it is.
>
> > For the actual issue at hand, the problem arises from doing builds on
> > 3.6 with both the VS2015 and VS2017 images. Apparently something
> > built in `/externals` by the VS2015 build gets cached, which then
> > breaks the VS2017 build; I haven't tracked down how exactly that is
> > happening. I think the preferred solution is probably to just drop
> > the VS2017 build on 3.6 on AppVeyor; VSTS runs on VS2017 and dropping
> > one of the builds from 3.6 will make AppVeyor significantly quicker on
> > that branch.
>
> Nice catch. I'd agree, it's probably not worth having both
> (particularly as, if Victor says, we have buildbots for the one
> Appveyor doesn't cover - but even if we don't I think VSTS has it
> covered).
>
> I presume you're suggesting keeping 2017 is so that we don't have
> stray 2015-built artifacts in the cache, which makes sense to me, and
> I have a mild preference for keeping the latest compiler, as that's
> likely the one that people will find easier to get. But 2015 is
> presumably the version the official 3.6 builds are made with, so
> there's an argument for keeping that one (although if we do that I
> guess we need to find a *different* way of fixing the cached artifact
> issue).
>
> tl; dr; I'm inclined to agree with you that just using VS2017 on
> Appveyor is the simplest option.
Hello,
Let me take this note as an opportunity to nag that I have a still
open pull request to add testing of Python on Cygwin to the AppVeyor
build, which in theory works quite well:
https://github.com/python/cpython/pull/8463
So +1 for dropping one build configuration from AppVeyor if that will
make it easier in the future to add this one :)
However, Victor has asked that as a prerequisite to adding a Cygwin
build to AppVeyor, we first have a relatively stable buildbot. I had
thought maybe adding advisory CI on AppVeyor *first* would make
getting a stable buildbot easier, but I can see the argument either
way, so we have added said buildbot:
https://buildbot.python.org/all/#/builders/164 Unfortunately, for
the last ~120 builds it has been all but useless due to at least two
small, but long outstanding issues preventing 3.7.x from building on
Cygwin. Both of those issues have proposed fixes pending review, both
of which have PRs linked to from my AppVeyor PR.
If anyone is interested in having a look at those I'd appreciate it,
thanks (one of them also got some review from Inada Naoki, but we
didn't ever agree on some concrete action items for making the patch
acceptable, and it has stalled again...)
Best,
E
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AES cipher implementation in standard library
On 2018-09-05 16:01, 大野隆弘 wrote: > Christian, really appreciated the details. I understood. > > Is wrapper library like ssl module with openssl on platform also not > good idea? > My intention is not re-invention but single standard way as standard > library. > > If I can read past discussion somewhere, it's also appreciated The Python standard library doesn't have to solve all problems. Although the slogan is "Batteries Included", we stopped including all batteries a long time. We try not to add new modules, especially complex and security-relevant modules like a generic crypto interface. The Python core developer team doesn't have any resources to design, create, and maintain a crypto interface. The ssl module is a bit special, because pip and other download tools need it. Without the ssl module, pip wouldn't be able to download packages over HTTPS. If you need cryptographic algorithms and primitives, then use the PyCA cryptography package. It's *the* recommended library for cryptography, and X.509. Christian ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AES cipher implementation in standard library
Christian, really appreciated the details. I understood. Is wrapper library like ssl module with openssl on platform also not good idea? My intention is not re-invention but single standard way as standard library. If I can read past discussion somewhere, it's also appreciated Thanks and Regards, Takahiro Ono 2018年9月5日(水) 1:48 Christian Heimes : > On 2018-09-04 16:37, 大野隆弘 wrote: > > Dear all, > > > > Have we tried cipher implementation includes AES as a standard library > > in the past? > > https://docs.python.org/3.6/library/crypto.html > > > > if possible I want to try to implement AES because famous 3rd party > > library is not maintained and general cipher programs should be used for > > multiple purpose.Though the implementation is tough, I believe this > > should be worth to it. > > In my case, I want to use AES implementation for zipfile module. > > strong -1 > > The Python standard library doesn't contain any encryption, signing, and > other cryptographic algorithms for multiple reasons. The only exception > from the rule are hashing algorithms and HMAC construct. There are legal > implications like export restrictions. Crypto is just too hard to get > right and we don't want to give the user additional rope. We already had > a very lengthy and exhausting discussion for the secrets module. That > module just provides a user-friendly interface to CPRNG. > > By the way, AES by itself is a useless to borderline dangerous > algorithm. It must be embedded within additional layers like block mode, > authenticated encryption / MAC, and more. There isn't a single correct > answer for block mode and AD algorithm, too. It highly depends on the > problem space. While GCM AEAD mode is good choice for network > communication, it can be a pretty bad idea for persistent storage. > > There is one excellent Python library with high level and low level > cryptographic algorithms: http://cryptography.readthedocs.io/ . It's t > > Regards, > Christian > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] AES cipher implementation in standard library
Sorry, allow me to ask one more thing. If I want to use AES in zipfile module, what the good way to implement? Thanks and Regards, - Takahiro Ono 2018年9月5日(水) 23:01 大野隆弘 : > Christian, really appreciated the details. I understood. > > Is wrapper library like ssl module with openssl on platform also not good > idea? > My intention is not re-invention but single standard way as standard > library. > > If I can read past discussion somewhere, it's also appreciated > > Thanks and Regards, > Takahiro Ono > > > > > 2018年9月5日(水) 1:48 Christian Heimes : > >> On 2018-09-04 16:37, 大野隆弘 wrote: >> > Dear all, >> > >> > Have we tried cipher implementation includes AES as a standard library >> > in the past? >> > https://docs.python.org/3.6/library/crypto.html >> > >> > if possible I want to try to implement AES because famous 3rd party >> > library is not maintained and general cipher programs should be used for >> > multiple purpose.Though the implementation is tough, I believe this >> > should be worth to it. >> > In my case, I want to use AES implementation for zipfile module. >> >> strong -1 >> >> The Python standard library doesn't contain any encryption, signing, and >> other cryptographic algorithms for multiple reasons. The only exception >> from the rule are hashing algorithms and HMAC construct. There are legal >> implications like export restrictions. Crypto is just too hard to get >> right and we don't want to give the user additional rope. We already had >> a very lengthy and exhausting discussion for the secrets module. That >> module just provides a user-friendly interface to CPRNG. >> >> By the way, AES by itself is a useless to borderline dangerous >> algorithm. It must be embedded within additional layers like block mode, >> authenticated encryption / MAC, and more. There isn't a single correct >> answer for block mode and AD algorithm, too. It highly depends on the >> problem space. While GCM AEAD mode is good choice for network >> communication, it can be a pretty bad idea for persistent storage. >> >> There is one excellent Python library with high level and low level >> cryptographic algorithms: http://cryptography.readthedocs.io/ . It's t >> >> Regards, >> Christian >> > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comparisions for collections.Counters
On Wed, Sep 5, 2018 at 3:13 AM Evpok Padding wrote: > According to the [doc][1], `collections.Counter` convenience intersection > and union functions are meant to help it represent multisets. However, it > currently lacks comparisons, which would make sense and seems > straightforward to implement. > x = Counter(a=1, b=2) y = Counter(a=2, b=1) x > y ? ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comparisions for collections.Counters
05.09.18 13:10, Evpok Padding пише: According to the [doc][1], `collections.Counter` convenience intersection and union functions are meant to help it represent multisets. However, it currently lacks comparisons, which would make sense and seems straightforward to implement. Am I missing something here or should I send a PR ASAP ? :-) There is a closed issue for this: https://bugs.python.org/issue22515. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Comparisions for collections.Counters
On Wed, 5 Sep 2018 at 18:28, Serhiy Storchaka wrote: > There is a closed issue for this: https://bugs.python.org/issue22515. > Oh, thanks, I had missed that. I guess I can live with it, although I agree with [the last comment][1] that this decision does not make a lot of sense. But hey, who am I to second-guess Guido anr Raymond H. Cheers, E [1]: https://bugs.python.org/issue22515#msg253251 ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Workflow blocked on the 3.6 because of AppVeyor; who owns the AppVeyor project?
On Wed, 5 Sep 2018 at 04:56 Paul Moore wrote:
> On Wed, 5 Sep 2018 at 12:24, Antoine Pitrou wrote:
> > For some reason it seems to be located in a hidden directory
> > (".github/appveyor.yml"). Not the most intuitive decision IMHO.
> > Travis' own config file ".travis.yml" is still at repository root, which
> > makes things more confusing.
>
> Thanks, agreed that's confusing. I'd prefer appveyor.yml to be at the
> project root, as that's what nearly all projects I deal with do. But
> at least I know where it is now :-)
>
This was on purpose as the CI files are not directly related to Python
itself so they are easier to leave out of any source tarball and such. The
reason .travis.yml is top-level is because Travis won't let us have it
anywhere else.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
