From miles.chris at gmail.com Tue Nov 1 01:25:43 2005 From: miles.chris at gmail.com (Chris Miles) Date: Tue, 1 Nov 2005 00:25:43 +0000 Subject: EDDIE-Tool 0.35 Released Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 EDDIE-Tool 0.35 has just been released. http://eddie-tool.net/ What is it ? The EDDIE-Tool is an intelligent UNIX monitoring agent written entirely in Python. It provides system, network and security monitoring features, with an extensive configuration facility for defining customized monitoring and data collection rules. What is new ? This version has been a long time coming but check out all the added features, including support for two new platforms. * FreeBSD support; * Microsoft Windows support; * Solaris 10 support; * Better support for Linux kernel 2.6; * SMTP response time monitoring; * FILE directive can show diffs when monitored files are modified; * Disk/filesystem throughput measuring on Solaris; * Many more enhancements and bugfixes - see http://eddie-tool.net/ doc/CHANGES Why is it interesting to Python users ? Besides system and network administrators, Python users may find EDDIE-Tool interesting as it is an example of a threaded, multi-platform software package, providing easy access to system statistics and using Python's power to offer a dynamic and programmable rules engine. Regards, Chris - -- Chris Miles http://chrismiles.info/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFDZrYUzitzBnMzNcIRAlQ+AKCTERmPUiDYYOgFxM1ZY/+Vz42PTgCfXJTd bK5yTX196OMQkJSQn/mDnTo= =IlNN -----END PGP SIGNATURE----- From calfdog at yahoo.com Tue Nov 1 05:26:54 2005 From: calfdog at yahoo.com (calfdog@yahoo.com) Date: 31 Oct 2005 20:26:54 -0800 Subject: cPAMIE18 released! - Python Automation module for Internet Explorer Message-ID: <1130819214.443761.26930@g43g2000cwa.googlegroups.com> What is PAMIE? PAMIE stands for Python Automation module for Internet Explorer. Requirements: ------------ * Window 2000, WinNT, WinXP * Python 2.4.x (I use Active State Python 2.4.x since it installs the needed win32all library) Optional tools for writing scripts: * Eclipse with pydev plugin ( great for writing, running and debugging scripts) - recommended!! * Emacs - for script writing * Notepad++ - for script writing * PythonWin IDE installed with Activestate Python - http://www.Activestate.org - for script writing and running ========================================================================== This was completely written in Python to be used as a QA/Development tool for Web testing. You will find this is one of the easiest automation tool to use for automating Internet Explorer. PAMIE is a class file (cPAMIE.py) that you import and you can calls its methods to write scripts that automate your IE browser client. Used with PY unit you can write complex Web testing frameworks. Uses: * Automate Web testing * Use along with Jmeter for Performance testing. * Load Testing ========================================================================== New Enhancements: ---------------- Frames support improved report status Just a few of the methods available: ------------------------------------ _frameWait - waits for user speficied frame document to load _wait - wait for documetn to load checkForFormName - check to see if a formname exists in the document checkForFrameName -- check to see if a framename exists ClickBtnImage - Clicks on an input type image button ClickButton - Click on a button ClickImage - clicks on an Image ClickLink - Clicks on a link ClickMenu - Clicks on an menu item,link ClickMenuImage - Clicks on an menu item that is a image. Click a Menu or Sub Menu Item ClickNthImage click on the Nth Image ClickNthLink - click on the Nth link ClickOuterLink - clicks on a link using outertext ClickPageLink - click on the page link GetTextBox - get tectbox value SettextBox - Sets texbox value GetNames - get the names of the form elements GetListbox - gets selected listbox item SetlistBox - sets selected listbox item GetRadioButton - Gets Radio button status SetRadioButton - Sets Radio button GetRadioButtonSet - same as above and much much more !!! Check it out! Thank you R.L. Marchetti From calfdog at yahoo.com Tue Nov 1 05:39:51 2005 From: calfdog at yahoo.com (calfdog@yahoo.com) Date: 31 Oct 2005 20:39:51 -0800 Subject: cPAMIE18 released!! - Python Automation module for Internet Explorer Message-ID: <1130819991.021399.17570@o13g2000cwo.googlegroups.com> URL: http://pamie.sourceforge.net What is PAMIE? PAMIE stands for Python Automation module for Internet Explorer. This is a free opensource tool that allows you to use Python to drive Internet Explorer. Designed for QA engineers with scripting ability. If you haved used the big commercial automation tools you will fine this easy to use. There is no record/playback, just script and validate. Requirements: ------------ * Window 2000, WinNT, WinXP * Python 2.4.x (I use Active State Python 2.4.x since it installs the needed win32all library) Optional tools for writing scripts: * Eclipse with pydev plugin ( great for writing, running and debugging scripts) - recommended!! * Emacs - for script writing * Notepad++ - for script writing * PythonWin IDE installed with Activestate Python - http://www.Activestate.org - for script writing and running ========================================================================== This was completely written in Python to be used as a QA/Development tool for Web testing. You will find this is one of the easiest automation tool to use for automating Internet Explorer. PAMIE is a class file (cPAMIE.py) that you import and you can calls its methods to write scripts that automate your IE browser client. Used with PY unit you can write complex Web testing frameworks. Uses: * Automate Web testing * Use along with Jmeter for Performance testing. * Load Testing ========================================================================== New Enhancements: ---------------- Frames support improved report status Just a few of the methods available: ------------------------------------ _frameWait - waits for user speficied frame document to load _wait - wait for documetn to load checkForFormName - check to see if a formname exists in the document checkForFrameName -- check to see if a framename exists ClickBtnImage - Clicks on an input type image button ClickButton - Click on a button ClickImage - clicks on an Image ClickLink - Clicks on a link ClickMenu - Clicks on an menu item,link ClickMenuImage - Clicks on an menu item that is a image. Click a Menu or Sub Menu Item ClickNthImage click on the Nth Image ClickNthLink - click on the Nth link ClickOuterLink - clicks on a link using outertext ClickPageLink - click on the page link ClickIndexLink printLinkIndex GetTextBox - get tectbox value SettextBox - Sets texbox value GetNames - get the names of the form elements GetListbox - gets selected listbox item SetlistBox - sets selected listbox item GetRadioButton - Gets Radio button status SetRadioButton - Sets Radio button GetRadioButtonSet - same as above getTableData - returns the text in table showAllTableText - finds all text(indexed)in table on the web page showTableLinkText - finds the link text dialogcontroller - manipulates modal dialogs ExecuteJS - executes a JavaScript Function on the page and much much more !!! Check it out! Thank you R.L. Marchetti From webmaster at keyphrene.com Tue Nov 1 10:04:41 2005 From: webmaster at keyphrene.com (webmaster@keyphrene.com) Date: Tue, 01 Nov 2005 09:04:41 GMT Subject: ANN: Naja 1.2.7 is now available Message-ID: <43672e5c$0$7585$636a15ce@news.free.fr> Naja is a download manager and a website grabber written in Python/wxPython.You can add some plugins (newsreader, newsgroups grabber, FTP - FTPS - SFTP client,WebDAV client) and take control of your downloads from your office. Naja supports proxy (HTTP, HTTPS, FTP,SOCKS v4a, SOCKSv5), and use some authentication methods.The downloading maybe achieved by splitting the file being downloaded into several parts and downloading these parts at the same time (HTTP,HTTPS,FTP). Donwload speeds are increased by downloading the file from the mirrors sites,when the sites propose it. Others features: Csv filter Cheksums (CRC32, MD2, MD4, MD5, SHA, SHA1, MDC2, RMD160) Crypt (Only for the eXtended version) and Decrypt (AES, DES, 3DES ...) newsreader, newsposter (uue, yEnc) CGI & WebDAV Server Web Interface basic and digest authentication for client and server Compress and decompress (zip, tar.gz, tar.bz2) Picture viewer (multi-protocol) Text Editor Naja is available for download from the Keyphrene web site: http://www.keyphrene.com/products/naja From bdivito at cox.net Tue Nov 1 03:46:10 2005 From: bdivito at cox.net (Ben Di Vito) Date: Mon, 31 Oct 2005 21:46:10 -0500 Subject: Initial release of Pathena Desktop Search Message-ID: Pathena is a new experimental application for indexing files on desktops running Unix-family operating systems. It was designed with technically oriented users in mind. Pathena consists of a PostgreSQL server plus a GUI client implemented with Python and Tkinter. Tsearch2, a companion package distributed with PostgreSQL, provides the full-text search engine. Search features enable users to find files based on path name or file content. User-defined profiles guide the discovery of relevant items within the user's file system. The initial set of supported file types includes text and source files, e-mail messages in 'maildir' format, various document types, and assorted others. Pathena is registered on PgFoundry, the PostgreSQL Development Group's site for developing and publishing PostgreSQL-related software. A longer description of the tool is available on the home page: http://pathena.projects.postgresql.org/ A project page is also available on PgFoundry: http://pgfoundry.org/projects/pathena/ The release can be downloaded from either place. Ben Di Vito From gary at modernsongs.com Tue Nov 1 23:06:55 2005 From: gary at modernsongs.com (Gary Poster) Date: Tue, 1 Nov 2005 17:06:55 -0500 Subject: Fredericksburg, VA ZPUG Meeting: November 9, 7:30-9:00 PM Message-ID: <4881F4B4-8574-4207-9C7B-C7A78AF556DB@modernsongs.com> Please join us November 9, 7:30-9:00 PM, for the sixth meeting of the Fredericksburg, VA Zope and Python User Group ("ZPUG"). Squid and Zope! Using Zope for newspaper publishing! The dangers of object oriented inheritance! Free food! * Andrew Sawyers will discuss using the open source cache server Squid with Zope, including a discussion of the O'Reilly book about Squid. * Allen Schmidt, Sr. Programmer for Fredericksburg.com - the website for the Free Lance-Star - will present on "Using Zope for Newspaper Publishing". * Jim Fulton, CTO of Zope Corporation, will present an abbreviated version of the argument given in Clemens Szyperski's Component Software for why both inheritance and delegation (e.g. acquisition) cause tight coupling and therefore should be avoided except in special circumstances. * We will serve delicious fruit, cheese, and soft drinks. We've had a nice group for all the meetings. Please come and bring friends! We also are now members of the O'Reilly and Apress user group programs, which gives us nice book discounts (prices better than Amazon's, for instance) and the possibility of free review copies. Ask me about details at the meeting if you are interested. General ZPUG information When: second Wednesday of every month, 7:30-9:00. Where: Zope Corporation offices. 513 Prince Edward Street; Fredericksburg, VA 22408 (tinyurl for map is http://tinyurl.com/duoab). Parking: Zope Corporation parking lot; entrance on Prince Edward Street. Topics: As desired (and offered) by participants, within the constraints of having to do with Python or Zope. Contact: Gary Poster (gary at zope.com) From hpk at trillke.net Thu Nov 3 13:48:55 2005 From: hpk at trillke.net (holger krekel) Date: Thu, 3 Nov 2005 13:48:55 +0100 Subject: pypy 0.8.0 released Message-ID: <20051103124855.GG23762@solar.trillke.net> pypy-0.8.0: Translatable compiler/parser and some more speed ============================================================== The PyPy development team has been busy working and we've now packaged our latest improvements, completed work and new experiments as version 0.8.0, our third public release. The highlights of this third release of PyPy are: - Translatable parser and AST compiler. PyPy now integrates its own compiler based on Python own 'compiler' package but with a number of fixes and code simplifications in order to get it translated with the rest of PyPy. This makes using the translated pypy interactively much more pleasant, as compilation is considerably faster than in 0.7.0. - Some Speed enhancements. Translated PyPy is now about 10 times faster than 0.7 but still 10-20 times slower than CPython on pystones and other benchmarks. At the same time, language compliancy has been slightly increased compared to 0.7 which had already reached major CPython compliancy goals. - Some experimental features are now translateable. Since 0.6.0, PyPy shipped with an experimental Object Space (the part of PyPy implementing Python object operations and manipulation) implementing lazily computed objects, the "Thunk" object space. With 0.8.0 this object space can also be translated preserving its feature additions. What is PyPy (about)? ------------------------------------------------ PyPy is a MIT-licensed research-oriented reimplementation of Python written in Python itself, flexible and easy to experiment with. It translates itself to lower level languages. Our goals are to target a large variety of platforms, small and large, by providing a compilation toolsuite that can produce custom Python versions. Platform, Memory and Threading models are to become aspects of the translation process - as opposed to encoding low level details into a language implementation itself. Eventually, dynamic optimization techniques - implemented as another translation aspect - should become robust against language changes. Note that PyPy is mainly a research and development project and does not by itself focus on getting a production-ready Python implementation although we do hope and expect it to become a viable contender in that area sometime next year. PyPy is partially funded as a research project under the European Union's IST programme. Where to start? ----------------------------- Getting started: http://codespeak.net/pypy/dist/pypy/doc/getting-started.html PyPy Documentation: http://codespeak.net/pypy/dist/pypy/doc/ PyPy Homepage: http://codespeak.net/pypy/ The interpreter and object model implementations shipped with the 0.8 version can run on their own and implement the core language features of Python as of CPython 2.4. However, we still do not recommend using PyPy for anything else than for education, playing or research purposes. Ongoing work and near term goals --------------------------------- At the last sprint in Paris we started exploring the new directions of our work, in terms of extending and optimising PyPy further. We started to scratch the surface of Just-In-Time compiler related work, which we still expect will be the major source of our future speed improvements and some successful amount of work has been done on the support needed for stackless-like features. This release also includes the snapshots in preliminary or embryonic form of the following interesting but yet not completed sub projects: - The OOtyper, a RTyper variation for higher-level backends (Squeak, ...) - A JavaScript backend - A limited (PPC) assembler backend (this related to the JIT) - some bits for a socket module PyPy has been developed during approximately 16 coding sprints across Europe and the US. It continues to be a very dynamically and incrementally evolving project with many of these one-week workshops to follow. PyPy has been a community effort from the start and it would not have got that far without the coding and feedback support from numerous people. Please feel free to give feedback and raise questions. contact points: http://codespeak.net/pypy/dist/pypy/doc/contact.html have fun, the pypy team, (Armin Rigo, Samuele Pedroni, Holger Krekel, Christian Tismer, Carl Friedrich Bolz, Michael Hudson, and many others: http://codespeak.net/pypy/dist/pypy/doc/contributor.html) PyPy development and activities happen as an open source project and with the support of a consortium partially funded by a two year European Union IST research grant. The full partners of that consortium are: Heinrich-Heine University (Germany), AB Strakt (Sweden) merlinux GmbH (Germany), tismerysoft GmbH (Germany) Logilab Paris (France), DFKI GmbH (Germany) ChangeMaker (Sweden), Impara (Germany) From mscott at goldenspud.com Wed Nov 2 19:15:20 2005 From: mscott at goldenspud.com (Matthew Scott) Date: Wed, 2 Nov 2005 12:15:20 -0600 Subject: ANN: Schevo 3.0-beta1 released Message-ID: ================== Schevo 3.0-beta1 ================== ---------------------- Release Announcement ---------------------- Also available at http://schevo.org/latest/release/announcements/3.0-beta1.html What's new in version 3.0-beta1? ================================ * Initial release of Schevo 3.0 series. Get Schevo! =========== See the `Schevo website`_ for more information, or go ahead and `get started with Schevo`_. .. _Schevo website: http://schevo.org/ .. _get started with Schevo: http://schevo.org/latest/guides/getting-started.html What is Schevo? =============== Schevo is a next-generation DBMS that focuses on the following: - **Database Integrity**: Schevo is designed from the ground up to protect your data. All changes to a Schevo database must be done using transactions, and Schevo ensures that those transactions always leave the database in a consistent state. - **Rapid Development**: Schevo includes features to make it easy and fun to create even the most complex of databases. Not only is the schema syntax easy to write and understand, you can also quickly place initial values in your schema that are required by your database, and use the same syntax to create sets of sample data to use during development. - **User Interface Generation**: Schevo provides user interface toolkits that take advantage of the richness of the database schema. You can use the full-featured Schevo Navigator to interact with your database without writing a single line of code outside of your database schema. A PyQt-based toolkit is already available, and TurboGears and NuFox toolkits are in the works. - **Rich Schema Definition**: The schema for a Schevo database is written in concise, easy-to-read Python code. Not only does the schema describe how information in the database is structured, but also defines all transactions and rules that ensure database integrity. - **Assisted Schema Evolution**: Once a Schevo database is deployed and is used to store valuable data, you will inevitably make further changes to the structure of the database. Schevo assists you in this task and makes it easy to restructure a database and facilitate the migration of data from one schema version to the next. Why use Schevo? =============== The main problem that Schevo was designed to address is that Relational databases, which use Structured Query Language (SQL), do not match well with object-oriented programming languages, such as Java, Python and Ruby. This situation has been labeled the "object-relational impedance mismatch" problem, and it is a significant barrier to the rapid development and evolution of database applications. Because of this mismatch, database applications tend to have three distinct layers of code: SQL within the database, object-oriented code within the application, and an object-relational mapping (ORM) layer to mediate between the SQL and the object language. These extra layers add additional complexity and inflexibility to what are already complex and inflexible databases. Schevo eliminates these extra layers. Schevo solves the object-relational impedance mismatch problem by combining relational features with the object-oriented programming language Python. A database schema defined in Schevo results in a database that enforces the same integrity constraints supported by the Relational model, with the added benefit of Python objects. The benefit of this is that application developers can create their entire application using the full power of the Python language without having to introduce another language (SQL) that has its own language constructs, its own datatypes, and a limited set of behavior. Instead, a Schevo database stores Schevo objects which use native Python datatypes and include any behavior defined for those objects. In addition, Schevo objects contain a great deal of metadata that is available for introspection to support the development of rich user interfaces with a minimal amount of code. In fact, Schevo includes a GUI Navigator that can display a fully interactive interface into any Schevo database. The Navigator is constructed on-the-fly based solely on the metadata available within the Schevo database file. The Navigator allows you to display, create, update, and delete any object within the database, within the rules and constraints defined for that database. -- Matthew R. Scott From spe.stani.be at gmail.com Wed Nov 2 21:25:47 2005 From: spe.stani.be at gmail.com (spe.stani.be@gmail.com) Date: 2 Nov 2005 12:25:47 -0800 Subject: SPE 0.7.5.e - Python IDE with improved uml, debugger & unicode support Message-ID: <1130963147.252324.200620@g43g2000cwa.googlegroups.com> What's new? SPE now creates backup files and can insert your standard signature (with for example license and copyright information) in your code. A bug that prevented SPE to start on Linux has been fixed and also a lot of bugfixes were implemented, especially for unicode. You can read more on the SPE news blog. If you like SPE, please contribute by coding, writing documentation or donating. Spread the word on blogs, ... It would be nice if some (experienced) Mac users would subscribe to the developers mailing list to speed up the Mac port for SPE. I expect my new Mac any moment. Spe is a python IDE with auto-indentation, auto completion, call tips, syntax coloring, uml viewer, syntax highlighting, class explorer, source index, auto todo list, sticky notes, integrated pycrust shell, python file browser, recent file browser, drag&drop, context help, ... Special is its blender support with a blender 3d object browser and its ability to run interactively inside blender. Spe ships with wxGlade (gui designer), PyChecker (source code doctor) and Kiki (regular expression console). Spe is extensible with wxGlade. Stani -- http://pythonide.stani.be http://pythonide.stani.be/manual/html/manual.html From fabioz at esss.com.br Thu Nov 3 17:48:17 2005 From: fabioz at esss.com.br (Fabio Zadrozny) Date: Thu, 03 Nov 2005 14:48:17 -0200 Subject: PyDev 0.9.8.4 released In-Reply-To: <434E801E.3010702@esss.com.br> References: <43382E1F.3000600@esss.com.br> <434E801E.3010702@esss.com.br> Message-ID: <436A3F51.8080603@esss.com.br> Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.4 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.4 Major highlights: ------------------------ * The license was changed to EPL. It can be found at: http://www.opensource.org/licenses/eclipse-1.0.php * Code-completion information is now saved in deltas instead of "saving only at shutdown" (being so, it does not loose information if it does not have a regular shut-down). Others that are new and noteworthy: ----------------------------------------------------- * Added option for not using the smart-indent after opening brackets * Some step-by-step instructions of how to get started with pydev have been contributed by Jack Trainor. * Many bugfixes Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com From bvdp at uniserve.com Thu Nov 3 22:54:26 2005 From: bvdp at uniserve.com (Bob van der Poel) Date: Thu, 03 Nov 2005 14:54:26 -0700 Subject: MMA - Musical MIDI Accompaniment 0.18 now available Message-ID: <11ml1sg45b5a4b0@corp.supernews.com> Beta 0.18 of MMA - Musical MIDI Accompaniment - is now available for downloading. Included in this release: Enhancements to lyrics, macros, command line macro define, various bug fixes, and minor syntax changes. MMA is a accompaniment generator -- it creates midi tracks for a soloist to perform with. User supplied files contain pattern selections, chords, and MMA directives. For full details please visit: http://mypage.uniserve.com/~bvdp/mma/ If you have any questions or comments, please send them to: bvdp at uniserve.com -- Bob van der Poel ** Wynndel, British Columbia, CANADA ** EMAIL: bvdp at uniserve.com WWW: http://mypage.uniserve.com/~bvdp From edreamleo at charter.net Sat Nov 5 14:06:46 2005 From: edreamleo at charter.net (Edward K. Ream) Date: Sat, 5 Nov 2005 07:06:46 -0600 Subject: Leo 4.4a2 withdrawn Message-ID: <192bf.39$4i6.18@fe06.lga> Leo 4.4a2 has been withdrawn due to problems that can cause Leo to lose what you have recently typed. Leo 4.4a3 will be released in about a week. Edward -------------------------------------------------------------------- Edward K. Ream email: edreamleo at charter.net Leo: http://webpages.charter.net/edreamleo/front.html -------------------------------------------------------------------- From sh at defuze.org Sun Nov 6 00:38:26 2005 From: sh at defuze.org (Sylvain Hellegouarch) Date: Sun, 6 Nov 2005 00:38:26 +0100 Subject: ANN: atomixlib 0.3.0 Message-ID: <1131233906.436d4272426e4@webmail.defuze.org> ================ atomixlib 0.3.0 ================ Available at : http://www.defuze.org/oss/atomixlib/ What's new? ================ * It breaks the compatibility with previous version. Mainly you do not need to pass the current atom element being constructed to the Atomix methods. Instead the Atomix class keeps an handle to that element internally. * It adds a lot more documentation via docstrings and an epydoc version of the API. * It fixes some issues with XHTML content * It is more flexible for creating the atom document (feed or entry based). * It improves performances of atomixlib since 0.2.0 Get atomixlib ================ http://www.defuze.org/oss/atomixlib/download/atomixlib-0.3.0.tgz What's atomixlib? ================ A Python module to facilitate Atom 1.0 documents generation. License ================ BSD Credits ================ I would like to thank Uche Ogbuji for discussing atomixlib so much and giving me some very neat ideas. Enjoy! - Sylvain Hellegouarch sh defuze.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From ian at excess.org Sun Nov 6 03:23:58 2005 From: ian at excess.org (Ian Ward) Date: Sat, 5 Nov 2005 21:23:58 -0500 Subject: ANN: Speedometer 2.1 - bandwidth and download monitor Message-ID: <20051106022358.GA2364@paintedblack> Announcing Speedometer 2.1 -------------------------- Speedometer home page: http://excess.org/speedometer/ Download: http://excess.org/speedometer/speedometer.py New in this release: ==================== - New simultaneous display of multiple graphs with options for stacking graphs vertically or horizontally - New labels to differentiate each graph - Removed 0-32 B/s from display to make more room for higher speeds - Fixed a wait_creation bug About Speedometer ================= Speedometer is a console bandwidth and file download progress monitor with a logarithmic bandwidth display and a simple command-line interface. Speedometer requires Python 2.1 or later and Urwid 0.8.9 or later for full-console bar graph display. Urwid may be downloaded from: http://excess.org/urwid/ Speedometer is released under the GNU LGPL. From python-url at phaseit.net Sun Nov 6 18:53:36 2005 From: python-url at phaseit.net (Cameron Laird) Date: Sun, 06 Nov 2005 17:53:36 +0000 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Nov 6) Message-ID: QOTW: "- don't use SAX unless your document is huge - don't use DOM unless someone is putting a gun to your head" - Istvan Albert "I wouldn't fret too much about a sharp remark from Fredrik Lundh. They're pretty much all that way. ;) It looks like you already did the right thing - read past the insults, and gleaned the useful information that he included in between. It takes a little training to get used to him, but if you can look past the nasty bite, he's really a valuable resource." - Steven Bethard Alex Martelli and Bengt Richter rely on the galilean property and set function to compute whether a list is duplicate-free: http://groups.google.com/group/comp.lang.python/browse_thread/thread/4b1da706b9f9e622/ You needn't just pine for syntax from other languages missing in Python, such as Perl's "start..end"; if you're Peter Otten, you can add it to Python: http://groups.google.com/group/comp.lang.python/browse_thread/thread/506412e06dfea965/ Python as podcast! You might have *thought* you knew about the language, but it's a big Python world. http://www.awaretek.com/python/index.html Similarly, yes, Python can do what strtok() does in C, although it's expressed more readably: http://groups.google.com/group/comp.lang.python/browse_thread/thread/5e71a1da4f5934dc/ Larry Bates demonstrates how simple use of ConfigParser can be: http://groups.google.com/group/comp.lang.python/browse_thread/thread/321ec0512ed8c926/ With the new-style object model, type() is a stylish indirection: http://groups.google.com/group/comp.lang.python/browse_thread/thread/f0fbfae9a69580a3/ Enthusiastic Alex accuses Van Roy and Hariri of having written the 21st century SICP, and more. Much more. With references. Yet he (and Magnus Lycka and others) remain faithful: http://groups.google.com/group/comp.lang.python/browse_thread/thread/77c2035ee4150c11/ Python's a great general-purpose language. It can address storage devices directly: http://groups.google.com/group/comp.os.linux.misc/browse_thread/thread/28eb92576280d3f0/ it can operate at high level, and 'most everything in between. ======================================================================== 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 at pythonjournal.com and editor at 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.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ (requires subscription) http://groups-beta.google.com/groups?q=python-url+group:comp.lang.python*&start=0&scoring=d& http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python 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 should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask 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. From dalke at dalkescientific.com Sun Nov 6 20:35:19 2005 From: dalke at dalkescientific.com (Andrew Dalke) Date: Sun, 6 Nov 2005 20:35:19 +0100 Subject: ANN: PyJudy 1.0 Message-ID: <9662493a87d2707a7d889352c0bcfec5@dalkescientific.com> Over the last three weeks of on-and-off work I've developed and have just released PyJudy 1.0, a wrapper to the Judy sparse dynamic array library. It is available for download at http://dalkescientific.com/Python/PyJudy.html Judy, from http://judy.sourceforge.net/ , is ... a C library that provides a state-of-the-art core technology that implements a sparse dynamic array. Judy arrays are declared simply with a null pointer. A Judy array consumes memory only when it is populated, yet can grow to take advantage of all available memory if desired. Judy's key benefits are scalability, high performance, and memory efficiency. A Judy array is extensible and can scale up to a very large number of elements, bounded only by machine memory. Since Judy is designed as an unbounded array, the size of a Judy array is not pre-allocated but grows and shrinks dynamically with the array population. Continuing from the PyJudy page at http://dalkescientific.com/Python/PyJudy.html PyJudy arrays are similar to Python dictionaries and sets. The primary difference is that PyJudy keys are sorted; by unsigned value if an integer, byte ordering if a string and object id if a Python object. In addition to wrapping the underlying Judy functions, PyJudy implements a subset of the Python dictionary interface for the JudyL and JudySL API and a subset of the set interface for the Judy1 API, along with some extensions for iterating a subrange of the sorted keys, values and items. In my performance tests I found that overall JudyL arrays were a bit slower than Python dictionaries. Part of that might be my inexperience with the details of writing Python extensions. Part might be that JudyL arrays are sorted. I found that the Judy1 arrays were faster than the set class in Python 2.4. It'll be interesting to see how Raymond's new set implementation affects that. I did not do any memory comparisons. PyJudy is distributed under the MIT license because that has few upper-case letters than the BSD one. Andrew Dalke dalke at dalkescientific.com Andrew dalke at dalkescientific.com From quentel.pierre at wanadoo.fr Sun Nov 6 22:26:39 2005 From: quentel.pierre at wanadoo.fr (Pierre Quentel) Date: Sun, 06 Nov 2005 22:26:39 +0100 Subject: ANN: Karrigell-2.2 beta released In-Reply-To: References: Message-ID: <436e7511$0$5404$8fcfb975@news.wanadoo.fr> A new beta version of release 2.2 is available on sourceforge (http://karrigell.sourceforge.net). It fixes the bugs that have been mentioned : - management of global scripts - incorrect options in the default configuration file - bug in mod_py, it didn't manage the line separator on Unix / Linux Thanks to all who have reported bugs. I plan to release the final 2.2 version within 2 weeks Regards, Pierre From nick125 at gmail.com Mon Nov 7 05:41:10 2005 From: nick125 at gmail.com (Nick) Date: 6 Nov 2005 20:41:10 -0800 Subject: ANN: Circe 0.0.3b1 released Message-ID: <1131338470.535761.327440@f14g2000cwb.googlegroups.com> === Announcing Circe 0.0.3b1 === Circe Mainpage: http://circe.nick125.com/ Circe Download Page: http://circe.nick125.com/node/2 === New features/bug fixes === We have added several bug fixes, and new features, such as unicode, into the 0.0.3 beta 1 release. === Whats Circe? === Circe is a multiplatform IRC client written in the Python language that utilizes the wxpython library for the graphical interface. Circe features Unicode, Scripting, and many other features. From detlev at die-offenbachs.de Mon Nov 7 12:16:02 2005 From: detlev at die-offenbachs.de (Detlev Offenbach) Date: Mon, 07 Nov 2005 12:16:02 +0100 Subject: ANN: eric3 3.8.0 released Message-ID: Hi, this is to inform you about the release of eric3 3.8.0. It is available via http://www.die-offenbachs.de/detlev/eric3.html The list below summarizes the difference between eric3 3.7.x and 3.8.x - too long list of bugfixes to mention here - these usability enhancements DEBUGGER -- added possibility for path translation for passive debugging and remote debugging (Configuration Dialog -> Debugger -> General) -- added support for project specific debugger settings (see Project menu -> Debugger) -- added support for special watchpoint conditions (variable is created, variable is changed) DOCUMENTATION GENERATOR: -- added capability to generate source documentation using CSS style sheets to the eric3-doc utility (including the default style and a style with reversed headers) (Note: eric3-helpviewer cannot show the styles due to the limited HTML support in QTextBrowser) -- added the flag '-t' to eric-doc and eric-api to tell them to look for additional files EDITOR: -- added additional lexers (CSS files, TeX files, Diff files, Make Files, Properties Files and Batch Files) (QScintilla > 1.5.x is required) GENERAL: -- some interface cleanups and little reorganization of the configuration dialog -- added action to open multiple files -- added the capability to use %-codes for entering command line arguments. Supported codes are: %D directory of the current editor %F filename of the current editor %H home directory of the current user %U user name of the current user %% the percent sign This functionality is available in the following dialogs: configuration dialog, Debugger->General page version control system, Command Options cvs, Execute Command subversion, Execute Command mercurial, Execute command Tools Configuration -- added a configuration option to set the default encoding for files, that don't contain an encoding marker GRAPHICS: -- added the capability to delete shapes to the graphics dialogs PROJECT MANAGEMENT -- some optimisations and additions in the project browsers -- added configurable filetype associations for projects -- changed "Add file dialog" to allow the addition of multiple files to the project RUBY: -- enhanced Ruby support (thanks to Richard Dale) SHELL: -- changed the shell completion to use the Scintilla userlist. It is activated by pressing the TAB key and deactivated by pressing the ESC key (without selection) or the TAB or ENTER key (with selection). TASKS -- extended task management with categorization and a colorized display TEMPLATES: -- added a templates system TOOLS: -- added support for cx_Freeze (FreezePython) -- added support for PyLint USER INTERFACE: -- added the commandline option "--nokde" to disable usage of the KDE dialogs -- switching the editor will highlight the current file in the project browser -- added a context menu for the "Listspace" view manager -- added an incremental quicksearch to the search toolbar VERSION CONTROL: -- added support for Mercurial VCS What is it? ----------- eric3 is a Python and Ruby IDE with batteries included. For details see the eric3 home page. Regards, Detlev -- Detlev Offenbach detlev at die-offenbachs.de From michael at stroeder.com Mon Nov 7 13:05:36 2005 From: michael at stroeder.com (=?ISO-8859-1?Q?Michael_Str=F6der?=) Date: Mon, 07 Nov 2005 13:05:36 +0100 Subject: ANN: python-ldap-2.0.11 Message-ID: <436F4310.5070105@stroeder.com> Find a new release of python-ldap: http://python-ldap.sourceforge.net/ python-ldap provides an object-oriented API to access LDAP directory servers from Python programs. It mainly wraps the OpenLDAP 2.x libs for that purpose. Additionally it contains modules for other LDAP-related stuff (e.g. processing LDIF, LDAPURLs and LDAPv3 schema). ---------------------------------------------------------------- Released 2.0.11 2005-11-07 Changes since 2.0.10: Lib/ * Class ldap.ldapobject.LDAPObject: Each method returns a result now * Class ldap.ldapobject.ReconnectLDAPObject: Some methods called the wrong methods of LDAPObject. Fixed. * Added new class ldap.async.Dict * Slightly cleaned up ldap.schema.subentry.attribute_types() * New sub-module ldap.resiter which simply provides a mix-in class for ldap.ldapobject.LDAPObject with a generator method allresults(). Obviously this only works with Python 2.3+. And it's still experimental. From fuzzyman at gmail.com Mon Nov 7 13:36:13 2005 From: fuzzyman at gmail.com (Fuzzyman) Date: 7 Nov 2005 04:36:13 -0800 Subject: ANN: logintools Critical Update Message-ID: <1131366973.503660.259150@f14g2000cwb.googlegroups.com> http://www.voidspace.org.uk/python/logintools.html Critical Bugfix in logintools (which also affects jalopy) The new release is 0.6.2 http://www.voidspace.org.uk/cgi-bin/voidspace/downman.py?file=jalopy_login.zip What's New ========= I recently updated logintools and jalopy to be compatible with the new pythonutils code. This was the 0.6.0 releases. Embarrassingly, I didn't update the email calls to use the new function signature in cgiutils. New user sign-ups have been thoroughly broken since. sigh The application I use logintools for doesn't allow new user signups. It only has administrator created accounts, so I didn't notice the broken code. This is now fixed and anyone who wants jalopy or logintools to work should download the new release. What is logintools ============= logintools is a full framework to do user authentication and account management with CGI. It provides you with a full system for restricting access to pages and your applications, including administration features, new user sign-ups, and the facility for users to edit their account details. Even better - you can add it to a Python CGI with as little as two lines of code (really). Configurable in terms of behaviour nad appearance, it also provides a mechanism for storing details of the user account. See the documentation at http://www.voidspace.org.uk/python/logintools.html From fuzzyman at gmail.com Mon Nov 7 14:05:18 2005 From: fuzzyman at gmail.com (Fuzzyman) Date: 7 Nov 2005 05:05:18 -0800 Subject: ANN : ConfigObj 4.0.1 Config File Reader/Writer Message-ID: <1131368718.860611.318600@o13g2000cwo.googlegroups.com> Version 4.0.1 of ConfigObj is now available. This includes one bugfix and two new features. http://www.voidspace.org.uk/python/configobj.html What's New ? ========== Fixed bug in ``Section.walk`` when transforming names as well as values. Added the ``istrue`` section method. (Fetches the boolean equivalent of a string value). Fixed ``list_values=False`` - single line values are not quoted or unquoted. See http://www.voidspace.org.uk/python/weblog/arch_d7_2005_11_05.shtml#e129 for a description of these changes. List values are written as ``item, item`` rather than ``item,item``. What is ConfigObj ? =============== ConfigObj is a simple but powerful config file reader and writer: an ini file round tripper. It's main feature is that it is very easy to use, with a straightforward programmer's interface and a simple syntax for config files. It has lots of other features though. This module is used in most Voidspace projects. See the ConfigObj Home Page for full documentation. It's features include : * Nested sections (subsections), to any level * List Values * Multiple Line Values * String interpolation (substitution) * Integrated with a powerful validation system o including automatic type checking/conversion o repeated sections o and allowing default values * All comments in the file are preserved * The order of keys/sections is preserved * No external dependencies From sylvain.thenault at logilab.fr Mon Nov 7 16:12:27 2005 From: sylvain.thenault at logilab.fr (Sylvain =?iso-8859-1?Q?Th=E9nault?=) Date: Mon, 7 Nov 2005 16:12:27 +0100 Subject: [ANN] ASTNG 0.13.1 Message-ID: <20051107151227.GC24171@crater.logilab.fr> Hi there ! I'm pleased to announce a new bug fix release of ASTNG. This release fixes a lot of bugs detected by pylint users, the most popular application built on top of this package. What's new ? ------------ * fix bug on building from living module the same object in encountered more than once time (eg builtins.object) (close #10069) * fix bug in Class.ancestors() regarding inner classes (close #10072) * fix .self_resolve() on From and Module nodes to handle package precedence over module (close #10066) * locals dict for package contains __path__ definition (close #10065) * astng provide GenExpr and GenExprFor nodes with python >= 2.4 (close #10063) * fix python2.2 compatibility (close #9922) * link .__contains__ to .has_key on scoped node to speed up execution * remove no more necessary .module_object() method on From and Module nodes * normalize parser.ParserError to SyntaxError with python 2.2 What is ASTNG ------------- The aim of this module is to provide a common base representation of python source code for projects such as pychecker, pyreverse, pylint... Well, actually the development of this library is essentialy governed by pylint's needs. It extends class defined in the compiler.ast [1] module with some additional methods and attributes. Instance attributes are added by a builder object, which can either generate extended ast (let's call them astng ;) by visiting an existant ast tree or by inspecting living object. Methods are added by monkey patching ast classes. Home page --------- http://www.logilab.org/projects/astng Download -------- ftp://ftp.logilab.org/pub/astng Mailing list ------------ mailto://python-projects at lists.logilab.org LOGILAB provides services in the fields of XML techniques and advanced computing (implementation of intelligent agents, knowledge management, natural language processing, statistical analysis, data mining, etc.), and also trainings on Python, XML, UML, Object Oriented design, design patterns use and other cutting edge topics. To know more about Logilab, visit http://www.logilab.com/. Logilab is also a strong supporter of the Free Software movement, and an active member of the Python and Debian communities. Logilab's open source projects can be found on http://www.logilab.org/. Enjoy! -- Sylvain Th?nault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org From sylvain.thenault at logilab.fr Mon Nov 7 16:13:22 2005 From: sylvain.thenault at logilab.fr (Sylvain =?iso-8859-1?Q?Th=E9nault?=) Date: Mon, 7 Nov 2005 16:13:22 +0100 Subject: [ANN] pylint 0.8.1 Message-ID: <20051107151322.GF24171@crater.logilab.fr> Hi there ! I'm pleased to announce a new bug fix release of PyLint. Notice that a lot of other bugs will be fixed by updating the logilab-astng package to 0.13.1. Almost all bugs noticed by pylint users since the 0.8 is out should be corrected by updating pylint and astng :) What's new ? ------------ * fix "deprecated module" false positive when the code imports a module whose name starts with a deprecated module's name (close #10061) * fix "module has no name __dict__" false positive (close #10039) * fix "access to undefined variable __path__" false positive (close #10065) * fix "explicit return in __init__" false positive when return is actually in an inner function (close #10075) What is pylint ? ---------------- Pylint is a python tool that checks if a module satisfy a coding standard. Pylint can be seen as another pychecker since nearly all tests you can do with pychecker can also be done with Pylint. But Pylint offers some more features, like checking line-code's length, checking if variable names are well-formed according to your coding standard, or checking if declared interfaces are truly implemented, and much more (see http://www.logilab.org/projects/pylint/ for the complete check list). The big advantage with Pylint is that it is highly configurable, customizable, and you can easily write a small plugin to add a personal feature. The usage it quite simple : $ pylint mypackage.mymodule This command will output all the errors and warnings related to the tested code (here : mypackage.mymodule), will dump a little summary at the end, and will give a mark to the tested code. Pylint is free software distributed under the GNU Public Licence. Home page --------- http://www.logilab.org/projects/pylint Download -------- ftp://ftp.logilab.org/pub/pylint Mailing list ------------ mailto://python-projects at logilab.org Enjoy! -- Sylvain Th?nault LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org From aahz at pythoncraft.com Tue Nov 8 05:21:24 2005 From: aahz at pythoncraft.com (Aahz) Date: Mon, 7 Nov 2005 20:21:24 -0800 Subject: BayPIGgies: November 10, 7:30pm (Google) Message-ID: <20051108042124.GA245@panix.com> The next meeting of BayPIGgies will be Thurs, November at 7:30pm at Google (Bldg 43, room Tunis). Hasan Diwan will demonstrate a prototype GPS system written in Python. Let's all work to convince him that he doesn't need to rewrite it in Java! BayPIGgies meetings alternate between IronPort (San Bruno, California) and Google (Mountain View, California). For more information and directions, see http://www.baypiggies.net/ Before the meeting, we sometimes meet at 6pm for dinner. Discussion of dinner plans is handled on the BayPIGgies mailing list. Advance notice: The meeting agenda for December 8 has been set. Please send e-mail to baypiggies at baypiggies.net if you want to suggest an agenda (or volunteer to give a presentation). -- Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/ "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." --Red Adair From ianb at colorstudy.com Tue Nov 8 09:23:58 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Tue, 08 Nov 2005 02:23:58 -0600 Subject: Chicago Python Users Group, Thurs Nov 10 Message-ID: <4370609E.5050804@colorstudy.com> November topics are "Remote, Generic and Random", just like us. We'll have presentations on PyRO (Python Remote Objects) by Fawad Halim, generic functions (as implemented in RuleDispatch) by Ian Bicking, and the standard library random module by Robert Ramsdell. There will also be time to chat, and many opportunities to ask questions. We encourage people at all levels to attend. We'll be meeting at 7 PM, Thursday November 10, in downtown Chicago at Performics 180 N. Lasalle 12th floor. RSVP is necessary for building security, email chris.mcavoy at gmail.com with a subject of "RSVP for ChiPy" to be added to the list. If you aren't sure if you can come, email just in case. About ChiPy (http://chipy.org): ChiPy meets on the second Thursday of each month, at different locations around Chicagoland. If you are interested in goings-on, please subscribe to our mailing list: http://mail.python.org/mailman/listinfo/chicago From jeff at taupro.com Tue Nov 8 10:15:57 2005 From: jeff at taupro.com (Jeff Rush) Date: Tue, 8 Nov 2005 03:15:57 -0600 Subject: DFW Pythoneer Meetings This Week Message-ID: <200511080315.58300.jeff@taupro.com> The Dallas-Ft. Worth Pythoneers are having three meetings this week. [1] Thursday, November 10th (i.e. Every Second Thursday) From 7 pm until 10 pm at Snuffer's Restaurant and Bar in Addison on Midway, we have a *social get-together*. Sure to be on the agenda is discussion about our recent experiences with learning Zope 3 and establishing a club IRC channel. Snuffer's Restaurant and Bar 14910 Midway Rd. Addison, TX 75244 972-991-8811 We meet in the glassed-in patio and try to have Python-related books and signs scattered about so people can find us. [2] Friday, November 11th (Kickoff of Ft. Worth Chapter) The first meeting of the Fort Worth chapter, we're trying to build up a group for those who find it difficult to drive all the way to Dallas/Addison. If you want local meetings, please make your presence known. We're meeting from 6 pm until 8 pm at: Artistic Blends 5298 Trail Lake Drive Fort Worth, TX 76133 (817) 292.4744 Look for the Kylixitis shirt wearing individual. [3] Saturday, November 12th (i.e. Second Saturday Hands-On Sessions) We start gathering at 1 pm and formally start at 2 pm. This is *hands-on programming* so bring your laptops. The site has both wired and wireless Internet, and we have a projector for talks. We run until 5 pm and then break for a group dinner. We're at the tables in the big middle of the bookstore, with laptops, hubs and cables everywhere. Easy to find. NerdBooks.com 1681 Firman Drive Richardson, TX 75081 (972) 470-9600 The topics this time will be Zope 3 and more Extreme Programming, applied to the web-based talks scheduler we're constructing as a group project for the PyCon conference. Next time, the Fourth Saturday, we hope to have a demo/talk of the Django web framework. ---- Locations, times and *maps* for all events are maintained at: http://python.meetup.com/10/events/ The DFW Pythoneers maintain a club wiki/mailing list at: http://www.python.org/dfw Hope to see you there, and especially some new faces! Jeff Rush, DFW Pythoneers Coordinator From grig.gheorghiu at gmail.com Tue Nov 8 19:02:34 2005 From: grig.gheorghiu at gmail.com (Grig Gheorghiu) Date: 8 Nov 2005 10:02:34 -0800 Subject: SoCal Piggies meeting: Nov.10 at USC (7 PM) Message-ID: <1131472954.108861.300130@g44g2000cwa.googlegroups.com> The next meeting of the SoCal Piggies will be this Thursday November 10 at USC, starting at 7 PM. We'll have 2 presentations: * "Python and Unicode" -- Daniel Arbuckle * "What You Can Do with Python in 90 Minutes" -- Mark Kohler If you're a Python enthusiast living in the L.A./O.C. area, please consider joining us for the meeting. The SoCal Piggies Wiki is at . Directions to the USC location are available here: Grig From me at privacy.net Tue Nov 8 20:49:37 2005 From: me at privacy.net (Mark Carter) Date: Tue, 08 Nov 2005 19:49:37 +0000 Subject: ANN: sharep 0.2 - share price downloader module Message-ID: <4371014e$0$41151$14726298@news.sunsite.dk> sharep is a Public Domain python module for downloading share prices from the internet. Currently only UK shares are supported. Feel free to submit support for other countries. News 08-Nov-2005 Version 0.2 released - updates for changes to Yahoo site 21-Dec-2004 Version 0.1 released Example >>> # download bid and ask price for Glaxo Pharmaceuticals; symbol name GSK >>> import sharep.uk >>> sharep.uk.bid('GSK') '1,184.00' >>> sharep.uk.ask('gsk') '1,186.00' Webpage: http://www.markcarter.me.uk/computing/python/sharep/sharep.htm Download: http://www.markcarter.me.uk/computing/python/sharep/sharep-0.2.zip From amk at amk.ca Wed Nov 9 14:39:35 2005 From: amk at amk.ca (A.M. Kuchling) Date: Wed, 9 Nov 2005 08:39:35 -0500 Subject: PyCon 2006 Call for Tutorials Message-ID: <20051109133935.GA26994@rogue.amk.ca> PyCon 2006 Call for Tutorials ------------------------------------------ Enjoy teaching classes or tutorials? PyCon 2006 is looking for proposals for a pre-conference tutorials day. PyCon 2006 will be held February 24-26 in Addison, Texas (near Dallas). Tutorials will be held on February 23, at the same location. Tutorial sessions will be a half day (3 hours, with a 15-minute break); presenters may request two sessions in order to make up a full day. Tutorials may be on any topic, but obviously should be instructional in nature. Providing take-home materials for attendees is encouraged, and tutorial presenters will receive $50 per student registered for theirsession (with a minimum payment of $500, and a maximum of $1500). Extra consideration will be given to presenters with prior experience teaching classes or giving conference tutorials. Please provide one reference or evidence of such prior experience (sessions taught at OSCON, EuroPython, local user groups, etc.). PyCon attendees will register for tutorials. We reserve the right to cancel tutorials with low attendance; presenters will not be paid for cancelled tutorials. Example tutorial topics can be found at: http://us.pycon.org/TX2006/Tutorials Important Dates =============== * Submission deadline: November 15, 2005 * Acceptance deadline: November 22, 2005 * Cancellation date: January 15, 2006 (for inadequate attendance) Submission Format ================================ Proposals should be 250 to 1000 words long (i.e., one to four pages in manuscript format), containing the following information: * Author name(s) * Contact Information * (Recommended) At least one previous presentation/teaching engagement reference * Summary of proposed presentation * Presentation outline * Intended audience (non-programmers, beginning programmers, advanced users, CPython developers, etc.) E-mail your proposal to . ASCII format is preferred (plain or reST), with HTML as a secondary alternative. If you have any questions about submission, please send mail to the conference organizers at pycon at python.org. From gary at modernsongs.com Wed Nov 9 15:34:03 2005 From: gary at modernsongs.com (Gary Poster) Date: Wed, 9 Nov 2005 09:34:03 -0500 Subject: Revised announcement for tonight's Fredericksburg ZPUG Message-ID: This is a revised announcement for tonight's Fredericksburg ZPUG meeting. Andrew Sawyers is postponing his Squid and Zope presentation until the January ZPUG meeting (January 11, 2006). This is the new agenda: ------ Please join us November 9, 7:30-9:00 PM, for the sixth meeting of the Fredericksburg, VA Zope and Python User Group ("ZPUG"). Using Zope for newspaper publishing! The dangers of object oriented inheritance! Free food! * Allen Schmidt, Sr. Programmer for Fredericksburg.com - the website for the Free Lance-Star - will present on "Using Zope for Newspaper Publishing". * Jim Fulton, CTO of Zope Corporation, will present an abbreviated version of the argument given in Clemens Szyperski's Component Software for why both inheritance and delegation (e.g. acquisition) cause tight coupling and therefore should be avoided except in special circumstances. * We will serve delicious fruit, cheese, and soft drinks. From python-url at phaseit.net Wed Nov 9 17:52:37 2005 From: python-url at phaseit.net (Cameron Laird) Date: Wed, 09 Nov 2005 16:52:37 +0000 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Nov 9) Message-ID: QOTW: "The lesson for me is to spend much less time on Python discussion and much more on unfinished projects. So even if I never use the new syntax, I will have gained something ;-)" - Terry Reedy "In short, this group is a broad church, and those readers with brains the size of planets should remember that they are just as much in a minority as the readers who appear on the list for the first time this week. The vast majority are here to learn and grow, and I think that's the sort of behaviour we should be encouraging." -- Steve Holden The reasons you like Python probably are put into words in at least one of these threads: http://groups.google.com/group/comp.lang.python/browse_thread/thread/b41ca4ba29b84471/ Tim Golden, ... help make the most of Excel: http://groups.google.com/group/comp.lang.python/browse_thread/thread/bcd29beecba33c98/ Spread your expertise around, face-to-face, just outside Dallas. http://groups.google.com/group/comp.lang.python.announce/msg/b7f6f62db23e1265 Program generators date from the Carboniferous. Or the age of Cobol. Well, from *some* time in the past, as least. . . . Except that they keep turning up nowadays, in such guises as refinable templating systems: http://groups.google.com/group/comp.lang.python/browse_thread/thread/8962903fc5717bfa/ While generators (like program generators, recursion, and many other powerful concepts) are great, they're *best* less often than is commonly realized: http://groups.google.com/group/comp.lang.python/browse_thread/thread/af6560b12bc719a6/ Deprecation of functionalism isn't an idle exercise. The point is not just to *say*, yes, we can live without lambda; Fredrik Lundh, for example, embraces New Python Style's willingness to define and redefine function objects, exactly in contrast to older lambda-oriented codings: http://mail.python.org/pipermail/tkinter-discuss/2005-November/000553.html ======================================================================== 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 at pythonjournal.com and editor at 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.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ (requires subscription) http://groups-beta.google.com/groups?q=python-url+group:comp.lang.python*&start=0&scoring=d& http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python 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 should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask 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. From blais at furius.ca Wed Nov 9 19:22:10 2005 From: blais at furius.ca (Martin Blais) Date: Wed, 9 Nov 2005 13:22:10 -0500 Subject: ANN: indra -- interfaces for web applications Message-ID: <8393fff0511091022s1cbad044i7a8be77b0a66b89e@mail.gmail.com> http://furius.ca/indra/ Indra is a set of simple programming interfaces that were defined with the intention of isolating web application code from specific back-ends. The goal is to be able to write powerful web applications with a clear separation that allows easily retargeting an application to a different backend, without having to rewrite the application code. Motivation When I wrote these interfaces, I was writing my own web application framework, and I worried about writing code that could not be retargeted to another platform in the future. What I decided to do was formalize what the interface between my application's code and the web app framework. To this effect, I had to identify what were the core components that I was using and came up with this set of interfaces. I have since implemented a web framework that implements all the interfaces provides by Indra. The interfaces are relatively low-level, and it would be easy to implement the same set of interfaces on other backends. (Since I thought this might be useful to others, I decided to share it. Here it is.) From blais at furius.ca Wed Nov 9 19:24:45 2005 From: blais at furius.ca (Martin Blais) Date: Wed, 9 Nov 2005 13:24:45 -0500 Subject: ANN: some Subversion tools written in Python Message-ID: <8393fff0511091024k5b7626eao2950470f5e86e6fc@mail.gmail.com> Some tools for Subversion that might be useful for others. http://furius.ca/pubcode/#subversion-tools svn-copy-register Replicates the directory structure and files of into , performing the necessary additions and deletions to register the changes files in into Subversion. is assumed to be a Subversion checkout. Files that exist on both sides are diffed to figure out if there are changes to be copied. svn-import-releases Take a list of directories, each representing a version of some files (like a checkout of a release of some software), and imports each of these sequentially over an existing checkout, registering the new fileset and creating a subversion release for every directory imported. From blais at furius.ca Wed Nov 9 19:35:43 2005 From: blais at furius.ca (Martin Blais) Date: Wed, 9 Nov 2005 13:35:43 -0500 Subject: ANN: rst.el -- renewed emacs support for editing restructuredtext documents Message-ID: <8393fff0511091035h6c986125g1437dc90e28df0e9@mail.gmail.com> FYI. (This is not Python-specific per-se, but everyone I know using Python has adopted docutils and rest, so this will be of interest to most people on this list using emacs.) emacs support for reStructuredText has been greatly improved and rewritten over the past few weeks. All emacs files have now been grouped in a single package, rst.el, with lots of new features. All the juicy details can be found here: http://docutils.sourceforge.net/docs/user/emacs.html rst.el is part of the docutils repository: http://svn.berlios.de/viewcvs/*checkout*/docutils/trunk/docutils/tools/editors/emacs/rst.el Note that all the old rest emacs packages (restructuredtext.el, rst-mode.el, rst-html.el) are obsoleted by this new package-- the new package contains all their functionality and more. Delete your old files. cheers, From astraw at caltech.edu Wed Nov 9 22:36:24 2005 From: astraw at caltech.edu (Andrew Straw) Date: Wed, 09 Nov 2005 13:36:24 -0800 Subject: ANN: seppo 20051109 - simple embarrassingly parallel python Message-ID: I'd like to announce "seppo" - simple embarrassingly parallel python. This should be considered a very alpha version, and was released to the public to gauge interest/reaction. Overview ======== The map function is well-known in Python, allowing a single function to be called on each member of an iterable sequence: map( function, [1,2,3,4] ) The seppo module allows the same functionality, but distributed over several processes: seppo.map_parallel( some_module.function, [1,2,3,4] ) In this case, each iteration may evaluate the function in a different process, possibly in a different computer. The idea is a simple concept and is hopefully natural transition for Python programmers to use the power of multi-processor computers and clusters. For more information, or to download ==================================== Please see: http://www.its.caltech.edu/~astraw/seppo.html From python at openlight.com Thu Nov 10 04:06:32 2005 From: python at openlight.com (George Belotsky) Date: Wed, 9 Nov 2005 22:06:32 -0500 Subject: Flightdeck-UI Online Version 0.3.91 Released Message-ID: <20051110030632.GA13579@localhost> Flightdeck-UI Online version 0.3.91 has been released. This is a minor update to the advanced beta version (0.3.9). Here is the list of changes in the new release. * A bug that caused the analog clock in the demo panel to read incorrectly after Daylight Savings Time ends has been fixed. * A special offset class ("FdUI.logic.Offsets.Localtime") has been added, which automatically adjusts to Daylight Savings Time without the need to restart the panel daemon. The "Offsets" module itself is also new. * The wind speed label in the weather demo panel was too narrow, causing the digital wind display to be cut off in some cases. This has been fixed. The distribution includes detailed installation instructions and two example control panels. The installation is designed to be a very simple process -- please contact the author if you have questions. See the homepage: "http://www.openlight.com/fdui" or download directly from: "http://www.openlight.com/fdui/downloads/fdui-online-0.3.91.tar.gz". What is Flightdeck-UI --------------------- The goal of the Flightdeck-UI project is to apply ideas from aircraft instrumentation design to general purpose user interfaces. The new web service version (Flightdeck-UI Online) retains the plug-in architecture of previous releases. Each plugin, however, may now be monitored at different sampling rates. Multiple data sources (hosts on the Internet, embedded devices, etc.) can be tracked simultaneously. Also, virtually any Unix command that you enter from the shell can be automatically executed by Flightdeck-UI Online, and the results displayed by the system's virtual instruments. Although the web service requires a Flash front end (developed using only the MTASC open source ActionScript compiler; see http://www.mtasc.org/) Flightdeck-UI Online is still primarily written in Python. The author welcomes any ideas and suggestions: please email them directly to "python at openlight.com". Best Wishes, George Belotsky. From info at wingware.com Thu Nov 10 04:23:45 2005 From: info at wingware.com (Wingware Announce) Date: Wed, 9 Nov 2005 22:23:45 -0500 (EST) Subject: Wing IDE for Python 2.0.4 released Message-ID: Hi, We're pleased to announce the release of Wing IDE for Python 2.0.4. This is a bugfix release and is a free upgrade for Wing IDE 2.0 users. The release can be downloaded from: http://wingware.com/downloads Highlights of this release include: * Preference for syntax highlighting colors in Python, C/C++, and Java files * Support for Zope 2.8 and gtk 2.8 * Modest improvements in search performance * Template panel is part of default tool set (Wing Pro only) * Over 40 bug fixes This release is available for Windows, Linux, and Mac OS X, and can be compiled from sources on *BSD, Solaris, and other Posix operating systems. A complete list of changes is available here: http://wingware.com/pub/wingide/2.0.4/CHANGELOG.txt For more information see: Product Info: http://wingware.com/products Sales: http://wingware.com/store/purchase Upgrades: http://wingware.com/store/upgrade Sincerely, The Wingware Team From sf at nuxeo.com Thu Nov 10 13:34:24 2005 From: sf at nuxeo.com (fermigier) Date: Thu, 10 Nov 2005 13:34:24 +0100 Subject: FunkLoad 1.3.0 and 1.3.1 are out Message-ID: <43733E50.9000304@nuxeo.com> FunkLoad 1.3.0 and 1.3.1 (which fixed a bug in the previous release) are out. FunkLoad 1.3.0 introduces a new http-proxy based recorder for user sessions. It also fixes a couple of outstanding bugs. Grab FunkLoad 1.3.1 on: http://funkload.nuxeo.org/ About FunkLoad: FunkLoad is a open source functional and load web tester, written in Python, whose main use cases are functional and regression testing of web projects, performance testing by loading the web application and monitoring your servers, load testing to expose bugs that do not surface in cursory testing, and stress testing to overwhelm the web application resources and test the application recoverability, and writing web agents by scripting any web repetitive task, like checking if a site is alive. From agreen at cirrustech.com.au Fri Nov 11 03:28:35 2005 From: agreen at cirrustech.com.au (Alan Green) Date: Fri, 11 Nov 2005 13:28:35 +1100 Subject: Sydney Python - Thursday November 17 Message-ID: <437401D3.4010902@cirrustech.com.au> The Sydney Python group is having its last meeting for the year next Thursday, November 17. Andy Todd will be regaling us with a preview of his upcoming OSDC presentation, "Building GUI Applications with PythonCard". Usual time and place: Thursday, November 17, 2005 (6:30 PM - 8:30 PM) James Squire Brewhouse 2 The Promenade King St Wharf Sydney, New South Wales If you could send me a note (or click the appropriate radio button on http://upcoming.org/event/39890) in advance, that would be much appreciated. (Just turning up is fine too.) Cheers, Alan. From titus at caltech.edu Fri Nov 11 19:18:02 2005 From: titus at caltech.edu (C. Titus Brown) Date: Fri, 11 Nov 2005 10:18:02 -0800 Subject: ANNOUNCE: twill v0.7.4, Web testing language. Message-ID: <4374E05A.4020701@caltech.edu> ANNOUNCING twill v0.7.4. twill is a simple Web scripting language built on top of Python and John J. Lee's 'mechanize'. It's designed for automated testing of Web sites, but it should prove useful for anybody who needs to interact with Web sites (especially those using logins and cookies) on the command line or via a script. twill can also now be used for stress-testing and benchmarking of complex sites via the twill-fork script. twill is a reimplementation of Cory Dodt's PBP. A twill script looks like this: # go to the /. login page go http://slashdot.org/login.pl # fill in the form fv 1 unickname test fv 1 upasswd test submit # ok, there's no such account ;). show error HTML. show --- This is the fifth public release of twill, version 0.7.4. (Tagline: "many bugs fixed, nose-based unit tests now work.") Download directly here: http://darcs.idyll.org/~t/projects/twill-0.7.4.tar.gz Documentation is online at http://www.idyll.org/~t/www-tools/twill.html --- Miscellaneous details: twill is implemented in Python and uses pyparsing and mechanize. In addition to the existing simple command language, twill can easily be extended with Python. twill also provides a fairly simple and well-documented wrapper around mechanize. twill scripts can be recorded with maxq, although scripts may require some hand tweaking at the moment. See the twill documentation for more information. twill does not understand JavaScript, I'm sorry to say. --- Notable bug fixes and features: * better error handling & display; * many, many browsing bugs fixed; * new 'url', 'exit', 'showlinks', 'title', 'config' and 'agent' commands; * 'nose' unit tests and unit-test support infrastructure; c.f. http://www.idyll.org/~t/www-tools/twill.html#unit-testing Thanks go to Tommi Virtanen, James Cameron, sureshvv, William Volkman, and Mike Rovner for patches and bug reports. From inigoserna at terra.es Sat Nov 12 17:56:27 2005 From: inigoserna at terra.es (=?ISO-8859-1?Q?I=F1igo?= Serna) Date: Sat, 12 Nov 2005 17:56:27 +0100 Subject: ANN: pynakotheka v1.0 Message-ID: <1131814587.26242.6.camel@inigo.katxi.org> Hello out there, I'm really pleased to announce the first public release of Pynakotheka. Pynakotheka is a simple GPL-licensed python script which generates static HTML photo albums to be added to web sites or to be burnt in CDs. It includes some templates and it's easy to create more. It depends on python, CheetahTemplate, EXIF and PIL. Read more and download it from: http://inigo.katxi.org/devel/pynakotheka or http://www.terra.es/personal7/inigoserna/pynakotheka Of course, all comments, suggestions etc. are welcome. Best regards, -- I?igo Serna Katxijasotzaileak -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente Url : http://mail.python.org/pipermail/python-announce-list/attachments/20051112/f2d4e411/attachment.pgp From ianb at colorstudy.com Sat Nov 12 23:09:10 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Sat, 12 Nov 2005 16:09:10 -0600 Subject: ANN: FormEncode 0.3 Message-ID: <43766806.4070805@colorstudy.com> I'm pleased to announce FormEncode 0.3. What is it? ----------- FormEncode is a package for form validation and conversion. It also includes modules for parsing, filling, and extracting metadata from HTML forms. It features robust conversion both of incoming and outgoing data, attention paid to helpful error messages, and a wide variety of pre-build validators. It also supports composition of validators, and validating structured data, including nested and repeating form elements. FormEncode is being used in several projects, including Subway, TurboGears, and SQLObject. Where is it? ------------ Website and docs: http://formencode.org Download: http://cheeseshop.python.org/pypi/FormEncode What has changed? ----------------- >From the news file: * Allow errors to be inserted automatically into a form when using ``formencode.htmlfill``, when a ```` tag isn't found for an error. * Added ``if_key_missing`` attribute to ``schema.Schema``, which will fill in any keys that are missing and pass them to the validator. * ``FancyValidator`` has changed, adding ``if_invalid_python`` and ``validate_python`` options (which also apply to all subclasses). Also ``if_empty`` only applies to ``to_python`` conversions. * ``FancyValidator`` now has a ``strip`` option, which if true and if input is a string, will strip whitespace from the string. * Allow chained validators to validate otherwise-invalid forms, if they define a ``validate_partial`` method. The credit card validator does this. * Handle ``FieldStorage`` input (from file uploads); added a ``formencode.fieldstorage`` module to wrap those instances in something a bit nicer. Added ``validators.FieldStorageUploadConverter`` to make this conversion. * Added ``StringBoolean`` converter, which converts strings like ``"true"`` to Python booleans. Bugfixes ~~~~~~~~ * A couple fixes to ``DateConverter``, ``FieldsMatch``, ``StringBoolean``, ``CreditCardValidator``. * Added missing ``Validator.assert_string`` method. * ``formencode.htmlfill_schemabuilder`` handles checkboxes better. * Be a little more careful about how ``Invalid`` exceptions are created (catch some errors sooner). * Improved handling of non-string input in ``htmlfill``. Experiments ~~~~~~~~~~~ * Some experimental work in ``formencode.formgen``. Experimental, I say! * Added an experimental ``formencode.context`` module for dynamically-scoped variables. From aleax at mail.comcast.net Sun Nov 13 03:34:01 2005 From: aleax at mail.comcast.net (Alex Martelli) Date: Sat, 12 Nov 2005 18:34:01 -0800 Subject: [ANNOUNCE] gmpy 1.1 beta released References: Message-ID: <1h5xf89.1dofi5u1kvmhdfN%aleax@mail.comcast.net> See http://gmpy.sourceforge.net/ for details. What is it: a wrapper for the GMP 4 library (http://swox.com/gmp/), to provide multi-precision arithmetic for Python. Multi-precision floats, and unbounded-precision rationals, are not present in stock Python; multi-precision integers ('long') are, but gmpy's version of multi-precision integers is faster for some operations, and provides lots of nifty pre-packaged additional functions. Minor changes and bug-fixes since the latest 1.0 alpha: support for the latest versions of GMP and Python, particularly on the Mac (whose gmp 4 is pickier...). Windows binary releases are now installer-exe's, support Python 2.3 and 2.4, and (thanks to enhancements in the underlying GMP) are faster than the previous Windows binary releases of gmpy (so is the source release, on any platform, if you build it with the latest and greatest GMP). This release has no known bugs (the scan0/scan1 bug that used to be present in Windows binary releases, as predicted, has disappeared without needing any changes to gmpy, thanks to bug fixes in GMP; the divm function's bugs, that were gmpy's responsibility, are now fixed). Alex From oliphant at ee.byu.edu Sun Nov 13 06:10:54 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Sat, 12 Nov 2005 22:10:54 -0700 Subject: SciPy Core (Numeric replacement) version 0.6.1 released Message-ID: <4376CADE.4010707@ee.byu.edu> Background: Numeric is an add-on Python module that has seen widespread adoption. It enables Python to be used as a Scientific Computing Environment similar to MATLAB or IDL. Numeric was originally written nearly 10 years ago, and while still performing admirably, needed much updating to take advantage of the new features in Python and to remove old warts. SciPy Core 0.6.1 SciPy Core is a new system which builds on the code-base of Numeric, but implements features (such as advanced index-selection, and user-settable error modes). There are over 25 major new feature enhancements. The LICENSE is still a BSD style License---the same as old Numeric. More information can be found at the web-site: http://numeric.scipy.org

