Mailman 3 November 2002 - Python-announce-list

[Module] lovins/1.0
by Danny Yoo 20 Nov '02

20 Nov '02

lovins/1.0 ---------- Lovins stemmer extension module A thin wrapper around Linh Huynh's Lovins Stemmer implementation. URL: http://hkn.eecs.berkeley.edu/~dyoo/python/py_lovins/ Download: http://hkn.eecs.berkeley.edu/~dyoo/python/py_lovins/lovins-1.0.tar.gz License: GPL Categories: Parsing/Formatting Danny Yoo (dyoo(a)hkn.eecs.berkeley.edu) http://hkn.eecs.berkeley.edu/~dyoo -- <a href="http://hkn.eecs.berkeley.edu/~dyoo/python/py_lovins/">lovins/1.0</a> -- Lovins stemmer extension module

1 0

Pyme -- Python OO interface to GPGME
by John Goerzen 20 Nov '02

20 Nov '02

Hello, Today I am announcing the first release of Pyme, the brand-new Python bindings for GPGME. Pyme: * Provides a convenient class-based interface to GPGME functions; * Exists and is supported; * Supports most GPGME functions automatically by reflection; thus, no code changes will be necessary to support most new GPGME features * Supports callbacks written in Python. * Features easy installation: python setup.py build; python setup.py install * Provides pre-built .debs for Debian GNU/Linux users. You may obtain Pyme at http://quux.org/devel/pyme License: GPL The following is from the Pyme documentation: Welcome to PyME, the GPGME Interface for Python. "Pyme", when prounced, rhymes with "Pine". The latest release of this package may be obtained from http://quux.org/devel/pyme/ FEATURES -------- * Feature-rich, full implementation of the GPGME library. Supports all GPGME features except interactive editing (coming soon). Callback functions may be written in pure Python. * Ability to sign, encrypt, decrypt, and verify data. * Ability to list keys, export and import keys, and manage the keyring. * Fully object-oriented with convenient classes and modules. GENERAL OVERVIEW ---------------- For those of you familiar with GPGME, you will be right at home here. Pyme is, for the most part, a direct interface to the C GPGME library. However, it is re-packaged in a more Pythonic way -- object-oriented with classes and modules. Take a look at the classes defined here -- they correspond directly to certain object types in GPGME for C. For instance, the following C code: GpgmeCtx context; GpgmeRecipients recp; gpgme_new(&context); gpgme_recipients_new(&recp); ... gpgme_op_encrypt(context, recp, plain, cipher); Translates into the following Python code: context = core.Context() recp = core.Recipients() ... context.encrypt(recp, plain, cipher) The Python module automatically does error-checking and raises Python exceptions when GPGME signals an error. Those exceptions correspond directly to GPGME errors. All GPGME exceptions are defined in the gpgme.errors module, and pyme.errors.GPGMEError is the parent of all exceptions. IMPORTANT NOTE -------------- This documentation only covers a small subset of available GPGME functions and methods. Please consult the documentation for the C library (available in doc/gpgme in this distribution) for comprehensive coverage. This library uses Python's reflection to automatically detect the methods that are available for each class, and as such, most of those methods do not appear explicitly anywhere. QUICK START SAMPLE PROGRAM -------------------------- This program is not for serious encryption, but for example purposes only! import sys from pyme import core, constants import pyme.constants.validity # Set up our input and output buffers. plain = core.Data('This is my message.') cipher = core.Data() # Initialize our context. c = core.Context() c.set_armor(1) # Set up the recipients. sys.stdout.write("Enter name of your recipient: ") name = sys.stdin.readline().strip() r = core.Recipients() r.add(name, constants.validity.FULL) # Do the encryption. c.op_encrypt(r, plain, cipher) print cipher.read() Note that although there is no explicit error checking done here, the Python GPGME library is automatically doing error-checking, and will raise an exception if there is any problem. This program is in the Pyme distribution as examples/simple.py. The examples directory contains more advanced samples as well. FOR MORE INFORMATION -------------------- PYME homepage: http://quux.org/devel/pyme GPGME documentation: http://www.fifi.org/cgi-bin/info2www?%28gpgme%29 GPGME homepage: http://www.gnupg.org/gpgme.html Base classes: pyme.core (START HERE!) Auxiliary classes: pyme.aux Utilities: pyme.util Error classes: pyme.errors Constants: pyme.constants Version information: pyme.version Base classes are documented at pyme.core and auxiliary classes at pyme.aux <P><A HREF="http://quux.org/devel/pyme">Pyme 0.5.0</A> -- OO Python interface to GnuPG. (20-Nov-02)

1 0

csv module 1.0 released
by Dave Cole 20 Nov '02

20 Nov '02

