Update of /cvsroot/mailman/mailman
In directory sc8-pr-cvs1:/tmp/cvs-serv10211
Modified Files:
Tag: Release_2_1-maint
README-I18N.en README.POSTFIX UPGRADING configure configure.in
Added Files:
Tag: Release_2_1-maint
STYLEGUIDE.txt
Log Message:
Backporting from the HEAD -- top level files
--- NEW FILE: STYLEGUIDE.txt ---
Python coding style guide for GNU Mailman
Copyright (C) 2002-2003 Python Software Foundation, Barry A. Warsaw
This document contains a style guide for Python programming, as used
in GNU Mailman. In general, Guido van Rossum's style guide should be
taken as a basis, as embodied in PEP 8:
http://python.sourceforge.net/peps/pep-0008.html
however, my (Barry Warsaw's) personal preferences differ from Guido's
in a few places. "When in Rome..." should apply meaning, when coding
stuff for Python, Guido's style should rule, however when coding for
Mailman, I'd like to see my preferences used instead. For software
like the email package, which is both standalone and distributed in
Python's standard library, please adhere to the established style,
which means please use my style.
Remember rule #1, A Foolish Consistency is the Hobgoblin of Little
Minds. That said, here's a quick outline of where my preferences
depart from Guido's:
- Imports usually should be on separate lines. While it's sometimes
okay to say
from types import StringType, ListType
it's never okay to say
import os, sys
Put these on separate lines.
- Imports are always put at the top of the file, just after any module
comments and docstrings, and before module globals and constants.
Imports should be grouped, with the order being
1. standard library imports
2. related major package imports (i.e. all email package imports next)
3. application specific imports
Dotted imports should follow non-dotted imports. Non-dotted imports
should be grouped by increasing length, while dotted imports should
be grouped roughly alphabetically.
- In general, there should be at most one class per module, if the
module contains class definitions. If it's a module of functions,
that's fine, group them as common sense dictates. A
class-containing module can also contain some helper functions, but
it's best to keep these non-public (i.e. use a single leading
underscore).
Always give the class and the module the same name.
Note though that Zope3's module naming style has a lot of merit.
Here, package and module names are all lower cased. I'm
experimenting with this approach for Mailman3.
- When importing a class from a class-containing module, it's usually
okay to spell this
from MyClass import MyClass
from foo.bar.YourClass import YourClass
If this spelling causes name clashes, then spell them
import MyClass
import foo.bar.YourClass
and use "MyClass.MyClass"
- Right hanging comments are discouraged, in favor of preceding
comments. E.g.
foo = blarzigop(bar) # if you don't blarzigop it, it'll shlorp
should be written as
# if you don't blarzigop it, it'll shlorp
foo = blarzigop(bar)
- Major sections of code in a module should be separated by line feed
characters (e.g. ^L -- that's a single character control-L not two
characters). This helps with Emacs navigation.
Always put a ^L before module-level functions, before class
definitions, before big blocks of constants which follow imports,
and any place else that would be convenient to jump to. Always put
two blank lines before a ^L.
- Also put to blank lines between any module level function. Put only
one blank line between methods in a class. No blank lines between
the class definition and the first method in the class (although
class docstrings often go in this space).
- Try to minimize the vertical whitespace in a class. If you're
inclined to separate stanzas of code for readability, consider
putting a comment in describing what the next stanza's purpose is.
Don't put stupid or obvious comments in just to avoid vertical
whitespace though.
- Unless internal quote characters would mess things up, the general
rule is that single quotes should be used for short strings, double
quotes for triple-quoted multi-line strings and docstrings. E.g.
foo = 'a foo thing'
warn = "Don't mess things up"
notice = """Our three chief weapons are:
- surprise
- deception
- an almost fanatical devotion to the pope
"""
- Write docstrings for all public modules, functions, classes, and
methods. Docstrings are not necessary and usually discouraged for
non-public methods, but you should have a comment that describes
what the method does. This comment should appear after the "def"
line.
- PEP 257 describes good docstrings conventions. Note that most
importantly, the """ that ends a multiline docstring should be on a
line by itself, e.g.:
"""Return a foobang
Optional plotz says to frobnicate the bizbaz first.
"""
- For one liner docstrings, keep the closing """ on the same line --
except for module docstrings!
- <> is strongly preferred over !=
- fill-column for docstrings should be 78.
- Always use string methods instead of string module functions, unless
your code must work with Python 1.5.2 (but let's hope not).
- For sequences, (strings, lists, tuples), use the fact that empty
sequences are false, so "if not seq" or "if seq" is preferable to
"if len(seq)" or "if not len(seq)". Unless you must be compatible
with Pythons before 2.2.1, always use True and False instead of 1
and 0 for boolean values.
- Always decide whether a class's methods and instance variables
should be public or non-public. In general, never make data
variables public unless you're implementing essentially a record.
It's almost always preferable to give a functional interface to
your class instead (Python 2.2's descriptors and properties make
this much nicer).
Also decide whether your attributes should be private or not. The
difference between private and non-public is that the former will
never be useful for a derived class, while the latter might be.
Yes, you should design your classes with inheritance in mind!
Private attributes should have two leading underscores, no trailing
underscores.
Non-public attributes should have a single leading underscore, no
trailing underscores.
Public attributes should have no leading or trailing underscores
(unless they conflict with reserved words, in which case, a single
trailing underscore is preferable to a leading one, or a corrupted
spelling, e.g. class_ rather than klass).
Index: README-I18N.en
===================================================================
RCS file: /cvsroot/mailman/mailman/README-I18N.en,v
retrieving revision 2.12.2.3
retrieving revision 2.12.2.4
diff -u -d -r2.12.2.3 -r2.12.2.4
--- README-I18N.en 22 Apr 2003 03:34:49 -0000 2.12.2.3
+++ README-I18N.en 22 Sep 2003 02:54:26 -0000 2.12.2.4
@@ -173,113 +173,6 @@
No error messages should appear.
Next, copy your files on an installed mailman tree, and run
- bin/transcheck XX, where XX is your coutry code.
-
- No warning should appear (but maybe some warning is ok, if you really
- know what you're doing).
-
- Now, try to run your translation (add an "add_language" line to
- Mailman/Defaults.py) and check the many scattered pieces blend
- together well. Sometimes you'll need some adjustment.
-
- When you're satistied, pack up a tar.gz with the following structure:
-
- messages/XX/LC_MESSAGES/mailman.po
- messages/XX/LC_MESSAGES/mailman.mo
- templates/XX/admindbdetails.html
- templates/XX/admindbpreamble.html
- .
- .
- templates/XX/userpass.txt
- templates/XX/verify.txt
-
- (XX is your country code) and send it to Barry Warsaw.
-
- By that time, your translation could be somewhat obsolete, because
- templates and mailman.pot could have been evolved meanwhile.
-
- Don't panic.
-
- You'll need to check diffs to find what changed and how, so that
- you can easily update your files.
-
- Save everything everytime, you'll need it.
-
-
-MORE INSTRUCTIONS
-
- Here is the recipe that Simone Piunno used for the Italian
- translations:
-
- "You can start without much technical knowledge, but if you want
- to keep your translation up-to-date (while the development branch
- evolves into the next stable release) you'd better learn how to
- use cvs and diff.
-
- Here is my recipe.
-
- Basically, you'll start by copying templates/en/* to your sandbox dir
- and then translating each file. Keep in mind that %(foo)s is a
- variable reference (much like %s in C) and must be left untouched.
- Also, you must be able to recognize a markup tag (eg, <foo>) because
- they must be left untouched too, and you should know how to escape
- non-ASCII characters, e.g. "�" -> "è", but only in html files.
- Remember that if you need a literal % sign, it must be doubled: %%
-
- Next, you copy messages/mailman.pot, renaming it to serbian.po.
- You can open this file with kbabel (a tool included in KDE SDK) and
- translate each string (original on the higher half of the window, your
- translation on the bottom half).
-
- If you are a masochist, you can even use emacs PO mode ;)
- Keep attention to the same markers and escaping as above, with the added
- complexity that here it's harder to say when a string is html (e.g. used
- for web UI) or pure text (e.g used for email interface)
-
- Then you try to compile you .po file:
-
- msgfmt -v -o serbian.mo serbian.po
-
- No error messages should appear.
-
- Next, copy your files on an installed mailman tree, and run
- bin/transcheck XX, where XX is your coutry code.
-
- Here is the recipe that Simone Piunno used for the Italian
- translations:
-
- "You can start without much technical knowledge, but if you want
- to keep your translation up-to-date (while the development branch
- evolves into the next stable release) you'd better learn how to
- use cvs and diff.
-
- Here is my recipe.
-
- Basically, you'll start by copying templates/en/* to your sandbox dir
- and then translating each file. Keep in mind that %(foo)s is a
- variable reference (much like %s in C) and must be left untouched.
- Also, you must be able to recognize a markup tag (eg, <foo>) because
- they must be left untouched too, and you should know how to escape
- non-ASCII characters, e.g. "�" -> "è", but only in html files.
- Remember that if you need a literal % sign, it must be doubled: %%
-
- Next, you copy messages/mailman.pot, renaming it to serbian.po.
- You can open this file with kbabel (a tool included in KDE SDK) and
- translate each string (original on the higher half of the window, your
- translation on the bottom half).
-
- If you are a masochist, you can even use emacs PO mode ;)
- Keep attention to the same markers and escaping as above, with the added
- complexity that here it's harder to say when a string is html (e.g. used
- for web UI) or pure text (e.g used for email interface)
-
- Then you try to compile you .po file:
-
- msgfmt -v -o serbian.mo serbian.po
-
- No error messages should appear.
-
- Next, copy your files on an installed mailman tree, and run
bin/transcheck XX, where XX is your country code.
No warning should appear (but maybe some warning is ok, if you really
Index: README.POSTFIX
===================================================================
RCS file: /cvsroot/mailman/mailman/README.POSTFIX,v
retrieving revision 2.11.2.2
retrieving revision 2.11.2.3
diff -u -d -r2.11.2.2 -r2.11.2.3
--- README.POSTFIX 7 Apr 2003 22:51:13 -0000 2.11.2.2
+++ README.POSTFIX 22 Sep 2003 02:54:26 -0000 2.11.2.3
@@ -7,7 +7,8 @@
Mailman should work pretty much out of the box with a standard
Postfix installation. As of this writing I've tested it with
- Postfix 19991231 up to pl13, and with 200010228 up to pl08.
+ Postfix 19991231 up to pl13, 200010228 up to pl08, and up to
+ Postfix 2.0.15.
By default, Postfix treats -owner and -request addresses
specially. Since we want Postfix to deliver such messages to
@@ -53,9 +54,8 @@
the case, adjust the instructions according to your use of
configure's --prefix and --with-var-prefix options.
- - If you are using Postfix-style virtual domains and you want
- Mailman to honor your virtual domains, read the section below
- first!
+ - If you are using virtual domains and you want Mailman to honor
+ your virtual domains, read the section below first!
- Add this to the bottom of the $prefix/Mailman/mm_cfg.py file:
@@ -115,29 +115,40 @@
VIRTUAL DOMAINS
- Postfix supports two styles of virtual domains, called
- "Postfix-style" and "Sendmail-style". With the latter, all
- aliases are visible in all domains, and nothing special need be
- done with Mailman.
+ Postfix 2.0 supports "virtual alias domains", essentially what
+ used to be called Postfix-style virtual domains in earlier Postfix
+ versions. To make virtual alias domains work with Mailman, you
+ need to do some setup in both Postfix and Mailman. Mailman will
+ write all virtual alias mappings to a file called, by default,
+ /usr/local/mailman/data/virtual-mailman. It will also use postmap
+ to create the virtual-mailman.db file that Postfix will actually
+ use.
- With Postfix-style virtual domains, things are a little trickier,
- although Mailman should work well with it. First, you'll need to
- add a path to Postfix's virtual_maps variable:
+ First, you need to set up the Postfix virtual alias domains as
+ described in the Postfix documentation (see Postfix's virtual(5)
+ manpage). Note that it's your responsibility to include the
+ "virtual-alias.domain anything" line as described manpage; Mailman
+ will not include this line in virtual-mailman. I highly encourage
+ you to make sure your virtual alias domains are working properly
+ before integrating with Mailman.
- virtual_maps = <your normal virtual files>,
+ Next, add a path to Postfix's virtual_alias_maps variable,
+ pointing to the virtual-mailman file, e.g.:
+
+ virtual_alias_maps = <your normal virtual alias files>,
hash:/usr/local/mailman/data/virtual-mailman
- assuming you've installed Mailman in the default location. Note
- that you must follow Postfix's instructions for setting up the
- virtual domains; get your virtual domains working in Postfix
- first before integrating Mailman.
+ assuming you've installed Mailman in the default location. If
+ you're using an older version of Postfix which doesn't have the
+ virtual_alias_maps variable, use the virtual_maps variable
+ instead.
Next, in your mm_cfg.py file, you will want to set the variable
POSTFIX_STYLE_VIRTUAL_DOMAINS to the list of virtual domains that
- Mailman should update. This may not be all of the virtual domains
- that your Postfix installation supports! The values in this list
- will be matched against the host_name attribute of mailing lists
- objects, and must be an exact match.
+ Mailman should update. This may not be all of the virtual alias
+ domains that your Postfix installation supports! The values in
+ this list will be matched against the host_name attribute of
+ mailing lists objects, and must be an exact match.
Here's an example:
@@ -148,7 +159,8 @@
myhostname = mail.dom1.ain
mydomain = dom1.ain
mydestination = $myhostname, localhost.$mydomain
- virtual_maps = hash:/some/path/to/virtual-dom1,
+ virtual_alias_maps =
+ hash:/some/path/to/virtual-dom1,
hash:/some/path/to/virtual-dom2,
hash:/some/path/to/virtual-dom2
@@ -159,7 +171,7 @@
@dom1.ain @mail.dom1.ain
This tells Postfix to deliver anything addressed to dom1.ain to
- the same mailbox at mail.dom1.com, it's default destination.
+ the same mailbox at mail.dom1.com, its default destination.
In this case you would not include dom1.ain in
POSTFIX_STYLE_VIRTUAL_DOMAINS because otherwise Mailman will write
@@ -169,7 +181,7 @@
[EMAIL PROTECTED] mylist-request
# and so on...
- The more specific entries trump your more general entries and thus
+ The more specific entries trump your more general entries, thus
breaking the delivery of any dom1.ain mailing list.
However, you would include dom2.ain and dom3.ain in mm_cfg.py:
Index: UPGRADING
===================================================================
RCS file: /cvsroot/mailman/mailman/UPGRADING,v
retrieving revision 2.11
retrieving revision 2.11.2.1
diff -u -d -r2.11 -r2.11.2.1
--- UPGRADING 12 Dec 2002 03:47:44 -0000 2.11
+++ UPGRADING 22 Sep 2003 02:54:26 -0000 2.11.2.1
@@ -1,5 +1,5 @@
Mailman - The GNU Mailing List Management System
-Copyright (C) 1998,1999,2000,2001,2002 by the Free Software Foundation, Inc.
+Copyright (C) 1998-2003 by the Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
@@ -72,11 +72,11 @@
upgrade, those messages will not get delivered, and I'm not
exactly sure yet how to upgrade those pending messages.
- NOTE: When upgrading to Mailman 2.1beta1, you will need to
- regenerate your aliases files. There have been many changes to
- the alias names, the programs they map to, and the name of the
- wrapper script. See README.<yourMTA> for details of making
- Mailman work with your mail server.
+ NOTE: When upgrading to Mailman 2.1, you will need to regenerate
+ your aliases files. There have been many changes to the alias
+ names, the programs they map to, and the name of the wrapper
+ script. See README.<yourMTA> for details of making Mailman work
+ with your mail server.
To regenerate your aliases, use the bin/genaliases script.
Index: configure
===================================================================
RCS file: /cvsroot/mailman/mailman/configure,v
retrieving revision 2.38.2.2
retrieving revision 2.38.2.3
diff -u -d -r2.38.2.2 -r2.38.2.3
--- configure 22 Apr 2003 03:34:49 -0000 2.38.2.2
+++ configure 22 Sep 2003 02:54:26 -0000 2.38.2.3
@@ -1,51 +1,326 @@
#! /bin/sh
-
-# From configure.in Revision: 2.39.2.1
-
+# From configure.in Revision: 2.39.2.2 .
# Guess values for system-dependent variables and create Makefiles.
-# Generated automatically using autoconf version 2.13
-# Copyright (C) 1992, 93, 94, 95, 96 Free Software Foundation, Inc.
+# Generated by GNU Autoconf 2.57.
#
+# Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002
[...5830 lines suppressed...]
+# by configure, so config.status won't be able to write to it; its
+# output is simply discarded. So we exec the FD to /dev/null,
+# effectively closing config.log, so it can be properly (re)opened and
+# appended to by config.status. When coming back to configure, we
+# need to make the FD available again.
+if test "$no_create" != yes; then
+ ac_cs_success=:
+ ac_config_status_args=
+ test "$silent" = yes &&
+ ac_config_status_args="$ac_config_status_args --quiet"
+ exec 5>/dev/null
+ $SHELL $CONFIG_STATUS $ac_config_status_args || ac_cs_success=false
+ exec 5>>config.log
+ # Use ||, not &&, to avoid exiting from the if with $? = 1, which
+ # would make configure fail if this is the last instruction.
+ $ac_cs_success || { (exit 1); exit 1; }
+fi
# Make sure all the build scripts are executable.
Index: configure.in
===================================================================
RCS file: /cvsroot/mailman/mailman/configure.in,v
retrieving revision 2.39.2.2
retrieving revision 2.39.2.3
diff -u -d -r2.39.2.2 -r2.39.2.3
--- configure.in 22 Apr 2003 03:34:51 -0000 2.39.2.2
+++ configure.in 22 Sep 2003 02:54:26 -0000 2.39.2.3
@@ -551,6 +551,7 @@
bin/clone_member \
bin/config_list \
bin/convert.py \
+bin/discard \
bin/dumpdb \
bin/find_member \
bin/fix_url.py \
@@ -568,6 +569,7 @@
bin/qrunner \
bin/remove_members \
bin/rmlist \
+bin/show_qfiles \
bin/sync_members \
bin/transcheck \
bin/unshunt \
_______________________________________________
Mailman-checkins mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/mailman-checkins
