Mailman 3 July 2004 - Python-announce-list

MGC2004 DEADLINE EXTENSION - 2nd Workshop on Middleware for Grid Computing
by Middleware 04 July 7, 2004

July 7, 2004

MGC2004 - 2nd International Workshop on Middleware for Grid Computing in conjunction with the 5th International Middleware Conference 2004 Toronto, Ontario, Canada - October 18th, 2004 http://mgc2004.lncc.br Announcements: ************* ************* Submission deadline has been extended to July 18th. ********** ************* No further extensions will be given. ********** Given the submission extension, notification of acceptance will be delayed until August 14th. The deadline for the camera-ready paper version has not changed and is a hard dealine !! To reduce the effort necessary for preparation of the camera-ready version, authors are advised to submit their papers already in ACM format. History: The first edition of this workshop (MGC2003) was held on June 17th 2003, in conjunction with the Middleware Conference, in Rio de Janeiro, Brazil. MGC2003 saw a good combination of the many different flavors in Middleware for Grid Computing, with 16 technical presentations and discussions on several stimulating topics including, among the others, Classic Grids, object oriented technologies, Service- based Grids, Open grid Service Architecture, Agent Grid, Interactive Grid, Grid Economy / Scheduling, and Portlets. After the event, extended and thoroughly revised versions of the papers were invited to a Special Issue of Concurrency and Computation Practice and Experience Journal - Vol.16 N.5 2004. The first workshop generated substantial interest in the community and we hope to build on this tradition this year. Far from exhausting the topics of interest, MGC2003 paved the way for a second edition of the workshop, that will continue the most interesting and stimulating topics emerged last year, and also include some novel issues. Description: Much of the focus of Grid until recently has been within research organizations. Currently the involvement of commercial organization has increased tremendously. That leads to a greater focus on integration with commercial computing models and more work on the security and resource management models required for automated and secure access negotiation for remote resources. In order to control such a broad base of resources, Grid Computing has a middleware layer which controls the distributed execution of applications. In this Workshop we would encourage researchers from the various GRID middleware communities to submit and present original work for publication. Overall topics of interest include but are not limited to: Classic Grid Middleware Object Oriented technologies or Component Middleware WSRF/OGSA/Web services Grid Middleware Architectures Grid Services Grid Middleware Security Resource Management and Scheduling Strategies and protocols for obtaining QoS Semantic Grid Middleware Managing Information in Grid Middleware Grid Object Metadata and Schemas Programming Models, Tools, and Environments Performance Evaluation and Modeling Evolution of and experiences with Grid systems Wireless Grids Data Grid Middleware Dependability and Fault Tolerance in Grids Virtualization in Grids Paper Submission: The Workshop on Middleware for Grid Computing invites authors to submit original and unpublished work. Papers should not exceed 4-6 single-spaced pages of text using 10 point size type on A4 paper. Authors should submit a PostScript (level 2) or PDF file that will print on a PostScript printer. Submission implies the willingness of at least one of the authors to register and present the paper. All selected papers for are peer-reviewed and will be published in the ACM Digital Library. Selected (extended) papers will be invited to a special issue of Concurrency and Computation: Practice and Experience Journal for 2005. Some papers may be selected to be presented as posters. Electronic only submission. Important Dates: Paper Submissions: July 18th, 2004 Papers Not. of acceptance: August 14th, 2004 Papers Camera-ready: September 1st, 2004 Program Committee (preliminar) * David Abramson - Monash U. AU * Cristiana Amza - U Toronto, CA * Rajkumar Buyya - U Melbourne, AU * Jim Basney - NCSA/UIUC, USA * Emmanuel Cecchet - INRIA Alpes, FR * Renato Cerqueira - PUC-Rio, BR * Walfredo Cirne - UFCG, BR * Geoff Coulson - Lancaster U, UK * Petre Dini - Cisco Systems & Concordia U, CA * Geoffrey Fox - U Indiana, US * Wolfgang Gentzsch - MCNC, US * Kate Keahey - U Chicago and ANL, US * Edmundo Madeira - UNICAMP, BR * Thomas Magedanz - TU Berlin & FHG Fokus, DE * Radha Nandkumar - NCSA/UIUC, US - Workshop Co-Chair * Andrea Omicini - U Bologna, IT * Fabio Porto - LNCC, BR - Publicity Co-Chair * Omer Rana - Cardiff U, UK * Vinod Rebello - UFF, BR * Noemi Rodrigues - PUC-Rio, BR * Bruno Schulze - LNCC, BR - Workshop Co-Chair * Stefan Tai - IBM T J Watson, US * Carlos Westphall - UFSC , BR

