«

[Erik Heneryd]
> Eli Stevens (WG.c) wrote:
> >I have a question about proper Python style when it comes to having a main
> >function in a module.

> http://www.artima.com/weblogs/viewpost.jsp?thread=4829

I asked myself the same question for a good while, and came up with the
following skeleton from nearly all my Python programs. At times, I
was removing lines below which appeared superfluous to me for smallish
scripts, but found out in the long run that, sooner or later for any
script which was surviving for some while, I have to add back the lines
I removed, while adding new features as needed in such scripts, so I now
stick to that skeleton. More comments follow below.

---------------------------------------------------------------------->
#!/usr/bin/env python
# -*- coding: Latin-1
# Copyright © 2004 Progiciels Bourbeau-Pinard inc.
# François Pinard <>, 2004.

"""\

"""

__metaclass__ = type

class Main:
def __init__(self):
pass

def main(self, *arguments):
import getopt
options, arguments = getopt.getopt(arguments, '')
for option, valeur in options:
pass

run = Main()
main = run.main

if __name__ == '__main__':
import sys
main(*sys.argv[1:])
----------------------------------------------------------------------<

If that file is imported instead of executed as a main program, the
`Main.main' method does not execute, but the `Main' object is still
instantiated and available within the imported module under the name
`run'. This can be used to call its methods, modify its options, etc.

The role of `__init__' is to setup the `run' object, and in particular,
to initialise default values for run options. The `main' method proper
goes after the `pass' at its end, which gets replaced, of course, by
option processing if any.

The strange `*' which appears in two place is so that `main' may
be called after the module being imported, with a variable number
of explicit arguments. This has proven to be the most natural and
convenient way to proceed: we think of the `main' method as accepting
a list of arguments, not a bundle them in a list or tuple. This is
useful, in particular, in an interactive Python session. The program
name is not a useful first argument in the general case, this is why it
is excluded in the last line of the above template, when the module is
run as a script.

Of course, the initial doc string is meant to be filled appropriately.

A word about the `__metaclass__' line. My intent is to forget all about
classic classes and go with the new type system as quickly as possible.
I do not want to derive each and every of my classes from `object',
and later edit all those `(object)' out when the classic classes will
effectively get deprecated. Much easier and cleaner to remove that
`__metaclass__' line then. Moreover, by using this `__metaclass__' line
in all my things, I do not risk obscure bugs because I forgot one of
these `object' derivation while I used more recent Python features.

Finally, to criticise myself, I'm not satisfied with the copyright line,
as it does not really state the copyright terms and conditions. I'm
used to include that copyright in all my things, or almost, but I should
either retract the line, or state conditions, for it to be meaningful.
Currently, people sometimes write to me to clarify conditions -- which
are GPL usually, yet my real intent in such things is to favour freedom
for both programming and programmers, much more than spousing FSF
politics which do not address both with equal attention!

--
François Pinard http://www.iro.umontreal.ca/~pinard

On 2004-04-21, François Pinard <> wrote:
>
> __metaclass__ = type
>
> class Main:
> def __init__(self):
> pass
>

> A word about the `__metaclass__' line. My intent is to forget all about
> classic classes and go with the new type system as quickly as possible.
> I do not want to derive each and every of my classes from `object',
> and later edit all those `(object)' out when the classic classes will
> effectively get deprecated. Much easier and cleaner to remove that
> `__metaclass__' line then. Moreover, by using this `__metaclass__' line
> in all my things, I do not risk obscure bugs because I forgot one of
> these `object' derivation while I used more recent Python features.
>


Very interesting.

Is there any reason to stick with old-style classes? Or would we all
be well-advised to use something like this?

I mostly just create classes the old way and never even think about
subclassing object.

[Lee Harr]
> On 2004-04-21, François Pinard <> wrote:

> > __metaclass__ = type

> Is there any reason to stick with old-style classes?

For your new programs, there is probably no good reason to worry about
old-style classes. For your old programs, it is likely that you will
not meet problems on the average by the mere action of switching to
types. However, there are areas of incompatibilities indeed, that one
may stumble upon, if one were pushing a bit deep in the internals.

> I mostly just create classes the old way and never even think about
> sub-classing object.

There are some new features, and corrections to previously debatable
features, which are not available in the old-style classes. If you do
very simple uses of classes, always, you might choose to ignore the
difference.

--
François Pinard http://www.iro.umontreal.ca/~pinard

François Pinard <> writes:

> A word about the `__metaclass__' line. My intent is to forget all about
> classic classes and go with the new type system as quickly as possible.
> I do not want to derive each and every of my classes from `object',
> and later edit all those `(object)' out when the classic classes will
> effectively get deprecated.

