My (positive) feedback on the new CPython workflow
Hi,
2017-07-18 11:36 GMT+02:00 Antoine Pitrou antoine@python.org:
Can I take the opportunity to say thank you again (both you and Larry) for the "blurb" tool? It really makes an important difference when contributing.
Regards
Antoine.
I concur with Antoine, I'm now *very* happy with the new workflow. The code became better, many things are much simpler for me (especially the tasks that I don't have to do myself anymore ;-)), my productivity increases and I see more and more active contributors, much more than before the move to GitHub and new workflow!
== Introduction ==
Two friends asked me recently how is the new Python workflow going.
Somehow, I decided to not express myself on the topic to avoid dummy knee-jerk reaction like "it sucks, it was better before, xxx doesn't work, now I have to xxx, etc."
It took me at least 3 months to be used to the new workflow, while tools were developed and enhanced, and the workflow was adjusted based on our early feedback.
So, here is my feedback :-)
== pre-commit CI: less regressions ==
From a pure technical point of view, IMHO pre-commit CI on Linux
(Travis CI) and Windows (AppVeyor) is a *MAJOR* enhancement. (I don't count macOS, since it's not mandatory yet.)
For example, before GitHub, it was common to break Windows since too few core developers were running tests *manually* on Windows.
It's hard to prove my point, so try to trust me: we reduce a lot the number of regressions introduced by new changesets. Before, every two weeks, we had to rush to push fixes in urgency (which sometimes leaded to bad code which required multiple iterations until we find the best fix).
It was especially annoying when a dev pushed a big change just before being away for 8-12 hours, which means having to push a fix without the review of the change author :-(
== More contributors, more contributions, faster reviewed/merged ==
In term of contributions, I looked at statistics yesterday and it became clear the number of different authors is significantely much higher, around 25 contributors / month before, now closer to 50: https://www.openhub.net/p/python/contributors/summary
Well, Git allows to store the original author, so statistics are simplify higher just because previously the tools failed to identify the real author.
But I'm watching the bug tracker, pull requests, and Git commits: there are a lot of *new* contributors, we get more contributions, and we are *faster* to integrate them.
I also saw again inactive core contributors starting to review again, or even write new PRs! It's a very good sign of the good health of our project!
More generally, the whole development seems to be more active, more productive and more *healthy*.
== Better scale horizontally ==
The new workflow better scales horizontally since we delegated much more work to the contributor. Previously the core developers were more the bottleneck.
Tasks delegated to the contributors:
- create the PR itself (can you still remind when we had to download a
patch file and create a commit? ;-)),
- write the commit message (I always hated to do that without any kind
of review...),
- add the NEWS entry (before it was common to explicitly ask to *not*
write it... to avoid conflicts with Misc/NEWS...).
- most contributors create backports (using cherry-pick) themself.
Before, this painful/error-prone task was usually done by a single developer without any review, without pre-commit tests, etc.
Note: I didn't see any contributor complaining about having to do these tasks. It seems like it's more the opposite, they are happy to be more *involved* in the project!
== GitHub ==
I never had to explain how to create an account on GitHub, nor how to create a PR.
Signing the CLA doesn't seem to be a blocker point neither, contributors are able to sign it and the bot tracks correctly the CLA status (thanks Brett for the bot! it's nice to feel safe for legal issues ;-)).
Maybe we have an excellent documentation. Maybe developers already know well the GitHub platform.
Even for backports, I didn't have to explain how to cherry-pick a commit, but it was common that I pointed to the devguide section when I proposed the author to do the backport himself/herself.
Having explicitly a list of "Approve" and "Requet changes" votes helps to *quickly* have an overview of the review status.
I'm just not unconfortable with the fact that an approval is kept even if the PR is modified after the review :-/ I would expect a list a notice "changed modified after the review" or something like that. At least, for my own reviews, to remind me to review again.
The [First time contributor] label on PR helps to remind Misc/ACKS: ask the author to add himself/herself to ACKS.
Compared to Rietveld, GitHub review tool is as "a good" (not much better, not much worse). Sometimes, I'm lost in reviews: my comments are hidden, I have to unfold many widgets. But it's not that bad. It seems like avoiding rebase works around some of these issues.
== Git branches ==
Having to create a local Git branch, push it to my repository and create PR is more work than attaching a patch file to bugs.python.org. It requires to be more organized to track my "local" Git branches.
I'm now trying to remove a local branch after pushing the PR, since it also exists in my "haypo" remote anyway. It helps to have a shorter list of branches.
I also wrote a shell script to run "git fetch haypo --prune" to remove "merged" branches (technically, I have to click on a button to remove my branch, after I merge my own PR).
Sometimes, I also see branches in the upstream repository (python/cpython), but it seems that we have less and less of them.
== NEWS.d and blurb ==
Thank you Larry Hastings, Brett Cannon and others who helped to write and integrate blurb: no more Misc/NEWS conflict, it's just amazing :-) We *all* wanted that for *years*!
Victor
18.07.17 13:24, Victor Stinner пише:
== More contributors, more contributions, faster reviewed/merged ==
In term of contributions, I looked at statistics yesterday and it became clear the number of different authors is significantely much higher, around 25 contributors / month before, now closer to 50: https://www.openhub.net/p/python/contributors/summary
Well, Git allows to store the original author, so statistics are simplify higher just because previously the tools failed to identify the real author.
But I'm watching the bug tracker, pull requests, and Git commits: there are a lot of *new* contributors, we get more contributions, and we are *faster* to integrate them.
I also saw again inactive core contributors starting to review again, or even write new PRs! It's a very good sign of the good health of our project!
More generally, the whole development seems to be more active, more productive and more *healthy*.
I have a different impression. Some core developers (like Raymond or Martin) stopped committing even if they are active on the bug tracker or mailing lists. Others make much less commits than they did before the migration.
I rather like the new workflow (except few lost features), but I afraid than many core developers are feeling uncomfortable with it.
Le 18/07/2017 à 13:36, Serhiy Storchaka a écrit :
I have a different impression. Some core developers (like Raymond or Martin) stopped committing even if they are active on the bug tracker or mailing lists. Others make much less commits than they did before the migration.
Assuming you meant Martin von Löwis, I think Martin stopped contributing long before we migrated to git (unfortunately, I might add). I hope he's doing ok.
Regards
Antoine.
18.07.17 14:40, Antoine Pitrou пише:
Assuming you meant Martin von Löwis, I think Martin stopped contributing long before we migrated to git (unfortunately, I might add). I hope he's doing ok.
I meant Martin Panter. His was the third of most active committers recent two years, but didn't commit anything recent months.
On 18 July 2017 at 21:36, Serhiy Storchaka storchaka@gmail.com wrote:
I rather like the new workflow (except few lost features), but I afraid than many core developers are feeling uncomfortable with it.
Aye, I think for folks already familiar with git and PR-style workflows through other projects, it's been almost a pure win, especially as various aspects have become more automated.
However, for folks that *weren't* already familiar with those, it's a pretty steep learning curve, and one accompanied by a non-trivial increase in the overall pace of development.
So in addition to thanking the folks working on the migration and the associated automation, I'd also like to explicitly thank Mariatta, Terry, Zachary, and everyone else that has contributed to the git cheatsheet and other workflow documentation updates in the developer's guide.
Cheers, Nick.
Le 18/07/2017 à 12:24, Victor Stinner a écrit :
== More contributors, more contributions, faster reviewed/merged ==
In term of contributions, I looked at statistics yesterday and it became clear the number of different authors is significantely much higher, around 25 contributors / month before, now closer to 50: https://www.openhub.net/p/python/contributors/summary
Beware of how those numbers are calculated.
When we were using hg, patches were typically committed by core developers, so only core developers appeared as "contributors" in the hg log.
Now we're using GitHub, commits are made by their contributors themselves, so the git log now shows their names.
(note the difference is really GitHub PRs vs. applying-patches-by-hand, not git vs. hg)
Furthermore, based on https://www.openhub.net/p/python/commits/summary, it seems the latest stats collected by OpenHub date back to 30th May 2017. They are two months late.
Regards
Antoine.
2017-07-18 13:57 GMT+02:00 Antoine Pitrou antoine@python.org:
Beware of how those numbers are calculated.
When we were using hg, patches were typically committed by core developers, so only core developers appeared as "contributors" in the hg log.
Right, that's why I wrote:
"Well, Git allows to store the original author, so statistics are simplify higher just because previously the tools failed to identify the real author."
I asked Mercurial developers if they would like to add a "committer" field, but this feature was never implemented :-(
Victor
On Tue, 18 Jul 2017 at 03:24 Victor Stinner victor.stinner@gmail.com wrote:
Hi,
2017-07-18 11:36 GMT+02:00 Antoine Pitrou antoine@python.org:
Can I take the opportunity to say thank you again (both you and Larry) for the "blurb" tool? It really makes an important difference when contributing.
Glad it's working out! And a thanks from me to everyone who participated in the discussions that led to blurb (and of course Larry for coding it up and putting up with me throughout the whole process :) .
Regards
Antoine.
I concur with Antoine, I'm now *very* happy with the new workflow. The code became better, many things are much simpler for me (especially the tasks that I don't have to do myself anymore ;-)), my productivity increases and I see more and more active contributors, much more than before the move to GitHub and new workflow!
Great! That was the goal the whole time so I'm glad it's starting to pay off.
== Introduction ==
Two friends asked me recently how is the new Python workflow going.
Somehow, I decided to not express myself on the topic to avoid dummy knee-jerk reaction like "it sucks, it was better before, xxx doesn't work, now I have to xxx, etc."
It took me at least 3 months to be used to the new workflow, while tools were developed and enhanced, and the workflow was adjusted based on our early feedback.
So, here is my feedback :-)
== pre-commit CI: less regressions ==
From a pure technical point of view, IMHO pre-commit CI on Linux (Travis CI) and Windows (AppVeyor) is a *MAJOR* enhancement. (I don't count macOS, since it's not mandatory yet.)
For example, before GitHub, it was common to break Windows since too few core developers were running tests *manually* on Windows.
It's hard to prove my point, so try to trust me: we reduce a lot the number of regressions introduced by new changesets. Before, every two weeks, we had to rush to push fixes in urgency (which sometimes leaded to bad code which required multiple iterations until we find the best fix).
It was especially annoying when a dev pushed a big change just before being away for 8-12 hours, which means having to push a fix without the review of the change author :-(
I have to admit I also appreciate the CI testing a lot since I worry a lot less about whether Python is in some broken state. And then thanks to all the hard work you've done, Victor, we know that if the buildbots go red that we have actually regressed and need to roll back a change instead of going "that buildbot is just always broken so you can ignore it".
It's getting to the point that I'm toying with the idea of making a Google Assistant command for my Google Home so I can say, "Hey Google, how is CPython doing?" and have it tell me if the buildbots are all green. :) And I still dream about having some LED light or grid for sprints where we can visibly see the buildbot statuses to know quickly when something has broken. But none of that was possible previously, so it's really exciting to have reached a stability point where this isn't a stupid idea. :)
== More contributors, more contributions, faster reviewed/merged ==
In term of contributions, I looked at statistics yesterday and it became clear the number of different authors is significantely much higher, around 25 contributors / month before, now closer to 50: https://www.openhub.net/p/python/contributors/summary
Well, Git allows to store the original author, so statistics are simplify higher just because previously the tools failed to identify the real author.
I'm going to be interested to see how the numbers look in Feb 2018 compared to now and see if there's a trend since the transition.
But I'm watching the bug tracker, pull requests, and Git commits: there are a lot of *new* contributors, we get more contributions, and we are *faster* to integrate them.
I also saw again inactive core contributors starting to review again, or even write new PRs! It's a very good sign of the good health of our project!
As Serhiy pointed out, though, some people have not made the transition. To help with this I plan on offering to do video chats with any core devs who want a personal walkthrough of the workflow, but I'm holding off on that until all of the critical workflow changes have landed as I don't want to be talking with someone and saying, "but this will be changing in a month or so". :)
More generally, the whole development seems to be more active, more productive and more *healthy*.
== Better scale horizontally ==
The new workflow better scales horizontally since we delegated much more work to the contributor. Previously the core developers were more the bottleneck.
Tasks delegated to the contributors:
- create the PR itself (can you still remind when we had to download a
patch file and create a commit? ;-)),
- write the commit message (I always hated to do that without any kind
of review...),
- add the NEWS entry (before it was common to explicitly ask to *not*
write it... to avoid conflicts with Misc/NEWS...).
Once again, glad the goals are panning out. :) Key thing has always been to increase our bandwidth and part of that was always to push more on to contributors so they can be more self-servicing.
- most contributors create backports (using cherry-pick) themself.
Before, this painful/error-prone task was usually done by a single developer without any review, without pre-commit tests, etc.
Nice! Maybe we should have a message from Bedevere after a PR gets merged saying something like, "thanks for the PR and congrats on getting it merged! If you're interested in helping to backport your PR to older versions of Python, let us know and follow the instructions at XXX to create backporting PRs."
Note: I didn't see any contributor complaining about having to do these tasks. It seems like it's more the opposite, they are happy to be more *involved* in the project!
== GitHub ==
I never had to explain how to create an account on GitHub, nor how to create a PR.
Signing the CLA doesn't seem to be a blocker point neither, contributors are able to sign it and the bot tracks correctly the CLA status (thanks Brett for the bot! it's nice to feel safe for legal issues ;-)).
Yeah, I sleep a little better at night thanks to that thing. :)
Maybe we have an excellent documentation. Maybe developers already know well the GitHub platform.
Even for backports, I didn't have to explain how to cherry-pick a commit, but it was common that I pointed to the devguide section when I proposed the author to do the backport himself/herself.
Having explicitly a list of "Approve" and "Requet changes" votes helps to *quickly* have an overview of the review status.
I'm just not unconfortable with the fact that an approval is kept even if the PR is modified after the review :-/ I would expect a list a notice "changed modified after the review" or something like that. At least, for my own reviews, to remind me to review again.
That wouldn't be too hard to add. I'm currently working on https://github.com/python/core-workflow/issues/94 which is going to label PRs based on their current stage (much like the stage field on bugs.python.org but much more automated). One of the labels is going to be "awaiting change review" for when a contributor has addressed requested changes, but it could be applied when the latest review is an approval but a post-approval change was made (along w/ a comment to point out that's why the label was added). Does that sound like what you're after?
The [First time contributor] label on PR helps to remind Misc/ACKS: ask the author to add himself/herself to ACKS.
That's a great trick! I really wish we could programmatically access that more easily than scouring the git repo for committer details.
Compared to Rietveld, GitHub review tool is as "a good" (not much better, not much worse). Sometimes, I'm lost in reviews: my comments are hidden, I have to unfold many widgets. But it's not that bad. It seems like avoiding rebase works around some of these issues.
== Git branches ==
Having to create a local Git branch, push it to my repository and create PR is more work than attaching a patch file to bugs.python.org. It requires to be more organized to track my "local" Git branches.
I'm now trying to remove a local branch after pushing the PR, since it also exists in my "haypo" remote anyway. It helps to have a shorter list of branches.
I also wrote a shell script to run "git fetch haypo --prune" to remove "merged" branches (technically, I have to click on a button to remove my branch, after I merge my own PR).
Sometimes, I also see branches in the upstream repository (python/cpython), but it seems that we have less and less of them.
I think people are pretty good about cleaning up after themselves since those branches usually only come up when someone makes a change through the web UI.
== NEWS.d and blurb ==
Thank you Larry Hastings, Brett Cannon and others who helped to write and integrate blurb: no more Misc/NEWS conflict, it's just amazing :-) We *all* wanted that for *years*!
Just to keep people up-to-date with what I personally have planned or I know people are working on:
- Status check for a news entry (
https://github.com/python/bedevere/pull/22) 2. Add a link to the end of the PR body back to bugs.python.org (thanks to Kushal; https://github.com/python/bedevere/issues/3 and https://github.com/python/bedevere/pull/24) 3. Label PRs based on what stage they are at ( https://github.com/python/core-workflow/issues/94; started work on this) 4. Make the CLA bot a status check instead of a label to make it a required status check ( https://github.com/python/the-knights-who-say-ni/issues/42) 5. Commit emails w/ diffs (thanks to Berker; https://github.com/python/bedevere/pull/27)
I think #2 and #5 cover the last initial complains people had about the new workflow, #1 and #3 will make things even better, and #4 is so I can sleep even better at night. ;)
My wishlist that I don't think anyone is actively working on ATM is:
- Bot to merge approved PRs (e.g. Rust's Homu)
- Bot to backport PRs (which could also be automatically merged)
- Automate Misc/ACKS (or do away with it and do something like
https://thanks.rust-lang.org/) 4. Make test coverage reports consistent 5. Automatically close stale PRs (e.g. not signing CLA, changes requested but not being made, etc.) 6. Bot to nudge core devs when they forget something (e.g. post-merge, a comment if someone forgot to change the commit message or PR number to have a "GH-" prefix)
I think that wishlist would get us as automated as reasonably possible while reminding people when the manual parts are accidentally done wrong.
On 7/18/2017 2:31 PM, Brett Cannon wrote:
Once again, glad the goals are panning out. :) Key thing has always been to increase our bandwidth and part of that was always to push more on to contributors so they can be more self-servicing.
* most contributors create backports (using cherry-pick) themself. Before, this painful/error-prone task was usually done by a single developer without any review, without pre-commit tests, etc.
Backports affecting the same file should be done in the same order, with the same 'before' state.
Real example: I merged PR A for file x.py and updated my clone to the result of the merge. I then prepared and merged PR B for the same file. Someone 'helpfully' prepared a backport of PR B, call it PR B3.6. It passed CI but was wrong. Fortunately, I checked the 'after' state of the file on a side-by-side diff. I prepared and merged PR A3.6, updated the 3.6 branck of my clone, and then prepared a new and correct backport of PR B.
Correct backporting is most easily assured if backports are done immediately. I currently do so myself instead of requesting and waiting for a contributor to do so (who likely is not immediately available). Even better would be for the backport to happen automatically.
My wishlist that I don't think anyone is actively working on ATM is:
- Bot to backport PRs (which could also be automatically merged)
So, to me, this is the priority item on the list.
- Bot to merge approved PRs (e.g. Rust's Homu)
How is a bot going to re-write the commit message? Beside which, 'approve' does not necessarily mean 'commit now'.
- Automate Misc/ACKS (or do away with it and do something like https://thanks.rust-lang.org/)
Nice, but it is easy enough to ask the new contributor to do it ;-).
- Make test coverage reports consistent
First, we need to make sure that the only difference in the before and after code is the diff shown on the PR files pages, so that the coverage difference is only due to the actual patch. From what I have seen, this does not seem true now. One way to make this happen would be to update the PR (or a copy thereof) to current repository, so that the only files affected by the tested PR are the ones intended and visible.
Second, at least for IDLE, the .coveragerc file needs a few exclude lines added. I suspect that they would be compatible with the rest of the tests. (This could be checked with grep.)
- Automatically close stale PRs (e.g. not signing CLA, changes requested but not being made, etc.)
What does 'close' (without merging) mean? I would not want older (IDLE) PRs permanently gone in any sense just because I am busy reviewing other patches. I recently merged PR based on a patch uploaded to BPO 8 years ago.
Not signing CLA is a special case.
- Bot to nudge core devs when they forget something (e.g. post-merge, a comment if someone forgot to change the commit message or PR number to have a "GH-" prefix)
When possible, I would prefer to get reminders before the merge.
-- Terry Jan Reedy
On Tue, 18 Jul 2017 at 16:06 Terry Reedy tjreedy@udel.edu wrote:
On 7/18/2017 2:31 PM, Brett Cannon wrote:
Once again, glad the goals are panning out. :) Key thing has always been to increase our bandwidth and part of that was always to push more on to contributors so they can be more self-servicing.
* most contributors create backports (using cherry-pick) themself. Before, this painful/error-prone task was usually done by a single developer without any review, without pre-commit tests, etc.Backports affecting the same file should be done in the same order, with the same 'before' state.
Real example: I merged PR A for file x.py and updated my clone to the result of the merge. I then prepared and merged PR B for the same file. Someone 'helpfully' prepared a backport of PR B, call it PR B3.6. It passed CI but was wrong. Fortunately, I checked the 'after' state of the file on a side-by-side diff. I prepared and merged PR A3.6, updated the 3.6 branck of my clone, and then prepared a new and correct backport of PR B.
Correct backporting is most easily assured if backports are done immediately. I currently do so myself instead of requesting and waiting for a contributor to do so (who likely is not immediately available). Even better would be for the backport to happen automatically.
My wishlist that I don't think anyone is actively working on ATM is:
Just so people know, I'm not going to reply to any comments about the wishlist since worrying about design details for something that doesn't even have someone motivated enough to work on it is I think too premature to worry about. I put this list here basically to see if something suddenly garnered someone's interest to implement or to see if there was an unexpected groundswell of interest to push it up the priority list. If any of these ideas to get someone behind them then the discussion will end up on the core-workflow mailing list.
On Tue, 18 Jul 2017 12:24:13 +0200, Victor Stinner victor.stinner@gmail.com wrote:
I'm just not unconfortable with the fact that an approval is kept even if the PR is modified after the review :-/ I would expect a list a notice "changed modified after the review" or something like that. At least, for my own reviews, to remind me to review again.
This could be changed if we have consensus to do so. Github has a setting that will cause existing approvals to be "dismissed" if a new commit is pushed.
Compared to Rietveld, GitHub review tool is as "a good" (not much better, not much worse). Sometimes, I'm lost in reviews: my comments are hidden, I have to unfold many widgets. But it's not that bad. It seems like avoiding rebase works around some of these issues.
I much prefer rietveld over github reviews, but I also much prefer the integration between the bug tracker and github over the minimal integration we had for rietveld. Thanks to all the people who made that happen, and especially Brett for leading it.
--David
On Jul 18, 2017, at 15:21, R. David Murray rdmurray@bitdance.com wrote:
I much prefer rietveld over github reviews, but I also much prefer the integration between the bug tracker and github over the minimal integration we had for rietveld. Thanks to all the people who made that happen, and especially Brett for leading it.
Not that I’m suggesting anything should change, but just FWIW, I find Gitlab to have a much better conversational review tool than Github. I often find myself getting lost in GH reviews (on many projects), but GL just organizes the conversation really well IMHO.
Cheers, -Barry
On Tue, 18 Jul 2017 at 12:54 Barry Warsaw barry@python.org wrote:
On Jul 18, 2017, at 15:21, R. David Murray rdmurray@bitdance.com wrote:
I much prefer rietveld over github reviews, but I also much prefer the integration between the bug tracker and github over the minimal integration we had for rietveld. Thanks to all the people who made that happen, and especially Brett for leading it.
Not that I’m suggesting anything should change, but just FWIW, I find Gitlab to have a much better conversational review tool than Github. I often find myself getting lost in GH reviews (on many projects), but GL just organizes the conversation really well IMHO.
It's very obvious, Barry, that you're playing the long game of trying to line up GitLab as the next platform once we grow tired of GitHub and need to switch in a few years. I'm on to you. ;)
- Bot to backport PRs (which could also be automatically merged)
So, to me, this is the priority item on the list.
I'm planning to work on the cherry-pick bot this during the core sprint in September. Unless someone beat me to it.
Automatically close stale PRs (e.g. not signing CLA, changes
requested but not being made, etc.)
This is also in my sprint plan, but only if I finish the cherry-pick bot :) Further discussion can be done here: https://github.com/python/core-workflow/issues/93
What does 'close' (without merging) mean?
The PR will be closed. The branch containing the changeset will still be available in the contributor's fork of CPython. Unless they delete it too.
On GitHub You can search for PRs that are closed but not merged by using the filters: is:pr is:closed is:unmerged
A list of closed PRs that were not merged https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is% 3Apr%20is%3Aclosed%20is%3Aunmerged%20
I believe the reopening the PR straight-forward: click on the "Reopen pull request" button.
Mariatta Wijaya
On Tue, Jul 18, 2017 at 4:01 PM, Brett Cannon brett@python.org wrote:
On Tue, 18 Jul 2017 at 12:54 Barry Warsaw barry@python.org wrote:
On Jul 18, 2017, at 15:21, R. David Murray rdmurray@bitdance.com wrote:
I much prefer rietveld over github reviews, but I also much prefer the integration between the bug tracker and github over the minimal integration we had for rietveld. Thanks to all the people who made that happen, and especially Brett for leading it.
Not that I’m suggesting anything should change, but just FWIW, I find Gitlab to have a much better conversational review tool than Github. I often find myself getting lost in GH reviews (on many projects), but GL just organizes the conversation really well IMHO.
It's very obvious, Barry, that you're playing the long game of trying to line up GitLab as the next platform once we grow tired of GitHub and need to switch in a few years. I'm on to you. ;)
python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
On Jul 18, 2017, at 11:01 PM, Brett Cannon wrote:
It's very obvious, Barry, that you're playing the long game of trying to line up GitLab as the next platform once we grow tired of GitHub and need to switch in a few years. I'm on to you. ;)
That, and bringing back the diamond operator for realz.
-B
2017-07-19 17:23 GMT+02:00 Barry Warsaw barry@python.org:
That, and bringing back the diamond operator for realz.
For people who don't know the "diamond operator" like me ;-)
haypo@selma$ python3 Python 3.5.3 (default, May 10 2017, 15:05:55)
from __future__ import barry_as_FLUFL 1 != 2
SyntaxError: invalid syntax
1 <> 2
True
Victor
Ah, how deservedly superficial my title is:
% python3 flufl.py File "flufl.py", line 3 1 <> 2 ^ SyntaxError: invalid syntax % cat flufl.py from __future__ import barry_as_FLUFL
1 <> 2
-Barry
On Jul 19, 2017, at 11:31, Victor Stinner victor.stinner@gmail.com wrote:
2017-07-19 17:23 GMT+02:00 Barry Warsaw barry@python.org:
That, and bringing back the diamond operator for realz.
For people who don't know the "diamond operator" like me ;-)
haypo@selma$ python3 Python 3.5.3 (default, May 10 2017, 15:05:55)
from __future__ import barry_as_FLUFL 1 != 2
SyntaxError: invalid syntax
1 <> 2
True
Victor
On 07/18/2017 02:36 AM, Antoine Pitrou wrote:
Can I take the opportunity to say thank you again (both you and Larry) for the "blurb" tool? It really makes an important difference when contributing.
On 07/18/2017 03:24 AM, Victor Stinner wrote:
Thank you Larry Hastings, Brett Cannon and others who helped to write and integrate blurb: no more Misc/NEWS conflict, it's just amazing :-) We *all* wanted that for *years*!
Thanks everybody! I'm glad it's been so well received.
By coincidence, I only saw this thread today, /*after*/ spending hours working through the last blurb integration issues. But it's been a success. And I'm pleased to announce I'll be releasing 3.5.4rc1 and 3.4.7rc1 with blurb fully integrated! There were a few surprising ramifications of blurb--but nothing we can't live with.
One nice side-effect of blurb: the formatting on Misc/NEWS, and therefore whatsnew/changelog.html, is somewhat improved. Every entry starts with a nice blue bpo-#### link, the section headers are 100% consistently spelled and in a consistent order, and we even have a shiny new "Security" section that goes at the top above "Core and Builtins".
//arry/
participants (10)
-
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Larry Hastings -
Mariatta Wijaya -
Nick Coghlan -
R. David Murray -
Serhiy Storchaka -
Terry Reedy -
Victor Stinner