[python-committers] My cavalier and aggressive manner, API change and bugs introduced for basically zero benefit

[Ezio Melotti]

On Sat, Jan 21, 2017 at 9:51 PM, Brett Cannon <brett at python.org> wrote:
> What I'm picking up from this is (as a gross oversimplification):
>
> * Victor _wants_ code reviews
> * Raymond thinks we _need_ code reviews
>
> So the common theme here regardless of whether you agree with Raymond or
> Victor's approach to development is that we are not getting enough code
> reviews to go around. To me that's what the systemic issue is that this
> email is bringing up.
>
> Now I think most of us don't think the solution to the lack of reviews is to
> lower our standard of what it takes to become a core developer (this doesn't
> mean we shouldn't do a better job of identifying potential candidates, just
> that we shouldn't give people commit privileges after a single patch like
> some projects do). To me that means we need to address why out of 79 core
> developers only 39 have a single commit over the past year, 30/79 have more
> than 12 commits over that same time scale, 15/79 people have more than 52
> commits, and 2/79 people have over 365 commits
> (https://github.com/python/cpython/graphs/contributors?from=2016-01-22&to=2017-01-21&type=c
> for the stats).
>
> Some of you have said you're waiting for the GitHub migration before you
> start contributing again, which I can understand (I'm going to be sending an
> email with an update on that after this email to python-dev &
> core-workflow). But for those that have not told me that I don't know what
> it will take to get you involved again.

I can tell you what drove me away:
1) real life got in the way, time is limited;
2) I spend the available time working on the bug tracker rather than
on core Python, since my time is likely more valuable if spent on bpo;
3) MLs are quite high traffic, and I gave up keeping up /for now/ [0]
(I have 6.8k unread mails from python-checkins, 460 from
python-issues, 320 from python-dev).  This also means that:
  a) if a bug related to one of the modules I maintained is opened, I
won't see it[1];
  b) if a message explicitly asks for my opinion/review, I won't see it[1];
4) the GitHub migration (first I was against, now I'm waiting for
everything to settle and then give it a try, in future I hope it will
become a reason to get me involved again);
5) the more time I spend away, the more difficult it becomes to follow
all the new features that get introduced.

As for what would get me involved again, for my case there's not much
else you can do -- I just need to find more free time, catch up with
development (mails, tools, features, etc) and then try to keep up.

Best Regards,
Ezio Melotti

[0]: FWIW one thing that helped me keeping the mail traffic low(er),
was following the weekly issues reports on python-dev, and adding
myself to nosy on the issues I cared about, rather than subscribing
and following the other mailing list (python-bugs-list and
new-bugs-announce).
I also used to keep an eye on #python-dev for new issues and replies,
and I wish more core-devs would hang around there, since it makes
communication (including asking for opinions/reviews) much faster.

[1]: Feel free to reach to me directly, either on IRC or via direct mail.

