Deep Python Encapsulation

Sachin Bhatt

class Computer:

    def __init__(self):
        self.__maxprice = 900
        self.minvalue = 200
   

c = Computer()
#print(c.__maxprice) # this will throw an exception
c.__maxprice = 1000 # hear am assigning the new value to my mangled variable
print(c.__maxprice) # this will return the value 1000

According to the encapsulation in python from here, __maxprice should not be accessible from outside, yet in the above example, I am able to edit and access the value.

JonB

@Sachin-Bhatt
Are you sure that self.__maxprice inside Computer actually accesses the same variable as the one set via c.__maxprice = 1000? Because the behavior you report would be explicable if in fact that call from the outside world creates a different variable.....

Sachin Bhatt

@JonB Yes, ik I made a bad choice by using it. Thanks for the clarification. My query got resolved.

TomZ

Thank you for asking, though. Very interesting behavior on the side of that language.

Compared to C++ or similar language which forbids you and tells you your mistake, I think a shadowing variable like this is likely to cause many hours of developer time to get wasted.

JonB

@TomZ
I do not disagree! I am not a Python expert, but I think what is/must be going on here is:

Python __something --- double underscore --- class variables are (apparently) "very private". More private that ones starting with a single underscore!
And I can only imagine that attempting to access them from the outside world --- c.__maxprice --- either throws a "not found" exception on read or on write actually creates a brand new __maxprice class variable, which "has the same name" as the private-private one but is not the same variable!?

Compared to C++ or similar language which forbids you and tells you your mistake, I think a shadowing variable like this is likely to cause many hours of developer time to get wasted.

As I have discovered, C++ does not error or warn you if you create a local variable in a class method whose name shadows a class member variable. It regards you as knowing what you are doing (C# would warn....). And we have spent many hours with questions on this forum which turn out to be totally unintended (or not understood) shadowing like this, such that I wish there were a C++ compiler option to warn about just this!

J.Hilk

@JonB said in Deep Python Encapsulation:

As I have discovered, C++ does not error or warn you if you create a local variable in a class method whose name shadows a class member variable

it does, if you enable -Wshadow

JonB

@J-Hilk
Interesting! But from https://stackoverflow.com/a/57079021 I don't see where it would warn about local variable shadowing member variable?? E.g. "Warn when a local variable shadows another local variable or parameter. ". I want to warn on shadowing a member variable (in a method), not a local or parameter one?

J.Hilk

@JonB from gcc.gnu.org

-Wshadow
Warn whenever a local variable or type declaration shadows another variable, parameter, type, class member (in C++), or instance variable (in Objective-C) or whenever a built-in function is shadowed. Note that in C++, the compiler warns if a local variable shadows an explicit typedef, but not if it shadows a struct/class/enum. If this warning is enabled, it includes also all instances of local shadowing. This means that -Wno-shadow=local and -Wno-shadow=compatible-local are ignored when -Wshadow is used. Same as -Wshadow=global.

so, it should

JonB

@J-Hilk
OK, so since -Wshadow is the same as -Wshadow=global they count member->local shadow as "global", I thought that would be something different.

I will bear -Wshadow in mind for gcc! Anything for MSVC?

J.Hilk

@JonB said in Deep Python Encapsulation:

Anything for MSVC?

build it first with gcc/clang ?

🤷‍♂️

TomZ

In QtCreator I have warnings from my linter (cppcheck) when I create local variables that shadow class-things (including method-names).