Mailman 3 February 2006 - Python-announce-list

[ANN] PyChecker 0.8.17 released
by Neal Norwitz 04 Feb '06

04 Feb '06

A new version of PyChecker is available. There are two notable new features (command line options): --only and -#/--limit. --only will only print warnings from files specified on the command line. --limit will limit the number of warnings printed. By default, only 10 warnings are printed unless you disable the limit check: -# 0. What is it? PyChecker is a tool for finding bugs in Python source code. It finds problems that are typically caught by a compiler for less dynamic languages, like C and C++. It is similar to lint. Comments, criticisms, new ideas, and other feedback is welcome. Changes from 0.8.16 to 0.8.17: * Fix spurious warning for Statement with no effect using bit shifts * Add -#/--limit command line option to set the max # of warnings to show * Remove broken command line options: -e/--errors, --complexity * Add -e/--level command line options which allows the error level to be specified: error, security, warning, unused, deprecated, style. These names map to numbers: 90, 90, 70, 50, 40, 10 (error == security). Specifying a value means all levels equal to or greater than it. * Add --only option which displays warnings only for files specified on the command line * Add --evil option for users to prevent the interpreter from crashing due to broken C extensions * Fix wrong file name when warning about returning values from __init__ functions. (#1291116) * Fix a few more glitches with setup.py. * Suppress warning about integer division when the code is: int(x / y) * Add code to skip testing objects from extension modules that are known to crash the interpreter. Currently, the list includes old versions of matplotlib.axes.BinOpType and wx.TheClipboard. * Support ROT_THREE and ROT_FOUR opcodes PyChecker is available on Source Forge: Web page: http://pychecker.sourceforge.net/ Project page: http://sourceforge.net/projects/pychecker/ Mailing List: pychecker-list(a)lists.sourceforge.net Enjoy and don't forget to provide feedback! Neal -- pychecker-list(a)lists.sourceforge.net

1 0

Notes from the Seneca Speaker Series talk on Python
by George Belotsky 03 Feb '06

03 Feb '06

The notes on the Python talk (formatted as S5 slides) that I gave as part of the Seneca Speaker Series are now available online: "http://cs.senecac.on.ca/speakers/docs/belotsky/". The talk is a brief tour on how to use Python in a complex project. This tour includes namespaces, Python's typesystem, descriptors, and refactoring of interfaces. It builds on my earlier, introductory Python talk at the same organization (which is Canada's largest college, with over 100,000 students): "http://cs.senecac.on.ca/soss/2005/presentations/george/index.html". This talk focuses on several very short examples, which show the immediate effectiveness (with minimal coding) of Python in diverse applications. If you like the S5 presentation system, you are welcome to download the theme from my slides, to use your own talks: "http://www.openlight.com/Python-S5-Theme.tar.gz". This theme modifies one of the original S5 themes, in order to give it a Python flavor. Best Wishes, George.

1 0

Movable Python 1.0.0 for Python 2.3 & 2.4
by Fuzzyman 03 Feb '06

03 Feb '06

It's finally happened, `Movable Python <http://www.voidspace.org.uk/python/movpy/>`_ is finally released. Versions for Python 2.3 & 2.4 are available from `The Movable Python Shop <http://voidspace.tradebit.com/groups.php>`_. The cost is £5 per distribution, payment by PayPal. £1 from every distribution goes to support the development of `SPE <http://pythonide.stani.be/>`_, the Python IDE. This gives you free support (via the `Movable Python Mailing List <http://groups.google.com/group/movpy>`_), and access to updates, for a year. There is a minor issue with the Python 2.2 version. This will be fixed and released in the next few days. In the meantime the previous version (0.4.6) is available for download from the shop. If you purchase this distribution your year will run from the date of the release of 1.0.0. Paying for **Movable Python** supports the development of the other Open Source `Voidspace Python Projects <http://www.voidspace.org.uk/python/index.shtml>`_. What is Movable Python ? =================== **Movable Python** is a distribution of Python for Windows that doesn't need to be installed. It easily fits onto a USB memory stick. Python on a stick. It is integrated with SPE, the Python IDE, to make **Movable Python** a portable Build, Test, and Run environment. It has a nice GUI to launch programs and control its behaviour. Movable Python is useful in the following situations: * Machines where you can't install programs. * Where you need a portable 'Build, Test, and Run' Python environment. * Having several versions of Python on the same machine for forward/backward compatibility testing. * Easily deploying Python scripts without having to install Python. * Try before you buy - test Python without having to install it, including new versions . * 'Python Runtime Environment'. '``.py``' files can be associated with movpy. For more information, see `An Introduction to Movable Python <http://www.voidspace.org.uk/python/movpy/introduction.html>`_. What's New ? ========== Changes since version 0.4.6. Completely new method for running files. This means you can launch multiple programs from the GUI. Lots of new libraries and tools included. Virtually all the included tools have had version upgrades since the last release. The GUI does a lot more : * Version number and Python version displayed on the GUI * You can pass arguments to your programs * It remembers the last directory you ran a program from * You choose if launched programs have a console box or not * You can configure the options programs are run with * You can edit the default options * Four configurable Quick Launch buttons * You can launch SPE from the GUI * You can launch the documentation (About) * You can launch an interpreter console * You can close the GUI without having to launch a program or go to the interpreter The following (command line) options are new : * ``f`` - run script in it's directory * ``b`` - pause after running script * ``o`` - override default options * ``die`` - get rid of GUI after running * ``k`` - run with console from movpyw * ``koff`` - run without console from movpy Complete documentation rewrite. Docs are now built with `rest2web <http://www.voidspace.org.uk/python/rest2web/>`_. ``movpyw.exe`` is now included in the Python 2.2 distribution. Bug fixed where first command line argument to your program was always lost. {sm;:oops:} Bug fixed so that ``IPOFF`` actually works now. Bug fixed so that ``-p`` in ``config.txt`` now works. Lots of other minor changes and improvements. {sm;:-)} Known Issues ========== There are some (minor) known issues with version 1.0.0. These will be fixed soon. * Version for Python 2.2 not yet available. * Possible issue running ``movpy.exe`` from long file paths on Windows 98. * The ``lib`` directory is not added to ``sys.path`` before entering interactive mode. There are also several items in the `TODO <http://www.voidspace.org.uk/python/movpy/TODO.html>`_ list. Many of these are future ways that **Movable Python** could be developed.