WHAT IS IT: The CSV module provides a fast CSV parser which can split and join CSV records which have been produced by Microsoft products such as Access and Excel. The module is available here: http://www.object-craft.com.au/projects/csv/download/csv-1.0.tar.gz The module home page is here: http://www.object-craft.com.au/projects/csv/ NOTES: The most important change for this release is that the basic quote handling has been modified to exactly match the observed behaviour of Excel. A comprehensive test suite has been added to test this observed behaviour. If the module does not conform to Excel behaviour we consider this to be a bug. No problems were reported with the 1.0pre1 release. This release makes the 1.0pre1 release official. CHANGES SINCE 0.5: * Moved to standard BSD template license. * Now using distutils to create source distribution. * Parser's handling of unusual quoting styles was found to be at odds with Excel. In particular, Excel only treats the quote character as special if it appears as the first character in a field, whereas our parser honoured them anywhere. We now produce the same result as Excel - quotes within a field appear in the output. * Introduced Parser.quote_char attribute to replace the hard coded " (double quote). You can now disable quoting by setting quote_char to 0 or None. * Introduced Parser.escape_char attribute which is used to escape special characters when quote_char is specified is disabled. * Introduced Parser.strict attribute which controls whether the parser will raise an exception on malformed fields rather than attempting to guess the right behaviour. * Introduced a suite of unit tests. -- http://www.object-craft.com.au

1 0

Sybase module 0.35 released
by Dave Cole 20 Nov '02

20 Nov '02

WHAT IS IT: The Sybase module provides a Python interface to the Sybase relational database system. It supports all of the Python Database API, version 2.0 with extensions. NOTES: In this release the module uses callback instead of inline error handling from the Sybase CT library. This has caused quite extensive changes to the threading support inside the low level extension module. One of the nice side effects of using callback error handling is that server errors while executing stored procedures will now be reported correctly. FreeTDS support is much improved in this version. You can build for FreeTDS like this: python setup.py build_ext -D HAVE_FREETDS -U WANT_BULKCOPY python setup.py install The module is available here: http://www.object-craft.com.au/projects/sybase/download/sybase-0.35.tar.gz The module home page is here: http://www.object-craft.com.au/projects/sybase/ CHANGES SINCE 0.35pre3: No problems were reported with the 0.35pre3 release so the changes are minimal. * sybasect extension module now includes a __version__ string. -- http://www.object-craft.com.au

1 0

Strip-o-Gram 1.2 Released!
by Chris Withers 19 Nov '02

19 Nov '02

Strip-o-Gram is an HTML Conversion Library implemented as a Python package that can convert HTML to Plain Text and strip specified tags and Javascript from HTML. See http://www.zope.org/Members/chrisw/StripOGram for more details. This release includes more documentation and allows the methods to be used from Zope's Script (Python)'s. cheers, Chris

1 0

[ANN] PyTables release 0.2
by Francesc Alted 19 Nov '02

19 Nov '02