1 0

[ANN] libgmail 0.0.3 -- Gmail access via Python
by follower＠gmail.com July 7, 2004

July 7, 2004

libgmail -- Python binding for Google's Gmail service <http://libgmail.sf.net/> The `libgmail` project is a pure Python binding to provide access to Google's Gmail web-mail service. The library currently ships with one demonstration utility to archive messages from a Gmail account into mbox files, suitable for importing into a local email client. License: GPL 2.0 Major changes since 0.0.1 & 0.0.2: * Archive Gmail to mbox utility. * No longer requires external ClientCookie package. * Uses constants extracted directly from Gmail Javascript, and includes utility to repeat the process if required. * Code & API refactoring. * Lazy retrieval and caching of thread and message data. * Sourceforge project & home page. <p><a href="http://libgmail.sf.net/">libgmail 0.0.3</a> - The `libgmail` project is a pure Python binding to provide access to Google's Gmail web-mail service. (08-Jul-04)</p>

1 0

ANN: pyXSLdoc 0.65
by csad7＠t-online.de July 7, 2004

July 7, 2004

what is it ---------- An application to produce documentation for XSLT files in XHTML format, similar to what javadoc does for Java files. changes since the last release ------------------------------ * shortcomments on overview tables are shown now (in ReST version only) * new options --windowtitle will be shown as Main Headline on overview page if no doctitle given or found --doctitle doctitle.txt in ReST format will be shown at the top of overview page --encoding specify the encoding of additional ReST documentation files like help.txt overview.txt or directory.txt. * improved --verbose, -v output prints messages about used doctitle, overview and helpfile ReST files now * bugfixes and Javadoc comment style improvements suggested by Doron Enav see http://cthedot.de/pyxsldoc/README.txt for a complete list of changes license ------- pyXSLdoc is published under the LGPL. download -------- download pyXSLdoc v0.65 - 040707 from http://cthedot.de/pyxsldoc/ pyXSLdoc needs * Python 2.3 (tested with Python 2.3.4 on Windows XP only) * Pyana (tested with Pyana 0.9.1 only) * Docutils (tested with Docutils 0.3 only) usage ----- Copy the XSLT files to document in a directory below pyXSLdoc (you could also give the complete path to your files but that would end up like that in the documentation). Then start the documentation process with >python xsldoc.py DIRNAMES FILENAMES [options] DIRNAMES directories with XSLT files to document,e.g. dir1 dir2 All directories and XSLT files below a given directory will be processed, so you can just use your XSLT package main directory name or use option -s. FILENAMES single XSLT files to document, e.g. file1.xsl path/file2.xsl options ~~~~~~~ -sSOURCEPATH, --sourcepath=SOURCEPATH sourcepath to XSLTs, all XSLT files under this path will be documented and ``$SOURCEPATH/doctitle.txt`` and ``$SOURCEPATH/overview.txt`` will be used for the overview. Alternatively you might also simply list all dirs and XSLT files to document. -j, --javadoc, --htmldocs process comments in Javadoc style (XHTML and @tags). Default is reStructuredText (ReST). -dDOCPATH, --docpath=DOCPATH documentation target directory. Default is ``./_xsldoc`` --windowtitle=WINDOWTITLE browser window title for the documentation. Text only, no markup. --doctitle=DOCTITLE show the contents of this ReST .txt file at the top of the overview page. Default is ``$SOURCEPATH/doctitle.txt``. If ommitted or no file is found, WINDOWTITLETEXT is used. -oOVERVIEW, --overview=OVERVIEW show the contents of this ReST .txt file on the overview page. Default is ``$SOURCEPATH/overview.txt`` --helpfile=HELPFILE show the information of this ReST .txt file on the help page. Default is ``./HELP.txt``. --encoding=ENCODING encoding of additional documenting ReST files (HELP.txt, doctitle.txt, overview.txt, directory.txt etc.). Default is utf-8. (Encoding of XSLT files and comments in these is of course read from the XSLT file itself.) -r, --removedocs remove all comments from given XSLTs and save results in COMMENTSTRIPPEDPATH. Present files will be OVERWRITTEN! -cCOMMENTSTRIPPEDPATH, --commentstrippedpath=COMMENTSTRIPPEDPATH path where XSLTs will be saved after removing of all docs. Only used when option ``--removedocs`` is given. Default directory is ``./_optimized``. -v, --verbose show more detailed information while generating the documentation thanks for the interest. any comment is appreciated christof hoeke http://cthedot.de <P><A HREF="http://cthedot.de/pyxsldoc/">pyXSLdoc 0.65</A> - generate XSLT documentation (7-Jul-04)