1 0

Roundup Issue Tracker release 1.0.1
by Richard Jones 03 Feb '06

03 Feb '06

I'm proud to release this, the 1.0.1 release of Roundup. Features in this release: - scripts/import_sf.py will import a tracker from Sourceforge.NET - added hasRole('Role Name') to HTMLUser Fixed in this release: - SQL generation for sort/group by separate Link properties (sf bug 1417565) - fix timezone offsetting in email Date: header - fix security check for hasPermission('Permission', None) If you're upgrading from an older version of Roundup you *must* follow the "Software Upgrade" guidelines given in the maintenance documentation. Roundup requires python 2.3 or later for correct operation. To give Roundup a try, just download (see below), unpack and run:: python demo.py Release info and download page: http://cheeseshop.python.org/pypi/roundup Source and documentation is available at the website: http://roundup.sourceforge.net/ Mailing lists - the place to ask questions: http://sourceforge.net/mail/?group_id=31577 About Roundup ============= Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this project. The contact for this project is richard(a)users.sourceforge.net. Roundup manages a number of issues (with flexible properties such as "description", "priority", and so on) and provides the ability to: (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.3+ installation. It doesn't even need to be "installed" to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates (a classic bug/feature tracker and a minimal skeleton) and five database back-ends (anydbm, sqlite, metakit, mysql and postgresql).

1 0

[ANNOUNCE] Twenty-eighth release of PythonCAD now available
by Art Haas 02 Feb '06

02 Feb '06

Hi. I'm pleased to announce the twenty-eighth development release of PythonCAD, a CAD package for open-source software users. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program that will match and eventually exceed features found in commercial CAD software. PythonCAD is released under the GNU Public License (GPL). PythonCAD requires Python 2.2 or newer. The interface is GTK 2.0 based, and uses the PyGTK module for interfacing to GTK. The design of PythonCAD is built around the idea of separating the interface from the back end as much as possible. By doing this, it is hoped that both GNOME and KDE interfaces can be added to PythonCAD through usage of the appropriate Python module. Addition of other PythonCAD interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The twenty-eighth release of PythonCAD offers improved abilities to edit entities in a drawing. Previous releases had inconsistent behavior for entity modification as some operations first required selecting then entities to change and then selecting the operation to perform, where other changes were accomplished by first selecting the action and then selecting entities. The latest release allows for entity modifications to be performed in either mode, thus making the code more consistent as well as easier to use. For people familiar with AutoCAD, PythonCAD now has 'NOUN->VERB' and 'VERB->NOUN' entity modification behavior. Numerous internal changes to the code utilizing more current functionality are also included in this release, in particular a rewrite of the entity moving code. Also, the ability to adjust the attributes of the text objects in a Dimension have been improved as well as simplified. And as usual, a wide number of bug fixes and other code enhancements are present in the release. A mailing list for the development and use of PythonCAD is available. Visit the following page for information about subscribing and viewing the mailing list archive: http://mail.python.org/mailman/listinfo/pythoncad Visit the PythonCAD web site for more information about what PythonCAD does and aims to be: http://www.pythoncad.org/ Come and join me in developing PythonCAD into a world class drafting program! Art Haas -- Man once surrendering his reason, has no remaining guard against absurdities the most monstrous, and like a ship without rudder, is the sport of every wind. -Thomas Jefferson to James Smith, 1822

1 0

ANN: OSCON 2006 (Python 14 Conference) Proposals due Feb. 13th
by Kevin Altis 02 Feb '06

02 Feb '06

