[Python-Dev] Python "2migr8"

Stephen J. Turnbull stephen at xemacs.org
Tue Apr 15 04:48:40 CEST 2014


Guido van Rossum writes:

 > On Mon, Apr 14, 2014 at 4:02 PM, Donald Stufft <donald at stufft.io> wrote:

 >> As someone who *has* given back, I can certainly understand why
 >> someone would feel that way. It often times *does* feel like
 >> CPython doesn’t want contributions.

Sure, but most of the time that feeling is based on a completely
contributor-centric viewpoint.  (Not to mention that I think this is a
little ironic given the position you're taking in the PEP 440
vs. semantic versioning thread.  I agree 100%, but still: ironic.)

As a user and wannabe developer of Python, one of the things I love
about Python (compared to say, Emacsen *shudder*) is that it has been
very good about avoiding the

    1. I have a problem.
    2. This patch fixes my problem.
    3. Now Python has a problem.

syndrome.  Contributors typically feel like they're unwanted, though,
at least at some points in the process of resolving (3) *before* the
patch gets into the mainline.  Of course mostly they're grownups and
get over it, but I suppose that feeling is what Donald is pointing to.

But there's a problem beyond "feeling" for developers paid to work *in
but not on* Python.  I suppose that often their employers *are*
sufficiently enlightened to be willing to allow their people to work
up a full patch (including tests and documentation), but *not* willing
to allow their people to spend twice as much time (or more) getting to
a "fully Pythonic" solution.

And it's not just the employer; the developer herself probably feels
that it's not a profitable use of her time.  She's solved her problem,
she's met the formal requirements for a Python contribution, it's
probably code she's proud of, and she's got 10 more tasks of the same
ilk listed on a whiteboard in her cubicle.  As a professional, of
course she wants to get to work on those.

I can see a few possible ways to address this.

1.  Commit core resources to fast-tracking (through review, concrete
    suggestions for improvement, and additional code) contributions
    from people who are "on deadline".  (Yeah, I know, that's
    problematic, and not just because of the scarcity of core
    reviewers.  But what else can we do?)

2.  Educate the employers about the benefits, not only from higher-
    quality code, but access to resources like core developer
    attention and (perhaps future hiring :-), and happier developers,
    that comes from encouraging their people to participate fully in
    the process.

    The point is to create a "you're *supposed* to spend the extra
    time" atmosphere *in the employment context*.

    This probably would work best if Guido's boss talks to the
    developer's boss at $BILLION_DOLLAR_BUSINESS. :-)

    Do Google and DropBox have blogs where they explain their "tithe
    to open source" policies?

3.  Related to 2.  I think there's an impression out there that "open
    source tithes" are for the top 1% of programmers.  I know that at
    LUG meetings and the like I've often heard comments like "nice
    work if you can get it, but my employer never will offer it to me".

    This impression must be debunked.  And it can be debunked.  Sure,
    there are many "we created this job for a particular genius
    programmer" positions out there, but many excellent companies have
    a generic tithe for all their developers.  We need examples other
    than Google.

4.  Get those developers to PyCon.  Get their bosses to PyCon. :-)
    Or maybe this should be point #1. :-)

 > Donald, your remark in itself sounds unnecessarily (and
 > unproductively!) passive-aggressive.

FWIW, I didn't read it that way.  I took it as a genuinely "more in
sorrow than in anger" statement.



More information about the Python-Dev mailing list