Menu
▾
▴
py-howto-checkins — Checkins to the Python HOWTOs
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(11) |
Sep
(10) |
Oct
(11) |
Nov
(8) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(12) |
Feb
(7) |
Mar
(21) |
Apr
(5) |
May
(4) |
Jun
(1) |
Jul
(33) |
Aug
(5) |
Sep
(13) |
Oct
(16) |
Nov
(2) |
Dec
(6) |
| 2002 |
Jan
|
Feb
|
Mar
(6) |
Apr
(4) |
May
(1) |
Jun
|
Jul
(4) |
Aug
|
Sep
(1) |
Oct
|
Nov
(6) |
Dec
(1) |
| 2003 |
Jan
(1) |
Feb
(2) |
Mar
|
Apr
(6) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
|
From: A.M. K. <aku...@us...> - 2001-01-23 02:48:11
|
Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv17593
Modified Files:
python-21.tex
Log Message:
Add introductory note about this article's draft status
Grammatical and typographic fixes from David Goodger
Expanded notes about PEP 229
Removed user-visible XXXes; they're in comments now
Index: python-21.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-21.tex,v
retrieving revision 1.4
retrieving revision 1.5
diff -C2 -r1.4 -r1.5
*** python-21.tex 2001/01/22 19:51:13 1.4
--- python-21.tex 2001/01/23 02:48:26 1.5
***************
*** 12,15 ****
--- 12,20 ----
\section{Introduction}
+ {\large This document is a draft, and is subject to change until
+ Python 2.1 is released. Please send any comments, bug reports, or questions,
+ no matter how minor, to \email{am...@bi...}.
+ }
+
It's that time again... time for a new Python release, version 2.1.
One recent goal of the Python development team has been to accelerate
***************
*** 45,49 ****
SPARK parsing framework, docstrings hold parts of the BNF grammar to
be parsed. This overloading is unfortunate, since docstrings are
! really intended to hold a function's documentation, and means you
can't properly document functions intended for private use in Zope.
--- 50,55 ----
SPARK parsing framework, docstrings hold parts of the BNF grammar to
be parsed. This overloading is unfortunate, since docstrings are
! really intended to hold a function's documentation, and it
! means you
can't properly document functions intended for private use in Zope.
***************
*** 148,152 ****
number of obsolete modules and features along the way. It's difficult
to know when a feature is safe to remove, since there's no way of
! knowing how much code uses it -- perhaps no programs depend on the
feature, or perhaps many do. To enable removing old features in a
more structured way, a warning framework was added. When the Python
--- 154,158 ----
number of obsolete modules and features along the way. It's difficult
to know when a feature is safe to remove, since there's no way of
! knowing how much code uses it --- perhaps no programs depend on the
feature, or perhaps many do. To enable removing old features in a
more structured way, a warning framework was added. When the Python
***************
*** 224,229 ****
installing extensions. In Python 2.1, the Distutils are used to
compile much of the standard library of extension modules,
! autodetecting which ones are supported on the current machine.
! It's hoped that this will make Python installations easier and more featureful.
\begin{seealso}
--- 230,253 ----
installing extensions. In Python 2.1, the Distutils are used to
compile much of the standard library of extension modules,
! autodetecting which ones are supported on the current machine. It's
! hoped that this will make Python installations easier and more
! featureful.
!
! Instead of having to edit the \file{Modules/Setup} file in order to
! enable modules, a \file{setup.py} script in the top directory of the
! Python source distribution is run at build time, and attempts to
! discover which modules can be enabled by examining the modules and
! header files on the system. In 2.1alpha1, there's very little you can
! do to change \file{setup.py}'s behaviour, or to discover why a given
! module isn't compiled. If you run into problems in 2.1alpha1, please
! report them, and be prepared to dive into \file{setup.py} in order to
! fix autodetection of a given library on your system. In the alpha2
! release I plan to add ways to have more control over what the script
! does (probably command-line arguments to \file{configure} or to
! \file{setup.py}).
!
! If it turns out to be impossible to make autodetection work reliably,
! it's possible that this change may become an optional build method
! instead of the default, or it may even be backed out completely.
\begin{seealso}
***************
*** 320,325 ****
returns an opaque sequence object that only supports being iterated
over, reading a line on every iteration but not reading the entire
! file into memory as the existing \method{readline()} method. You'd
! use it like this:
\begin{verbatim}
--- 344,349 ----
returns an opaque sequence object that only supports being iterated
over, reading a line on every iteration but not reading the entire
! file into memory as the existing \method{readlines()} method does.
! You'd use it like this:
\begin{verbatim}
***************
*** 347,351 ****
\item Modules can now control which names are imported when \code{from
! \var{module} import *} is used, by defining a \code{__all__} attribute
containing a list of names that will be imported. One common
complaint is that if the module imports other modules such as
--- 371,375 ----
\item Modules can now control which names are imported when \code{from
! \var{module} import *} is used, by defining an \code{__all__} attribute
containing a list of names that will be imported. One common
complaint is that if the module imports other modules such as
***************
*** 403,414 ****
% ======================================================================
! \section{XXX Nested Scopes ?}
- xxx
% ======================================================================
! \section{XXX Weak References ?}
- xxx
% ======================================================================
--- 427,457 ----
% ======================================================================
! \section{Nested Scopes}
!
! % XXX
! The PEP for this new feature hasn't been completed yet, and the
! requisite changes haven't been checked into CVS yet.
!
! \begin{seealso}
!
! \seepep{227}{Statically Nested Scopes}{Written and implemented by Jeremy Hylton.}
!
! \end{seealso}
% ======================================================================
! \section{Weak References}
!
! % XXX
! The PEP for this new feature hasn't been completed yet, and the
! requisite changes haven't been checked into CVS yet.
!
!
! \begin{seealso}
!
! \seepep{205}{Statically Nested Scopes}{Written and implemented by Jeremy Hylton.}
!
! \end{seealso}
% ======================================================================
***************
*** 416,422 ****
The author would like to thank the following people for offering
! suggestions on various drafts of this article: Michael Hudson,
! Marc-Andr\'e Lemburg,
! Neil Schemenauer, Thomas Wouters.
\end{document}
--- 459,464 ----
The author would like to thank the following people for offering
! suggestions on various drafts of this article: David Goodger, Michael
! Hudson, Marc-Andr\'e Lemburg, Neil Schemenauer, Thomas Wouters.
\end{document}
|
|
From: A.M. K. <aku...@us...> - 2001-01-22 19:50:59
|
Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv3013
Modified Files:
python-21.tex
Log Message:
Added dictionary.popitem() and the improved XML modules.
Reorder the smaller items, roughly in decreasing order of visibility to
the Python coder
Finished an incomplete sentence.
Moved the unwritten sections down to the bottom.
Bumped version number and added acknowledgements
Index: python-21.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-21.tex,v
retrieving revision 1.3
retrieving revision 1.4
diff -C2 -r1.3 -r1.4
*** python-21.tex 2001/01/22 17:52:19 1.3
--- python-21.tex 2001/01/22 19:51:13 1.4
***************
*** 4,8 ****
\title{What's New in Python 2.1}
! \release{0.01}
\author{A.M. Kuchling}
\authoraddress{\email{am...@bi...}}
--- 4,8 ----
\title{What's New in Python 2.1}
! \release{0.03}
\author{A.M. Kuchling}
\authoraddress{\email{am...@bi...}}
***************
*** 143,151 ****
% ======================================================================
- \section{XXX Nested Scopes ?}
-
- xxx
-
- % ======================================================================
\section{PEP 230: Warning Framework}
--- 143,146 ----
***************
*** 336,339 ****
--- 331,341 ----
For a fuller discussion of the line I/O changes, see the python-dev
summary for January 1-15, 2001.
+
+ \item A new method, \method{popitem()}, was added to dictionaries to enable
+ destructively iterating through the contents of a dictionary; this can be faster for large dictionaries because .
+ \code{D.popitem()} removes a random \code{(\var{key}, \var{value})} pair
+ from the dictionary and returns it as a 2-tuple. This was implemented
+ mostly by Tim Peters and Guido van Rossum, after a suggestion and
+ preliminary patch by Moshe Zadka.
\item \module{curses.panel}, a wrapper for the panel library, part of
***************
*** 358,372 ****
A stricter version of this patch was first suggested and implemented
! by Ben Wolfson, but after some python-dev discussion, this weaker final version
! \item The \module{ftplib} module now defaults to retrieving files in passive mode,
! because passive mode is more likely to work from behind a firewall.
! This request came from the Debian bug tracking system, since other
! Debian packages use \module{ftplib} to retrieve files and then don't
! work from behind a firewall. It's deemed unlikely that this will
! cause problems for anyone, because Netscape defaults to passive mode
! and few people complain, but if passive mode is unsuitable for your
! application or network setup, call
! \method{set_pasv(0)} on FTP objects to disable passive mode.
\item Various functions in the \module{time} module, such as
--- 360,372 ----
A stricter version of this patch was first suggested and implemented
! by Ben Wolfson, but after some python-dev discussion, a weaker
! final version was checked in.
! \item The PyXML package has gone through a few releases since Python
! 2.0, and Python 2.1 includes an updated version of the \module{xml}
! package. Some of the noteworthy changes include support for Expat
! 1.2, the ability for Expat parsers to handle files in any encoding
! supported by Python, and various bugfixes for SAX, DOM, and the
! \module{minidom} module.
\item Various functions in the \module{time} module, such as
***************
*** 383,386 ****
--- 383,398 ----
This change was proposed and implemented by Thomas Wouters.
+ \item The \module{ftplib} module now defaults to retrieving files in passive mode,
+ because passive mode is more likely to work from behind a firewall.
+ This request came from the Debian bug tracking system, since other
+ Debian packages use \module{ftplib} to retrieve files and then don't
+ work from behind a firewall. It's deemed unlikely that this will
+ cause problems for anyone, because Netscape defaults to passive mode
+ and few people complain, but if passive mode is unsuitable for your
+ application or network setup, call
+ \method{set_pasv(0)} on FTP objects to disable passive mode.
+
+ \item The size of the Unicode character database was compressed by another 55K thanks to Fredrik Lundh.
+
\end{itemize}
***************
*** 391,399 ****
% ======================================================================
\section{Acknowledgements}
The author would like to thank the following people for offering
! suggestions on various drafts of this article: Neil Schemenauer,
! Thomas Wouters.
\end{document}
--- 403,422 ----
% ======================================================================
+ \section{XXX Nested Scopes ?}
+
+ xxx
+
+ % ======================================================================
+ \section{XXX Weak References ?}
+
+ xxx
+
+ % ======================================================================
\section{Acknowledgements}
The author would like to thank the following people for offering
! suggestions on various drafts of this article: Michael Hudson,
! Marc-Andr\'e Lemburg,
! Neil Schemenauer, Thomas Wouters.
\end{document}
|
|
From: A.M. K. <aku...@us...> - 2001-01-22 17:52:05
|
Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv21556
Modified Files:
python-21.tex
Log Message:
Add reference to PEP 232.
Use correct flag name Py_TPFLAGS_CHECKTYPES
Mention that numeric methods can return Py_NotImplemented (NAS)
Mention optional arguments in time modules (TW)
Various minor rewrites and additional attributions
Index: python-21.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-21.tex,v
retrieving revision 1.2
retrieving revision 1.3
diff -C2 -r1.2 -r1.3
*** python-21.tex 2001/01/22 16:15:44 1.2
--- python-21.tex 2001/01/22 17:52:19 1.3
***************
*** 67,70 ****
--- 67,76 ----
object.
+ \begin{seealso}
+
+ \seepep{232}{Function Attributes}{Written and implemented by Barry Warsaw.}
+
+ \end{seealso}
+
% ======================================================================
\section{PEP 207: Rich Comparisons}
***************
*** 268,272 ****
Extension types can now set the type flag
! \code{Py_TPFLAGS_NEWSTYLENUMBER} in their \code{PyTypeObject}
structure to indicate that they support the new coercion model. In
such extension types, the numeric slot functions can no longer assume
--- 274,278 ----
Extension types can now set the type flag
! \code{Py_TPFLAGS_CHECKTYPES} in their \code{PyTypeObject}
structure to indicate that they support the new coercion model. In
such extension types, the numeric slot functions can no longer assume
***************
*** 278,282 ****
of the other type will then be tried, and perhaps they can handle the
operation; if the other type also returns \code{Py_NotImplemented},
! then a \exception{TypeError} will be raised.
\begin{seealso}
--- 284,292 ----
of the other type will then be tried, and perhaps they can handle the
operation; if the other type also returns \code{Py_NotImplemented},
! then a \exception{TypeError} will be raised. Numeric methods written
! in Python can also return \code{Py_NotImplemented}, causing the
! interpreter to act as if the method did not exist (perhaps raising a
! \exception{TypeError}, perhaps trying another object's numeric
! methods).
\begin{seealso}
***************
*** 307,311 ****
depending on how slow the C library's \function{getc()} was, but is
around 66\%, and potentially much faster on some particular operating
! systems.
A new module and method for file objects was also added, contributed
--- 317,322 ----
depending on how slow the C library's \function{getc()} was, but is
around 66\%, and potentially much faster on some particular operating
! systems. Tim Peters did much of the benchmarking and coding for this
! change, motivated by a discussion in comp.lang.python.
A new module and method for file objects was also added, contributed
***************
*** 313,318 ****
the existing \function{xrange()} built-in. \function{xreadlines()}
returns an opaque sequence object that only supports being iterated
! over, reading a line on every iteration but not reading the entire file into memory as
! the existing \method{readline()} method. You'd use it like this:
\begin{verbatim}
--- 324,330 ----
the existing \function{xrange()} built-in. \function{xreadlines()}
returns an opaque sequence object that only supports being iterated
! over, reading a line on every iteration but not reading the entire
! file into memory as the existing \method{readline()} method. You'd
! use it like this:
\begin{verbatim}
***************
*** 322,326 ****
\end{verbatim}
! For a fuller discussion of the line I/O changes, see the python-dev summary for January 1-15, 2001.
\item \module{curses.panel}, a wrapper for the panel library, part of
--- 334,339 ----
\end{verbatim}
! For a fuller discussion of the line I/O changes, see the python-dev
! summary for January 1-15, 2001.
\item \module{curses.panel}, a wrapper for the panel library, part of
***************
*** 357,360 ****
--- 370,386 ----
\method{set_pasv(0)} on FTP objects to disable passive mode.
+ \item Various functions in the \module{time} module, such as
+ \function{asctime()} and \function{localtime()},
+ require a floating point argument containing the time in seconds since
+ the epoch. The most common use of these functions is to work with the
+ current time, so the floating point argument has been made optional;
+ when a value isn't provided, the current time will be used. For
+ example, log file entries usually need a string containing the current
+ time; in Python 2.1, \code{time.asctime()} can be used, instead of the
+ lengthier \code{time.asctime(time.localtime(time.time()))} that was
+ previously required.
+
+ This change was proposed and implemented by Thomas Wouters.
+
\end{itemize}
***************
*** 368,372 ****
The author would like to thank the following people for offering
! suggestions on various drafts of this article: no one yet!
\end{document}
--- 394,399 ----
The author would like to thank the following people for offering
! suggestions on various drafts of this article: Neil Schemenauer,
! Thomas Wouters.
\end{document}
|
|
From: A.M. K. <aku...@us...> - 2001-01-22 16:15:31
|
Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv8547
Modified Files:
python-21.tex
Log Message:
Fill out various transcripts and XXX bits, thanks to the WMATA.
The only missing section is the Nested Scopes section, which has to wait
to see if a patch is actually committed. (Plus any other notable changes
that get made or backed out between now and 2.1final, of course...)
Index: python-21.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/python-21.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -r1.1 -r1.2
*** python-21.tex 2001/01/22 04:02:09 1.1
--- python-21.tex 2001/01/22 16:15:44 1.2
***************
*** 37,42 ****
\section{PEP 232: Function Attributes}
! In Python 2.1, functions can have arbitrary attributes assigned to
! them. We noticed that people were often using docstrings to hold
information about functions and methods, because the \code{__doc__}
attribute was the only way of attaching any information to a function.
--- 37,42 ----
\section{PEP 232: Function Attributes}
! In Python 2.1, functions can now have arbitrary
! information attached to them. People were often using docstrings to hold
information about functions and methods, because the \code{__doc__}
attribute was the only way of attaching any information to a function.
***************
*** 48,57 ****
can't properly document functions intended for private use in Zope.
! XXX example here
% ======================================================================
\section{PEP 207: Rich Comparisons}
! xxx
% ======================================================================
--- 48,138 ----
can't properly document functions intended for private use in Zope.
! Attributes can now be set and retrieved on functions, using the
! regular Python syntax:
+ \begin{verbatim}
+ def f(): pass
+
+ f.publish = 1
+ f.secure = 1
+ f.grammar = "A ::= B (C D)*"
+ \end{verbatim}
+
+ The dictionary containing attributes can be accessed as
+ \member{__dict__}. Unlike the \member{__dict__} attribute of
+ class instances, in functions you can actually assign a new dictionary
+ to \member{__dict__}, though the new value is restricted to a
+ regular Python dictionary; you can't be tricky and set it to a
+ \class{UserDict} instance, a DBM file, or any other random mapping
+ object.
+
% ======================================================================
\section{PEP 207: Rich Comparisons}
! In earlier versions, Python's support for implementing comparisons on
! user-defined classes and extension types was quite simple. Classes
! could implement a \method{__cmp__} method that was given two instances
! of a class, and could only return 0 if they were equal or +1 or -1 if
! they weren't; the method couldn't raise an exception or return
! anything other than a Boolean value. Users of Numeric Python often
! found this model too weak and restrictive, because in the
! number-crunching programs that numeric Python is used for, it would be
! more useful to be able to perform elementwise comparisons of two
! matrices, returning a matrix containing the results of a given
! comparison for each element. If the two matrices are of different
! sizes, then the compare has to be able to raise an exception to signal
! the error.
!
! In Python 2.1, rich comparisons were added in order to support this need.
! Python classes can now individually overload each of the \code{<},
! \code{<=}, \code{>}, \code{>=}, \code{==}, and \code{!=} operations.
! The new magic method names are:
!
! \begin{tableii}{c|l}{code}{Operation}{Method name}
! \lineii{<}{\method{__lt__}}
! \lineii{<=}{\method{__le__}}
! \lineii{>}{\method{__gt__}}
! \lineii{>=}{\method{__ge__}}
! \lineii{==}{\method{__eq__}}
! \lineii{!=}{\method{__ne__}}
! \end{tableii}
!
! (The magic methods are named after the corresponding Fortran operators
! \code{.LT.}. \code{.LE.}, \&c. Numeric programmers are almost
! certainly quite familar with these names and will find them easy to
! remember.)
!
! Each of these magic methods is of the form \code{\var{method}(self,
! other)}, where \code{self} will be the object on the left-hand side of
! the operator, while \code{other} will be the object on the right-hand
! side. For example, the expression \code{A < B} will cause
! \code{A.__lt__(B)} to be called.
!
! Each of these magic methods can return anything at all: a Boolean, a
! matrix, a list, or any other Python object. Alternatively they can
! raise an exception if the comparison is impossible, inconsistent, or
! otherwise meaningless.
!
! The built-in \function{cmp(A,B)} function can use the rich comparison
! machinery, and now accepts an optional argument specifying which
! comparison operation to use; this is given as one of the strings
! \code{"<"}, \code{"<="}, \code{">"}, \code{">="}, \code{"=="}, or
! \code{"!="}. If called without the optional third argument,
! \function{cmp()} will only return -1, 0, or +1 as in previous versions
! of Python; otherwise it will call the appropriate method and can
! return any Python object.
!
! There are also corresponding changes of interest to C programmers;
! there's a new slot \code{tp_richcmp} in type objects and an API for
! performing a given rich comparison. I won't cover the C API here, but
! will refer you to PEP 207, or the documentation for Python's C API,
! for the full list of related functions.
!
! \begin{seealso}
!
! \seepep{207}{Rich Comparisions}{Written by Guido van Rossum, heavily
! based on earlier work by David Ascher, and implemented by Guido van Rossum.}
!
! \end{seealso}
% ======================================================================
***************
*** 85,89 ****
\begin{verbatim}
>>> import regex
! xxx
\end{verbatim}
--- 166,171 ----
\begin{verbatim}
>>> import regex
! __main__:1: DeprecationWarning: the regex module is deprecated; please use the re module
! >>>
\end{verbatim}
***************
*** 101,117 ****
to suppress a warning. For example, you may have a program that uses
the \module{regex} module and not want to spare the time to convert it
! to use the \module{re} module right now. The warning can be suppressed by calling
\begin{verbatim}
! XXX is this correct?
! warnings.filterwarnings(module = 'regex')
\end{verbatim}
Functions were also added to Python's C API for issuing warnings;
! refer to the PEP or to Python's API documentation for the details.
! \seepep{5}{Guidelines for Language Evolution}{Written by Paul Prescod.}
! \seepep{230}{Warning Framework}{Written and implemented by GvR.}
% ======================================================================
--- 183,212 ----
to suppress a warning. For example, you may have a program that uses
the \module{regex} module and not want to spare the time to convert it
! to use the \module{re} module right now. The warning can be
! suppressed by calling
\begin{verbatim}
! import warnings
! warnings.filterwarnings(action = 'ignore',
! message='.*regex module is deprecated',
! category=DeprecationWarning,
! module = '__main__')
\end{verbatim}
+ This adds a filter that will apply only to warnings of the class
+ \class{DeprecationWarning} triggered in the \module{__main__} module, and applies a regular expression to only match the message about the \module{regex} module being deprecated, and will cause such warnings to be ignored. Warnings can also be printed only once, printed every time the offending code is executed, or turned into exceptions that will cause the program to stop (unless the exceptions are caught in the usual way, of course).
+
Functions were also added to Python's C API for issuing warnings;
! refer to PEP 230 or to Python's API documentation for the details.
! \begin{seealso}
! \seepep{5}{Guidelines for Language Evolution}{Written by Paul Prescod,
! to specify procedures to be followed when removing old features from
! Python. The policy described in this PEP hasn't been officially
! adopted, but the eventual policy probably won't be too different from
! Prescod's proposal.}
! \seepep{230}{Warning Framework}{Written and implemented by Guido van Rossum.}
! \end{seealso}
% ======================================================================
***************
*** 131,135 ****
It's hoped that this will make Python installations easier and more featureful.
! \seepep{229}{xxx}{Written and implemented by A.M. Kuchling.}
% ======================================================================
--- 226,232 ----
It's hoped that this will make Python installations easier and more featureful.
! \begin{seealso}
! \seepep{229}{Using Distutils to Build Python}{Written and implemented by A.M. Kuchling.}
! \end{seealso}
% ======================================================================
***************
*** 143,151 ****
\begin{verbatim}
! xxx sample transcript
\end{verbatim}
\seepep{217}{Display Hook for Interactive Use}{Written and implemented by Moshe Zadka.}
% ======================================================================
\section{PEP 208: New Coercion Model}
--- 240,262 ----
\begin{verbatim}
! >>> # Create a recursive data structure
! ... L = [1,2,3]
! >>> L.append(L)
! >>> L # Show Python's default output
! [1, 2, 3, [...]]
! >>> # Use pprint.pprint() as the display function
! ... import sys, pprint
! >>> sys.displayhook = pprint.pprint
! >>> L
! [1, 2, 3, <Recursion on list with id=135143996>]
! >>>
\end{verbatim}
+ \begin{seealso}
+
\seepep{217}{Display Hook for Interactive Use}{Written and implemented by Moshe Zadka.}
+ \end{seealso}
+
% ======================================================================
\section{PEP 208: New Coercion Model}
***************
*** 169,172 ****
--- 280,285 ----
then a \exception{TypeError} will be raised.
+ \begin{seealso}
+
\seepep{208}{Reworking the Coercion Model}{Written and implemented by
Neil Schemenauer, heavily based upon earlier work by Marc-Andr\'e
***************
*** 174,177 ****
--- 287,291 ----
operations will now be processed at the C level.}
+ \end{seealso}
% ======================================================================
***************
*** 216,220 ****
panel library figures out where panels overlap and which sections are
visible.
- XXX who contributed this?
\item Modules can now control which names are imported when \code{from
--- 330,333 ----
***************
*** 231,240 ****
\end{verbatim}
\item The \module{ftplib} module now defaults to retrieving files in passive mode,
because passive mode is more likely to work from behind a firewall.
! If passive mode is unsuitable for your application or network setup, call
! \method{set_pasv(0)} on FTP objects to disable passive mode.
!
! XXX check bug 126851 for arguments.
\end{itemize}
--- 344,359 ----
\end{verbatim}
+ A stricter version of this patch was first suggested and implemented
+ by Ben Wolfson, but after some python-dev discussion, this weaker final version
+
\item The \module{ftplib} module now defaults to retrieving files in passive mode,
because passive mode is more likely to work from behind a firewall.
! This request came from the Debian bug tracking system, since other
! Debian packages use \module{ftplib} to retrieve files and then don't
! work from behind a firewall. It's deemed unlikely that this will
! cause problems for anyone, because Netscape defaults to passive mode
! and few people complain, but if passive mode is unsuitable for your
! application or network setup, call
! \method{set_pasv(0)} on FTP objects to disable passive mode.
\end{itemize}
|
|
From: A.M. K. <aku...@us...> - 2001-01-22 04:01:57
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv1019 Added Files: python-21.tex Log Message: Beginning of a "What's New in Python 2.1" article ***** Error reading new file[Errno 2] No such file or directory: 'python-21.tex' |
|
From: Fred L. D. <fd...@us...> - 2001-01-16 15:49:07
|
Update of /cvsroot/py-howto/pyhowto In directory usw-pr-cvs1:/tmp/cvs-serv3711 Modified Files: curses.tex Log Message: Fix minor typo: rerminals --> terminals Index: curses.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/curses.tex,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -r1.11 -r1.12 *** curses.tex 2001/01/16 13:01:04 1.11 --- curses.tex 2001/01/16 15:49:00 1.12 *************** *** 32,36 **** In a world of X displays, one might ask ``why bother''? It's true ! that character-cell display rerminals are an obsolete technology, but there are niches in which being able to do fancy things with them are still valuable. One is on small-footprint or embedded Unixes that --- 32,36 ---- In a world of X displays, one might ask ``why bother''? It's true ! that character-cell display terminals are an obsolete technology, but there are niches in which being able to do fancy things with them are still valuable. One is on small-footprint or embedded Unixes that |
|
From: Eric S. R. <es...@us...> - 2001-01-16 13:01:11
|
Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv5066
Modified Files:
curses.tex
Log Message:
Some typo fixes, and a paragraph of motivation.
Index: curses.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/curses.tex,v
retrieving revision 1.10
retrieving revision 1.11
diff -C2 -r1.10 -r1.11
*** curses.tex 2001/01/16 12:52:30 1.10
--- curses.tex 2001/01/16 13:01:04 1.11
***************
*** 31,34 ****
--- 31,41 ----
use widely differing codes, and often have their own minor quirks.
+ In a world of X displays, one might ask ``why bother''? It's true
+ that character-cell display rerminals are an obsolete technology, but
+ there are niches in which being able to do fancy things with them are
+ still valuable. One is on small-footprint or embedded Unixes that
+ don't carry an X server. Another is for tools like OS installers
+ and kernel configurators that may have to run before X is available.
+
The curses library hides all the details of different terminals, and
provides the programmer with an abstraction of a display, containing
***************
*** 425,429 ****
functions that take either integer or 1-character-string
arguments; these may be useful in writing more readable tests for
! your command interprers. It also supplies conversion functions
that take either integer or 1-character-string arguments and return
the same type. For example, \function{curses.ascii.ctrl()} returns
--- 432,436 ----
functions that take either integer or 1-character-string
arguments; these may be useful in writing more readable tests for
! your command interpreters. It also supplies conversion functions
that take either integer or 1-character-string arguments and return
the same type. For example, \function{curses.ascii.ctrl()} returns
***************
*** 453,457 ****
This HOWTO didn't cover some advanced topics, such as screen-scraping
! or capturing mouse events from an xterm inatance. But the Python
library page for the curses modules is now pretty complete. You
should browse it next.
--- 460,464 ----
This HOWTO didn't cover some advanced topics, such as screen-scraping
! or capturing mouse events from an xterm instance. But the Python
library page for the curses modules is now pretty complete. You
should browse it next.
***************
*** 474,479 ****
The ncurses FAQ: \url{http://dickey.his.com/ncurses/ncurses.faq.html}
-
- Any other suggested references?
\end{document}
--- 481,484 ----
|
|
From: Eric S. R. <es...@us...> - 2001-01-16 12:52:35
|
Update of /cvsroot/py-howto/pyhowto
In directory usw-pr-cvs1:/tmp/cvs-serv4106
Modified Files:
curses.tex
Log Message:
Thinko fixes.
Index: curses.tex
===================================================================
RCS file: /cvsroot/py-howto/pyhowto/curses.tex,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -r1.9 -r1.10
*** curses.tex 2000/11/29 03:32:13 1.9
--- curses.tex 2001/01/16 12:52:30 1.10
***************
*** 144,148 ****
support is present. It then runs your hook, and then finally
deinitializes appropriately. The hook is called inside a try-catch
! hook which catches exceptions, performs curses deinitialization, and
then passes the exception upwards. Thus, your terminal won't be left
in a funny state on exception.
--- 144,148 ----
support is present. It then runs your hook, and then finally
deinitializes appropriately. The hook is called inside a try-catch
! clause which catches exceptions, performs curses deinitialization, and
then passes the exception upwards. Thus, your terminal won't be left
in a funny state on exception.
***************
*** 329,336 ****
automatically). Once that's done, the \function{has_colors()}
function returns TRUE if the terminal in use can actually display
! colour. (Note that curses uses the American spelling 'color', instead
! of the Canadian/British spelling 'colour'; if you're like me, you'll
! have to resign yourself to misspelling it for the sake of these
! functions.)
The curses library maintains a finite number of colour pairs,
--- 329,336 ----
automatically). Once that's done, the \function{has_colors()}
function returns TRUE if the terminal in use can actually display
! colour. (Note from amk: that curses uses the American spelling
! 'color', instead of the Canadian/British spelling 'colour'; if you're
! like me, you'll have to resign yourself to misspelling it for the sake
! of these functions.)
The curses library maintains a finite number of colour pairs,
|
|
From: Martin v. L. <lo...@us...> - 2000-12-06 20:19:18
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv28906 Modified Files: xml-howto.tex Log Message: Synchronize with 1.7 of xml-howto in PyXML. Index: xml-howto.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/xml-howto.tex,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** xml-howto.tex 2000/10/07 22:17:42 1.8 --- xml-howto.tex 2000/12/06 20:19:15 1.9 *************** *** 635,639 **** \module{xml.dom.ext.reader.Sax2}, which provides the functions \function{FromXmlStream}, \function{FromXml}, \function{FromXmlFile}, ! and \function{FromXmlFile} which will construct a DOM tree from their input (a file-like object, a string, a file name, and a URL, respectively). They all return a DOM \class{Document} object. --- 635,639 ---- \module{xml.dom.ext.reader.Sax2}, which provides the functions \function{FromXmlStream}, \function{FromXml}, \function{FromXmlFile}, ! and \function{FromXmlUrl} which will construct a DOM tree from their input (a file-like object, a string, a file name, and a URL, respectively). They all return a DOM \class{Document} object. |
|
From: A.M. K. <aku...@us...> - 2000-11-29 03:32:17
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv23327 Modified Files: curses.tex Log Message: Add link to Console module, for people using Windows Index: curses.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/curses.tex,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** curses.tex 2000/08/17 00:39:22 1.8 --- curses.tex 2000/11/29 03:32:13 1.9 *************** *** 49,52 **** --- 49,58 ---- proprietary Unixes may not support everything, though. + No one has made a Windows port of the curses module. On a Windows + platform, try the Console module written by Fredrik Lundh. The + Console module provides cursor-addressable text output, plus full + support for mouse and keyboard input, and is available from + \url{http://effbot.org/efflib/console}. + \subsection{The Python curses module} |
|
From: A.M. K. <aku...@us...> - 2000-11-25 00:46:53
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv9668 Modified Files: rexec.tex Log Message: Correct URL for Penguin, and credit Felix Gallo as the author Index: rexec.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/rexec.tex,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** rexec.tex 2000/10/06 02:14:08 1.7 --- rexec.tex 2000/11/25 00:46:51 1.8 *************** *** 536,543 **** FAQ at \url{http://java.sun.com/sfaq/index.html}. ! Perl supports similar features, via a software package called Penguin. Humberto Ortiz Zuazaga wrote a paper called "The Penguin Model for Secure Distributed Internet Scripting", at ! \url{http://momo.uthscsa.edu/~humberto/project.html}. Thanks to Fred Drake for bringing it to my attention. --- 536,544 ---- FAQ at \url{http://java.sun.com/sfaq/index.html}. ! Perl supports similar features, via a software package called Penguin ! developed by Felix Gallo. Humberto Ortiz Zuazaga wrote a paper called "The Penguin Model for Secure Distributed Internet Scripting", at ! \url{http://www.hpcf.upr.edu/~humberto/documents/penguin-safe-scripting.html}. Thanks to Fred Drake for bringing it to my attention. |
|
From: A.M. K. <aku...@us...> - 2000-11-23 08:08:43
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv29256 Modified Files: ODBChints.tex apachenote.tex Log Message: Markup fixes to get compilation to work Index: ODBChints.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/ODBChints.tex,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** ODBChints.tex 1999/12/09 12:58:18 1.2 --- ODBChints.tex 2000/11/23 08:08:39 1.3 *************** *** 164,172 **** \item Create a new directory, calldll, under the lib directory, e.g. ! c:\Program Files\Python\lib\caldll\ \item Unpack calldll.zip into this directory using WinZip, pkunzip, etc. ! \item Move all the files in the calldll\lib\ subdirectory (created by the unzip) up to the parent (calldll) directory and delete the lib subdirectory --- 164,172 ---- \item Create a new directory, calldll, under the lib directory, e.g. ! \file{c:/Program Files/Python/lib/calldll}. \item Unpack calldll.zip into this directory using WinZip, pkunzip, etc. ! \item Move all the files in the \file{calldll/lib/} subdirectory (created by the unzip) up to the parent (calldll) directory and delete the lib subdirectory *************** *** 174,181 **** \item Create the file __init__.py in the calldll directory and put a suitable comment in it: ! # File to allow this directory to be treated as a python 1.5 ! package. ! \item Edit calldll\odbc.py to fix a bug in the get_info facility: In the functions "get_info_word" and "get_info_long", change "calldll.membuf" to "windll.membuf" --- 174,182 ---- \item Create the file __init__.py in the calldll directory and put a suitable comment in it: ! \begin{verbatim} ! # File to allow this directory to be treated as a python 1.5 package. ! \end{verbatim} ! \item Edit calldll/odbc.py to fix a bug in the get_info facility: In the functions "get_info_word" and "get_info_long", change "calldll.membuf" to "windll.membuf" Index: apachenote.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/apachenote.tex,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** apachenote.tex 1999/12/09 12:58:18 1.2 --- apachenote.tex 2000/11/23 08:08:39 1.3 *************** *** 79,84 **** \section{Python} \subsection{Directory} ! My python installation is in \code{C:\Python}, contrary ! to the default installation directory of \code{<nobr>C:\Program Files\Python1.5.}</nobr> The former is more convenient to use in environment paths.</ul> --- 79,84 ---- \section{Python} \subsection{Directory} ! My python installation is in \code{C:/Python}, contrary ! to the default installation directory of \code{<nobr>C:/Program Files/Python1.5.}</nobr> The former is more convenient to use in environment paths.</ul> *************** *** 93,97 **** If not already present, add to your <I>System</I> Path variable (not <I>User</I> Path variable) the directory of where python.exe resides, e.g.: ! <ul>\code{<nobr>C:\Python</nobr>}</ul> </ul> <b>PYTHONPATH</b><ul> --- 93,97 ---- If not already present, add to your <I>System</I> Path variable (not <I>User</I> Path variable) the directory of where python.exe resides, e.g.: ! <ul>\code{<nobr>C:/Python</nobr>}</ul> </ul> <b>PYTHONPATH</b><ul> |
|
From: A.M. K. <aku...@us...> - 2000-11-23 08:03:39
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv28633 Modified Files: Makefile Log Message: Cleaned up Makefile, and added rules to copy output files into my Web tree Index: Makefile =================================================================== RCS file: /cvsroot/py-howto/pyhowto/Makefile,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** Makefile 2000/09/07 01:43:51 1.4 --- Makefile 2000/11/23 08:03:35 1.5 *************** *** 1,62 **** ! HOWTOS=advocacy.tex curses.tex editor.tex \ ! regex-to-re.tex regex.tex rexec.tex \ ! sockets.tex sorting.tex \ ! xml-howto.tex xml-ref.tex \ ! python-2.0.tex ! ! MKHOWTO=mkhowto ! ! ! all: DVI PDF PS HTML ! ! dist: ! for i in dvi pdf ps ; do \ cd $$i ; \ ! tar -cvf - *.$$i | gzip -9 >All.tgz ;\ cd .. ;\ done - tar -cvf - $(HOWTOS) dvi pdf ps html | gzip -9 -c >dist-howto.tgz - - DVI: dvi - for i in $(HOWTOS) ; do \ - $(MKHOWTO) --dvi $$i ;\ - base=`basename $$i .tex` ;\ - mv $$base.dvi dvi/ ;\ - done - - dvi: - mkdir dvi - - HTML: - for i in $(HOWTOS) ; do \ - $(MKHOWTO) --html --split 1 $$i ;\ - base=`basename $$i .tex` ;\ - rm -rf $$base/TMP/ ;\ - done - - PDF: pdf - for i in $(HOWTOS) ; do \ - $(MKHOWTO) --pdf $$i ;\ - base=`basename $$i .tex` ;\ - mv $$base.pdf pdf/ ;\ - done ! pdf: ! mkdir pdf ! PS: ps ! for i in $(HOWTOS) ; do \ ! $(MKHOWTO) --ps $$i ;\ ! base=`basename $$i .tex` ;\ ! mv $$base.ps ps/ ;\ ! done ! ps: ! mkdir ps - clean: - rm -f *~ *.log pdf/*.pdf ps/*.ps dvi/*.dvi - rm -rf html/* --- 1,80 ---- ! MKHOWTO=../tools/mkhowto ! WEBDIR=~/www/python/howto/ ! VPATH=.:dvi:pdf:ps:txt ! ! # List of HOWTOs that aren't to be processed ! ! REMOVE_HOWTO = ODBChints.tex apachenote.tex ! ! # Determine list of files to be built ! ! HOWTO=$(filter-out $(REMOVE_HOWTO),$(wildcard *.tex)) ! DVI =$(patsubst %.tex,%.dvi,$(HOWTO)) ! PDF =$(patsubst %.tex,%.pdf,$(HOWTO)) ! PS =$(patsubst %.tex,%.ps,$(HOWTO)) ! TXT =$(patsubst %.tex,%.txt,$(HOWTO)) ! HTML =$(patsubst %.tex,%,$(HOWTO)) ! ! # Rules for building various formats ! %.dvi : %.tex ! $(MKHOWTO) --dvi $< ! mv $@ dvi ! ! %.pdf : %.tex ! $(MKHOWTO) --pdf $< ! mv $@ pdf ! ! %.ps : %.tex ! $(MKHOWTO) --ps $< ! mv $@ ps ! ! %.txt : %.tex ! $(MKHOWTO) --text $< ! mv $@ txt ! ! % : %.tex ! $(MKHOWTO) --html $< ! tar -zcvf html/$*.tgz $* ! zip -r html/$*.zip $* ! ! default: ! @echo "'all' -- build all files" ! @echo "'dvi', 'pdf', 'ps', 'txt', 'html' -- build one format" ! ! all: $(DVI) $(PDF) $(PS) $(TXT) $(HTML) ! ! .PHONY : dvi pdf ps txt html ! dvi: $(DVI) ! ! pdf: $(PDF) ! ps: $(PS) ! txt: $(TXT) ! html:$(HTML) ! ! # Rule to build collected tar files ! dist: #all ! for i in dvi pdf ps txt ; do \ cd $$i ; \ ! tar -zcf All.tgz *.$$i ;\ cd .. ;\ done ! # Rule to copy files to the Web tree on AMK's machine ! web: dist ! cp dvi/* $(WEBDIR)/dvi ! cp ps/* $(WEBDIR)/ps ! cp pdf/* $(WEBDIR)/pdf ! cp txt/* $(WEBDIR)/txt ! for dir in $(HTML) ; do cp -rp $$dir $(WEBDIR) ; done ! for ltx in $(HOWTO) ; do cp -p $$ltx $(WEBDIR)/latex ; done ! clean: ! rm -f *~ *.log *.ind *.l2h *.aux *.toc *.how ! rm -f *.dvi *.ps *.pdf *.bkm ! clobber: ! rm dvi/* ps/* pdf/* txt/* html/* |
|
From: A.M. K. <aku...@us...> - 2000-11-11 01:49:40
|
Update of /cvsroot/py-howto/pyhowto/zodb In directory slayer.i.sourceforge.net:/tmp/cvs-serv3293 Modified Files: chatter.py gfdl.tex introduction.tex prog-zodb.tex zeo.tex zodb.tex Added Files: links.tex Log Message: Add the text from my old ZODB/ZEO page (very roughly, so it still needs a *lot* of editing) --- NEW FILE --- % links.tex % Collection of relevant links ZODB HOWTO, by Michel Pelletier:\\ Goes into slightly more detail about the rules for writing applications using the ZODB. \\ \url{http://www.zope.org/Members/michel/HowTos/ZODB-How-To} Introduction to the Zope Object Database, by Jim Fulton \\ Goes into much greater detail, explaining advanced uses of the ZODB and how it's actually implemented. A definitive reference, and highly recommended. \\ \url{http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html} Download link for ZEO \\ \url{http://www.zope.org/Products/ZEO/} Index: chatter.py =================================================================== RCS file: /cvsroot/py-howto/pyhowto/zodb/chatter.py,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** chatter.py 2000/11/08 23:55:45 1.1 --- chatter.py 2000/11/11 01:49:37 1.2 *************** *** 28,33 **** self.name = name ! # Internal attribute: _messages holds all the chat messages. ! self._messages = BTree.BTree() --- 28,32 ---- self.name = name ! # Internal attribute: _messages holds all the chat messages. self._messages = BTree.BTree() Index: gfdl.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/zodb/gfdl.tex,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** gfdl.tex 2000/11/08 23:55:45 1.1 --- gfdl.tex 2000/11/11 01:49:37 1.2 *************** *** 1,3 **** ! % fdl.tex % This file is a chapter. It must be included in a larger document to work % properly. --- 1,3 ---- ! % gfdl.tex % This file is a chapter. It must be included in a larger document to work % properly. Index: introduction.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/zodb/introduction.tex,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** introduction.tex 2000/11/08 23:55:45 1.1 --- introduction.tex 2000/11/11 01:49:37 1.2 *************** *** 17,21 **** programming languages provide facilities that automatically write objects to disk and read them in again when they're required by a ! running program. It's certainly possible to build your own system for making Python --- 17,21 ---- programming languages provide facilities that automatically write objects to disk and read them in again when they're required by a ! running program, and the ZODB adds such facilities to Python. It's certainly possible to build your own system for making Python *************** *** 35,66 **** - \subsection{OODBs vs. Relational DBs} Another way to look at it is that the ZODB is a Python-specific ! object-oriented database (OODB). Relational databases (RDBs) are far more common than OODBs. ! Relational databases store information in tables; a table consists of any number of rows, each row containing several columns of ! information. Let's introduce the example that we'll be using through this document. The example comes from my day job working for the MEMS Exchange, in a greatly simplified version. - - XXX explain a bit more ! The job is to track process runs, which are lists of manufacturing steps ! to be performed in a semiconductor fab. A run is owned by a particular user, and has a name and assigned ID number. Runs consist of a number of operations; an operation is a single step to be performed, such as depositing something on a wafer or etching ! something off it. Operations may have parameters, which are ! additional information required to perform an operation. For example, ! if you're depositing something on a wafer, you need to know two ! things: 1) what you're depositing, and 2) how much should be ! deposited. ! You might deposit 100 microns of silicon oxide, or 1 micron of copper. Mapping these structures to a relational database is straightforward: --- 35,68 ---- \subsection{OODBs vs. Relational DBs} Another way to look at it is that the ZODB is a Python-specific ! object-oriented database (OODB). Commercial object databases for C++ ! or Java often require that you jump through some hoops, using a ! special preprocessor or avoiding certain data types. As we'll see, ! the ZODB has some hoops of its own, but in comparison the naturalness ! of the ZODB is astonishing. Relational databases (RDBs) are far more common than OODBs. ! Relational databases store information in tables; a table consists of any number of rows, each row containing several columns of ! information. Let's introduce the example that we'll be using through this document. The example comes from my day job working for the MEMS Exchange, in a greatly simplified version. ! The job is to track process runs, which are lists of manufacturing ! steps to be performed in a semiconductor fab. A run is owned by a particular user, and has a name and assigned ID number. Runs consist of a number of operations; an operation is a single step to be performed, such as depositing something on a wafer or etching ! something off it. ! ! Operations may have parameters, which are additional information ! required to perform an operation. For example, if you're depositing ! something on a wafer, you need to know two things: 1) what you're ! depositing, and 2) how much should be deposited. You might deposit ! 100 microns of silicon oxide, or 1 micron of copper. Mapping these structures to a relational database is straightforward: *************** *** 81,87 **** class Run: .run_id ! ... XXX finish - If you were \subsection{What is ZEO?} --- 83,92 ---- class Run: .run_id ! ... XXX finish this code ... ! ! ! ! XXX continue \subsection{What is ZEO?} Index: prog-zodb.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/zodb/prog-zodb.tex,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** prog-zodb.tex 2000/11/08 23:55:45 1.1 --- prog-zodb.tex 2000/11/11 01:49:37 1.2 *************** *** 8,16 **** \section{ZODB Programming} - \subsection{How ZODB Works} - - XXX (ExtensionClass, dirty bits) - - \subsection{Installing ZODB} --- 8,11 ---- *************** *** 59,64 **** --- 54,240 ---- problems, please let me know. + \subsection{How ZODB Works} + XXX (ExtensionClass, dirty bits) + + There are 3 main interfaces in the ZODB: + \class{Storage}, \class{DB}, and \class{Connection} classes. + + \begin{itemize} + \item \class{Storage} classes are the lowest layer, and handle storing + and retrieving objects from some form of long-term storage. A few + different types of Storage have been written, such as + \class{FileStorage}, which uses regular files, + and \class{BerkeleyStorage}, which uses Sleepycat Software's + BerkeleyDB 2.7. You could + write a new Storage that stored objects in a relational database or + Metakit file, for example, if you needed to ensure some property + useful to your application. Two example storages, + \class{DemoStorage} and \class{MappingStorage}, are + available to use as models if you want to write a new Storage. + + \item The \class{DB} class sits on top of a storage, and mediates the + interaction between several connections. One \class{DB} instance + is created per process. + + \item Finally, the \class{Connection} class caches objects, and moves + them into and out of object storage. A multi-threaded program can + open a separate \class{Connection} instance for each thread. + + \end{itemize} + + \subsection{Opening a ZODB} + + Preparing to use a ZODB requires 3 steps: you have to open the + Storage, then create a DB instance that uses the Storage, and then get + a Connection from the DB instance. All this is only a few lines of + code: + + \begin{verbatim} + from ZODB import FileStorage, DB + + storage = FileStorage.FileStorage('/tmp/test-filestorage.fs') + db = DB( storage ) + conn = db.open() + \end{verbatim} + + Note that you can use a completely different data storage mechanism + by changing the first line that opens a Storage; the + above example uses a \class{FileStorage}. Soon you'll see how ZEO + uses this flexibility to good effect. + + \subsection{Using a ZODB} + + Making a Python class persistent is quite simple; it simply needs + to subclass from the \class{Persistent} class, as shown in this + example: + + \begin{verbatim} + import ZODB + from Persistence import Persistent + + class User(Persistent): + pass + \end{verbatim} + + (The apparently unnecessary \code{import ZODB} statement is + needed for the following \\code{from...import} statement to work + correctly, since the ZODB code is doing some magical tricks with + importing.) + + For simplicity, in the examples the \class{User} class will + simply be used as a holder for a bunch of attributes. Normally the + class would define various methods that add functionality, but that + has no impact on the ZODB's treatment of the class. + + The ZODB uses persistence by reachability; starting from + a set of root objects, all the attributes of those objects are made + persistent, whether they're simple Python data types or class instances. + + As an example, we'll create a simple database of users that allows + retrieving a \class{User} object given the user's ID. First, we + retrieve the primary root object of the ZODB; this object behaves like + a Python dictionary, so you can just add a new key/value pair for your + application's root object. We'll insert a \class{BTree} object + that will contain all the \class{User} objects. (The + \class{BTree} module is also included as part of Zope.) + + \begin{verbatim}dbroot = conn.root() + + # Ensure that a 'userdb' key is present + if not dbroot.has_key('userdb'): + import BTree + dbroot['userdb'] = BTree.BTree() + + userdb = dbroot['userdb'] + \end{verbatim} + + Inserting a new user is simple: create the \class{User} + object, fill it with data, insert it into the BTree, and commit this + transaction. + + \begin{verbatim}# Create new User instance + newuser = User() + + # Add whatever attributes you want to track + newuser.id = 'amk' + newuser.first_name = 'Andrew' ; newuser.last_name = 'Kuchling' + ... + + # Add object to the BTree, keyed on the ID + userdb[ newuser.id ] = newuser + + # Commit the change + get_transaction().commit() + \end{verbatim} + + When you import the ZODB package, it adds a new function, + \function{get_transaction()}, to Python's collection of built-in + functions. \function{get_transaction()} returns a transaction + object, which has two important methods: \method{commit()} and + \method{abort()}. \method{commit()} writes out any modified objects + to disk, making the changes permanent, while + \method{abort()} rolls back any changes that have been made, + restoring the original state of the objects. If you're familiar with + database transactional semantics, this is all what you'd expect. + + Because the integration with Python is so complete, it's a lot like + having transactional semantics for your program's variables, and you + can experiment with transactions at the Python interpreter's prompt: + + \begin{verbatim}>>> newuser + <User instance at 81b1f40> + >>> newuser.first_name # Print initial value + 'Andrew' + >>> newuser.first_name = 'Bob' # Change first name + >>> newuser.first_name # Verify the change + 'Bob' + >>> get_transaction().abort() # Abort transaction + >>> newuser.first_name # The value has changed back + 'Andrew' + \end{verbatim} + + \subsection{Rules for Writing Persistent Classes} + + The ZODB uses various Python hooks to catch attribute accesses, + which cover most of the ways of modifying an object, but not all of + them. If you modify a \class{User} object by assigning to one of + its attributes, as in \code{userobj.first_name = 'Andrew'}, the + ZODB will mark the object as having been changed, and it'll be written + out on the following \method{commit()}. + + The most common idiom that \emph{isn't} caught by Zope is + mutating a list or dictionary. If \class{User} objects have a + attribute named \code{friends} containing a list, calling + \code{userobj.friends.append( otherUser )} doesn't mark + \code{userobj} as modified; from the ZODB's point of + view, \code{userobj.friends} was only read, and its value, which + happened to be an ordinary Python list, was returned. The ZODB isn't + aware that the returned value was later modified. + + This is one of the few quirks you'll have to remember when using + the ZODB; if you modify an attribute of an object in place, you have + to manually mark the object as having been modified, by + setting the \code{_p_changed} attribute to true: + + \begin{verbatim} + userobj.friends.append( otherUser ) + userobj._p_changed = 1 + \end{verbatim} + + You can hide this implementation detail by not designing your + class's API to use direct attribute access; instead, you can use the + Java-style approach of accessor methods for everything, and then set + \code{_p_changed} within the accessor method. For example, you + might forbid accessing the \code{friends} attribute directly, + and add a \method{get_friend_list()} accessor and an + \method{add_friend()} modifier method to the class. + Alternatively, you could use a ZODB-aware list or mapping type that + sets \code{_p_changed} for you; the ZODB includes a + \class{PersistentMapping} class, and I've contributed a + \class{PersistentList} class that may make it into a future + release. + Index: zeo.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/zodb/zeo.tex,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** zeo.tex 2000/11/08 23:55:45 1.1 --- zeo.tex 2000/11/11 01:49:37 1.2 *************** *** 1,14 **** % ZEO - % How ZEO works (ClientStorage) % Installing ZEO % Configuring ZEO \section{ZEO} - \subsection{How ZEO Works} - XXX (ClientStorage) - - \subsection{Installing ZEO} This package contains the Python code for ZEO, packaged to make it --- 1,11 ---- % ZEO % Installing ZEO + % How ZEO works (ClientStorage) % Configuring ZEO \section{ZEO} + \subsection{Installing ZEO} This package contains the Python code for ZEO, packaged to make it *************** *** 86,89 **** correctly. ! \subsection{Configuring ZEO} --- 83,294 ---- correctly. ! ! \subsection{How ZEO Works} ! ! The ZODB, as I've described it so far, can only be used within a ! single Python process running on one machine. ZEO, Zope ! Enterprise Objects, extends the ZODB machinery to provide access to ! objects over a network. The name "Zope Enterprise Objects" is a bit ! misleading. ZEO can be used to store Python objects, and access them ! in a distributed fashion, without Zope ever entering a picture; ! essentially the combination of ZEO and ZODB is a Python-specific ! object database. ! ! ZEO consists of about 1400 lines of Python code. The code is ! relatively small because it contains only code for a TCP/IP server, ! and for a new type of Storage, \class{ClientStorage}. ! \class{ClientStorage} doesn't use disk files at all; it simply ! makes remote procedure calls to the server, which then passes them on ! a regular \class{Storage} class such as \class{FileStorage}. ! The following diagram lays out the system: ! ! [ XXX insert diagram here ] ! ! Any number of processes can create a \class{ClientStorage} ! instance, and any number of threads in each process can be using that ! instance. \class{ClientStorage} aggressively caches objects ! locally, so, in order to avoid using stale data, the ZEO server sends ! an invalidate message to all the connected \class{ClientStorage} ! instances on every write operation. The invalidate message contains ! the object ID for each object that's been modified, so the ! \class{ClientStorage} instances can delete the old data for the ! given object from their caches. ! ! This design decision has some consequences you should be aware of. ! First, while ZEO isn't tied to Zope, it was first written for use with ! Zope, which stores HTML, images, and program code in the database. As ! a result, reads from the database are \emph{far} more frequent than ! writes, and ZEO is therefore better suited for read-intensive ! applications. If every \class{ClientStorage} is writing to the ! database very frequently, this will result in a storm of invalidate ! messages being sent, and this might take up more processing time than ! the actual database operations themselves. ! ! On the other hand, for applications that have few writes in ! comparison to the number of read accesses, this aggressive caching can ! be a major win. Consider the job of writing a Slashdot-like ! discussion forum, where you want to divide the load among several Web ! servers. If news items and postings are represented by objects, and ! accessed through ZEO, then the most heavily accessed objects -- the ! most recent or most popular postings -- will very quickly wind up in ! the caches of the \class{ClientStorage} instances on the ! front-end servers. The back-end ZEO server will do relatively little ! work, only being called upon to return the occasional older posting ! that's requested, and to send the occasional invalidate message when a ! new posting is added. The ZEO server isn't going to be ! contacted for ! every single request, so its workload will remain manageable. ! ! \subsection{Configuring and Running a ZEO Server} + Once the code has been unpacked, the next step is to run a ZEO + server. Go to the Zope installation directory and run this command: + + \begin{verbatim}python lib/python/ZEO/start.py -p 9672 /tmp/storage.fs + \end{verbatim} + + This starts a ZEO server listening on TCP port 9672, and using a + \class{FileStorage} on top of the file + \file{/tmp/storage.fs}. If you want to use a storage other than + \class{FileStorage}, you'll have to manually hack the code in + \file{start.py} to create an instance of a different class. + + + \subsection{Connecting to a ZEO Server} + + Once a ZEO server is up and running, using it is just like using + ZODB with a more conventional disk-based storage. The only difference + is that you'll create a \class{ClientStorage} instance instead of + a \class{FileStorage} instance: + + \begin{verbatim} + from ZEO import ClientStorage + from ZODB import DB + + storage = ClientStorage.ClientStorage( ('localhost', 9762) ) + db = DB( storage ) + conn = db.open() + \end{verbatim} + + From this point onward, your ZODB-based code is happily unaware + that objects are being retrieved from a ZEO server, and not from the + local disk. + + \subsection{Sample Application: chatter.py} + + For an example application, we'll build a little chat application. + What's interesting is that none of the application's code deals with + network programming at all; instead, an object will hold chat + messages, and be magically shared between all the clients through ZEO. + I won't present the complete script here; you can <a + href="chatter.py">download it or read <a + href="chatter.py.html">the colourised source code. Only the + interesting portions of the code will be covered here. + + The basic data structure is the \class{ChatSession} object, + which provides an \method{add_message()} method that adds a + message, and a \method{new_messages()} method that returns a list + of new messages that have accumulated since the last call to + \method{new_messages()}. Internally, \class{ChatSession} + maintains a B-tree that uses the time as the key, and stores the + message as the corresponding value. + + The constructor for \class{ChatSession} is pretty simple; it simply creates an attribute containing a B-tree: + + \begin{verbatim} + class ChatSession(Persistent): + def __init__(self, name): + self.name = name + # Internal attribute: _messages holds all the chat messages. + self._messages = BTree.BTree() + \end{verbatim} + + \method{add_message()} has to add a message to the + \code{_messages} B-tree. A complication is that it's possible + that some other client is trying to add a message at the same time; + when this happens, the client that commits first wins, and the second + client will get a \exception{ConflictError} exception when it tries + to commit. For this application, \exception{ConflictError} isn't + serious but simply means that the operation has to be retried; other + applications might treat it as a fatal error. The code uses + \code{try...except...else} inside a \code{while} loop, + breaking out of the loop when the commit works without raising an + exception. + + \begin{verbatim} + def add_message(self, message): + """Add a message to the channel. + message -- text of the message to be added + """ + + while 1: + try: + now = time.time() + self._messages[ now ] = message + get_transaction().commit() + except ConflictError: + # Conflict occurred; this process should pause and + # wait for a little bit, then try again. + time.sleep(.2) + pass + else: + # No ConflictError exception raised, so break + # out of the enclosing while loop. + break + # end while + \end{verbatim} + + \method{new_messages()} introduces the use of \textit{volatile} + attributes. Attributes of a persistent object that begin with + \code{_v_} are considered volatile and are never stored in the + database. \method{new_messages()} needs to store the last time + the method was called, but if the time was stored as a regular + attribute, its value would be committed to the database and shared + with all the other clients. \method{new_messages()} would then + return the new messages accumulated since any other client called + \method{new_messages()}, which isn't what we want. + + \begin{verbatim} + def new_messages(self): + "Return new messages." + + # self._v_last_time is the time of the most recent message + # returned to the user of this class. + if not hasattr(self, '_v_last_time'): + self._v_last_time = 0 + + new = [] + T = self._v_last_time + + for T2, message in self._messages.items(): + if T2 > T: + new.append( message ) + self._v_last_time = T2 + + return new + \end{verbatim} + + This application is interesting because it uses ZEO to easily share a + data structure, using it more like a networking tool than a database. + I can foresee many interesting applications using ZEO in this way: + + \begin{itemize} + \item With a Tkinter front-end, and a cleverer, more scalable data + structure, you could build a shared whiteboard using the same + technique. + + \item A shared chessboard object would make writing a networked chess + game easy. + + \item You could create a Python class containing a CD's title and + track information, and make a CD database containing many objects + available through a read-only ZEO server. + + \item A program like Quicken could use a ZODB on the local disk to + store its data. This avoids the need to write and maintain + specialized I/O code that reads in your objects and writes them out; + instead you can concentrate on the problem domain, writing objects + that represent cheques, stock portfolios, or whatever. + + \end{itemize} + Index: zodb.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/zodb/zodb.tex,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** zodb.tex 2000/11/08 23:55:45 1.1 --- zodb.tex 2000/11/11 01:49:37 1.2 *************** *** 1,5 **** \documentclass{howto} ! \title{ZODB/ZEO HOWTO} \release{0.01} --- 1,5 ---- \documentclass{howto} ! \title{Programming with ZODB and ZEO} \release{0.01} *************** *** 27,30 **** --- 27,31 ---- \appendix + \input links.tex \input gfdl.tex |
|
From: A.M. K. <aku...@us...> - 2000-11-08 23:58:10
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv10937 Removed Files: zodb-zeo.tex Log Message: Deleted this document; it will be replaced by the one in the zodb/ subdirectory |
Update of /cvsroot/py-howto/pyhowto/zodb In directory slayer.i.sourceforge.net:/tmp/cvs-serv10693 Added Files: Makefile chatter.py gfdl.tex introduction.tex modules.tex prog-zodb.tex storages.tex transactions.tex zeo.tex zodb.tex Log Message: Initial checkin --- NEW FILE --- TEX_FILES = gfdl.tex introduction.tex modules.tex prog-zodb.tex \ storages.tex transactions.tex zeo.tex zodb.tex MKHOWTO=../../tools/mkhowto zodb.dvi: $(MKHOWTO) --dvi zodb.tex --- NEW FILE --- import sys, time, os, random from ZEO import ClientStorage import ZODB from ZODB.POSException import ConflictError from Persistence import Persistent import BTree class ChatSession(Persistent): """Class for a chat session. Messages are stored in a B-tree, indexed by the time the message was created. (Eventually we'd want to throw messages out, add_message(message) -- add a message to the channel new_messages() -- return new messages since the last call to this method """ def __init__(self, name): """Initialize new chat session. name -- the channel's name """ self.name = name # Internal attribute: _messages holds all the chat messages. self._messages = BTree.BTree() def new_messages(self): "Return new messages." # self._v_last_time is the time of the most recent message # returned to the user of this class. if not hasattr(self, '_v_last_time'): self._v_last_time = 0 new = [] T = self._v_last_time for T2, message in self._messages.items(): if T2 > T: new.append( message ) self._v_last_time = T2 return new def add_message(self, message): """Add a message to the channel. message -- text of the message to be added """ while 1: try: now = time.time() self._messages[ now ] = message get_transaction().commit() except ConflictError: # Conflict occurred; this process should pause and # wait for a little bit, then try again. time.sleep(.2) pass else: # No ConflictError exception raised, so break # out of the enclosing while loop. break # end while def get_chat_session(conn, channelname): """Return the chat session for a given channel, creating the session if required.""" # We'll keep a B-tree of sessions, mapping channel names to # session objects. The B-tree is stored at the ZODB's root under # the key 'chat_sessions'. root = conn.root() if not root.has_key('chat_sessions'): print 'Creating chat_sessions B-tree' root['chat_sessions'] = BTree.BTree() get_transaction().commit() sessions = root['chat_sessions'] # Get a session object corresponding to the channel name, creating # it if necessary. if not sessions.has_key( channelname ): print 'Creating new session:', channelname sessions[ channelname ] = ChatSession(channelname) get_transaction().commit() session = sessions[ channelname ] return session if __name__ == '__main__': if len(sys.argv) != 2: print 'Usage: %s <channelname>' % sys.argv[0] sys.exit(0) storage = ClientStorage.ClientStorage( ('localhost', 9672) ) db = ZODB.DB( storage ) conn = db.open() s = session = get_chat_session(conn, sys.argv[1]) messages = ['Hi.', 'Hello', 'Me too', "I'M 3L33T!!!!"] while 1: # Send a random message msg = random.choice(messages) session.add_message( '%s: pid %i' % (msg,os.getpid() )) # Display new messages for msg in session.new_messages(): print msg # Wait for a few seconds pause = random.randint( 1, 4 ) time.sleep( pause ) --- NEW FILE --- % fdl.tex % This file is a chapter. It must be included in a larger document to work % properly. \section{GNU Free Documentation License} Version 1.1, March 2000\\ Copyright $\copyright$ 2000 Free Software Foundation, Inc.\\ 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA\\ Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. \subsection*{Preamble} The purpose of this License is to make a manual, textbook, or other written document ``free'' in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of ``copyleft'', which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference. \subsection{Applicability and Definitions} This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The ``Document'', below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as ``you''. A ``Modified Version'' of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A ``Secondary Section'' is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The ``Invariant Sections'' are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. The ``Cover Texts'' are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A ``Transparent'' copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not ``Transparent'' is called ``Opaque''. Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, \LaTeX~input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only. The ``Title Page'' means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, ``Title Page'' means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. \subsection{Verbatim Copying} You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies. \subsection{Copying in Quantity} If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document. \subsection{Modifications} You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version: \begin{itemize} \item Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. \item List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five). \item State on the Title page the name of the publisher of the Modified Version, as the publisher. \item Preserve all the copyright notices of the Document. \item Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. \item Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. \item Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. \item Include an unaltered copy of this License. \item Preserve the section entitled ``History'', and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled ``History'' in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. \item Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the ``History'' section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. \item In any section entitled ``Acknowledgements'' or ``Dedications'', preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. \item Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. \item Delete any section entitled ``Endorsements''. Such a section may not be included in the Modified Version. \item Do not retitle any existing section as ``Endorsements'' or to conflict in title with any Invariant Section. \end{itemize} If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section entitled ``Endorsements'', provided it contains nothing but endorsements of your Modified Version by various parties -- for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version. \subsection{Combining Documents} You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections entitled ``History'' in the various original documents, forming one section entitled ``History''; likewise combine any sections entitled ``Acknowledgements'', and any sections entitled ``Dedications''. You must delete all sections entitled ``Endorsements.'' \subsection{Collections of Documents} You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document. \subsection{Aggregation With Independent Works} A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an ``aggregate'', and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate. \subsection{Translation} Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail. \subsection{Termination} You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. \subsection{Future Revisions of This Licence} The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http:///www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation. \subsection*{ADDENDUM: How to use this License for your documents} To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page: \begin{quote} Copyright $\copyright$ YEAR YOUR NAME. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being LIST THEIR TITLES, with the Front-Cover Texts being LIST, and with the Back-Cover Texts being LIST. A copy of the license is included in the section entitled ``GNU Free Documentation License''. \end{quote} If you have no Invariant Sections, write ``with no Invariant Sections'' instead of saying which ones are invariant. If you have no Front-Cover Texts, write ``no Front-Cover Texts'' instead of ``Front-Cover Texts being LIST''; likewise for Back-Cover Texts. If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software. --- NEW FILE --- %Introduction % What is ZODB? % What is ZEO? % How ZEO works (ClientStorage) % OODBs vs. Relational DBs % Other OODBs \section{Introduction} This HOWTO explains how to write Python programs that use the Z Object Database (ZODB) and Zope Enterprise Objects (ZEO). \subsection{What is ZODB?} The ZODB is a persistence system for Python objects. Persistent programming languages provide facilities that automatically write objects to disk and read them in again when they're required by a running program. It's certainly possible to build your own system for making Python objects persistent. The usual starting points are the \module{pickle} module, for converting objects into a string representation, and database modules, such as the \module{gdbm} or \module{bsddb} modules, provide ways to write strings to disk and read them back. It's straightforward to combine the \module{pickle} module and a database module to store and retrieve objects, and in fact the \module{shelve} module, included in Python's standard library, does this. The downside is that the programmer has to explicitly manage objects, reading an object when it's needed and writing it out to disk when the object is no longer required. The ZODB manages objects for you, keeping them in a cache and writing them out if they haven't been accessed in a while. \subsection{OODBs vs. Relational DBs} Another way to look at it is that the ZODB is a Python-specific object-oriented database (OODB). Relational databases (RDBs) are far more common than OODBs. Relational databases store information in tables; a table consists of any number of rows, each row containing several columns of information. Let's introduce the example that we'll be using through this document. The example comes from my day job working for the MEMS Exchange, in a greatly simplified version. XXX explain a bit more The job is to track process runs, which are lists of manufacturing steps to be performed in a semiconductor fab. A run is owned by a particular user, and has a name and assigned ID number. Runs consist of a number of operations; an operation is a single step to be performed, such as depositing something on a wafer or etching something off it. Operations may have parameters, which are additional information required to perform an operation. For example, if you're depositing something on a wafer, you need to know two things: 1) what you're depositing, and 2) how much should be deposited. You might deposit 100 microns of silicon oxide, or 1 micron of copper. Mapping these structures to a relational database is straightforward: runs run_id owner title acct_num operations run_id step_id process_id parameters run_id step_id param_name param_value In an object-oriented programming language, you would write three classes: class Run: .run_id ... XXX finish If you were \subsection{What is ZEO?} \subsection{About the Author} \label{intro:author} --- NEW FILE --- % Related Modules % PersistentMapping % PersistentList % BTree % Catalog \section{Related Modules} \subsection{PersistentMapping} \subsection{PersistentList} \subsection{BTree} \subsection{Catalog} --- NEW FILE --- %ZODB Programming % How ZODB works (ExtensionClass, dirty bits) % Installing ZODB % Rules for Writing Persistent Classes \section{ZODB Programming} \subsection{How ZODB Works} XXX (ExtensionClass, dirty bits) \subsection{Installing ZODB} The ZODB forms part of Zope, but it's difficult and somewhat painful to disentangle the bits from Zope that you need to write Python programs that use only the ZODB. Accordingly I've gone ahead and packaged only the packages required for the ZODB, so you can install them and start programming. These packages are quite young and are still experimental; don't be surprised if the installation process runs into problems. Please inform me of any difficulties you encounter. \subsubsection{Requirements} You'll need Python, of course; version 1.5.2 certainly works, and the ZODB code seems to compile using the Python 2.0 CVS tree. The code is packaged using the new distribution tools, so first you'll have to get the latest Distutils release from the Distutils SIG page at \url{http://www.python.org/sigs/distutils-sig/download.html}, and install it. This is simply a matter of untarring or unzipping the release package, and then running \code{python setup.py install}. Be sure you have the latest version of Distutils; if you encounter problems compiling ZODB/TimeStamp.c or your compiler reports an error like "Can't create build/temp.linux2/ExtensionClass.o: No such file or directory", you need an updated version. Old versions of Distutils have two bugs which affect the setup scripts. First, for a long time the define_macros keyword in setup.py files didn't work due to a Distutils bug, so I hacked TimeStamp.c in earlier releases. The Distutils have since been fixed, and the hack became unnecessary, so I removed it. Second, the code that creates directories tries to be smart and caches them to save time by not trying to create a directory twice, but this code was broken in old versions of Distutils. \subsubsection{Installing the Packages} Download the ZODB tarball containing all the packages for both ZODB and ZEO from \url{http://www.kuchling.com/files/zodb/}. Run the standard command for installing software using the Distutils: \code{python setup.py install}. If you encounter any problems, please let me know. \subsection{Rules for Writing Persistent Classes} --- NEW FILE --- % Storages % FileStorage % BerkeleyStorage % OracleStorage \section{Storages} \subsection{ FileStorage} \subsection{ BerkeleyStorage} \subsection{ OracleStorage} --- NEW FILE --- %Transactions and Versioning % Committing and Aborting % Subtransactions % Versions % Multithreaded ZODB Programs \section{Transactions and Versioning} \subsection{Committing and Aborting} \subsection{Subtransactions} \subsection{Versions} \subsection{Multithreaded ZODB Programs} --- NEW FILE --- % ZEO % How ZEO works (ClientStorage) % Installing ZEO % Configuring ZEO \section{ZEO} \subsection{How ZEO Works} XXX (ClientStorage) \subsection{Installing ZEO} This package contains the Python code for ZEO, packaged to make it easier to set up and run a ZEO Storage Server on your machine. Most notably, I've rewritten the \code{start.py} script to use a configuration file and renamed it to \code{zeod}. WARNING: This packaging is HIGHLY EXPERIMENTAL and has only been tested on one machine, which happened to be running Red Hat 6.2. I fully expect there to be problems and incompatibilities on other Unix variants or even other Linux distributions. Please inform me of any problems, or post your questions to the ZEO mailing list at \email{zop...@zo...}. \subsubsection{Requirements} To run a ZEO server, you'll need Python 1.5.2 or 2.0, and the ZODB packages from \url{http://www.kuchling.com/files/zodb/} have to be installed. \emph{Note for Python 1.5.2 users}: ZEO requires updated versions of the \code{asyncore.py} and \code{asynchat.py} modules that are included in 1.5.2's standard library. You can grab copies of the Python 2.0 versions of these modules from the above Web site, or from the Python 2.0 distribution. \subsubsection{Installation} The \code{setup.py} script won't do all the work for you at the moment, since two scripts need to go into odd locations and the Distutils don't seem to support this at the moment. One script goes into \code{/etc/rc.d/init.d}, so you can configure your system to start a ZEO Storage Server at boot-up. \begin{enumerate} \item Run \code{python setup.py install} to install the ZEO/ package into your Python installation. \item Copy various files into their proper locations: \begin{verbatim} cp zeo.conf /usr/local/etc/ ; chmod 644 /usr/local/etc/zeo.conf cp zeo /etc/rc.d/init.d ; chmod 755 /etc/rc.d/init.d/zeo cp zeod /usr/local/bin ; chmod 755 /usr/local/bin/zeod \end{verbatim} \item Edit \code{/usr/local/etc/zeo.conf} appropriately for your desired setup. \end{enumerate} To test whether ZEO is working correctly, try running the following lines of code, which will connect to the server, add some bits of data to the root of the ZODB, and commits the transaction: \begin{verbatim} from ZEO import ClientStorage from ZODB import DB # Change next line to connect to your ZEO server storage = ClientStorage.ClientStorage( ('kronos', 1972) ) db = DB( storage ) conn = db.open() root = conn.root() # Store some things in the root root['list'] = ['a', 'b', 1.0, 3] root['dict'] = {'a':1, 'b':4} # Commit the transaction get_transaction().commit() \end{verbatim} If this code runs properly, then your ZEO server is probably working correctly. \subsection{Configuring ZEO} --- NEW FILE --- \documentclass{howto} \title{ZODB/ZEO HOWTO} \release{0.01} \author{A.M.\ Kuchling} \authoraddress{am...@bi...} \begin{document} \maketitle \tableofcontents \copyright{Copyright $\copyright$ 2000 A.M. Kuchling. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the appendix entitled ``GNU Free Documentation License''.} \input{introduction} \input{prog-zodb} \input{transactions} \input{modules} \input{storages} \input{zeo} \appendix \input gfdl.tex \end{document} |
|
From: A.M. K. <aku...@us...> - 2000-11-08 23:52:40
|
Update of /cvsroot/py-howto/pyhowto/zodb In directory slayer.i.sourceforge.net:/tmp/cvs-serv10492/zodb Log Message: Directory /cvsroot/py-howto/pyhowto/zodb added to the repository |
|
From: A.M. K. <aku...@us...> - 2000-10-19 01:42:36
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv32595 Modified Files: python-2.0.tex Log Message: Correction from David Bolen: the Windows version no longer crashes on trying to import a 1.5 module Bump the document version number Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.40 retrieving revision 1.41 diff -C2 -r1.40 -r1.41 *** python-2.0.tex 2000/10/17 13:02:42 1.40 --- python-2.0.tex 2000/10/19 01:42:33 1.41 *************** *** 4,8 **** \title{What's New in Python 2.0} ! \release{1.00} \author{A.M. Kuchling and Moshe Zadka} \authoraddress{\email{am...@bi...}, \email{mo...@ma...} } --- 4,8 ---- \title{What's New in Python 2.0} ! \release{1.01} \author{A.M. Kuchling and Moshe Zadka} \authoraddress{\email{am...@bi...}, \email{mo...@ma...} } *************** *** 832,845 **** The version number of the Python C API was incremented, so C extensions compiled for 1.5.2 must be recompiled in order to work with ! 2.0. On Windows, attempting to import a third party extension built ! for Python 1.5.x usually results in an immediate crash; there's not ! much we can do about this. (Here's Mark Hammond's explanation of the ! reasons for the crash. The 1.5 module is linked against ! \file{Python15.dll}. When \file{Python.exe} , linked against ! \file{Python16.dll}, starts up, it initializes the Python data ! structures in \file{Python16.dll}. When Python then imports the ! module \file{foo.pyd} linked against \file{Python15.dll}, it ! immediately tries to call the functions in that DLL. As Python has ! not been initialized in that DLL, the program immediately crashes.) Users of Jim Fulton's ExtensionClass module will be pleased to find --- 832,838 ---- The version number of the Python C API was incremented, so C extensions compiled for 1.5.2 must be recompiled in order to work with ! 2.0. On Windows, it's not possible for Python 2.0 to import a third ! party extension built for Python 1.5.x due to how Windows DLLs work, ! so Python will raise an exception and the import will fail. Users of Jim Fulton's ExtensionClass module will be pleased to find *************** *** 1335,1339 **** The authors would like to thank the following people for offering ! suggestions on drafts of this article: Mark Hammond, Gregg Hauser, Jeremy Hylton, Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip Montanaro, Vladimir Marangozov, Guido van Rossum, Neil Schemenauer, --- 1328,1332 ---- The authors would like to thank the following people for offering ! suggestions on various drafts of this article: David Bolen, Mark Hammond, Gregg Hauser, Jeremy Hylton, Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip Montanaro, Vladimir Marangozov, Guido van Rossum, Neil Schemenauer, |
|
From: A.M. K. <aku...@us...> - 2000-10-17 13:02:45
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv790 Modified Files: python-2.0.tex Log Message: Bump version number -- this document is pretty much finished! Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.39 retrieving revision 1.40 diff -C2 -r1.39 -r1.40 *** python-2.0.tex 2000/10/16 14:19:21 1.39 --- python-2.0.tex 2000/10/17 13:02:42 1.40 *************** *** 4,8 **** \title{What's New in Python 2.0} ! \release{0.05} \author{A.M. Kuchling and Moshe Zadka} \authoraddress{\email{am...@bi...}, \email{mo...@ma...} } --- 4,8 ---- \title{What's New in Python 2.0} ! \release{1.00} \author{A.M. Kuchling and Moshe Zadka} \authoraddress{\email{am...@bi...}, \email{mo...@ma...} } *************** *** 11,20 **** \section{Introduction} - - {\large This is a draft document; please report inaccuracies and - omissions to the authors. This document should not be treated as - definitive; features described here might be removed or changed during - the beta cycle before the final release of Python 2.0. - } A new release of Python, version 2.0, will be released some time this --- 11,14 ---- |
|
From: A.M. K. <aku...@us...> - 2000-10-16 14:19:25
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv26409 Modified Files: python-2.0.tex Log Message: Correct form of FourThought's name Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.38 retrieving revision 1.39 diff -C2 -r1.38 -r1.39 *** python-2.0.tex 2000/10/12 03:04:22 1.38 --- python-2.0.tex 2000/10/16 14:19:21 1.39 *************** *** 1144,1148 **** \begin{itemize} \item 4DOM, a full DOM implementation ! from FourThought LLC. \item The xmlproc validating parser, written by Lars Marius Garshol. \item The \module{sgmlop} parser accelerator module, written by Fredrik Lundh. --- 1144,1148 ---- \begin{itemize} \item 4DOM, a full DOM implementation ! from FourThought, Inc. \item The xmlproc validating parser, written by Lars Marius Garshol. \item The \module{sgmlop} parser accelerator module, written by Fredrik Lundh. |
|
From: A.M. K. <aku...@us...> - 2000-10-12 03:04:25
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv31481 Modified Files: python-2.0.tex Log Message: Various minor additions and clarifications, mostly suggested by Jeremy Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.37 retrieving revision 1.38 diff -C2 -r1.37 -r1.38 *** python-2.0.tex 2000/10/12 02:49:12 1.37 --- python-2.0.tex 2000/10/12 03:04:22 1.38 *************** *** 30,34 **** better error messages went into 2.0; to list them all would be impossible, but they're certainly significant. Consult the ! publicly-available CVS logs if you want to see the full list. % ====================================================================== --- 30,38 ---- better error messages went into 2.0; to list them all would be impossible, but they're certainly significant. Consult the ! publicly-available CVS logs if you want to see the full list. This ! progress is due to the five developers working for ! PythonLabs are now getting paid to spend their days fixing bugs, ! and also due to the improved communication resulting ! from moving to SourceForge. % ====================================================================== *************** *** 89,98 **** commented on, revised by people other than the original submitter, and bounced back and forth between people until the patch is deemed worth ! checking in. This didn't come without a cost: developers now have ! more e-mail to deal with, more mailing lists to follow, and special ! tools had to be written for the new environment. For example, ! SourceForge sends default patch and bug notification e-mail messages ! that are completely unhelpful, so Ka-Ping Yee wrote an HTML ! screen-scraper that sends more useful messages. The ease of adding code caused a few initial growing pains, such as --- 93,104 ---- commented on, revised by people other than the original submitter, and bounced back and forth between people until the patch is deemed worth ! checking in. Bugs are tracked in one central location and can be ! assigned to a specific person for fixing, and we can count the number ! of open bugs to measure progress. This didn't come without a cost: ! developers now have more e-mail to deal with, more mailing lists to ! follow, and special tools had to be written for the new environment. ! For example, SourceForge sends default patch and bug notification ! e-mail messages that are completely unhelpful, so Ka-Ping Yee wrote an ! HTML screen-scraper that sends more useful messages. The ease of adding code caused a few initial growing pains, such as *************** *** 103,110 **** acceptance or rejection, while +0 and -0 mean the developer is mostly indifferent to the change, though with a slight positive or negative ! slant. The most significant change from the Apache model is that ! Guido van Rossum, who has Benevolent Dictator For Life status, can ! ignore the votes of the other developers and approve or reject a ! change, effectively giving him a +Infinity / -Infinity vote. Producing an actual patch is the last step in adding a new feature, --- 109,117 ---- acceptance or rejection, while +0 and -0 mean the developer is mostly indifferent to the change, though with a slight positive or negative ! slant. The most significant change from the Apache model is that the ! voting is essentially advisory, letting Guido van Rossum, who has ! Benevolent Dictator For Life status, know what the general opinion is. ! He can still ignore the result of a vote, and approve or ! reject a change even if the community disagrees with him. Producing an actual patch is the last step in adding a new feature, *************** *** 475,479 **** % ====================================================================== ! \section{Optional Collection of Cycles} The C implementation of Python uses reference counting to implement --- 482,486 ---- % ====================================================================== ! \section{Garbage Collection of Cycles} The C implementation of Python uses reference counting to implement *************** *** 514,529 **** objects to be leaked. ! An experimental step has been made toward fixing this problem. When ! compiling Python, the \verb|--with-cycle-gc| option can be specified. ! This causes a cycle detection algorithm to be periodically executed, ! which looks for inaccessible cycles and deletes the objects involved. ! A new \module{gc} module provides functions to perform a garbage ! collection, obtain debugging statistics, and tuning the collector's parameters. ! ! Why isn't cycle detection enabled by default? Running the cycle detection ! algorithm takes some time, and some tuning will be required to ! minimize the overhead cost. It's not yet obvious how much performance ! is lost, because benchmarking this is tricky and depends crucially ! on how often the program creates and destroys objects. Several people tackled this problem and contributed to a solution. An --- 521,541 ---- objects to be leaked. ! Python 2.0 fixes this problem by periodically executing a cycle ! detection algorithm which looks for inaccessible cycles and deletes ! the objects involved. A new \module{gc} module provides functions to ! perform a garbage collection, obtain debugging statistics, and tuning ! the collector's parameters. ! ! Running the cycle detection algorithm takes some time, and therefore ! will result in some additional overhead. It is hoped that after we've ! gotten experience with the cycle collection from using 2.0, Python 2.1 ! will be able to minimize the overhead with careful tuning. It's not ! yet obvious how much performance is lost, because benchmarking this is ! tricky and depends crucially on how often the program creates and ! destroys objects. The detection of cycles can be disabled when Python ! is compiled, if you can't afford even a tiny speed penalty or suspect ! that the cycle collection is buggy, by specifying the ! \samp{--without-cycle-gc} switch when running the \file{configure} ! script. Several people tackled this problem and contributed to a solution. An *************** *** 619,626 **** and PR\#7'' in the April 2000 archives of the python-dev mailing list for the discussion leading up to this implementation, and some useful ! relevant links. % Starting URL: % http://www.python.org/pipermail/python-dev/2000-April/004834.html Work has been done on porting Python to 64-bit Windows on the Itanium processor, mostly by Trent Mick of ActiveState. (Confusingly, --- 631,644 ---- and PR\#7'' in the April 2000 archives of the python-dev mailing list for the discussion leading up to this implementation, and some useful ! relevant links. % Starting URL: % http://www.python.org/pipermail/python-dev/2000-April/004834.html + Note that comparisons can now also raise exceptions. In earlier + versions of Python, a comparison operation such as \code{cmp(a,b)} + would always produce an answer, even if a user-defined + \method{__cmp__} method encountered an error, since the resulting + exception would simply be silently swallowed. + Work has been done on porting Python to 64-bit Windows on the Itanium processor, mostly by Trent Mick of ActiveState. (Confusingly, *************** *** 631,634 **** --- 649,657 ---- information. + Another new platform is Darwin/MacOS X; inital support for it is in + Python 2.0. Dynamic loading works, if you specify ``configure + --with-dyld --with-suffix=.x''. Consult the README in the Python + source distribution for more instructions. + An attempt has been made to alleviate one of Python's warts, the often-confusing \exception{NameError} exception when code refers to a *************** *** 1137,1142 **** patch-by-patch details. - % XXX gettext support - Brian Gallew contributed OpenSSL support for the \module{socket} module. OpenSSL is an implementation of the Secure Socket Layer, --- 1160,1163 ---- *************** *** 1202,1208 **** (Contributed by Gordon MacMillan and Moshe Zadka.) \item{\module{linuxaudiodev}:} Support for the \file{/dev/audio} device on Linux, a twin to the existing \module{sunaudiodev} module. ! (Contributed by Peter Bosch.) \item{\module{mmap}:} An interface to memory-mapped files on both --- 1223,1235 ---- (Contributed by Gordon MacMillan and Moshe Zadka.) + \item{\module{gettext}:} This module provides internationalization + (I18N) and localization (L10N) support for Python programs by + providing an interface to the GNU gettext message catalog library. + (Integrated by Barry Warsaw, from separate contributions by Martin von + Loewis, Peter Funk, and James Henstridge.) + \item{\module{linuxaudiodev}:} Support for the \file{/dev/audio} device on Linux, a twin to the existing \module{sunaudiodev} module. ! (Contributed by Peter Bosch, with fixes by Jeremy Hylton.) \item{\module{mmap}:} An interface to memory-mapped files on both *************** *** 1315,1320 **** The authors would like to thank the following people for offering suggestions on drafts of this article: Mark Hammond, Gregg Hauser, ! Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip Montanaro, Vladimir ! Marangozov, Guido van Rossum, Neil Schemenauer, and Russ Schmidt. \end{document} --- 1342,1348 ---- The authors would like to thank the following people for offering suggestions on drafts of this article: Mark Hammond, Gregg Hauser, ! Jeremy Hylton, Fredrik Lundh, Detlef Lannert, Aahz Maruch, Skip ! Montanaro, Vladimir Marangozov, Guido van Rossum, Neil Schemenauer, ! and Russ Schmidt. \end{document} |
|
From: Fred L. D. <fd...@us...> - 2000-10-12 02:49:16
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv18831 Modified Files: python-2.0.tex Log Message: Comment out a separator line, since all the others are commented out, and it would look kind of silly if typeset. Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.36 retrieving revision 1.37 diff -C2 -r1.36 -r1.37 *** python-2.0.tex 2000/10/12 02:37:14 1.36 --- python-2.0.tex 2000/10/12 02:49:12 1.37 *************** *** 966,970 **** Modules}, that joins the basic set of Python documentation. ! ====================================================================== \section{XML Modules} --- 966,970 ---- Modules}, that joins the basic set of Python documentation. ! % ====================================================================== \section{XML Modules} |
|
From: A.M. K. <aku...@us...> - 2000-10-12 02:37:18
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv6586 Modified Files: python-2.0.tex Log Message: Add new section on the XML package. (This was the only major new 2.0 feature left that wasn't covered. The article is therefore now essentially complete.) A few minor changes Index: python-2.0.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/python-2.0.tex,v retrieving revision 1.35 retrieving revision 1.36 diff -C2 -r1.35 -r1.36 *** python-2.0.tex 2000/10/04 12:40:44 1.35 --- python-2.0.tex 2000/10/12 02:37:14 1.36 *************** *** 157,162 **** distribution; it's also available on the Web at \url{http://starship.python.net/crew/lemburg/unicode-proposal.txt}. ! This article will simply cover the most significant points from the ! full interface. In Python source code, Unicode strings are written as --- 157,162 ---- distribution; it's also available on the Web at \url{http://starship.python.net/crew/lemburg/unicode-proposal.txt}. ! This article will simply cover the most significant points about the Unicode ! interfaces. In Python source code, Unicode strings are written as *************** *** 616,625 **** The comparison \code{a==b} returns true, because the two recursive ! data structures are isomorphic. \footnote{See the thread ``trashcan and PR\#7'' in the April 2000 archives of the python-dev mailing list for the discussion leading up to this implementation, and some useful relevant links. ! %http://www.python.org/pipermail/python-dev/2000-April/004834.html ! } Work has been done on porting Python to 64-bit Windows on the Itanium --- 616,625 ---- The comparison \code{a==b} returns true, because the two recursive ! data structures are isomorphic. See the thread ``trashcan and PR\#7'' in the April 2000 archives of the python-dev mailing list for the discussion leading up to this implementation, and some useful relevant links. ! % Starting URL: ! % http://www.python.org/pipermail/python-dev/2000-April/004834.html Work has been done on porting Python to 64-bit Windows on the Itanium *************** *** 951,955 **** setup (name = "PyXML", version = "0.5.4", ext_modules =[ expat_extension ] ) - \end{verbatim} --- 951,954 ---- *************** *** 967,975 **** Modules}, that joins the basic set of Python documentation. ! % ====================================================================== ! %\section{New XML Code} ! %XXX write this section... % ====================================================================== \section{Module changes} --- 966,1129 ---- Modules}, that joins the basic set of Python documentation. ! ====================================================================== ! \section{XML Modules} ! ! Python 1.5.2 included a simple XML parser in the form of the ! \module{xmllib} module, contributed by Sjoerd Mullender. Since ! 1.5.2's release, two different interfaces for processing XML have ! become common: SAX2 (version 2 of the Simple API for XML) provides an ! event-driven interface with some similarities to \module{xmllib}, and ! the DOM (Document Object Model) provides a tree-based interface, ! transforming an XML document into a tree of nodes that can be ! traversed and modified. Python 2.0 includes a SAX2 interface and a ! stripped-down DOM interface as part of the \module{xml} package. ! Here we will give a brief overview of these new interfaces; consult ! the Python documentation or the source code for complete details. ! The Python XML SIG is also working on improved documentation. ! ! \subsection{SAX2 Support} ! ! SAX defines an event-driven interface for parsing XML. To use SAX, ! you must write a SAX handler class. Handler classes inherit from ! various classes provided by SAX, and override various methods that ! will then be called by the XML parser. For example, the ! \method{startElement} and \method{endElement} methods are called for ! every starting and end tag encountered by the parser, the ! \method{characters()} method is called for every chunk of character ! data, and so forth. ! ! The advantage of the event-driven approach is that that the whole ! document doesn't have to be resident in memory at any one time, which ! matters if you are processing really huge documents. However, writing ! the SAX handler class can get very complicated if you're trying to ! modify the document structure in some elaborate way. ! ! For example, this little example program defines a handler that prints ! a message for every starting and ending tag, and then parses the file ! \file{hamlet.xml} using it: ! ! \begin{verbatim} ! from xml import sax ! ! class SimpleHandler(sax.ContentHandler): ! def startElement(self, name, attrs): ! print 'Start of element:', name, attrs.keys() ! ! def endElement(self, name): ! print 'End of element:', name ! ! # Create a parser object ! parser = sax.make_parser() ! ! # Tell it what handler to use ! handler = SimpleHandler() ! parser.setContentHandler( handler ) ! ! # Parse a file! ! parser.parse( 'hamlet.xml' ) ! \end{verbatim} ! ! For more information, consult the Python documentation, or the XML ! HOWTO at \url{http://www.python.org/doc/howto/xml/}. ! ! \subsection{DOM Support} ! ! The Document Object Model is a tree-based representation for an XML ! document. A top-level \class{Document} instance is the root of the ! tree, and has a single child which is the top-level \class{Element} ! instance. This \class{Element} has children nodes representing ! character data and any sub-elements, which may have further children ! of their own, and so forth. Using the DOM you can traverse the ! resulting tree any way you like, access element and attribute values, ! insert and delete nodes, and convert the tree back into XML. ! ! The DOM is useful for modifying XML documents, because you can create ! a DOM tree, modify it by adding new nodes or rearranging subtrees, and ! then produce a new XML document as output. You can also construct a ! DOM tree manually and convert it to XML, which can be a more flexible ! way of producing XML output than simply writing ! \code{<tag1>}...\code{</tag1>} to a file. ! ! The DOM implementation included with Python lives in the ! \module{xml.dom.minidom} module. It's a lightweight implementation of ! the Level 1 DOM with support for XML namespaces. The ! \function{parse()} and \function{parseString()} convenience ! functions are provided for generating a DOM tree: ! ! \begin{verbatim} ! from xml.dom import minidom ! doc = minidom.parse('hamlet.xml') ! \end{verbatim} ! \code{doc} is a \class{Document} instance. \class{Document}, like all ! the other DOM classes such as \class{Element} and \class{Text}, is a ! subclass of the \class{Node} base class. All the nodes in a DOM tree ! therefore support certain common methods, such as \method{toxml()} ! which returns a string containing the XML representation of the node ! and its children. Each class also has special methods of its own; for ! example, \class{Element} and \class{Document} instances have a method ! to find all child elements with a given tag name. Continuing from the ! previous 2-line example: + \begin{verbatim} + perslist = doc.getElementsByTagName( 'PERSONA' ) + print perslist[0].toxml() + print perslist[1].toxml() + \end{verbatim} + + For the \textit{Hamlet} XML file, the above few lines output: + + \begin{verbatim} + <PERSONA>CLAUDIUS, king of Denmark. </PERSONA> + <PERSONA>HAMLET, son to the late, and nephew to the present king.</PERSONA> + \end{verbatim} + + The root element of the document is available as + \code{doc.documentElement}, and its children can be easily modified + by deleting, adding, or removing nodes: + + \begin{verbatim} + root = doc.documentElement + + # Remove the first child + root.removeChild( root.childNodes[0] ) + + # Move the new first child to the end + root.appendChild( root.childNodes[0] ) + + # Insert the new first child (originally, + # the third child) before the 20th child. + root.insertBefore( root.childNodes[0], root.childNodes[20] ) + \end{verbatim} + + Again, I will refer you to the Python documentation for a complete + listing of the different \class{Node} classes and their various methods. + + \subsection{Relationship to PyXML} + + The XML Special Interest Group has been working on XML-related Python + code for a while. Its code distribution, called PyXML, is available + from the SIG's Web pages at \url{http://www.python.org/sigs/xml-sig/}. + The PyXML distribution also used the package name \samp{xml}. If + you've written programs that used PyXML, you're probably wondering + about its compatibility with the 2.0 \module{xml} package. + + The answer is that Python 2.0's \module{xml} package isn't compatible + with PyXML, but can be made compatible by installing a recent version + PyXML. Many applications can get by with the XML support that is + included with Python 2.0, but more complicated applications will + require that the full PyXML package will be installed. When + installed, PyXML versions 0.6.0 or greater will replace the + \module{xml} package shipped with Python, and will be a strict + superset of the standard package, adding a bunch of additional + features. Some of the additional features in PyXML include: + + \begin{itemize} + \item 4DOM, a full DOM implementation + from FourThought LLC. + \item The xmlproc validating parser, written by Lars Marius Garshol. + \item The \module{sgmlop} parser accelerator module, written by Fredrik Lundh. + \end{itemize} + % ====================================================================== \section{Module changes} *************** *** 982,985 **** --- 1136,1141 ---- and \module{nntplib}. Consult the CVS logs for the exact patch-by-patch details. + + % XXX gettext support Brian Gallew contributed OpenSSL support for the \module{socket} |
|
From: Martin v. L. <lo...@us...> - 2000-10-07 22:17:45
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv16298 Modified Files: xml-howto.tex Log Message: Updated to SAX2, and 4DOM. Index: xml-howto.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/xml-howto.tex,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** xml-howto.tex 1999/12/09 12:58:18 1.7 --- xml-howto.tex 2000/10/07 22:17:42 1.8 *************** *** 6,13 **** \title{Python/XML HOWTO} ! \release{0.06} \author{The Python/XML Special Interest Group} ! \authoraddress{\email{xm...@py...}\break (edited by \email{am...@bi...})} \begin{document} --- 6,13 ---- \title{Python/XML HOWTO} [...1212 lines suppressed...] \end{definitions} \section{Glossary} *************** *** 1250,1255 **** Many of the following definitions are taken from Lars Marius Garshol's ! SGML glossary, at ! \url{http://www.stud.ifi.uio.no/\~larsga/download/diverse/sgmlglos.html}. \begin{definitions} --- 791,795 ---- Many of the following definitions are taken from Lars Marius Garshol's ! SGML glossary, at \url{http://www.stud.ifi.uio.no/\~larsga/download/diverse/sgmlglos.html}. \begin{definitions} |
|
From: A.M. K. <aku...@us...> - 2000-10-06 02:14:13
|
Update of /cvsroot/py-howto/pyhowto In directory slayer.i.sourceforge.net:/tmp/cvs-serv24939 Modified Files: rexec.tex Log Message: Remove comment about needing to use pre in restricted mode, since Fred fixed the problem Index: rexec.tex =================================================================== RCS file: /cvsroot/py-howto/pyhowto/rexec.tex,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** rexec.tex 2000/10/04 12:38:34 1.6 --- rexec.tex 2000/10/06 02:14:08 1.7 *************** *** 148,154 **** allow operations that change the filesystem or use network connections to other machines. (The \code{pcre} module may be unfamiliar. It's ! an internal module used by the \code{pre} module, which is the module ! that should be used by restricted code to perform regular expression ! matches.) It also restricts the variables and functions that are available from --- 148,153 ---- allow operations that change the filesystem or use network connections to other machines. (The \code{pcre} module may be unfamiliar. It's ! an internal module used by the \module{re} module, so restricted code ! can still use the \module{re} to perform regular expression matches.) It also restricts the variables and functions that are available from |
