Title: Avoid master/slave terminology
Type: enhancement Stage: resolved
Components: Documentation, Interpreter Core Versions: Python 3.8
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: Mariatta, ammar2, berker.peksag, cheryl.sabella, eric.smith, giampaolo.rodola, gvanrossum, larry, miss-islington, pitrou, rhettinger, serhiy.storchaka, steven.daprano, suic, terry.reedy, vstinner, xtreak
Priority: normal Keywords: patch

Created on 2018-09-07 14:22 by vstinner, last changed 2018-09-16 20:52 by suic. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 9099 merged vstinner, 2018-09-07 14:43
PR 9100 closed vstinner, 2018-09-07 14:44
PR 9101 merged vstinner, 2018-09-07 15:16
PR 9102 merged vstinner, 2018-09-07 15:38
PR 9195 merged vstinner, 2018-09-11 22:40
Messages (45)
msg324739 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 14:21
For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.

For more context, see:

msg324740 - (view) Author: Ammar Askar (ammar2) * (Python triager) Date: 2018-09-07 14:26
Do you have examples of where this occurs? 

From I really only found the openpty function, and the man pages/argument names there already use this terminology so it wouldn't make much sense to change it there.
msg324744 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 14:43
I'm working on patches to change that.
msg324747 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 14:57
IMHO it's ok to keep the "master" term for:

* Git "master" branch
* "webmaster"
* "postmaster"

To find all impacted files, I used the commend:

git grep -i -E 'master|slave'|grep -v -E 'webmaster|postmaster|/blob/master/'
msg324748 - (view) Author: Ammar Askar (ammar2) * (Python triager) Date: 2018-09-07 14:58
The libregrtest change looks good but I disagree on the pty/openpty changes. If you look at all the current Linux man pages and documentation, they follow the master/slave terminology. Generally, Python documentation for underlying os functions like fork, stat etc are kept short because the OS documentation is the ultimate resource for them. 

This change causes a deviation from the existing standard and will only serve to make things more confusing, I would suggest deferring it until the actual OS documentation reflects this change as well.
msg324750 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 14:59
The doctest module has doctest.master symbol:
# For backward compatibility, a global instance of a DocTestRunner
# class, updated by testmod.
master = None

I'm not sure about changing this one. Here there is no slave, so it's less confusing.

But more generally, maybe it's time to remove this deprecated variable only kept for backward compatibility?
msg324752 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:00
Tkinter and IDLE are full of "master" variables:

   master: parent for widgets.

It seems to be a keep concept of Tkinter windows.
msg324754 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:04
nntplib.NNTP() has a slave() method, but this method sends a "SLAVE" command to the NNTP server. Changing that would require to modify the NNTP protocol, that's out of the scope of this issue...

RFC 977 "Network News Transfer Protocol" (NNTP)
Section 3.12: The SLAVE command
msg324755 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:06
In the C API, PyMemoryViewObject has a mbuf.master attribute, Include/memoryview.h:

typedef struct {
    int flags;          /* state flags */
    Py_ssize_t exports; /* number of direct memoryview exports */
    Py_buffer master; /* snapshot buffer obtained from the original exporter */
} _PyManagedBufferObject;

/* memoryview state flags */
#define _Py_MEMORYVIEW_RELEASED    0x001  /* access to master buffer blocked */
#define _Py_MEMORYVIEW_C           0x002  /* C-contiguous layout */
#define _Py_MEMORYVIEW_FORTRAN     0x004  /* Fortran contiguous layout */
#define _Py_MEMORYVIEW_SCALAR      0x008  /* scalar: ndim = 0 */
#define _Py_MEMORYVIEW_PIL         0x010  /* PIL-style layout */

