[Python-Dev] How far to go with user-friendliness

2015-07-18 Thread Victor Stinner 
Hi Antoine,

I'm really sad to read your message. Antoine is one of the most active
Python core developer and it would be a big loss if he really stops
contributing. Antoine helped me to stop the drug called "micro
optimization", he always has good advices on the Python development.

I tried to stay away the discussion on mock, but it's hard because it is
flooding my mailbox. I had to use mox (moX, not moCK) and I don't like its
API. I really like mock API, it's natural and obvious.

When mock 1.1 was released, many people complained because "it broke
OpenStack (CI)". A few days later i unerstood that raising an error for
unkown methods with a name starting with "assert" is a good thing. It
helped to fix a lot a bugs in OpenStack tests!

For the discussion on "assret", I'm surprised how much people replied. The
mock maintainer, Michael Foord, replied: it was an explicit request from
users...

Victor

Le samedi 18 juillet 2015, Antoine Pitrou  a écrit :

>
> Frankly, this kind of inept discussion, where a bunch of folks get hung
> up about an extremely minor design decision (who cares whether "assret"
> is being special-cased or not? in the actual world, not the fantasy
> world of righteous indignation and armchair architects?), is amongst
> the reasons why I'm stopping contributing to CPython.
>
> Keep up the good work, you're making this place totally repulsive to
> participate in. Every maintainer or contributor now has an army of
> voluntary hair-splitters to bother about, most of whom probably aren't
> relying on said functionality to begin with.
>
> Regards
>
> Antoine.
>
___
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: Python 3.5 beta 4 is tagged in one week

2015-07-18 Thread Larry Hastings 



Approximately a week from when I post this, I'll be tagging Python 3.5 
beta 4, which is the last beta before we go to release candidates.  
Please wind up all your bug fixes soon, I'd really like checkins to 3.5 
to stop soon.


And a minor reminder: when we hit Release Candidate 1, I'll be switching 
the canonical repo for 3.5 to a public Bitbucket repo. Any bug fixes 
that go in between RC 1 and final will only be merged using Bitbucket 
"pull requests".


The new workflow experiment continues,


//arry/
___
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] How far to go with user-friendliness

2015-07-18 Thread s.krah 


 Ein Sa, 18 Jul 2015 04:34:19 + Stephen J. Turnbull 
 hat geschrieben  

Antoine Pitrou writes: 
 > [...] is amongst the reasons why I'm stopping contributing to 
 > CPython. 
 
> We'll miss your code. But you're only one committer, even if you've 
> contributed more than the average amount. On the other hand, Python 
> needs to *grow* the committer group beyond its current size, and 
> *some* such discussion is necessary for new committers' advancement to 
> "benevolent dictator for one PEP" level, which is also a pain point 
> IMHO.

I don't think growing committer numbers is CPython's #1 problem. CPython
needs *relevant*contributions:  Hypothetically speaking, I'd wager that
someone writing an industrial strength concurrent garbage collector is
*far more likely* to share Antoine's attitude.

ALL developer's who fall into that category are being put off by the
current climate on python-dev and python-ideas, and there's no
shortage of other languages to contribute to.

Likewise, I don't think PEPs are the problem either: Python already has
too many features (recently I found myself thinking that C++ is a really
nice small language :).


Stefan Krah


___
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] How far to go with user-friendliness

2015-07-18 Thread Stephen J. Turnbull 
s.krah writes:

 > I don't think growing committer numbers is CPython's #1 problem.

Maybe not; not being a committer I don't have a strong opinion myself.
However, committers, and especially the group qualified for the BD1P
role, regularly post wishes for more senior developers to these lists.

 > Hypothetically speaking, I'd wager that someone writing an
 > industrial strength concurrent garbage collector is *far more
 > likely* to share Antoine's attitude.

