Mailman 3 January 2006 - Python-announce-list

Dr. Dobb's Python-URL! - weekly Python news and links (Jan 23)
by Magnus Lycka Jan. 23, 2006

Jan. 23, 2006

QOTW: "The IEEE-754 standard doesn't wholly define output conversions, and explicitly allows that a conforming implementation may produce any digits whatsoever at and after the 18th signficant digit, when converting a 754 double to string. In practice, all implementations I know of that exploit that produce zeroes at and after the 18th digit -- but they could produce 1s instead, or 9s, or digits from pi, or repetitions of the gross national product of Finland in 1967." - Tim Peters "If you can't do a first version in six months with a team of six people it is a sign that you don't really know what you want." - Jack Diederich Besides the layout for the new Python web site, work on converting the content from the current site has begun: http://groups.google.se/group/comp.lang.python/browse_frm/thread/330af3b245… There has been interest in Sudoku solvers on comp.lang.python lately: http://groups.google.se/group/comp.lang.python/search?q=sudoku&start=0&scor… Don't expect to use the ConfigParser for non-text data. Use ConfigObj instead when that's what you need: http://groups.google.se/group/comp.lang.python/browse_frm/thread/3b5f75051b… How do you use Python without installing it on your computer? http://groups.google.se/group/comp.lang.python/browse_frm/thread/8ed65089a7… Should a web development framework be included in the standard library? http://groups.google.se/group/comp.lang.python/browse_frm/thread/d3e9bd6d00… Claudio Grondi tries to grok Python by asking questions that seem to confuse those who try to answer: http://groups.google.se/group/comp.lang.python/browse_frm/thread/b6515a4574… No, regular expressions aren't supposed to be gargantuan, but there should really be a proper exception when they are: http://groups.google.se/group/comp.lang.python/browse_frm/thread/64df1dd720… This is neither the first nor the last week, when someone asks questions related to a mismatch between binary floats and decimal numbers: http://groups.google.se/group/comp.lang.python/browse_frm/thread/fe07673b9f… How do we generate graphics dynamically with Python CGI scripts? http://groups.google.se/group/comp.lang.python/browse_frm/thread/8179735820… A PHP programmer is making efforts to figure out Python, in particular with regards to threads, databases and modularity. (Welcome Robin!) http://groups.google.se/group/comp.lang.python/browse_frm/thread/bf75a37e92… http://groups.google.se/group/comp.lang.python/browse_frm/thread/2055bab118… Numarray, Numeric, NumPy... There should be one--and preferably only one--obvious way to do it. So, which is it? http://groups.google.se/group/comp.lang.python/browse_frm/thread/2a308411c3… ======================================================================== Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. For far, FAR more Python reading than any one mind should absorb, much of it quite interesting, several pages index much of the universe of Pybloggers. http://lowlife.jp/cgi-bin/moin.cgi/PythonProgrammersWeblog http://www.planetpython.org/ http://mechanicalcat.net/pyblagg.html comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Steve Bethard, Tim Lesher, and Tony Meyer continue the marvelous tradition early borne by Andrew Kuchling, Michael Hudson and Brett Cannon of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Kurt B. Kaiser publishes a weekly report on faults and patches. http://www.google.com/groups?as_usubject=weekly%20python%20patch Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://python.sourceforge.net/peps/pep-0042.html The online Python Journal is posted at pythonjournal.cognizor.com. editor(a)pythonjournal.com and editor(a)pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work. del.icio.us presents an intriguing approach to reference commentary. It already aggregates quite a bit of Python intelligence. http://del.icio.us/tag/python *Py: the Journal of the Python Language* http://www.pyzine.com Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.pyth… Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topic/python/ (requires subscription) http://groups-beta.google.com/groups?q=python-url+group:comp.lang.python*&s… http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lan… There is *not* an RSS for "Python-URL!"--at least not yet. Arguments for and against are occasionally entertained. Suggestions/corrections for next week's posting are always welcome. E-mail to <Python-URL(a)phaseit.net> should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask <claird(a)phaseit.net> to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project.

1 0

mrquery find duplicate images
by Edward C. Jones Jan. 23, 2006

Jan. 23, 2006

I have uploaded a new version of "mrquery" to my webpage at "http://members.tripod.com/~edcjones/pycode.html". It is no longer importing a non-existent module. ---- "mrquery" checks collections of images for duplicates. To install, expand the tarball in your PYTHONPATH and compile a pair of C programs. To create a new set of image data: ../mrq.py animals new /pics/animals To update data: ../mrq.py animals update The output is a set of html files you can display on your browser.

1 0

ANN: MoinMoin 1.5.1 (advanced wiki engine) released
by Alexander Schremmer Jan. 22, 2006

Jan. 22, 2006

_ _ /\/\ ___ (_)_ __ /\/\ ___ (_)_ __ / \ / _ \| | '_ \ / \ / _ \| | '_ \ __ / /\/\ \ (_) | | | | / /\/\ \ (_) | | | | | /| |_ \/ \/\___/|_|_| |_\/ \/\___/|_|_| |_| |.__) ============================================== MoinMoin 1.5.1 advanced wiki engine released ============================================== MoinMoin is an easy to use, full-featured and extensible wiki software package written in Python. It can fulfill a wide range of roles, such as a personal notes organizer deployed on a laptop or home web server, a company knowledge base deployed on an intranet, or an Internet server open to individuals sharing the same interests, goals or projects. A wiki is a collaborative hypertext environment with an emphasis on easy manipulation of information. MoinMoin 1.5.1 is a bug fix release. It mainly addresses the issues that slipped through the 1.5 release cycle. The 1.5 branch brings you several new features such as the GUI editor, which allows the users to edit pages in a WYSIWYG environment, and many bug fixes. The download page: http://moinmoin.wikiwikiweb.de/MoinMoinDownload Major bug fixes in 1.5.1 ======================== * A race condition in the code, that conflicted with a broken copy.py in the std lib, was worked around in order to avoid DeepCopyErrors. * Unzipping was broken in 1.5.0. * Fixed the docutils version check. * Fixed a few Internet Explorer issues. Major new features in 1.5 ========================= * The WYSIWYG editor for wiki pages allows you to edit pages without touching the markup. Furthermore, the wiki page is not stored as HTML after editing but kept as wiki markup in order to simplify the editing process for users that cannot or do not want to use the new editor. * AutoAdmin security policy allows users to gain admin permissions on particular pages. * The new authentication system allows to add short methods that check the credentials of the user. This allowed us to add eGroupware single sign on support. * Separation of homepages into a separate wiki (in a farm) and having a single user database is supported. * A DeSpam action to allow mass-reverting of spam attacks. * PackageInstaller support for simplified installation of plugins, themes and page bundles. This enables you to decide in which languages help pages should be installed. Note that Python 2.3.0 or newer is required. For a more detailed list of changes, see the CHANGES file in the distribution or http://moinmoin.wikiwikiweb.de/MoinMoinRelease1.5/CHANGES MoinMoin History ================ MoinMoin has been around since year 2000. The codebase was initally started by Jürgen Hermann; it is currently being developed by a growing team. Being originally based on PikiPiki, it has evolved heavily since then (PikiPiki and MoinMoin 0.1 consisted of just one file!). Many large enterprises have been using MoinMoin as a key tool of their intranet, some even use it for their public web page. A large number of Open Source projects use MoinMoin for communication and documentation. Of course there are also many private installations. More Information ================ * Project site: http://moinmoin.wikiwikiweb.de/ * Feature list: http://moinmoin.wikiwikiweb.de/MoinMoinFeatures * Download: http://moinmoin.wikiwikiweb.de/MoinMoinDownload * DesktopEdition: http://moinmoin.wikiwikiweb.de/DesktopEdition * This software is available under the GNU General Public License v2. * Changes: http://moinmoin.wikiwikiweb.de/MoinMoinRelease1.5/CHANGES * Known bugs: * http://moinmoin.wikiwikiweb.de/KnownIssues * http://moinmoin.wikiwikiweb.de/MoinMoinBugs sent by Alexander Schremmer for the MoinMoin team

1 0

ANN: pyFltk-1.1RC2
by a.held＠computer.org Jan. 21, 2006

Jan. 21, 2006

This is to announce the second release candidate for pyFltk-1.1, then Python bindings for the cross platform GUI toolkit fltk-1.1 This release candidate has been tested with fltk-1.1.6 and fltk-1.1.7 and requires Python2.4. pyFltk and fltk is a lighweight, easy-to-use GUI toolkit for Python. It can be used where simplicity, small footprint, and ease-of-use are important. Changes: * Now it is possible to extend all widgets in Python * Fl_Preferences has been added. * Various bug fixes A source distribution and a Windows installer (including fltk) can be downloaded from htpp://pyfltk.sourceforge.net. Regards Andreas Held http://pyfltk.sourceforge.net