typedef struct {
    _PyManagedBufferObject *mbuf; /* managed buffer */
    Py_hash_t hash;               /* hash value for read-only views */
    int flags;                    /* state flags */
    Py_ssize_t exports;           /* number of buffer re-exports */
    Py_buffer view;               /* private copy of the exporter's view */
    PyObject *weakreflist;
    Py_ssize_t ob_array[1];       /* shape, strides, suboffsets */
} PyMemoryViewObject;
msg324756 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:10
sqlite3.dump._iterdump() access to the "sqlite_master" table.... Hum, I don't think that Python chose the name of this table. This issue should be addressed in SQLite, not in Python.
msg324757 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:11
nis module contains the error message: NisError("No NIS master found for any map"), but libnis has a yp_master() function, it's no like Python picked this name. I suggest to keep "master" here to keep Python consistent with libnis. And "NIP master" gives the context of the "master" term.
msg324758 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:17
(Oops, I didn't want to put so many people in the nosy list, sorry about the spam.)
msg324759 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:17
Ok, with these 3 PRs, I should have replaced most usages of master and slave terms.
msg324760 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:20
New changeset 012f5b968a738b15ae9b40c499a1c0778b0615a9 by Victor Stinner in branch 'master':
bpo-34605, libregrtest: Rename --slaveargs to --worker-args (GH-9099)
msg324761 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:21
> bpo-34605, libregrtest: Rename --slaveargs to --worker-args (GH-9099)

I don't think that this change should be backported to 3.7 and older, since it *might* break the backward compatibility.
msg324762 - (view) Author: Karthikeyan Singaravelan (xtreak) * Date: 2018-09-07 15:23
Just want to add that it's a constant source of problem with respect to Redis and antirez wrote a detailed blog post about it yesterday : . It causes a lot of energy and emotional drain when issues like this get to twitter and top pages of HN :

msg324763 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 15:30
New changeset 5e922658fb55734bf8b4c6246033ea93af172ff7 by Victor Stinner in branch 'master':
bpo-34605: Avoid master/slave terms (GH-9101)
msg324768 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 16:13
New changeset 7e610bcdf128f61b925654e4fa80fbac83537d0e by Victor Stinner in branch 'master':
bpo-34605: childs => children (GH-9102)
msg324773 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2018-09-07 17:18
I'm a little surprised by this.  It's not like slavery was acceptable when these computer science terms were coined and it's only comparatively recently that they've gone out of fashion.  On the other hand, there are some areas in computer software where "master" and "slave" are the exact technical terms (e.g. IDE), and avoiding them would lead to confusion.

Of the four citations you reference, one of them is a PR for Django, and three of them say "see the Django PR".  The Django PR is an unreadable infinitely-long page of miserable arguing.  So the context doesn't help much.

Have there been any actual complaints?  Or is this an attempt to solve a problem that doesn't really exist?
msg324774 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2018-09-07 17:20
As a counter-example: A quick grep finds 555 occurrences of the word "kill" in CPython master.  Everybody knows killing is bad and using the term might upset certain people.  Yet I would not support expunging the word "kill" from Python.
msg324775 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 17:22
> Have there been any actual complaints?

Yes, but sadly they are private.
msg324776 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2018-09-07 17:25
> The Django PR is an unreadable infinitely-long page of miserable arguing.  So the context doesn't help much.

In short, some people associate the words "master" and "slave" to slavery. To enhance the diversity in the Python community, I suggest to try to avoid these terms whenever possible. As I wrote in previous comments, it seems like we have to keep them in a few places.
msg324777 - (view) Author: Larry Hastings (larry) * (Python committer) Date: 2018-09-07 17:50
> > Have there been any actual complaints?
> Yes, but sadly they are private.

I'm not super-excited by the idea that Python has to change its behavior based on secret comments.  Python has traditionally had a very open governance model where all discussions happen in public.

While I understand the need to preserve the privacy of victims, is there some way we can bring the decision-making process out into the open?  As far as I can tell, the entire process so far has been "Victor concludes that these terms are bad, and creates and merges several PRs an hour or two later with zero discussion".

Perhaps the complaints could be edited to anonymize them, and then we could see them?  Or must Python change its governance model because of diversity concerns?
msg324778 - (view) Author: Matthew Barnett (mrabarnett) * (Python triager) Date: 2018-09-07 18:19
Not all uses of the word "master" are associated with slavery, e.g. "master craftsman", "master copy", "master file table".

I think it's best to avoid use of master/slave where practicable, but other uses of "master" are not necessarily a problem.
msg324780 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-09-07 18:32
To me, there is nothing wrong with the word 'master', as such.  I mastered Python to become a master of Python.  Purging Python of 'master' seems ill-conceived.  The word 'slave' is different matter to me.

In tk and tkinter, the 'parent' and 'master' of a widget may be different widgets, but I cannot remember the functional difference, nor whether the terms are used consistently.

Like Larry, I object to action based on hidden evidence.
msg324786 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2018-09-07 19:07
Having said that, there are situations where words are used confusingly or inappropriately, and better choices are available.  (I am sometimes confused, for instance, by the use of 'client' and 'server'.)  In such situations, change can be justified without reference to private complaints.
msg324810 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2018-09-07 23:08
I'm using "master" in memoryview because of the audio connotation ("the 
source from which all copies will be produced"):

The ManagedBufferObject is literally the source from which all views 
are produced.

Conductors are sometimes called "Maestro", there are chess grandmasters, 
Tiger Woods won the Masters Tournament, Art Tatum is called a master 
pianist, millions of people hold a master's degree.

The term "master" has so many positive connotations that I think it is 
misguided to effectively eliminate it from the current English language.
msg324816 - (view) Author: Steven D'Aprano (steven.daprano) * (Python committer) Date: 2018-09-08 01:04
I strongly disagree with this as a general principle.

"Master/slave" is a powerful, obvious metaphor which works well and is not the same as parent/child, server/client or employer/worker.

In fact, in the BDSM subcultures, "master/slave" can have *positive* connotations. You want to support diversity, then why are you discriminating against that subculture?

Talking about diversity: my wife is of a nationality that historically were often stolen to be slaves and indentured servants, and were discriminated against as second-class people right well into the second half the middle of the 20th century. My maternal family comes from a racial group (Slavic) which gives us the English word for slave and come from serf background. Both of us are angered by this attack on our linguistic culture. Stop trying to sanitize and infantalize language. That's far more offensive than the master/slave terminology.

I'm not sorry for this impassioned plea. You want diversity, that includes people like me.
msg324822 - (view) Author: Gabriel Marko (suic) * Date: 2018-09-08 08:39

> For diversity reasons, it would be nice to try to avoid "master" and "slave" terminology which can be associated to slavery.

This is too vague. Define what "diversity reasons" are and elaborate your point. Referring to some online discussions is not a way for making a serious argument. Make a point at least (i.e. define the term, add pro/contra arguments and explain why you've taken your decision). Your political standpoint is your political standpoint and it's not my business. However, making these changes without giving reasons and arguments for them is a problem.

Let me ask:

Are these "diversity reasons" really reasons? What I've heard seen so far regarding "diversity reasons, ..." had little to nothing to do with rational thinking or argumentation. Is it really necessary to pollute Python code base with SJW ideology/terminology? What comes next?

Ad absurdum: If I find anything associated with something unpleasant to me in Python code or something which can be considered as e.g. "cultural appropriation", I'm free to change it for diversity reason?
msg324823 - (view) Author: Matej Cepl (mcepl) * Date: 2018-09-08 08:49
Guys, really, don't we have anything better to do with your time than this silliness?

Even if the terminology would be used in the strictest and most brutal meaning, i.e., slave must mindlessly follow orders of its master, there is nothing of approval of the real human slavery in the past (or present). This is just the pretty good terminology for such one-sided relationship which is traditionally used in the computer world. By elimination of the word from the world, not a yota changes about the reality of slavery in the past (or present).

-1 from me with the extreme violence for introducing such quasi-political nonsense to BPO and wasting everybody's time.
msg324825 - (view) Author: Gabriel Marko (suic) * Date: 2018-09-08 09:27
@mcepl: I completely agree with you that we shouldn't waste time with this. I would be better not to dig into the discussion about "master-slave" terminology. IMO we don't even need to go into that as the problem here is more substantial:

This case can create a very problematic precedent i.e. _on can modify (even drastically) a well established terminology based on "pseudo-reasons", political opinion or ideology_.

IMO this should be stopped and  prevented as soon as possible for all sake. On the other hand, I believe the @vstinner is a rational person and he is able to give _rational reasons_ for his decision which other could challenge as "potential offensiveness" of language is not an argument.
msg324838 - (view) Author: Cheryl Sabella (cheryl.sabella) * (Python triager) Date: 2018-09-08 12:59
This is certainly a topic that generates a lot of opinions both ways, not just here, but on many other projects.  Based on that, I don't think it's fair to blame Victor for bringing it up for discussion.  This is and has been an industry discussion for many years (master/slave as it relates to technology was named the most politically incorrect term in 2004).  Victor simply brought it up here.

All of the same arguments and counterarguments have been mentioned in these past discussions.  You can argue that this is ridiculous and political correctness has gone too far.  You can argue that this term (master/slave) perfectly reflects the model.  You can argue that it's not the same relationship as parent/child.  These are probably all valid reasons to not change it.  But, I think it's mostly because it's what we're used to.  

Here's an idea -- find a friend and explain to them that there is a concept in computer science where there is a group of 'things' and exactly one of those things is the main point of contact or first in line, but the other things around it that either get direction from that main one, or they are exact copies of that main one, or they are downstream from that main one.  Sometimes it's because if the main one isn't available, then one of the others is ready to take its place.  Or sometimes it's for other purposes (like IDE).  Really set the stage in describing what it is.  Then tell them it's called master/slave.  They probably won't believe that name because it's a little shocking.  We take it for granted, but it doesn't really describe the situation.

I know I'm simplifying and I'm probably not 100% accurate, but I think you get my point.  Except for the fact that it's imbedded in engineering and computer science and we know it, there's not really a  reason for it to be called what it is and there might be other alternatives that are better descriptors.

Personally, one that I've never seen suggested, but one that I think can be used to describe the relationship of "one in charge and others follow, but can take over" would be alpha/omega (as in a wolf pack).  It's a little stronger that leader/follower, doesn't imply the same structure as parent/child, and allows for the idea that an omega could take over the role of an alpha.  Plus, it's very neutral.  Just too bad the guys who originally coined the phrase "master/slave" didn't use "alpha/omega".  

(for the record, political correctness sometimes drives me crazy and I may not see a need to change something like master/slave, but at the same time, I can understand why other people would like to see it changed)

(second aside - I don't recall that there were arguments a few months ago on the PR to make the docs gender neutral.  Maybe people were against that too as being 'too politically correct', but they didn't feel the need to talk about.  To me, this issue is similar to that one.)
msg324840 - (view) Author: Ammar Askar (ammar2) * (Python triager) Date: 2018-09-08 13:48
Most of the opposition seems to be against a blanket replacing of all master and slave usages, which seems fairly reasonable to me. 

For example, I'm all for the libregrtest change since it conveys the meaning just as well and is an internal tool. However, changing MemoryView and pty seem way more iffy. These changes are potentially backwards incompatible and actually hurt usability.

Unlike other projects, Python doesn't have nearly enough uses of this terminology to warrant a massive political discussion in my opinion. Just look at the usages on a case-by-case basis and be done with it.
msg324841 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2018-09-08 13:55
I commented here to explain the master <-> view terminology of memoryview. 
If anyone wants to change that, please open a separate issue and add me as 
the author to the nosy list.
msg324843 - (view) Author: Gabriel Marko (suic) * Date: 2018-09-08 14:05
@cheryl.sabella let me challenge some points in your arguments:

> Based on that, I don't think it's fair to blame Victor for bringing it up for discussion.

Ok, but where was the discussion? @vstinner didn't even make a point and some of the PRs were merged. Maybe I'm too spoiled by the field where I come from but this can be hardly considered to be "bringing up something for a discussion" when someone doesn't even make a point (like e.g. "I think it should be changed because..."). Ad absurdum I could say: Because of because-it-can-hurt-someones-feelings reasons it would be nice to...

> I don't recall that there were arguments a few months ago on the PR to make the docs gender neutral.  Maybe people were against that too as being 'too politically correct', but they didn't feel the need to talk about.  To me, this issue is similar to that one.

_Personally_, I consider that to be the same kind of PC/SJW nonsense and there should've been a similar discussion. However, there's a big difference. Making documentation gender neutral is unnecessary but it doesn't affect any established CS terminology and doesn't introduce artificial terminological inconsistency between related technologies. 

> But, I think it's mostly because it's what we're used to.

Yes, and that's what is established terminology about.

> Here's an idea -- find a friend and explain to them that there is a concept in computer science...

When you enter a new field a part of your responsibility is to learn its terminology and not voluntarily change it because it somehow affects you (hurts your feelings, not compatible with your political view point etc.). Imagine doing the same thing in physics, chemistry or mathematics. Would you redefine number 1 for diversity reasons (there are ways for making up diversity reasons even for this*)? The terminology used inside a field is primarily for the people who are inside the field and understand it.

My arguments can sound a bit sarcastic as they try to illustrate the absurdity of this whole issue. They are by no means personal. Seeing all the PC/SJW nonsense around me, I'm afraid that this can be the starting of Python becoming PCython (by which I don't mean a combination of Python with Cython :)).

