N.Davis wrote:
(snip)
> Functions existing in a module? Surely if "everything is an object" (OK
> thats Java-talk but supposedly Python will eventually follow this too)
> then there should be nothing in a module thats not part of a class.
Why ? The name of the paradigm is *object* oriented, not *class*
oriented !-)
Believe it or else, there are OO languages that don't even have a
concept of 'class' (self, Javascript, Io, ...). They are called
prototype-based languages (by opposition to class-based), and are
usually much more object-oriented than Java.
In Python, "everything is an object" means that even classes and
functions are objects. Try this:
def fun(): pass
print fun.__class__.__name__
in fact, 'def' is just synctatic sugar to create a new instance of class
'function'
Now try this:
class Function(object):
def __call__(self, arg):
print "%s called with arg %s" % (self, arg)
f = Function()
f(42)
So in fact, a function is just a special case of a callable object.
When we say that Python is 100% OO, we mean it !-)
> Even
> a static method is simply a class function that operates on the
> "collection of all instances" rather than a single instance.
Nope. In most Java code, static methods are functions in disguise. Write
a Java class with only static methods and static variables, and you have
a very classic procedural module...
> Related classes in the same file? Be careful.
Of what ? This is a common practice in most OO languages, you know...
> Doesn't anything "knowing"
> about anything else compromise encapsulation?
Nope. Any of your objects needs to know at least something about at
least another object, or how could they send messages to each other ?
BTW encapsulation is *not* data-hiding.
> Why would
> properly-designed classes have such a close relationship?
I don't think you understand what kind of 'close relationship' we're
talking about. It's not about "a class knowing each and every
implementation detail of another class", it's about a bunch of classes
designed to work together to achieve a given goal.
BTW, note that the stronger coupling in OO is probably implementation
inheritence, and it's overabused in most static-typed languages.
> Having back in the day worked on big real-time systems where being very
> strict about encapsulation was a god-send for fighting complexity, I
> feel unnerved by Perl and Python's laid-back OO culture
Please avoid comparing oranges and apples. Perl culture is about hacks
and unreadable code, when Python's culture is about simplicity and
readability. Just not the same culture.
> of "you can do
> it if you feel like it but don't have to".
Some languages have what we call a "discipline-and-bondage" culture.
Some others have a "we're all consenting adults here" culture. The
difference is that the first category of languages impose arbitrary
restrictions on the programmer, that usually lead to more verbose and
complex code, which usually leads to much opportunities for bugs.
> While you could do all manner
> of nasty hacks in C++ I worked with people who carefully avoided this.
> Maybe that was just luck....
Nope, just common sens I'd say. But also, C++ - just like C - is a
low-*level language that allows you to do what you want with resources
(and specially with memory), so the consequences of a programming error
can be much more desastrous.
Now "nasty hacks" are not part of the Python culture. Dynamicity and
simplicity are not nasty hacks, just a way to get rid of useless complexity.
If you have a problem with having many classes in one file, then you'll
have a hard time with some other Python's features, like eg relying on
conventions for access control[1] or duck-typing[2]
[1] 'aName' => public, '_aName' => protected, '__aName' => private
[2] "if it walks like a duck and quake like a duck, then it's close
enough to a duck for what we want to do with it...."
So my best advice here is: don't fight against the language, don't waste
your time trying to enforce Java idioms in Python (I did, so believe me
when I tell you it's a pure waste of time), just forget Java idioms and
learn Python as it is. You'll discover that Python is not a "scripting"
language, but one of the most powerful and enjoyable languages around.
(disclaimer : my sig is a deliberate counter-exemple of good Python
coding style)
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in '[EMAIL PROTECTED]'.split('@')])"
--
http://mail.python.org/mailman/listinfo/python-list