OSCON 2006: Opening Innovation http://conferences.oreillynet.com/os2006/ Save the date for the 8th annual O'Reilly Open Source Convention, happening July 24-28, 2006 at the Oregon Convention Center in beautiful Portland, Oregon. Call For Participation ---------------------- Submit a proposal-fill out the form at: http://conferences.oreillynet.com/cs/os2006/create/e_sess/ Important Dates: * Proposals Due: Midnight (PST) February 13, 2006 * Speaker Notification: March 27, 2006 * Tutorial Presentation Files Due: June 12, 2006 * Session Presentation Files Due: June 26, 2006 * Conference: July 24-28, 2006 Proposals --------- We are considering proposals for 45 minute sessions and 3 hour tutorials. We rarely accept 90 minute proposals, as most general sessions are 45 minutes in length. Your proposals are examined by a committee which draws from them and which also solicits proposals to build the program. Proposals are due by midnight (PST), Feb. 13, 2006. The OSCON Speaker Manager, Vee McMillen, emails notification of the status of your talk (accepted or otherwise) by March 27, 2006. Unless the content of your talk is particularly timely (e.g., features of a product that will be launched at OSCON), you are required to send us your slides several weeks before the conference begins. Submit proposals via the form below. Some tips for writing a good proposal for a good talk: * Keep it free of marketing: talk about open source software, but not about a commercial product--the audience should be able to use and improve the things you talk about without paying money * Keep the audience in mind: they're technical, professional, and already pretty smart. * Clearly identify the level of the talk: is it for beginners to the topic, or for gurus? What knowledge should people have when they come to the talk? * Give it a simple and straightforward title: fancy and clever titles make it harder for people (committee and attendees) to figure out what you're really talking about * Limit the scope of the talk: in 45 minutes, you won't be able to cover Everything about Widget Framework X. Instead, pick a useful aspect, or a particular technique, or walk through a simple program. * Pages of code are unreadable: mere mortals can deal with code a line at a time. Sometimes three lines at a time. A page of code can't be read when it's projected, and can't be comprehended by the audience. * Explain why people will want to attend: is the framework gaining traction? Is the app critical to modern systems? Will they learn how to deploy it, program it, or just what it is? * Let us know in your proposal notes whether you can give all the talks you submitted proposals for * Explain what you will cover in the talk NOTE: All presenters whose talks are accepted (excluding Lightning Talks) will receive free registration at the conference. For each half-day tutorial, the presenter receives one night's accommodation, a limited travel allowance, and an honorarium. We give tutors and speakers registration to the convention (including tutorials), and tutors are eligible for a travel allowance: up to US$300 from the west coast of the USA, up to US$500 from the east coast of the USA, up to US$800 from outside the USA. Registration opens April, 2006. If you would like to be notified by email when registration opens, please use the form on our main page. CONFERENCE INFO =============== The O'Reilly Open Source Convention is where coders, sysadmins, entrepreneurs, and business people working in free and open source software gather to share ideas, discover code, and find solutions. At OSCON 2005, more than 2,400 attendees took part in 241 sessions and tutorials across eleven technology tracks, learning about the newest features and versions from creators and experts. A record number of products launches and announcements were made, and sponsors and exhibitors from a wide range of companies filled the largest exhibit hall in OSCON's history. We anticipate that OSCON 2006 will be even more successful, and continue to be the place for the open source community to meet up, debate, make deals, and connect face to face. OSCON 2006 will take place at the Oregon Convention Center in Portland, Oregon July 24-28, 2006. OSCON 2006 will feature the projects, technologies, and skills that you need to write and deploy killer modern apps. We're looking for proposals on platforms and applications around: * Multimedia including voice (VoIP) and video * AI including spam-busting, classification, clustering, and data mining * Collaboration including email, calendars, RSS, OPML, mashups, IM, presence, and session initialization * Project best practices including governance, starting a project, and managing communities * Microsoft Windows-based open source projects including .NET, Mono, and regular C/C++/Visual Basic Windows apps * Enterprise Java techniques including integration, testing, and scalable deployment solutions * Linux kernel skills for sysadmins including virtualization, tuning, and device drivers * Device hacking including iPods, Nintendo, PSP, XBox 360, and beyond * Design including CSS, GUI, and user experience (XP) * Entrepreneurial topics including management for techies, how to go into business for yourself, and business models that work * Security including hardening, hacking, root kits (Sony and otherwise), and intrusion detection/cleanup * Fun subjects with no immediate commercial application including retro computing, games, and BitTorrent Tracks at OSCON will include: * Desktop Apps * Databases, including MySQL, PostgreSQL, Ingres, and others * Emerging Topics * Java * Linux Kernel for SysAdmins * Linux for Programmers * Perl, celebrating the 10th year of The Perl Conference! * PHP * Programming, including everything that's not specific to a particular language * Python * Security * Ruby, including Ruby on Rails * Web Apps, including Apache * Windows

1 0

LDTP 0.3.0 released !!!
by A Nagappan 01 Feb '06

01 Feb '06

Hi, LDTP community has reached another important milestone with the release of LDTP 0.3.0. This release features the new architecture which is a result of more than 3 months of hard work by the LDTP community. This newsletter also includes latest news on our approach towards achieving an automated test engine. Useful references have been included at the end of this article for those who wish to hack/use LDTP. LDTP is now at version 0.3.0 ! Whats new in this release... + New Client Server Architecture: This release includes major changes in the architecture with LDTP using client/server architecture to handle more scenarios which were not possible with the previous versions. Thankfully, not much changes are required for the old scripts for them to be used. Kudos to the LDTP community for making this release a grand success. + Run time appmap generation (initialization of appmap is optional) Appmaps can be optional with the new LDTP as it can be generated autimatically at run time.This along with the Regular Expression (discussed below) feature will greatly minimise the script changes required after the GUI of the application to be tested changes. + Regular expression based object search (both context and component) This cool new feature enables the script writer to give regular expressions instead of complete names for the components under testing. This relieves the script writer from setting the context for different window titles. + For unexpected windows (example: connection reset by peer /connection timed out dialogs) can be handled by registering a callback function and the respective callback function will be called, whenever the registered window with the title appears and even this window could be based on regular expression + Programming language is no barrier for automation! Now the scripts can be written in any language even though the default one is Python. + Cleaner code base LDTP code base has been restructured and all the files follow proper coding guidelines. This helps newbies to get started with hacking LDTP more easily than ever before. This release is a promising one from the LDTP community with a bag full of features and lot more! so what are you waiting for. Grab your copy from the following link and start easing your work by automating using LDTP. Downloads... You can download the latest version of LDTP from http://ldtp.freedesktop.org/wiki/Downloads LDTP is available as rpm package. LDTP is also available as deb package for Debian and Ubuntu distributions. Thanks to Casanova (prashmohan(a)gmail.com) for the providing the same. For a step by step instruction on setting up LDTP please refer http://ldtp.freedesktop.org/wiki/How_20to_20setup_20pyldtp_20in_20GNU_2fLin… References For detailed information on LDTP framework and latest updates visit http://ldtp.freedesktop.org All the published newsletters including the current one can be downloaded from http://ldtp.freedesktop.org/wiki/Newsletters For release notes of every release including the current one please refer http://ldtp.freedesktop.org/wiki/Release_20Notes For information on various APIs in LDTP including those added for this release can be got from http://ldtp.freedesktop.org/wiki/API_20Reference To subscribe to LDTP mailing lists, visit http://ldtp.freedesktop.org/wiki/Mailing_20list IRC Channel - #ldtp on irc.freenode.net Thanks Nagappan Nagappan A <anagappan(a)novell.com> Linux Desktop Testing Project - http://gnomebangalore.org/ldtp http://nagappanal.blogspot.com