SciPy Core 0.6.1 - Replacement for Numeric Python. (12-Nov-05) From oliphant at ee.byu.edu Sun Nov 13 06:24:14 2005 From: oliphant at ee.byu.edu (Travis Oliphant) Date: Sat, 12 Nov 2005 22:24:14 -0700 Subject: SciPy 0.4.3 released (built against 0.6.1 of scipy_core) Message-ID: <4376CDFE.9060101@ee.byu.edu> Background: Full scipy builds on top of scipy_core to provide many more tools for computational science and engineering. Included are tools for optimization, integration (including ode solvers), signal processing, sparse matrices, complete FFTs, complete linear algebra, statistical functions, input and output routines, interpolation, integration, and many special functions. SciPy 0.4.3 This version is the first release to build on top of the new scipy_core (v 0.6.1). The code is relatively stable, but there may be some lingering bugs from the transition from Numeric. Please report any errors you find. The LICENSE is a BSD style License---the same as scipy_core. More information can be found (some of which is dated) at http://www.scipy.org. The sourceforge site where it can be downloaded is http://sourceforge.net/projects/scipy.

SciPy (full) 0.4.3 - Extension modules for scipy_core (12-Nov-05) From nick.smallbone at gmail.com Sun Nov 13 23:35:36 2005 From: nick.smallbone at gmail.com (Nick Smallbone) Date: 13 Nov 2005 14:35:36 -0800 Subject: ANN: PySizer 0.1 Message-ID: <1131921336.796367.146700@z14g2000cwz.googlegroups.com> I'd like to announce the first release of PySizer, a memory usage profiler for Python code. PySizer was written as part of Google's Summer of Code. The source, documentation and so on are at http://pysizer.8325.org. The current release is at http://pysizer.8325.org/dist/sizer-0.1.tar.gz. The code is kept in a Subversion repository at http://codespeak.net/svn/user/nick8325/sizer. The idea is to take a snapshot of memory use at some time, and then use the functions of the profiler to find information about it. Features -------- * You can make a snapshot of all reachable objects at a given time, organised as a tree (well, a graph, since there are cycles). * For any given object, you can find out how much space it takes up, what objects it references and so on. With a patched version of Python, you can also find out what stack of function calls created an object, and what objects were created by each stack of calls. * You can collect objects into groups. For example, you can group each object according to the module it appears to come from. Then you can treat each module as a single object. * You can filter objects, find the amount of space used by instances of each type, find objects which appeared from one snapshot to the next, find the biggest objects/types/groups, and so on. Requirements ------------ See http://pysizer.8325.org/INSTALL. The main one is Python 2.4 - I will port it to 2.3 soon. Bugs, suggestions, comments, problems, anything else ---------------------------------------------------- You can contact me at nick.smallbone at gmail.com. I would love to know if you find a use for it, too. From cito at online.de Mon Nov 14 01:18:46 2005 From: cito at online.de (Christoph Zwerschke) Date: Mon, 14 Nov 2005 01:18:46 +0100 Subject: Webware for Python 0.9 released Message-ID: Webware 0.9 has been released. Webware for Python is a suite of Python packages and tools for developing object-oriented, web-based applications. The suite uses well known design patterns and includes a fast Application Server, Servlets, Python Server Pages (PSP), Object-Relational Mapping, Task Scheduling, Session Management, and many other features. Webware is very modular and easily extended. Webware for Python is well proven and platform-independent. It is compatible with multiple web servers, database servers and operating systems. The new release includes numerous enhancements, additions and bug fixes over the previous release. We can list only a few of them here: * easier installation * improved documentation * improved examples * bug fixes * a built-in HTTP server for immediate "playing", * a debug app server compatible with WingIDE and other debuggers * support for the Kid templating language * support for PostgreSQL * better support for recent versions of Python including properties, the object type and the datetime module Check out the Webware for Python home page at http://w4py.org From fuzzyman at gmail.com Mon Nov 14 17:06:54 2005 From: fuzzyman at gmail.com (Fuzzyman) Date: 14 Nov 2005 08:06:54 -0800 Subject: ANN: rest2web 0.4.0alpha Message-ID: <1131984414.528210.132080@g44g2000cwa.googlegroups.com> rest2web 0.4.0 alpha is now available. http://www.voidspace.org.uk/python/rest2web/ What's New ? ========== See http://www.voidspace.org.uk/python/rest2web/reference/changelog.html#version-0-4-0-alpha-2005-11-11 Lots of bugfixes and new features since the 0.3.0 release. Includes a new gallery plugin (which will also function as a standalone HTML gallery generator). http://www.voidspace.org.uk/python/rest2web/reference/gallery.html There is also an experimental windows executable version. The documentation has been greatly improved, including a tutorial which should get anyone up to scratch on the basics very quickly. http://www.voidspace.org.uk/python/rest2web/tutorial.html What is rest2web ============= **rest2web** is a tool for autogenerating wesites, or parts of websites. It's main features are : * Integrated with docutils. * Automatically builds index pages and navigation links (sidebars and {acro;breadcrumbs;Weird name for navigation links ?}). * Embedded code in templates for unlimited expressiveness. * Flexible macro system. * Uses relative links, so sites can be viewed from the filesystem. * Unicode internally - so you don't have to be. {sm;:-p} * Includes features for multiple translations of sites. * Built-in gallery creator plugin. * The basic system is very easy to use. * Lots of powerful (optional) features. The content can be stored as HTML, or in reST format; in which case the HTML will be generated using docutils. **rest2web** inserts each page into a template, and automatically creates index pages for sections, and navigation links. From pmartin at snakecard.com Mon Nov 14 18:51:00 2005 From: pmartin at snakecard.com (Philippe C. Martin) Date: Mon, 14 Nov 2005 11:51:00 -0600 Subject: SnakeCard GPL products Message-ID: <200511141151.00303.pmartin@snakecard.com> Dear all, I have decided to focus my activities on development and support. I have released SnakeCard's produt line source code under the GPL licence www.snakecard.com) It includes: SCF: SnakeCard Framework (software=Python) SCFB: SnaleCard Framework Bundle (software=Python, applets BasicCard T=1, JavaCard T=0) SCALS: (software: Python (core), VB6 (GUI), C++ (GINA DLL), applets BasicCard T=1, JavaCard T=0) SC PCSC Server(software=Python) School and Corporate IDs: Python (core), wxWidget (GUI), applets BasicCard T=1, JavaCard T=0) Regards, Philippe -- ************************************* Philippe C. Martin SnakeCard, LLC www.snakecard.com ************************************* From michels at mps.mpg.de Tue Nov 15 11:30:20 2005 From: michels at mps.mpg.de (Helmut Michels) Date: Tue, 15 Nov 2005 11:30:20 +0100 Subject: Data Plotting Library DISLIN 9.0 Message-ID: I am pleased to announce version 9.0 of the data plotting software DISLIN. DISLIN is a high-level and easy to use plotting library for displaying data as curves, bar graphs, pie charts, 3D-colour plots, surfaces, contours and maps. Several output formats are supported such as X11, VGA, PostScript, PDF, CGM, WMF, HPGL, TIFF, GIF, PNG, BMP and SVG. The software is available for several C, Fortran 77 and Fortran 90 compilers. Plotting extensions for the interpreting languages Perl, Python and Java are also supported for the most operating systems. DISLIN distributions and manuals in PDF, PostScript and HTML format are available from the DISLIN home page http://www.dislin.de and via FTP from the server ftp://ftp.gwdg.de/pub/grafik/dislin All DISLIN distributions are free for non-commercial use. ------------------- Helmut Michels Max Planck Institute for Solar System Research Phone: +49 5556 979-334 Max-Planck-Str. 2 Fax : +49 5556 979-240 D-37191 Katlenburg-Lindau Mail : michels at mps.mpg.de From cfbolz at gmx.de Tue Nov 15 18:33:43 2005 From: cfbolz at gmx.de (Carl Friedrich Bolz) Date: Tue, 15 Nov 2005 18:33:43 +0100 Subject: PyPy sprint announcement: Gothenburg 7th - 11th December 2005 Message-ID: <437A1BF7.50802@gmx.de> Gothenburg PyPy Sprint II: 7th - 11th December 2005 ====================================================== (NOTE: internal EU-only sprint starts on the 5th!) The next PyPy sprint is scheduled to be in December 2005 in Gothenborg, Sweden. Its main focus is heading towards phase 2, which means JIT work, alternate threading models and logic programming (but there are also other possible topics). We'll give newcomer-friendly introductions. To learn more about the new PyPy Python-in-Python implementation look here: http://codespeak.net/pypy Goals and topics of the sprint ------------------------------ We have released pypy-0.8.0_, which is officially a "research base" for future work. The goal of the Gothenburg sprint is to start exploring new directions and continue in the directions started at the Paris sprint. The currently scheduled main topics are: - The L3 interpreter, a small fast interpreter for "assembler-level" flow graphs. This is heading towards JIT work. - Stackless: write an app-level interface, which might be either Tasklets, as in "Stackless CPython", or the more limited Greenlets. - Porting C modules from CPython. (_socket is not finished) - Optimization/debugging work in general. In particular our thread support is far from stable at the moment and unaccountably slow. - Experimentation: logic programming in Python. A first step might be to try to add logic variables to PyPy. .. _`pypy-0.8.0`: http://codespeak.net/pypy/dist/pypy/doc/release-0.8.0.html Location & Accomodation ------------------------ The sprint will be held in the apartment of Laura Creighton and Jacob Halen which is in Gotabergsgatan 22. The location is central in Gothenburg. It is between the tram_ stops of Vasaplatsen and Valand, where many lines call. .. _tram: http://www.vasttrafik.se Probably cheapest and not too far away is to book accomodation at `SGS Veckobostader`_. (You can have a 10% discount there; ask in the pypy-sprint mailing list for details. We also have some possibilites of free accomodation.) .. _`SGS Veckobostader`: http://www.sgsveckobostader.com Exact times ----------- The public PyPy sprint is held Wednesday 7th - Sunday 11th December 2005. There is a sprint for people involved with the EU part of the project on the two days before the "official" sprint. Hours will be from 10:00 until people have had enough. It's a good idea to arrive a day before the sprint starts and leave a day later. In the middle of the sprint there usually is a break day and it's usually ok to take half-days off if you feel like it. Network, Food, currency ------------------------ Sweden is not part of the Euro zone. One SEK (krona in singular, kronor in plural) is roughly 1/10th of a Euro (9.15 SEK to 1 Euro). The venue is central in Gothenburg. There is a large selection of places to get food around, from edible-and-cheap to outstanding. You normally need a wireless network card to access the network, but we can provide a wireless/ethernet bridge. Sweden uses the same kind of plugs as Germany. 230V AC. Registration etc.pp. -------------------- Please subscribe to the `PyPy sprint mailing list`_, introduce yourself and post a note that you want to come. Feel free to ask any questions there! There also is a separate `Gothenburg people`_ page tracking who is already thought to come. If you have commit rights on codespeak then you can modify yourself a checkout of http://codespeak.net/svn/pypy/extradoc/sprintinfo/gothenburg-2005/people.txt .. _`PyPy sprint mailing list`: http://codespeak.net/mailman/listinfo/pypy-sprint .. _`Gothenburg people`: http://codespeak.net/pypy/extradoc/sprintinfo/gothenburg-2005/people.html From TrentM at ActiveState.com Wed Nov 16 01:25:29 2005 From: TrentM at ActiveState.com (TrentM@ActiveState.com) Date: Tue, 15 Nov 2005 16:25:29 -0800 Subject: ANN: ActivePython 2.4.2 is now available Message-ID: <200511160025.jAG0PTWe005401@smtp3.ActiveState.com> I'm happy to announce that ActivePython 2.4.2 is now available for free download from: http://www.ActiveState.com/Products/ActivePython/ This release updates ActivePython to version 2.4.2, that was finalized a few weeks ago. My apologies for the tardiness. If you'll believe it, I've been busy implementing *Ruby* AutoComplete in Komodo. One thing you may not have noticed is that ActivePython has added support for a number of platforms in the past months. Installers are available for the following operating systems and architectures: - Windows/x86 - Mac OS X/powerpc (new) - Linux/x86 - Solaris/SPARC - Solaris/x86 (new) - AIX/powerpc (new) - HP-UX/PA-RISC (new) We would welcome any and all feedback to: ActivePython-feedback at ActiveState.com Please file bugs against ActivePython at: http://bugs.ActiveState.com/ActivePython What is ActivePython? --------------------- ActivePython is ActiveState's quality-assured binary distribution of Python. Builds for AIX, HP-UX, Linux, Mac OS X, Solaris, and Windows are made freely available. ActivePython includes the Python core and core extensions (zlib 1.2.3, bzip2 1.0.2, bsddb 4.2.52, Tk 8.4.9, and Tix 8.1.4) and is fully compatible with other Python distributions of the same version. ActivePython also includes a wealth of Python documentation, including: - the core Python docs; - Andrew Kuchling's "What's New in Python" series; - the Non-Programmer's Tutorial for Python; - Mark Pilgrim's excellent "Dive into Python"; and - a snapshot of the Python FAQs, HOWTOs, and PEPs. An online version of the docs can be found here: http://aspn.activestate.com/ASPN/docs/ActivePython/2.4/welcome.html Extra Bits ---------- ActivePython releases also include the following packages: - Windows "debug" package: Debug-built binaries for ActivePython users building debug versions of their binary Python extensions. - ActivePython24.chm: An MS compiled help collection of the full ActivePython documentation set. Linux users of applications such as xCHM might find this useful. This package is installed by default on Windows. These packages are available from: ftp://ftp.activestate.com/ActivePython/etc/ Thanks, and enjoy! Trent, Python Tech Lead -- Trent Mick TrentM at ActiveState.com From jao at geophile.com Wed Nov 16 01:36:07 2005 From: jao at geophile.com (Jack Orenstein) Date: Tue, 15 Nov 2005 19:36:07 -0500 Subject: ANN: Object Shell -- osh 0.6 Message-ID: In a Unix shell, you can run a series of commands, connecting the output of one command with the input to the next command using pipes. The information passed from one command to the next is normally organized into lines of text. Tools such as awk and sed are designed to extract and transform information from these lines. It would be much simpler if the data passed between commands was organized into objects. Osh is based on this idea. Because osh is based on Python, it is Python objects that are passed between commands, and Python functions are used to manipulate objects. Osh is licensed under the GPL. For more information and for downloads: http://geophile.com/osh. Jack Orenstein From python-url at phaseit.net Wed Nov 16 02:50:34 2005 From: python-url at phaseit.net (Cameron Laird) Date: Wed, 16 Nov 2005 01:50:34 +0000 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Nov 16) Message-ID: QOTW: "You can tell everything is well in the world of dynamic languages when someone posts a question with nuclear flame war potential like 'python vs. ruby' and after a while people go off singing hymns about the beauty of Scheme..." - vdrab "ctypes completely rocks." - Grant Edwards Michael Lange endows Tkinter with a Tree widget: http://mail.python.org/pipermail/tkinter-discuss/2005-November/000556.html Fuzzyman has written a valuable commentary on urllib2. How do we collectively get a reference to this in the tutorial and/or library reference? http://www.voidspace.org.uk/python/articles/urllib2.shtml What *is* good style for Pythonic symbolic constants? http://groups.google.com/group/comp.lang.python/browse_thread/thread/f09d1d77d605bdba/ Diez Roggisch and others describe typical limits to the powers of GUI toolkits, and hint at ways to circumvent those limits: http://groups.google.com/group/comp.lang.python/browse_thread/thread/75ac35b00714fd38/ Edgewall Software arranges the tutorial on a tree some readers find convenient: http://projects.edgewall.com/python-sidebar/html/toc-tutorial.html Ben Finney asks serious questions about code re-use: http://groups.google.com/group/comp.lang.python/browse_thread/thread/23dbb109fb831e8f/ We're still a long way from knowing how to manage memory well, and certainly it's an opaque issue during software development. Here's what's known: http://groups.google.com/group/comp.lang.python/browse_thread/thread/da4d11f2a05bfb41/ ======================================================================== 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 at pythonjournal.com and editor at 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.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ (requires subscription) http://groups-beta.google.com/groups?q=python-url+group:comp.lang.python*&start=0&scoring=d& http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python 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 should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask 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. From marc at laukien.org Thu Nov 17 00:10:06 2005 From: marc at laukien.org (Marc Laukien) Date: Wed, 16 Nov 2005 18:10:06 -0500 Subject: ANNOUNCE: Ice 3.0 released Message-ID: ZeroC, Inc. is pleased to announce the availability of the Internet Communications Engine (Ice), version 3.0.0. For a detailed description of Ice, please have a look at http://www.zeroc.com/ice.html. The most significant change since version 2.1.2 is the addition of IceGrid, a replacement for the IcePack activation service that revolutionizes the way you build and deploy your Ice applications. With support for replication, load balancing, and application distribution, IceGrid provides the tools you need to create scalable grid applications and manage them remotely. For more information on IceGrid, please see http://www.zeroc.com/icegrid/index.html. As you have come to expect, this release also includes a great deal of smaller enhancements and fixes that improve the reliability of your programs and help you get them to market faster. In addition to traditional proprietary licensing models for commercial customers, Ice is also freely available as Open Source under the terms of the GNU General Public License (GPL). You can download the complete Ice source and documentation from http://www.zeroc.com/download.html. From tony.meyer at gmail.com Thu Nov 17 01:05:12 2005 From: tony.meyer at gmail.com (Tony Meyer) Date: Thu, 17 Nov 2005 13:05:12 +1300 Subject: python-dev Summary for 2005-09-01 to 2005-09-15 Message-ID: <89D49E4E-7858-4FF2-B122-58CFD7EF362A@gmail.com> [Note: yes, this is *September*! All my (Tony's) bad, Steve has been chugging away at the summaries like he should have. Extra apologies for this one - it was approved by python-dev a while back, and I didn't realise that I hadn't done the python-list post.] python-dev Summary for 2005-09-01 through 2005-09-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-09-01_2005-09-15.html] ============= Announcements ============= ----------------------------- QOTF: Quotes of the Fortnight ----------------------------- In the thread on the print statement, Charles Cazabon provided some nice imagery for Guido's Python 3.0 strategy. Our first QOTF is his comment about the print statement: It's an anomaly. It stands out in the language as a sore thumb waiting for Guido's hammer. We also learned something important about the evolution of Python thanks to Paul Moore. In the thread on the Python 3.0 executable name, Greg Ewing worried that if the Python 3.0 executable is named "py": Python 4.0 is going to just be called "p", and by the time we get to Python 5.0, the name will have vanished altogether! Fortunately, as Paul Moore explains in our second QOTF, these naming conventions are exactly as we should expect them: That's OK, by the time Python 5.0 comes out, it will have taken over the world and be the default language for everything. So omitting the name is exactly right :-) [SJB] Contributing threads: - `Replacement for print in Python 3.0 `__ - `Python 3 executable name `__ -------------------------------------------------- The "Swiss Army Knife (...Not)" API design pattern -------------------------------------------------- This fortnight saw a number of different discussions on what Guido's guiding principles are in making design decisions about Python. Guido introduced the "Swiss Army Knife (...Not)" API design pattern, which has been lauded by some as `the long-lost 20th principle from the Zen of Python`_. A direct quote from Guido: [I]nstead of a single "swiss-army-knife" function with various options that choose different behavior variants, it's better to have different dedicated functions for each of the major functionality types. This principle is the basis for pairs like str.split() and str.rsplit () or str.find() and str.rfind(). The goal is to keep cognitive overhead down by associating with each use case a single function with a minimal number of parameters. [SJB] .. _the long-lost 20th principle from the Zen of Python: http:// mail.python.org/pipermail/python-dev/2005-September/056228.html Contributing threads: - `Replacement for print in Python 3.0 `__ - `Replacement for print in Python 3.0 `__ ------------------------ A Python-to-C++ compiler ------------------------ Mark Dufour announced `Shed Skin`_, an experimental Python-to-C++ compiler, which can convert many Python programs into optimized C++ code, using static type inference techniques. It works best for Python programs written in a relatively static C++-style; much work remains to be done, and Mark would like anyone interested in getting involved to contact him. Shed Skin was one of the recent `Google`_ `Summer of Code`_ projects. .. _Shed Skin: http://shedskin.sourceforge.net .. _Google: http://www.google.com .. _Summer of Code: http://code.google.com/summerofcode.html [TAM] Contributing thread: - `First release of Shed Skin, a Python-to-C++ compiler. `__ -------------------------------------------------------------- python-checkins followups now stay on the python-checkins list -------------------------------------------------------------- In a follow-up to a `thread in early July`_, the python-checkins mailing list Reply-To header munging has been turned off. Previously, follow-ups to python-checkins would be addressed to python-dev; now, follow-ups will stay on the python-checkins list by default. .. _thread in early July: http://www.python.org/dev/summary/ 2005-07-01_2005-07-15.html#behavior-of-sourceforge-when-replying-to- python-checkins [TAM] Contributing thread: - `python-checkins reply-to `__ ========= Summaries ========= -------------------------------------------- Converting print to a function in Python 3.0 -------------------------------------------- In Python 3.0, Guido wants to change print from a statement to a function. Some of his motivation for this change: * Converting code that uses the print statement to instead use the logging package, a UI package, etc. is complicated because of the syntax. Parentheses, commas and >>s all behave differently in the print statement than they would in a function call. * Having print as a statement makes the language harder to evolve. For example, if it's determined that Python should gain printf behavior of some sort, adding this is harder -- as a statement, it would require the introduction of new syntax, as a function, it would feel like a second-class citizen compared to print. * Since the print statement always inserts spaces, code that doesn't want these spaces will often have to use a completely different style of formatting (e.g. using sys.stdout.write and/or string formatting) * Changing the behavior of statements is hard, while builtin functions can simply be replaced by setting an attribute of __builtin__. Guido's initial proposal suggested three methods to be adopted by all stream (file-like) objects:: stream.write(a1, a2, ...) equivalent to: map(stream.write, map(str, [a1, a2, ...])) stream.writeln(a1, a2, ...) equivalent to: stream.write(a1, a2, ..., "\n") stream.writef(fmt, a1, a2, ...) equivalent to: stream.write(fmt % (a1, a2, ...)) Additionally, three new builtins would appear, write(), writeln() and writef() which called the corresponding methods on sys.stdout. People had a number of problems with this initial proposal: * People make heavy use of the space-insertion behavior of the current print statement. With Guido's initial proposal, inserting spaces would require manually adding space characters, e.g. ``write (foo, " ", bar, " ", baz)``. * People want to keep the stream API simple. With Guido's initial proposal, all file-like objects would probably need to support these three new methods. (But see also `Deriving file-like object methods from read() and write()`_.) * People primarily (about 85% of the time) use the print statement to print complete lines. With Guido's initial proposal, the function to do this, writeln(), has the longer name than the less-frequently needed write(). There were a variety of proposals following Guido's that attempted to address the issues above, most of which were posted to the wiki_. They generally all proposed a function something like:: def print(*args): sys.stdout.write(' '.join(str(arg) for arg in args)) sys.stdout.write('\n') with support for a file= keyword parameter to specify a stream other than sys.stdout, and a sep= keyword parameter to specify a separator other than ' '. There was some discussion about how the final newline could be suppressed, including a nl= keyword parameter and the usage of the Ellipsis object (e.g. so that ``print(foo, bar, ...) `` would not print the final newline). There was also substantial support for a formatting variant like:: def printf(fmt, *args): print(fmt % args) In the end, Guido seemed to be leaning towards supporting three printing variants:: * print(...) would be much like the proposals above, calling str() on each argument and then printing them with spaces in between and a following newline * printraw(...) or printbare(...) would also call str() on each argument and print them, but with no intervening spaces and no final newline (c) printf(fmt, ...) would string-substitute the arguments into the format string and then write the format string Each of these functions would also accept a keyword parameter for specifying a stream other than sys.stdout. Because ``print`` is a keyword, ``from __future__ import printing`` would be required to use the new print() function. At this point, the thread trailed off, and no final decisions were made. [SJB] .. _wiki: http://wiki.python.org/moin/PrintAsFunction Contributing threads: - `Python 3 design principles `__ - `Replacement for print in Python 3.0 `__ - `New Wiki page - PrintAsFunction `__ - `Hacking print (was: Replacement for print in Python 3.0) `__ - `Pascaloid print substitute (Replacement for print in Python 3.0) `__ ---------------------------------- Making C code easier in Python 3.0 ---------------------------------- Nick Jacobson asked whether reference counting would be replaced in Python 3.0. Guido pointed out that the (CPython) implementation would have to be completely changed, and that isn't planned; many people also pointed out that reference counting is an implementation detail, not part of the language specification, and that there are other options that can be explored (e.g. `PyPy`_, `Jython`_, `IronPython`_). Arising from this question was a suggestion from Greg Ewing to build something akin to `Pyrex`_ (which takes care of reference count/ garbage collection issues automatically) into the standard Python distribution. This suggestion was met with general enthusiasm; some general discussion about which cases were most appropriate for Pyrex use (e.g. extension modules, wrapping C libraries, modules implemented in C for performance reasons) also followed. .. _PyPy: http://codespeak.net/pypy/ .. _Jython: http://www.jython.org/ .. _IronPython: http://www.ironpython.com/ .. _Pyrex: http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/ [TAM] Contributing thread: - `reference counting in Py3K `__ -------------------------- Multiple views of a string -------------------------- Tim Delaney suggested that str.partition could return 'views' of a string, rather than new string objects, as the substrings, to avoid the time needed to create strings that are potentially unused. Raymond Hettinger pointed out that the practical cost is unlikely to be significant, as the strings are likely to be empty, small, or used, and that all the pre-Python 2.5 methods would still be available for those times when they would be more appropriate. However, using string 'views' (objects that reference the 'parent' string, rather than copying the data) caught the imagination of several Python-dev'ers. Discussion ensued about how this object could work (Skip Montanaro threw together a sample implementation); towards the end it was pointed out that buffer() objects, with some additional string methods, could provide this slice-like instance with low memory requirements. Guido also mentioned `NSString`_, the NextStep string type used by `ObjC`_, which is fairly similar. .. _ObjC: http://en.wikipedia.org/wiki/Objc .. _NSString: http://developer.apple.com/documentation/Cocoa/ Reference/Foundation/ObjC_classic/Classes/NSString.html [TAM] Contributing threads: - `Proof of the pudding: str.partition() `__ - `String views (was: Re: Proof of the pudding: str.partition()) `__ - `String views `__ ------------------------------- String-formatting in Python 3.0 ------------------------------- Currently, using ``%`` for string formatting has a number of inconvenient consequences: * precedence issues: ``"a%sa" % "b"*4`` produces ``'abaabaabaaba'``, not ``'abbbba'`` * special-cased tuples: ``"%s" % x`` produces a string representation of x *unless* x is a tuple (in which case it unpacks it, raising a TypeError if ``len(x) != 1``). * keyword formatting issues: a number of people have complained that ``%(myvar)s`` is much more complicated than it needs to be (hence string.Template's ``$myvar``). To address the first two issues, Raymond Hettinger proposed that string formatting become a builtin function, and others proposed that formatting become a method of str/unicode objects. Guido definitely agreed with the move from ``%`` to a callable, but it was unclear as to his preference for function or method. Nick Coghlan tried to address the ``%(myvar)s`` issue by exploring a few extensions to string.Template formatting. He produced a format() function where arguments could be specified either by position (e.g. $1, $2, etc.) or with keywords (e.g. $item, $quantity), and where the usual C-style format specifiers were still supported:: format("$item: $[0.2f]quantity", quantity=0.5, item='Bees') format("$1: $[0.2f]2", 'Bees', 0.5) Nick also briefly explored format specifiers for expanding iterables, but Guido disliked the idea, explaining that adding or removing a print from a program should not drastically change the program's behavior (as it might if a print accidentally consumed an iterable that you weren't done with). There was also some high-level discussion about internationalization concerns, where format strings need to be easy for translators to read and reorganize. Since word orders may change, having either keyword parameters or positional parameters (as in Nick's scheme) is crucial. Unfortunately, this discussion seemed to get lost in the massive `Converting print to a function in Python 3.0`_ discussion, and no decisions were made about either a formatting function or Nick's format specifier extensions. [SJB] Contributing threads: - `Replacement for print in Python 3.0 `__ - `string formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0) `__ - `string formatting and i18n `__ - `string.Template format enhancements (Re: Replacement for print in Python 3.0) `__ --------------------------------------------------------- Deriving file-like object methods from read() and write() --------------------------------------------------------- A variety of methods on the file object, including __iter__(), next (), readline(), readlines() and writelines(), are all derivable from the read() and write() methods. At least twice this fortnight, the issue was raised about making it easier for file-like objects to add the derivable methods if they've defined read() and write(). One suggestion was to provide a FileMixin class (like the DictMixin of UserDict) that other types could inherit from. This has the problem that the creator of the file-like object must determine at the time that the class is defined that it should support the additional methods. It is also more difficult to use mixin classes in C code (because multiple inheritance requires dealing with the type's metaclass). Fredrik Lundh suggested that something along the lines of `PEP 246`_'s object adaptation might be appropriate, but there was still some disagreement on the issue. [SJB] .. _PEP 246: http://www.python.org/peps/pep-0246.html Contributing threads: - `Mixin classes in the standard library `__ - `Simplify the file-like-object interface (Replacement for print in Python 3.0) `__ - `Simplify the file-like-object interface `__ ------------------------------------ Making new-style classes the default ------------------------------------ Lisandro Dalcin proposed that something like:: from __future__ import new_style_classes be introduced to have newly defined classes implicitly derive from object. It was pointed out that this functionality is already available through the module-level statement:: __metaclass__ = type The argument was made that the __future__ version would be easier for non-experts to understand and to Google for, but Guido declared that the current syntax is fine -- there are much more important issues to be dealt with right now. [SJB] Contributing thread: - `PEP 3000 and new style classes `__ -------------------------------------------------- Using __future__ to have builtins return iterators -------------------------------------------------- Lisandro Dalcin requested a __future__ import of some sort that would * make range() and zip() return iterators * remove xrange() * make the dict.keys(), dict.values(), dict.items() etc. methods return iterators Guido indicated that an alternate builtins module could be provided so that the first point could be covered with something like:: from future_builtins import zip, range However, there wasn't really a good way to change the dict methods. Simply importing a new dict object from "future_builtins" wouldn't solve the problem because using anyone's module that used the old dict object would mean a mix of the two types in your module. And since __future__ imports are intended to affect only the module which includes them, changing the builtin dict object globally would be inappropriate (as it would let an import in one module break code in another). [SJB] Contributing thread: - `PEP 3000 and iterators `__ ------------------------------------------------------------- Using compiled re methods vs. using module-level re functions ------------------------------------------------------------- After Michael Chermside commented that users should be encouraged to use the methods on compiled re objects instead of the re functions available at the module level (and after Stephen J. Turnbull promised to look into supplying such a documentation patch), there was a brief discussion about how much of a difference using the compiled re objects really makes. As it turns out, in the CPython implementation, the module-level functions cache the first 100 patterns, so in many cases, the only additional cost of using the module-level functions is a dictionary lookup. [SJB] Contributing thread: - `Revising RE docs `__ -------------------------------------- urlparse and urls with too many '../'s -------------------------------------- Fabien Schwob pointed out that urlparse.join() doesn't strip out any extraneous '..' directories (e.g. http://example.com/../index.html). While Guido indicated that he found the current behaviour acceptable, Jeff Epler pointed out that `RFC 2396`_ states that invalid URIs like this may be handled by removing the ".." segments from the resolved path (although this is an implementation detail). Armin Rigo indicated that, even if this is theoretically not a bug, a proposed patch with this motiviation would be welcome. .. _RFC 2396: http://www.faqs.org/rfcs/rfc2396.html [TAM] Contributing thread: - `bug in urlparse `__ ----------------------------------------------- Using an iterator instead of a tuple for \*args ----------------------------------------------- Nick Coghlan suggested that in Python 3.0, the \*args extended function call syntax should produce an iterator instead of a tuple as it currently does. That would mean that code like:: output(*some_long_iterator) would not load the entire iterator into a memory before processing it. I pointed him to a previous discussion Raymond Hettinger and I had about the subject that indicated that for \*args, sequences were preferable to iterators in a number of situations. Guido agreed, indicating that \*args will continue to be sequences in Python 3.0. [SJB] Contributing thread: - `iterators and extended function call syntax (WAS: Replacement for print in Python 3.0) `__ ---------------------------------------- Constructing traceback objects in Python ---------------------------------------- Contributing thread: - `Asynchronous use of Traceback objects `__ ------------------------------- No dedent() methods for strings ------------------------------- Contributing thread: - `str.dedent `__ ------------------------ Arguments vs. parameters ------------------------ - `Term unification `__ ----------------------------------------------------------------------- Removing sequence support from the return value of stat() in Python 3.0 ----------------------------------------------------------------------- Terry J. Reedy proposed that, in Python 3.0, instead of os.stat() returning a sequence (where the order of the items is only of historical significance), a proper stat object be returned. This was met with general support, and so seems likely to occur. Skip Montanaro also proposed that the st_ prefixes in the attribute names be removed, since there are no namespace issues to be concerned with, which met with some approval, but concern from Guido that the forms with the prefixes would be more familiar to users, and make Googling or grepping simpler. [TAM] Contributing thread: - `stat() return value (was: Re: Proof of the pudding: str.partition ()) `__ -------------------------------------------------- Making code in the Tools directory more accessible -------------------------------------------------- Installation of Python typically doesn't include the Tools directory; combined with the lack of mention of these scripts in the documentation, this means that knowledge of these generally useful scripts is fairly limited. Tim Peters noted that historically a Tools directory was only added to the Windows installer if it was specifically requested; as such, the audiopy, bgen, compiler, faqwiz, framer, modulator, msi, unicode, and world Tools directories are not currently included in the Windows installer. Nick Coghlan added that Tools/README.txt isn't included in the Windows installer, so Windows users don't get a synopsis of the tools that are included; he also suggested that adding this readme to the "undocumented modules" section of the standard library would be a simple improvement. Non- windows users typically don't get the Tools directory at all with an install. Remaining questions included how the directory should be documented (e.g. man pages for the scripts, a documentation page for them), where to install them on non-Windows installations (e.g. /usr/share/ python, /usr/lib/pythonX.Y/Tools), and whether the Windows installer should include all of the directories. [TAM] Contributing thread: - `Tools directory (Was RE: Replacement for print in Python 3.0) `__ ---------------------------------- Responsiveness of IDLE development ---------------------------------- Noam Raphael posted a request for help getting a large patch to IDLE committed to CVS. He was concerned that there hasn't been any IDLE development recently, and that patches are not being considered. He indicated that his group was considering offering a fork of IDLE with the improvements, but that they would much prefer integrating the improvements into the core distribution. It was pointed out that a fork might be the best solution, for various reasons (e.g. the improvements may not be of general interest, the release time would be much quicker), and that this was how the current version of IDLE was developed. However, later on it turned out that Kurt Kaiser had missed the python-dev message, and when it was brought to his attention he moved the discussion to idle- dev, and it seems that everything will end happily and fork-less. [TAM] Contributing thread: - `IDLE development `__ ----------------------------- Speeding up list append calls ----------------------------- A `comp.lang.python message from Tim Peters`_ prompted Neal Norwitz to investigate how the code that Tim posted could be sped up. He hacked the code to replace var.append() with the LIST_APPEND opcode, and achieved a roughly 200% speed increase. Although this doesn't work in general, Neal wondered if it could be used as a peephole optimization when a variable is known to be a list. Martin v. L?wis suggested that the code could simply check whether it was a list; Phillip J. Eby and Fredrik Lundh pointed out that this is similar to what various math operators do (e.g. speeding up int + int calls). .. _comp.lang.python message from Tim Peters: http:// groups.google.com/group/comp.lang.python/msg/9075a3bc59c334c9 [TAM] Contributing thread: - `speeding up list append calls `__ ------------------------------------ Allowing str.strip to remove "words" ------------------------------------ Jonny Reichwald proposed an enhancement to str.strip(). In addition to its current form, where it takes a string of characters to strip, to take any iterable containing either character lists or string lists, so that is is possible to remove entire words from the stripped string. For example:: #A char list gives the same result as the standard strip >>> my_strip("abcdeed", "de") 'abc' #A list of strings instead >>> my_strip("abcdeed", ("ed",)) 'abcde' #The char order in the strings to be stripped are of importance >>> my_strip("abcdeed", ("ad", "eb")) 'abcdeed' Raymond Hettinger queried whether there was actual demand for such a change, and whether such demand was sufficient to justify the added complexity; Josiah Carlson also pointed out that implementing this only requires a four-line function. Judging from the lack of responses, it seems likely that there isn't enough demand. Contributing thread: - `str.strip() enhancement `__ ================ Deferred Threads ================ - `C coding experiment `__ - `os.path.diff(path1, path2) `__ =============== Skipped Threads =============== - `import exceptions `__ - `[Python-checkins] python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4 `__ - `setdefault's second argument `__ - `Alternative imports (Re: Python 3 design principles) `__ - `python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4 `__ - `Status of PEP 328 `__ - `Weekly Python Patch/Bug Summary `__ - `itertools.chain should take an iterable ? `__ - `partition() (was: Remove str.find in 3.0?) `__ - `gdbinit problem `__ - `Exception Reorg PEP checked in `__ - `international python `__ - `SIGPIPE => SIG_IGN? `__ - `[draft] python-dev Summary for 2005-08-16 through 2005-08-31 `__ - `[Python-checkins] python/dist/src/Lib urllib.py, 1.169, 1.170 `__ - `Wanting to learn `__ - `Python code.interact() and UTF-8 locale `__ - `pygettext() without newlines (Was: Re: Replacement for print in Python 3.0) `__ - `Python 3 executable name (was: Re: PEP 3000 and iterators) `__ - `Python 3 executable name `__ - `Skiping searching throw dictionaries of mro() members. `__ - `Fwd: [Python-checkins] python/dist/src/Misc NEWS, 1.1193.2.94, 1.1193.2.95 `__ - `[Python-checkins] python/dist/src/Lib/test regrtest.py, 1.171, 1.172 test_ioctl.py, 1.2, 1.3 `__ - `python/dist/src/Lib urllib.py, 1.165.2.1, 1.165.2.2 `__ - `Variant of removing GIL. `__ - `Compatibility between Python 2.3.x and Python 2.4.x `__ - `Example for "property" violates "Python is not a one pass compiler" `__ - `python optimization `__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from September 01, 2005 through September 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 3rd summary written by the python-dev summary pairing of Steve Bethard and Tony Meyer (Tempus Fugit!). 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 penny helps 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 at 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://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/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-07-16_2005-07-31.html .. _original text file: http://www.python.org/dev/summary/ 2005-09-01_2005-09-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf From fabioz at esss.com.br Thu Nov 17 17:44:24 2005 From: fabioz at esss.com.br (Fabio Zadrozny) Date: Thu, 17 Nov 2005 13:44:24 -0300 Subject: PyDev 0.9.8.5 released In-Reply-To: <434E801E.3010702@esss.com.br> References: <43382E1F.3000600@esss.com.br> <434E801E.3010702@esss.com.br> Message-ID: <437CB368.2010501@esss.com.br> Hi All, PyDev - Python IDE (Python Development Enviroment for Eclipse) version 0.9.8.5 has been released. Check the homepage (http://pydev.sourceforge.net/) for more details. Details for Release: 0.9.8.5 Major highlights: ------------------- * Removed the dependency on packages 'sun.xxxx.Base64', so that other VMs can be targetted * Some code-completion problems in the 'resolution order' regarding tokens in __init__ were solved * Added option so that the user can choose whether to automatically add 'self' or not in method declarations Cheers, Fabio -- Fabio Zadrozny ------------------------------------------------------ Software Developer ESSS - Engineering Simulation and Scientific Software www.esss.com.br PyDev - Python Development Enviroment for Eclipse pydev.sf.net pydev.blogspot.com From smulloni at smullyan.org Thu Nov 17 22:28:54 2005 From: smulloni at smullyan.org (Jacob Smullyan) Date: Thu, 17 Nov 2005 15:28:54 -0600 Subject: ANN: PyDO 2.0rc1 Message-ID: I'm pleased to announce the release of PyDO-2.0rc1. What's New ---------- * If you pass in a module via the new "module" keyword argument of the project() method of PyDO objects and the autoschema function, the dynamically generated classes generated will be associated with that module so it can be pickled and unpickled. * several bugfixes, with corresponding tests. What it is ---------- PyDO is Drew Csillag's ORM (Object-Relational Mapper) database access library for Python that facilitates writing a Python database access layer. PyDO attempts to be simple, flexible, extensible, and unconstraining. PyDO 2 is a rewrite of the 1.x series distributed with SkunkWeb. It has several enhancements: * PyDO can now be used in multi-threaded or twisted-style asynchronous sitations, with or without a customizable connection pool. * PyDO objects are now dict subclasses, but also support attribute access to fields. * Projections -- subsets of the field list of a super-class -- are now supported by the PyDO.project() method. * Table attributes are now declared in a more concise way. * PyDO2 supports runtime table introspection. * Overall, the API has been tightened and the code restructured. PyDO 2 requires Python 2.4 or later. It currently supports PostgreSQL, MySQL, Sqlite, MSSQL, and Oracle. PyDO is dual GPL/BSD licensed. The source tarball is available at SkunkWeb's berlios site: https://developer.berlios.de/projects/skunkweb/ or, more directly: http://download.berlios.de/skunkweb/PyDO-2.0rc1.tar.gz or at the cheeseshop: http://cheeseshop.python/org/pypi/PyDO or install it with easy_install: easy_install PyDO Questions pertaining to PyDO can be addressed to the SkunkWeb mailing list at sourceforge: http://lists.sourceforge.net/lists/listinfo/skunkweb-list Cheers, Jacob Smullyan From mj at zopatista.com Fri Nov 18 17:26:32 2005 From: mj at zopatista.com (Martijn Pieters) Date: Fri, 18 Nov 2005 17:26:32 +0100 Subject: Python-NL Conference: Python Pepernoten Meeting Message-ID: <437E00B8.2020006@zopatista.com> ========================= Python Pepernoten meeting ========================= On December 9th the PUN (Python Usergroup Netherlands) will hold it's "Pepernoten" meeting in De Waag in Amsterdam. This is a free and freely accessible meeting. Location and time ----------------- The meeting will take place in `De Waag`_ in Amsterdam. De Waag is located in the centre of Amsterdam on the `Nieuwmarkt 4`_ (about 15 minutes walk from Central Station or by Metro lines 51, 53 and 54, station Nieuwmarkt). We'll start at 10am and the program will probably last until about 4pm. Afterwards there is time for informal socialising. Programme --------- Below is the provisional program. If you'd like to give a talk please let us know. All talks will be in Dutch. * Jack Jansen - Bgen en C++ (like SWIG but good ;-) * Stani Michiels - SPE (open source IDE) * Dick Kniep - Lindix (large project with various connections to for example OpenOffice) * Martijn Faassen - lxml (super-fast xml library) (provisional) * Jeroen Vloothuis - Zope 3 technology outside of Zope * Lightning talks Lightning talks --------------- The idea of the Lightning talks is to give people the opportunity to share their findings. If you have something to show off but don't have enough material to fill a full presentation this is your call. We have several registered lightning talks already; the exact programme will be announced later. Registration and costs ---------------------- Registration is free, although food and drink are to be paid for by yourself. We do ask you to register yourself online (in Dutch) at: http://nl.python.org/aanmelden_pepernoten/ .. _De Waag: http://www.waag.org/waagsite/ .. _Nieuwmarkt 4: http://tinyurl.com/d73r7 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://mail.python.org/pipermail/python-announce-list/attachments/20051118/425686be/signature.pgp From Ivo at textnews.nntp.hccnet.nl Fri Nov 18 14:57:29 2005 From: Ivo at textnews.nntp.hccnet.nl (IvoNet@gmail.com) Date: 18 Nov 2005 13:57:29 GMT Subject: New: PPCEncoder 4 PocketPC Message-ID: <437dddc9$0$812$3a628fcd@textreader.nntp.hccnet.nl> I have written a nice Multimedia re-encoder (PPCEncoder) in Python. It re-encodes movies to PocketPC format. You can find it here: http://IvoNet.nl Greetz, Ivo. PS. I'm planning on making it OpenSource, but before I do that I want to clean up the code more. http://IvoNet.nl -- ---------------------------------------------- Posted with NewsLeecher v3.0 Final * Binary Usenet Leeching Made Easy * http://www.newsleecher.com/?usenet ---------------------------------------------- From pmartin at snakecard.com Fri Nov 18 20:14:31 2005 From: pmartin at snakecard.com (Philippe C. Martin) Date: Fri, 18 Nov 2005 13:14:31 -0600 Subject: SnakeCard on sourceforge Message-ID: <200511181314.31432.pmartin@snakecard.com> Dear all, The SnakeCard product line is now hosted on sourceforge.net: SCFB - http://sourceforge.net/projects/sctoolkits SC-ID - http://sourceforge.net/projects/sc-id I will keep posting the snapshots on www.snakecard.com as well as SCLOGON and SCWEB until they take shape ;-) Regards, Philippe -- ************************************* Philippe C. Martin SnakeCard, LLC www.snakecard.com ************************************* From amk at amk.ca Sat Nov 19 16:22:35 2005 From: amk at amk.ca (A.M. Kuchling) Date: Sat, 19 Nov 2005 10:22:35 -0500 Subject: Help sponsor Pycon Message-ID: <20051119152235.GA9610@rogue.amk.ca> PyCon is now looking for sponsors to help fund the conference; please see for more information. Sponsors help ensure that PyCon remains a low-cost conference. Several levels of sponsorship are available to match your company's budget. Sponsoring is also a good targeted way to reach a large set of Python users. If you want to advertise something -- a product, a book, a job opening -- to the PyCon community, it costs only $200 to include your marketing material in the tote bag given to all conference attendees. For more details, see . A.M. Kuchling Chair, PyCon 2006 amk at amk.ca From ianb at colorstudy.com Mon Nov 21 01:21:57 2005 From: ianb at colorstudy.com (Ian Bicking) Date: Sun, 20 Nov 2005 18:21:57 -0600 Subject: ANN: FormEncode 0.4 Message-ID: <43811325.2080404@colorstudy.com> I'm pleased to announce FormEncode 0.4. What Changed? ------------- Lots of cleanups and clarifications. Also a module to integrate with SQLObject. Read all about the changes: http://formencode.org/news.html What is it? ----------- FormEncode is a package for form validation and conversion. It also includes modules for parsing, filling, and extracting metadata from HTML forms. It features robust conversion both of incoming and outgoing data, attention paid to helpful error messages, and a wide variety of pre-build validators. It also supports composition of validators, and validating structured data, including nested and repeating form elements. FormEncode is being used in several projects, including Subway, TurboGears, and SQLObject. Where is it? ------------ Website and docs: http://formencode.org Download: http://cheeseshop.python.org/pypi/FormEncode -- Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org From mcfletch at vrplumber.com Mon Nov 21 05:34:01 2005 From: mcfletch at vrplumber.com (Mike C. Fletcher) Date: Sun, 20 Nov 2005 23:34:01 -0500 Subject: Toronto Python User's Group (PyGTA) meeting this Tuesday Message-ID: <43814E39.70804@vrplumber.com> We will again be holding PyGTA at the Linux Caffe @ 7pm this Tuesday. If no one else stands up to suggest a topic I'm thinking I'll discuss/show the OpenGL-ctypes work I've been doing on and off for the past few months. I'll try to get a laptop on which to present it so it can produce a few pretty graphics while we discuss how it's written and why I've gone with a foreign-function interface to replace the SWIG-wrapped one. More details can be found here: http://web.engcorp.com/pygta/wiki/NextMeeting Have fun, Mike -- ________________________________________________ Mike C. Fletcher Designer, VR Plumber, Coder http://www.vrplumber.com http://blog.vrplumber.com From tony.meyer at gmail.com Mon Nov 21 06:02:35 2005 From: tony.meyer at gmail.com (Tony Meyer) Date: Mon, 21 Nov 2005 18:02:35 +1300 Subject: python-dev Summary for 2005-09-16 through 2005-09-30 Message-ID: <6c63de570511202102v60ca7c13ra4ff032d7574daa4@mail.gmail.com> [The HTML version of this Summary will be available at http://www.python.org/dev/summary/2005-09-16_2005-09-30.html] ============= Announcements ============= ----------------------------- QOTF: Quotes of the fortnight ----------------------------- We have two quotes this week, one each from the two biggest threads of this fortnight: concurrency and conditional expressions. The first quote, from Donovan Barda, puts Python's approach to threading into perspective: The reality is threads were invented as a low overhead way of easily implementing concurrent applications... ON A SINGLE PROCESSOR. Taking into account threading's limitations and objectives, Python's GIL is the best way to support threads. When hardware (seriously) moves to multiple processors, other concurrency models will start to shine. Our second QOTF, by yours truly (hey, who could refuse a nomination from Guido?), is a not-so-subtle reminder to leave syntax decisions to Guido: Please no more syntax proposals! ... We need to leave the syntax to Guido. We've already proved that ... we can't as a community agree on a syntax. That's what we have a BDFL for. =) Contributing threads: - `GIL, Python 3, and MP vs. UP < http://mail.python.org/pipermail/python-dev/2005-September/056609.html>`__ - `Adding a conditional expression in Py3.0 < http://mail.python.org/pipermail/python-dev/2005-September/056617.html>`__ [SJB] ------------------- Compressed MSI file ------------------- Martin v. L?wis discovered that a little more than a `MiB`_ could be saved in the size of Python installer by using LZX:21 instead of the standard MSZIP when compressing the CAB file. After confirmation from several testers that the new format worked, the change (for Python 2.4.2 and beyond) was made. .. _MiB: http://en.wikipedia.org/wiki/Mibibyte Contributing thread: - `Compressing MSI files: 2.4.2 candidate? < http://mail.python.org/pipermail/python-dev/2005-September/056694.html>`__ [TAM] ========= Summaries ========= ----------------------- Conditional expressions ----------------------- Raymond Hettinger proposed that the ``and`` and ``or`` operators be modified in Python 3.0 to produce only booleans instead of producing objects, motivating this proposal in part by the common (mis-)use of `` and or `` to emulate a conditional expression. In response, Guido suggested that that the conditional expression discussion of `PEP 308`_ be reopened. This time around, people seemed almost unanimously in support of adding a conditional expression, though as before they disagreed on syntax. Fortunately, this time Guido cut the discussion short and pronounced a new syntax: `` if else ``. Although it has not been implemented yet, the plan is for it to appear in Python 2.5. .. _PEP 308: http://www.python.org/peps/pep-0308.html Contributing threads: - `"and" and "or" operators in Py3.0 < http://mail.python.org/pipermail/python-dev/2005-September/056510.html>`__ - `Adding a conditional expression in Py3.0 < http://mail.python.org/pipermail/python-dev/2005-September/056546.html>`__ - `Conditional Expression Resolution < http://mail.python.org/pipermail/python-dev/2005-September/056846.html>`__ [SJB] --------------------- Concurrency in Python --------------------- Once again, the subject of removing the global interpreter lock (GIL) came up. Sokolov Yura suggested that the GIL be replaced with a system where there are thread-local GILs that cooperate to share writing; Martin v. L?wis suggested that he try to implement his ideas, and predicted that he would find that doing so would be a lot of work, would require changes to all extension modules (likely to introduce new bugs, particularly race conditions), and possibly decrease performance. This kicked off several long threads about multi-processor coding. A long time ago (circa Python 1.4), Greg Stein experimented with free threading, which did yield around a 1.6 times speedup on a dual-processor machine. To avoid the overhead of multi-processor locking on a uniprocessor machine, a separate binary could be distributed. Some of the code apparently did make it into Python 1.5, but the issue died off because no-one provided working code, or a strategy for what to do with existing extension modules. Guido pointed out that it is not clear at this time how multiple processors will be used as they become the norm. With the threaded programming model ( e.g. in Java) there are problems with concurrent modification errors (without locking) or deadlocks and livelocks (with locking). Guido's hunch (and mine, FWIW) is that instead of writing massively parallel applications, we will continue to write single-threaded applications that are tied together at the process level rather than at the thread level. He also pointed out that it's likely that most problems get little benefit out of multiple processors. Guido threw down the gauntlet: rather than the endless discussion about this topic, someone should come up with a GIL-free Python (not necessarily CPython) and demonstrate its worth. Phillip J. Eby reminded everyone that Jython, IronPython, and PyPy exist, and that someone could, for example, create a multiprocessor-friendly backend for PyPy. Guido also pointed out that fast threading benefits from fast context switches, which benefits from small register sets, and that the current trend in chips is towards larger register sets. In addition, multiple processors with shared memory don't scale all that well (multiple processors with explicit interprocess communication (IPC) channels scale much better). These all favour multi-processing over multi-threading. Donovan Baarda went so far as to say (a QOTF, as above), that Python's GIL is the best way to support threads, which are for single-processor use, and that when multiple-processor platforms have matured more other concurrency models will likewise mature. OTOH, Bob Ippolito pointed out that (in many operating systems) there isn't a lot of difference between threads and processes, and that threads can typically still use IPC. Bob argued that the biggest argument for threading is that lots of existing C/C++ code uses threads. Simon Percivall argued that the problem is that Python offers ("out of the box") some support for multi-threaded programming, but little for multi-process programming beyond the basics (e.g. data sharing, communication, control over running processes, dealing out tasks to be handled). Simon suggested that the best way to stop people complaining about the GIL is to provide solid, standardized support for multi-process programming. The idea of a "multiprocess" module gained a reasonable amount of support. Phillip J. Eby outlined an idea he is considering PEPifying, in which one could switch all context variables (such as the Decimal context and the sys.* variables) simulaneously and instantaneously when changing execution contexts (like switching between coroutines). He has a prototype implementation of the basic idea, which is less than 200 lines of Python and very fast. However, he pointed out that it's not completely PEP-ready at this point, and he needs to continue considering various parts of the concept. Bruce Eckel joined the thread, and suggested that low-level threads people are only now catching up to objects, but as far as concurrency goes their brains still think in terms of threads, so they naturally apply thread concepts to objects. He believes that pthread-style thinking is two steps backwards: you effectively throw open the innards of the object that you just spent time decoupling from the rest of your system, and the coupling is not predictable. Bruce and Guido had discussed offlist "active objects": defining a class as "active" would install a worker thread and concurrent queue in each object of that class, automatically turn method calls into tasks and enqueue them, and prevent any other interaction other than enqueued messages. Guido felt that if multiple active objects could co-exist in the same process, but be prevented (by the language implementation) from sharing data except via channels, and dynamic reallocation of active objects across multiple CPUs were possible, then this might be a solution. He pointed out that an implementation would really be needed to prove this. Phillip and Martin pointed out that preventing any other interaction other than enqueued messages is the difficult part; each active object would, for example, have to have its own sys.modules. Phillip felt that such a solution (which Bruce posed as "a" solution, not "the" solution) wouldn't help with GIL removal, but would help with effective use of multiprocessor machines on platforms where fork() is available, if the API works across processes as well as threads. Bruce then restarted the discussion, putting forth eight criteria that he felt would be necessary for the "pythonic" solution to concurrency. Items on the list were discussed further, with some disagreement about what was possible. The concurrency discussion continues next month... Contributing threads: - `Variant of removing GIL. < http://mail.python.org/pipermail/python-dev/2005-September/056423.html>`__ - `GIL, Python 3, and MP vs. UP (was Re: Variant of removing GIL.) < http://mail.python.org/pipermail/python-dev/2005-September/056458.html>`__ - `GIL, Python 3, and MP vs. UP < http://mail.python.org/pipermail/python-dev/2005-September/056498.html>`__ - `Active Objects in Python < http://mail.python.org/pipermail/python-dev/2005-September/056752.html>`__ - `Pythonic concurrency < http://mail.python.org/pipermail/python-dev/2005-September/056801.html>`__ - `Pythonic concurrency - cooperative MT < http://mail.python.org/pipermail/python-dev/2005-September/056860.html>`__ [TAM] ----------------------------------- Removing nested function parameters ----------------------------------- Brett Cannon proposed removing support for nested function parameters so that instead of being able to write:: def f((x, y)): print x, y you'd have to write something like:: def f(arg): x, y = arg print x, y Brett (with help from Guido) motivated this removal (for Python 3.0) by a few factors: (1) The feature has low visibility: "For every user who is fond of them there are probably ten who have never even heard of it." - Guido (2) The feature can be difficult to read for some people. (3) The feature doesn't add any power to the language; the above functions emit essentially the same byte-code. (4) The feature makes function parameter introspection difficult because tuple unpacking information is not stored in the function object. In general, people were undecided on this proposal. While a number of people said they used the feature and would miss it, many of them also said that their code wouldn't suffer that much if the feature was removed. No decision had been made at the time of the summary. Contributing thread: - `removing nested tuple function parameters < http://mail.python.org/pipermail/python-dev/2005-September/056459.html>`__ [SJB] ----------------------------------------- Evaluating iterators in a boolean context ----------------------------------------- In Python 2.4 some builtin iterators gained __len__ methods when the number of remaining items could be made available. This broke some of Guido's code that tested iterators for their boolean value (to distinguish them from None). Raymond Hettinger (who supplied the original patch) argued that `testing for None`_ using boolean tests was in general a bad idea, and that knowing the length of an iterator, when possible, had a number of use cases and allowed for some performance gains. However, Guido felt strongly that iterators should not supply __len__ methods, as this would lead to some people writing code expecting this method, which would then break when it received an iterator which could not determine its own length. The feature will be rolled back in Python 2.5, and Raymond will likely move the __len__ methods to private methods in order to maintain the performance gains. .. _testing for None: http://www.python.org/peps/pep-0290.html#testing-for-none Contributing threads: - `bool(iter([])) changed between 2.3 and 2.4 < http://mail.python.org/pipermail/python-dev/2005-September/056576.html>`__ - `bool(container) [was bool(iter([])) changed between 2.3 and 2.4] < http://mail.python.org/pipermail/python-dev/2005-September/056879.html>`__ [SJB] -------------------------------------------------- Properties that only call the getter function once -------------------------------------------------- Jim Fulton proposed adding a new builtin for a property-like descriptor that would only call the getter method once, so that something like:: class Spam(object): @readproperty def eggs(self): ... expensive computation of eggs self.eggs = result return result would only do the eggs computation once. Currently, you can't do this with a property() because the ``self.eggs = result`` statement tries to call the property's ``fset`` method instead of replacing the property with the result of the eggs() call. A few other people commented that they'd needed similar functionality at times, and Guido seemed moderately interested in the idea, but there was no final resolution. Contributing thread: - `RFC: readproperty < http://mail.python.org/pipermail/python-dev/2005-September/056769.html>`__ [SJB] -------- Codetags -------- Micah Elliott submitted his `Codetags PEP 350`_ (after revisions following the comp.lang.python discussion) to python-dev for comment. A common feeling was that this (particularly synonyms) was over-engineering; Guido pointed out that he only uses XXX, and this is certainly the most common (although not only) example in the Python source itself. Some suggestions were made, many of which Micah integrated into the PEP. The suggestion was made that an implementation should precede approval of the PEP. Micah indicated that he would continue development on the tools, and that he encourages anyone interested in using a standard set of codetages to give these a try. .. _Codetags PEP 350: http://python.org/peps/pep-0350.html - `PEP 350: Codetags < http://mail.python.org/pipermail/python-dev/2005-September/056744.html>`__ [TAM] ---------------------------- Improving set implementation ---------------------------- Raymond Hettinger suggested a "small, but interesting, C project" to determine whether the setobject.c implementation would be improved by recoding the set_lookkey() function to optimize key insertion order using Brent's variation of Algorithm D (c.f. Knuth vol. III, section 6.4, p525). It has the potential to boost performance for uniquification applications with duplicate keys being identified more quickly, and possibly also more frequent retirement of dummy entires during insertion operations. Andrew Durdin pointed out that Brent's variation depends on the next probe position for a key being derivated from the key and its current position, which is incompatible with the current perturbation system; Raymond replaced perturbation with a secondary hash with linear probing. Antoine Pitrou did some `experimenting with this`_, resulting in a -5% to 2% speedup with various benchmarks. Raymond has also been experimenting with a simpler approach: whenever there are more than three probes, always swap the new key into the first position and then unconditionally re-insert the swapped-out key. He reported that, most of the time, this gives an improvement, and it doesn't require changing the perturbation logic. This simpler approach is cheap to implement, but the benefits are also smaller, with it improving only the worse collisions. .. _experimenting with this: http://pitrou.net/python/sets - `C coding experiment < http://mail.python.org/pipermail/python-dev/2005-September/055965.html>`__ [TAM] -------------- Relative paths -------------- Nathan Bullock suggested a ''relpath(path_a, path_b)'' addition to os.paththat returns a relative path from path_a to path_b. Trent Mick pointed out that there are a `couple of`_ `recipes for this`_, as well as `Jason Orendorff's Path module`_. Several people supported this idea, and hopefully either Nathan or one of the recipe authors will submit a patch with this functionality. .. _couple of: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/302594 .. _recipes for this: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/208993 .. _Jason Orendorff's Path module: http://www.jorendorff.com/articles/python/path/ Contributing threads: - `os.path.diff(path1, path2) < http://mail.python.org/pipermail/python-dev/2005-September/056391.html>`__ - `os.path.diff(path1, path2) (and a first post) < http://mail.python.org/pipermail/python-dev/2005-September/056703.html>`__ [TAM] ---------------------------------- Adding a vendor-packages directory ---------------------------------- Rich Burridge followed up a `comp.lang.python thread`_ about a "vendor-packages" directory for Python by submitting a `patch`_ and asking for comments about the proposal on python-dev. General consensus was that the proposal needed a better rationale, explaining why this improved on simply adding a .pth file to the site-packages directory. Rich explained that the rationale is that Python files supplied by the vendor (Sun, Apple, RedHat, Microsoft) with their operating system software should go in a separate base directory to differentiate them from Python files installed specifically at the site. However, Bob Ippolito pointed out that, as of OS X 10.4 ("Tiger") Apple already does this via a .pth file (" Extras.pth"), which points to ''/System/Library/Frameworks/Python.framework/Versions/2.3/Extras/lib/python'' and includes wxPython by default. Bob also pointed out that such a "vendor-packages.pth" should look like ''import site; site.addsitedir('/usr/lib/python2.4/vendor-packages')'' so that packages like Numeric, PIL, and PyObjC, which take advantage of .pth files themselves, work when installed to the vendor-packages location. Phillip J. Eby pointed out that it would be good to have a document for "Python Distributors" that explained these kind of things, and suggested that perhaps a volunteer or two could be found within the distutils-SIG to do this. .. _comp.lang.python thread: http://mail.python.org/pipermail/python-list/2005-September/300029.html .. _patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1298835&group_id=5470&atid=305470 Contributing thread: - `vendor-packages directory < http://mail.python.org/pipermail/python-dev/2005-September/056682.html>`__ [TAM] ======================= Version numbers on OS X ======================= Guido asked if platform.system_alias() could be improved on OS X by mapping uname()'s ''Darwin x.y'' to ''OS X 10.(x-4).y''. Bob Ippolito and others pointed out that this was not a good idea, because uname() only reports on the kernel version number and not the Cocoa API, which is really what OS X 10.x.y refers to. He pointed out that the correct way to do it using a public API is to used gestalt, which is what platform.mac_ver() does. On further inspection, it was discovered that parsing the /System/Library/CoreServices/SystemVersion.plist property list is also a supported API, and would not rely on access to the Carbon API set. Bob and Wilfredo S?nchez Vega provided sample code that would parse this plist; Marc-Andre Lemburg suggested that a patch be written for system_alias() that would use this method (if possible) for Mac OS. Contributing thread: - `Mapping Darwin 8.2.0 to Mac OS X 10.4.2 in platform.py < http://mail.python.org/pipermail/python-dev/2005-September/056651.html>`__ [TAM] ================ Deferred Threads ================ - `Python 2.5a1, ast-branch and PEP 342 and 343 < http://mail.python.org/pipermail/python-dev/2005-September/056449.html>`__ =============== Skipped Threads =============== - `Visibility scope for "for/while/if" statements < http://mail.python.org/pipermail/python-dev/2005-September/056669.html>`__ - `inplace operators and __setitem__ < http://mail.python.org/pipermail/python-dev/2005-September/056766.html>`__ - `Repository for python developers < http://mail.python.org/pipermail/python-dev/2005-September/056717.html>`__ - `For/while/if statements/comprehension/generator expressions unification < http://mail.python.org/pipermail/python-dev/2005-September/056508.html>`__ - `list splicing < http://mail.python.org/pipermail/python-dev/2005-September/056472.html>`__ - `Compatibility between Python 2.3.x and Python 2.4.x < http://mail.python.org/pipermail/python-dev/2005-September/056437.html>`__ - `python optimization < http://mail.python.org/pipermail/python-dev/2005-September/056441.html>`__ - `test__locale on Mac OS X < http://mail.python.org/pipermail/python-dev/2005-September/056463.html>`__ - `possible memory leak on windows (valgrind report) < http://mail.python.org/pipermail/python-dev/2005-September/056478.html>`__ - `Mixins. < http://mail.python.org/pipermail/python-dev/2005-September/056481.html>`__ - `2.4.2c1 fails test_unicode on HP-UX ia64 < http://mail.python.org/pipermail/python-dev/2005-September/056551.html>`__ - `2.4.2c1: test_macfs failing on Tiger (Mac OS X 10.4.2) < http://mail.python.org/pipermail/python-dev/2005-September/056558.html>`__ - `test_ossaudiodev hangs < http://mail.python.org/pipermail/python-dev/2005-September/056559.html>`__ - `unintentional and unsafe use of realpath() < http://mail.python.org/pipermail/python-dev/2005-September/056616.html>`__ - `Alternative name for str.partition() < http://mail.python.org/pipermail/python-dev/2005-September/056630.html>`__ - `Weekly Python Patch/Bug Summary < http://mail.python.org/pipermail/python-dev/2005-September/056713.html>`__ - `Possible bug in urllib.urljoin < http://mail.python.org/pipermail/python-dev/2005-September/056736.html>`__ - `Trasvesal thought on syntax features < http://mail.python.org/pipermail/python-dev/2005-September/056741.html>`__ - `Fixing pty.spawn() < http://mail.python.org/pipermail/python-dev/2005-September/056750.html>`__ - `64-bit bytecode compatibility (was Re: [PEAK] ez_setup on 64-bit linux problem) < http://mail.python.org/pipermail/python-dev/2005-September/056811.html>`__ - `C API doc fix < http://mail.python.org/pipermail/python-dev/2005-September/056827.html>`__ - `David Mertz on CA state e-voting panel < http://mail.python.org/pipermail/python-dev/2005-September/056840.html>`__ - `[PATCH][BUG] Segmentation Fault in xml.dom.minidom.parse < http://mail.python.org/pipermail/python-dev/2005-September/056844.html>`__ - `linecache problem < http://mail.python.org/pipermail/python-dev/2005-September/056856.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from September 16, 2005 through September 30, 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 4th summary written by the python-dev summary duo of Steve Bethard and Tony Meyer (I feel like the White Rabbit in Wonderland...). 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 penny helps 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 at 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://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/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-08-01_2005-08-15.html .. _original text file: http://www.python.org/dev/summary/2005-09-16_2005-09-30.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-announce-list/attachments/20051121/0048c1e7/attachment.html From tony.meyer at gmail.com Mon Nov 21 06:17:38 2005 From: tony.meyer at gmail.com (Tony Meyer) Date: Mon, 21 Nov 2005 18:17:38 +1300 Subject: python-dev Summary for 2005-10-01 through 2005-10-15 Message-ID: <6c63de570511202117o75ce3b66l148945ad29e0ee82@mail.gmail.com> Title: python-dev Summary for 2005-10-01 through 2005-10-15 Content-type: text/x-rst Encoding: utf-8 python-dev Summary for 2005-10-01 through 2005-10-15 ++++++++++++++++++++++++++++++++++++++++++++++++++++ .. contents:: [The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-10-01_2005-10-15.html] ============= Announcements ============= ---------------------------- QOTF: Quote of the Fortnight ---------------------------- >From Phillip J. Eby: So, if threads are "easy" in Python compared to other langauges, it's *because of* the GIL, not in spite of it. Contributing thread: - `Pythonic concurrency < http://mail.python.org/pipermail/python-dev/2005-October/057062.html>`__ [SJB] ---------------------------------------- GCC/G++ Issues on Linux: Patch available ---------------------------------------- Christoph Ludwig provided the previously `promised patch`_ to address some of the issues in compiling Python with GCC/G++ on Linux. The patch_ keeps ELF systems like x86 / Linux from having any dependencies on the C++ runtime, and allows systems that require main() to be a C++ function to be configured appropriately. .. _promised patch: http://www.python.org/dev/summary/2005-07-01_2005-07-15.html#gcc-g-issues-on-linux .. _patch: http://python.org/sf/1324762 Contributing thread: - `[C++-sig] GCC version compatibility < http://mail.python.org/pipermail/python-dev/2005-October/057230.html>`__ [SJB] ========= Summaries ========= --------------------- Concurrency in Python --------------------- Michael Sparks spent a bit of time descibing the current state and future goals of the Kamaelia_ project. Mainly, Kamaelia aims to make concurrency as simple and easy to use as possible. A scheduler manages a set of generators that communicate with each other through Queues. The long term goals include being able to farm the various generators off into thread or processes as needed, so that whether your concurrency model is cooperative, threaded or process-based, your code can basically look the same. There was also continued discussion about how "easy" threads are. Shane Hathaway made the point that it's actually locking that's "insanely difficult", and approaches that simplify how much you need to think about locking can keep threading relatively easy -- this was one of the strong points of ZODB. A fairly large camp also got behind the claim that threads are easy if you're limited to only message passing. There were also a few comments about how Python makes threading easier, e.g. through the GIL (see `QOTF: Quote of the Fortnight`_) and through threading.threads's encapsulation of thread-local resources as instance attributes. .. _Kamaelia: http://kamaelia.sourceforge.ne Contributing threads: - `Pythonic concurrency - cooperative MT < http://mail.python.org/pipermail/python-dev/2005-October/056898.html>`__ - `Pythonic concurrency < http://mail.python.org/pipermail/python-dev/2005-October/057023.html>`__ [SJB] ------------------------------------- Organization of modules for threading ------------------------------------- A few people took issue with the current organization of the threading modules into Queue, thread and threading. Guido views Queue as an application of threading, so putting it in the threading module is inappropriate (though with a deeper package structure, it should definitely be a sibling). Nick Coghlan suggested that Queue should be in a threadtools module (in parallel with itertools), while Skip proposed a hierarchy of modules with thread and lock being in the lowest level one, and Thread and Queue being in the highest level. Aahz suggested (and Guido approved) deprecating the thread module and renaming it to _thread at least in Python 3.0. It seems the deprecation may happen sooner though. Contributing threads: - `Making Queue.Queue easier to use < http://mail.python.org/pipermail/python-dev/2005-October/057184.html>`__ - `Autoloading? (Making Queue.Queue easier to use) < http://mail.python.org/pipermail/python-dev/2005-October/057216.html>`__ - `threadtools (was Re: Autoloading? (Making Queue.Queue easier to use)) < http://mail.python.org/pipermail/python-dev/2005-October/057262.html>`__ - `Threading and synchronization primitives < http://mail.python.org/pipermail/python-dev/2005-October/057269.html>`__ [SJB] ------------------------- Speed of Unicode decoding ------------------------- Tony Nelson found that decoding with a codec like mac-roman or iso8859-1 can take around ten times as long as decoding with utf-8. Walter D?rwald provided a patch_ that implements the mapping using a unicode string of length 256 where undefined characters are mapped to u"\ufffd". This dropped the decode time for mac-roman to nearly the speed of the utf-8 decoding. Hye-Shik Chang showed off a fastmap decoder with comparable performance. In the end, Walter's patch was accepted. .. patch: http://www.python.org/sf/1313939 Contributing thread: - `Unicode charmap decoders slow < http://mail.python.org/pipermail/python-dev/2005-October/056958.html>`__ [SJB] ------------------ Updates to PEP 343 ------------------ Jason Orendorff proposed replacing the __enter__() and __exit__() methods on context managers with a simple __with__() method instead. While Guido was unconvinced that __enter__() and __exit__() should be dropped, he was convinced that context managers should have a __with__() method in parallel with the __iter__() method for iterators. There was some talk of special-casing the @contextmanager decorator on the __with__() method, but no conclusion. Contributing threads: - `Proposed changes to PEP 343 < http://mail.python.org/pipermail/python-dev/2005-October/057040.html>`__ - `PEP 343 and __with__ < http://mail.python.org/pipermail/python-dev/2005-October/056931.html>`__ [SJB] ---------------------- str and unicode issues ---------------------- Martin Blais wanted to completely disable the implicit conversions between unicode and str, so that you would always be forced to call either .encode() or .decode() to convert between one and the other. This is already available through adding ``sys.setdefaultencoding('undefined')`` to your sitecustomize.py file, but the suggestion started another long discussion over unicode issues. Antoine Pitrou suggested that a good rule of thumb is to convert to unicode everything that is semantically textual, and to only use str for what is to be semantically treated as a string of bytes. Fredrik Lundh argued against this for efficiency reasons -- pure ASCII text would consume more space as a unicode object. There were suggestions that in Python 3.0, opening files in text mode will require an encoding and produce string objects, while opening files in binary mode will produce bytes objects. The bytes() type will be a mutable array of bytes, which can be converted to a string object by specifying an encoding. Contributing threads: - `Divorcing str and unicode (no more implicit conversions). < http://mail.python.org/pipermail/python-dev/2005-October/056916.html>`__ - `unifying str and unicode < http://mail.python.org/pipermail/python-dev/2005-October/056934.html>`__ - `bytes type < http://mail.python.org/pipermail/python-dev/2005-October/056945.html>`__ [SJB] ---------------------------------------------------------------------- Allowing \*args syntax in tuple unpacking and before keyword arguments ---------------------------------------------------------------------- Gustavo Niemeyer propsed the oft-seen request for allowing the \*args syntax in tuple unpacking, e.g.:: for first, second, *rest in iterator: Guido requested a PEP, saying that he wasn't convinced that there was much of a gain over the already valid:: for item in iterator: (first, second), rest = item[2:], item[:2] Greg Ewing and others didn't like Guido's suggestion as it violates DRY (Don't Repeat Yourself). Others also chimed in with some examples in support of the proposal, but no one has yet put together a PEP. In a related matter, Guido indicated that he wants to be able to write keyword-only arguments after a \*args, so that you could, for example, write:: f(a, b, *args, foo=1, bar=2, **kwds) People seemed almost unanimously in support of this proposal, but, to quote Nick Coghlan, it has still "never bugged anyone enough for them to actaully get around to fixing it". Contributing thread: - `Extending tuple unpacking < http://mail.python.org/pipermail/python-dev/2005-October/057056.html>`__ [SJB] ---------- AST Branch ---------- Guido gave the AST branch a three week ultimatum: either the branch should be merged into MAIN within the next three weeks, or the branch should be abandoned entirely. This jump-started work on the branch, and the team was hoping to merge the changes the weekend of October 15th. Contributing threads: - `Python 2.5a1, ast-branch and PEP 342 and 343 < http://mail.python.org/pipermail/python-dev/2005-September/056449.html>`__ - `Python 2.5 and ast-branch < http://mail.python.org/pipermail/python-dev/2005-October/056986.html>`__ - `AST branch update < http://mail.python.org/pipermail/python-dev/2005-October/057281.html>`__ [SJB] ----------------------------------- Allowing "return obj" in generators ----------------------------------- Piet Delport suggested having ``return obj`` in generators be translated into ``raise StopIteration(obj)``. The return value of a generator function would thus be available as the first arg in the StopIteration exception. Guido asked for some examples to give the idea a better motivation, and felt uncomfortable with the return value being silently ignored in for-loops. The idea was postponed until at least one release after a PEP 342 implementation enters Python, so that people can have some more experience with coroutines. Contributing threads: - `Proposal for 2.5: Returning values from PEP 342 enhanced generators < http://mail.python.org/pipermail/python-dev/2005-October/056957.html>`__ - `PEP 342 suggestion: start(), __call__() and unwind_call() methods < http://mail.python.org/pipermail/python-dev/2005-October/057042.html>`__ - `New PEP 342 suggestion: result() and allow "return with arguments" in generators (was Re: PEP 342 suggestion: start(), __call__() and unwind_call() methods) < http://mail.python.org/pipermail/python-dev/2005-October/057116.html>`__ [SJB] ----------------------------- API for the line-number table ----------------------------- Greg Ewing suggested trying to simplify the line-number table (lnotab) by simply matching each byte-code index with a file and line number. Phillip J. Eby pointed out that this would make the stdlib take up an extra megabyte, suggesting two tables instead, one matching bytecodes to line numbers, and one matching the first line-number of a chunk with its file. Michael Hudson suggested that what we really want is an API for accessing the lnotab, so that the implementation that is chosen is less important. The conversation trailed off without a resolution. Contributing thread: - `Simplify lnotab? (AST branch update) < http://mail.python.org/pipermail/python-dev/2005-October/057285.html>`__ [SJB] ------------------------------ Current directory and sys.path ------------------------------ A question about the status of `the CurrentVersion registry entry`_ led to a discussion about the different behaviors of sys.path across platforms. Apparently, on Windows, sys.path includes the current directory and the directory of the script being executed, while on Linux, it only includes the directory of the script. .. _the CurrentVersion registry entry: http://www.python.org/windows/python/registry.html Contributing thread: - `PythonCore\CurrentVersion < http://mail.python.org/pipermail/python-dev/2005-October/057095.html>`__ [SJB] ---------------------------------- Changing the __class__ of builtins ---------------------------------- As of Python 2.3, you can no longer change the __class__ of any builtin. Phillip J. Eby suggested that these rules might be overly strict; modules and other mutable objects could probably reasonably have their __class__s changed. No one seemed really opposed to the idea, but no one offered up a patch to make the change either. Contributing thread: - `Assignment to __class__ of module? (Autoloading? (Making Queue.Queueeasier to use)) < http://mail.python.org/pipermail/python-dev/2005-October/057253.html>`__ [SJB] ------------------------------------------ exec function specification for Python 3.0 ------------------------------------------ In Python 3.0, exec is slated to become a function (instead of a statement). Currently, the presence of an exec statement in a function can cause some subtle changes since Python has to worry about exec modifying function locals. Guido suggested that the exec() function could require a namespace, basically dumping the exec-in-local-namespace altogether. People seemed generally in favor of the proposal, though no official specification was established. Contributing thread: - `PEP 3000 and exec < http://mail.python.org/pipermail/python-dev/2005-October/057135.html>`__ [SJB] ------------------------------------ Adding opcodes to speed up self.attr ------------------------------------ Phillip J. Eby experimented with adding LOAD_SELF and SELF_ATTR opcodes to improve the speed of object-oriented programming. This gained about a 5% improvement in pystone, which isn't organized in a very OO manner. People seemed uncertain as to whether paying the cost of adding two opcodes to gain a 5% speedup was worth it. No decision had been made at the time of this summary. Contributing thread: - `LOAD_SELF and SELF_ATTR opcodes < http://mail.python.org/pipermail/python-dev/2005-October/057321.html>`__ [SJB] -------------------------------------- Dropping support for --disable-unicode -------------------------------------- Reinhold Birkenfeld tried unsuccessfully to make the test-suite pass with --disable-unicode set. M.-A. Lemburg suggested that the feature should be ripped out entirely, to simplify the code. Martin v. L?wis suggested deprecating it to give people a chance to object. The plan is now to add a note to the configure switch that the feature will be removed in Python 2.6. Contributing threads: - `Tests and unicode < http://mail.python.org/pipermail/python-dev/2005-October/056897.html>`__ - `--disable-unicode (Tests and unicode) < http://mail.python.org/pipermail/python-dev/2005-October/056920.html>`__ [SJB] ----------------------------------------- Bug in __getitem__ inheritance at C level ----------------------------------------- Travis Oliphant discovered that the addition of the mp_item and sq_item descriptors and the resolution of any comptetion for __getitem__ calls is done *before* the inheritance of any slots takes place. This means that if you create a type in C that supports the sequence protocol, and tries to inherit the mapping protocol from a parent C type which does not support the sequence protocol, __getitem__ will point to the parent type's __getitem__ instead of the child type's __getitem__. This seemed like more of a bug than a feature, so the behavior may be changed in future Pythons. Contributing thread: - `Why does __getitem__ slot of builtin call sequence methods first? < http://mail.python.org/pipermail/python-dev/2005-October/056901.html>`__ [SJB] ================ Deferred Threads ================ - `Early PEP draft (For Python 3000?) < http://mail.python.org/pipermail/python-dev/2005-October/057251.html>`__ - `Pythonic concurrency - offtopic < http://mail.python.org/pipermail/python-dev/2005-October/057294.html>`__ =============== Skipped Threads =============== - `PEP 350: Codetags < http://mail.python.org/pipermail/python-dev/2005-October/056894.html>`__ - `Active Objects in Python < http://mail.python.org/pipermail/python-dev/2005-October/056896.html>`__ - `IDLE development < http://mail.python.org/pipermail/python-dev/2005-October/056907.html>`__ - `Help needed with MSI permissions < http://mail.python.org/pipermail/python-dev/2005-October/056908.html>`__ - `C API doc fix < http://mail.python.org/pipermail/python-dev/2005-October/056910.html>`__ - `Static builds on Windows (continued) < http://mail.python.org/pipermail/python-dev/2005-October/056976.html>`__ - `Removing the block stack (was Re: PEP 343 and __with__) < http://mail.python.org/pipermail/python-dev/2005-October/057001.html>`__ - `Removing the block stack < http://mail.python.org/pipermail/python-dev/2005-October/057008.html>`__ - `Lexical analysis and NEWLINE tokens < http://mail.python.org/pipermail/python-dev/2005-October/057014.html>`__ - `PyObject_Init documentation < http://mail.python.org/pipermail/python-dev/2005-October/057039.html>`__ - `Sourceforge CVS access < http://mail.python.org/pipermail/python-dev/2005-October/057051.html>`__ - `__doc__ behavior in class definitions < http://mail.python.org/pipermail/python-dev/2005-October/057066.html>`__ - `Sandboxed Threads in Python < http://mail.python.org/pipermail/python-dev/2005-October/057082.html>`__ - `Weekly Python Patch/Bug Summary < http://mail.python.org/pipermail/python-dev/2005-October/057092.html>`__ - `test_cmd_line failure on Kubuntu 5.10 with GCC 4.0 < http://mail.python.org/pipermail/python-dev/2005-October/057094.html>`__ - `defaultproperty (was: Re: RFC: readproperty) < http://mail.python.org/pipermail/python-dev/2005-October/057120.html>`__ - `async IO and helper threads < http://mail.python.org/pipermail/python-dev/2005-October/057121.html>`__ - `defaultproperty < http://mail.python.org/pipermail/python-dev/2005-October/057129.html>`__ - `Fwd: defaultproperty < http://mail.python.org/pipermail/python-dev/2005-October/057131.html>`__ - `C.E.R. Thoughts < http://mail.python.org/pipermail/python-dev/2005-October/057137.html>`__ - `problem with genexp < http://mail.python.org/pipermail/python-dev/2005-October/057175.html>`__ - `Python-Dev Digest, Vol 27, Issue 44 < http://mail.python.org/pipermail/python-dev/2005-October/057207.html>`__ - `Europeans attention please! < http://mail.python.org/pipermail/python-dev/2005-October/057233.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from October 01, 2005 through October 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 5th summary written by the python-dev summary taskforce of Steve Bethard and Tony Meyer (thanks Steve!). 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 penny helps 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 at 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://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/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-09-01_2005-09-15.html .. _original text file: http://www.python.org/dev/summary/2005-10-01_2005-10-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-announce-list/attachments/20051121/2f82c513/attachment.htm From tony.meyer at gmail.com Mon Nov 21 06:18:28 2005 From: tony.meyer at gmail.com (Tony Meyer) Date: Mon, 21 Nov 2005 18:18:28 +1300 Subject: python-dev Summary for 2005-10-16 through 2005-10-31 Message-ID: <6c63de570511202118t7747899y9eec468be48d2cac@mail.gmail.com> [The HTML version of this Summary will be available at http://www.python.org/dev/summary/2005-10-16_2005-10-31.html] ============= Announcements ============= -------------- AST for Python -------------- As of October 21st, Python's compiler now uses a real Abstract Syntax Tree (AST)! This should make experimenting with new syntax much easier, as well as allowing some optimizations that were difficult with the previous Concrete Syntax Tree (CST). While there is no Python interface to the AST yet, one is intended for the not-so-distant future. Thanks again to all who contributed, most notably: Armin Rigo, Brett Cannon, Grant Edwards, John Ehresman, Kurt Kaiser, Neal Norwitz, Neil Schemenauer, Nick Coghlan and Tim Peters. Contributing threads: - `AST branch merge status < http://mail.python.org/pipermail/python-dev/2005-October/057347.html>`__ - `AST branch update < http://mail.python.org/pipermail/python-dev/2005-October/057387.html>`__ - `AST branch is in? < http://mail.python.org/pipermail/python-dev/2005-October/057483.html>`__ - `Questionable AST wibbles < http://mail.python.org/pipermail/python-dev/2005-October/057489.html>`__ - `[Jython-dev] Re: AST branch is in? < http://mail.python.org/pipermail/python-dev/2005-October/057642.html>`__ [SJB] -------------------- Python on Subversion -------------------- As of October 27th, Python is now on Subversion! The new repository is http://svn.python.org/projects/. Check the `Developers FAQ`_ for information on how to get yourself setup with Subversion. Thanks again to Martin v. L?wis for making this possible! .. _Developers FAQ: http://www.python.org/dev/devfaq.html#subversion-svn Contributing threads: - `Migrating to subversion < http://mail.python.org/pipermail/python-dev/2005-October/057424.html>`__ - `Freezing the CVS on Oct 26 for SVN switchover < http://mail.python.org/pipermail/python-dev/2005-October/057537.html>`__ - `CVS is read-only < http://mail.python.org/pipermail/python-dev/2005-October/057679.html>`__ - `Conversion to Subversion is complete < http://mail.python.org/pipermail/python-dev/2005-October/057690.html>`__ [SJB] --------------- Faster decoding --------------- M.-A. Lemburg checked in Walter D?rwald's patches that improve decoding speeds by using a character map. These should make decoding into mac-roman or iso8859-1 nearly as fast as decoding into utf-8. Thanks again guys! Contributing threads: - `Unicode charmap decoders slow < http://mail.python.org/pipermail/python-dev/2005-October/057341.html>`__ - `New codecs checked in < http://mail.python.org/pipermail/python-dev/2005-October/057505.html>`__ - `KOI8_U (New codecs checked in) < http://mail.python.org/pipermail/python-dev/2005-October/057576.html>`__ [SJB] ========= Summaries ========= --------------------- Strings in Python 3.0 --------------------- Guido proposed that in Python 3.0, all character strings would be unicode, possibly with multiple internal representations. Some of the issues: - Multiple implementations could make the C API difficult. If utf-8, utf-16 and utf-32 are all possible, what types should the C API pass around? - Windows expects utf-16, so using any other encoding will mean that calls to Windows will have to convert to and from utf-16. However, even in current Python, all strings passed to Windows system calls have to undergo 8 bit to utf-16 conversion. - Surrogates (two code units encoding one code point) can slow indexing down because the number of bytes per character isn't constant. Note that even though utf-32 doesn't need surrogates, they may still be used (and must be interpreted correctly) in utf-32 data. Also, in utf-32, "graphemes" (which correspond better to the traditional concept of a "character" than code points do) may still be composed of multiple code points, e.g. "?" (e with a accent) can be written as "e" + "'". This last issue was particularly vexing -- Guido thinks "it's a bad idea to offer an indexing operation that isn't O(1)". A number of proposals were put forward, including: - Adding a flag to strings to indicate whether or not they have any surrogates in them. This makes indexing O(1) when no surrogates are in a string, but O(N) otherwise. - Using a B-tree instead of an array for storage. This would make all indexing O(log N). - Discouraging using the indexing operations by providing an alternate API for strings. This would require creating iterator-like objects that keep track of position in the unicode object. Coming up with an API that's as usable as the slicing API seemed difficult though. Contributing thread: - `Divorcing str and unicode (no more implicit conversions). < http://mail.python.org/pipermail/python-dev/2005-October/057362.html>`__ [SJB] ------------------- Unicode identifiers ------------------- Martin v. L?wis suggested lifting the restriction that identifiers be ASCII. There was some concern about confusability, with the contention that confusions like "O" (uppercase O) for "0" (zero) and "1" (one) for "l" (lowercase L) would only multiply if larger character sets were allowed. Guido seemed less concerned about this problem than about about how easy it would be to share code across languages. Neil Hodgson pointed out that even though a transliteration into English exists for Japanese, the coders he knew preferred to use relatively meaningless names, and Oren Tirosh indicated that Israeli programmers often preferred transliterations for local business terminology. In either case, with or without unicode identifiers the code would already be hard to share. In the end, people seemed mostly in favor of the idea, though there was some suggestion that it should wait until Python 3.0. Contributing threads: - `Divorcing str and unicode (no more implicit conversions). < http://mail.python.org/pipermail/python-dev/2005-October/057362.html>`__ - `i18n identifiers (was: Divorcing str and unicode (no more implicit conversions). < http://mail.python.org/pipermail/python-dev/2005-October/057812.html>`__ - `i18n identifiers < http://mail.python.org/pipermail/python-dev/2005-October/057813.html>`__ [SJB] ----------------- Property variants ----------------- People still seem not quite pleased with properties, both in the syntax, and in how they interact with inheritance. Guido proposed changing the property() builtin to accept strings for fget, fset and fdel in addition to functions (as it currently does). If strings were passed, the property() object would have late-binding behavior, that is, the function to call wouldn't be looked-up until the attribute was accessed. Properties whose fget, fset and fdel functions can be overridden in subclasses might then look like:: class C(object): foo = property('getFoo', 'setFoo', None, 'the foo property') def getFoo(self): return self._foo def setFoo(self, foo): self._foo = foo There were mixed reactions to this proposal. People liked getting the expected behavior in subclasses, but it does violate DRY (Don't Repeat Yourself). I posted an `alternative solution`_ using metaclasses that would allow you to write properties like:: class C(object): class foo(Property): """The foo property""" def get(self): return self._foo def set(self, foo): self._foo = foo which operates correctly with subclasses and follows DRY, but introduces a confusion about the referrent of "self". There were also a few suggestions of introducing a new syntax for properties (see `Generalizing the class declaration syntax`_) which would have produced things like:: class C(object): Property foo(): """The foo property""" def get(self): return self._foo def set(self, foo): self._foo = foo At the moment at least, it looks like we'll be sticking with the status quo. .. _alternative solution: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442418 Contributing threads: - `Definining properties - a use case for class decorators? < http://mail.python.org/pipermail/python-dev/2005-October/057350.html>`__ - `Defining properties - a use case for class decorators? < http://mail.python.org/pipermail/python-dev/2005-October/057407.html>`__ - `properties and block statement < http://mail.python.org/pipermail/python-dev/2005-October/057419.html>`__ - `Property syntax for Py3k (properties and block statement) < http://mail.python.org/pipermail/python-dev/2005-October/057427.html>`__ [SJB] ------------------- PEP 343 resolutions ------------------- After Guido accepted the idea of adding a __with__() method to the context protocol, `PEP 343`_ was reverted to "Proposed" until the remaining details could be ironed out. The end results were: - The slot name "__context__" will be used instead of "__with__". - The builtin name "context" is currently offlimits due to its ambiguity. - Generator-iterators do NOT have a native context. - The builtin function "contextmanager" will convert a generator-function into a context manager. - The "__context__" slot will NOT be special cased. If it defines a generator, the __context__() function should be decorated with @contextmanager. - When the result of a __context__() call returns an object that lacks an __enter__() or __exit__() method, an AttributeError will be raised. - Only locks, files and decimal.Context objects will gain __context__() methods in Python 2.5. Guido seemed to agree with all of these, but has not yet pronounced on the revised `PEP 343`_. .. _PEP 343: http://www.python.org/peps/pep-0343.html Contributing threads: - `PEP 343 updated < http://mail.python.org/pipermail/python-dev/2005-October/057349.html>`__ - `Proposed resolutions for open PEP 343 issues < http://mail.python.org/pipermail/python-dev/2005-October/057516.html>`__ - `PEP 343 - multiple context managers in one statement < http://mail.python.org/pipermail/python-dev/2005-October/057637.html>`__ - `PEP 343 updated with outcome of recent discussions < http://mail.python.org/pipermail/python-dev/2005-October/057769.html>`__ [SJB] --------------- Freeze protocol --------------- Barry Warsaw propsed `PEP 351`_, which suggests a freeze() builtin which would call the __freeze__() method on an object if that object was not hashable. This would allow dicts to automatically make frozen copies of mutable objects when they were used as dict keys. It could reduce the need for "x" and "frozenx" builtin pairs, since the frozen versions could be automatically derived when needed. Raymond Hettinger indicated some problems with the proposal: - sets.Set supported something similar, but found that it was not really helpful in practice. - Freezing a list into a tuple is not appropriate since they do not have all the same methods. - Errors can arise when the mutable object gets out of sync with its frozen copy. - Manually freezing things when necessary is relatively simple. Noam Raphael proposed a copy-on-change mechanism which would essentially give frozen copies of an object a reference to that object. When the object is about to be modified, a copy would be made, and all frozen copies would be pointed at this. Thus an object that was mutable but never changed could have lightweight frozen copies, while an object that did change would have to pay the usual copying costs. Noam and Josiah Carlson then had a rather heated debate about how feasible such a copy-on-change mechanism would be for Python. .. _PEP 351: http://www.python.org/peps/pep-0351.html Contributing thread: - `PEP 351, the freeze protocol < http://mail.python.org/pipermail/python-dev/2005-October/057543.html>`__ [SJB] ---------------------------------- Required superclass for Exceptions ---------------------------------- Guido and Brett Cannon introduced `PEP 352`_ which proposes that all Exceptions be required to derive from a new exception class, BaseException. The chidren of BaseException would be KeyboardInterrupt, SystemExit and Exception (which would contain the remainder of the current hierarchy). The goal here is to make the following code do the right thing:: try: ... except Exception: ... Currently, this code fails to catch string exceptions and other exceptions that do not derive from Exception, and it (probably) inappropriately catches KeyboardInterrupt and SystemExit which are supposed to indicate that Python is shutting down. The current plan is to introduce BaseException and have KeyboardInterrupt and SystemExit multiply inherit from Exception and BaseException. The PEP lists the roadplan for deprecating the various other types of exceptions. The PEP also attempts to standardize on the arguments to Exception objects, so that by Python 3.0, all Exceptions will support a single argument which will be stored as their "message" attribute. Guido was ready to accept it on October 31st, but it has not been marked as Accepted yet. .. _PEP 352: http://www.python.org/peps/pep-0352.html Contributing threads: - `PEP 352: Required Superclass for Exceptions < http://mail.python.org/pipermail/python-dev/2005-October/057736.html>`__ - `PEP 352 Transition Plan < http://mail.python.org/pipermail/python-dev/2005-October/057750.html>`__ [SJB] ----------------------------------------- Generalizing the class declaration syntax ----------------------------------------- Michele Simionato suggested a generalization of the class declaration syntax, so that:: : would be translated into:: = ("", , ) Where is simply the namespace that results from executing . This would actually remove the need for the class keyword, as classes could be declared as:: type : There were a few requests for a PEP, but nothing has been made available yet. Contributing thread: - `Definining properties - a use case for class decorators? < http://mail.python.org/pipermail/python-dev/2005-October/057435.html>`__ [SJB] -------------------- Task-local variables -------------------- Phillip J. Eby introduced a pre-PEP proposing a mechanism similar to thread-local variables, to help co-routine schedulers to swap state between tasks. Essentially, the scheduler would be required to take a snapshot of a coroutine's variables before a swap, and restore that snapshot when the coroutine is swapped back. Guido asked people to hold off on more PEP 343-related proposals until with-blocks have been out in the wild for at least a release or two. Contributing thread: - `Pre-PEP: Task-local variables < http://mail.python.org/pipermail/python-dev/2005-October/057464.html>`__ [SJB] ----------------------------------------- Attribute-style access for all namespaces ----------------------------------------- Eyal Lotem proposed replacing the globals() and locals() dicts with "module" and "frame" objects that would have attribute-style access instead of __getitem__-style access. Josiah Carlson noted that the first is already available by doing ``module = __import__(__name__)``, and suggested that monkeying around with function locals is never a good idea, so adding additional support for doing so is not useful. Contributing threads: - `Early PEP draft (For Python 3000?) < http://mail.python.org/pipermail/python-dev/2005-October/057251.html>`__ [SJB] --------------------------------- Yielding all items of an iterator --------------------------------- Gustavo J. A. M. Carneiro was looking for a nicer way of indicating that all items of an iterable should be yielded. Currently, you probably want to use a for-loop to express this, e.g.:: for step in animate(win, xrange(10)): # slide down yield step Andrew Koenig suggested that the syntax:: yield from be equivalent to:: for i in x: yield i People seemed uncertain as to whether or not there were enough use cases to merit the additional syntax. Contributing thread: - `Coroutines, generators, function calling < http://mail.python.org/pipermail/python-dev/2005-October/057405.html>`__ [SJB] ----------------------------------------- Getting an AST without the Python runtime ----------------------------------------- Thanks to the merging of the AST branch, Evan Jones was able to fully divorce the Python parse from the Python runtime so that you can get AST objects without having to have Python running. He made the divorced AST parser available on `his site`_. .. _his site: http://evanjones.ca/software/pyparser.html Contributing thread: - `Parser and Runtime: Divorced! < http://mail.python.org/pipermail/python-dev/2005-October/057684.html>`__ [SJB] =============== Skipped Threads =============== - `Pythonic concurrency - offtopic < http://mail.python.org/pipermail/python-dev/2005-October/057294.html>`__ - `Sourceforge CVS access < http://mail.python.org/pipermail/python-dev/2005-October/057342.html>`__ - `Weekly Python Patch/Bug Summary < http://mail.python.org/pipermail/python-dev/2005-October/057343.html>`__ - `Guido v. Python, Round 1 < http://mail.python.org/pipermail/python-dev/2005-October/057366.html>`__ - `Autoloading? (Making Queue.Queue easier to use) < http://mail.python.org/pipermail/python-dev/2005-October/057368.html>`__ - `problem with genexp < http://mail.python.org/pipermail/python-dev/2005-October/057370.html>`__ - `PEP 3000 and exec < http://mail.python.org/pipermail/python-dev/2005-October/057380.html>`__ - `Pythonic concurrency - offtopic < http://mail.python.org/pipermail/python-dev/2005-October/057442.html>`__ - `enumerate with a start index < http://mail.python.org/pipermail/python-dev/2005-October/057459.html>`__ - `list splicing < http://mail.python.org/pipermail/python-dev/2005-October/057479.html>`__ - `bool(iter([])) changed between 2.3 and 2.4 < http://mail.python.org/pipermail/python-dev/2005-October/057481.html>`__ - `A solution to the evils of static typing and interfaces? < http://mail.python.org/pipermail/python-dev/2005-October/057485.html>`__ - `PEP 267 -- is the semantics change OK? < http://mail.python.org/pipermail/python-dev/2005-October/057506.html>`__ - `DRAFT: python-dev Summary for 2005-09-01 through 2005-09-16 < http://mail.python.org/pipermail/python-dev/2005-October/057508.html>`__ - `int(string) (was: DRAFT: python-dev Summary for 2005-09-01 through 2005-09-16) < http://mail.python.org/pipermail/python-dev/2005-October/057510.html>`__ - `LXR site for Python CVS < http://mail.python.org/pipermail/python-dev/2005-October/057511.html>`__ - `int(string) < http://mail.python.org/pipermail/python-dev/2005-October/057512.html>`__ - `Comparing date+time w/ just time < http://mail.python.org/pipermail/python-dev/2005-October/057514.html>`__ - `AST reverts PEP 342 implementation and IDLE starts working again < http://mail.python.org/pipermail/python-dev/2005-October/057528.html>`__ - `cross compiling python for embedded systems < http://mail.python.org/pipermail/python-dev/2005-October/057534.html>`__ - `Inconsistent Use of Buffer Interface in stringobject.c < http://mail.python.org/pipermail/python-dev/2005-October/057589.html>`__ - `Reminder: PyCon 2006 submissions due in a week < http://mail.python.org/pipermail/python-dev/2005-October/057618.html>`__ - `MinGW and libpython24.a < http://mail.python.org/pipermail/python-dev/2005-October/057624.html>`__ - `make testall hanging on HEAD? < http://mail.python.org/pipermail/python-dev/2005-October/057662.html>`__ - `"? operator in python" < http://mail.python.org/pipermail/python-dev/2005-October/057673.html>`__ - `[Docs] MinGW and libpython24.a < http://mail.python.org/pipermail/python-dev/2005-October/057693.html>`__ - `Help with inotify < http://mail.python.org/pipermail/python-dev/2005-October/057705.html>`__ - `[Python-checkins] commit of r41352 - in python/trunk: . Lib Lib/distutils Lib/distutils/command Lib/encodings < http://mail.python.org/pipermail/python-dev/2005-October/057780.html>`__ - `svn:ignore < http://mail.python.org/pipermail/python-dev/2005-October/057783.html>`__ - `svn checksum error < http://mail.python.org/pipermail/python-dev/2005-October/057790.html>`__ - `svn:ignore (Was: [Python-checkins] commit of r41352 - in python/trunk: . Lib Lib/distutils Lib/distutils/command Lib/encodings) < http://mail.python.org/pipermail/python-dev/2005-October/057793.html>`__ - `StreamHandler eating exceptions < http://mail.python.org/pipermail/python-dev/2005-October/057798.html>`__ - `a different kind of reduce... < http://mail.python.org/pipermail/python-dev/2005-October/057814.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from October 16, 2005 through October 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 6th summary written by the python-dev summary dyad of Steve Bethard and Tony Meyer (more thanks!). 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 penny helps 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 at 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://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/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-09-16_2005-09-30.html .. _original text file: http://www.python.org/dev/summary/2005-10-16_2005-10-31.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-announce-list/attachments/20051121/bfa954da/attachment.html From aronovitch at gmail.com Mon Nov 21 12:41:31 2005 From: aronovitch at gmail.com (Amit Aronovitch) Date: Mon, 21 Nov 2005 13:41:31 +0200 Subject: OSDC::Israel Conference 26-28 Feb. 2006 Message-ID: <4381B26B.3080902@gmail.com> ====================================== Open Source Developers' Conference, 26-28 February, 2006, Netanya, Israel ====================================== Announcement and Call for Papers http://www.osdc.org.il/call_for_paper.html About ------ The Open Source Developers' Conferences (OSDCs) are grassroots symposia originating from Australia. The conference tries to bring together the users of various OS technologies such as Perl, Python, Ruby, Tcl, PHP, MySQL, PostgreSQL, Subversion and more. The Israeli OSDC is organized by the Israeli Perl Mongers and the Israeli Python user group. Our aim is to bring together practitioners, scholars, students, programmers, researchers and managers from different areas to discuss their views on various aspects of the Open Source technologies, to share knowledge and to have fun while doing so. Structure ---------- The conference will last for 3 days with 3 parallel tracks of presentations. Presentations will be given in either Hebrew or English, depending on the speaker's preference (the language will be listed in advance). Call for Papers ---------------- Recommended Topics for Python Related Presentations: * Python based web & content-management technology (e.g. Zope) * Major or Interesting packages (e.g. Twisted) * Language development and new implementations (e.g. PyPy) * Interfacing other languages (e.g. boost-python) The examples given above are suitable for long presentations or tutorials, but we also accept 40 and 20 minutes presentations, and 5 minute lightning talks. Any other topics which are interesting and relevant to Open Source Developers are also welcome. For submitting proposals: http://www.osdc.org.il/proposal.html For updates and more details: http://www.osdc.org.il/index.html From kgmuller at xs4all.nl Mon Nov 21 16:27:40 2005 From: kgmuller at xs4all.nl (Klaus Muller) Date: Mon, 21 Nov 2005 16:27:40 +0100 Subject: ANN: Release of simulation package SimPy 1.6.1 Message-ID: <200511211527.jALFRfnU035647@smtp-vbr11.xs4all.nl> It is our pleasure to announce the release of version 1.6.1 of the SimPy discrete event simulation package. Download from http://simpy.sourceforge.net/ . What is SimPy? ============== SimPy (= Simulation in Python) is an object-oriented, process-based discrete-event simulation language based on standard Python. It is released under the GNU Lesser GPL (LGPL). SimPy provides the modeler with components of a simulation model including processes, for active components like customers, messages, and vehicles, and resources, for passive components that form limited capacity congestion points like servers, checkout counters, and tunnels. It also provides monitor variables to aid in gathering statistics. Random variates are provided by the standard Python random module. SimPy is in use at many universities, research institutes and in industry. What is new? ============ - Addition of Tally data collection class as an alternative to Monitor. It is intended for collecting very large data sets (50000 observations or more) more efficiently in storage space and time than Monitor. - Addition of function setHistogram to class Monitor for initializing histograms. - Addition of function allEventTimes (returns event times of all scheduled events). - Change of Resource to work with Tally (new Resource API is backwards-compatible with 1.6). - Revised function allEventNotices() for debugging/teaching purposes. It returns a pretty-printed string with event times and names of process instances. Nature/purpose of this release? =============================== SimPy 1.6.1 is a minor sub-release of version 1.6. It does not add any new simulation constructs, but just provides support to efficient simulation data collection of large numbers of observations. Enjoy, and don't forget to give us you feedback! Klaus M?ller Tony Vignaux -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3936 bytes Desc: not available Url : http://mail.python.org/pipermail/python-announce-list/attachments/20051121/74dc66f4/smime.bin From limodou at gmail.com Tue Nov 22 02:57:39 2005 From: limodou at gmail.com (limodou) Date: Tue, 22 Nov 2005 09:57:39 +0800 Subject: ANN:NewEdit 3.1 released Message-ID: <505f13c0511211757k56ed74cfq@mail.gmail.com> What's it? ======== It's an Editor based on wxPython. NewEdit uses Mixin and Plugin technique as its architecture. Most of its classes can be extended via mixin and plugin components, and finally become an integrity class at creating the instance. So NewEdit is very dynamic. You can write the new features in new files, and hardly need to modify the existing code. And if you want to extend the existing classes, you could write mixins and plugins, and this will be bound to the target class that I call "Slot Class". This technique will make the changes centralized and easily managed. What are its features? ================ * Cross platform o based on wxPython, so it can run anywhere that wxPython works, such as: Windows, Linux. o Unicode support. * Most features of wxStyledTextCtrl(Scintilla) o Syntax highlighting, support Python, c/c++, html, plain text, perl, ruby, css, javascript o Folding o Brace Matching o ... * Extended selection o Extended word selection -- You can press Ctrl+?MouseDoubleClick to select a word including '.' o Matched selection -- Select text in quoted chars like: (), [], {}, '', "". * Other editing extension o Duplicating text -- Just like Vim Ctrl+V, Ctrl+P, and more. You can duplicate above or below char, word, line o Quoting text -- Add some quoted chars before and after selected text, just as: "", '', (), [], {}, and o Text convertion and view -- python -> html, reStructured Text -> html, textile -> html, and you can output or view o Utf-8 encoding auto detect o Changing document encoding o Auto backup o Last session support -- It'll save all the filenames as closed, and reopen the files as next started. o Smart judge the indent char -- It'll auto guess the indent char, and sets it. o Finding in files o Bookmark support * Python support o built-in python interactive window based on ?PyShell, support Unicode o Auto completion o Function syntax calltips o Run, run with argument, stop python source o Auto change current path o Python class browser * Code snippets o You can manage your code snippets with categories, and each category can have many items. Every item will represent a code snippet. You can insert an item just by double-clicking on it. It even supports importing and exporting. * Simple project support o Can create a special file _project, so every file and folder under the folder which has the _project can be considered as a whole project. * Extension mechanism o Script -- You can write easy script to manipulate the all resource of NewEdit, just like: text conversion, etc. o Plugin -- Customized function. More complex but more powerful. Can easily merge with NewEdit, and can be managed via menu. o Shell command -- Add often used shell commands, and execute them. * Ftp support o You can edit remote files through ftp. You can add, rename, delete, upload, download file/directory. * Multilanguage support o Currently supports two languages: English and Chinese, which can be auto-detected. * Shipped plugins(must be configed as used them before) o Document links -- Python documentation and wxPython documentation. o Many plugins can be found at NewEdit wiki page. * Shipped scripts o Many scripts can be found at NewEdit wiki page. * Wizard (New) o You can make your own wizard template. The wizard can input user data, combine with template, and output the result. And wizard also support code framework created. This feature will help you improving coding efficiency. * Direcotry Browser(New) o Browse multiple directories, and you can really add, delete, rename directories and files. Double click will open the file in Editor window. * AutoComPlete(acp)(New) o Suport user autocomplete file, it can help to input code very helpful and functional. Just like EditPlus, but may be more powerful. Where to download it? ================ download lastest version 3.1: http://wiki.woodpecker.org.cn/moin/NewEdit?action=AttachFile&do=get&target=newedit_3.1.zip also have windows installer: http://wiki.woodpecker.org.cn/moin/NewEdit?action=AttachFile&do=get&target=NewEdit3.1.exe wiki: http://wiki.woodpecker.org.cn/moin/NewEdit svn: http://cvs.woodpecker.org.cn/svn/woodpecker/newedit maillist: http://groups.google.com/group/NewEdit If you have any problem as using NewEdit, welcome to join the NewEdit maillist to discuss. Hope fun! -- I like python! My Blog: http://www.donews.net/limodou NewEdit Maillist: http://groups.google.com/group/NewEdit From quentel.pierre at wanadoo.fr Mon Nov 21 22:13:09 2005 From: quentel.pierre at wanadoo.fr (Pierre Quentel) Date: Mon, 21 Nov 2005 22:13:09 +0100 Subject: ANN: Karrigell-2.2 final released In-Reply-To: References: Message-ID: <43823864$0$6681$8fcfb975@news.wanadoo.fr> The definitive 2.2 version of Karrigell, a Python web framework, has been released at http://karrigell.sourceforge.net The main changes in this version are the support of Virtual Hosts and the inclusion of the Cheetah templating system This final release fixes 2 bugs, one in the asynchronous HTTP server which would use 100% of the CPU in some cases, and another one in the protected directory management Best regards, Pierre From topdev at free.fr Tue Nov 22 10:02:30 2005 From: topdev at free.fr (Chrys) Date: 22 Nov 2005 01:02:30 -0800 Subject: a contest open to various programming languages (including Python) Message-ID: <1132650150.805157.150600@z14g2000cwz.googlegroups.com> The second edition of the programming contest TopDev2006 will take place on January 28th-29th 2006. This contest is original by its independance from any languages. The winners will not be the fastest programmer, but the ones who will propose the greatest technical solution with the most complete documentation.("it's not a speed contest, upon an arithmetical problem"). Anyone can contest TopDev (students or professionals, alone or in pair,...). More than thousand of participants are expected for this world-wide contest. A realistic and detailed business case is to be realized using any language (Java, PHP, C#, ASP.Net, Python,...or an UML model) within only 60 hours, from home. Subscription and more informations : http://www.TopDevOne.com From t.koutsovassilis at gmail.com Wed Nov 23 03:50:16 2005 From: t.koutsovassilis at gmail.com (t.koutsovassilis@gmail.com) Date: 22 Nov 2005 18:50:16 -0800 Subject: ANN: Porcupine Web Application Server 0.0.4 released Message-ID: <1132714216.819240.243740@g49g2000cwa.googlegroups.com> QuiX now supports radio buttons and timers (timeouts and intervals). This release also introduces a couple of useful desktop enhancements. The task bar context menu allows the user to minimize all windows or activate the desired window at once. Each user is also capable of choosing the task bar position (top or bottom). The object query language (POQL) is enriched by adding a new function named "instanceof". This function returns "true" if an object is a subclass of a given type. Finally a new dictionary data type is added to the list of the primary data types and the user content class has a new attribute used for keeping his/her preferences. One step closer to our vision; the WebOS. Resources ========= What is Porcupine? http://www.innoscript.org/content/view/30/42/ Porcupine online demo: http://www.innoscript.org/content/view/21/43/ Porcupine tutorials: http://wiki.innoscript.org/index.php/Developers/Tutorials Developer resources: http://www.innoscript.org/component/option,com_remository/Itemid,33/func,selectcat/cat,3/ From faltet at carabos.com Wed Nov 23 12:39:21 2005 From: faltet at carabos.com (Francesc Altet) Date: Wed, 23 Nov 2005 12:39:21 +0100 Subject: ANN: PyTables 1.2 Message-ID: <200511231239.21489.faltet@carabos.com> PyTables is a library to deal with very large datasets. It leverages the excellent HDF5 and numarray libraries to allow doing that in a very efficient way using the Python language. More info in: http://pytables.sourceforge.net/ ========================= Announcing PyTables 1.2 ========================= The PyTables development team is happy to announce the availability of a new major version of PyTables package. This version sports a completely new in-memory tree implementation based around a *node cache system*. This system loads nodes only when needed and unloads them when they are rarely used. The new feature allows the opening and creation of HDF5 files with large hierarchies very quickly and with a low memory consumption (the object tree is no longer completely loaded in-memory), while retaining all the powerful browsing capabilities of the previous implementation of the object tree. You can read more about the dings and bells of the new cache system in: http://www.carabos.com/downloads/pytables/NewObjectTreeCache.pdf Also, Jeff Whitaker has kindly contributed a new module called tables.NetCDF. It is designed to be used as a drop-in replacement for Scientific.IO.NetCDF, with only minor actions to existing code. Also, if you have the Scientific.IO.NetCDF module installed, it allows to do conversions between HDF5 <--> NetCDF3 formats. Go to the PyTables web site for downloading the beast: http://pytables.sourceforge.net/ If you want more info about this release, please check out the more comprehensive announcement message available in: http://www.carabos.com/downloads/pytables/ANNOUNCE-1.2.html Acknowledgments =============== Thanks to the users who provided feature improvements, patches, bug reports, support and suggestions. See THANKS file in distribution package for a (incomplete) list of contributors. Many thanks also to SourceForge who have helped to make and distribute this package! And last but not least, a big thank you to THG (http://www.hdfgroup.org/) for sponsoring many of the new features recently introduced in PyTables. --- **Enjoy data!** -- The PyTables Team -- >0,0< Francesc Altet ? ? http://www.carabos.com/ V V C?rabos Coop. V. ??Enjoy Data "-" From t.koutsovassilis at gmail.com Wed Nov 23 19:24:53 2005 From: t.koutsovassilis at gmail.com (t.koutsovassilis@gmail.com) Date: 23 Nov 2005 10:24:53 -0800 Subject: ANN: Porcupine Web Application Server 0.0.5 released Message-ID: <1132770293.523480.196840@g14g2000cwa.googlegroups.com> Sorry for posting this again but the new release is the 0.0.5 and not the 0.0.4. QuiX now supports radio buttons and timers (timeouts and intervals). This release also introduces a couple of useful desktop enhancements. The task bar context menu allows the user to minimize all windows or activate the desired window at once. Each user is also capable of choosing the task bar position (top or bottom). The object query language (POQL) is enriched by adding a new function named "instanceof". This function returns "true" if an object is a subclass of a given type. Finally a new dictionary data type is added to the list of the primary data types and the user content class has a new attribute used for keeping his/her preferences. One step closer to our vision; the WebOS. Resources ========= What is Porcupine? http://www.innoscript.org/content/view/30/42/ Porcupine online demo: http://www.innoscript.org/content/view/21/43/ Porcupine tutorials: http://wiki.innoscript.org/index.php/Developers/Tutorials Developer resources: http://www.innoscript.org/component/option,com_remository/Itemid,33/func,selectcat/cat,3/ From sverker.is at home.se Fri Nov 25 09:12:36 2005 From: sverker.is at home.se (sverker.is@home.se) Date: 25 Nov 2005 00:12:36 -0800 Subject: Guppy-PE: A Python Programming Environment Message-ID: <1132906356.489622.116770@g43g2000cwa.googlegroups.com> I would like to announce Guppy-PE 0.1 The first version of Guppy-PE, a programming environment providing object and heap memory sizing and analysis and comes with a prototypical specification language that can be used to formally specify aspects of Python programs and generate tests and documentation from a common source. License: MIT For more information, see: http://guppy-pe.sourceforge.net Best Regards, Sverker Nilsson sverker.is at home.se From python-url at phaseit.net Sat Nov 26 22:40:45 2005 From: python-url at phaseit.net (Cameron Laird) Date: Sat, 26 Nov 2005 21:40:45 +0000 Subject: Dr. Dobb's Python-URL! - weekly Python news and links (Nov 26) Message-ID: QOTW: "... '[B]ut assume that I have some other use case' isn't a valid use case". - Fredrik Lundh "Rolling your own solution, on the other hand, can end in a long road discovering what those CORBA people were doing for all those years." - Paul Boddie NOTW: sceptifications. Steven D'Aprano carefully details a common confusion among newcomers about empty lists and initialization: http://groups.google.com/group/comp.lang.python/browse_thread/thread/8480fae54a64fc15/ Inyeol Lee and others illustrate use of regular expression syntax having to do with repeated patterns: http://groups.google.com/group/comp.lang.python/browse_thread/thread/b5e7abb4ff1e156c/ Metakit 2.4.9.5 corrects a potential disk-full error, and improves performance greatly in certain circumstances: http://www.equi4.com/pub/mk/CHANGES http://www.equi4.com/metakit.html William Peterson jokes that, "[i]f you ask ten people on this newsgroup [about GUI construction newcomers] you'll probably get twelve opinions"--and then the community promptly proves him right: http://groups.google.com/group/comp.lang.python/browse_thread/thread/6fd1ea6b4a2d31f8/ Having arrived in the twenty-first century, clp now has its own (provisional) podcast: http://groups.google.com/group/comp.lang.python/browse_thread/thread/b39581f59dce9191/ David Wahler cogently perverts^H^H^H^H^H^H^H^Hextends pickle to serialize *classes* (as opposed to their instances): http://groups.google.com/group/comp.lang.python/browse_thread/thread/10a03f094303a91c/ Fully-general backward-compatibility has substantial costs, often greater than the version migration it's supposed to spare us. Several of the regulars discuss this seriously: http://groups.google.com/group/comp.lang.python/browse_thread/thread/423d9dfa80456966/ __slots__ are only a (memory) optimization, restricted to well-defined circumstances, explains the martellibot: http://groups.google.com/group/comp.lang.python/browse_thread/thread/1cc68de7af477386/ A good thing about Cheetah is that it cooperates with Python's inheritance: http://groups.google.com/group/comp.lang.python/browse_thread/thread/f063406b648c7d0c/ ======================================================================== 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 at pythonjournal.com and editor at 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.python.* Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ (requires subscription) http://groups-beta.google.com/groups?q=python-url+group:comp.lang.python*&start=0&scoring=d& http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lang.python 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 should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask 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. From tony.meyer at gmail.com Sun Nov 27 06:22:32 2005 From: tony.meyer at gmail.com (Tony Meyer) Date: Sun, 27 Nov 2005 18:22:32 +1300 Subject: python-dev Summary for 2005-11-01 through 2005-11-15 Message-ID: <6c63de570511262122s1c6143fai6f8d726ddc7648cf@mail.gmail.com> [The HTML version of this Summary will be available at http://www.python.org/dev/summary/2005-11-01_2005-11-15.html] ============= Announcements ============= ---------------------------------------- PyPy 0.8.0 and Gothenburg PyPy Sprint II ---------------------------------------- `PyPy 0.8.0`_ has been released. This third release of PyPy includes a translatable parser and AST compiler, some speed enhancements (transated PyPy is now about 10 times faster than 0.7, but still 10-20 times slower than CPython), increased language compliancy, and some experimental features are now translatable. This release also includes snapshots of interesting, but not yet completed, subprojects including the OOtyper (a RTyper variation for higher-level backends), a JavaScript backend, a limited (PPC) assembler backend, and some bits for a socket module. The next PyPy Sprint is also coming up soon. The Gothenborg PyPy Sprint II is on the 7th to 11th of December 2005 in Gothenborg, Sweden. Its focus is heading towards phase 2, which means JIT work, alternate threading modules, and logic programming. Newcomer-friendly introductions will also be given. The main topics that are currently scheduled are the L3 interpreter (a small fast interpreter for "assembler-level" flow graphs), Stackless (e.g. Tasklets or Greenlets), porting C modules from CPython, optimization/debugging work, and logic programming in Python. .. _`PyPy 0.8.0`: http://codespeak.net/pypy/dist/pypy/doc/release-0.8.0.html Contributing threads: - `PyPy 0.8.0 is released! < http://mail.python.org/pipermail/python-dev/2005-November/057878.html>`__ - `Gothenburg PyPy Sprint II: 7th - 11th December 2005 < http://mail.python.org/pipermail/python-dev/2005-November/058143.html>`__ [TAM] ------------------------ PyCon Sprint suggestions ------------------------ Every PyCon has featured a python-dev `sprint`_. For the past few years, hacking on the AST branch has been a tradition, but since the AST branch has now been merged into the trunk, other options are worth considering this year. Several PEP implementations were suggested, including `PEP 343`_ ('with:'), `PEP 308`_ ('x if y else z'), `PEP 328`_ ('absolute/relative import'), and `PEP 341`_ ('unifying try/except and try/finally'). Suggestions to continue the AST theme were also made, including one of the "global variable speedup" PEPs, `Guido's instance variable speedup idea`_, using the new AST code to improve/extend/rewrite the optimization steps the compiler performs, or rewriting PyChecker to operate from the AST representation. Phillip J. Eby also suggested working on the oft-mentioned bytes type. All of these suggestions, as well as any others that are made, are being recorded on the `PythonCore sprint wiki`_. .. _sprint: http://wiki.python.org/moin/PyCon2006/Sprints .. _PEP 343: http://www.python.org/peps/pep-0343.html .. _PEP 308: http://www.python.org/peps/pep-0308.html .. _PEP 328: http://www.python.org/peps/pep-0328.html .. _PEP 341: http://www.python.org/peps/pep-0341.html .. _Guido's instance variable speedup idea: http://mail.python.org/pipermail/python-dev/2002-February/019854.html .. _PythonCore sprint wiki: http://wiki.python.org/moin/PyCon2006/Sprints/PythonCore Contributing threads: - `python-dev sprint at PyCon < http://mail.python.org/pipermail/python-dev/2005-November/057830.html>`__ - `PEP 328 - absolute imports (python-dev sprint at PyCon) < http://mail.python.org/pipermail/python-dev/2005-November/057853.html>`__ [TAM] -------------------------------------- Reminder: Python is now on Subversion! -------------------------------------- Just a reminder to everyone that the Python source repository_ is now hosted on Subversion. A few minor bugs were fixed, so you can make SVK mirrors of the repository successfully now. Be sure to check out the newly revised Python Developers FAQ_ if you haven't already. .. _repository: http://svn.python.org/projects/ .. _FAQ: http://www.python.org/dev/devfaq.html Contributing threads: - `Freezing the CVS on Oct 26 for SVN switchover < http://mail.python.org/pipermail/python-dev/2005-November/057823.html>`__ - `svn checksum error < http://mail.python.org/pipermail/python-dev/2005-November/057843.html>`__ - `Problems with revision 4077 of new SVN repository < http://mail.python.org/pipermail/python-dev/2005-November/057867.html>`__ - `No more problems with new SVN repository < http://mail.python.org/pipermail/python-dev/2005-November/057888.html>`__ - `dev FAQ updated with day-to-day svn questions < http://mail.python.org/pipermail/python-dev/2005-November/057999.html>`__ - `Mapping cvs version numbers to svn revisions? < http://mail.python.org/pipermail/python-dev/2005-November/058051.html>`__ - `Checking working copy consistency < http://mail.python.org/pipermail/python-dev/2005-November/058056.html>`__ - `Is some magic required to check out new files from svn? < http://mail.python.org/pipermail/python-dev/2005-November/058065.html>`__ [SJB] --------------------------- Updating the Python-Dev FAQ --------------------------- Brett Cannon has generously volunteered to clean up some of the developers' documentation and wants to know if people would rather the bug/patch guidelines to be in a classic paragraph-style layout or a more FAQ-style layout. If you have an opinion on the topic, please let him know! Contributing threads: - `dev FAQ updated with day-to-day svn questions < http://mail.python.org/pipermail/python-dev/2005-November/058025.html>`__ - `Revamping the bug/patch guidelines (was Re: Implementation of PEP 341) < http://mail.python.org/pipermail/python-dev/2005-November/058108.html>`__ [SJB] ========= Summaries ========= ----------- Event loops ----------- This thread initiated in discussion on sourceforge about patches 1049855_ and 1252236_; Martin v. L?wis and Michiel de Hoon agreed that the fixes were fragile, and that a larger change should be discussed on python-dev. Michiel writes visualization software; he (and others, such as the writers of matplotlib) has trouble creating a good event loop, because the GUI toolkit (especially Tkinter) wants its own event loop to be in charge. Michiel doesn't actually need Tkinter for his own project, but he has to play nice with it because his users expect to be able to use other tools -- particularly IDLE -- while running his software. Note that this isn't the first time this sort of problem has come up; usually it is phrased in terms of a problem with Tix, or not being able to run turtle while in IDLE. Event loops by their very nature are infinite loops; once they start, everything else is out of luck unless it gets triggered by an event or is already started. Donovan Baarda suggested looking at Twisted for state of the art in event loop integration. Unfortunately, as Phillip Eby notes, it works by not using the Tkinter event loop. It decides for itself when to call dooneevent (do-one-event). It is possible to run Tkinter's dooneevent version as part of your own event loop (as Twisted does), but you can't really listen for its events, so you end up with a busy loop polling, and stepping into lots of "I have nothing to do" functions for every client eventloop. You can use Tkinter's loop, but once it goes to sleep waiting for input, everything sort of stalls out for a while, and even non-Tkinter events get queued instead of processed. Mark Hammond suggests that it might be easier to replace the interactive portions of python based on the "code" module. matplotlib suggests using ipython instead of standard python for similar reasons. Another option might be to always start Tk in a new thread, rather than letting it take over the main thread. There was some concern (see patch 1049855) that Tkinter doesn't - and shouldn't - require threading. [Jim Jewett posted a summary of this very repetitive and confusing (to the participants, not just summarizers!) thread towards its end, which this summary is very heavily based on. Many thanks Jim!] Contributing threads: - `Event loops, PyOS_InputHook, and Tkinter < http://mail.python.org/pipermail/python-dev/2005-November/057954.html>`__ - `Event loops, PyOS_InputHook, and Tkinter - Summary attempt < http://mail.python.org/pipermail/python-dev/2005-November/058034.html>`__ .. _1049855: http://www.python.org/sf/1049855 .. _1252236: http://www.python.org/sf/1252236 [TAM] ----------------------------- Importing .pyc and .pyo files ----------------------------- Osvaldo Santana Neto pointed out that if a .pyo file exists, but a .pyc doesn't, then a regularly run python will not import it (unless run with -O), but if the .pyo is in a zip file (which is on the PYTHONPATH) then it will import it. He felt that the inconsistency should be addressed and that the zipimport behaviour was preferable. However, Guido said that his intention was always that, without -O, *.pyo files are entirely ignored (and, with -O, *.pyc files are entirely ignored). In other words, it is the zipimport behaviour that is incorrect. Guido suggested that perhaps .pyo should be deprecated altogether and instead we could have a post-load optimizer optimize .pyc files according to the current optimization settings. The two use cases presented for including .pyo files but not .py files were in situations where disk space is at a premium, and where a proprietary "canned" application is distributed to end users who have no intention or need to ever add to the code. A suggestion was that a new bytecode could be introduced for assertions that would turn into a jump if assertions were disabled (with -O). Guido thought that the idea had potential, but pointed out that it would take someone thinking really hard about all the use cases, edge cases, implementation details, and so on, in order to write a PEP. He suggested that Brett and Phillip might be suitable volunteers for this. Contributing thread: - `Inconsistent behaviour in import/zipimport hooks < http://mail.python.org/pipermail/python-dev/2005-November/057959.html>`__ [TAM] --------------------------------------- Default __hash__() and __eq__() methods --------------------------------------- Noam Raphael suggested that having the default __hash__() and __eq__() methods based off of the object's id() might have been a mistake. He proposed that the default __hash__() method be removed, and the default __eq__() method compare the two objects' __dict__ and slot members. Jim Fulton offered a counter-proposal that both the default __hash__() and __eq__() methods should be dropped for Python 3.0, but Guido convinced him that removing __eq__() is probably a bad idea; it would mean an object wouldn't compare equal to itself. In the end, Guido decided that having a default __hash__() method based on id() isn't really a bad decision; without it, you couldn't have sets of "identity objects" (objects which don't have a usefully defined value-based comparison). He suggested that the right decision was to make the hash() function smarter, and have it raise an exception if a class redefined __eq__() without redefining __hash__(). (In fact, this is what it used to do, but it was lost when object.__hash__() was introduced.) Contributing threads: - `Why should the default hash(x) == id(x)? < http://mail.python.org/pipermail/python-dev/2005-November/057859.html>`__ - `Should the default equality operator compare values instead of identities? < http://mail.python.org/pipermail/python-dev/2005-November/057868.html>`__ - `For Python 3k, drop default/implicit hash, and comparison < http://mail.python.org/pipermail/python-dev/2005-November/057924.html>`__ [SJB] --------------------------- Indented multi-line strings --------------------------- Avi Kivity reintroduced the oft-requested means of writing a multi-line string without getting the spaces from the code indentation. The usual options were presented:: def f(...): ... msg = ('From: %s\n' 'To: %s\n' 'Subject: Host failure report for %s\n') ... msg = '''\ From: %s To: %s Subject: Host failure report for %s''' ... msg = textwrap.dedent('''\ From: %s To: %s Subject: Host failure report for %s''') Noam Raphael suggested that to simplify the latter option, textwrap.dedent() should become a string method, str.dedent(). There were also a few suggestions that this sort of dedenting should have syntactic support (e.g. with an appropriate string prefix). In general, the discussion harkened back to `PEP 295`_, a similar proposal that was previously rejected. People tossed the ideas around for a bit, but it didn't look like any changes were likely to be made. .. _PEP 295: http://www.python.org/peps/pep-0295.html Contributing threads: - `indented longstrings? < http://mail.python.org/pipermail/python-dev/2005-November/058042.html>`__ - `str.dedent < http://mail.python.org/pipermail/python-dev/2005-November/058058.html>`__ - `OT pet peeve (was: Re: str.dedent) < http://mail.python.org/pipermail/python-dev/2005-November/058072.html>`__ [SJB] ------------------ Continued AST work ------------------ Neal Norwitz has been chasing down memory leaks; he believes that the current AST is now as good as before the AST branch was merged in. Nick explained that he is particularly concerned about the returns hidden inside in macros in the AST compiler's symbol table generation and bytecode generation steps. Niko Matsakis suggested that an arena is the way to go for memory management; the goal is to be able to free memory en-masse whatever happens and not have to track individual pointers. Jeremy Hylton noted that the AST phase has a mixture of malloc/free and Python object allocation; he felt that it should be straightforward to change the malloc/free to use an arena API, but that a separate mechanism would be needed to associate a set of PyObject* with the arena. The arena concept gained general approval, and there was some discussion about how best to implement it. In other AST news Rune Holm submitted two_ patches_ for the AST compiler that add better dead code elimination and constant folding and Thomas Lee is attempting to implement `PEP 341`_ (unification of try/except and try/finally), and asked for some help (Nick Coghlan gave some suggestions). .. _two: http://www.python.org/sf/1346214 .. _patches: http://www.python.org/sf/1346238 .. _PEP 341: http://python.org/peps/pep-0341.html Contributing threads: - `Optimizations on the AST representation < http://mail.python.org/pipermail/python-dev/2005-November/057865.html>`__ - `Implementation of PEP 341 < http://mail.python.org/pipermail/python-dev/2005-November/058075.html>`__ - `ast status, memory leaks, etc < http://mail.python.org/pipermail/python-dev/2005-November/058089.html>`__ - `Memory management in the AST parser & compiler < http://mail.python.org/pipermail/python-dev/2005-November/058138.html>`__ - `PEP 341 patch & memory management (was: Memory management in the AST parser & compiler) < http://mail.python.org/pipermail/python-dev/2005-November/058142.html>`__ [TAM] --------------------------------------------------------------------- Adding functional methods (reduce, partial, etc.) to function objects --------------------------------------------------------------------- Raymond Hettinger suggested that some of the functionals, like map or partial, might be appropriate as attributes of function objects. This would allow code like:: results = f.map(data) newf = f.partial(somearg) A number of people liked the idea, but it was pointed out that map() and partial() are intended to work with any callable, and turning these into attributes of function objects would make it hard to use them with classes that define __call__(). Guido emphasized this point, saying that complicating the callable interface was a bad idea. Contributing thread: - `a different kind of reduce... < http://mail.python.org/pipermail/python-dev/2005-November/057828.html>`__ [SJB] -------------------------------------------------- Distributing debug build binaries (python2x_d.dll) -------------------------------------------------- David Abrahams asked whether it would be possible for python.org to make a debug build of the Python DLL more accessible. Thomas Heller pointed out that the Microsoft debug runtime DLLs are not distributable (which is why the Windows installer does not include the debug version of the Python DLL), and that the ActiveState distribution contains Python debug DLLs. Tim Peters explained that when he used to collect up the debug-build bits at the time the official installer was built, they weren't included in the main installer, because they bloated its size for something that most users don't want. He explained that he stopped collecting the bits because no two users wanted the same set of stuff, and so it grew so large that people complained that it was too big. Tim suggested that the best thing to do would be to define precisely what an acceptable distribution format is and what exactly it should contain. Martin indicated that he would accept a patch that picked up the files and packages them, and he would include them in the official distribution. Contributing thread: - `Plea to distribute debugging lib < http://mail.python.org/pipermail/python-dev/2005-November/057896.html>`__ [TAM] ----------------------------------- Creating a python-dev-announce list ----------------------------------- Jack Jansen suggested that a low-volume, moderated, python-dev-announce mailing list be created for time-critical announcements for people developing Python. The main benefit would be the ability to keep up with important announcements such as new releases, the switch to svn, and so on, even when developers don't have time to keep up with all threads. Additionally, it would be easier to separate out such announcements, even when following all threads. Although these summaries exist (and the announcements section at the top pretty much covers what Jack is after), the summaries occur at least a week after the end of the period that they cover, which could be as much as three weeks after any announcement (if it occurred on the first of a month, for example). I suggested that a simpler possibility might follow along the lines of the PEP topic that the python-checkins list provides (a feature of Mailman). This would still require some sort of effort by the announcer (e.g. putting some sort of tag in the subject), but wouldn't require an additional list, or additional moderators. However, Martin pointed out that this would put an extra burden on people to remember to post to such a list; this burden would also exist using the Mailman topic mechanism. There wasn't much apparent support for the list, so this seems unlikely to occur at present. Of course, that could be because the people that would like it are too busy to have noticed the thread yet <0.5 wink>, so perhaps there is more to come. Contributing thread: - `Proposal: can we have a python-dev-announce mailing list? < http://mail.python.org/pipermail/python-dev/2005-November/057880.html>`__ [TAM] ------------------------------------- Notifications of weakref dereferences ------------------------------------- When integrating with another system (such as gtk), it can be useful if each object in the other system maps to (at most) one python wrapper. If python references drop to zero, then the next python reference would (by default) create a different wrapper object. So the wrapper tries to stay alive (with only a weak reference to the true object) as long as the true object does. But if that wrapper does get used, it needs to replace the weak reference with a strong reference. The standard weakref callbacks weren't quite up to the task, but it looked like there were workarounds, either by abusing weakref methods in a subtask, or by changing the architecture slightly. Contributing thread: - `Weak references: dereference notification < http://mail.python.org/pipermail/python-dev/2005-November/057961.html>`__ [Jim Jewett] -------------------------------------------- Should 1.2 be a floating point or a decimal? -------------------------------------------- There was general agreement that decimal might deserve a literal marker of its own in python 3.0, but much less agreement that it should be the default floating or fixed point representation. Decimals are better for many business applications, but floats are faster and are better for most scientific and engineering applications. Contributing thread: - `Unifying decimal numbers. < http://mail.python.org/pipermail/python-dev/2005-November/057951.html>`__ [Jim Jewett] ----------------------- Speeding up int(string) ----------------------- Uncle Timmy wants python to do better on certain benchmarks, and gave `an example`_. The bottleneck turns out to be parsing an integer from a string. At the moment, this is not only slow, it has potential bugs. Patches were submitted, but had not been applied at the time this summary was written. .. _an example: http://spoj.sphere.pl/ Contributing threads: - `int(string) (was: DRAFT: python-dev Summary for 2005-09-01 through 2005-09-16) < http://mail.python.org/pipermail/python-dev/2005-November/057994.html>`__ - `to_int -- oops, one step missing for use. < http://mail.python.org/pipermail/python-dev/2005-November/058006.html>`__ - `(no subject) < http://mail.python.org/pipermail/python-dev/2005-November/058023.html>`__ [Jim Jewett] ---------------------------------------------------- Building Python with Visual C++ 2005 Express Edition ---------------------------------------------------- Is it possible? Probably, but like other newer VC++ there are problems, particularly with changes to crt, and deprecation of standard interfaces. It won't become the "standard" build tool. Contributing thread: - `Building Python with Visual C++ 2005 Express Edition < http://mail.python.org/pipermail/python-dev/2005-November/058024.html>`__ [Jim Jewett] ------------------------ Freezing mutable objects ------------------------ `Last fortnight's thread` about ways to take an immutable snapshot of an otherwise mutable object continued. Discussions centered around how true the reflection has to be, and how to do this efficiently; an agreement was difficult to come to. Contributing thread: - `apparent ruminations on mutable immutables (was: PEP 351, the freeze protocol) < http://mail.python.org/pipermail/python-dev/2005-November/057839.html>`__ .. _Last fortnight's thread: http://www.python.org/dev/summary/2005-10-16_2005-10-31.html#freeze-protocol [TAM] =============== Skipped Threads =============== - `Divorcing str and unicode (no more implicit conversions). < http://mail.python.org/pipermail/python-dev/2005-November/057827.html>`__ - `[C++-sig] GCC version compatibility < http://mail.python.org/pipermail/python-dev/2005-November/057831.html>`__ - `PYTHOPN_API_VERSION < http://mail.python.org/pipermail/python-dev/2005-November/057879.html>`__ - `Adding examples to PEP 263 < http://mail.python.org/pipermail/python-dev/2005-November/057891.html>`__ - `Class decorators vs metaclasses < http://mail.python.org/pipermail/python-dev/2005-November/057904.html>`__ - `PEP 352 Transition Plan < http://mail.python.org/pipermail/python-dev/2005-November/057911.html>`__ - `PEP submission broken? < http://mail.python.org/pipermail/python-dev/2005-November/057935.html>`__ - `cross-compiling < http://mail.python.org/pipermail/python-dev/2005-November/057939.html>`__ - `[OTAnn] Feedback < http://mail.python.org/pipermail/python-dev/2005-November/057941.html>`__ - `Weekly Python Patch/Bug Summary < http://mail.python.org/pipermail/python-dev/2005-November/057949.html>`__ - `Coroutines (PEP 342) < http://mail.python.org/pipermail/python-dev/2005-November/058133.html>`__ ======== Epilogue ======== This is a summary of traffic on the `python-dev mailing list`_ from November 01, 2005 through November 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 7th summary written by the python-dev summary squad of Steve Bethard and Tony Meyer (so nice to be back on time!). 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 penny helps 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 at 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://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/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-10-01_2005-10-15.html .. _original text file: http://www.python.org/dev/summary/2005-11-01_2005-11-15.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-announce-list/attachments/20051127/b9a7f721/attachment-0001.html From gary at modernsongs.com Sun Nov 27 14:24:25 2005 From: gary at modernsongs.com (Gary Poster) Date: Sun, 27 Nov 2005 08:24:25 -0500 Subject: Fredericksburg VA ZPUG: No December meeting; details on Jan and Feb meetings Message-ID: <01DBCBC0-928D-497B-87FB-EE99443EDF49@modernsongs.com> As discussed at the November Fredericksburg, VA ZPUG meeting, we are not going to have a December 14 ZPUG because of holiday goings-on. Andrew Sawyers will present on Squid and Zope in our January 11 meeting (other topics TBD). Zac Bir, Benji York, and Gary Poster will present in our February 8 meeting in an all-Twisted session based very loosely on the new O'Reilly Twisted book (http://www.oreilly.com/catalog/twistedadn/ index.html), with Zac concentrating on Twisted and OS X, Gary concentrating on Twisted and Zope 3, and Benji giving a lightning talk of his impressions of the book. General ZPUG information When: second Wednesday of every month, 7:30-9:00 (except not December 14, 2005!) Where: Zope Corporation offices. 513 Prince Edward Street; Fredericksburg, VA 22408 (tinyurl for map is http://tinyurl.com/duoab). Parking: Zope Corporation parking lot; entrance on Prince Edward Street. Topics: As desired (and offered) by participants, within the constraints of having to do with Python or Zope. Contact: Gary Poster (gary at zope.com) From pmartin at snakecard.com Mon Nov 28 01:02:35 2005 From: pmartin at snakecard.com (Philippe C. Martin) Date: Sun, 27 Nov 2005 18:02:35 -0600 Subject: SCU3 and Python packaged for U3 (with SCU3) V 0.1 released Message-ID: Dear all, I am very happy to announce the release of SCU3 V 0.1 and SCU3Python.u3p V. 0.1. SCU3 is a python wrapper for U3 compliante devices SCU3Python.u3p is a Python binary (2.4.2) packaged with SCU3 that allows to launch idle from the U3 device launchpad Both may be found on www.snakecard.com, download section. Best regards, Philippe From ian at excess.org Mon Nov 28 07:50:57 2005 From: ian at excess.org (Ian Ward) Date: Mon, 28 Nov 2005 01:50:57 -0500 Subject: ANN: Urwid 0.8.10 curses-based UI library Message-ID: <20051128065056.GA6532@paintedblack> Announcing Urwid 0.8.10 ---------------------- Urwid home page: http://excess.org/urwid/ Tarball: http://excess.org/urwid/urwid-0.8.10.tar.gz Updated Tutorial: http://excess.org/urwid/tutorial.html About this release: =================== This release includes three new tutorial chapters as well as a big pile of bug fixes. New in this release: ==================== - Expanded tutorial to cover advanced ListBox usage, custom widget classes and the Pile, BoxAdapter, Columns, GridFlow and Overlay classes. - Added escape sequence for 'shift tab' to curses_display. - Added ListBox.set_focus_valign(..) to allow positioning of the focus widget within the ListBox. - Added WidgetWrap class for extending existing widgets without inheriting their complete namespace. - Fixed web_display/mozilla breakage from 0.8.9. Fixed crash on invalid locale setting. Fixed ListBox slide-back bug. Fixed improper space trimming in calculate_alignment(..). Fixed browse.py example program rows bug. Fixed sum definition, use of long ints for python2.1. Fixed warnings with python2.1. Fixed Padding.get_pref_col(..) bug. Fixed Overlay splitting CJK characters bug. About Urwid =========== Urwid is a curses-based UI library for Python. It features fluid interface resizing, CJK support, multiple text layouts, simple attribute markup, powerful scrolling list boxes, flexible edit boxes and HTML screen shots. Urwid is released under the GNU LGPL. From titus at caltech.edu Tue Nov 29 09:54:50 2005 From: titus at caltech.edu (C. Titus Brown) Date: Tue, 29 Nov 2005 00:54:50 -0800 Subject: ANNOUNCE: twill v0.8 Message-ID: <438C175A.3040806@caltech.edu> ANNOUNCING twill v0.8. twill is a simple language for testing Web applications. It's designed for automated testing of Web sites, but it can be used to interact with Web sites in a variety of ways. twill has an interactive shell, 'twill-sh', and can also run scripts. twill is a reimplementation of Cory Dodt's PBP. It is built on top of Python and John J. Lee's mechanize. A twill script looks like this: # go to the /. login page go http://slashdot.org/login.pl # fill in the form fv 1 unickname test fv 1 upasswd test submit # ok, there's no such account ;). show error HTML. show --- This is the sixth public release of twill, version 0.8. (Tagline: "85% unit tested.") You can install twill with easy_install via PyPi, or download the latest .tar.gz at: http://darcs.idyll.org/~t/projects/twill-0.8.tar.gz Documentation is included in the .tar.gz and is also online at http://www.idyll.org/~t/www-tools/twill.html --- Miscellaneous details: twill is implemented in Python and uses pyparsing and mechanize. In addition to the existing simple command language, twill can easily be extended with Python. twill also provides a fairly simple and well-documented wrapper around mechanize. twill scripts can be recorded with maxq, although scripts may require some hand tweaking at the moment. See the twill documentation for more information. twill does not understand JavaScript, I'm sorry to say. --- New features: * test WSGI Python applications in-process; * Updated to latest versions of mechanize, ClientCookie, ClientForm, and pullparser; * Significant increase in number of unit tests & their code coverage; * Automatic 'tidy' preprocessing when available; * easy_install/eggs now supported; * http-equiv redirect now works; * new commands: - 'formaction' changes form URLs; - 'tidy_ok' checks for 'tidy' correctness; - 'showhistory' command; Special thanks to sureshvv and Simon Buenzli... From andy at enfoldsystems.com Tue Nov 29 17:50:03 2005 From: andy at enfoldsystems.com (Andy McKay) Date: Tue, 29 Nov 2005 08:50:03 -0800 Subject: Vancouver Python and Zope User Group: Dec 6th Message-ID: <438C86BB.90302@enfoldsystems.com> Brett Cannon: What's new in Python 2.5 A review of all the funky new features we can look forward to in upcoming Python 2.5 releases ActiveState, 7pm, Dec 6th. More info: http://www.vanpyz.org -- Andy McKay Enfold Systems, LLC http://www.enfoldsystems.com From frank at niessink.com Tue Nov 29 23:23:57 2005 From: frank at niessink.com (Frank Niessink) Date: Tue, 29 Nov 2005 23:23:57 +0100 Subject: [ANN] Release 0.52 of Task Coach Message-ID: <438CD4FD.4090309@niessink.com> Hi all, I'm pleased to announce release 0.52 of Task Coach. New in this release: Bugs fixed: * For completed tasks, the number of days left for a task is now the number of days between the completion date and the due date. This prevents that the number of days left of completed tasks keeps decreasing, i.e. becoming more negative. For uncompleted tasks, the number of days left is still the number of days between today and the due date, of course. Patch provided by Maciej Malycha. * Put taskocachlib package first on the Python search path to prevent name conflict with the config module on Gentoo Linux. * Mention blue icon in the help on task colors. * Don't allow empty categories. Features added: * Tasks can be dragged and dropped. * Tasks can have an hourly fee and/or a fixed fee. Revenue is calculated based on effort spent. * First tiny steps towards a user manual, see 'Help' -> 'Help contents'. * Whether the main window hides itself when iconized is now adjustable behavior. See 'Edit' -> 'Preferences'. Feature changed: * Backups are created just before saving, instead of when loading a .tsk file. Patch provided by Maciej Malycha. Feature removed: * Files in the old comma-separated format can no longer be read by Task Coach. What is Task Coach? Task Coach is a simple task manager that allows for hierarchical tasks, i.e. tasks in tasks. Task Coach is open source (GPL) and is developed using Python and wxPython. You can download Task Coach from: http://taskcoach.niessink.com https://sourceforge.net/projects/taskcoach/ A binary installer is available for Windows XP, in addition to the source distribution. Note that Task Coach is alpha software, meaning that it is wise to back up your task file regularly, and especially when upgrading to a new release. Cheers, Frank From simon at unisolve.com.au Wed Nov 30 07:51:37 2005 From: simon at unisolve.com.au (Simon Taylor) Date: Wed, 30 Nov 2005 17:51:37 +1100 Subject: ANNOUNCE: Last chance to register for OSDC 2005 Message-ID: OSDC 2005 is almost upon us. If you haven't already registered, then you have until 4pm this Friday to do so. See http://www.osdc.com.au/registration/ Don't miss out on this unique and exciting Australian Open Source event! - Simon Taylor From casevh at comcast.net Wed Nov 30 08:51:27 2005 From: casevh at comcast.net (casevh@comcast.net) Date: 29 Nov 2005 23:51:27 -0800 Subject: ANN: DecInt 0.3 - Arithmetic for very large decimal integers Message-ID: <1133337086.976849.263960@g49g2000cwa.googlegroups.com> DecInt is a class that support arithmetic on very large decimal integers. For example, it can calculate the decimal form of the 42nd Mersenne prime, all 7,816,230 digits, in less than 21 seconds. And less than 6 seconds if gmpy 1.01 is available. This version is significantly faster than the prior version. Multiplication used a combination of 4-way Toom-Cook and Nussbaumer convolution. Pure Python multiplication is less than 10x slower than GMP's hand optimised assembler code! Division uses a new algorithm based on David M. Smith's division algorithm. Pure Python division is 16x slower than GMP but can actually be faster in some instances; for example, dividing a 2,000,000 digit number by an 800,000 digit number. DecInt can be found at http://home.comcast.net/~casevh/ (DecInt used to be called BigDecimal; I renamed it to avoid confusion with the "decimal" class include with Python.) Enjoy, casevh From mscott at goldenspud.com Wed Nov 30 19:11:50 2005 From: mscott at goldenspud.com (mscott@goldenspud.com) Date: Wed, 30 Nov 2005 12:11:50 -0600 (CST) Subject: ANN: Louie-1.0b2 - Signal dispatching mechanism Message-ID: <20051130181150.17AAD8C8C1@localhost.localdomain> Louie 1.0b2 is available: Louie provides Python programmers with a straightforward way to dispatch signals between objects in a wide variety of contexts. It is based on PyDispatcher_, which in turn was based on a highly-rated recipe_ in the Python Cookbook. .. _PyDispatcher: http://pydispatcher.sf.net/ .. _recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/87056 For more information, visit the Louie project site: Patrick K. O'Brien and contributors From amk at amk.ca Wed Nov 30 23:56:06 2005 From: amk at amk.ca (A.M. Kuchling) Date: Wed, 30 Nov 2005 17:56:06 -0500 Subject: Python bug day on Sunday Dec. 4 Message-ID: <20051130225606.GA24037@rogue.amk.ca> Let's have a Python bug day this Sunday. One goal might be to assess bugs and patches, and make a list of ones we can work on at the Python core sprint at PyCon . Meeting on IRC: #python-dev on irc.freenode.net Date: Sunday, December 4th Time: roughly 9AM to 3PM Eastern (2PM to 8PM UTC). People on the US West Coast may want to show up from 9AM to 3PM Pacific time (12PM to 6PM Eastern), because it'll be more convenient. Meeting on IRC: #python-dev on irc.freenode.net --amk