13.06.18 23:46, Victor Stinner пише:
It's not like Pablo proposed the idea himself and force to get this
feature merged. Pablo just implemented an idea proposed by two other
It looks like Pablo implements ideas for which he does not fully
understand the consequences and the drawbacks. Well, his skills are
not bad, but we don't need more half-baken features in the stdlib,
it is better to have less but more qualitative
features that fit well with the rest of the stdlib.
I don't see anything wrong here. It's not uncommon that a newly merged
feature is still discussed, and I don't see anything wrong with
Pablo's behaviour here. I don't see how we could prevent such further
discussions on posix_spawn(). At least, I don't see how Pablo could
prevent these issues.
My point was that if you count the number of merged PRs, you should
exclude reverted and unfinished works.
At the end, I really like the final commit:
It adds a new rounding mode (_PyTime_ROUND_UP), write a non-trivial
function test for negative timeout, has a good NEWS entry, etc.
Pablo showed that he is able to implement large change and fix all
cases, not a single case. IMHO it's a good example, rather than a bad
It is just that more than a half of this work was made by you.
Many of other PRs are documentation fixes.
Is it an issue?
No, but these PRs are much easier. And some of them just add the
documentation for features added in other PRs and should not be
I think Pablo will be good core developer and agree with the description
given by Victor. But it seems that he still needs to learn something about
what changes are good for Python.
Ok, I account your -1 vote.
Actually just -0. After dropping reverted PRs I have no enough
information still for having a strong opinion. But I have no strong
objections if you hold on to him.
In private, I told Pablo that I consider that the main
difference between a core developer and a contributor is that core
developers are expected to spend more time on reviews and mentoring.
The main difference is that the core developer constantly make
decisions about his own and foreign patches. It is responsible for
quality of merged code.
IMHO the purpose of adding a new core developer is reducing the
burden for other core developers. He/she can take a part of the
work, make qualified reviews and merge PRs without involving
attention of BDFL or other core developers. For now, Pablo's PRs add
the work for core developers.