1 0

Python Meet Manchester 8th Feb, Lass O'Gowrie
by Michael Sparks 01 Feb '06

01 Feb '06

Hi, This is to announce what looks like it might be the first Python Meet Manchester - should be fun! It's happening NEXT week. * Where: Lass O'Gowrie Pub. Directions: http://tinyurl.com/cp3kv * When: 7pm onwards, Wed 8th Feb If you've been to one in London you know pretty much what to expect - a bunch of geeks in a pub talking, well, about python and stuff they find interesting as well as demos and informal talks. If you've used/ written/ found something you think's cool and want to talk about it & show it off please do. As it's the first time we've no idea if the Lass O'Gowrie will be ideal or not, and if it isn't there's always the possibility of a Python "Crawl" to solve that :-) Sign up page (not obligatory, but would be nice if people did - it at least has my ugly mug on as a point of reference for people :-) here: * http://tinyurl.com/a9cry Current topics people have offered up for discussion: * Turbo Gears * Kamaelia (Similar, but not identical, problem space to twisted for people who don't know what it is) * How to write "Pythonically". (I'm convinced you need to be dutch for that one myself ;-) Also if you're vaguely interested in python, but are interested in other things like RoR, please come along - the London meets are interesting because of the eclectic mix of people/interests :-) Likewise if there's anything you'd be interested in seeing/hearing about, please come and chat about it :) Please forward this around! See you there! Michael.

1 0

[ANN] filelike 0.1.1
by Ryan Kelly 01 Feb '06

01 Feb '06

Hi Everyone, I've just uploaded the first version of my module for building, wrapping and transforming file-like objects: filelike-0.1.1 More details at: http://www.rfk.id.au/software/projects/filelike/ At the Cheese Shop: http://cheeseshop.python.org/pypi/filelike/ Cheers, Ryan Description: ------------ The filelike module takes care of the groundwork for implementing and handling file-like objects that implement a rich file-like interface, including reading, writing, and iteration. It also provides a number of useful classes built on top of this functionality. The main class is FileLikeBase, which implements the entire file-like interface (currently minus seek() and tell()) on top of primitive _read() and _write() methods. Subclasses may implement either or both of these methods to obtain all the higher-level file behaviors. Two methods are provided for when code expects to deal with file-like objects: * is_filelike(obj): checks that an object is file-like * to_filelike(obj): wraps a variety of objects in a file-like interface On top of this framework are built a collection of useful classes, including: * TransFile: pass file contents through an arbitrary translation function (e.g. compression, encryption, ...) * FixedBlockSizeFile: ensure all read/write requests are aligned with a given blocksize * DecryptFile: on-the-fly reading and writing to an encrypted file (using PEP272 cipher API) As an example of the type of thing this module is designed to achieve, here's how to use the DecryptFile class to transparently access an encrypted file: # Create the decryption key from Crypto.Cipher import DES cipher = DES.new('abcdefgh',DES.MODE_ECB) # Open the encrypted file f = DecryptFile(file("some_encrypted_file.bin","r"),cipher) The object in <f> now behaves as a file-like object, transparently decrypting the file on-the-fly as it is read. -- 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

python-dev Summary for 2006-01-01 through 2006-01-15
by Tony Meyer 01 Feb '06