1 0

Ann: FarPy GUIE v0.4
by dberlin＠gmail.com Jan. 21, 2006

Jan. 21, 2006

GUIE (GUI Editor) provides a simple WYSIWYG GUI editor for wx. The program was made in C# and saves the GUI that was created to a XML format I called GUIML. This GUIML is a pretty standard representation of the GUI created with the program. Next, GUIE takes these GUIML files and translates it to wxPython Python code. You may ask yourself why I took the extra step? Why didn't I go straight from C# controls to wxPython code? Why is GUIML necessary? Well, it isn't. It is there simply for people (or maybe I) to take the GUIML and convert it to other languages. This, by effect can convert this tool from a Python GUI editor, to "any programming language with a GUI module" GUI editor. http://farpy.holev.com Changes (as of v0.4) Added: wxRuby support! Fixed: Minor bugs More languages to come!

1 0

ANN: Veusz 0.9, a scientific plotting package
by Jeremy Sanders Jan. 20, 2006

Jan. 20, 2006

Veusz 0.9 --------- Velvet Ember Under Sky Zenith ----------------------------- http://home.gna.org/veusz/ Veusz is Copyright (C) 2003-2006 Jeremy Sanders <jeremy(a)jeremysanders.net> Licenced under the GPL (version 2 or greater) Veusz is a scientific plotting package written in Python. It uses PyQt for display and user-interfaces, and numarray for handling the numeric data. Veusz is designed to produce publication-ready Postscript output. Veusz provides a GUI, command line and scripting interface (based on Python) to its plotting facilities. The plots are built using an object-based system to provide a consistent interface. Changes from 0.8: Please refer to ChangeLog for all the changes. Highlights include: * Contour support (thanks to the code of the matplotlib guys!) * Undo/redo * Rubber band axis zooming * More flexible data importing Features of package: * X-Y plots (with errorbars) * Contour plots * Images (with colour mappings) * Stepped plots (for histograms) * Line plots * Function plots * Fitting functions to data * Stacked plots and arrays of plots * Plot keys * Plot labels * LaTeX-like formatting for text * EPS output * Simple data importing * Scripting interface * Save/Load plots * Dataset manipulation * Embed Veusz within other programs To be done: * UI improvements * Import filters (for qdp and other plotting packages, fits, csv) Requirements: Python (probably 2.3 or greater required) http://www.python.org/ Qt 3 (free edition) http://www.trolltech.com/products/qt/ PyQt 3 (SIP is required to be installed first) http://www.riverbankcomputing.co.uk/pyqt/ http://www.riverbankcomputing.co.uk/sip/ numarray http://www.stsci.edu/resources/software_hardware/numarray Microsoft Core Fonts (recommended) http://corefonts.sourceforge.net/ PyFITS (optional) http://www.stsci.edu/resources/software_hardware/pyfits For documentation on using Veusz, see the "Documents" directory. The manual is in pdf, html and text format (generated from docbook). If you enjoy using Veusz, I would love to hear from you. Please join the mailing lists at https://gna.org/mail/?group=veusz Cheers Jeremy -- Jeremy Sanders http://www.jeremysanders.net/

1 0

python-dev Summary for 2005-12-16 through 2005-12-31
by Tony Meyer Jan. 20, 2006

