"Dive Into Python" is a free Python book for experienced programmers.
Chapter 5, "Unit Testing", is now available:
http://diveintopython.org/roman_divein.html
Chapter 5 teaches unit testing with PyUnit (now known as the "unittest"
module, standard in Python 2.1). It goes step by step through the full
lifecycle of a module:
- specifying requirements
- writing test cases
- writing code until all tests pass
- updating tests to handle bugs and new requirements
- refactoring to improve performance
Each step includes full Python source code for both the test cases and the
module being tested, so you can see how the code evolves from a set of
function stubs that fail all test cases to a complete, working, well-tuned
module.
Mark Pilgrim
f8dy(a)diveintopython.org
--
You're smart; why haven't you learned Python yet?
http://diveintopython.org/
pyui
----
pure python user interface library for pygame
Pyui is a user interface library written entirely in the high-level
language python that uses the pygame framework. It is targeted primarily
as a user interface for games but could be applicable to other types of
multimedia applications. Pyui is very portable as the underlying pygame
framework is built on top of the SDL which runs on Linux, Windows, and
Macintosh operating systems.
URL: http://pyui.sourceforge.net
Download: http://prdownloads.sourceforge.net/pyui/pyui_0.3.zip
License: LGPL
Requires: pygame
Categories: GUI
sean riley (sean(a)twistedmatrix.com)
--
<a href="http://pyui.sourceforge.net">pyui</a> -- pure python user
interface library for pygame
I was finally able to get version 0.5 out. Just in case this is the
first time you are seeing this message, or you forgot what PyChecker is:
PyChecker is a tool for finding common bugs in python source code.
It finds problems that are typically caught by a compiler for less
dynamic languages, like C and C++. Because of the dynamic nature
of python, some warnings may be incorrect; however,
spurious warnings should be fairly infrequent.
The highlights are that code at the module scope is now checked.
There is still a problem with class variables and globals that are default
parameter values. But other than that, there should be no more spurious
Variable unused warnings.
Code that makes PyChecker raise an exception should now be caught in most
cases and this produces a warning. Please mail me if you find it blowing
up on your code. The last line processed is shown in the warning, so
if you include some context, I can hopefully fix the problem.
Also, PyChecker should really use the files passed on the command line,
even if it uses the same module name internally. So it will check your
warn.py, not PyChecker's warn.py.
Feedback, comments, criticisms, new ideas, better ideas, etc. are all
greatly appreciated. Thanks for everyone who has taken the time to mail me.
If you can think of common mistakes that are made that PyChecker doesn't
find, please let me know.
Here's the CHANGELOG:
* Catch internal errors "gracefully" and turn into a warning
* Add checking of most module scoped code
* Add pychecker subdir to imports to prevent filename conflicts
* Don't produce unused local variable warning if variable name == '_'
* Add -g/--allglobals option to report all global warnings, not just first
* Add -V/--varlist option to selectively ignore variable not used warnings
* Add test script and expected results
* Print all instructions when using debug (-d/--debug)
* Overhaul internal stack handling so we can look for more problems
* Fix glob'ing problems (all args after glob were ignored)
* Fix spurious Base class __init__ not called
* Fix exception on code like: ['xxx'].index('xxx')
* Fix exception on code like: func(kw=(a < b))
* Fix line numbers for import statements
PyChecker is available on Source Forge:
Web page: http://pychecker.sourceforge.net/
Project page: http://sourceforge.net/projects/pychecker/
Neal
--
pychecker(a)metaslash.com
GypsyMail 0.6.0 beta
--------------------
A Form Mail cgi script
A Python clone of the well-known cgiemail script, with added features
and flexibility. This script allows you to set up an HTML form on your
website, to collect information from your site's visitors, and send a
very nicely formatted e-mail to yourself, or other e-mail addresses.
Comes with sample forms and templates. Cross-platform. Under continuing
development. I am looking for testers for this script.
URL:
http://www.thinkspot.net/sheila/computers/software/gypsymail.html
Download:
http://www.thinkspot.net/sheila/computers/software/gypsy/gypsy060.tar.gz
or
http://www.thinkspot.net/sheila/computers/software/gypsy/gypsy060.zip
License: GPL
Categories: CGI Scripts
NEW in version 0.6.0 (from the change log):
version 0.6.0 beta - 2000.5.28
-Wrote an html document file instead of the help.txt file. Much
more extensive documentation.
-Changed the way that a field is exempted from a check for
headers inserted by a hacker. Removed the previous noverify tag
from the form field names. Now this is handled by putting an
additional line in the config file of the form
values-FormFieldName = <list>.
-Added a confirm- option. Now two fields can both check for the
same data and verify that the input matches (such as for
confirming passwords, and the like).
-Check for CRLF characters in the message body text and replaced
them with LF characters, to prevent double line spacing in some
situations.
-Moved most configuration information from the main gypsymail.py
file to a separate configuration file. This allows for the main
script to run different forms with different configuration
options.
-Moved many of the functions used by the main script to a
separate file, gypsyutils.py.
Sheila King
http://www.thinkspot.net/sheila/
--
Sheila King
http://www.thinkspot.net/sheila/http://www.k12groups.org/
Jext is a free sofware (GNU/GPL) meant to become a flexible,
multi-platform programming editor. Jext is written in Java and the latest
development release (available on www.jext.org) provides serveral
interesting features for Pyhon development:
- auto indent
- syntax colorization
- internal console
- embedded Jython (press F5 to execute current editing script)
- Python class browser (written in Python)
Jext is being partially rewritten using Python. For instance, almost all
the menu item are Python driven. This tool also offers several generic
features which will still help you in Python coding:
- word completion
- abreviation expansion (typing: ei then ESC may expand to if : elif:
for instance)
- workspaces
- and all the kind of editing functions you may need (comment,
uncomment, etc...)
Hope you'll like it :-))
Romain "Java Swinguer !" Guy
romain.guy(a)jext.org
www.jext.org
"Now, don't you worry. The saucers are up there. The graveyard is out there.
But I'll be locked up safely in there."
- Paula Trent, Plan 9 From Outer Space
PyX
---
Proposal (in the making) for a versatile Python structured text standard
PyX is an attempt -- currently in its inceptive phase -- to formulate a
standard for structured textual data that may be applied to docstrings,
hierarchical configuration files and classical documents alike. PyX aims
to provide a grammar and tools to transform documents from the source
via intermediate representations as Python instance attributes, mappings
or lists to output formats such as XML, HTML, and plain text.
This is *alpha*. Please do not hesitate to send any comments, share
thoughts, provide critique. Also, because of the early stage this thing
is in, even the web page is hard to read, never mind the obfuscated
sources. So again, please drop me a line if you're interested.
Installation procedures to be provided.
URL: http://home.snafu.de/castor/projects/pyx/
Download: http://home.snafu.de/castor/projects/downloads/
License: not yet defined
Requires: pylon (downloadable from http://home.snafu.de/castor/projects/downloads/)
Categories: Parsing/Formatting, Structured Data Processing
Wolfgang Lipp (lipp(a)epost.de)
http://home.snafu.de/castor/projects/
--
<a href="http://home.snafu.de/castor/projects/pyx/">PyX</a> -- Proposal
(in the making) for a versatile Python structured text standard
crystal / pre-1
---------------
Crystal is a server that controls CrystalFontz 632 and 634 LCD screens
Crystal is a simple TCP server that uses a plaintext protocol to control
CrystalFontz[1] 632 and 634 series LCD screens (e.g. out 'hello world').
The pre-1 version of Crystal supports many of the functions defined in
Ben Wilson's pyCFontz[2] module, upon which crystal is based, including
most major text entry, cursor movement, backlight control, and
formatting functions. Future versions will allow multiple simultaneous
connections, and implement the full set of control functions. The server
will eventually support advanced functionality like multiple LCD
support, screen region locking by client programs, and display
templates.
Comments, code contributions, and suggestions for further development
are welcomed, and may be emailed to rupe(a)metro.yak.net.
URL: http://metro.yak.net/crystal.html
Download: http://metro.yak.net/crystal-pre1.py
License: Public Domain
Requires: pyCFontz (LGPL)
Categories: Servers
Rupert Scammell
--
<a href="http://metro.yak.net/crystal.html">crystal / pre-1</a> --
Crystal is a server that controls CrystalFontz 632 and 634 LCD screens
wxPython 2.3.0 is now available for download. Unfortunately the shell
server at sourceforge is down for a few days and so I can't update the
wxPython.org web page, but in the meantime you can get the files directly
from
http://sourceforge.net/project/showfiles.php?group_id=10718.
Sources and binaries for win32 and Linux for Python 1.5.2, 2.0 and 2.1 are
available. (The win32 binaries with "-hybrid" in the name are built with
extra debugging code enabled so some things that caused mysterious problems
before will now pop-up a slightly less mysterious message dialog.)
There have been a large number of changes for this release. I'll include
the relevant portion of CHANGES.txt here:
Removed initial startup dependency on the OpenGL DLLs so only the
glcanvasc.pyd depends on them, (on wxMSW.)
Changed wxFont, wxPen, wxBrush to not implicitly use the
wxThe[Font|Pen|Brush]List objects behind the scenes, but to use normal
ctor and dtors.
Exposed the wxThe[Font|Pen|Brush]List to wxPython.
Also added wxTheColourDatabase and added a library module (in the
wxPython.lib.colourdb module) to load LOTS more colour names into the
colour database.
Added wxWakeUpMainThread, wxMutexGuiEnter, wxMutexGuiLeave,
wxMutexGuiLocker and wxThread_IsMain to assist with dealing with GUI
access from non-GUI threads.
wxPyOnDemandOutputWindow is now (more) thread safe if non-GUI threads
use print, sys.stdout.write, etc.
Added CreateTextSizer and CreateButtonSizer to wxDialog
Added wxPython/lib/infoframe.py from Chris Fama. It contains a class
that can be used in place of wxPyOnDemandOutputWindow.
Added colourselect.py, imagebrowser.py and an updated calendar.py to
wxPython/lib from Lorne White.
Added patch to wxPoint_LIST_helper from Tim Hochberg that should make
it gobs faster in certain situations.
Added tools that will take an image file in a wx supported format and
convert it to data embedded in a Python source file. The image is
converted to XPM format which is essentially a list of strings
containing info about each pixel. The image's transparency mask is
included, if there is one, or a mask can be added if a mask colour is
specified on the command line. It is then pickled and optionally
compressed and written to a Python source file along with functions to
convert it to either a wxBitmap or a wxImage. See
wxPython/demo/images.py for examples, and wxPython/Tools/img2py.py for
the implementation.
Fixed wxStyledTextCtrl to be much faster on wxGTK. There was some
experimental code that got left in place that ended up causing way too
many refreshes.
A couple more hacks in my_distutils.py so wxPython can be built with
the distutils that comes with Python 2.1.
Added a ton of missing methods for wxPrintData.
Switched to InnoSetup for MSW distributions.
Added wxToggleButton.
Fixed bug that prevented wxTreeCtrl.OnCompareItems from being called.
Added some methods to wxGrid:
GetCellHighlightPenWidth
GetCellHighlightROPenWidth
SetCellHighlightPenWidth
SetCellHighlightROPenWidth
GetGridWindow
GetGridRowLabelWindow
GetGridColLabelWindow
GetGridCornerLabelWindow
Added wxGetClientDisplayRect which on wxMSW returns a wxRect
representing the area on screen not occupied by the taskbar and such.
On other platforms it is equivallent to wxGetDisplaySize.
***---***---***---***---***---***---***---***---***---***---***---
Implemented the first phase of OOR (Original Object Return). See
the text in the demo for more details of what this means, but in a
nutshell methods such as wxWindow.GetParent or FindWindowById will
now return a shadow object of the proper type if it can. By
"proper type" I mean that if the wxWindow pointer returned from
FindWindowById really points to a wxButton then the Python object
constructed will be of a wxButtonPtr class instead of wxWindowPtr
as before. This should reduce or eliminiate the need for
wxPyTypeCast. (Woo Hoo!) The objects returned are still not the
original Python object, but that is the next step. (Although it
will probably only work on Python 2.1 and beyond because it will
use weak references.)
This first phase of the OOR plan is fairly significant and has
required a lot of changes all over wxPython, most of which should
be transparent to you, however I'm not 100% sure that it didn't
introduce any new bugs that are hiding somewhere and didn't get
stomped on during my testing. So please be sure to test everything
thoroughly when you install this version and be sure to report any
object-type related oddities to me.
***---***---***---***---***---***---***---***---***---***---***---
There is now a wxObject class that most other classes derive from like
in C++, but the methods provided don't really match but are wxPython
specific. It could have been added long ago but OOR required it so
it finally got done.
Finally added wxPyLineShape.GetLineControlPoints, which has been on my
list for a while. The above OOR modification made this easier.
Fixed the __cmp__ methods for wxPoint and others.
Added wxWave.
Added the wxPython.lib.mixins package to the library, it is where
useful mix-in classes can be placed. Currently there is one to help
make the columns in a wxListCtrl sortable, and the MagicIMageList
from Mike Fletcher. If you have any custom code that can be factored
out of existing classes into a mix-in that would be useful to others
please send it to me for inclusion in this package.
Added a few little sample applications to help newbies to get started
by having smaller functional apps to play with. They can be found in
wxPython/samples.
--
Robin Dunn
Software Craftsman
robin(a)AllDunn.com Java give you jitters?
http://wxPython.org Relax with wxPython!
pyhz 0.3.2
----------
python binding for libhz in autoconvert (A program to detect and convert
Chinese encodings)
pyhz is a python binding for libhz in autoconvert. Autoconvert is a
program/library written by Saka to detect and convert Chinese encodings.
Autoconvert can be found at http://www.debian.org/~ygh
URL: http://pyhz.on.openave.net
Download: http://pyhz.on.openave.net/data/pyhz.3.2.tar.bz2
License: GPL
Platform: tested on linux
Requires: autoconvert
Categories: Encryption/Encoding, Chinese tools
hashao
--
<a href="http://pyhz.on.openave.net">pyhz 0.3.2</a> -- python binding
for libhz in autoconvert (A program to detect and convert Chinese
encodings)
This is a summary of traffic on the python-dev mailing list between
May 10 and May 24 (inclusive) 2001. It is intended to inform the
wider Python community of ongoing developments. To comment, just
post to python-list(a)python.org or comp.lang.python in the usual
way. Give your posting a meaningful subject line, and if it's about a
PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep
iteration) All python-dev members are interested in seeing ideas
discussed by the community, so don't hesitate to take a stance on a
PEP if you have an opinion.
This is the eighth summary written by Michael Hudson.
Summaries are archived at:
<http://starship.python.net/crew/mwh/summaries/>
Posting distribution (with apologies to mbm)
Number of articles in summary: 322
| [|]
| [|]
30 | [|]
| [|] [|] [|] [|]
| [|] [|] [|] [|]
| [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|]
20 | [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
10 | [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
| [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|] [|]
0 +-023-025-017-018-028-031-036-032-025-002-015-018-020-032
Thu 10| Sat 12| Mon 14| Wed 16| Fri 18| Sun 20| Tue 22|
Fri 11 Sun 13 Tue 15 Thu 17 Sat 19 Mon 21 Wed 23
Pretty busy fortnight. The above distribution may be somewhat skewed
because I changed my subscription address to python-dev and was
unsubscribed for a while. Although any impact this had is probably
countered by ESR and Barry's discussion of "Puffy the Frog"...
* Type/class *
Paul Prescod has been keeping an eye on Guido's descr-branch work,
and posted concerns about when objects will have a __dict__:
<http://mail.python.org/pipermail/python-dev/2001-May/014694.html>
Then there was more technical discussion about subclassing builtin
types and Steven Majewski evangelising prototype-based OO languages
(though I'm not sure why!).
* Easy codec access *
Marc-Andre Lemburg checked in his decode string method patch, and
some new codecs so you can now do things like:
>>> "abc".encode('zlib').encode('base64')
'eJxLTEoGAAJNASc=\n'
>>> _.decode('base64').decode('zlib')
'abc'
There was a small discussion on what other codecs might be handy and
Guido added quoted-printable to check it was easy.
* Performance *
The big discussion(s) on python-dev over the past fourteen days has
centred on performance, especially on that of comparisons and the
related area of dict performance. It all started with Tim Peters
running a simple test program on 2.0, 2.1 and current CVS:
<http://mail.python.org/pipermail/python-dev/2001-May/014781.html>
The discussion had an unusual <wink> flavour for one about
performance: a concentration on measuring performance numbers and
making sure that the optimizations being discussed actually improved
these numbers. This is hard; everyone wants to speed the "typical
Python app" but of course there is no such thing; people have been
using, amongst others, pystone, pybench and the test suite, none of
which are particularly good candidates...
Tim posted the distribution of sizes of dicts in a run of the test
suite:
<http://mail.python.org/pipermail/python-dev/2001-May/014890.html>
which showed that small dicts are overwhelmingly the commonest. Marc
piped up with an old optimization idea of his:
<http://mail.python.org/pipermail/python-dev/2001-May/014891.html>
He posted a patch to sourceforge, Tim rewrote it and checked it in,
so dicts should be a little faster in 2.2.
But as I said, the discussion was kicked off by the performance of
comparisons, especially strings. Martin von Loewis posted some
statistics from an instrumented interpreter:
<http://mail.python.org/pipermail/python-dev/2001-May/014808.html>
The issue is that the rich comparisons of Python 2.1 have added a
layer of complexity to the comparisons code. Although the rich
comparisons (might) provide an opportunity for faster code in some
circumstances, code that still uses old-style comparisons can and
does take a hit. Strings still use the old-style comparisons and are
compared a *lot* (especially in dicts), so it seems "upgrading" them
to rich comparisons should be a win and Marc posted a patch to sf
that does this.
Marc also managed to promise <wink> to make a concerted effort to
find speed optimizations in the next few months:
<http://mail.python.org/pipermail/python-dev/2001-May/014928.html>
Finally, in a coda Jeremy noticed that Python spends an alarming
amount of time decoding those "Oi|s#" strings that get passed to
PyArg_ParseTuple:
<http://mail.python.org/pipermail/python-dev/2001-May/014911.html>
and Tim pointed out that optimizing "O" might be a win:
<http://mail.python.org/pipermail/python-dev/2001-May/014924.html>
* FP vs. tutorial *
Tim pointed out that the tutorial currently contains examples of
floating point output that is platform dependent, and that this is
bad. He proposed changing the tutorial to only use fractions that
can be exactly represented as floats, and adding a discussion
(possibly in an appendix) of the reasons why
>>> 0.1
0.10000000000000001
is not broken. There was a discussion of how detailed the discussion
should be where the point was made that it's not really important to
explain precisely *why* this happens, but it suffices to convince the
newbie that floating point is more complicated than he or she thinks.
Lets hope that suitable text is composed soon, and that people
actually read it ... there have been two "floating point is broken"
bug reports on sourceforge in just the last week.
* unifying os.rename semantics across platforms *
Skip pointed out that os.rename behaves differently on Posix and
Windows platforms when the destination file exists:
<http://mail.python.org/pipermail/python-dev/2001-May/014957.html>
on Posix the destination is silently replaced in an atomic operation,
whereas on Windows an exception is raised. Skip proposed enforcing
posix semantics everywhere, but this has two problems (a) it's
backwards incompatible (b) it's impossible (you can't avoid the race
condition on Windows). So maybe we'll just settle for better
documentation.
* Python 2.1.1 *
Thomas Wouters started back-porting bug fixes to the 2,1-maint branch
in preparation for a 2.1.1 release. There is as yet no firm - or
even vague - plans about release dates.
* Daily Python-URL on your Palm *
Marc-Andre Lemburg announced that you can now read Pythonware's Daily
Python-URL on your Palm Pilot as an AvantGo channel:
<http://mail.python.org/pipermail/python-dev/2001-May/014983.html>
Cheers,
M.