* To see how far could this go, look at this video:
msg324847 - (view) Author: Berker Peksag (berker.peksag) * (Python committer) Date: 2018-09-08 16:41
Personally, I find parent/child more descriptive if it can be used in the same context with master/slave, so I'm in favor of replacing master/slave with parent/child where applicable.

However, I agree that the code changes in PR 9100 are a bit excessive. It would be nice if we could keep the members of the public API (some of them have already been deprecated) and variable/function/parameter names left out of this cleanup.
msg324849 - (view) Author: Stefan Krah (skrah) * (Python committer) Date: 2018-09-08 17:04
Trying to remove myself from the nosy list again (I know that the interface sometimes surprisingly adds/removes persons).
msg324870 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2018-09-09 00:48
Mostly, I don't think these changes should be made, particularly in cases where "slave" isn't mentioned at all.  The word "master" is used in many contexts where master/slave doesn't apply (such as "master key").   Also, I think the PR disrespects all the original authors of the various documentation entries, none of whom have been consulted.

If a particular passage is demonstrably unclear or offensive, it should be changed; otherwise, we shouldn't let vaguely formed notions of political correctness shape other clear uses of plain English.  

As far as I can't tell there isn't a single instance where the docs use "master" as a reference to human slavery or where the use could be seen to imply an endorsement of that notion.

