What are modules really for?

[Tito]

Re: What are modules really for?

> [1] 'aName' => public, '_aName' => protected, '__aName' => private

I didn't know this one, as I am quite new to Python. Is it really
general use?

Regards,
Tito

[bruno modulix]

Re: What are modules really for?

Tito wrote:[color=blue][color=green]
>> [1] 'aName' => public, '_aName' => protected, '__aName' => private[/color]
>
>
> I didn't know this one, as I am quite new to Python. Is it really
> general use?[/color]

Yes, it's the convention.

Well, to be more exact, this is:

name => interface (intended for public use)
_name => implementation (not intented for public use)
__name => mangled (should not be hidden or overriden) [1]
__name__ => magic (has special meaning for the Python interpreter) [2]

BTW, from module import * tends to only import 'public' symbols, so you
can use _name to prevent _name being imported by accident.

[1] The purpose here is not to enforce privacy, but to protect the
symbolf from being accidentaly overriden or hidden.
given:
class Foo(object):
def __init__(self, name):
self.__name = name
f = Foo('foo')

You'll have to use :
f._Foo__name

to access foo.__name from outside the class (this hold for derived
classes too).


[2] __name__ attributes (variables and functions) usually have special
behaviours attached to them. For exemple,
- obj.__init__(se lf, ...) is called on object initialisation
- seq.__len__() is called by len(seq),
- obj.__str__() is called by str(obj)
- obj.__add__ is the '+' operator called by obj1 + obj2 ->
obj1.__add__(se lf, obj2),
- obj.__getattr__ (self, name) is called when you lookup an inexistant
attribute of obj, etc...

You'll find all this (and much more) in the doc.

HTH
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[Guest]

Re: What are modules really for?

On Wed, 10 Aug 2005 09:36:13 +0100
N.Davis wrote:
[color=blue]
> As for multiple inheritance, yes I've always been aware of it being
> available in C++, but I learned C++ at a company which banned multiple
> inheritance in their coding standards, with comments about "The GOTO of
> the 1990s".[/color]

Looks like something religious. It seems they was completely ignorant about
what the multiple inheritance is and what is it for.

--
jk

[Mike Meyer]

Re: What are modules really for?

Peter Hansen <peter@engcorp. com> writes:
[color=blue]
> Dan wrote:[color=green]
>> You might think of modules in Python as like packages in Java. However,
>> putting classes in the same module doesn't give them any additional
>> powers to interact with each other. (At least, not that I know of.)[/color]
>
> Use of "global" to rebind shared module-scope names...[/color]

You can rebind module-scope names from outside the module. It's an
ugly practice, and I wouldn't recommend it, but it *is* possible.

But you're on the right track. If two consenting classes want to share
_named module variables, it's best that they be in the same module.

<mike
--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

[Neil Benn]

Re: What are modules really for?

Tito wrote:
[color=blue]
> <snip>
>[color=green][color=darkred]
>>>
>>>[/color]
>>If I want to change one class and replace the file on the install then I
>>need to put a whole bunch of classes on - increasing the change of
>>making a mistake.
>>
>>[/color]
>
>Sorry, I don't understand the previous sentence. What is meant by
>"replace on the install"? And by "to put a whole bunch of classes on"?
>
>
>
>
><snip>
>[/color]
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?
[color=blue]
>
>Well, I wasn't talking exactly about making use of dangerous features of
> languages, but more about the way of using imperative object-oriented
>languages in a non-object-oriented way.
>
>[/color]
well, in languages like C#, Java and eiffel - you shouldn't really be
doing that anyways. that is why they are poor choices for hobbies,
hacks and quickie.
[color=blue]
>Regards,
>Tito
>
>[/color]
P.S. why is Glenn McGrath walking about??

Cheers,

Neil

--

Neil Benn
Senior Automation Engineer
Cenix BioScience
BioInnovations Zentrum
Tatzberg 47
D-01307
Dresden
Germany

Tel : +49 (0)351 4173 154
e-mail : benn@cenix-bioscience.com
Cenix Website : http://www.cenix-bioscience.com

[bruno modulix]

Re: What are modules really for?

Neil Benn wrote:
(snip)[color=blue][color=green]
>>[/color]
> 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,[/color]

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

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.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[Magnus Lycka]

Re: What are modules really for?

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

int too? ;)

Actaully, I think Python and Java are fairly much on equal footing
here, with Java possibly being slightly behind rather than ahead.
[color=blue]
> 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.[/color]

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.
[color=blue]
> 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?[/color]

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...

