Deep Python Encapsulation
-
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 1000According 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.
@Sachin-Bhatt
Are you sure thatself.__maxpriceinsideComputeractually accesses the same variable as the one set viac.__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
Are you sure thatself.__maxpriceinsideComputeractually accesses the same variable as the one set viac.__maxprice = 1000? Because the behavior you report would be explicable if in fact that call from the outside world creates a different variable.....@JonB Yes, ik I made a bad choice by using it. Thanks for the clarification. My query got resolved.
-
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.
-
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.
@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__maxpriceclass 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!
-
-
@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__maxpriceclass 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!
@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
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
-
@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@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
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?@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
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
@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
-
@J-Hilk
OK, so since-Wshadowis the same as-Wshadow=globalthey count member->local shadow as "global", I thought that would be something different.I will bear
-Wshadowin mind for gcc! Anything for MSVC?
