Sexism in the Ruby community: how does the Python community manage it?

Owen Jacobson owen.jacobson at grimoire.ca
Wed Oct 16 23:13:33 EDT 2013


Last week, Elad Maidar wrote a fairly short but readable opinion 
piece[0] illustrating some long-standing social problems in the Ruby 
community, ending with a very specific call to action around naming 
conventions for Ruby projects and gems. To save you the trouble of 
scrolling to the bottom of this post and clicking, here's the relevant 
bit:

> What is missing you ask? I think that there is no consideration in 
> women when it comes to gem naming convention, here are a few gems that 
> i found in a 5 mintues search on Rubygems.org to demonstrate why women 
> and other groups probably feel uncomfortable when trying to get into 
> the Rails community:
> 
> * retarded
> * bitch
> * hoe
> * womanizer
> * recursive_pimp_slap
> * miniskirt
> * childlabor
> * bj
> * sex
> * fuck
> * rape-me
> * therapist - yeah, It passes as a double meaning - but still.
> * shag
> * db_nazi
> * and ass
> 
> While some of you may think this is a righteous callout - I think that 
> as a community we need to strive to be as appealing as possible, there 
> is nothing cool about naming your gem “fuck” or “retarded” and we as a 
> community - need to stop this from happening as much as we can.

Read the rest, it's pretty good.

(A number of the named gems have been pulled by their authors.)

It occurred to me to go digging around pypi - arguably[1] the Python 
community's equivalent to gems - to see if I could find similar 
institutionalized sexism.

The good news: the specific examples Elad called out are STRIKINGLY 
absent from pypi. By and large the published python packages are 
inobjectionable. Well done, "us", in as much as there is an "us" to 
congratulate.

There are a few examples of the same sort of bad decision-making that 
are, I think, worth discussing:

* SexMachine (https://pypi.python.org/pypi/SexMachine/0.1.1 - an 
attempt to detect the gender of names, which… well, ask the nearest boy 
named Sue - or girl named Leslie)
* sexytime (https://pypi.python.org/pypi/sexytime/0.1.0)
* pep8nazi (https://pypi.python.org/pypi/pep8nazi/0.1 - do we shove 
non-PEP8-compliant authors into "showers" now?)

So, two questions:

1. What social biases and problems *do* we unwittingly encourage by way 
of community-tolerated behaviour? Where, if not through the conventions 
for naming, do we encourage sexism, racism, and other mindlessly 
exclusionary behaviour?

2. What kind of social pressure can we bring to bear to _keep_ Python's 
package naming conventions as socially neutral as they are, if and when 
some high-profile dirtbag decides this language is the best language? 
How can we apply the same pressures to other parts of the Python 
community?

3. How can we reach out to the Ruby community and help *them* get past 
the current crop of gender issues, and help them as a group to do 
better next time?

I'm very much on the side of education, tolerance, and social 
consequences, not administrative fiat or organized retaliation. I think 
Elad's call for the Rubygems folks to unilaterally drop libraries is 
misguided, but well-intentioned, and I don't think the same sort of 
call towards Pypi to drop "unacceptable" library names is a good idea 
either. However, I think it's hugely important and hugely beneficial 
that we welcome as many folks into the Python community as possible, 
and do our best to foster an environment where people can succeed 
regardless of who or what they are, and recent evidence suggests that 
that requires ongoing conversation and engagement, not just passive 
acceptance.

So, how should we be more awesome?

-o

(For some additional context, and why I think passive acceptance isn't 
good enough, see 
http://iangent.blogspot.ca/2013/10/the-petrie-multiplier-why-attack-on.html 
.)

[0] 
http://devandpencil.herokuapp.com/blog/2013/10/09/being-an-asshole-does-not-make-you-awesome/ 

[1] as in let's not have a packaging or language mudfight over it, 
please? Pretty please?




More information about the Python-list mailing list