What are modules really for?

B

bruno modulix

Neil Benn wrote:
(snip)
Suppose you have a logistics tracking system available on every install
in your company - there are 55 installs throughout the company. You
wish to push through a patch because of a problem. If you have one
class per file you can push that class through onto the client install.
However, if you have 15 different classes in one file - you will need to
drop all 15 classes through,

I don't see much difference, this is just one file to replace anyway...
thereby increasing the likelihood of
accidently pushing a bug onto the install.

Why ? You fixed a bug in one place in the file, ok ? So why would this
impact whatever else lives in that file ? And you did test your fix
before deploying, did you ?

I just don't get your point.
 
M

Magnus Lycka

N.Davis said:
Functions existing in a module? Surely if "everything is an object" (OK
thats Java-talk but supposedly Python will eventually follow this too)

int too? ;)

Actaully, I think Python and Java are fairly much on equal footing
here, with Java possibly being slightly behind rather than ahead.
then there should be nothing in a module thats not part of a class. Even
a static method is simply a class function that operates on the
"collection of all instances" rather than a single instance.

Object != class instance.

In Python, almost everything is an object. Files, classes, instances,
ints, modules, functions etc can be passes around, assigned to new
names, referenced in containers, printed etc etc. This is very helpful.
Forcing people to write a lot of bloat code around their functions
isn't really that helpful...

I can appreciate a language like Smalltalk, designed from ground up with
a pure OO approach--but it seems to me that Java's design was basically
to make a C++ derivate with bars and safety belts in a lot of places to
stop programmers from shooting themselves in the foot.
Related classes in the same file? Be careful. Doesn't anything "knowing"
about anything else compromise encapsulation? Why would
properly-designed classes have such a close relationship?

In your code, nothing ever knows anything about anything else? :)

I'm sure you have written code where a class knows of some other
class, for instance through inheritance or composition. It does
actually even happen that it's reasonable to let two classes be
mutually aware of each other, even if it's not as common as one
way relationships. It's often better to have a third class control
the relationship between the two, but that's my design decision,
not Guido van Rossum's or James Gosling's.

There is a fundamental difference in the philosophies behind the
design of Java and Python. It seems to me that Java is designed
to make is difficult for programmers to write bad code, while
Python is designed to make it easy to write good code. This makes
a big difference.

Another aspect to consider is that Python classes are typically
shorter than Java classes, since Python isn't as noisy as Java.

Perhaps you should have a look at HTMLGen for instance. It's a
library for generating HTML code. (Pretty old.) IIRC it has a lot
of classes that are just one line long. These classes represent
simple tags, and all behaviour is defined in some base class, so
the only thing that differs between i.e. the I class and the B
class is that str(I('Hello')) should be rendered as <I>Hello</I>
and str(B('Hello')) should be rendered as <B>Hello</B>. I don't
know what the name of their base class is, but assuming 'X', they
are just implemented as 'class I(X):pass' and class B(X):pass'.
It would have been a bit silly if Python had forced them out in
different files...
 
B

Brian Quinlan

N.Davis said:
Functions existing in a module? Surely if "everything is an object"
> (OK thats Java-talk but supposedly Python will eventually follow this
> too)

There is a difference between everything being an object and everything
being an instance of a class. In Python, every runtime entity is an
object but not everything is a class instance. In Java, there are
runtime-accessable entities that are neither objects nor class instances.
then there should be nothing in a module thats not part of a class. Even
a static method is simply a class function that operates on the
"collection of all instances" rather than a single instance.

Really? What instances do the static methods in the Java Math class
operate on? Not Math instances, of course. So what is the rational for
them being packaged in the Math class?

Cheers,
Brian
 
B

bruno modulix

Magnus said:

Yes, int too.
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
'__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
'__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
'__hex__', '__init__', '__int__', '__invert__', '__long__',
'__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__',
'__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__',
'__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
'__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__',
'__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__',
'__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
(snip)
It seems to me that Java is designed
to make is difficult for programmers to write bad code, while
Python is designed to make it easy to write good code.

+1 QOTW
 
D

Dennis Lee Bieber

Suppose you have a logistics tracking system available on every install
in your company - there are 55 installs throughout the company. You
wish to push through a patch because of a problem. If you have one
class per file you can push that class through onto the client install.
However, if you have 15 different classes in one file - you will need to
drop all 15 classes through, thereby increasing the likelihood of
accidently pushing a bug onto the install. If you want to do live
updating (don;t think that this is a feature of Python so it's acadmenic
here) then what do you do, reload all 15 classes - just the one you've
changed?
Is your development environment so uncontrolled that you expect
the programmers are unable to edit one part (a class) in a file without
corrupting the other parts?

Or is your "push" mechanism so unreliable as to corrupt
individual files during the transfer depending upon their length?

That's what it sounds like you are saying.
--
 
T

Terry Reedy

Brian Quinlan said:
There is a difference between everything being an object and everything
being an instance of a class. In Python, every runtime entity is an
object but not everything is a class instance.

However, everything is an instance of a class or type. And once old-style
classes are dropped, all classes will be user-defined types and types will
be built-in classes. And it seems that for instances of such unified
type-classes, type(x) == x.__class__:<class '__main__.c'>
# don't know if user metaclasses can change this or not

So the distinction, if kept, will be pretty thin.

Terry J. Reedy
 
M

Magnus Lycka

bruno said:
Yes, int too.

I was talking about everything being an object in Java...

Java has an Integer class which is OO and an int type
which is usable from a performance point of view. At
least that distinction existed when I was looking at
Java.
 
M

Mike Meyer

Magnus Lycka said:
Except whitespace, comments, operators and statements!
(Did I miss anything?)

What makes you think operators qualify as exceptions?
<type 'builtin_function_or_method'>

If you're talking about the character used to represent that operator
- well, I don't think there's any way to derive the underlying object
from that character.

In fact, that's true for everything else you list. Maybe the properly
refined version of Terry's statement should be:

Everything you can manipulate is an instance of a class or a
type.

<mike
 
T

Terry Reedy

[snip] Maybe the properly
refined version of Terry's statement should be:

Everything you can manipulate is an instance of a class or a
type.

Yes and no.

First, the context of the statement was a previous claim that some things
are class instances and some not. So my point in that context was a) that
adding 'or type' changes 'some' to 'every' and that new classes mostly
eliminate the difference between class and type, making the addition
eminently sensible. So while I thought of a qualifier like that, I left it
out as irrelevant and a distractions.

Second, any qualifier I can think of seems to have the danger of confusing
as well as enlightening. One might not realize, for instance, that
functions are something you can manipulate and might therefore mistakenly
think that the qualifier excludes functions. I also thought of putting it
as 'everything in Python's dataspace ...', but that has the same problem.

Perhaps 'every runtime entity...'. would work. That seems to excludes
source code (and things within source code like comments and whitespace and
operator symbols), unless the code or pieces thereof *are* turned into (or
wrapped as) string instances. Names might seem like an exception, but
again, they are only accessible at runtime as string instances. Or maybe a
more direct statement 'except for source code, everything...' would be
better.

So I have so far not settled on a 'best' context-free statement of the
design principle.

Terry J. Reedy
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,262
Messages
2,571,311
Members
47,986
Latest member
ColbyG935

Latest Threads

Top