I hope not.  It's one thing to wish that one can be surrounded by
peers with compatible workflows.  It's another to address those who
aren't one's peers with words like "keep up the good work, it's people
like you that make this a repulsive place to be."  (That may not be an
exact quote but it's in the same spirit.)

 > All developer's who fall into that category are being put off by the
 > current climate on python-dev and python-ideas, and there's no
 > shortage of other languages to contribute to.

And you propose to do what about that?  I made a concrete proposal (a
cloture rule) that would be an improvement.  It has precedent from
Guido himself.

It's not a panacea, of course, but AFAIK the committers in general
still prefer an open community; closing the lists or asking
non-committers or non-module-owners or whatever to be "seen and not
heard" is not going to get support.  So I don't think there is a
panacea.  It's unfortunate if that means some senior developers decide
to leave, but senior developers do leave projects occasionally for a
variety of reasons.  All the more reason to cultivate an environment
where new people feel free to join and participate, IMO, YMMV.

For senior developers in a community as large as Python's, with a code
base to match, to continue to get value from participation, they're
going to need to have a bit of noblesse oblige in their makeup.  In
that sense, senior developers in Python are victims of its success.

 > Likewise, I don't think PEPs are the problem either:

I'm sorry, I wasn't clear.  The point is not a need to produce and
approve more PEPs, or even commits.  It's having more people at the
levels where they're *qualified* for commit rights or the BD1P role.
Those are the people who make it fun for each other to keep working on
a large, mature project where curating existing code is a large
burden.  Partly because they're fun and productive to work with, and
partly because they can share the burden of maintenance.

Regards,
___
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] How far to go with user-friendliness

2015-07-18 Thread s.krah 


Stephen J. Turnbull  wrote:

 >> Hypothetically speaking, I'd wager that someone writing an 
 >> industrial strength concurrent garbage collector is *far more 
 >> likely* to share Antoine's attitude. 
 
> I hope not. It's one thing to wish that one can be surrounded by 
> peers with compatible workflows. It's another to address those who 
> aren't one's peers with words like "keep up the good work, it's people 
> like you that make this a repulsive place to be." (That may not be an 
> exact quote but it's in the same spirit.) 

Sorry, that amounts to twisting my words. An attitude is a general way of
approaching things and I meant it in a positive way.

I haven't read the flame you're alluding to, but an occasional flame is NOT
the defining characteristic of a person.

On the contrary, on the bug-tracker Antoine has been most helpful,
responsive and welcoming towards newcomers.


It would be a great loss if he really stops and I hope he'll reconsider.


Stefan Krah






___
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] How far to go with user-friendliness

2015-07-18 Thread Stephen J. Turnbull 
s.krah writes:

 > Sorry, that amounts to twisting my words.

Let's not play the dozens here.  That just extends the thread to no
point.

 > It would be a great loss if he really stops and I hope he'll
 > reconsider.

I agree with both points.  I don't think anybody disagrees, so let's
not belabor them, either -- after all, the point here is that people
keep posting about things that don't help solve real problems.

I have two proposals on the table ("cloture" and "redirect people
dissatisfied with the offered rationale to a more appropriate channel
for discussion").  Perhaps we could discuss those, or propose
additional or better ways to improve the situation, or a better
channel for this "meta" discussion itself?  After Nick's post, I think
there's no denying that Antoine has plenty of company in frustration
-- there is a systematic problem here.

Regards,
___
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] cpython: Tighten-up code in the set iterator to use an entry pointer rather than

2015-07-18 Thread Ezio Melotti 
On Thu, Jul 9, 2015 at 3:41 PM, Guido van Rossum  wrote:
> On Wed, Jul 8, 2015 at 10:19 PM, Serhiy Storchaka 
> wrote:
>>
>> On 08.07.15 01:45, Raymond Hettinger wrote:
>>>
>>> P.S.  I don't think python-dev post was necessary or helpful (and I still
>>> haven't had a chance to read the whole thread).  It would have been
>>> sufficient to assign the tracker entry back to me.
>>
>>
>> Well, I'll open new issue and assign it to you for every your commit that
>> looks questionable to me.
>
>
> That sounds like a fine solution, and a good conclusion of the thread.
>