FWIW, Guido drew a line for this a few years ago when someone suggested removing the example using the phrase, "I see said the blind man and he picked up the hammer and saw".  The judgment was that we weren't going to go down this path unless there was actual offensive speech.
msg324955 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2018-09-10 23:08
Indeed, "master" in itself is used in a wide range of contexts and can have quite positive connotations (I master Python programming).

The word "slave" I agree with removing if used gratuitously. If its use reflects an established convention which we do not have power to change, then we should probably keep using it for the sake of clarity (for example in the openpty case, since we're merely exposing a glibc function).
msg324995 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2018-09-11 06:33
I'm closing this now. Three out of four of Victor's PRs have been merged. The fourth one should not be merged because it reflects the underlying terminology of UNIX ptys. There's a remaining quibble about "pliant children" -> "helpers" but that can be dealt with as a follow-up PR without keeping this discussion open.
msg325094 - (view) Author: miss-islington (miss-islington) Date: 2018-09-11 23:40
New changeset fa7dfae3171914f91d629a64c6e829788b485b06 by Miss Islington (bot) (Victor Stinner) in branch 'master':
bpo-34605: Replace "pliant children" with "helpers" (GH-9195)
msg325241 - (view) Author: Gabriel Marko (suic) * Date: 2018-09-13 12:24
The discussion under GH PRs is now censored. What will be the next level?
msg325247 - (view) Author: Mariatta Wijaya (Mariatta) * (Python committer) Date: 2018-09-13 14:16
No further discussion needed. This issue has been closed and resolved. Thanks Victor for the PRs.
msg325351 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2018-09-14 15:29
News about this issue published on different resources are exaggerated. Actually the controversial changes were rejected. All merged changes look correct to me, they fix outdated terminology ("worker" instead of "buildslave" is now the official term in the Buildbot documentation) and make the documentation using more common terminology (for example "parent process" instead of "master process" in context of multiprocessing).
msg325500 - (view) Author: Gabriel Marko (suic) * Date: 2018-09-16 20:52
@serhiy.storchaka: IMO, the problem isn't the master/slave terminology itself but the way how the changes were introduced (no discussion) and the justification ("diversity reasons"???).

IMO this is the next level: and I can't imagine what comes next. I find this nonsensical and I'm very disappointed that this ideological nonsense is infecting Python.

IMO the core developers should make a clear statement about this (either pro or contra). Once it's made, I'll have no other choice than respect that stance and act accordingly. Saying that "there will be not more discussions" or sending people to twitter like Guido did is not a solution and it's rather damaging the Python community and its reputation. :(
Date User Action Args
2018-09-16 20:52:13suicsetmessages: + msg325500
2018-09-14 15:29:00serhiy.storchakasetnosy: + serhiy.storchaka
messages: + msg325351
2018-09-13 14:16:27Mariattasetnosy: + Mariatta
messages: + msg325247
2018-09-13 12:24:39suicsetmessages: + msg325241
2018-09-13 10:42:11giampaolo.rodolasetnosy: + giampaolo.rodola
2018-09-11 23:40:09miss-islingtonsetnosy: + miss-islington
messages: + msg325094
2018-09-11 22:40:34vstinnersetpull_requests: + pull_request8631
2018-09-11 06:33:15gvanrossumsetstatus: open -> closed

nosy: + gvanrossum
messages: + msg324995

resolution: fixed
stage: patch review -> resolved
2018-09-10 23:08:18pitrousetnosy: + pitrou
messages: + msg324955
2018-09-09 00:48:53rhettingersetnosy: + rhettinger
messages: + msg324870
2018-09-08 21:59:30mceplsetnosy: - mcepl
2018-09-08 17:04:38skrahsetnosy: - skrah
2018-09-08 17:04:14skrahsetnosy: terry.reedy, vstinner, larry, eric.smith, mcepl, steven.daprano, skrah, berker.peksag, ammar2, cheryl.sabella, suic, xtreak
messages: + msg324849
2018-09-08 16:41:51berker.peksagsetnosy: + berker.peksag
messages: + msg324847

components: + Documentation
type: enhancement
2018-09-08 14:05:51suicsetnosy: + skrah
messages: + msg324843
2018-09-08 13:55:56skrahsetnosy: - skrah
2018-09-08 13:55:31skrahsetmessages: + msg324841
2018-09-08 13:48:14ammar2setmessages: + msg324840
2018-09-08 12:59:21cheryl.sabellasetnosy: + cheryl.sabella
messages: + msg324838
2018-09-08 09:27:12suicsetmessages: + msg324825
2018-09-08 08:49:20mceplsetnosy: + mcepl
messages: + msg324823
2018-09-08 08:43:34eric.smithsetnosy: + eric.smith
2018-09-08 08:39:53suicsetnosy: + suic
messages: + msg324822
2018-09-08 01:04:13steven.dapranosetnosy: + steven.daprano
messages: + msg324816
2018-09-07 23:08:27skrahsetnosy: + skrah
messages: + msg324810
2018-09-07 19:07:18terry.reedysetmessages: + msg324786
2018-09-07 18:32:13terry.reedysetnosy: + terry.reedy, - mrabarnett
messages: + msg324780
2018-09-07 18:19:50mrabarnettsetnosy: + mrabarnett
messages: + msg324778
2018-09-07 17:50:43larrysetmessages: + msg324777
2018-09-07 17:25:06vstinnersetmessages: + msg324776
2018-09-07 17:22:31vstinnersetmessages: + msg324775
2018-09-07 17:20:49larrysetmessages: + msg324774
2018-09-07 17:18:01larrysetnosy: + larry
messages: + msg324773
2018-09-07 16:13:14vstinnersetmessages: + msg324768
2018-09-07 15:38:35vstinnersetpull_requests: + pull_request8556
2018-09-07 15:30:36vstinnersetmessages: + msg324763
2018-09-07 15:23:07xtreaksetnosy: + xtreak
messages: + msg324762
2018-09-07 15:21:25vstinnersetmessages: + msg324761
2018-09-07 15:20:45vstinnersetmessages: + msg324760
2018-09-07 15:17:59vstinnersetmessages: + msg324759
2018-09-07 15:17:17vstinnersetnosy: - barry, terry.reedy, paul.moore, ronaldoussoren, larry, tim.golden, ned.deily, ezio.melotti, eric.araujo, mrabarnett, r.david.murray, asvetlov, docs@python, zach.ware, koobs, steve.dower, dstufft, Alex.Willmer
messages: + msg324758
2018-09-07 15:16:38vstinnersetcomponents: - Build, Demos and Tools, Distutils, Documentation, Extension Modules, IDLE, Installation, Library (Lib), macOS, Regular Expressions, Tests, Tkinter, Unicode, Windows, XML, 2to3 (2.x to 3.x conversion tool), ctypes, IO, Cross-Build, email, Argument Clinic, FreeBSD, SSL
2018-09-07 15:16:18vstinnersetpull_requests: + pull_request8555
2018-09-07 15:13:51yselivanovsetnosy: - yselivanov
components: - asyncio
2018-09-07 15:11:33vstinnersetmessages: + msg324757
2018-09-07 15:10:10vstinnersetmessages: + msg324756
2018-09-07 15:06:26vstinnersetmessages: + msg324755
2018-09-07 15:04:06vstinnersetmessages: + msg324754
2018-09-07 15:00:49vstinnersetmessages: + msg324752
2018-09-07 14:59:52vstinnersetmessages: + msg324750
2018-09-07 14:58:40ammar2setmessages: + msg324748
2018-09-07 14:57:23vstinnersetmessages: + msg324747
2018-09-07 14:44:46vstinnersetpull_requests: + pull_request8554
2018-09-07 14:43:31vstinnersetkeywords: + patch
stage: patch review
pull_requests: + pull_request8553
2018-09-07 14:43:19vstinnersetmessages: + msg324744
2018-09-07 14:26:28ammar2setnosy: + ammar2
messages: + msg324740
2018-09-07 14:22:00vstinnercreate