Ravi Teja wrote: > What I mean is <<utility>> is the formal notation for a class in which > global functions are aggregated. It's not a hack. > Python is not alone here. Most OO languages aside Java and Smalltalk > have functions outside classes and UML accomodates though not > encourages free functions.
It doesn't seem to sit well with the common Python idiom of having several free functions packaged in a module, sadly. > Python is dynamic but only once the program starts > executing :-). Even though Python classes "can" change, they do so only > at runtime ( wouldn't it be scary if they decided to change as code > when you are not looking :-) ). So dynamism of Python should not be as > much of an issue. But on a similar note, I was wondering about classes such as BaseHTTPServer where the function to be called is looked up by name, and may or may not exist, or the situation where multiple function calls with similar signatures can be redirected to one using some getattr trickery - these don't seem to play well with the static nature of UML. (Or editor auto-completion, or cross-referencing code in an IDE...) I tend to shy away from such constructs for these reasons. -- Ben Sizer -- http://mail.python.org/mailman/listinfo/python-list