1 0

Middleware'04 Final Call for Workshops and Posters
by Middleware 04 July 7, 2004

July 7, 2004

ACM/IFIP/USENIX Middleware 2004 Workshops Call For Workshop Papers and Posters http://www.eecg.toronto.edu/middleware2004/ws.htm Middleware'2004 will host three exciting workshops and a long-waited Doctoral Symposium. Workshop papers will be published in the Middleware'2004 Companion Proceedings and in the ACM Digital library. Please visit the workshop pages for specific submission details. * 3rd Workshop on Adaptive and Reflective Middleware * 2nd Workshop on Middleware for Grid Computing * 2nd Workshop on Middleware for Pervasive and Ad-Hoc Computing * 1st International Middleware Doctoral Symposium To visit the pages of each workshop, follow the links in http://www.eecg.toronto.edu/middleware2004/ws.htm Important Dates: Workshop paper submissions: July 10th, 2004 Notification of acceptance: August 10th, 2004 Camera-ready papers: September 1st, 2004 Workshops: October 18th or 19th, 2004 ****************************************************************************** ACM/IFIP/USENIX Middleware 2004 Workshops Call For Posters Posters are meant for publicizing current research initiatives as well as interesting new systems implemented using middleware technology. Reports of preliminary experience from middleware use cases are solicited. A 500-word summary of the poster's contents should be submitted by July 10th, 2004. Along with the notification of acceptance, authors will receive formatting instructions for the posters to be presented at the conference. Poster summaries will be published as part of the workshop proceedings. Note that the poster summaries will not be published within the conference proceedings. Submissions should be in PDF or PS format and should be sent directly by e-mail to the Posters Chair at delara(a)cs.toronto.edu, with the following subject line: "Middleware 2004 Poster Submission". Important Dates: Poster submissions: July 10th, 2004 Notification of acceptance: August 10th, 2004 For additional information contact: Eyal de Lara Middleware2004 Posters Chair Department of Computer Science University of Toronto Tel: +1-416-946-8656; Fax: +1-416-978-4765 delara(a)cs.toronto.edu

1 0

cx_Freeze 3.0 beta2
by Anthony Tuininga July 7, 2004

July 7, 2004

What is cx_Freeze? cx_Freeze is a set of utilities for freezing Python scripts into executables using many of the techniques found in Thomas Heller's py2exe, Gordon McMillan's Installer and the Freeze utility that ships with Python itself. Where do I get it? http://starship.python.net/crew/atuining http://www.computronix.com/utilities.shtml (it may be a few days before the second site is updated) What's new? 1) Fix issues with locating the initscripts and bases relative to the directory in which the executable was started. 2) Added new base executable ConsoleKeepPath which is used when an existing Python installation is required (such as for FreezePython itself). 3) Forced the existence of a Python installation to be ignored when using the standard Console base executable. 4) Remove the existing file when copying dependent files; otherwise, an error is raised when attempting to overwrite read-only files. 5) Added option -O (or -OO) to FreezePython to set the optimization used when generating bytecode. -- Anthony Tuininga anthony(a)computronix.com Computronix Distinctive Software. Real People. Suite 200, 10216 - 124 Street NW Edmonton, AB, Canada T5N 4A3 Phone: (780) 454-3700 Fax: (780) 454-3838 http://www.computronix.com

