I've just finished refactoring an awful C# class. I had been delaying the job for a while because I didn't want to do it.
Then, while staring at the code, I realised I could simply delete all the private methods and fields, leaving the public interface intact, and then re-implement the class in a much cleaner way. Great idea! I finished the job in a few hours, with a brand new class that doesn't give me a headache.
This is the first time I've actually seen a real value in having private and public scope for methods and variables. It makes refactoring much safer and easier! So... why don't we have them in Python?
Subscribe to:
Post Comments (Atom)
Popular Posts
-
These are the robots I've been working on for the last 12 months. They each weigh about 11 tonnes and have a 17 meter reach. The control... -
This hard-to-see screenshot is a Generic Node Graph Editing framework I'm building. I'm hoping it can be used for any kind of node... -
So, you've created a car prefab using WheelCollider components, and now you can apply a motorTorque to make the whole thing move along. ... -
After my last post, I decided to benchmark the scaling properties of Stackless, Kamaelia, Fibra using the same hackysack algorithm. Left axi... -
It is about 8 degrees C this morning. So cold, especially when last week we had high twenties. To help solve the problem, a friend suggeste...
-
MiddleMan: A Pub/Sub and Request/Response server in Go. This is my first Go project. It is a rewrite of an existing Python server, based o...
-
Why would I ask that question? Python 3 has been available for some time now, yet uptake is slow. There aren't a whole lot of packages i...
-
I'm now using bzr instead of svn. I'm pushing my repositories to: http://exactlysimilar.org/bzr/ I'm also auto publishing docume...
-
I've just read a newspaper article (courtesy of Kranzky ) from WA Business News documenting the malfeasance, gross negligence and misc...
-
I've just uploaded Fibra 2 to the cheeseshop. Fibra 2 includes the promised non-blocking plugin, which allows a generator based task to...
17 comments:
We do.
It's just that if you *need* to, you can access the private classes too. If you do that with your own library, then you probably need to refactor it. If you do it with somebody elses, you have to count on it breaking when he refactors the code.
The lack of an actual "private" keyword doesn't stop you from separating your code into a public API and internal implementation.
Just use the standard Python convention that attributes / methods starting with an underscore are private.
In addition to the under and dunder, you can use things like properties to refactor a seemingly public variable to act like a method.
I agree that the model is helpful.
I know it's helpful. So is static typing, it's extremely helpful when refactoring legacy code. But that's not what python is about which simplicity and minimalism.
If you want to be able to refactor python code easily you need to make sure you have good unit tests.
Please see the tutorial at http://docs.python.org/tutorial/classes.html#tut-private for more information about this.
>>> class A:
... def __private(self):
... return 2
... def public(self):
... return self.__private()
...
>>> a = A()
>>> a.__private()
Traceback (most recent call last):
File "", line 1, in
AttributeError: A instance has no attribute '__private'
>>> a.public()
2
Right, I had forgotten about the underscore prefix system. I guess it fell from memory due to lack of use, because it is so ugly!
Then you should have forgotten all of your C# because it's so ugly.
Actually, it's so much more readable and explicite than a keyword in the declaration.
I must agree with Simon, underscore prefix is ugly. I can't understand why there isn't "real" private scope, it feels so fundamental when thinking about encapsulation.
Though I don't have much experience with procedural languages.
if you have private and public then you should add protected and internal and there are still situations when all the 4 options are not good enough. It just adds a lot of complexity in order to get more control. Learn give up control you control freaks!
First: Python is not only procedural...
Second: Python has a philosophie, and it defined the language. Thats the main reason to avoid the use of keywords like private, static, etc.
Good points. I'm thinking this completely from the Java point of view so I missed this Python philosophy.
__slots__ ?
But until today, nobody convinced me why make attributes and methods really private
This isn't about keywords on implementations, this is about interfaces, right? Most Python software doesn't need explicit public interfaces. And those that do use zope.interface. I don't mean to be so blunt, but after years of using one of the following two strategies, it seems a non-problem; either: (1) duck-type and use data-normalization decorators around your public methods (e.g. guarantee your REST API can give your method that needs strings a unicode value without issue; move the EAFB and normalization into a decorator for more elegant, readable methods); (2) use zope.interface and zope.component. You can use both.
s/EAFB/EAFP
You can separate interface and implementation using closures. To me this seems much less natural in Python compared to JavaScript where it's the norm. I would like a better syntax for this.
def make_class():
global X
def private_method(self): pass
class X(object):
def public_method(self):
private_method(self)
Post a Comment