> For instance, not to pick on Andrew
> but he hasn't committed anything but he obviously still cares about the
> project. So what would it take to get Andrew to help review patches again so
> that the next time something involving random comes through he feels like
> taking a quick look?
>
> As I have said before, the reason I took on the GitHub migration is for us
> core developers. I want our workflow to be as easy as possible so that we
> can be as productive as possible. But the unspoken goal I have long-term is
> to get to the point that even dormant core devs want to contribute again,
> and to the point that everyone reviews a patch/month and more people
> reviewing a patch/week (although I'll take a patch/year to start). I want to
> get to the point that every person with commit privileges takes 30 minutes a
> month to help with reviews and that the majority of folks take 30 minutes a
> week to review (and please don't think this as a hard rule and if you don't
> the privileges go away, view this as an aspirational goal). Even if people
> who don't have time to review the kind of patches Victor is producing which
> triggered this thread, reviewing documentation patches can be done without
> deep knowledge of things and without taking much time. That way people who
> have time to review the bigger, more difficult patches can actually spend
> their time on those reviews and not worrying about patches fixing a spelling
> mistake or adding a new test to raise test coverage.
>
> All of this is so that I hope one day we get to the point where all patches
> require a review no matter who proposed the code change. Now I think we're
> quite a ways of from being there, but that's my moonshot goal for our
> workflow: that we have enough quality reviews coming in that we feel that
> even patches from fellow core developers is worth requiring the extra code
> check and disbursement of knowledge without feeling like a terrible drag on
> productivity.
>
> Once the GitHub migration has occurred I'm planning to tackle our Misc/NEWS
> problem and then automate Misc/ACKS. After that, though, I hope we can take
> the time to have a hard look at what in our workflow prevents people from
> making even occasional code reviews so that everyone wants to help out again
> (and if any of this interests you then please subscribe to core-workflow).
>
>
> On Fri, 20 Jan 2017 at 02:46 Victor Stinner <victor.stinner at gmail.com>
> wrote:
>>
>> Hi,
>>
>> Raymond Hettinger used a regression that I introduced in the builtin
>> sorted() function (in Python 3.6.0) to give me his feedback on my
>> FASTCALL work, but also on Argument Clinic.
>>
>> Context: http://bugs.python.org/issue29327#msg285848
>>
>> Since the reported issues is wider than just FASTCALL, including how I
>> contribute to CPython, I decided to discuss the topic with a wider
>> audience. I continue the discussion on python-committers to get the
>> opinion of the other core developers.
>>
>> Sorry for my very long answer! I tried to answer to each issues
>> reported by Raymond.
>>
>> Inaccurate summary: I'm a strong supporter of "it's better to ask
>> forgiveness than permission", whereas Raymond considers that I
>> introduced too many regressions with my workflow.
>>
>>
>> Raymond Hettinger added the comment:
>> > A few random thoughts that may or may not be helpful:
>> >
>> > * We now have two seasoned developers and one new core developer that
>> > collectively are creating many non-trivial patches to core parts of Python
>> > at an unprecedented rate of change.  The patches are coming in much faster
>> > than they can reasonably be reviewed and carefully considered, especially by
>> > devs such as myself who have very limited time available.  IMO, taken as
>> > whole, these changes are destabilizing the language.  Python is so
>> > successful and widely adopted that we can't afford a "shit happens"
>> > attitude.  Perhaps that works in corners of the language, infrequently used
>> > modules, but it makes less sense when touching the critical paths that have
>> > had slow and careful evolution over 26 years.
>> >
>> > * Besides the volume of patches, one other reason that reviews are hard
>> > to come by is that they apply new APIs that I don't fully understand yet.
>> > There are perhaps two people on the planet who could currently give
>> > thoughtful, correct, and critical evaluation of all those patches.  Everyone
>> > else is just watching them all fly by and hoping that something good is
>> > happening.
>>
>> Since one or maybe even two years, I noticed that many of my issues
>> were blocked by the lack of reviews. As you wrote, only few developer
>> have the knowledge and background to be able to provide a good review
>> (not only "tests pass, so LGTM") on my changes modifying the Python
>> core.
>>
>> I also wanted to discuss this topic, but I didn't really know what to
>> propose. Let's take this opportunity to explain how I contribute to
>> CPython, especially how I decide to wait for a review or not.
>>
>> For each patch that I write, I estimate the risk of regression. You
>> may know that any regression is something unexpected, so such
>> estimation is tricky. Here is my heuristic:
>>
>> (*) if the patch is trivial (short, non controversal), I push it
>> immediatly.
>>
>>
>> (*) If I'm less confident, I open an issue and attach the patch. I
>> wait at least one day before pushing.
>>
>> It's strange, but the process of opening an issue and attaching the
>> patch usually helps to review the code myself (find bugs, or more
>> generally enhance the patch). Maybe because it forces me to review the
>> change one more time?
>>
>> If the change is not part of a larger patch serie, so doesn't block me
>> to move further, I try to keep the issue open around one week.
>>
>> The truth is that too few of my patches get a review :-/ Maybe I
>> should wait longer, but then it becomes harder for me to handle many
>> patches.
>>
>> Maybe it's a tooling issues. Recently, I started to use local branches
>> in a Git repository. It helps a lot of work on parallel on large
>> changes. Before, I only worked in a single directory (default/, the
>> default Mercurial branch) and applied/reverted patches everytime. It's
>> painful, especially when I have to use multiple computers, download
>> again publshed patches, etc. Maybe it will run smoother once CPython
>> will move to Git and GitHub.
>>
>> By the way, it's painful to squash a long patch serie into a giant
>> patch, much harder to review, where changes don't make sense at all at
>> the first look. Again, a better reviewing tool supporting patch series
>> (GitHub) will help here too.
>>
>> Not supporting patch series in our reviewing tool also explains why I
>> prefer to push than having to wait for a review. Rebasing manually
>> long patch series stored as giant .patch files is complicated.
>>
>>
>> (*) If the change changes an API or changes a core component, I wait
>> for at least one review from a core reviewer. Sometimes, I even send
>> an email to python-dev. Again, sometimes I don't get any feedback on
>> the patch nor the email after two weeks :-/ At least, I tried :-)
>> Usually, I get feedback in less than one week, or no feedback at all.
>> I understand that nobody understands my change or nobody cares :-)
>>
>> I totally understand that most core developers have a little amount of
>> time available to contribute to Python. I'm trying to find a
>> compromise between the risk of introducing regressions and being stuck
>> in my work. This email might help me to adjust my workflow.
>>
>> By the way, I'm trying to always run the full test suite (./python -m
>> test -rW -j0) before pushing any change. If I suspect that I may have
>> introduced reference leaks, I also run "./python -m test -R 3:3 ..."
>> on the tests related to the modified code to check for
>> memory/reference leaks.
>>
>>
>> > * One other reason for the lack of review comments in the enthusiasm and
>> > fervor surrounding the patches.  I feel like there is a cost of questioning
>> > whether the patches should be done or how they are done, like I am burning
>> > little karma every time.  Sometimes it feels safest and most cordial to just
>> > say nothing and let you make hundreds of semi-reviewed changes to just about
>> > every critical part of the language.
>>
>> "semi-reviewed". Let me be more accurate: yeah, I do push a lot of
>> changes which were not reviewed by anyone (see above).
>>
>>
>> > * Historically, if there was creator or maintainer of the code who was
>> > still active, that person would always be consulted and have a final say on
>> > whether a change should be applied.  Now, we have code constantly being
>> > changed without consulting the original author (for example, the recent and
>> > catastrophic random initialization bug was due to application of a patch
>> > without consulting the author of _randommodule.c and the maintainer of
>> > random.py, or this change to sorted(), or the changes to decimal, etc).
>>
>> What do you mean by "author"? As you wrote, Python is now 26 years
>> old, so it had a very long history, and each file has a very long list
>> of "authors". I guess that you mean more a "maintainer".
>>
>> My problem is that I'm not aware of any explicit list of maintainers.
>> I didn't know that you were the maintainer of the random module before
>> you told me that at the Facebook sprint last september. I didn't
>> expect that the random module had a maintainer, I thought that any
>> core developer would be allowed to modify the code.
>>
>> Moreover, since I open an issue for most of my changes, it gives an
>> opportunity to maintainers to review changes. Maybe we need more
>> components in the bug tracker to notify maintainers of pending
>> changes?
>>
>>
>> You mentionned 3 different changes, let me reply.
>>
>>
>> (1) The random change: http://bugs.python.org/issue29085
>>
>> I introduced a regression in random.Random.seed(): a typo in the C
>> code has the consequence that the current time and process identifier
>> is used, instead of os.urandom(16), to initialize the Mersenne Twister
>> RNG.
>>
>> IMHO the regression is not "catastrophic". Only few developers
>> instanciate random.Random themself, random.Random must not be used for
>> security, etc. I let others decide if this bug was catastrophic or
>> not.
>>
>>
>> Since we are talking about the development process, let me see how the
>> change was made.
>>
>> Context: The PEP 524 has a long and painful history... Something like
>> more than 500 messages were sent on the bug tracker and python-dev,
>> and nobody was listening to each others, two security experts
>> "rage-quitted" Python because of this mess... I decided to try to fix
>> this issue in a constructive way, so I wrote a PEP. Nick wrote a
>> different PEP, since it was clear that it was possible to handle
>> security in two different incompatible ways. A mailing list was even
>> created just to discuss this bug! A mailing list just for a bug gives
>> an idea of the size of the mess :-)
>>
>> Well, about the change itself, it was done in
>> http://bugs.python.org/issue27776
>>
>> The patch was available for review during 19 days
>> (2016-08-18-2016-09-06) and was reviewed by Nick Coghlan. Since Nick
>> wrote a similar PEP, I trusted him to be able to review my change.
>> (Well, anyway I already trust all core developers, but I mean that I
>> was trusting him even more than usual :-))
>>
>> Since the change has a big impact on security, I had prefer to get a
>> review of more developers, especially our security experts... but as I
>> wrote, two security experts "rage- quitted". Again, this PEP has a
>> long and sad story :-/
>>
>> Note: you say that you are the maintainer of the random module, but I
>> don't recall having see you in any recent discussions and issues
>> related to os.urandom(), whereas a lot of enhancements and changes
>> were done last 2 years. I made many changes to support new OS
>> functions like getentropy() an getrandom().
>>
>>
>> Oooookay, let's see the second change, "this change to sorted()",
>> http://bugs.python.org/issue29327
>>
>> (2) I introduced a bug in sorted(), last August:
>> https://hg.python.org/cpython/rev/15eab21bf934/
>>
>> Calling sorted(iterable=[]) does crash. To be honest, I didn't imagine
>> that anyone would pass the iterable by keyword, but Serhiy is very
>> good to spot bugs in corner cases :-)
>>
>> IMHO the regression is subtle.
>>
>> When I optimized the code to use FASTCALL, I replaced
>> PyTuple_GetSlice(args, 1, argc) with &PyTuple_GET_ITEM(args, 1). I
>> checked that all tests passed, so it looks ok to me.
>>
>> I didn't imagine that anyone would call sorted(iterable=[]), so I
>> didn't notice that PyTuple_GetSlice() can create an empty tuple.
>>
>> The previous code was wrong since sorted() accepted iterable as a
>> keyword, whereas sort.list() doesn't.
>>
>> So well, I let you guess if a review would have spot this bug in the
>> large change.
>>
>>
>> (3) Recently, I ran sed to replace code patterns to use faster ways to
>> call functions:
>> https://hg.python.org/cpython/rev/54a89144ee1d
>>
>> "Replace PyObject_CallObject(callable, NULL) with
>> _PyObject_CallNoArg(callable)"
>>
>> I recalled that I modified the _decimal module and that Stefan Krah
>> complained, because he wants to have the same code base on Python 3.5,
>> 3.6 and 3.7. He also mentionned an external test suite which was
>> broken by recent _decimal changes (not sure if my specific change was
>> in cause or not), but I wasn't aware of it.
>>
>> To be honest, I didn't even notice that I modified _decimal when I ran
>> sed on all .c files. Since the change was straightforward and (IMHO)
>> made the code more readable, I didn't even wait for a review if I
>> recall correctly.
>>
>> Stefan and me handled this issue privately (he reverted my change),
>> I'm not sure that it's worth it to say more about this "issue" (or
>> even "non-issue").
>>
>> To be clear, I don't consider that my change introduced a regression.
>>
>>
>> > * In general, Guido has been opposed to sweeping changes across the code
>> > base for only tiny benefits.  Of late, that rule seems to have been lost.
>> >
>> > * The benefits of FASTCALL mainly apply to fine grained functions which
>> > only do a little work and tend to be called frequently in loops.  For
>> > functions such as sorted(), the calling overhead is dominated by the cost of
>> > actually doing the sort.  For sorted(), FASTCALL is truly irrelevant and
>> > likely wasn't worth the complexity, or the actual bug, or any of the time
>> > we've now put in it.  There was no actual problem being solved, just a
>> > desire to broadly apply new optimizations.
>>
>> Ok, first, you qualify my FASTCALL changes as code churn. So let me
>> show an example with sorted():
>> https://hg.python.org/cpython/rev/b34d2ef5c412
>>
>> Can you elaborate how such change increases the complexity?
>>
>>
>> Second, "no actual problem being solved"
>>
>> Since the goal of FASTCALL is to optimize Python, I guess that you
>> consider that the speedup doesn't justify the change. I gave numbers
>> in the issue #29327:
>>
>> Microbenchmark on sorted() on Python 3.7 compared to 3.5 (before
>> FASTCALL):
>> ---
>> haypo at smithers$ ./python -m perf timeit 'seq=list(range(10))'
>> 'sorted(seq)' --compare-to=../3.5/python -v
>> Median +- std dev: [3.5] 1.07 us +- 0.06 us -> [3.7] 958 ns +- 15 ns:
>> 1.12x faster (-11%)
>>
>> haypo at smithers$ ./python -m perf timeit 'seq=list(range(10)); k=lambda
>> x:x' 'sorted(seq, key=k)' --compare-to=../3.5/python -v
>> Median +- std dev: [3.5] 3.34 us +- 0.07 us -> [3.7] 2.66 us +- 0.05
>> us: 1.26x faster (-21%)
>> ---
>>
>> IMHO such speedup is significant even on a microbenchmark. Can you
>> elaborate what are your criteria to decide if an optimization is worth
>> it?
>>
>>
>>
>> > * Historically, we've relied on core developers showing restraint.  Not
>> > every idea that pops into their head is immediately turned into a patch
>> > accompanied by pressure to apply it.  Devs tended to restrict themselves to
>> > parts of the code they knew best through long and careful study rather
>> > sweeping through modules and altering other people's carefully crafted code.
>>
>> Should I understand that I should restrict myself to some files? Or
>> not touch some specific parts of Python, like... "your" code like
>> random, itertools and collections modules?
>>
>> I replied to the 3 issues you mentioned previously and explained how I
>> contribute to Python.
>>
>>
>> > * FWIW, I applaud your efforts to reduce call overhead -- that has long
>> > been a sore spot for the language.
>> >
>> > * Guido has long opposed optimizations that increase risk of bugs,
>> > introduce complexity, or that affect long-term maintainability.   In some
>> > places, it looks like FASTCALL is increasing the complexity (replacing
>> > something simple and well-understood with a wordier, more intricate API that
>> > I don't yet fully understand and will affect my ability to maintain the
>> > surrounding code).
>>
>> I'm sorry, I didn't spent much time on explaing the FASTCALL design
>> nor documenting my changes. It's partially deliberate to make
>> everything related to FASTCALL private. Since it's a huge project
>> modifying a lot of code, I wanted to wait until the APIs and the code
>> stop moving too fast to take time to explain my work and document it.
>>
>> If you have specific questions, please go ahead.
>>
>>
>> Shortest summary:
>>
>> * FASTCALL replaces (args: tuple, kwargs: optional dict) with (args: C
>> array, nargs: int, kwnames: tuple of keyword keys). It's a new calling
>> convention which allows to avoid a temporary tuple to pass positional
>> arguments and avoids temporary dictionary to pass keyworkd arguments.
>>
>> * To use FASTCALL, C functions should be converted to the new
>> METH_FASTCALL calling convention
>>
>> * PyObject_Call() can replaced with _PyObject_FastCallKeywords() or
>> _PyObject_FastCallDict() (when we still get kwargs as a dict) in such
>> conversion
>>
>> * Many existing C functions were optimized internally to use FASCALL,
>> so even if you don't modify your code, you will benefit of it
>> (speedup). Typical example: PyFunction_CallFunctionObjArgs().
>>
>>
>> The most massive change were purely internal and don't affect the most
>> famous C APIs at all. In some cases, to fully benefit of FASTCALL,
>> code should be modified. I'm trying to restrict such changes to Python
>> internals, especially the most used functions.
>>
>> I expected that the required changes were straightforward enough, it
>> looks like I was wrong, but I don't recall anyone, before you
>> recently, asking for an explanation.
>>
>>
>>
>> > * It was no long ago that you fought tooth-and-nail against a single
>> > line patch optimization I submitted.  The code was clearly correct and had a
>> > simple disassembly to prove its benefit.  Your opposition was based on "it
>> > increases the complexity of the code, introduces a maintenance cost, and
>> > increases the risk of bugs".  In the end, your opposition killed the patch.
>> > But now, the AC and FASTCALL patches don't seem to mind any of these
>> > considerations.
>>
>> Context: http://bugs.python.org/issue26201
>>
>> It seems like we need more _explicit_ rules to decide if an
>> optimization is worth it or not. For me, the de facto standard request
>> for an optimization is to prove it with a benchmark. I requested a
>> benchmark, but you refused to provide it.
>>
>> So I ran my own benchmark and saw that your change made the modified
>> code (PyList_Append()) 6% slower. I'm not sure that my bencmark was
>> correct, but it was a first step to take a decision.
>>
>>
>> To come back to FASTCALL, your point is that it doesn't provide any
>> speedup.
>>
>> In most FASTCALL issues that I opened, I provide a script to reproduce
>> my benchmark and the benchmark results. The speedup is usually betwen
>> 10% and 20% faster.
>>
>> Should I understand that 6% slower is ok, whereas 10-20% faster is not
>> good? Can you please elaborate?
>>
>>
>> > * AC is supposed to be a CPython-only concept.  But along the way APIs
>> > are being changed without discussion.  I don't mind that sorted() now
>> > exposes *iterable* as a keyword argument, but it was originally left out on
>> > purpose (Tim opined that code would look worse with iterable as a keyword
>> > argument).  That decision was reversed unilaterally without consulting the
>> > author and without a test.  Also as AC is being applied, the variable names
>> > are being changed.  I never really liked the "mp" that used in dicts and
>> > prefer the use of "self" better, but it is a gratuitous change that
>> > unilaterally reverses the decisions of the authors and makes the code not
>> > match any of the surrounding code that uses the prior conventions.
>>
>> Ah, at least I concur with you on one point :-) Changes to convert
>> functions to AC must not change the API (type of arguments: positional
>> only/keyword/..., default values, etc.) nor provide a worse docstring.
>>
>> There is an active on-going work to enhance AC to fix issues that you
>> reported, like the default value of positional-only parameters which
>> should not be rendered in the function signature (I created the issue
>> #29299 with a patch). Serhiy is also working on implementing the last
>> major missing feature of AC: support *args and **kwargs parameters
>> (issue #20291).
>>
>> FYI I wasn't involved in AC changes, I only started to look at AC
>> recently (1 or 2 months ago). Again, I agree that these changes should
>> be carefully reviewed, which is an hard task since required changes
>> are usually large and move a lot of code. We need more eyes to look at
>> these changes!
>>
>> For the specific case of sorted(), the name of first parameter is
>> already documented in the docstring and documentation in Python 2.7:
>> "iterable". So I guess that you mean that it is now possible to use it
>> as a keyword argument. Well, see the issue #29327 for the long story.
>> This issue is a regression, it was already fixed, and I didn't
>> introduce the API change.
>>
>>
>> Oh by the way, when I read your comment, I understand that I'm
>> responsible of all regressions. It's true that I introduced
>> regressions, that's where I said "shit happens" (or more politically
>> correct: "it's better to ask forgiveness than permission" ;-)). Since
>> I'm one of the most active contributor in CPython, I'm not surprised
>> of being the one who introduce many (most?) regressions :-) I'm trying
>> to review my changes multiple times, test corner cases, etc. But I'm
>> not perfect.
>>
>> Sadly, to show its full power, FASTCALL requires changes at many
>> levels of the code. It requires to change at lot of code, but I
>> understood that core developers approved the whole project. Maybe I
>> was wrong? At least, I asked for permissions multiple changes,
>> especially at the start.
>>
>>
>>
>> > * FWIW, the claim that the help is much better is specious.  AFAICT,
>> > there has never been the slightest problem with "sorted(iterable, key=None,
>> > reverse=False) --> new sorted list" which has been clear since the day it
>> > was released.   It is some of the new strings the are causing problems with
>> > users (my students frequently are tripped-up by the / notation for example;
>> > no one seems to be able to intuit what it means without it being explained
>> > first).
>>
>> Good news, it seems like you have a good experience in API design,
>> documentation, etc. Join the "Argument Clinic" project to help us to
>> enhance docstrings, function signatures and documentation ;-)
>>
>> See the good part of the AC on-going work: it's a nice opportunity to
>> also enhance documentation, not only provide a signature.
>>
>> By the way, to be honest, the main advantage of converting functions
>> to AC is to get a signature. The signature is visible in docstrings
>> which is nice, but it is also very useful to a wide range of tools
>> like (IDE, static checks, etc.).
>>
>> Conversion to FASTCALL is more a nice effect. At least, it is a good
>> motivation for me to convert mor and more code to AC :-)
>>
>> AC moves docstring closer to the list of parameters. IHMO it makes the
>> C code simpler to read and understand. It also removes the boring code
>> responsible to "parse" arguments, so it makes the code shorter. But
>> well, this is just my opinion.
>>
>>
>> > * FWIW, I'm trying to be constructive and contribute where I can, but
>> > frankly I can't keep up with the volume of churn.   Having seen bugs being
>> > introduced, it is not inappropriate to ask another dev to please be careful,
>> > especially when that dev has been prolific to an unprecedented degree and
>> > altering core parts of the language for function calls, to new opcodes, the
>> > memory allocators, etc.  Very few people on the planet are competent to
>> > review these changes, make reasonable assessments about whether the
>> > complexity and churn are worth it.  An fewer still have the time to keep up
>> > with the volume of changes.
>>
>>
>> Hum, I wasn't involved in bytecode changes.
>>
>> Well, I reviewed the very good work of Demur Rumed. I recall that you
>> worked on a similar area, trying to fetch bytecode by 16-bit instead
>> of 8-bit. Demur proposed a good design and I recall that the design
>> was approved.
>>
>> I helped a little bit on the implementation and I pushed the final
>> change, but all credits go to Demur and Serhiy Storshaka! By the way,
>> Serhiy made further efficient enhancements in the bytecode of
>> CALL_FUNCTION instructions.
>>
>>
>> About memory allocations, I guess that you are referring to my change
>> on PyMem_Malloc() allocator. I discussed the issue on python-dev and
>> waited for approval of my peers before pushing anything, since I know
>> well that it's a critical part of Python:
>> https://mail.python.org/pipermail/python-dev/2016-March/143467.html
>>
>> I provide all data requested by Marc Andre Lemburg (test the change
>> with common projects, Django, Pillow, numpy) and made further changes
>> (PYTHONMALLOC=debug tool) to help to handle this backward incompatible
>> change (GIL is now required to call PyMem_Malloc).
>>
>> Hopefully, it seems like nobody noticed this subtle change (GIL now
>> requied): I didn't see any bug report. By the way, I fixed a misused
>> PyMem_Mem() in numpy.
>>
>>
>> > * Please do continue your efforts to improve the language, but also
>> > please moderate the rate of change, mitigate the addition complexity, value
>> > stability over micro-optimizations, consult the authors and maintainers of
>> > code, take special care without code that hasn't been reviewed because that
>> > lacks a safety net, and remember that newer devs may be taking cues from you
>> > (do you want them making extensive changes to long existing stable code
>> > without consulting the authors and with weak LGTM reviews?)
>>
>> Ok, I will do it.
>>
>> Thank you for you feedback Raymond. I hope that my email helps you to
>> understand how I work and how I take my decisions.
>>
>> Victor
>> _______________________________________________
>> python-committers mailing list
>> python-committers at python.org
>> https://mail.python.org/mailman/listinfo/python-committers
>> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/