1 0

REMINDER: BayPIGgies: July 8, 7:30pm
by Aahz July 7, 2004

July 7, 2004

The next meeting of BayPIGgies will be Thurs July 8 at 7:30pm. It will feature Roger Binns talking about BitPim, a program that manipulates data on cell phones. http://bitpim.sf.net/ BayPIGgies meetings are in Stanford, California. For more information and directions, see http://www.baypiggies.net/ Before the meeting, some people meet at 6pm for dinner at Jing Jing in downtown Palo Alto. Ducky Sherwood is handling that; please send RSVPs to ducky(a)osafoundation.org Discussion of dinner plans is handled on the BayPIGgies mailing list. NOTE: Please RSVP by 3pm 7/8 if you want to attend the dinner. Jing Jing 443 Emerson St. (half block north of University) Palo Alto 650-328-6885 Advance notice: The August 12 meeting agenda has not been set. Please send e-mail to baypiggies(a)baypiggies.net if you want to make a presentation. -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "Typing is cheap. Thinking is expensive." --Roy Smith, c.l.py

1 0

python-dev Summary for 2004-06-16 through 2004-06-30
by Brett Cannon July 6, 2004

July 6, 2004

Initial attempt bounced; if this actually ends up as a duplicate, sorry. ---------------- python-dev Summary for 2004-06-16 through 2004-06-30 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from June 16, 2004 through June 30, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the forty-third summary written by Brett Cannon (and that count is correct; 21.5 months worth of reading and writing). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot 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`_. .. _PEP Markup: http://www.python.org/peps/pep-0012.html 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 on 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. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _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 .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-06-16_2004-06-30.html .. _original text file: http://www.python.org/dev/summary/2004-06-16_2004-06-30.ht Summary Announcements ===================== The trouble plaguing mail.python.org mid-month has been cleared up. It had led to some rather delayed emails so if you sent one in and it was ignored for no good reason you might want to consider bringing the topic back up. In the little comment made by the summary count last month, I questioned whether that count was correct. Turns out it was off by one; this is the true forty-third semi-monthly summary by me (month-long summaries I count as two summaries; more of a count of the number of semi-months I have been doing this). So counting the two week span that I took off when Raymond Hettinger summarized for a week way back in October 2002 (still waiting for the second week, Raymond =) I have been doing this for 22 months straight. And yet after all of that email I still have my vision intact. Amazing. A reader suggested that PEP mentions also include the the title of the PEP. Now normally I purposefully leave it out. Not only is it easier for me to not have to look up the title, but I always hope it might help spurn people on to read the PEP instead of going by my summary of what it entails. Does that even work? If you would rather have me state the title, send me an email. Silence will be taken to mean that you are fine with the way I do it now. Otherwise I need to have a certain number of people (have a number in my head between 1 and 100 =) tell me that they would rather have me institute this change. Summaries ========= --------------------------------------------- Decimal type still chugging along --------------------------------------------- Facundo Batista updated `PEP 327`_ with what are close to the last issues for the PEP. There has also been some recent activity in the sandbox on the package. It could still make it into 2.4 ... And it has! As I wrote this Decimal.py graduated kindergarten, left the sandbox, and is now out on the playground with the rest of Lib. Play nice. .. _PEP 327: http://www.python.org/peps/pep-0327.html Contributing threads: - `PEP 327 (Decimal data type) updated and status <http://mail.python.org/pipermail/python-dev/2004-June/045434.html>`__ ------------------------------------------------- CVS docs, now in handy tarball form ------------------------------------------------- Fred Drake has tweaked the script that puts up new versions of the CVS docs to also upload a tarball of the HTML. You can find that and links to the other in-development documentation at http://www.python.org/dev/doc/ . Contributing threads: - `Downloadable HTML from the trunk <http://mail.python.org/pipermail/python-dev/2004-June/045452.html>`__ --------------------------------------------- Proposed additions to heapq API --------------------------------------------- Raymond Hettinger proposed adding two new functions to the heapq API. heappushpop() would take an item, push it on to the heap, and then pop off the smallest value. heapiter() would return a destructive iterator. The actual implementation of heappushpop() got the most discussion. No final decision has been made, so if either function sounds good to you then do speak up. Contributing threads: - `heapq API <http://mail.python.org/pipermail/python-dev/2004-June/045348.html>`__ --------------------------------------- Consolidation of CJK codecs --------------------------------------- Hye-Shik Chang consolidated the various CJK codecs into various files and managed to save some space in terms of the files themselves. As M-A Lemburg pointed out, though, there was no need to in terms of loading size since most linkers mmap only what is needed to run. Contributing threads: - `Planned updates for cjkcodecs before 2.4a1 <http://mail.python.org/pipermail/python-dev/2004-June/045415.html>`__ ------------------------------------------------ Function decorators in 2.4 ... maybe ------------------------------------------------ The topic of whether function decorators would go into 2.4, and if so with what syntax, continued to be debated from the `last summary`_. Beyond reference implementations (which include an implementation not requiring new syntax), nothing really changed. Overall people agreed they would like to see it in 2.4 using whatever syntax Guido chooses (and he has three in mind, so no more suggestions!), but if he felt the need to wait then functionality would be held off for 2.5 . Contributing threads: - `functions decorators in 2.4? <http://mail.python.org/pipermail/python-dev/2004-June/045440.html>`__ - `decorators and 2.4 <http://mail.python.org/pipermail/python-dev/2004-June/045516.html>`__ ------------------------------------------------------------------------- Making ``''.join(list_of_strs)`` an inconsequential idiom ------------------------------------------------------------------------- As most people know, concatenating strings in a 'for' loop is a bad idea; the idiom you are supposed to use is to store the strings you want to concatenate in a list and the pass it to ``''.join(list_of_strs)``. This is because string addition requires allocating memory for the size of the concatenation and then copying from both strings into the new memory. The constant new memory allocation is costly when you have a loop that goes for more than a few iterations. Raymond Hettinger suggested altering the str object to have a pointer that would point to any strings that were meant to be treated as concatenated to the current string. The problem with this is that it grew the str object the size of a pointer and that is costly for a object as common as string. Armin Rigo gave this challenge a shot and ended up with a bunch of code that special-cases the BINARY_ADD opcode. Neither solution as been accepted at this moment. Contributing threads: - `Wild Idea for the Year <http://mail.python.org/pipermail/python-dev/2004-June/045488.html>`__ - `Building strings with += <http://mail.python.org/pipermail/python-dev/2004-June/045504.html>`__ ---------------------------------------------------------------------------------------- Possible exposure of universal newlines outside of the file object ---------------------------------------------------------------------------------------- Scott David Daniels suggested a new itertools function that would work like universal newlines but for strings or files already opened without universal newlines turned on. People were receptive to the idea, just not for putting it into itertools. Suggestions ranged from exposing the functionality as a static method of the file type to sticking it into 'string'. No conclusion of where to put it was reached. Contributing threads: - `Possible addition to itertools <http://mail.python.org/pipermail/python-dev/2004-June/045456.html>`__ ---------------------------------- NOP does exist I tell you! ---------------------------------- Raymond Hettinger asked if anyone objected to adding a no-op opcode (aptly named NOP). People said nope (see? "NOP", "nope", sound the same? <eddie izzard>Forget it</eddie izzard>). So it's in. Contributing threads: - `NOP <http://mail.python.org/pipermail/python-dev/2004-June/045491.html>`__ --------------------------------------------------------------- Yes, the Windows binary for 2.4 will use VC 7.1 --------------------------------------------------------------- Yes, Python 2.4 will use VC 7.1 . No, we are not going to have a VC 6 binary (you can build it if you want, though). No, distributing the needed DLLs with the installer does not go against the GPL to the best of our knowledge (even though the codebase is not GPL but more BSD and no one from the FSF has told it including the DLLs is wrong). Maybe, we will use Martin v. Loewis' MSI installer, maybe not (still being debated as this was being written). Contributing threads: - `VC 7.1 maintenance? <http://mail.python.org/pipermail/python-dev/2004-June/045357.html>`__ ------------------------------------- Possible itertools additions ------------------------------------- Raymond Hettinger suggested two itertools additions; count_elements and pairswap. The former counts the number of times an item appears in the passed-in iterable and returns pairs of the count and the item. The latter takes an iterable that returns pairs and returns an iterable that returns those pairs swapped. In the end people didn't see the need for pairswap. People did want count_elements, but not as an iterator but as something that returned a dictionary. It was suggested as both a class method of dict and as a new bucket type that could possibly go into the 'collections' module. No final decisions yet, though. Contributing threads: - `Candidate Itertools <http://mail.python.org/pipermail/python-dev/2004-June/045394.html>`__ --------------------------------------------------------- Gettin' PEP 292 ("Simpler String Substitutions") into 2.4 --------------------------------------------------------- Barry Warsaw brought up the point that `PEP 292`_ was slated to go into 2.4 (it's currently in the sandbox). The two biggest questions was the names of the new functions and where to stick them. The name issue was not quite as bad once Barry explained the reasoning behind the existing names. Where to put the code, though, was not so easily dealt with. The original idea (which Barry and I came up with, so I am biased here) was to turn the string module into a package with the new code going there. Barry also pointed out that the code in 'string' that is deprecated and will eventually go away can be moved into an individual module that can just simply be deleted from the package later and then dismissed with the removal of a single ``import *`` line in __init__.py for the package. Not everyone saw the utopia Barry and I were trying to build. People suggested just not bothering with turning 'string' into a package. Still others suggested a new package altogether; 'stringlib' and 'text' were suggested names. It's still not resolved. .. _PEP 292: http://www.python.org/peps/pep-0292.html Contributing threads: - `PEP 292 for Python 2.4 <http://mail.python.org/pipermail/python-dev/2004-June/045406.html>`__ ------------------------------------------------------------------------- Having u.encode() return something other than strings ------------------------------------------------------------------------- Currently unicode.encode() returns only strings. M-A Lemburg wanted to lift this restriction. Guido pointed out that this could possibly cause problems for type inferencing since the return type would vary based on an argument (which made me happy since my masters thesis ties into this stuff). A compromise was reached where the method will only return 8-bit or Unicode strings; basically only subtypes of basestring. Contributing threads: - `Allowing u.encode() to return non-strings <http://mail.python.org/pipermail/python-dev/2004-June/045417.html>`__ -------------------------------------------------- Comparing floats and longs is a pain -------------------------------------------------- Basically this all boiled down to this (quoted from Michael Chermside): "when comparing a long with a float where the exponent is larger than the precision, that the float should be treated as if it were EXACTLY EQUAL TO <coefficient>*2^<exponent>, instead of trying to treat it as some sort of a range." Guido said he would like to see this in 2.4 if someone would write up the code and commit it. Contributing threads: - `Comparing heterogeneous types <http://mail.python.org/pipermail/python-dev/2004-June/045460.html>`__ ---------------------------------------------------------- German and Turkish docstrings from pydoc ---------------------------------------------------------- Martin v. Loewis is currently trying to figure out where to put partial translations of docstrings in the stdlib for pydoc to use as appropriate. Contributing threads: - `Including translated doc strings in 2.4 <http://mail.python.org/pipermail/python-dev/2004-June/045490.html>`__ ------------------------------------------------------------------------------------------- What to do when 'raise' is called after the last exception was caught ------------------------------------------------------------------------------------------- What should happen if you call 'raise' when you already caught the last exception that was raised? People debated what the official docs said. Seemed to coalesce to be what ever the last exception was; caught or not. This ties into being what exception was currently stored. Contributing threads: - `Re-raise in absence of an "active" exception <http://mail.python.org/pipermail/python-dev/2004-June/045497.html>`__ --------------------------------------------------------------------- Can you help with cleaning up the Demo directory? --------------------------------------------------------------------- The Demo directory is in need of some TLC. A bunch of modules in there are out of date and could use an update to current Python abilities. If you care to help by submitting patches to update the code that would be great. There is a large swath of code in there varying from extremely simple to involved so if the mood ever strikes you there will be something for everyone. And if you attend the next Python Bug Day you can also work on it then. Contributing threads: - `What can we do about dealing with the Demo directory? <http://mail.python.org/pipermail/python-dev/2004-June/045654.html>`__ -------------------------------------------------------------------- No more expected test failures on Windows for 2.4 -------------------------------------------------------------------- The bsddb tests are now expected to pass on Windows. What this means is that failures are no longer the norm on Windows for the Python regression testing suite. Contributing threads: - `Joy in Berkeley Windowsland <http://mail.python.org/pipermail/python-dev/2004-June/045669.html>`__ ------------------------------------------------------ Getting accessible local dicts per thread ------------------------------------------------------ Jim Fulton wanted to expose the pre-thread local dict . He has an implementation going that he is going to play with and work the kinks out of. After that the code will most likely be committed. Contributing threads: - `Proposal: thread.get_dict <http://mail.python.org/pipermail/python-dev/2004-June/045681.html>`__ -------------------------------- Where to stick SHA-256 -------------------------------- Someone contributed a patch for adding SHA-256 support. A discussion built up over where to put it, if at all. It's still going on at this moment. Most people seem to agree that if it is included, it should either just be another function in the sha module or that sha.sha() should accept an optional argument specifying how many bits to use for the hash. Contributing threads: - `SHA-256 module <http://mail.python.org/pipermail/python-dev/2004-June/045724.html>`__ ------------------------------------------ Making weakrefs subclassable ------------------------------------------ Fred Drake has a patch to add the ability to subclass weakrefs. He wasn't sure if there would be a performance penalty though. But Tim Peters stepped up and said there wouldn't be. So it looks like it should go in shortly. Contributing threads: - `making weakref.ref objects subclassable <http://mail.python.org/pipermail/python-dev/2004-June/045787.html>`__