Announcing PyTables 0.2 ----------------------- What's new ----------- - Numerical Python arrays supported! - Much improved documentation - Programming API almost stable - Improved navegability across the object tree - Added more unit tests (there are almost 50) - Dropped HDF5_HL dependency (a tailored version is included in sources now) - License changed from LGPL to BSD What is ------- The goal of PyTables is to enable the end user to manipulate easily scientific data tables and Numerical Python objects (new in 0.2!) in a persistent hierarchical structure. The foundation of the underlying hierachical data organization is the excellent HDF5 library (http://hdf.ncsa.uiuc.edu/HDF5). Right now, PyTables provides limited support of all the HDF5 functions, but I hope to add the more interesting ones (for PyTables needs) in the near future. Nonetheless, this package is not intended to serve as a complete wrapper for the entire HDF5 API. A table is defined as a collection of records whose values are stored in fixed-length fields. All records have the same structure and all values in each field have the same data type. The terms "fixed-length" and strict "data types" seems to be quite a strange requirement for an interpreted language like Python, but they serve a useful function if the goal is to save very large quantities of data (such as is generated by many scientifc applications, for example) in an efficient manner that reduces demand on CPU time and I/O. In order to emulate records (C structs in HDF5) in Python, PyTables implements a special metaclass that detects errors in field assignments as well as range overflows. PyTables also provides a powerful interface to process table data. Quite a bit effort has been invested to make browsing the hierarchical data structure a pleasant experience. PyTables implements just three (orthogonal) easy-to-use methods for browsing. What is HDF5? ------------- For those people who know nothing about HDF5, it is is a general purpose library and file format for storing scientific data made at NCSA. HDF5 can store two primary objects: datasets and groups. A dataset is essentially a multidimensional array of data elements, and a group is a structure for organizing objects in an HDF5 file. Using these two basic constructs, one can create and store almost any kind of scientific data structure, such as images, arrays of vectors, and structured and unstructured grids. You can also mix and match them in HDF5 files according to your needs. How fast is it? --------------- Despite to be an alpha version and that there is lot of room for improvements (it's still CPU bounded!), PyTables can read and write tables quite fast. But, if you want some (very preliminary) figures (just to know orders of magnitude), in a AMD Athlon@900 it can currently read from 40000 up to 60000 records/s and write from 5000 up to 13000 records/s. Raw data speed in read mode ranges from 1 MB/s up to 2 MB/s, and it drops to the 200 KB/s - 600 KB/s range for writes. Go to http://pytables.sf.net/bench.html for a somewhat more detailed description of this small (and synthetic) benchmark. Anyway, this is only the beginning (premature optimization is the root of all evils, you know ;-). Platforms --------- I'm using Linux as the main development platform, but PyTables should be easy to compile/install on other UNIX machines. Thanks to Scott Prater, this package has passed all the tests on a UltraSparc platform with Solaris 7. It also compiles and passes all the tests on a SGI Origin2000 with MIPS R12000 processors and running IRIX 6.5. If you are using Windows and you get the library to work, please let me know. An example? ----------- At the bottom of this message there is some code (less that 100 lines and only less than half being real code) that shows basic capabilities of PyTables. Web site -------- Go to the PyTables web site for more details: http://pytables.sf.net/ Final note ---------- This is second alpha release, and probably last alpha, so it is still time if you want to suggest some API addition/change or addition/change of any useful missing capability. Let me know of any bugs, suggestions, gripes, kudos, etc. you may have. -- Francesc Alted falted(a)openlc.org *-*-*-**-*-*-**-*-*-**-*-*- Small code example *-*-*-**-*-*-**-*-*-**-*-*-* """Small but almost complete example showing the PyTables mode of use. As a result of execution, a 'tutorial1.h5' file is created. You can look at it with whatever HDF5 generic utility, like h5ls, h5dump or h5view. """ import sys from Numeric import * from tables import * #'-**-**-**-**-**-**- user record definition -**-**-**-**-**-**-**-' # Define a user record to characterize some kind of particles class Particle(IsRecord): name = '16s' # 16-character String idnumber = 'Q' # unsigned long long (i.e. 64-bit integer) TDCcount = 'B' # unsigned byte ADCcount = 'H' # unsigned short integer grid_i = 'i' # integer grid_j = 'i' # integer pressure = 'f' # float (single-precision) energy = 'd' # double (double-precision) print print '-**-**-**-**-**-**- file creation -**-**-**-**-**-**-**-' # The name of our HDF5 filename filename = "tutorial1.h5" print "Creating file:", filename # Open a file in "w"rite mode h5file = openFile(filename, mode = "w", title = "Test file") print print '-**-**-**-**-**-**- group an table creation -**-**-**-**-**-**-**-' # Create a new group under "/" (root) group = h5file.createGroup("/", 'detector', 'Detector information') print "Group '/detector' created" # Create one table on it table = h5file.createTable(group, 'readout', Particle(), "Readout example") print "Table '/detector/readout' created" # Get a shortcut to the record object in table particle = table.record # Fill the table with 10 particles for i in xrange(10): # First, assign the values to the Particle record particle.name = 'Particle: %6d' % (i) particle.TDCcount = i % 256 particle.ADCcount = (i * 256) % (1 << 16) particle.grid_i = i particle.grid_j = 10 - i particle.pressure = float(i*i) particle.energy = float(particle.pressure ** 4) particle.idnumber = i * (2 ** 34) # This exceeds long integer range # Insert a new particle record table.appendAsRecord(particle) # Flush the buffers for table table.flush() print print '-**-**-**-**-**-**- table data reading & selection -**-**-**-**-**-' # Read actual data from table. We are interested in collecting pressure values # on entries where TDCcount field is greater than 3 and pressure less than 50 pressure = [ x.pressure for x in table.readAsRecords() if x.TDCcount > 3 and x.pressure < 50 ] print "Last record read:" print x print "Field pressure elements satisfying the cuts ==>", pressure # Read also the names with the same cuts names = [ x.name for x in table.readAsRecords() if x.TDCcount > 3 and x.pressure < 50 ] print print '-**-**-**-**-**-**- array object creation -**-**-**-**-**-**-**-' print "Creating a new group called '/columns' to hold new arrays" gcolumns = h5file.createGroup(h5file.root, "columns", "Pressure and Name") print "Creating a Numeric array called 'pressure' under '/columns' group" h5file.createArray(gcolumns, 'pressure', array(pressure), "Pressure column selection") print "Creating another Numeric array called 'name' under '/columns' group" h5file.createArray('/columns', 'name', array(names), "Name column selection") # Close the file h5file.close() print "File '"+filename+"' created"

1 0

RELEASE: ClientCookie 0.2.0b
by jjl＠pobox.com 19 Nov '02

19 Nov '02

