Does _private makes refactoring harder?

[Lucas_Malor]

@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.

2. 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

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

@storchaka

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).

@stoneleaf

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.