1 0

IMDbPY 1.3 released
by alberanid＠libero.it July 6, 2004

July 6, 2004

IMDbPY 1.3 is available here: http://imdbpy.sourceforge.net/ IMDbPY is a Python package useful to retrieve and manage the data of the IMDb movie database. In this release, minor changes were introduced to stay up-to-date with the IMDb's web site. The test suite was moved outside the tgz package. IMDbPY aims to provide an easy way to access the IMDb's database using a Python script. Platform-independent and written in pure Python, it's theoretically independent from the data source (since IMDb provides two or three different interfaces to their database). IMDbPY is mainly intended for programmers and developers who want to build their Python programs using the IMDbPY package, but some example scripts - useful for simple users - are included. So far the only data source supported is the IMDb web server. -- Davide Alberani <alberanid(a)libero.it> [PGP KeyID: 0x465BFD47] http://erlug.linux.it/~da/

1 0

Python Bug Day this Saturday
by A.M. Kuchling July 6, 2004

July 6, 2004

The second Python Bug Day is coming soon: Saturday, July 10, 2004. What's a bug day? ================= Participants meet in an IRC channel and collaboratively go through the Python bug database, fixing and closing bugs as they go. It's a good way to contribute to Python and learn about the source code, helps the developers by reducing the backlog of bugs, and makes Python 2.4 a better release. When? ===== This Saturday, July 10, 2004, from 9AM to 9PM EDT (1PM to 1AM GMT). Where? ====== The #python-dev channel on irc.freenode.net. More information ================ For instructions and more information, see http://www.python.org/cgi-bin/moinmoin/PythonBugDay --amk

1 0

The new mail system is up
by Barry Warsaw July 6, 2004

July 6, 2004

Your friendly neighborhood volunteer postmasters have completed the migration of the python.org mail system to the new machine donated by XS4ALL. We'll be watching and tweaking the system over the next few days, but so far, everything looks pretty good. Of course, if you notice any problems, contact us at postmaster(a)python.org. Huge thanks go to Thomas Wouters, Brad Knowles, Neil Schemenauer, and Skip Montanaro for staying up late with me tonight. :) -Barry

1 0