ClientCookie 0.2.0b This is a beta release (will be some time before I consider it stable, but it's certainly quite useable as it is). http://wwwsearch.sourceforge.net/ClientCookie/ Changes since the last release (0.1.2b): * Improved documentation. * Changed license to MIT (from Perl Artistic). Thanks, Gisle. [MIT license essentially says: don't sue me.] * Removed cookies argument from urlopen, and added install_opener function. This is the way urllib2 does things, and is also simpler. This won't change again, honest! The documentation on this is also much better now. * Removed _TimeLocal.py. :-) ClientCookie is a Python module for handling HTTP cookies on the client side, useful for accessing web sites that require cookies to be set, and returned later. It is a port of Gisle Aas' Perl module HTTP::Cookies, from the libwww-perl library. import ClientCookie response = ClientCookie.urlopen("http://foo.bar.com/") This function behaves identically to urllib2.urlopen, except that it deals with cookies automatically. That's probably all you need to know. Python 1.5.2 or above is required. Plans for the next few releases: non-eager response objects, while retaining the seek method; HTTP-EQUIV and Refresh handling, via a new OpenerDirector and Handler class(es). John

1 0

RELEASE: ClientForm 0.0.4b
by jjl＠pobox.com 19 Nov '02

19 Nov '02

ClientForm 0.0.4b This is a beta release (probably the last before first stable release). http://wwwsearch.sourceforge.net/ClientCookie/ Changes since the last release (0.0.3b): * Changed license to MIT (from Perl Artistic). Thanks, Gisle. [MIT license essentially says: don't sue me.] * Various bug-fixes and documentation improvements. * Internal changes (internal unless you're using your own form parser): Control, ListControl and ScalarControl constructor cleanup, and separation of ListControl into RadioControl, CheckboxControl and SelectControl. * Rather than using the values of the OPTION elements to set SELECT values, SELECT items can also be specified by the labels of the OPTION elements. For example, if you have a SELECT control like so: <SELECT name="cheeses"> <OPTION value="br">Brie</OPTION> <OPTION value="ched">Cheddar</OPTION> <OPTION value="grgnz" label="Gorgonzola">Special offer on Gorgonzola!</OPTION> </SELECT> instead of setting its value like this: form["cheeses"] = ["br", "ched", "grgnz"] you can now optionally use the more readable (and, possibly, more maintainable): control = form.find_control("cheeses") control.set_value_by_label(["Brie", "Cheddar", "Gorgonzola"]) Note that the label HTML attribute defaults to the content of the OPTION element (as does the value HTML attribute). ClientForm is a Python module for handling HTML forms on the client side, useful for parsing HTML forms, filling them in and returning the completed forms to the server. It has developed from a port of Gisle Aas' Perl module HTML::Form, from the libwww-perl library, but the interface is not the same. import ClientForm import urllib2 request = urllib2.Request("http://www.acme.com/form.html") response = urllib2.urlopen(request) forms = ClientForm.ParseResponse(response) form = forms[0] form["cheeses"] = ["parmesan", "leicester", "cheddar"] form.toggle("cheeses", "gorgonzola") form["author"] = "Gisle Aas" request2 = form.click("Thanks") response2 = urllib2.urlopen(request2) print response2.geturl() print response2.info() # headers for line in response2.readlines(): # body print line All of the standard input types are supported: TEXT, PASSWORD, HIDDEN, TEXTAREA, RESET, BUTTON, SUBMIT, IMAGE, RADIO, CHECKBOX and SELECT/OPTION. FILE (for file upload) is not yet supported, but will be in a future version. Python 1.5.2 or above is required. To run the tests, you need the unittest module (from PyUnit). unittest is a standard library module with Python 2.1 and above. John

1 0

Article: RSS for Python
by Uche Ogbuji 19 Nov '02

19 Nov '02

http://www-106.ibm.com/developerworks/webservices/library/ws-pyth11.html RSS is one of the most successful XML services ever. Despite its chaotic roots, it has become the community standard for exchanging content information across Web sites. Python is an excellent tool for RSS processing, and Mike Olson and Uche Ogbuji introduce a couple of modules available for this purpose. -- Uche Ogbuji Fourthought, Inc. http://uche.ogbuji.net http://4Suite.org http://fourthought.com Python&XML column: 2. Introducing PyXML - http://www.xml.com/pub/a/2002/09/25/py.html The Past, Present and Future of Web Services 1 - http://www.webservices.org/index.php/article/articleview/663/1/24/ The Past, Present and Future of Web Services 2 - 'http://www.webservices.org/index.php/article/articleview/679/1/24/ Serenity through markup - http://adtmag.com/article.asp?id=6807 Tip: Using generators for XML processing - http://www-106.ibm.com/developerworks/xml/library/x-tipgenr.html

1 0

python-dev Summary, 2002-11-01 through 2002-11-15
by drifty＠bigfoot.com 18 Nov '02

18 Nov '02