[Brian Quinlan]

Re: What are modules really for?

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

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.
[color=blue]
> 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.[/color]

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

[bruno modulix]

Re: What are modules really for?

Magnus Lycka wrote:[color=blue]
> N.Davis wrote:
>[color=green]
>> Functions existing in a module? Surely if "everything is an object"
>> (OK thats Java-talk but supposedly Python will eventually follow this
>> too)[/color]
>
>
> int too? ;)[/color]

Yes, int too.
[color=blue][color=green][color=darkred]
>>> i = 42
>>> i.__class__[/color][/color][/color]
<type 'int'>[color=blue][color=green][color=darkred]
>>> i.__class__.__n ame__[/color][/color][/color]
'int'[color=blue][color=green][color=darkred]
>>> dir(i)[/color][/color][/color]
['__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__'][color=blue][color=green][color=darkred]
>>>[/color][/color][/color]


(snip)[color=blue]
> 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.[/color]

+1 QOTW

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom. gro'.split('@')])"

[Dennis Lee Bieber]

Re: What are modules really for?

On Thu, 11 Aug 2005 11:12:26 +0200, Neil Benn
<benn@cenix-bioscience.com> declaimed the following in comp.lang.pytho n:
[color=blue]
> 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?
>[/color]
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.
--[color=blue]
> =============== =============== =============== =============== == <
> wlfraed@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
> wulfraed@dm.net | Bestiaria Support Staff <
> =============== =============== =============== =============== == <
> Home Page: <http://www.dm.net/~wulfraed/> <
> Overflow Page: <http://wlfraed.home.ne tcom.com/> <[/color]

[Terry Reedy]

Re: What are modules really for?


"Brian Quinlan" <brian@sweetapp .com> wrote in message
news:42FB55BC.7 0608@sweetapp.c om...[color=blue]
> 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.[/color]

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__:[color=blue][color=green][color=darkred]
>>> type(int)[/color][/color][/color]
<type 'type'>[color=blue][color=green][color=darkred]
>>> int.__class__[/color][/color][/color]
<type 'type'>[color=blue][color=green][color=darkred]
>>> class c(object): pass[/color][/color][/color]
....[color=blue][color=green][color=darkred]
>>> c1 = c()
>>> type(c1)[/color][/color][/color]
<class '__main__.c'>[color=blue][color=green][color=darkred]
>>> c1.__class__[/color][/color][/color]
<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

[Tito]

Re: What are modules really for?

bruno modulix wrote:[color=blue]
> Magnus Lycka wrote:
>[color=green]
>>N.Davis wrote:
>>
>>[color=darkred]
>>>Functions existing in a module? Surely if "everything is an object"
>>>(OK thats Java-talk but supposedly Python will eventually follow this
>>>too)[/color]
>>
>>
>>int too? ;)[/color]
>
>
> Yes, int too.[/color]

I think he is talking about *Java* int.

Regards,
Tito

[Magnus Lycka]

Re: What are modules really for?

bruno modulix wrote:[color=blue]
> Magnus Lycka wrote:
>[color=green]
>>N.Davis wrote:
>>
>>[color=darkred]
>>>Functions existing in a module? Surely if "everything is an object"
>>>(OK thats Java-talk but supposedly Python will eventually follow this
>>>too)[/color]
>>
>>
>>int too? ;)[/color]
>
>
> Yes, int too.[/color]

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.

[Magnus Lycka]

Re: What are modules really for?

Terry Reedy wrote:[color=blue]
> However, everything is an instance of a class or type.[/color]

Except whitespace, comments, operators and statements!
(Did I miss anything?)

You can obviously argue whether a "variable" (or name if
you like) is an object, or just refers to an object, but
then we're getting philosophical I guess. C.f.

http://www.comviz.com.ulaval.ca/module1/Images/MagrittePipe.jpg

or http://www.fredosaurus.com/notes-cpp...tr/60song.html

[Mike Meyer]

Re: What are modules really for?

Magnus Lycka <lycka@carmen.s e> writes:[color=blue]
> Terry Reedy wrote:[color=green]
>> However, everything is an instance of a class or type.[/color]
> Except whitespace, comments, operators and statements!
> (Did I miss anything?)[/color]

What makes you think operators qualify as exceptions?
[color=blue][color=green][color=darkred]
>>> type(operator.a dd)[/color][/color][/color]
<type 'builtin_functi on_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

--
Mike Meyer <mwm@mired.or g> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.