Jan. 20, 2006

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-12-16_2005-12-31.html] ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Python-dev is in love with Python, though sometimes too much, Fredrik Lundh contends: ...in reality, some things are carefully thought out and craftily implemented, some things are engineering tradeoffs made at a certain time, and some things are just accidents -- but python-dev will happily defend the current solution with the same energy, no matter what it is. Contributing thread: - `a quit that actually quits <http://mail.python.org/pipermail/python-dev/2005-December/059283.html>`__ [SJB] ------------------------------------------------------- Reminder: plain text documentation patches are accepted ------------------------------------------------------- Want to help out with the Python documentation? Don't know LaTeX? No problem! Plain text or ReST fixes are also welcome. You won't be able to produce a diff file like with a normal patch, but comments that explain how to fix the docs are just as good. A form like "in section XXX right before the paragraph starting with YYY, the documentation should say ZZZ" will make it easy for the doc maintainers to apply your fix. Contributing thread: - `LaTeX and Python doc contributions <http://mail.python.org/pipermail/python-dev/2005-December/059001.html>`__ [SJB] --------------------------------------------------------------- PyPy Sprint: Palma de Mallorca (Spain) 23rd - 29th January 2006 --------------------------------------------------------------- The next PyPy_ sprint is scheduled to take place from the 23rd to the 29th of January 2006 in Palma De Mallorca, Balearic Isles, Spain. There will be newcomer-friendly introductions and the focus will mainly be on current JIT work, garbage collection, alternative threading models, logic programming and on improving the interface with external functions. .. _PyPy: http://codespeak.net/pypy Contributing thread: - `Next PyPy Sprint: Palma de Mallorca (Spain) 23rd - 29th January 2006 <http://mail.python.org/pipermail/python-dev/2005-December/058975.html>`__ [TAM] -------------------------------------------------- SHA-224, -256, -384 and -512 support in Python 2.5 -------------------------------------------------- Ronald L. Rivest asked about the cryptographic hash function support in Python, now that md5 and sha1 are broken in terms of collision-resistance. The new-in-Python-2.5 hashlib module was pointed out (and somewhat belatedly added to the NEWS file), which includes new implementations for SHA-224, -256, -384 and -512 (these, including tests, are already in SVN). Gregory P. Smith noted that although the code isn't currently available for earlier versions of Python, he does plan to release a standalone package for Python 2.3 and Python 2.4, when time permits. Contributing thread: - `hashlib - faster md5/sha, adds sha256/512 support <http://mail.python.org/pipermail/python-dev/2005-December/058850.html>`__ [TAM] ========= Summaries ========= ----------------------------------- Improving the documentation process ----------------------------------- Fredrik Lundh asked about automatically updating the development docs, so that users wouldn't be required to have a latex toolchain installed to get an HTML version of the current docs. This spawned a long discussion about using something other than LaTeX (e.g. microformats_ or ReST_) for markup. Though HTML has the advantage that many Python users are already familiar with it, a number of people voiced concerns about the ease of reading and writing it. ReST is generally easy to read and write, but some people suggested that for complicated structured text (like Python function and class definitions) it was no better than LaTeX. Fredrik Lundh presented some example code side-by-side_ and argued that using HTML with something like PythonDoc_ could better represent the documentation's intent. He also produced an initial conversion_ of the Python docs to this format. Fredrik also pointed out that currently the doc patch submission procedure is rather tedious, and listed_ the rather large number of steps required for end-users and developers to get their documentation fixes added to the current Python docs. He claimed that a simple wiki, discussion board, or "user edit" mechanism like that of roundup_, combined with automated updates of the documentation from the Python SVN trunk, could reduce this procedure to two or three simple steps. As a partial effort towards this goal, Trent Mick started posting `daily builds`_ of the Python HTML. This prompted Neal Norwitz to set up the docs server in a similar manner so that it now produces development documentation builds twice daily at http://docs.python.org/dev/. .. _microformats: http://microformats.org/wiki/microformats .. _side-by-side: http://mail.python.org/pipermail/python-dev/2005-December/059022.html .. _PythonDoc: http://effbot.org/zone/pythondoc.htm .. _conversion: http://effbot.org/zone/pythondoc-lib.htm .. _listed: http://mail.python.org/pipermail/python-dev/2005-December/059311.html .. _roundup: http://roundup.sourceforge.net .. _daily builds: http://trentm.com/python/ Contributing threads: - `status of development documentation <http://mail.python.org/pipermail/python-dev/2005-December/058910.html>`__ - `documentation comments <http://mail.python.org/pipermail/python-dev/2005-December/058991.html>`__ - `[Doc-SIG] status of development documentation <http://mail.python.org/pipermail/python-dev/2005-December/058999.html>`__ - `reST limitations? (was Re: status of development documentation) <http://mail.python.org/pipermail/python-dev/2005-December/059016.html>`__ - `that library reference, again <http://mail.python.org/pipermail/python-dev/2005-December/059087.html>`__ - `[Doc-SIG] that library reference, again <http://mail.python.org/pipermail/python-dev/2005-December/059294.html>`__ [SJB] -------------------------------------- Making quit and exit more command-like -------------------------------------- Fredrik Lundh kicked off a surprisingly long thread when he proposed that typing "quit" or "exit" in the interactive prompt actually exit (i.e. raises SystemExit) rather than printing a message informing the user how they can exit, to avoid the "if you knew what I wanted, why didn't you just do it?" situation. His proposal was to install a custom excepthook that looks for the appropriate NameErrors at the top level (in interactive mode only). Early discussion revolved around the implementation. Skip Montanaro worried that multiple code sources wanting to change sys.excepthook would step on one another's toes; Fredrik felt that if you add your own excepthook, you take responsibility. Martin was also concerned about this; although Fredrik believed that the change was so early that no code would try to add a hook prior to this, Martin suggested that the code stand as an example of good practice and pass execution on to any existing excepthook (if the command wasn't "exit" or "quit"). Reinhold Birkenfeld suggested that exit and quit could be instances of a class whose repr() raises SystemExit; however, this would cause an exit to be incorrectly performed whenever the exit or quit objects were examined (e.g. calling vars()). Reinhold suggested a variation where the SystemExit would only be raised if sys._getframe(1).f_code.co_names was "exit" or "quit"). Having quit and exit be functions (i.e. one would type "exit()" to exit) was also suggested, with a plain "exit" printing a help message (as today). However, while this shortens the platform-independent method of exiting ("raise SystemExit") to "exit()", it does nothing to address the "why didn't you just do it?" problem. Ka-Ping Yee was concerned that Fredrik's implementation would cause an exit in surprising situations, such as :: print exit # seems surprising [3, 4, 5, exit] # seems surprising 'a' in 'xyz' or exit # desirable or undesirable? del exit # actually happened to me x = exit # seems surprising And that Reinhold's modified proposal would do likewise:: print exit # seems surprising [3, 4, 5, exit] # seems surprising 'a' in 'xyz' or exit # desirable or undesirable? def foo(): print exit foo() # seems surprising As such, Fredrik proposed adding a new sys attribute that contains the most recent interpreter line, which could be examined to check that the line entered was simply "exit" or "quit" by itself. Skip suggested that such an attribute be made clearly private magic (e.g. by naming it sys._last_input). Michael Hudson suggested that the clever hacks could be avoided by simply having the equivalent of "if input.rstrip() == "exit": raise SystemExit" in the implementation of the interactive interpreter. Fredrik felt that this would elevate "exit" and "quit" into reserved keywords, in that this could occur:: >>> def exit(): ... print "bye" >>> # what is it? >>> exit $ oops! (However, one could simply type "repr(exit)" rather than "exit" in this case). Walter Dörwald suggested adding "sys.inputhook" (c.f. sys.displayhook, sys.excepthook), which gets each statement entered and returns True if it processed the line or False if normal handling should be done; Alex Martelli made a similar suggestion. This would not only allow special handling for "exit", "quit", and "help", but also might make implementing alternative shells easier. Nick Coghlan added a default handler to this suggestion, which checked a new dictionary, "sys.aliases", for special statements of this type and called an appropriate function if found. Fredrik's concern with this method was the same as with Michael Hudson's - that typing "exit" as a shortcut for "print repr(exit)" (when the user had assigned a value to "exit") would cause the shell to exit. As a result, Nick modified his default inputhook to check that the statement didn't exist in __main__'s vars(). Fernando Perez pointed out that this begins to come close to reimplementing ipython_. Fernando also commented that he felt that the amount of code he thought would be necessary to avoid any side-effects when determining whether "exit" should exit or not would make the standard interpreter too brittle, and that this should be left to third-party interpreters. He gave a lengthy explanation of the process that ipython went through, including linking to `the _prefilter method` that performs the appropriate magic in ipython. His opinion was that interpreters should have a separate command mode, entered by a particular character (e.g. the '%' used in ipython); while this would simply code, '%exit' would be even harder for people to guess, however. Some people were concerned that "quit" and "exit" would be treated specially (i.e. the standard way to do something is to "call a function" and a special case for exiting the interpreter is inappropriate); others pointed out that this would be there especially for people who don't know how to program in Python, and might not know that typing an EOF would exit the shell (or what the EOF character was for their platform). Fredrik's proposal gained a lot of early support, but later posters were not so keen. Stephen J. Turnbull suggested that the problem was simply that the current "help"/"exit" messages are impolite, and changing the language would solve the problem. Similarly, Aahz suggested that adding an explanation of how to quit to the startup message would suffice, although others disagreed that users would notice this, particularly when it was needed. Despite the strong support, however, in the end, Guido stepped in and stated that, in his opinion, nothing was wrong wih the status quo (or that if anything were to be changed, the hints provided by typing "exit" or "quit" should be removed). This pretty much ended the discussion. .. _ipython: http://ipython.scipy.org .. _`the _prefilter method`: http://projects.scipy.org/ipython/ipython/file/ipython/trunk/IPython/iplib.… Contributing threads: - `a quit that actually quits <http://mail.python.org/pipermail/python-dev/2005-December/059094.html>`__ --------------------------------------- Exposing the Subversion revision number --------------------------------------- Barry Warsaw proposed `a fairly simple patch`_ to expose the Subversion revision number to Python, both in the Py_GetBuildInfo() text, in a new Py_GetBuildNumber() C API function, and via a new sys.build_number attribute. A lengthy discussion took place about the correct method of determining the "revision number" that should be used. There are many possibilities, from the originally proposed revision number in which the directory was last modified, to the latest revision number within the tree, to using subversion itself. Each method requires a different amount of processing in order to determine the correct value. Barry indicated a preference for the original, simple, method, because he wished to keep the patch as simple as possible, didn't want to depend on Python already being built, and felt that generally developers will just 'svn up' at the top of the source tree then rebuild, rather than 'svn up' a buried sub-tree, change back to the top directory, and rebuild from there. Phillip J. Eby's concern with this was that this would not indicate if a change has been made locally and committed, unless the developer also did a 'svn up'. He also pointed out that the "Revision" from 'svn info' can change when the code doesn't change (because it will change when code in branches, the sandbox, PEPs, and so forth change). In the end, using the svnversion command was agreed on as a suitable method. The two main advantages are that this is the officially sanctioned (by Subversion) method, and that it indicates when local changes have been made. Armin Rigo voiced a concern that people would use sys.build_number to check for features in their programs, instead of using sys.version_info (or duck-typing methods such as hasattr()) because it seems that comparing a single number is easier than comparing a tuple. This was of especial concern considering that this value would only be present in CPython. He suggested that a new build_info attribute could be added to sys instead, which would be a tuple of ("CPython", "<SVN revision number>", "trunk"); that is, it would also include which Python implementation the program is using (for particular use by the test suite). The name also has advantages in that the number is actually a string (because 'M' will be present if there are local modifications) and it is not tied to a specific version control system. Michael Hudson pointed out that this value will not be able to be obtained when Python is built from an 'svn export' (where the .svn files do not exist), which is probably the case for many Python distributions. He wondered whether a subversion trigger could put the revision number into some file in the repository to cover this case, but Martin indicated that this would be difficult (although if the distribution is built from a tag, that the information would not be necessary). Barry suggested that the number would be the latest revision at which getbuildinfo was changed if a .svn directory isn't found. As an aside to this patch, Martin suggested that the build number should be dropped, as it stopped working on Windows some time ago and no longer provides any useful information. There was no opposition to this proposal, and some support. .. _a fairly simple patch: http://python.org/sf/1382163 Contributing threads: - `Expose Subversion revision number to Python <http://mail.python.org/pipermail/python-dev/2005-December/058832.html>`__ [TAM] --------------------------------------- Python's lists, linked lists and deques --------------------------------------- Martin Blais asked why Python didn't have native singly-linked or doubly-linked list types. Generally, it seemed that people couldn't find use cases for them that weren't covered by Python's builtin lists, collections.deque objects, or head-plus-tail-style two-tuples. The proposal was redirected to comp.lang.python until it was more developed. In a related thread, Christian Tismer asked if Python's list type could do a little usage-tracking and switch between the current array-based implementation and a deque-based implementation if, say, a large number of inserts or deletes began to occur at the beginning of the list. He got a few responses suggesting that it would be more complication that it was worth, but mostly his question got drowned out by the linked-list discussion. Contributing threads: - `Linked lists <http://mail.python.org/pipermail/python-dev/2005-December/058754.html>`__ - `deque alternative (was: Linked lists) <http://mail.python.org/pipermail/python-dev/2005-December/059054.html>`__ - `deque alternative <http://mail.python.org/pipermail/python-dev/2005-December/059076.html>`__ - `(back to): Linked lists -- (was: deque alternative) <http://mail.python.org/pipermail/python-dev/2005-December/059119.html>`__ [SJB] ------------------------ set() memory consumption ------------------------ Noam Raphael noted, as others have before, that sets (and dicts) do not release allocated memory after calls to pop(). He suggested that to keep pop() as amortized O(1) per delete, all that was needed was to resize the table to half its current size whenever it dropped to less that one quarter full. People seemed generally to think that the dict implementation (and therefore the set implementation which is based on it) were already highly optimized for real-world performance, and that there were too few use cases where a set would be filled and then emptied, but not filled up again. Raymond Hettinger is hesitant about getting too explicit in the documentation, because some of the choices are an implementation accident that might be different in, say, Jython. There are some `proposed changes`_ to the dictnotes.txt file in the source distribution; there may well be room for additional improvements. .. _proposed changes: http://python.org/sf/1397848 Contributing thread: - `When do sets shrink? <http://mail.python.org/pipermail/python-dev/2005-December/059228.html>`__ [SJB, with additions from Jim Jewett] --------------------------------------------------------- Changing the naming conventions of builtins in Python 3.0 --------------------------------------------------------- Ka-Ping Yee provocatively suggested that, to be consistent with the recommended style guide, in Python 3.0 built-in constants (None, True, False) should be in all caps (NONE, TRUE, FALSE), and built-in classes (object, int, float, str, unicode, set, list, tuple, dict) should be in CapWords (Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict). However, Michael Chermside noted that there is a common convention that the fundamental built-in types (not standard library types; e.g. set, not sets.Set) are all in lowercase. Almost no-one liked this idea, and many people were vehemently opposed. Guido quickly pronounced this dead for built-in types (cleaning up and making the more consistent the standard library classes is another matter). Contributing thread: - `Naming conventions in Py3K <http://mail.python.org/pipermail/python-dev/2005-December/059304.html>`__ [TAM] ------------------- Default comparisons ------------------- Today, you can compare anything, unless someone has gone out of their way to prevent it. Unfortunately, this comparison can eventually fallback to comparing id(), which is not stable across database save-and-restore. Not falling back to id(), which is suggested in `PEP 3000`_, would mean that comparison results are more permanent (and less arbitrary), but it would come at the cost of extra raised exceptions that make it harder to get a canonical ordering. An alternative solution would be to promote a standard way to say "just get me a canonical ordering of some sort". "Comparison" would raise a TypeError if the pair of objects were not comparable; "Ordering" would continue on to "something consistent", just like sorts do today. Josiah Carlson suggested that this could be achieved by new superclasses for all built-in types (except string and unicode, which already subclass from basestring). int, float, and complex would subclass from basenumber; tuple and list would subclass from basesequence; dict and set would subclass from basemapping. Each of these base classes define a group in which items are comparable; if you end up in a situation in which the base classes of the compared object differ, you compare their base class name. If a user-defined classes wanted to be compared against (e.g.) ints, floats, or complex, the user would subclass from basenumber; if the user only wanted their objects to compare against objects of its own type, they define their own __cmp__. However, Marc-Andre Lemburg pointed out that Python already uses this 'trick' based on the type name (falling back to id(), which is the problem), and that inheriting from (e.g.) basenumber could result in unexpected side-effects. .. _PEP 3000: http://www.python.org/peps/pep-3000.html Contributing thread: - `Keep default comparisons - or add a second set? <http://mail.python.org/pipermail/python-dev/2005-December/058899.html>`__ [TAM] --------------------------------------- Converting open() to a factory function --------------------------------------- Guido had previously_ indicated that while file() will always stay the name of the file object, open() may be changed in the future to a factory function (instead of just being an alias for file). Noting that ``help(open)`` now just displays the file object documentation, Aahz suggested that open() become a factory function now. Fredrik Lundh chimed in to suggest that a textopen() function should also be introduced, which would call codecs.open() or file() depending on whether or not an encoding was supplied. There was mild support for both proposals, but no patches were available at the time of this writing. .. _previously: http://mail.python.org/pipermail/python-dev/2004-July/045921.html Contributing thread: - `file() vs open(), round 7 <http://mail.python.org/pipermail/python-dev/2005-December/059073.html>`__ [SJB] ----------------------------- NotImplemented and __iadd__() ----------------------------- Facundo Batista presented a bug_ where using += on Decimal objects returned NotImplemented instead of raising an exception. Armin Rigo was able to supply a patch after adding the following conditions to the documentation: * PySequence_Concat(a, b) and operator.concat(a, b) mean "a + b", with the difference that we check that both arguments appear to be sequences (as checked with operator.isSequenceType()). * PySequence_Repeat(a, b) and operator.repeat(a, b) mean "a * b", where "a" is checked to be a sequence and "b" is an integer. Some bounds can be enforced on "b" -- for CPython, it means that it must fit in a C int. .. _bug: http://www.python.org/sf/1355842 Contributing thread: - `NotImplemented reaching top-level <http://mail.python.org/pipermail/python-dev/2005-December/059046.html>`__ [SJB] --------------------------------------------------- Using buildbot to automate testing of Python builds --------------------------------------------------- Contributing thread: - `Automated Python testing (was Re: status of development documentation) <http://mail.python.org/pipermail/python-dev/2005-December/059060.html>`__ ----------------------------------------------------- Importing C++ extensions compiled with Visual C++ 8.0 ----------------------------------------------------- Ralf W. Grosse-Kunstleve indicated that while they could compile their C++ extensions with Visual C++ 8.0, importing any such extensions resulted in an error:: This application has failed to start because MSVCP80.dll was not found. Re-installing the application may fix this problem. Though the combination of compiling Python with VS.NET2003 and an extension with VS2005 is not supported, Ralf was able to get things to work by adding ``/manifest`` to the linker options and invoking ``mt.exe`` to embed the manifest. Contributing thread: - `Python + Visual C++ 8.0? <http://mail.python.org/pipermail/python-dev/2005-December/059085.html>`__ [SJB] ------------------------------- Using ssize_t as the index type ------------------------------- Martin v. Löwis presented `PEP 353`_, which proposes using ssize_t as the index type in the CPython implementation. In Python 2.4, indices of sequences are restricted to the C type int. On 64-bit machines, sequences therefore cannot use the full address space, and are restricted to 2**31 elements. The PEP proposes to change this, introducing a platform-specific index type Py_ssize_t. An implementation of the proposed change is in `an SVN branch`_; the Py_ssize_t will have the same size as the compiler's size_t type, but is signed (it will be a typedef for ssize_t where available). Although at the moment one needs 16GiB to just hold the pointers of a 2GiElement list, these changes also allow strings and mmap objects longer than 2GiB (and also improve the scipy_core (neé Numarray and Numerical) objects, which are already 64-bit clean). Since the proposed change will cause incompatibilities on 64-bit machines, the reasoning is that this change should be done as early as possible (i.e. while such machines are not in wide use). Guido approved the PEP, indicating he believed it was long overdue. Several other people also indicated support for the PEP. Note that people felt that Martin's PEP was of a particularly high standard; people considering writing their own PEP should consider reading this (once it has a number and is available online!) to gain an understanding of how a good PEP is both extremely readable (even when including arcane C programming points!) and well-organised. .. _an SVN branch: http://svn.python.org/projects/python/branches/ssize_t .. _PEP 353: http://www.python.org/peps/pep-0353.html Contributing threads: - `New PEP: Using ssize_t as the index type <http://mail.python.org/pipermail/python-dev/2005-December/059266.html>`__ - `Test branch for ssize_t changes <http://mail.python.org/pipermail/python-dev/2005-December/058863.html>`__ [TAM] ----------------------------------------------------------------------------- Garbage collection based on object memory consumption instead of object count ----------------------------------------------------------------------------- Andrea Arcangeli suggested that Python's garbage collection could be improved by invoking a gc.collect() at least once every time the amount of anonymous memory allocated by the interpreter increases by a tunable factor (defaulting to 2, meaning the memory doubles, and with a factor of 1 mimicking the current state, where collection is done if 1000 new objects are allocated). Aahz and Martin v. Löwis indicated that it was extremely unlikely that anything would be done about this unless Andrea submitted a patch (with doc patches and tests). Contributing thread: - `suggestion for smarter garbage collection in function of size (gc.set_collect_mem_growth(2)) <http://mail.python.org/pipermail/python-dev/2005-December/059184.html>`__ [TAM] ---------------------------------- Adding zlib module to python25.dll ---------------------------------- Thomas Heller and Martin v. Löwis had been discussing whether the zlib module should become builtin, at least on Windows (i.e. part of python25.dll). This would simplify both the build process and py2exe, the latter could then bootstrap extraction from the compressed file just with pythonxy.dll, but this is currently not done, because the pythoncore.vcproj would then not be buildable anymore unless you also have the right version of zlib on disk. To solve this problem, Thomas proposed that the Python release could incorporate a copy of zlib, primarily for use on Windows (with the project files appropriately adjusted). This change was later made. Contributing thread: - `Incorporation of zlib sources into Python subversion <http://mail.python.org/pipermail/python-dev/2005-December/058873.html>`__ [TAM] ---------------------------------------- Procedure for fixing bugs in ElementTree ---------------------------------------- Neal Norwitz found a few bugs in ElementTree and asked what the procedure was, since the ElementTree module is maintained externally by Fredrik Lundh. The answer was to post the bug to sourceforge as usual, and and assign it to Fredrik Lundh. The ElementTree in the Python SVN trunk should only have critical patches committed - all other patches would be applied by Fredrik to his externally distributed ElementTree package, and imported to the Python SVN trunk after the next release of ElementTree. Contributing thread: - `ref leak in element tree/pyexpat <http://mail.python.org/pipermail/python-dev/2005-December/058872.html>`__ [SJB] --------------------------------------- Starting enumerate with non-zero values --------------------------------------- Can enumerate start somewhere other than zero? Answer: it complicates the API too much; if you want an arbitrary slice, then make it explicitly a slice. Contributing thread: - `synchronized enumerate <http://mail.python.org/pipermail/python-dev/2005-December/058896.html>`__ [Jim Jewett] ------------------ Are sets mappings? ------------------ This spun out of the default comparisons discussion; when deciding what could be "sensibly" compared, (or even how best to teach python) there was a discussion of more abstract types. It wasn't clear where to put sets. Contributing thread: - `Sets are mappings? <http://mail.python.org/pipermail/python-dev/2005-December/058923.html>`__ [Jim Jewett] --------------------- Local socket timeouts --------------------- If you want your network client to eventually give up on failed connections, you need to set a timeout - but you have to do that at the socket level, instead of in the library that you're actually using. (There are other problems with the current method too, such as being too global, or not quite acting as expected.) It was agreed that people should be able to handle timeout settings from the networking library that they actually use, but I don't think there are patches yet. Contributing thread: - `timeout options in high-level networking modules <http://mail.python.org/pipermail/python-dev/2005-December/058996.html>`__ [Jim Jewett] ================ Deferred Threads ================ - `Build failure and problem on Windows <http://mail.python.org/pipermail/python-dev/2005-December/058918.html>`__ =============== Skipped Threads =============== - `PEP 8 updates/clarifications, function/method style <http://mail.python.org/pipermail/python-dev/2005-December/058835.html>`__ - `DRAFT: python-dev summary for 2005-11-16 to 2005-11-31 <http://mail.python.org/pipermail/python-dev/2005-December/058869.html>`__ - `[Python-checkins] commit of r41497 -python/trunk/Lib/test <http://mail.python.org/pipermail/python-dev/2005-December/058871.html>`__ - `fresh checkout won't build <http://mail.python.org/pipermail/python-dev/2005-December/058876.html>`__ - `fixing log messages <http://mail.python.org/pipermail/python-dev/2005-December/058883.html>`__ - `(no subject) <http://mail.python.org/pipermail/python-dev/2005-December/058916.html>`__ - `os.startfile with optional second parameter <http://mail.python.org/pipermail/python-dev/2005-December/058919.html>`__ - `[OT] Fwd: a new python port: iPod <http://mail.python.org/pipermail/python-dev/2005-December/058920.html>`__ - `Patch to make unittest.TestCase easier to subclass <http://mail.python.org/pipermail/python-dev/2005-December/058995.html>`__ - `Patch reviews & request for patch review <http://mail.python.org/pipermail/python-dev/2005-December/059027.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2005-December/059031.html>`__ - `A few questions about setobject <http://mail.python.org/pipermail/python-dev/2005-December/059091.html>`__ - `Small any/all enhancement <http://mail.python.org/pipermail/python-dev/2005-December/059127.html>`__ - `floating point literals don't work in non-US locale in 2.5 <http://mail.python.org/pipermail/python-dev/2005-December/059176.html>`__ - `JOB OPENING: Implementor for Python and Search <http://mail.python.org/pipermail/python-dev/2005-December/059183.html>`__ - `PyCon TX 2006: Early-bird registration ends Dec. 31! <http://mail.python.org/pipermail/python-dev/2005-December/059195.html>`__ - `set.copy documentation string <http://mail.python.org/pipermail/python-dev/2005-December/059222.html>`__ - `Bug in Py_InitModule4 <http://mail.python.org/pipermail/python-dev/2005-December/059272.html>`__ - `floating point literals don't work in non-USlocale in 2.5 <http://mail.python.org/pipermail/python-dev/2005-December/059290.html>`__ - `slight inconsistency in svn checkin email subject lines <http://mail.python.org/pipermail/python-dev/2005-December/059335.html>`__ - `Gaming on Sunday (Jan 1) <http://mail.python.org/pipermail/python-dev/2005-December/059339.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from December 16, 2005 through December 31, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 10th summary written by the python-dev summary duopoly of Steve Bethard and Tony Meyer (back to back!). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. -------------------- Commenting on Topics -------------------- To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! ------------------------- How to Read the Summaries ------------------------- The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://svn.python.org/projects/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo :); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-11-16_2005-11-30.html .. _original text file: http://www.python.org/dev/summary/2005-12-16_2005-12-31.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