================================================== python-dev Summary, 2002-11-01 through 2002-11-15 ================================================== This is a summary of traffic on the `python-dev mailing list`_ between November 1, 2002 and November 15, 2002 (inclusive). It is intended to inform the wider Python community of on-going developments on the list that might interest the wider Python community. To comment on anything mentioned here, just post to python-list(a)python.org or comp.lang.python in the usual way; give your posting a meaningful subject line, and if it's about a PEP, include the PEP number (e.g. Subject: PEP 201 - Lockstep iteration). All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join python-dev! This is the fifth summary written by Brett Cannon (after a relaxing two week hiatus; thanks to Raymond Hettinger for doing the Summary while I was gone). All summaries are now archived at http://www.python.org/dev/summary/ (thanks to A.M. Kuchling for setting that up). 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_; you can safely ignore it (although I suggest learning reST; its simple and is accepted for PEP markup). Also, because of the wonders of programs that like to reformat, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is. If you want to do that, get an original copy of the text file. .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html ====================== Summary Announcements ====================== Not much to say for this summary. The only thread skipped that someone out there might care about was one on getting the PEPs to display properly for IE 6 when the PEP was written in reST_. Thanks goes to Raymond Hettinger for covering the Summary while I was away on vacation. Thanks also goes out to Laura Creighton and Guido for suggesting graduate schools that are Python-friendly. Michael Chermside was the only person to respond directly to my question as to whether anyone had issue with me injecting my personality into the summary. But he said to go ahead and let me personality permeate throughout this thing, so it will. Let that be a lesson to anyone who wanted me to shut up and be drab; had you and a friend spoken up this little tirade would not be happening. =) ================================= `Getting python-bz2 into 2.3`__ ================================= __ http://mail.python.org/pipermail/python-dev/2002-November/029830.html Continuation of http://mail.python.org/pipermail/python-dev/2002-October/029829.html Gustavo Niemeyer asked how he should go about getting his python-bz2_ module into the standard library. He was basically told to submit a patch complete with the module, docs, regression tests, etc.; everything a healthy module needs. It was also suggested that he provide a MSVC project file. That didn't work for Gustavo (who now has CVS write priveleges; congrats) since he doesn't use Windows. This was a slight problem because if the extension file doesn't build under Windows it can't be included in the PythonLabs Windows distro. So keep in mind that if your module won't directly compile for 6 different versions of Windows it won't be included in the Windows distro. .. _python-bz2: http://python-bz2.sourceforge.net/ =================================== `Becoming a python contributor`__ =================================== __ http://mail.python.org/pipermail/python-dev/2002-November/029831.html Continuation of http://mail.python.org/pipermail/python-dev/2002-October/029828.html Gustavo Niemeyer asked about how he could help contribute to Python. He made the observation that "Guido and others [have been] bothered a few times because of the lack of man power" which has led to a "small core of very busy developers working on core/essential/hard stuff *and* in code reviewing as well" (and I can attest to this fact that this is very true; I am amazed the guys at PythonLabs have any form of a life outside of work with the amount of time they put in). Gustavo felt "that the Python development is currently overly centralized". Martin v. Loewis responded first. He said that "the most important aspect I'd like to hand off is the review of patches; to Tim, it is the analysis of bug reports". Martin then listed various points on how to be able to review a patch and how to handle bug reports; the email is at http://mail.python.org/pipermail/python-dev/2002-November/029831.html . I *highly* recommend reading the email because Martin's points are all good and more patch reviewers would be rather nice. M.A. Lemburg commented next, saying that he "wouldn't mind if other developers with some time at hand jump in on already assigned patches and bug reports to help out". Just because a patch has been assigned to someone doesn't mean the patch or the assignee couldn't use more help. Having the patch assigned to someone just means that they take responsibility to apply the patch if it is worthy of being accepted or to reject it. It should not stop other people from making comments or helping out so that the assignee can have a little bit of time saved for other things... like another patch to assign to themselves. MAL also suggested that we have more maintainers that are in charge of chunks of code, e.g. Martin handles all locale code. Martin disagreed with this idea, though. Jack Jansen agreed with Martin. He thought that if something came up that was not within the realm of a specific person that it "either get[s] ignored, or passed on to Guido, or picked up by yourself or Michael [Hudson] or one of the very few other people who do general firefighting". Martin commented later that he would hope that the stewardship of specific code does not get any more formal. Martin then stated how one goes about getting commit priveleges for Python on SF: "just step forward and say that you want. In the past, Guido has set a policy that people who's commit privilege is fresh will still have to use SF, but can perform the checkin themselves". Tradition has stated that "fresh" is your first two or three SF patches. But please only step forward if you are known to python-dev or PythonLabs since commit priveleges won't be given to people who just wander in off the proverbial street and ask for it. Martin basically states this in a later email by saying that "people should not produce a burst of patches just to get commit privileges. Instead, they should contribute patches steadily (and should have done so in the past), and then get CVS write access as a simplification for the rest of the maintainers". Neal Norwitz pointed out that if a bug ends up with a fix it is best to submit a separate patch instead of attaching it to the bug report. That way there is a bigger chance of the patch being seen and dealth with. But please make sure to mention that it fixes a bug so that the bug can be closed! Martin even suggested mentioning this fact in the title of the patch submission. ==================== `RoundUp status`__ ==================== __ http://mail.python.org/pipermail/python-dev/2002-November/029879.html This is a splinter thread of the 'Becoming a python contributor' thread in which Micheal Hudson asked how using Roundup_ for replacing SF_ was coming along. Guido said things had come up that was holding it up. One was that the test server running at http://www.python.org:8080 had died when the box was restarted (it is now back up). There were also some changes to Roundup that needed to be dealt with in order to get everything over from SF on to Roundup. Guido also just ran out of time to review it more, although he did like what he had reviewed so far. Guido asked for a volunteer. It was asked what was needed. Guido said that Roundup had moved over to Zope-style templating so all the old templates that Gordon (I assuming this is Gordon McMillan) wrote needed to be changed. There were also some bugs that needed to be dealt with that are being tracked at Roundup hosted at http://www.python.org:8080 . And there also will need to be preparations for the day that development is moved over from SF to the Roundup setup; that will require transferring everything over from SF, shutting down SF, and handling any bugs that crop up from the heavy use that the new setup is going to get. So if you have any dislike for SF, then please contribute to Roundup and help get Python off of there! .. _Roundup: http://roundup.sourceforge.net/ .. _SF: http://www.sf.net/ ======================================= `Contributing...current bug status`__ ======================================= __ http://mail.python.org/pipermail/python-dev/2002-November/029846.html Neal Norwitz went through the SF_ bug tracker and counted 325 bugs and generated a very easy to read page listing all the bugs with their relevant info. You can find the HTML version at http://www.metaslash.com/py/sf.data.html . If you find a bug there you think you can help out on, then go to SF and do so! ======================= `Low hanging fruit`__ ======================= __ http://mail.python.org/pipermail/python-dev/2002-November/029850.html Neal Norwitz generated a list of what he thought were easily fixable bugs and put them in this thread (it's the first email so just go to the link for this thread). So if you have a little bit of free time and want to help out why don't you try to tackle one of these bugs? =============== `Snake farm`__ =============== __ http://mail.python.org/pipermail/python-dev/2002-November/029853.html The only reason I am mentioning this thread here is to help get the word out about the `Snake Farm`_ ; hosted by Lysator_ and sponsored by the `Python Business Forum`_ . It is a compile farm that downloads from CVS, compiles, and runs the test suite of Python daily. It has caught a bunch of bugs and has been a great help. The majority of the thread was spent trying to get FreeBSD 4.4 to compile Python and trying to work out a possible bug in pymalloc. .. _Snake Farm: http://www.lysator.liu.se/~sfarmer/ .. _Lysator: http://www.lysator.liu.se/ .. _Python Business Forum: http://www.python-in-business.org ==================================== `David Goodger joins PEP editor`__ ==================================== __ http://mail.python.org/pipermail/python-dev/2002-November/029866.html David Goodger has somehow gotten suckered into becoming a PEP editor (I suspect Barry Warsaw had something to do with this since he used to do all of the PEP editing). So you can all welcome David to his new responsibility by flooding him with all of those PEPs you have lying around and were not sure were good enough to submit. =) ======================== `metaclass insanity`__ ======================== __ http://mail.python.org/pipermail/python-dev/2002-November/029872.html Continuation of http://mail.python.org/pipermail/python-dev/2002-October/029795.html Michael Hudson posted the question as to how to get writing ``__bases__`` for new-style classes to do the "right thing" since the mro does not seem to be updated. Kevin Jacob gave it a go but ran into a bug. Guido said that currently there is no way to touch the MRO from Python code. All of that info is stored in the tp_mro slot in the object's C representation and is stored as a tuple whose members are expected to be either types or classic classes. Guido said he would accept a patch for assigning to the mro if a check was included to make sure the previously mentioned constraint was maintained. He also said he would probably accept a patch that allowed for assignable ``__bases__`` and writing ``__name__`` . Michael Hudson commented about the difficulty of all of these patches. One thing that came up was the connection between ``__bases__`` and ``__base__`` and how assignment to ``__base__`` should not be taken lightly; Guido commented that "the old and new base must be layout compatible, exactly like for assignment to __class__". Guido later pointed out that ``__base__`` becomes the built-in type that you derive from; whether it be object, list, dict, etc. It was agreed that ``__base__`` shouldn't be writable. The point was made that nestable classes are not picklable since only thing at the top level of a module can be pickled. Guido said he considered this a flaw although he couldn't think of why someone would want to embed a class within a class or a function. This spawned comments on how to deal with this. It seemed the best solution was to change ``__name__`` for the inner class to a fully dotted name (e.g. ``X.Y.__name__ = "X.Y"``) and then make a simple change to either ``pickle`` or ``getattr()``. It was eventually agreed upon that setting ``__name__`` to the full dotted name of the class was the best solution and it was filed as `bug #633930`_ . As part of trying to give Guido good examples of why nested classes are good (the best attempt was Walter Dorwald in an email at http://mail.python.org/pipermail/python-dev/2002-November/029906.html that elicited a "that's cool" comment from Guido), the idea of having ``__iter__`` contain a class definition that returned an instance of that class came up. That was shot down because of the performance hit of dealing with the class definition on every call to ``__iter__``. But the idea of defining ``__iter__`` as a generator was pointed out by Just van Rossum. Doing that simplifies the code usually a good amount since the generator handles all ``.next()`` calls and you just need to have the generator stop when you want your iterator to stop. Apparently this is not a widely used idiom, so I am mentioning it here since it is a great idea that I can personally attest to as being a rather nice way to handle iterators. .. _bug #633930: http://www.python.org/sf/633930 ============================ `[#527371] sre bug/patch`__ ============================ __ http://mail.python.org/pipermail/python-dev/2002-November/029936.html I am mentioning this thread not because the bug is that big of a deal, but because of the PEP that was brought up when dealing with the bug; `PEP 291`_ . This informational PEP, among other things, lists modules that must be kept compatible with certain versions of Python; in this case sre has to be kept compatible with Python 1.5.2. Except for sre, they are all packages that have made their way into the library. You might want to have a look at the list if you are hacking on any packages in the stdlib. .. _PEP 291: http://www.python.org/peps/pep-0291.html ====================================================================== `Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]`__ ====================================================================== __ http://mail.python.org/pipermail/python-dev/2002-November/029941.html Once again this is not to meant to mention directly what as discussed in the thread but a point made. The bug that was discovered was an issue with 64-bit machines and the 32-bit limitation of lists and slicing. The 32-bit limit currently is hard-coded into the C code. Obviously some people would like to see this changed. Neal Norwitz laid down a rough outline on how one could go about changing this at http://mail.python.org/pipermail/python-dev/2002-November/029953.html . Guido then made a pronouncement later stating that he is willing to break binary compatibility once for Python 2.3 or 2.4 to get this done. He also mentioned some other things to make sure to do. As of this writing no one has stepped forward to take this on. ============================== `Reindenting unicodedata.c`__ ============================== __ http://mail.python.org/pipermail/python-dev/2002-November/029997.html While doing some work on `Modules/unicodedata.c`_ , Martin v. Loewis noticed that the indentation style didn't follow `PEP 7`_ and he wondered if it would be okay to re-indent the file. This brought up two points. One was that PEP 7 was not stringently followed. The PEP says to "Use single-tab indents, where a tab is worth 8 spaces". Now that goes against Python coding style where you are supposed to use 4-space indents. So the question of whether one should still use the tab style in new C code came up. Guido said he wished new C code would, but for files he doesn't touch very often he doesn't feel he can enforce it. Barry and Martin came up with an Emacs "local variables" stanza for the bottom of any file that uses a non-PEP style which can be found at http://mail.python.org/pipermail/python-dev/2002-November/030067.html . But following the PEP is still the "officially" supported style. But you should try to follow PEP 7 for all new C code and PEP 8 for Python code. The other point was when to re-indent. It was agreed upon to only do that when a major change in the code was occuring. And when you do re-indent, do it as a separate check-in for CVS. .. _Modules/unicodedata.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Modul… .. _PEP 7: http://www.python.org/peps/pep-0007.html ============================= `Printing and __unicode__`__ ============================= __ http://mail.python.org/pipermail/python-dev/2002-November/030098.html Martin v. Loewis brought up a point made by Henry Thompson on c.l.py asking why printing ignores ``__unicode__``. Martin thought it shouldn't and listed a bunch of options on how to make printing work with ``__unicode__``. The winner was to have "A file indicates "unicode-awareness" somehow. For a Unicode-aware file, it tries ``__unicode__``, ``__str__``, and ``__repr__``, in order". The agreed solution was to add an ``.encoding`` attribute. This attribute can be set to None when the stream is in Unicode and never converts to a byte-stream. But then M.A. Lemburg chimed in. He was fine with the addition of the ``.encoding``; "this attribute is already available on stream objects created with codecs.open()". What he didn't like was having ``.encoding`` set to None mean the stream would accept Unicode. Martin asked then if ``StringIO`` should have ``.encoding``. MAL replied that "``StringIO`` should be considered a non-Unicode aware stream, so it should not implement .encoding". He thought that if someone wanted ``StringIO`` to be Unicode-aware they could use "the tools in codecs.py [since they] can be used for this (basically by doing the same kind of wrapping as ``codecs.open()`` does)". But then Martin pointed out that StringIO is already Unicode-aware. This debate continued between MAL, Martin, and Guido. But then Guido just said he gave up since the current behavior was relied upon too much. =================== `Adopting Optik`__ =================== __ http://mail.python.org/pipermail/python-dev/2002-November/030108.html Splinter threads: - `Re: [getopt-sig] Adopting Optik <http://mail.python.org/pipermail/python-dev/2002-November/030154.html>`__ - `Re: Adopting Optik <http://mail.python.org/pipermail/python-dev/2002-November/030189.html>`__ - `Fw: [Python-Dev] Adopting Optik <http://mail.python.org/pipermail/python-dev/2002-November/030165.html>`__ - `[getopt-sig] Re: [Python-Dev] Adopting Optik <http://mail.python.org/pipermail/python-dev/2002-November/030179.html>`__ Guido sent an email saying that he would like to get Python 2.3a out the door by X-mas. This means trying to come up with a new name for Optik_ , Greg Ward's command-line options parser. The complaint about the current name is that it's too cute. Guido started it by suggesting the name ``options``. Peter Funk brought up two things. One was that Docutils already used the module under its Optik name. To this Guido responded that they could just change the name in the code. Peter also said that Greg liked ``OptionsParser``. There was also the point that module names are preferred to be short and lowercase. Ka-Ping Yee and myself brought up the point that ``options`` is very generic. Guido agreed with this point while also mentioning that many people already have their own modules named options.py. He then suggested ``optlib`` since "It's short, un-cute, and follows the \*lib pattern used all over the Python stdlib". Greg Ward liked this suggestion. I personally suggested ``ArgParser``, trying to get a tie-in for sys.argv. Greg Ewing built off of this and suggested ``argvparse``, similar to ``urlparse``. David Ascher preferred ``argparse`` since "The v is archaic and so silent it fades away =)". David Abrahams disagreed, stating how the "v" deals with any ambiguity. David Abrahams also said he would vote for ``argvparse`` to break a tie. Ka-Ping Yee suggested ``cmdline`` and ``cmdopts``. David Abrahams liked both. Steve Holden built off of Guido's ``optlib`` and pushed for ``optionlib``. Raymond Hettinger threw ``OptionParser`` into the ring. But then Guido asked for a call to votes between ``optlib`` and ``argvparse``. I tallied the votes at one point with it kind of split between them. Then Guido announced that ``optparse`` won (and no, that is not a typo). .. _Optik: http://optik.sf.net/ =========================== `Killing off bdist_dumb`__ =========================== __ http://mail.python.org/pipermail/python-dev/2002-November/030139.html Splinter threads: - `RE: [Distutils] Killing off bdist_dumb <http://mail.python.org/pipermail/python-dev/2002-November/030153.html>`__ - `E: [Distutils] Killing off bdist_dumb <http://mail.python.org/pipermail/python-dev/2002-November/030219.html>`__ A.M. Kuchling asked if anyone would mind if bdist_dumb was removed from distutils (the conversation also happened with `distutils-sig`_ ). Apparently it is rather broken in terms of the paths of the files because it makes them all relative. M.A. Lemburg, though, spoke up stating that he uses bdist_dumb. It still wasn't fully resolved as of this writing. The point of being able to build bdist_wininst on non-Windows platforms came up during this discussion as well. It was decided to move the binary files needed for bdist_wininst into CVS (now filed as `bug #638595`_ ). .. _distutils-sig: http://www.python.org/sigs/distutils-sig/ .. _bug #638595: http://www.python.org/sf/638595 =============================================== `Python interface to attribute descriptors`__ =============================================== __ http://mail.python.org/pipermail/python-dev/2002-November/030118.html Splinter threads: - `Python interface to attribute descriptors <http://mail.python.org/pipermail/python-dev/2002-November/030213.html>`__ Paul Dubois decided to cause himself some grief and attempt to comprehend the miracle that is descriptors (more info can be found in the `2.2.2 What's New`_ doc and in `PEP 252`_). He was wondering if there was more documentation than the signatures of the functions for the C API. He also wanted to know if there was a way to play with them in the Python world since all of his attempts fell short of them being "first-class citizen from Python". Guido admitted that the docs were lacking. He then asked for some help in writing the docs. He responded to Paul's second question by saying that he thought it should work as long as you avoided classic classes. Thanks to Guido saying that is should work, Paul realized that he misread the PEP. To be nice he emailed out an example of how a descriptor could know where it came from at http://mail.python.org/pipermail/python-dev/2002-November/030141.html . Phillip Ebey also chimed in on how to write a metaclass that said the name of the descriptor at http://mail.python.org/pipermail/python-dev/2002-November/030213.html . .. _2.2.2 What's New: http://www.python.org/doc/2.2.2/whatsnew/sect-rellinks.html#SECTION00032000… .. _PEP 252: http://www.python.org/peps/pep-0252.html ============================== `IDLE local scope cleanup`__ ============================== __ http://mail.python.org/pipermail/python-dev/2002-November/030124.html Patrick O'Brien (author of PyCrust_ ) wondered how IDLE managed to keep its local scope so clean once it finished launching. Guido said that IDLE (or at least the GRPC version which Patrick O'Brien believes stands for Generalized Remote Procedure Call) runs the shell in a subprocess that is careful not to pollute the namespace. Patrick thanked Guido and then presented his real question: how to handle not polluting the namespace with a way getting around a pickling issue. He "used to just pass a regular dictionary to code.InteractiveInterpreter, which worked well enough", but there was an issue with pickling. So then he tried passing ``sys.modules['__main__'].__dict__``, which worked but cluttered the namespace. Guido's response: "Remove the clutter". Guido said that this would most likely require a minimalistic main program that bootstrapped using ``__import__('run').main()`` which would run the code without adding to the namespace. .. _PyCrust: http://www.orbtech.com/wiki/PyCrust

1 0