# Does \_private makes refactoring harder?

**URL:** <https://discuss.python.org/t/does-private-makes-refactoring-harder/104774>\
**Category:** Python Help\
**Created:** [November 7, 2025, 7:01pm UTC](https://discuss.python.org/t/does-private-makes-refactoring-harder/104774 "2025-11-07T19:01:56Z")\
**Posts on this page:** 1\
**Showing post:** 18

<div class="post-metadata">

**Author:** ![Lucas\_Malor](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/lucas_malor/32/24845_2.png) [@Lucas\_Malor](https://discuss.python.org/u/Lucas_Malor)\
**Post date:** [November 14, 2025, 10:48pm UTC](https://discuss.python.org/t/does-private-makes-refactoring-harder/104774/18 "2025-11-14T22:48:13Z")

</div>

> [@MegaIng](#):
>
> then nail down semantics for the class case.[…] We can’t read your mind.

##########################################################################  
But you can read my posts `;-)` I quote myself:  
##########################################################################

> [@Lucas\_Malor](#):
>
> > [@MegaIng](#):
> >
> > you have no defined what your proposed `local` does _inside_ a class
> 
> I was thinking about two options:
> 
> 1. `local` will make the member private, and stop. so `local self.x = None` will be in practice identical to `local self._x = None` with no @property, and `local def f(self)` will be identical to `def _f(self)`
> 
> pros: dead simple
> 
> cons: you can’t define a getter, a setter or a deleter without using a different name. Probably you can do it with different keywords – but I don’t like it – or with annotations – that Python doesn’t have. Anyway, annotations or other keywords are outside my proposal.
> 
> 1. `local` will act as an alias. `local self.x = None` doesn’t create a “real” field named `x`, but a field named `_x`. The same for methods. If you want a “completely” private field, you can write `local self._x = None`. It will mapped to a field named `__x`. In theory you can also add yet another keyword, but I think it’s too much; so, outside my proposal again.
> 
> pros: this way you can add getter, setter and deleter with the same name of the alias.
> 
> cons: it will create a “magical” `self._x`. Not explicit and potentially confusing for people that will introspect the object. Furthermore, the creation of another field named `_x` should be disallowed, and the same for methods.

##########################################################################  
Now answering to sinoroc:  
##########################################################################

> [@sinoroc](#):
>
> A big portion of refactoring activities is moving and renaming things

##########################################################################  
Yeah, I completely agree. It’s also funny. It’s like tidy up your house after a crazy party.  
##########################################################################

> [@sinoroc](#):
>
> where one would wrap `_x` with a `property` to make it public instead of renaming `_x` to `x`

##########################################################################  
Not saying that. I’m saying that you can name your private members `local x` or `local fun()` instead of `_x` and `_fun()`. If you want to make them public, you have just to remove `local`.  
##########################################################################

> [@sinoroc](#):
>
> Tools have been able to do this kind of refactoring for decades.

Yeah, it was already said, and my reply was: if so, also debugging a private member and modify it has powerful tools that exists from a lot of time.

I would like also that `local` will make the variable “really” private. Terry said there was already discussed – and I don’t find it suprising… But I found only this:

[https://discuss.python.org/search?q=private%20%23ideas%20in%3Atitle%20order%3Alatest](https://discuss.python.org/search?q=private%20%23ideas%20in%3Atitle%20order%3Alatest)

I quote some of the posts I find they have some good counterpoints:

> [@Is name mangling still still the best way to best, the only way and the future way for private instance variables?](https://discuss.python.org/t/is-name-mangling-still-still-the-best-way-to-best-the-only-way-and-the-future-way-for-private-instance-variables/51272/9):
>
> Perhaps because how inconvenient they are if you want to break abstractions (and you need to do this all the time for debugging, testing, and “temporary” fixes).

> [@Private, protected modifier and \_\_ notation](https://discuss.python.org/t/private-protected-modifier-and-notation/22356/10):
>
> people can extend functionality, or more easily work around bugs, because they have access to those private/internal data and functions.

This is true. The fact that `_x` is not special at all and you can access it easily as `x` is good if you want a fast debug and test. And it’s true you can workaround bugs more easily. I remember I’ve done it for a public py library. I had to read a private member to patch my app (app is so cool to say instead of program now… maybe because is Unix like. Only three letters).

But it’s really easy to read and modify also a “real” private member. That’s a piece of cake.

---

_[View the full topic](https://discuss.python.org/t/does-private-makes-refactoring-harder/104774)._