python-dev Summary for 2005-12-01 through 2005-12-15
by Tony Meyer Jan. 20, 2006

Jan. 20, 2006

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-12-01_2005-12-15.html] ============= Announcements ============= ----------------------------------------------------- Reminder: plain text documentation fixes are accepted ----------------------------------------------------- Want to help out with the Python documentation? Don't know LaTeX? No problem! Plain text or ReST fixes are also welcome. You won't be able to produce a diff file like with a normal patch, but comments that explain how to fix the docs are just as good. A form like "in section XXX right before the paragraph starting with YYY, the documentation should say ZZZ" will make it easy for the doc maintainers to apply your fix. Contributing thread: - `c.l.p post on docs <http://mail.python.org/pipermail/python-dev/2005-December/058479.html>`__ [SJB] -------------------------------------------- New-style exceptions patch requesting review -------------------------------------------- With `PEP 352`_ ready_ for Guido's pronouncement, Michael Hudson has asked for a few more developers to review his patch_ to make all exceptions new-style. It should be basically ready, but it would be nice to have a few eyes for sanity checks, documentation, and compilations on the various platforms. .. _PEP 352: http://www.python.org/peps/pep-0352.html .. _ready: http://www.python.org/dev/summary/2005-10-16_2005-10-31.html#required-super… .. _patch: http://bugs.python.org/1104669 Contributing threads: - `New-style exceptions patch (was Re: PEP 8 updates/clarifications) <http://mail.python.org/pipermail/python-dev/2005-December/058542.html>`__ - `New-style exceptions patch <http://mail.python.org/pipermail/python-dev/2005-December/058543.html>`__ [SJB] ---------------------------------------- Debugging lib available from ActiveState ---------------------------------------- Trent Mick confirmed that ActiveState do distribute a separate distribution of debug DLLs for each Python release. These can be found by filling in the version number in the URL ftp://ftp.activestate.com/ActivePython/etc/ActivePython-<version>-win32-ix86-debug.zip Contributing thread: - `Plea to distribute debugging lib <http://mail.python.org/pipermail/python-dev/2005-December/058446.html>`__ [TAM] ========= Summaries ========= ------------------------------- Updating the Python style guide ------------------------------- Ian Bicking kicked off a lengthy discussion about updating various aspects of `PEP 8`_ (the Python code style guide), which resulted in a substantial revision of the PEP. PEP 8 stated that if a module defines a single exception raised for all sorts of conditions, it is generally called "error" or "Error". Ian noted that other than some outlying cases (e.g. os.error, socket.error), CapWords are always used. He also wondered if exceptions should have names that are relatively unique, or simply unique within their namespace. Finally, he requested a position be taken on acronyms (e.g. HHTPRedirect or HttpRedirect). Barry Warsaw pointed out that since exceptions are now classes, the rules for naming classes should really apply; his preference is CapWordsEndingInError rather than Error or error. He also suggested that acronym letters should be capitalised. There was mostly consensus on this, although some prefer shorter exception class names. Guido wondered whether the function/method naming convention (lower_case, mixedCase, or CapWords) was so controversial that the PEP should not make a recommendation other than of consistency. In the end, however, the status quo (lower_case except for consistency reasons) won out. He was definite about module, package, and class names, however, which should be all-lowercase without underscores (modules/packages), or CapWords (class names). (He noted that standard library modules such as StringIO.py and UserDict.py that break this rule should be changed). PEP 8 recommended appending an underscore rather than corrupted spelling when a name conflicts with a reserved word e.g. class\_ rather than klass). Ian suggested that a specific recommendation for the class argument to classmethods be made; out of cls, klass and class\_ he preferred cls. He further suggested that, as self is not used outside of the first argument of instance methods, whatever spelling of the class argument is used should not be used elsewhere (e.g. cls for the class argument, and class\_ elsewhere). This was generally accepted. A further suggestion from Barry's `Mailman style guide`_ was also made, that from-imports should follow non-from imports, and dotted imports should follow non-dotted imports. Non-dotted imports should be grouped by increasing length, while dotted imports should be grouped roughly alphabetically. However, this was felt to be too prescriptive; users should follow their own aesthetic taste. Various other small modifications and improvements were suggested and made, such as: * PEP 8 stated that modules designed for use via "from M import \*" should prefix their globals, internal functions, and internal classes with an underscore. Ian suggested that __all__ should be recommended over using a leading underscore, which was done. * PEP 8 was fairly dated in discussing inheritance and public/non-public methods. Ian suggested that the language should be updated, and that property() should be discussed, and this was done. * PEP 8 recommended that class-based exceptions are used rather than string-based exceptions. Ian suggested that language be changed to recommend more strongly against string-based exceptions, which was done. * To make the PEP more concise and succinct, references to Emacs were removed. There was also a sub-thread that considered when to use normal instance variables and when to use accessor methods. Jim Fulton suggested that attributes should be used if the accessors are trivial, whereas Skip Montanaro preferred more frequent use of accessor methods, to avoid incorrect usage of classes. Phillip J. Eby's opinion was that normal instance variables should be used, until there is a need to do something when they change, at which point properties should be introduced. PEP 8 now recommends simple attribute access over accessors. One distinction is how people interpret "public" and "private". Skip's opinion is that just because an attribute doesn't start with an underscore doesn't mean that it is implicitly declared public, and that people should familiarise themselves with the callable methods of an object and only use direct access if the necessary methods aren't provided. Jim felt that the API should be documented, and people should use that API (he considered that prepending an underscore documents that the attribute is internal; although this does not cover the "subclassing API"). Ian also brought up the section of PEP 8 that discussed private attributes and double leading underscores. PEP 8 was unclear whether double leading attributes should only be used to avoid name conflicts when subclassing, or whether indicating that an attribute was meant to be private was a valid use. This spun off a very long discussion about private variables. Several people spoke up against double-underscore prefixes. On the other hand, Raymond Hettinger felt that the PEP should not dictate how variables should be named, especially for a convention with a long history and language support. Jim Fulton went so far as to suggest that __private be deprecated, which gained some support. However, Guido stated that he not only liked __private, he liked the current implementation. Specifically, he felt that the typically-shallow class hierarchies found in Python reduces the likelihood of accidental reuse of class names (he also advocated that subclasses should not share names with parent classes), and he liked that the name-mangling algorithm was well-defined and simple (e.g. so that when in the debugger it is easy to manually mangle/unmangle names). Interestingly, this is the main reason that Jeremy Hylton dislikes mangled names: because the debugger is unaware of the names and he can't remember how to type them, and also because it's annoying to have to change every instance of __var to _var if the intended usage changes (as compared to C++ private variables, where only the declaration of visibility must change). He noted, though, that these are problems that tools (debuggers, editors, IDEs) could solve. Others felt that keeping mangling was fine, but that it should be changed so that collisions were harder (e.g. use a GUID instead of the class name). However, this violates one of Guido's reasons for liking the current implementation (although it's possible that having better support for the feature in common tools would remove this necessity). Tim Peters gave a nice explanation of why the name mangling is provided:: If your utility or mixin base class `A` has a data member named `n`, nobody deriving from `A` dare name one of their data members `n` too, and it's unreasonable to expect everyone deriving from `A` to learn and avoid all the names `A` uses internally. It's even more unreasonable for A's author to have to promise, after A's first release, never to change the name of, or introduce any new, attribute (A's author dare not, lest the new name conflict with a name someone else's subclass used). If A's author names the attribute `__n` instead, all those problems go away, provided only that some subclass doesn't also name itself `A`. Contributing threads: - `PEP 8 updates/clarifications <http://mail.python.org/pipermail/python-dev/2005-December/058532.html>`__ - `Deprecate __ private (was Re: PEP 8 updates/clarifications) <http://mail.python.org/pipermail/python-dev/2005-December/058555.html>`__ - `Import order (was Re: PEP 8 updates/clarifications) <http://mail.python.org/pipermail/python-dev/2005-December/058671.html>`__ - `Deprecate __ private (was Re: PEP 8updates/clarifications) <http://mail.python.org/pipermail/python-dev/2005-December/058694.html>`__ - `PEP 8 updates/clarifications, function/method style <http://mail.python.org/pipermail/python-dev/2005-December/058732.html>`__ .. _PEP 8: http://www.python.org/dev/peps/pep-0008.html .. _Mailman style guide: http://barry.warsaw.us/software/STYLEGUIDE.txt [TAM] ------------------------------------ ElementTree in the Python 2.5 stdlib ------------------------------------ Skip Montanaro forwarded to python-dev a bit of a comp.lang.python thread asking why ElementTree wasn't part of the standard library. He and others argued that it was "best of breed" with a wide user base, and that it met the other requirements_ for stdlib inclusion like having an active maintainer, Fredrik Lundh. After a relatively brief discussion, Fredrik got the ball rolling, setting things up so that: * The ``external`` directory at the top of the SVN tree contains snapshots of his celementtree and elementtree packages * The ``etree`` subpackage of the ``xml`` module contains the ElementTree, cElementTree, ElementPath and ElementInclude modules Mike Brown started a brief follow-up thread concerned that the XML-SIG hadn't been consulted on this inclusion. Martin v. Löwis and others indicated that sidestepping XML-SIG had not been intentional, but also that carrying the discussion on XML-SIG as well would not likely have changed the outcome due to the strong community support for ElementTree. As a side effect of this discussion, magic in ``xml/__init__`` was removed in favor of introducing an ``xmlcore`` package containing all the xml modules found in the basic standard library, and an ``xml`` module which imports things from ``xmlcore`` or PyXML if it's available. .. _requirements: http://mail.python.org/pipermail/python-dev/2003-April/034881.html Contributing threads: - `ElementTree - Why not part of the core? (fwd) <http://mail.python.org/pipermail/python-dev/2005-December/058512.html>`__ - `stupid package tricks <http://mail.python.org/pipermail/python-dev/2005-December/058622.html>`__ - `ElementTree in stdlib <http://mail.python.org/pipermail/python-dev/2005-December/058638.html>`__ - `Sharing expat instances <http://mail.python.org/pipermail/python-dev/2005-December/058692.html>`__ - `"xml"; package in standard library <http://mail.python.org/pipermail/python-dev/2005-December/058710.html>`__ [SJB] -------------------- More work on the AST -------------------- This fortnight saw implementations for the two main models proposed for revamping the AST memory management. Martin v. Löwis created a branch_ that converted all AST objects to PyObjects and used the normal Python reference counting to manage them. This requires that AST code: * initialize all PyObjects to NULL * Py_XDECREF() each PyObject on exit * goto an error block for Py_DECREF()ing if there is a failure Jeremy Hylton worked up a separate version of the AST code using an arena API. This requires that AST code: * call PyArena_AddPyObject() for any allocated PyObject * call PyArena_AddMallocPointer() for any malloc()ed memory The arena code was merged into the trunk, though it seemed that work on the PyObject branch would continue in order to be able to compare the final outcomes of both strategies. In a related issue, because the AST code is generated from Parser/asdl_c.py, and because subversion sets the timestamp for each file to the checkout time, trying to build the current trunk on a machine without Python installed failed even when the AST C files had been checked into subversion. It looked like the best solution would be to introduce a separate make rule for generating the AST code. .. _branch: http://svn.python.org/projects/python/branches/ast-objects/ Contributing threads: - `ast-objects branch created <http://mail.python.org/pipermail/python-dev/2005-December/058433.html>`__ - `Memory management in the AST parser & compiler <http://mail.python.org/pipermail/python-dev/2005-December/058434.html>`__ - `PyAST_FromNode returning PyTypeObject* ? <http://mail.python.org/pipermail/python-dev/2005-December/058440.html>`__ - `should I really have to install Python before I can build it ? <http://mail.python.org/pipermail/python-dev/2005-December/058608.html>`__ - `should I really have to install Python before Ican build it ? <http://mail.python.org/pipermail/python-dev/2005-December/058618.html>`__ - `should I really have to install Python before Icanbuild it ? <http://mail.python.org/pipermail/python-dev/2005-December/058625.html>`__ [SJB] ------------------- Python GC Refresher ------------------- Gregoire Weber asked for a little more information on Python's garbage collector since the links in ``Modules/gcmodule.c`` were broken. Python's garbage collector is a combination of reference counting and the periodic invocation of a cyclic garbage collector. Python's reference counting means that each time an object P is referenced by another object, P's refcount is incremented, and each time one of the references to P is removed, P's refcount is decremented. When P's refcount reaches zero, the interpreter pauses to reclaim P and all objects that were reachable only from P. In addition to this reference counting, Python's cyclic garbage collector means that after a large number of objects have been allocated (and not deallocated though reference counting), the interpreter will pause to try to clear out any unreferenced cycles. Contributing thread: - `Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore <http://mail.python.org/pipermail/python-dev/2005-December/058526.html>`__ [SJB] ----------------------------------- Improving the documentation process ----------------------------------- Skip Montanaro suggested that, in order to lower the barrier for submitting documentation patches, it might be worth allowing anonymous bug reports. Guido was against this, indicating that he thought the problem was more the sourceforge sign-up hassle than the need to provide an email address, and suggested that it might be time to switch to roundup_. Martin v. Löwis was concerned about the transition process - whether or not roundup could properly import the sourceforge bug reports, and whether or not the python.org/sf/<sf bug id> redirect would continue to work. The discussion trailed off before any final decisions were made. .. _roundup: http://roundup.sourceforge.net/ Contributing threads: - `Tracker anonymity <http://mail.python.org/pipermail/python-dev/2005-December/058489.html>`__ [SJB] ------------------------ hasattr() and properties ------------------------ Thomas Lotze noticed that when applied to a class instance (but not an object of that class), hasattr calls getattr and decides that the attribute doesn't exist if the call raises any exception. For example:: >>> class Foo(object): ... def get(self): ... raise Exception ... bar = property(get) ... >>> hasattr(Foo, "bar") True >>> hasattr(Foo(), "bar") False He asked whether it would make more sense to only report a missing attribute if an AttributeError is raised. Greg Ewing agreed that this would be an improvement, but felt that calling the property access code as a side effect of hasattr seems like a misfeature. Thomas also wondered whether it would make sense for properties to look up the attribute in the same way that getattr would rather than calling getattr. Greg wondered if descriptors need a forth slot for hasattr customisation, removing the need to rely on catching exceptions, so that the logic would be:: if there is a descriptor for the attribute: if the descriptor's hasattr slot is populated: return the result of calling it else: return True else: look in the instance dict for the attribute Guido indicated that he believes that a property that has a side effect (other than caching, statistics, logging, and so forth) is a misfeature anyway, so he doesn't have a problem with hasattr() trying getattr() and reporting False if that raises an exception. Discussion died out before anything was resolved. Contributing thread: - `hasattr and properties <http://mail.python.org/pipermail/python-dev/2005-December/058498.html>`__ [TAM] --------------------------------- Supporting iterables in xmlrpclib --------------------------------- Skip Montanaro `presented a patch`_ to allow all currently supported iterables (e.g. sets and arrays) to be marshalled as lists with xmlrpclib. The goals are to extend the set of sequences that can be marshalled transparently, and keep the caller from caring as much about the limitations of the XML-RPC datatypes. Guido felt that this was a bad idea, however; he feels that it's better to be aware of the limitations in what XML-RPC can handle and try to handle it. Contributing thread: - `Broader iterable support for xmlrpclib <http://mail.python.org/pipermail/python-dev/2005-December/058474.html>`__ .. _presented a patch: http://python.org/sf/1374063 [TAM] ----------------------------------------- Checking Jython support code into CPython ----------------------------------------- Fredrik Lundh asked what the policy with respect to Jython-specific modules in the standard library was. Guido felt that as long as it didn't do any harm (likely causing unit tests to fail) to CPython, it would be fine. He noted that traditionally Jython-specific code has been checked into Jython's own source control, however, and Martin v. Löwis indicated that this is what he would prefer. Contributing thread: - `Jython and CPython <http://mail.python.org/pipermail/python-dev/2005-December/058680.html>`__ [TAM] ----------------------------------------- Getting rid of __builtins__ in Python 3.0 ----------------------------------------- Neal Norwitz asked Guido whether improving the confusing system of having both __builtins__ and __builtin__ could be begun. Guido clarified that having both is clearly a bad idea, that he's not sure that renaming builtin to __builtin__ was correct (and that perhaps it should be changed back), that __builtins__ always being a dict would simplify some code but need special handling of vars() in interactive mode, and that another alternative might be to merge the __builtin__ and __builtins__ functionality (under the __builtin__ name). Guido asked that people mull this over, but hasn't had any responses so far. Contributing thread: - `__builtin__ vs __builtins__ <http://mail.python.org/pipermail/python-dev/2005-December/058652.html>`__ [TAM] ------------------------------------- Subject lines of python-commit emails ------------------------------------- If you subscribe to python-checkins, you get email every time something is updated. Most people don't care about every change; the subject lines were made a bit more useful for classification. Contributing thread: - `Subject lines of commit email <http://mail.python.org/pipermail/python-dev/2005-December/058447.html>`__ [Jim Jewett] ------------------------------------------- Additional arguments for logging formatters ------------------------------------------- People would like to pass additional arguments to the logging formatters. Now they will be able to also pass a dict containing extra values. There were a few questions on the API; particularly on what to do if the extra dict redefines some of the already documented variables. Contributing thread: - `Proposed additional keyword argument in logging calls <http://mail.python.org/pipermail/python-dev/2005-December/058449.html>`__ [Jim Jewett] ------------------------------------------------------- Correct location for dynmically linked/shared libraries ------------------------------------------------------- Since ElementTree is being added, so is cElementTree (not as good for subclassing, but faster). This used a statically compiled expat, but there is already a statically compiled expat distributed with python. The two uses have been merged, and there was some discussion about where \*.so or \*.dll files should go if they represent only part of a package. Contributing thread: - `Location of .so files (Was: Sharing expat instances) <http://mail.python.org/pipermail/python-dev/2005-December/058824.html>`__ [Jim Jewett] ================ Deferred Threads ================ - `Linked lists <http://mail.python.org/pipermail/python-dev/2005-December/058754.html>`__ =============== Skipped Threads =============== - `Python bug day this Sunday <http://mail.python.org/pipermail/python-dev/2005-December/058432.html>`__ - `os.normpath may change the meaning of the path if it contains symbolic links? <http://mail.python.org/pipermail/python-dev/2005-December/058452.html>`__ - `SVN backup? <http://mail.python.org/pipermail/python-dev/2005-December/058456.html>`__ - `svn problem - can't get log info for a specific revision <http://mail.python.org/pipermail/python-dev/2005-December/058462.html>`__ - `Patch reviews & request for patch review <http://mail.python.org/pipermail/python-dev/2005-December/058470.html>`__ - `Dynamic Link Library <http://mail.python.org/pipermail/python-dev/2005-December/058472.html>`__ - `[Python-checkins] commit of r41586 - in python/trunk: Lib/SimpleXMLRPCServer.py Misc/NEWS <http://mail.python.org/pipermail/python-dev/2005-December/058476.html>`__ - `Short-circuiting iterators <http://mail.python.org/pipermail/python-dev/2005-December/058484.html>`__ - `Bug bz2.BZ2File(...).seek(0,2) + patch <http://mail.python.org/pipermail/python-dev/2005-December/058524.html>`__ - `imaplib module with IDLE implememted via threads <http://mail.python.org/pipermail/python-dev/2005-December/058531.html>`__ - `Exception type on handling closed files <http://mail.python.org/pipermail/python-dev/2005-December/058573.html>`__ - `A missing piece of information in weakref documentation <http://mail.python.org/pipermail/python-dev/2005-December/058585.html>`__ - `Directory for packages maintained outside the core (was Re: ElementTree - Why not part of the core?) <http://mail.python.org/pipermail/python-dev/2005-December/058592.html>`__ - `Incorporating external packages into Python's std distribution <http://mail.python.org/pipermail/python-dev/2005-December/058600.html>`__ - `On moving to new-style classes <http://mail.python.org/pipermail/python-dev/2005-December/058688.html>`__ - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2005-December/058719.html>`__ - `Website cruft <http://mail.python.org/pipermail/python-dev/2005-December/058729.html>`__ - `Add timeout to subprocess.py? <http://mail.python.org/pipermail/python-dev/2005-December/058784.html>`__ - `patch tracker ping: cross compile and mingw support <http://mail.python.org/pipermail/python-dev/2005-December/058803.html>`__ - `Needed tester for patch in urllib.py module <http://mail.python.org/pipermail/python-dev/2005-December/058817.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from December 01, 2005 through December 15, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the 9th summary written by the python-dev summary gathering of Steve Bethard and Tony Meyer (more on its way). To contact us, please send email: - Steve Bethard (steven.bethard at gmail.com) - Tony Meyer (tony.meyer at gmail.com) Do *not* post to comp.lang.python if you wish to reach us. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every cent counts so even a small donation with a credit card, check, or by PayPal helps. -------------------- Commenting on Topics -------------------- To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! ------------------------- How to Read the Summaries ------------------------- The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://svn.python.org/projects/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo :); you can safely ignore it. We do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow us to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-11-01_2005-11-15.html .. _original text file: http://www.python.org/dev/summary/2005-12-01_2005-12-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

CFP: The 2006 IAENG International Workshop on Internet Computing and Web Services (in IMECS 2006)
by imecs__2006＠iaeng.org Jan. 19, 2006

Jan. 19, 2006

Call for Papers From: International Association of Engineers (http://www.iaeng.org) Journal Engineering Letters (http://www.engineeringletters.com) The 2006 IAENG International Workshop on Internet Computing and Web Services (Part of The International MultiConference of Engineers and Computer Scientists IMECS 2006) 20-22 June, 2006, Hong Kong http://www.iaeng.org/IMECS2006/IWICWS2006.html The IWICWS'06 workshop is held as part of the International MultiConference of Engineers and Computer Scientists 2006. The IMECS 2006 is organized by the International Association of Engineers (IAENG), and serves as good platforms for the engineering community members to meet with each other and to exchange ideas. Extended version of the papers under this workshop can be included in the special issue of our journal Engineering Letters. And, further extended version can also be included in a book called "Current Trends in Internet Computing and Web Services" to be published by IAENG. The IMECS 2006 multiconference has the focus on the frontier topics in the theoretical and applied engineering and computer science subjects. It consists of 14 workshops (see the details at IMECS website: www.iaeng.org/IMECS2006). The multiconference serves as good platforms for the engineering community members of different disciplines to meet with each other and to exchange ideas. The current conference committee of the IMECS 2006 includes over 140 workshop co-chairs and committee members of mainly research center heads, department heads, professors, research scientists from over 20 countries, while a few of the committee members are also experienced software development directors and engineers. All submitted papers will be under peer review and accepted papers will be published in the conference proceeding (ISBN: 988-98671-3-3). The abstracts will be indexed and available at major academic databases. The Technology Research Databases (TRD) of CSA (Cambridge Scientific Abstracts), DBLP and Computer Science Bibliographies have promised to index the print proceeding in advance of its publication. And after the publication of the proceeding, print copies will also be sent to databases like IEE INSPEC, Engineering Index (EI) and ISI Thomson Scientific for indexing. The accepted papers will also be considered for publication in the special issues of the journal Engineering Letters. Some participants may also be invited to submit extended version of their conference papers for considering as book chapters (soon after the conference). The topics of the workshop include, but not limited to, the following: Internet architecture design Internet search methods Optimization methods Security and protection Fault Tolerance Software Agents Web Java-based applications Knowledge-based web systems Multimedia web tools, architectures, and broadcasting Web data mining and database management Coding and compression Information retrieval Distance learning E-commerce applications E-business modeling and applications And other Internet applications and other web services applications ========= Submission: Prospective authors are invited to submit their draft paper in abstract format (one page) or in full paper format to imecs(a)iaeng.org by 12 March, 2006. The submitted file can be in MS Word format, PS format, or PDF formats. The first page of the draft paper should include: · Title of the paper; · Name, affiliation and e-mail address for each author; · A maximum of 5 keywords of the paper; Also, the name of the workshop session that the paper is being submitted to should be stated in the email. ============= Important Dates: Proposals for special conference sessions and tutorials deadline: 30 December, 2005 Draft Manuscript / Abstract submission deadline: 12 March, 2006 Camera-Ready papers & Pre-registration due: 2 April, 2006 IMECS 2006: 20-22 June, 2006 More details about the IWICWS 2006 can be found at: http://www.iaeng.org/IMECS2006/IWICWS2006.html IWICWS Workshop Co-chairs and Committee Members: Fidel Cacheda (co-chair) Assistant professor, Department of Information and Communications Technologies University of A Coruna, Spain Chin-Chen Chang IEEE Fellow, IEE Fellow Chair Professor in Department of Information Engineering and Computer Science, Feng Chia University, Taiwan Yen-Wen Chen Associate Professor, Dept. of Communication Engineering National Central University, Taiwan Dr. Manuel Jose Damasio (co-chair) Head of course at the film, video and Multimedia course of the Communication Sciences Department, Universidade Lusofona de Humanidades e Tecnologias, Portugal Enrique Herrera-Viedma (co-chair) Professor in the Department of Computer Science and Artificial Intelligence Sub-director of the Library Sciences School University of Granada, Spain Fu-Chien Kao Associate Professor, Department of Computer Science and Information Engineering, Da-Yeh University, Taiwan Dr. Reggie Kwan School of Science and Technology, The Open University of Hong Kong, Hong Kong Dr. Cartik R. Kothari (co-chair) Electrical and Computer Engineering The University of Memphis, USA Dr. Adela Lau (co-chair) Lecturer, Department of Industrial & Systems Engineering The Hong Kong Polytechnic University, Hong Kong Cha-Hwa Lin Assistant Professor, Department of Computer Science and Engineering National Sun-Yat Sen University, Taiwan Qusay H. Mahmoud (co-chair) Assistant Professor, Department of Computing and Information Science University of Guelph, Canada Nikolaos Matsatsinis (co-chair) Associate Professor, Decision Support Systems Laboratory Technical University of Crete, Greece Dr. George Mavrommatis Hellenic Military Academy, Greece Maria Luque Rodriguez Assistant Professor in the Department of Computer Science and Numerical Analysis University of Cordoba, Spain Fu Lee Wang, PhD Lecturer, Department of Computer Science City University of Hong Kong, Hong Kong Hsiao-Fan Wang Chair Professor of Engineering Department of Industrial Engineering and Engineering Management National Tsing Hua University, Taiwan Wei Yen (co-chair) Assistant Professor, Department of Computer Science and Engineering Director of Industrial Cooperation Section Tatung University, Taiwan ******** It will be highly appreciated if you can circulate these calls for papers to your colleagues.

1 0

ANN: PyEnchant 1.1.5
by Ryan Kelly Jan. 19, 2006

Jan. 19, 2006

Hi Everyone, I'm pleased to announce the release of PyEnchant version 1.1.5. This is a bugfix release to address some hangs when running on MS Windows. Specifically: * Fix hang in included MySpell (Windows distribution) * Workaround for some MySpell/unicode problems * Update to latest setuptools ez_setup.py Users of previous versions are encouraged to upgrade. Also, my attempts to announce version 1.1.4 on python-announce seem to have bounced, so I'm including the 1.1.4 ChangeLog below. Cheers, Ryan About: ------ Enchant (http://www.abisource.com/enchant/) is the spellchecking package behind the AbiWord word processor, is being considered for inclusion in the KDE office suite, and is proposed as a FreeDesktop.org standard. It's completely cross-platform because it wraps the native spellchecking engine to provide a uniform interface. PyEnchant brings this simple, powerful and flexible spellchecking engine to Python: http://pyenchant.sourceforge.net/ It also provides extended functionality including classes for tokenizing text and iterating over the spelling errors in it, as well as a ready-to-use text interface and wxPython dialog. Current Version: 1.1.4 Licence: LGPL with exemptions, as per Enchant itself ChangeLog for 1.1.4: -------------------- * No longer need to use the registry under Windows * Moved to setuptools for managing distribution * Registered at the Cheese Shop, with Eggs available for Windows users * Implemented unittest TestCases, works with `python setup.py test` * Plugins on Windows moved to "enchant" subdirectory * SpellChecker now coerces to/from unicode automatically * Use python default encoding rather than UTF-8 where appropriate * Various documentation cleanups * bug fixes: * (1230151): count of live instances done by normalized key * Accept unicode strings as broker orderings -- Ryan Kelly http://www.rfk.id.au | This message is digitally signed. Please visit ryan(a)rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details

1 0