Why would you do that? Even if you don't inherit from object
explicitly (eg. what you do) object is still a base class.

I don't like using a __metaclass__ global because it's a non-local
effect.

Cheers,
mwh

--
I never disputed the Perl hacking skill of the Slashdot creators.
My objections are to the editors' taste, the site's ugly visual
design, and the Slashdot community's raging stupidity.
-- http://www.cs.washington.edu/homes/k...shdot.html#faq

Lee Harr <> writes:

> On 2004-04-21, François Pinard <> wrote:
> >
> > __metaclass__ = type
> >
> > class Main:
> > def __init__(self):
> > pass
> >
>
> > A word about the `__metaclass__' line. My intent is to forget all about
> > classic classes and go with the new type system as quickly as possible.
> > I do not want to derive each and every of my classes from `object',
> > and later edit all those `(object)' out when the classic classes will
> > effectively get deprecated. Much easier and cleaner to remove that
> > `__metaclass__' line then. Moreover, by using this `__metaclass__' line
> > in all my things, I do not risk obscure bugs because I forgot one of
> > these `object' derivation while I used more recent Python features.
> >
>
>
> Very interesting.
>
> Is there any reason to stick with old-style classes? Or would we all
> be well-advised to use something like this?

I'd say, just inherit from object all the time.

> I mostly just create classes the old way and never even think about
> subclassing object.

Tsk!

BTW, my slides from PythonUK on this kind of thing are online at

http://starship.python.net/crew/mwh/hacks/

Cheers,
mwh

--
Indeed, when I design my killer language, the identifiers "foo" and
"bar" will be reserved words, never used, and not even mentioned in
the reference manual. Any program using one will simply dump core
without comment. Multitudes will rejoice. -- Tim Peters, 29 Apr 1998

[Michael Hudson]
> François Pinard <> writes:

> > A word about the `__metaclass__' line. My intent is to forget all about
> > classic classes and go with the new type system as quickly as possible.
> > I do not want to derive each and every of my classes from `object',
> > and later edit all those `(object)' out when the classic classes will
> > effectively get deprecated.

> Why would you do that?

Your question is surprising, after you just quoted the answer. I guess
I miss the real meaning of your question.

> I don't like using a __metaclass__ global because it's a non-local
> effect.

That's exactly why it is useful. You don't like it to be useful?

--
François Pinard http://www.iro.umontreal.ca/~pinard

François Pinard <> writes:

> [Michael Hudson]
> > François Pinard <> writes:
>
> > > A word about the `__metaclass__' line. My intent is to forget all about
> > > classic classes and go with the new type system as quickly as possible.
> > > I do not want to derive each and every of my classes from `object',
> > > and later edit all those `(object)' out when the classic classes will
> > > effectively get deprecated.
>
> > Why would you do that?
>
> Your question is surprising, after you just quoted the answer. I guess
> I miss the real meaning of your question.

In case I confused you, I meant the "edit the '(object)' out" bit.

> > I don't like using a __metaclass__ global because it's a non-local
> > effect.
>
> That's exactly why it is useful. You don't like it to be useful?

I like my code to do things similar to what it looks like it's doing.

To me,

class MyClass:
...

says "classic class".

Cheers,
mwh

--
Two decades later, well-known hacker Henry Spencer described the
Perl scripting language as a "Swiss-Army chainsaw", intending to
convey his evaluation of the language as exceedingly powerful but
ugly and noisy and prone to belch noxious fumes. -- the jargon file

(Note: this is about having a line `__metaclass__ = type' near the
beginning of a Python program.)

[Michael Hudson]
> I like my code to do things similar to what it looks like it's doing.
> To me,
> class MyClass:
> ...
> says "classic class".

I understand your concern. But since I do not want classic classes
anymore in my code, I prefer to read all classes as new style, as
blindly as possible. If I ever wanted to specify a class as old-style
(but I never had the need so far), I would write:

from types import ClassType

class MyOldClass:
__metaclass__ = ClassType
...

Why would you want to specifically use classic classes in these days?

--
François Pinard http://www.iro.umontreal.ca/~pinard