01 Feb '06

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2006-01-01_2006-01-15.html] ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- Guido, on the crashability of Python: I'm not saying it's uncrashable. I'm saying that if you crash it, it's a bug unless proven harebrained. Contributing thread: - `Include ctypes into core Python? <http://mail.python.org/pipermail/python-dev/2006-January/059621.html>`_ [SJB] ------------------------------------ Brett Cannon looking for Ph.D. ideas ------------------------------------ Brett Cannon is looking for Python-related ideas to form the subject of his PhD dissertation, under Eric Wohlstadter at the University of British Columbia. He has three areas in which he has possible funding (XML integration, game scripting support, and AOP); he is open to grants from anyone else interested in particular Python development. If anyone has suggestions for topics, Brett is listening! So far: * Phillip J. Eby mentioned that he has been doing some research on implementing a non-traditional form of AOP in Python. * Bill Janssen suggested a system to compile Python to AJAX. * Steve Holden suggested a Python learning system. * Ian Bicking suggested Boxer_ implemented for Python. * Armin Rigo suggested PyPy related work. * Jason Orendorff suggested collecting a downloadable corpus of Python source code, and performing various analyses on it. * Dennis Allison suggested interpreter structures for Python-like languages that do not use a global interpreter lock, as well as various other topics. .. _Boxer: http://dewey.soe.berkeley.edu/boxer.html Contributing thread: - `Ph.D. dissertation ideas? <http://mail.python.org/pipermail/python-dev/2006-January/059702.html>`__ [TAM] --------------------------------- 2.4 Documentation with Commentary --------------------------------- Ian Bicking put an instance_ of his commenting system, Commentary_, up against the full 2.4 documentation. If you'd like to see how the Python docs look with user-added comments, now's your chance! .. _instance: http://pythonpaste.org/comment/python24/ .. _Commentary: http://pythonpaste.org/commentary/ Contributing thread: - `[Doc-SIG] that library reference, again <http://mail.python.org/pipermail/python-dev/2006-January/059353.html>`__ [SJB] --------------------------------------- Builds of the Development Documentation --------------------------------------- Be sure to keep yourself up to date with the newest Python documentation - Neal Norwitz has arranged it so that the current Python development documentation is now automatically generated every 12 hours and placed at http://docs.python.org/dev/. Contributing thread: - `automated builds and tests <http://mail.python.org/pipermail/python-dev/2006-January/059362.html>`__ [SJB] -------------------------------- PEPs now automatically installed -------------------------------- Martin v. Löwis has arranged for an automatic installation of PEPs_: they will now get published in the subversion post-commit. Contributing thread: - `Installing PEPs <http://mail.python.org/pipermail/python-dev/2006-January/059745.html>`__ .. _PEPs: http://www.python.org/peps [TAM] ========= Summaries ========= --------------------------------------------------- Using buildbot to automate testing of Python builds --------------------------------------------------- A buildbot_ has been setup to facilitate `automated testing of the Python SVN`_. There are currently five slaves setup: * Linux x86 (gentoo 2.6, glibc 2.3) * Linux AMD64 (gentoo 2.6, glibc 2.3) * Solaris10 sparc * OS X 10.3 G5 * OS X 10.4 G4 Ideally, all supported platforms will be added (including OS, version, hardware, and various configurations); the slaves are testing the trunk and the 2.4 branch. Note that Window buildbot slaves have to have an appropriate compiler (MS VC 7.1), otherwise it can't compile the code; the Windows Python would also like to build several other packages (like bz2 and Tcl/Tk). A periodic "clean build" may also be added; there was discussion whether this should be done via a patch to the buildbot master, via an IRC command, or with a separate scheduler. Martin v. Löwis would rather buildbot produced static pages than act as a web server (for security reasons). Brian Warner explained that it once did, but was changed to make it easier to implement features like the "Force Build" button. An explanation of the security was given, and it seems satisfactory at the moment. The buildbot testing has already produced results: a compiler warning on OS X 10.3 was noticed. A discussion took place as to whether this should be fixed (it should) and who could do it (Ronald Oussoren volunteered, with help from Skip Montanaro). Fredrik Lundh had been playing with "automatic module discovery" in an attempt to figure out how complete the library reference really is, tracking down missing reference pages and generating stubs for pages that "should exist". He suggested that the buildbot could also run this script; at the time of this summary this was in progress. .. _automated testing of the Python SVN: http://www.python.org/dev/buildbot/ .. _buildbot: http://buildbot.sourceforge.net/ Contributing threads: - `buildbot <http://mail.python.org/pipermail/python-dev/2006-January/059359.html>`__ - `Buildbot questions <http://mail.python.org/pipermail/python-dev/2006-January/059429.html>`__ - `[Buildbot-devel] Re: buildbot <http://mail.python.org/pipermail/python-dev/2006-January/059455.html>`__ - `Automated Python testing <http://mail.python.org/pipermail/python-dev/2006-January/059460.html>`__ - `building a module catalogue with buildbot <http://mail.python.org/pipermail/python-dev/2006-January/059623.html>`__ - `Buildbot: doing occasional full builds <http://mail.python.org/pipermail/python-dev/2006-January/059643.html>`__ [TAM] ---------------------- A "Rejected Ideas" PEP ---------------------- Alexander Kozlovsky submitted a pre-PEP for the oft-repeated request that Python do away with its explicit "self" parameter. Guido responded with a definitive "This won't change", but didn't want to allow the PEP to be created just to be rejected. A number of people felt that the mailing lists weren't a sufficiently visible place for this response, especially considering the huge number of times the request has been presented. Thomas Wouters proposed a "Rejected Ideas" PEP that would list some of the more commonly raised proposals that weren't really even worthy of a PEP, with references to the appropriate python-list or python-dev discussions. Tim Peters nominated the alternate title "Don't Bother: PEPs Rejected Before Being Written" which perhaps better summarizes the intent. People seemed generally in favor of the idea, and Thomas Wouters offered to write up a first draft indicating three major rejected ideas: * removing the explicit "self" parameter * upgrading the Python parser beyond a simple LL(1) * allowing parentheses to be omitted in function calls At the time of this summary, no PEP was yet available. Contributing threads: - `Draft proposal: Implicit self in Python 3.0 <http://mail.python.org/pipermail/python-dev/2006-January/059446.html>`__ - `Rejected ideas PEP (was re: Draft proposal: Implicit self in Python 3.0) <http://mail.python.org/pipermail/python-dev/2006-January/059514.html>`__ [SJB] ------------------------------- Using ssize_t as the index type ------------------------------- Continuing from `last week`_, more process was made towards `PEP 353`_. Tim Peters, Neal Norwitz, and Martin v. Löwis discussed replacing '#' as a format character, and how this could be down in a backwards compatible way; they also discussed how Py_ssize_t could be output correctly in a printf-style statement. Martin suggested using %zd, but this isn't in VC 7.1; Tim suggested that a macro be added to pyport.h, which would use "z" where possible, and define something else where not (e.g. Windows). Tim also suggested that PyErr_Format() and PyString_Format() should be taught to recognize the "z" qualifier, with the macros hidden inside the implementation of those functions. M.-A. Lemburg pointed out other changes of output parameter types which will cause problems in extensions, and worried that authors wouldn't be able to get these converted in time for Python 2.5. Martin disagreed. While code will continue to work with 32-bit systems with little work, more needs to be done for 64-bit systems. Martin suggested that users could continue to use 32-bit Python (since nothing will be gained by using 64-bit anyway) until the required changes are made. For more details, see the "Open Issues" section of the PEP. .. _last week: http://www.python.org/dev/summary/2005-12-16_2005-12-31.html#using-ssize-t-… .. _PEP 353: http://www.python.org/peps/pep-0353.html Contributing threads: - `[Python-checkins] commit of r41906 - python/branches/ssize_t/Objects/obmalloc.c <http://mail.python.org/pipermail/python-dev/2006-January/059381.html>`__ - `New PEP: Using ssize_t as the index type <http://mail.python.org/pipermail/python-dev/2006-January/059437.html>`__ - `[Python-checkins] r41972 - python/branches/ssize_t/Objects/funcobject.c <http://mail.python.org/pipermail/python-dev/2006-January/059516.html>`__ - `Py_ssize_t output parameters (Was: [Python-checkins] r41971 ...) <http://mail.python.org/pipermail/python-dev/2006-January/059597.html>`__ [TAM] ------------------------------------- Adding ctypes to the standard library ------------------------------------- Thomas Heller suggested that ctypes be included in core Python (starting with 2.5). The common response was that while ctypes is a useful, popular, mature module, it does make it very easy to get a core dump, which violates the guideline that if you get a core dump it's a bug in Python or in a third party extension or you're doing something harebrained. On the other hand, it was pointed out that the dl module suffers from the same problem, and is included without any warnings (the documentation was later fixed to include warnings). Martin v. Löwis suggested making ctypes a dynamically loaded module (ctypes.pyd), so administrators could remove it, and I could also make it a separate option in the Windows installer, so administrators could opt out of installing it. Everyone seemed happy with prominent warnings in the documentation, so the plan was to check this in. However, licensing issues were hit with libffi, so the check-in is on hold for the moment. Stay tuned for more exciting news on this next fortnight! Contributing thread: - `Include ctypes into core Python? <http://mail.python.org/pipermail/python-dev/2006-January/059604.html>`__ [TAM] ----------------------------------------- Adding tests when no fix is yet available ----------------------------------------- After Georg Brandl checked in a test for the compiler module without a corresponding fix, Tim Peters reverted the change, indicating that no check-in should ever leave the repository in such a state that ``regrtest.py -uall`` fails. The ensuing thread discussed a number of ways of checking in a test for a bug when code to fix the bug was not yet available. Neal Norwitz proposed adding two files to Lib/test, outstanding_bugs.py and outstanding_crashes.py, which would include the appropriate tests, but which would not be run under ``regrtest.py -uall``. Some people were concerned about the maintainability of keeping failing tests for a module separate from the other tests of that module, so Neal Norwitz and Scott David Daniels presented a patch_ and a recipe_ for decorators that mark individual test functions as failing. No official pronouncement on how failing tests should be added to the Python test suite had been made at the time of this summary. .. _patch: http://python.org/sf/1399935 .. _recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/466288 Contributing thread: - `Checking in a broken test was: Re: [Python-checkins] r41940 - python/trunk/Lib/test/test_compiler.py <http://mail.python.org/pipermail/python-dev/2006-January/059481.html>`__ - `r42003 - python/trunk/Lib/test/outstanding_bugs.pypython/trunk/Lib/test/outstanding_crashes.py <http://mail.python.org/pipermail/python-dev/2006-January/059599.html>`__ [SJB] ------------------------------------------- Running the test suites in multiple locales ------------------------------------------- Georg Brandl noted that unicode format modifiers were (in SVN) incorrectly using the locale (one should always use locale.format to get locale-aware formatting). Fredrik Lundh suggested that all test should be run in a different locale than C to detect these bugs, perhaps adding a "use setlocale" flag to the test runner, to simplify this. Neal Norwitz made a patch to do this, finding a failure in test_email and two failures in test_re. Contributing thread: - `locale and LC_NUMERIC <http://mail.python.org/pipermail/python-dev/2006-January/059530.html>`__ [TAM] ----------------------------------------------------------- Replacing the docutils directory with an svn:externals link ----------------------------------------------------------- David Goodger replaced the static copy of docutils in the "peps" repository with a svn:externals link to the docutils repository. There was some concern about svn querying servers other than svn.python.org (the docutils repository is hosted on svn.berlios.de) and about linking to a potentially broken repository. David assured python-dev that the svn.berlios.de server was hardly ever unreachable, and changed the svn:externals link to select the 0.4 revision of docutils instead of the trunk. That guaranteed a non-broken copy of docutils, and made updating to a new revision just a simple propedit. Contributing thread: - `r42015 - peps/trunk <http://mail.python.org/pipermail/python-dev/2006-January/059676.html>`__ [SJB] -------------- Tkinter status -------------- A brief message from Joseph Rodrigues asking about the status of Tkinter in Python started a short thread about how Tkinter is maintained in Python. Martin v. Löwis is the primary maintainer, and he mainly focuses on integrating user contributions and making sure that Python is compatible with the latest release of Tcl/Tk. New widgets don't get wrapped automatically - if you want one supported, you should submit a patch. Contributing thread: - `Tkinter <http://mail.python.org/pipermail/python-dev/2006-January/059588.html>`__ [SJB] ------------------------------------ Roadmap for ConfigParser development ------------------------------------ Once again, the output capability of ConfigParser was brought up; this time by Facundo Bastista, who `submitted a patch`_ that orders the output so that doctest output can be easily reliable. He pointed out that there is `another open patch`_ that allows the user to specify the order through an "ordered dictionary". Guido explained that he didn't feel that it mattered, as long as the patch also allows comments to be preserved; his preference was for everything (ordering, blank lines, and comments) to be preserved. Tony Meyer point out some examples_ of previous_ `python-dev discussion`_ about how ConfigParser should be modified, and that SpamBayes_ includes a ConfigParser subclass that allows 'surgical' editing of files. .. _submitted a patch: http://python.org/sf/1399309 .. _another open patch: http://python.org/sf/1371075 .. _previous: http://mail.python.org/pipermail/python-dev/2004-October/049454.html .. _python-dev discussion: http://mail.python.org/pipermail/python-dev/2004-October/049527.html .. _examples: http://aspn.activestate.com/ASPN/Mail/Message/python-dev/1483518 .. _SpamBayes: http://spambayes.org Contributing thread: - `ConfigParser to save with order <http://mail.python.org/pipermail/python-dev/2006-January/059480.html>`__ [TAM] ------------------------------- Patches for the logging package ------------------------------- Shane Hathaway asked about the process for submitting patches for the logging package. Vinay Sajip is the primary maintainer, and accepts patches (compatible with Python 1.5.2) through sourceforge as normal, though personal emails are appropriate if you are worried about spending time on a patch that is not accepted. There was a brief followup discussion about how to get the logging package to interact nicely with external log rotation tools, including the possible creation of a ``reopen()`` function for files, but the thread trailed off without any solid conclusion on this issue. Contributing thread: - `Logging enhancements <http://mail.python.org/pipermail/python-dev/2006-January/059566.html>`__ [SJB] ---------------------------------- os.path.getmtime() bugs on Windows ---------------------------------- Christian Tismer noted that if, in a single interactive session on Windows, create a file, get its os.path.getmtime(), change your time zone, and get its os.path.getmtime() again, the time stamps are different. He asked whether there was a way to circumvent the problem, or if a patch could be created. Tim Peters gave him a `reference to a CodeProject page` that discusses the problem. Martin v. Löwis has meant to work on a patch for several years; his plan is to drop usage of msvcrt's stat(3), and instead implement os.stat in terms of Windows API directly - this would also have the advantage that subsecond time-stamps can be exposed. This patch would need to be implemented twice; once for Win9X (ANSI file names) and once for NT+ (unicode file names). .. _reference to a CodeProject page: http://www.codeproject.com/datetime/dstbugs.asp Contributing thread: - `os.path.getmtime on Windows <http://mail.python.org/pipermail/python-dev/2006-January/059741.html>`__ [TAM] ---------------------------------------- Generating Python-ast.c and Python-ast.h ---------------------------------------- Python-ast.c and Python-ast.h are generated automatically from Parser/asdl_c.py and then checked into Subversion. However, a ``make distclean`` removes these files, and if you do not have a 2.2+ version of Python available, they cannot be regenerated. The best solution seemed to be to alter ``make distclean`` to not remove Python-ast.c and Python-ast.h as they only need to be regenerated when the AST definition changes, which is rather infrequent. Contributing thread: - `[Python-checkins] commit of r41880 - python/trunk/Python/Python-ast.c <http://mail.python.org/pipermail/python-dev/2006-January/059356.html>`__ [SJB] ----------------------------------------- Allowing dict subclasses for exec globals ----------------------------------------- Currently, the ``exec`` statement allows the locals expression (the second expression after ``in``) to be any mapping type. The globals expression (the first expression after ``in``) should be a dict object, but Python does not currently raise an exception if you use a dict subclass, though it will not call any overridden methods correctly. `Crutcher Dunnavant presented a patch`_ that allows the globals expression to be a dictionary subclass such that overridden methods are called properly. Because it gives Python new capabilities, if the patch is accepted, it will not become part of Python until 2.5. .. _Crutcher Dunnavant presented a patch: http://www.python.org/sf/1402289 Contributing thread: - `[PATCH] Fix dictionary subclass semantics when used as global dictionaries <http://mail.python.org/pipermail/python-dev/2006-January/059625.html>`__ [SJB] -------------------------------------- Finding an appropriate recursion limit -------------------------------------- Python limits the depth of the function call stack. Too low a limit, and some functions fail needlessly. Too high a limit, and some programs get a segmentation fault instead of an exception. There is no easy, automated, way to find the "right" limit. Contributing thread: - `Limiting the recursion limit <http://mail.python.org/pipermail/python-dev/2006-January/059652.html>`__ [Jim Jewett] ------------------------ When is a PEP necessary? ------------------------ Q. Why are so many PEPs about changes to syntax or the core language instead of (less intrusive) changes to the standard library? A. Unintrusive changes to the standard library can often just go in without the overhead of a PEP. This process *is* different from some other languages. Contributing thread: - `PEP and stdlib <http://mail.python.org/pipermail/python-dev/2006-January/059694.html>`__ [Jim Jewett] -------------------------------- Mixing file iteration techniques -------------------------------- 'for lines in file:' uses a buffer; doing an explicit readline does not use that buffer, which can lead to corrupted data. Thomas Wouters submitted a patch to raise an error instead of silently corrupting data. For backwards compatibility, it still doesn't complain when the mixing doesn't happen to corrupt data. He chose to raise an error instead of correcting the problem (by using the buffer exactly when he now raises an error) to minimize the changes. Contributing thread: - `file.next() vs. file.readline() <http://mail.python.org/pipermail/python-dev/2006-January/059410.html>`__ [Jim Jewett] ------------------------------------- Multiple interpreters sharing objects ------------------------------------- Having multiple interpreters sharing the same object isn't heavily tested. There is a threading-related bug (fixed in 2.4.2) that can result in (false) complaints about being run in restricted mode. In addition, if a thread finishes, another interpreter might reuse the thread id, which wasn't quite fully cleaned up. Various small patches were proposed; none are perfect, all are probably an improvement. Contributing threads: - `Sharing between multiple interpreters and restricted mode <http://mail.python.org/pipermail/python-dev/2006-January/059412.html>`__ - `PyThreadState_Delete vs PyThreadState_DeleteCurrent <http://mail.python.org/pipermail/python-dev/2006-January/059595.html>`__ - `pystate.c changes for Python 2.4.2 <http://mail.python.org/pipermail/python-dev/2006-January/059716.html>`__ [Jim Jewett] ----------------------------- Unicode exceptions with print ----------------------------- What to do if the output encoding can't handle the text you just sent it? Should it just substitute something (losing information) or should it really throw an exception? (What is wrong? Argh! I can't even print the bad data out!) Contributing thread: - `Unicode print/stdoutput exceptions are not nice <http://mail.python.org/pipermail/python-dev/2006-January/059715.html>`__ [Jim Jewett] -------------- curses testing -------------- Alone, the setupterm call [curses.setupterm(sys.__stdout__.fileno())] does nothing remarkable, but when it is done inside of curses.initscr() / curses.endwin() the terminal is not restored properly. Georg Brandl thinks that if setupterm() is to be tested, it should be executed before initscr(). Contributing thread: - `Birkenfeld's gone <http://mail.python.org/pipermail/python-dev/2006-January/059492.html>`__ [Jim Jewett] --------------------- Momentary API changes --------------------- Some functions were turned into macros, which are not so good for dynamic linking. This was later fixed. Contributing thread: - `API changes <http://mail.python.org/pipermail/python-dev/2006-January/059374.html>`__ [Jim Jewett] ---------------------- sudo security concerns ---------------------- If you can run a script as someone else (including root), and can set the environment variables, then you can get a python interactive session as that someone. Contributing thread: - `sudo security hole w/ potential Python connection <http://mail.python.org/pipermail/python-dev/2006-January/059586.html>`__ [Jim Jewett] ---------------------------- Problems with tar on Solaris ---------------------------- GNU tar should be used on Solaris, as the Solaris tar has problems. Contributing thread: - `TAR problems under Solaris <http://mail.python.org/pipermail/python-dev/2006-January/059415.html>`__ [Jim Jewett] ---------------------------- That which we call a rose... ---------------------------- "Reinhold Birkenfeld" was a pseudonym Georg Brandl first used when he was sixteen. Three years (plus change) later, he has decided to become known within the Python development community by his real name. Among the expected humourous replies, there was some discussion about whether pseudonyms should be permitted for people contributing to Python, but this (including exactly what a "contribution" is) wasn't resolved. Contributing thread: - `Birkenfeld's gone <http://mail.python.org/pipermail/python-dev/2006-January/059492.html>`__ [TAM] ================== Previous Summaries ================== - `When do sets shrink? <http://mail.python.org/pipermail/python-dev/2006-January/059346.html>`__ - `Including zlib... <http://mail.python.org/pipermail/python-dev/2006-January/059372.html>`__ - `a quit that actually quits <http://mail.python.org/pipermail/python-dev/2006-January/059384.html>`__ - `Real time behaviour of Pythons memory management; WAS: RE: Documentation about Python's GC,python-dev list messages referenced in Modules/gcmodule.c notreachable anymore <http://mail.python.org/pipermail/python-dev/2006-January/059408.html>`__ - `slight inconsistency in svn checkin email subject lines <http://mail.python.org/pipermail/python-dev/2006-January/059355.html>`__ - `buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in) <http://mail.python.org/pipermail/python-dev/2006-January/059419.html>`__ =============== Skipped Threads =============== - `Weekly Python Patch/Bug Summary <http://mail.python.org/pipermail/python-dev/2006-January/059352.html>`__ - `current test problems <http://mail.python.org/pipermail/python-dev/2006-January/059360.html>`__ - `mac memory leaks <http://mail.python.org/pipermail/python-dev/2006-January/059367.html>`__ - `bsddb broken <http://mail.python.org/pipermail/python-dev/2006-January/059425.html>`__ - `Jython and CPython <http://mail.python.org/pipermail/python-dev/2006-January/059434.html>`__ - `Compiler warnings for 64-bit portability problems <http://mail.python.org/pipermail/python-dev/2006-January/059464.html>`__ - `some interesting readings <http://mail.python.org/pipermail/python-dev/2006-January/059482.html>`__ - `Birkenfeld's gone <http://mail.python.org/pipermail/python-dev/2006-January/059492.html>`__ - `Python-Dev Digest, Vol 29, Issue 111 <http://mail.python.org/pipermail/python-dev/2006-January/059494.html>`__ - `PyCon TX 2006: Early-bird registration ends Jan. 15! <http://mail.python.org/pipermail/python-dev/2006-January/059511.html>`__ - `test_curses <http://mail.python.org/pipermail/python-dev/2006-January/059528.html>`__ - `sudo security hole w/ potential Python connection <http://mail.python.org/pipermail/python-dev/2006-January/059586.html>`__ - `Python-Dev Digest, Vol 30, Issue 32 <http://mail.python.org/pipermail/python-dev/2006-January/059587.html>`__ - `Hello <http://mail.python.org/pipermail/python-dev/2006-January/059628.html>`__ - `DRAFT: python-dev Summary for 2005-12-01 through 2005-12-15 <http://mail.python.org/pipermail/python-dev/2006-January/059713.html>`__ - `DRAFT: python-dev Summary for 2005-12-16 through 2005-12-31 <http://mail.python.org/pipermail/python-dev/2006-January/059717.html>`__ - `DRAFT: python-dev Summary for 2005-12-16 through2005-12-31 <http://mail.python.org/pipermail/python-dev/2006-January/059726.html>`__ - `Python icon <http://mail.python.org/pipermail/python-dev/2006-January/059738.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from January 01, 2006 through January 15, 2006. 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 11th summary written by the python-dev summary deuce of Steve Bethard and Tony Meyer (Happy New Year!). 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-12-01_2005-12-15.html .. _original text file: http://www.python.org/dev/summary/2006-01-01_2006-01-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0