# Core developer rules of thumb (incl. "What needs a PEP"?)

**URL:** <https://discuss.python.org/t/core-developer-rules-of-thumb-incl-what-needs-a-pep/14104>\
**Category:** Core Development\
**Created:** [March 7, 2022, 4:36pm UTC](https://discuss.python.org/t/core-developer-rules-of-thumb-incl-what-needs-a-pep/14104 "2022-03-07T16:36:28Z")\
**Posts on this page:** 1\
**Showing post:** 15

<div class="post-metadata">

**Author:** ![ncoghlan](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/ncoghlan/32/14266_2.png) [@ncoghlan](https://discuss.python.org/u/ncoghlan)\
**Post date:** [March 12, 2022, 3:10pm UTC](https://discuss.python.org/t/core-developer-rules-of-thumb-incl-what-needs-a-pep/14104/15 "2022-03-12T15:10:48Z")

</div>

> [@iritkatriel](#):
>
> Functional changes, over time, inevitably make the code harder to maintain. If we don’t deal with this continuously via incremental refactoring then we end up re-implementing whole components when they reach a state where nobody wants to touch them anymore. That is more likely to introduce bugs.

[Proposal: rename \_PyInterpreterFrame struct as \_Py\_framedata](https://discuss.python.org/t/proposal-rename-pyinterpreterframe-struct-as-py-framedata/14213) is another example of this kind of readability/maintainability proposal - minimising the size of the functional diffs when splitting an existing data structure in two has resulted in the situation where it can be hard to tell in some new diffs whether the code is using the old structure or the new one, and that’s a potential problem as the two have significantly different memory management expectations.

Now, we may decide in that case that further naming churn isn’t worth the hassle, but I don’t think it’s self-evident that keeping the status quo would be the right outcome. I _do_ think it’s reasonable to require a discussion on Discourse before making that kind of change, though. While the risk of generating an interminable bikeshed discussion is real, I don’t think that outweighs the potential benefit in others pointing out potential downsides to the change _before_ it is made, as well as in having a more in-depth rationale for the change available than can be readily incorporated into a commit message.

---

_[View the full topic](https://discuss.python.org/t/core-developer-rules-of-thumb-incl-what-needs-a-pep/14104)._