Whenever I have a non-trivial commit to do, I create a patch and
upload it to the tracker, with an explanation of the problem and the
solution.  If after a few days no one commented, I commit it and close
the issue.

If a problem arises post-commit, people can reopen the issue and
comment there.  Since the issue number is included in all the commits,
it is also easy to find related discussions.

Creating an issue after the fact is an acceptable solution too, but I
would prefer to see an issue before the commit.

FWIW I only consider simple documentation issues and typo/whitespace
fixes as "trivial", YMMV.

Best Regards,
Ezio Melotti


> --
> --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] How far to go with user-friendliness

2015-07-18 Thread Nick Coghlan 
On 18 Jul 2015 1:19 pm, "Nick Coghlan"  wrote:
> I'm with Antoine in wondering why we even bother with contributing when
the thanks we can expect is for people to feel entitled to demand we spend
hours of our time debating trivial details

Sorry, I crossed a line there - I know everyone posting to this thread is
doing so with the best interests of Python at heart.

I also know that from the questioners' side this kind of thread feels like
a perfectly reasonable request for further explanation. However, from the
core developer side, some folks are averaging more than 3 commits a day,
and we have the ever looming presence of almost *five thousand* open issues
that we haven't had the opportunity to address (I'm personally on the nosy
list for more than 400 of them).

Whenever someone offers a patch to address one of those issues, we have to
decide how fussy we want to be - every time we say "No, that's not ready
yet", there's a chance other priorities will come up for the contributor
(even when it's another core developer) that mean we end up with a patch
languishing on the tracker with unaddressed feedback rather than a resolved
issue.

As a result, the question asked about potential changes isn't generally "Is
this perfect?" but rather "Is this usable, maintainable, complete and an
improvement over the status quo?".

If a contribution passes that *second* barrier, then it's likely to be
accepted. This is also the standard we'll apply to *ourselves* in deciding
whether or not we'd like a pre-commit review on a particular change.

This means the kind of question raised in this thread has a standard
answer: the change was made because the contributor addressing the issue
wanted to address it that way, and the core developer committing the change
was willing to accept public responsibility for any *actual* (as opposed to
hypothetical) long term harm arising from the decision.

We can sometimes construct an after-the-fact rationalisation, but honestly,
it usually comes down to asking ourselves the question "Am I prepared to
reject this improvement entirely over that one potentially controversial
aspect?" and deciding that we'd prefer to accept the long term technical
risk over the near term social risk of potentially alienating the patch
author.

The *problem* with threads like this one is that they end up feeling like
punishment for being accommodating to the wishes of contributors on minor
design details. The end result of such a process isn't a better CPython -
it's *higher* barriers to contribution and *more* unresolved issues, as
core developers become ever more reluctant to accept responsibility for
contributed changes that may in any way be controversial.

Potential core developers are also likely to be put off by the prospect of
"you too can volunteer to be micromanaged by a large community mailing
list, doesn't that sound like fun?"

Review throughput is our primary bottleneck in getting fixes and
enhancements into CPython. While tooling improvements can help us make
better use of the time of the core developers we already have, and better
track and acknowledge the efforts of potential future core developers, the
reasons folks *quit* are social ones, as are the reasons folks get
discouraged from contributing in the first place.

That's the tension at the heart of open source development - every time we
object to someone else's decision or reject their work, we run the risk of
contributing to one of our peers deciding to stop volunteering their time
and energy. We run the same risk every time we use our control over
infrastructure and tools to enforce a change in process and practices.

Not taking those risks isn't the answer - that's a recipe for stagnation,
rather than continuous improvement. Rather, we want to be taking those
risks deliberately and consciously, having already asked ourselves "If this
is the final straw in someone deciding that contributing to our community
isn't a worthwhile use of their time, am I prepared to accept that
responsibility over this particular topic?".

Regards,
Nick.
___
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