Mailman 3 May 2001 - Python-announce-list

ANN: Dive Into Python chapter 5 released
by Mark Pilgrim May 31, 2001

May 31, 2001

"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/

1 0

[Module] pyui
by sean riley May 30, 2001

May 30, 2001

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

1 0

PyChecker v0.5 released
by Neal Norwitz May 30, 2001

May 30, 2001

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

1 0

[Application] Update: GypsyMail 0.6.0 beta
by Sheila King May 30, 2001

May 30, 2001

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/

1 0

New IDE for Python
by Romain Guy May 29, 2001

May 29, 2001

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

1 0

[Module] PyX
by Wolfgang Lipp May 28, 2001

May 28, 2001

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

1 0

[Application] crystal / pre-1
by Parnassus Submission May 25, 2001

May 25, 2001

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

1 0

[ANNOUNCE] wxPython 2.3.0
by Robin Dunn May 25, 2001

May 25, 2001

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!

1 0

[Wrapper] pyhz 0.3.2
by Parnassus Submission May 25, 2001

May 25, 2001

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)

1 0

python-dev summary 2001-05-10 - 2001-05-24
by Michael Hudson May 24, 2001

May 24, 2001

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.

1 0