Re: [Python-Dev] PEP: 576 Title: Rationalize Built-in function classes
2018-05-19 11:15 GMT+02:00 mark : > The PEP can be viewed here: > https://github.com/python/peps/blob/master/pep-0576.rst > (...) > P.S. > I'm happy to have discussion of this PEP take place via GitHub, > rather than the mailing list, but I thought I would follow the conventional > route for now. Previously, we required to add the full text of the PEP inside the email to be able to reply inline by email. I know that Guido van Rossum started a discussion on python-commiters to propose to change how we discuss PEPs, but I don't think that any decision has been taken at this point, no? 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] Reminder: Please elaborate commit messages
Hi, In https://bugs.python.org/issue33531, Andrew Svetlov wrote "Fixed failed sendfile tests on Windows (at least I hope so)." without giving any bpo number or a commit number. So I looked at latest commits and I found: --- commit e2537521916c5bf88fcf54d4654ff1bcd332be4a Author: Andrew Svetlov Date: Mon May 21 12:03:45 2018 +0300 Fix asyncio flaky tests (#7023) --- Please try to write better error messages for people who will dig into the Git history in 1, 5 or 10 years: * Usually, it's better to open a bug. Here you could give the full error message, mention on which platform the test fails, etc. * Mention which tests are affected * Maybe even give an extract of the error message of the fixed test in the commit message I know that it's more effort and fixing flaky tests is annoying and may require multiple iterations, but again, please think to people who will have to read the Git history later... I was able able to rebuild the context of this commit from a comment of https://bugs.python.org/issue33531 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] Reminder: Please elaborate commit messages
Sorry for that. I thought that the bpo issue can be skipped because it is tests-only change, no asyncio code was affected. Will be more accurate next time. On Tue, May 22, 2018 at 3:26 PM Victor Stinner wrote: > Hi, > > In https://bugs.python.org/issue33531, Andrew Svetlov wrote "Fixed > failed sendfile tests on Windows (at least I hope so)." without giving > any bpo number or a commit number. So I looked at latest commits and I > found: > > --- > commit e2537521916c5bf88fcf54d4654ff1bcd332be4a > Author: Andrew Svetlov > Date: Mon May 21 12:03:45 2018 +0300 > > Fix asyncio flaky tests (#7023) > --- > > Please try to write better error messages for people who will dig into > the Git history in 1, 5 or 10 years: > > * Usually, it's better to open a bug. Here you could give the full > error message, mention on which platform the test fails, etc. > * Mention which tests are affected > * Maybe even give an extract of the error message of the fixed test in > the commit message > > I know that it's more effort and fixing flaky tests is annoying and > may require multiple iterations, but again, please think to people who > will have to read the Git history later... > > I was able able to rebuild the context of this commit from a comment > of https://bugs.python.org/issue33531 > > Victor > -- Thanks, Andrew Svetlov ___ 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] Reminder: Please elaborate commit messages
Usually, I don't open a new bug to fix or enhance a test. So I wouldn't say that it's mandatory. It's really on a case by case basis. It seems like test_asyncio failures are a hot topic these days :-) It's one of the reasons why Python 3.7rc1 has been delayed by 2 days, no? :-) Victor 2018-05-22 14:37 GMT+02:00 Andrew Svetlov : > Sorry for that. > I thought that the bpo issue can be skipped because it is tests-only change, > no asyncio code was affected. > Will be more accurate next time. > > On Tue, May 22, 2018 at 3:26 PM Victor Stinner wrote: >> >> Hi, >> >> In https://bugs.python.org/issue33531, Andrew Svetlov wrote "Fixed >> failed sendfile tests on Windows (at least I hope so)." without giving >> any bpo number or a commit number. So I looked at latest commits and I >> found: >> >> --- >> commit e2537521916c5bf88fcf54d4654ff1bcd332be4a >> Author: Andrew Svetlov >> Date: Mon May 21 12:03:45 2018 +0300 >> >> Fix asyncio flaky tests (#7023) >> --- >> >> Please try to write better error messages for people who will dig into >> the Git history in 1, 5 or 10 years: >> >> * Usually, it's better to open a bug. Here you could give the full >> error message, mention on which platform the test fails, etc. >> * Mention which tests are affected >> * Maybe even give an extract of the error message of the fixed test in >> the commit message >> >> I know that it's more effort and fixing flaky tests is annoying and >> may require multiple iterations, but again, please think to people who >> will have to read the Git history later... >> >> I was able able to rebuild the context of this commit from a comment >> of https://bugs.python.org/issue33531 >> >> Victor > > -- > Thanks, > Andrew Svetlov ___ 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] PEP: 576 Title: Rationalize Built-in function classes
On Tue, May 22, 2018 at 5:29 AM, Victor Stinner wrote: > 2018-05-19 11:15 GMT+02:00 mark : > > The PEP can be viewed here: > > https://github.com/python/peps/blob/master/pep-0576.rst > > (...) > > P.S. > > I'm happy to have discussion of this PEP take place via GitHub, > > rather than the mailing list, but I thought I would follow the > conventional > > route for now. > > Previously, we required to add the full text of the PEP inside the > email to be able to reply inline by email. > > I know that Guido van Rossum started a discussion on python-commiters > to propose to change how we discuss PEPs, but I don't think that any > decision has been taken at this point, no? > That doesn't stop us from experimenting with the new flow. If it works, we can adopt it officially. If it doesn't work, we can ask Mark to post a copy to python-ideas (or -dev) for discussion later. ISTR there are plenty of PEPs that never get posted to python-ideas because they are discussed on a separate list. -- --Guido van Rossum (python.org/~guido) ___ 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] Procedure for adding new public C API
On 21May2018 0708, Paul Moore wrote: On 21 May 2018 at 14:42, Serhiy Storchaka wrote: Is it even acceptable to add a symbol into the limited ABI? I thought the idea was that if I linked with python3.dll, my code would work with any version of Python 3? By introducing new symbols, code linked with the python3.dll shipped with (say) Python 3.8 would fail to run if executed with the python3.dll from Python 3.5. The limited API is versioned. If you use only Python 3.5 API (define Py_LIMITED_API to 0x0305), the built code will be expected to work on 3.5 and later. In theory. Thanks, I'd missed that point (I need to go and check my build process, in that case :-)). The fact that the headers and python3.def claim different functions are in the limited API basically breaks any ability to use this. You really do need to build with the oldest possible version. Alternatively, we can try again to get everyone to agree that since their APIs shipped as stable in earlier versions that we need to actually make them stable (or take a breaking backwards incompatible change to make them non-stable). Last time Zach and I attempted this we got nowhere. (There's a bug on bpo somewhere with details and helper scripts, as well as unrecorded discussions from the sprints a couple years ago.) Sorry to be the bearer of bad news. Cheers, Steve ___ 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] PEP: 576 Title: Rationalize Built-in function classes
On 22May2018 0741, Guido van Rossum wrote: ISTR there are plenty of PEPs that never get posted to python-ideas because they are discussed on a separate list. There are often better venues for the initial discussion (such as security-sig, distutils-sig or datetime-sig), but I think that's orthogonal from posting the full text of a PEP. That said, if the aim is to keep discussion in another place (such as github), you really don't want copies floating around any other mailing lists. Eventually I'd hope it comes through for final review though, as I'm sure a number of us are unlikely to click through to github unless we have a specific interest in the topic. Cheers, Steve ___ 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] Reminder: Please elaborate commit messages
On 5/22/2018 8:37 AM, Andrew Svetlov wrote: Sorry for that. I thought that the bpo issue can be skipped because it is tests-only change, no asyncio code was affected. Will be more accurate next time. A new issue was not needed. Adding 'bpo-33531' would have been fine, automatically linking the issue and the PR in both directions. -- Terry Jan Reedy ___ 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] Reminder: Please elaborate commit messages
On Tue, May 22, 2018 at 8:52 AM Victor Stinner wrote: > Usually, I don't open a new bug to fix or enhance a test. So I > wouldn't say that it's mandatory. It's really on a case by case basis. > It seems like test_asyncio failures are a hot topic these days :-) > It's one of the reasons why Python 3.7rc1 has been delayed by 2 days, > no? :-) Yes, getting Windows tests stable wasn't easy. I think it's solved now (thanks to Andrew), but we always welcome any help from other core devs :) Yury ___ 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] Reminder: Please elaborate commit messages
On 5/22/2018 2:26 PM, Yury Selivanov wrote: On Tue, May 22, 2018 at 8:52 AM Victor Stinner wrote: Usually, I don't open a new bug to fix or enhance a test. So I wouldn't say that it's mandatory. It's really on a case by case basis. It seems like test_asyncio failures are a hot topic these days :-) It's one of the reasons why Python 3.7rc1 has been delayed by 2 days, no? :-) Yes, getting Windows tests stable wasn't easy. I think it's solved now (thanks to Andrew), but we always welcome any help from other core devs :) The AppVeyor (Windows) failure have been gone for a day. The Travis failures are rarer. -- Terry Jan Reedy ___ 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] Procedure for adding new public C API
On 22 May 2018 at 18:00, Steve Dower wrote: > On 21May2018 0708, Paul Moore wrote: >> >> On 21 May 2018 at 14:42, Serhiy Storchaka wrote: Is it even acceptable to add a symbol into the limited ABI? I thought the idea was that if I linked with python3.dll, my code would work with any version of Python 3? By introducing new symbols, code linked with the python3.dll shipped with (say) Python 3.8 would fail to run if executed with the python3.dll from Python 3.5. >>> >>> >>> The limited API is versioned. If you use only Python 3.5 API (define >>> Py_LIMITED_API to 0x0305), the built code will be expected to work on >>> 3.5 and later. In theory. >> >> >> Thanks, I'd missed that point (I need to go and check my build >> process, in that case :-)). > > > The fact that the headers and python3.def claim different functions are in > the limited API basically breaks any ability to use this. You really do need > to build with the oldest possible version. > > Alternatively, we can try again to get everyone to agree that since their > APIs shipped as stable in earlier versions that we need to actually make > them stable (or take a breaking backwards incompatible change to make them > non-stable). Last time Zach and I attempted this we got nowhere. (There's a > bug on bpo somewhere with details and helper scripts, as well as unrecorded > discussions from the sprints a couple years ago.) > > Sorry to be the bearer of bad news. I think I recall the earlier discussion. I agree that the current situation makes the stable ABI less useful than it would otherwise have been. But being able to build an embedding application or extension, and say "this will work with any version of Python newer than the version I built it with" is still very useful. 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] PEP: 576 Title: Rationalize Built-in function classes
On Tue, May 22, 2018 at 10:07 AM, Steve Dower wrote: > On 22May2018 0741, Guido van Rossum wrote: > >> ISTR there are plenty of PEPs that never get posted to python-ideas >> because they are discussed on a separate list. >> > > There are often better venues for the initial discussion (such as > security-sig, distutils-sig or datetime-sig), but I think that's orthogonal > from posting the full text of a PEP. > I don't think that the original rationale for posting the full text of a PEP to a mailing list still applies. The raw text is on GitHub in the python/peps repo, and the formatted text is on python.org. We're not some kind of bureaucratic org that pretends to still live in the world of paper and pencil. > That said, if the aim is to keep discussion in another place (such as > github), you really don't want copies floating around any other mailing > lists. Eventually I'd hope it comes through for final review though, as I'm > sure a number of us are unlikely to click through to github unless we have > a specific interest in the topic. > IMO if you can't be bothered to click through on GitHub you forfeit your right to comment. (Which isn't a right anyway, it's a privilege.) -- --Guido van Rossum (python.org/~guido) ___ 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] PEP: 576 Title: Rationalize Built-in function classes
For the record: the only reason that I replied on GitHub was because the proposal was not yet posted (as far as I know) to any mailing list. Typically, a post is made to a mailing list more or less at the same time as creating the PEP. In this case, there was a delay of a few days, maybe also because of unrelated issues with the compilation of the PEPs. ___ 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] My fork lacks a 3.7 branch - can I create it somehow?
On 22.05.2018 3:07, Skip Montanaro wrote: My GitHub fork of the cpython repo was made awhile ago, before a 3.7 branch was created. I have no remotes/origin/3.7. Is there some way to create it from remotes/upstream/3.7? I asked on GitHub's help forums. The only recommendation was to to delete my fork and recreate it. That seemed kind of drastic, and I will do it if that's really the only way, but this seems like functionality Git and/or GitHub probably supports. Thx, You don't really need copies of official branches on your Github fork if you're not a maintainer for these branches. (You'll have to keep master though AFAIK since Git needs some branch to be marked as "default".) It's sufficient to just have topic branches for PRs there: you take official branches from python/cpython and topic branches from your fork, do the edits and manipulations locally, then upload the changed topic branches to your fork. I found this easier than having everything in your fork 'cuz it saves you the hassle of keeping your copies up-to-date and having unexpected merge conflicts in your PRs if the copies get out of date. Skip ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/vano%40mail.mipt.ru -- Regards, Ivan ___ 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] My fork lacks a 3.7 branch - can I create it somehow?
> You don't really need copies of official branches on your Github fork if you're not a maintainer for these branches. I explicitly wanted to run with 3.7 in the run-up to release. On that branch, the built ./python reports 3.7.0b4+ at startup. Master tells me 3.8.0a0 on startup. Since my local repo is a clone of my fork, it made sense to me to have a 3.7 branch on my fork which I could switch to. Am I only nutcase who thinks that might be mildly useful? (Or that if I want to test an application across multiple versions using tox that it makes sense to have pre-release visibility of point releases.) Skip ___ 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] My fork lacks a 3.7 branch - can I create it somehow?
On May 22, 2018, at 18:51, Skip Montanaro wrote: > [Ivan Pozdeev]: >> You don't really need copies of official branches on your Github fork >> if you're not a maintainer for these branches. > I explicitly wanted to run with 3.7 in the run-up to release. On that > branch, the built ./python reports 3.7.0b4+ at startup. Master tells me > 3.8.0a0 on startup. Since my local repo is a clone of my fork, it made > sense to me to have a 3.7 branch on my fork which I could switch to. Am I > only nutcase who thinks that might be mildly useful? (Or that if I want to > test an application across multiple versions using tox that it makes sense > to have pre-release visibility of point releases.) No, what you what you want to do makes perfect sense. It sounds like Ivan is used to projects with a somewhat different workflow than ours. We don't have "branch maintainers"; core-developers are responsible themselves for merging changes into all appropriate branches. While these days some of the backporting can be semi-automated, thanks to the backport bot, but it is still up to the core developer to decide whether a change can and should be backported, so having all active branches available in a local repo is a pretty much a necessity. As always, the Developer's Guide should be able to answer questions like this: https://devguide.python.org/devcycle/ -- Ned Deily [email protected] -- [] ___ 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] My fork lacks a 3.7 branch - can I create it somehow?
On Tue, May 22, 2018 at 3:51 PM, Skip Montanaro wrote: >> You don't really need copies of official branches on your Github fork if > you're not a maintainer for these branches. > > I explicitly wanted to run with 3.7 in the run-up to release. On that > branch, the built ./python reports 3.7.0b4+ at startup. Master tells me > 3.8.0a0 on startup. Since my local repo is a clone of my fork, it made > sense to me to have a 3.7 branch on my fork which I could switch to. Am I > only nutcase who thinks that might be mildly useful? (Or that if I want to > test an application across multiple versions using tox that it makes sense > to have pre-release visibility of point releases.) To run with 3.7 you need 3.7 in your local repo, but there's no particular reason that you need to push that branch back up to your personal fork on github. It's very unlikely that anyone looking for a 3.7 branch would go to your fork and expect to find it there. As far as git is concerned, the main repo on github, your fork on github, and your local repo are 3 independent repositories, equally valid. The relationships between them are purely a matter of convention. -n -- Nathaniel J. Smith -- https://vorpus.org ___ 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] My fork lacks a 3.7 branch - can I create it somehow?
[Nathaniel Smith ] > ... > As far as git is concerned, the main repo on github, your fork on > github, and your local repo are 3 independent repositories, equally > valid. The relationships between them are purely a matter of > convention. Thanks for that! It instantly cleared up several mysteries for me. I'm just starting to learn git & github, and am starkly reminded of an old truth: there is absolutely nothing "obvious" about source-control systems, or workflows, before you already know them ;-) ___ 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
