Mailman 3 May 2003 - Python-announce-list

py2exe 0.3.4 released
by Thomas Heller 09 May '03

09 May '03

After one year of silence I've released py2exe 0.3.4. py2exe is a distutils extension to build Windows executables from python scripts. Not too much has changed: there is now support for including early bound COM code generated by makepy (I'm not sure if this is a good idea), and a binary distribution for the beta Python 2.3 version. http://starship.python.net/crew/theller/py2exe/ Enjoy, Thomas

1 0

ANN: Twisted 1.0.5
by Itamar Shtull-Trauring 08 May '03

08 May '03

Twisted is an event-driven networking framework for server and client applications. More detailed information can be found after the "What's New" section. For more information, visit http://www.twistedmatrix.com, join the list http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python or visit us on #twisted at irc.freenode.net. What's New in 1.0.5 =================== - Twisted requires Python 2.2 and later. Python 2.1 is no longer supported. - TLS on the fly support, i.e. it's possible switch to TLS in the middle of TCP connection. - Component architecture is now closer to Zope3 (Interface to Interface adaptation). - Refactored logging system. - Documentation for the Woven web system. - Bug fixes, documentation improvements and speed enhancements. What is Twisted? ================ Twisted is an event-driven framework for building networked clients and servers. It contains a powerful and simple networking core, a full-featured suite of interoperable protocols, among them a powerful web server and applications framework. Twisted supports many event loops for both server apps and GUI integration on the client side, including: - Win32 events, including GUI support - GTK+ - GTK+ 2 - Qt - wxPython - Tkinter Twisted can run protocols over TCP, SSL, UDP, multicast, Unix sockets and subprocesses. It also includes scheduling support, threading integration, RDBMS event loop integration and other basic requirements for networked applications. Also included are implementations of many protocols. In some cases this includes complete frameworks providing facilities on top of the base protocol: - SSH - IMAP - DNS - FTP - HTTP, including a complete web framework - XML-RPC - SOAP server framework - NNTP and complete NNTP server framework - SOCKSv4 (server only) - SMTP - IRC - telnet - POP3 - AOL's instant messaging TOC - MSN messaging - OSCAR, used by AOL-IM as well as ICQ (client only) - MouseMan serial mice, and GPS devices - Twisted Perspective Broker, a remote object protocol

1 0

WebWare + Zope Page Templates
by Uwe Schmitt 08 May '03

08 May '03

Hi, I wrote a class which mixes Python/WebWare Servlets and the Zope templating language TAL. The usage is quite easy, many things as caching of compiled templates, is done automatically. For more information look at http://www.procoders.net/pythonstuff Greetings, Uwe. -- Dr. rer. nat. Uwe Schmitt http://www.procoders.net schmitt(a)procoders.net "A service to open source is a service to mankind."

1 0

SC-Track Roundup 0.5.7 - an issue tracking system
by Richard Jones 08 May '03

08 May '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ================================================= SC-Track Roundup 0.5.7 - an issue tracking system ================================================= This is a bugfix release for version 0.5.x - if you're upgrading from before 0.5, you *must* read doc/upgrading.txt! Unfortunately, the Zope frontend for Roundup is currently broken. If you'd like to volunteer to fix it, let me know. Roundup requires python 2.1.3 or later for correct operation. Users of the sqlite backend are encouraged to upgrade sqlite to version 2.7.3. We've had a good crack at bugs (thanks to all who contributed!): - - fixed Interval maths (sf bug 665357) - - fixed sqlite rollback/caching bug (sf bug 689383) - - fixed rdbms table update detection logic (sf bug 703297) - - fixed detection of bad date specs (sf bug 691439) - - required String properties not being flagged (thanks Ajit George) - - only look for CSV files when importing (thanks Dan Grassi) - - can now unset values in CSV editing (sf bug 704788) - - fixed rdbms email address lookup (case insensitivity) - - email file attachments added to issue files list (sf bug 711501) - - added socket timeout to attempt to prevent stuck processes (sf bug 665487) - - email registered users shouldn't be able to log in (sf bug 714673) - - handle missing addresses on users (sf bug 724537) Source and documentation is available at the website: http://roundup.sourceforge.net/ Release Info (via download page): http://sourceforge.net/projects/roundup Mailing lists - the place to ask questions: http://sourceforge.net/mail/?group_id=31577 About Roundup ============= Roundup is a simple-to-use and -install issue-tracking system with command-line, web and e-mail interfaces. It is based on the winning design from Ka-Ping Yee in the Software Carpentry "Track" design competition. Note: Ping is not responsible for this project. The contact for this project is richard(a)users.sourceforge.net. Roundup manages a number of issues (with flexible properties such as "description", "priority", and so on) and provides the ability to: (a) submit new issues, (b) find and edit existing issues, and (c) discuss issues with other participants. The system will facilitate communication among the participants by managing discussions and notifying interested parties when issues are edited. One of the major design goals for Roundup that it be simple to get going. Roundup is therefore usable "out of the box" with any python 2.1+ installation. It doesn't even need to be "installed" to be operational, though a disutils-based install script is provided. It comes with two issue tracker templates (a classic bug/feature tracker and a minimal skeleton) and six database back-ends (anydbm, bsddb, bsddb3, sqlite, metakit and gadfly). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (Darwin) iD8DBQE+ugV/rGisBEHG6TARAoHUAJ9ShWFrmTP9/owXemuVr1fukTnh6ACfSA03 QQjDeQhOpcHomxyXlQLqn2Y= =w8bw -----END PGP SIGNATURE-----

1 0

python-dev Summary for 2003-04-01 through 2003-04-15 *and* 2003-04-16 through 2003-04-30
by drifty＠bigfoot.com 08 May '03

08 May '03

When I realized today I didn't mail out a copy of the python-dev Summary for the last half of April I felt like I had not done it for the first half of April. Sure enough, I had not. So I am just including both here. If I ever go two weeks without posting a new summary, feel free to send me an email asking where it's at. If I ever stop doing this I will announce it in my last summary. ------------------------------------- +++++++++++++++++++++++++++++++++++++++++++++++++++++ python-dev Summary for 2003-04-01 through 2003-04-15 +++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from April 1, 2003 through April 15, 2003. It is intended to inform the wider Python community of on-going developments on the list and to have an archived summary of each thread started on the list. To comment on anything mentioned here, just post to python-list(a)python.org or `comp.lang.python`_ 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 fifteenth summary written by Brett Cannon (<voice of Comic Book Guy from "The Simpsons">Most summaries written by a single person, *ever* </voice>). 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; its simple and is accepted for `PEP markup`__. 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. __ http://www.python.org/peps/pep-0012.html .. _python-dev: http://www.python.org/dev/ .. _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 .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-03-16_2003-03-31.html ====================== Summary Announcements ====================== So all three people who expressed an opinion about the new Quickies_ format liked the new one, so it stays. Do you guys actually like the links to the CVS in the Summaries? The various links I put in to every single file mentioned that does not have direct documentation is time-consuming. But if you find it useful it can stay. Please let me know whether you actually use it (this means if you don't tell me!). ========= `Boom`__ ========= __ http://mail.python.org/pipermail/python-dev/2003-April/034370.html Splinter threads: - `RE: [Python-checkins] python/dist/src/Modules gcmodule.c <http://mail.python.org/pipermail/python-dev/2003-April/034371.html>`__ Related threads: - `Garbage collecting closures <http://mail.python.org/pipermail/python-dev/2003-April/034521.html>`__ - `Algorithm for finalizing cycles <http://mail.python.org/pipermail/python-dev/2003-April/034609.html>`__ Do you want to know what dedication is? Thinking of Python code that will cause Python to crash during dental surgery. Well, Tim Peters is that dedicated and managed to come up with some code that crashed Python when it attempted to garbage-collect some objects. This begins the joy that is garbage collection and finalizer functions. Gather around, children, as we learn about how Python tries to keep you from having to worry about keeping track of your trash. When Python executes the garbage collector, it looks to see what objects are unreachable based on reference counts; when something has a reference count of 0 nothing is referencing it so it is just floating out in the middle of no where with no one giving a hoot about whether it is their or not (children: "Awww! Poor, lonely object!"). But some of these lonely objects have what we call a finalizer (children: "What's that?!?"; isn't it cute when children are still inquisitive? Good for you for still being inquisitive! Have to be supportive, you know). A finalizer is either an instance that has a __del__ object or an object that has something in its tp_del slot (children: <nod>). Does anyone know why we have to take of these lonely objects that are somewhat special? (children: <look around for someone to be brave enough to actually try to answer; no one does>) Well, since these objects have something that must be called before they are garbage-collected, we have to make sure they don't reference an object that is out there but people think is cared about when it is only an object with a finalizer and we don't care about their opinions; it might want to keep an object's reference count above 0 and thus not be collected (children: "Oh..."). What makes them especially difficult to handle is that some objects that don't look like finalizers lie and end up acting like they are by defining a __getattr__ method that does very rude things (children: "That's not nice!"). And since it is really hard to tell whether they are real finalizers or just act like one, we just let them be out there forever so that they don't make the great Interpreter have to deal with them (some rabble-rouser: "My dad says that there is no great Interpreter and that everything came from the Compiler and Linker when they got together and did something my dad won't tell me about. Something about the bits and the bees..."; rest of children: "Nu-uh! The Interpeter is real! We've seen it! It's all-powerful and knowing! Take it back, take it back!"). Luckily, though, it is only an issue with something old-timers call classic classes; things that started to decay away long, long ago(children: "Yay! No more cruft!") And thanks to the diligent work of some very important people, it has been dealt with (children: "Yay! Thank you important people!"). There is a lesson to be learned here children; do not put old things to pasture to early since you can make stubborn old people mad which is bad since they make up the majority of voters in America (children: "Yes, teacher!"; smart-ass in the back of the room: "How old are you, teacher?" <snicker>). Guido said that Python's cleanup model could be summed up as "things get destroyed when nothing refers to them at some arbitrary time after nothing refers to them." And the corollary is "always explicitly close your external resources." In other words, when nothing points to the object will get collected at *some* point, but not necessarily immediately. The corollary is just good programming practice; close your resources yourself instead of relying on finalizers to do it for you since there is no guarantee when that will happen. Tim Peters gave several suggestions in regards in how to make sure things get cleaned up; from registering cleanup code with sys.atexit() to keep a weakref in a module with a finalizer to be executed when the module is collected. ========= Quickies ========= `Distutils documentation amputated in 2.2 docs?`__ Splinter threads: - `How do I report a bug? <http://mail.python.org/pipermail/python-dev/2003-April/034328.html>`__ Greg Ewing that two sections from the Distutils docs disappeared between Python 1.6 and 2.2. Sections are still missing and will stay so until someone comes up with a patch to add in the missing sections. There was also a discussion on making it more obvious how to report a bug on SF_. __ http://mail.python.org/pipermail/python-dev/2003-April/034314.html .. _SF: .. _SourceForge: http://www.sf.net/ `PEP 269 once more.`__ Jonathan Riehl got his patch for implementing `PEP 269`_ ("Pgen Module for Python") but then uploaded a newer version that is better. __ http://mail.python.org/pipermail/python-dev/2003-April/034317.html .. _PEP 269: http://www.python.org/peps/pep-0269.html `Minor issue with PyErr_NormalizeException`__ It was discovered that PyErr_NormalizeException could dump core because it forgot to return on possible errors. It's been fixed and back-ported. __ http://mail.python.org/pipermail/python-dev/2003-April/034325.html `Capabilities (we already got one)`__ Splinter threads: - `Capabilities <http://mail.python.org/pipermail/python-dev/2003-April/034315.html>`__ - `Security challenge <http://mail.python.org/pipermail/python-dev/2003-April/034343.html>`__ The thread that refuses to die continued into this month. Nothing ground-breaking was said, though. Ben Laurie, though, did say he is working on a PEP_ so hopefully that will make this whole discussion clear. __ http://mail.python.org/pipermail/python-dev/2003-April/034323.html .. _PEP: http://www.python.org/peps/ `[PEP] += on return of function call result`__ Someone wanted to do ``log.setdefault(r, '') += "test %d\n" % t`` which does not work. But it was pointed out you can just do ``temp = log.setdefault(r, ''); temp += "test %d\n" % t``. __ http://mail.python.org/pipermail/python-dev/2003-April/034339.html `How to suppress instance __dict__?`__ This is only of interest to people who use `Boost.Python`_ (which I don't use so I am not going to summarize it; although if you use C++ you will want to look at Boost.Python). __ http://mail.python.org/pipermail/python-dev/2003-April/034319.html .. _Boost.Python: http://www.boost.org/libs/python/doc/ `Super and properties`__ Someone got bit by properties not working nicely with super(). Nathan Srebro subsequently posted a `link <http://www.ai.mit.edu/~nati/Python/>`__ to a his own version of super() which handles this problem. __ `fwd: Dan Sugalski on continuations and closures`__ Kevin Altis forwarded some posts by Dan Sugalski (the guy heading the Parrot_ project and who Guido will throw a pie at at OSCON 2004 =) about closures and continuations that he found at http://simon.incutio.com/archive/2003/04/03/#closuresAndContinuations . Very well-written and might clarify things for people if they care to know more about closures, continuations, and why Lisp folks claim they are so damn important. __ http://mail.python.org/pipermail/python-dev/2003-April/034368.html .. _Parrot: http://www.parrotcode.org/ `LONG_LONG`__ Python 2.3 renames the LONG_LONG definition from the C API to PY_LONG_LONG as it should have been renamed. Yes, this will break things, but it was incorrect to have not renamed it. If you need to keep compatibility with code before Python 2.3, just use the following code (contributed by Mark Hammond):: #if defined(PY_LONG_LONG) && !defined(LONG_LONG) #define LONG_LONG PY_LONG_LONG #endif __ http://mail.python.org/pipermail/python-dev/2003-April/034396.html `socket question`__ Someone asking why something didn't build under Solaris and subsequently being redirected to python-list(a)python.org . __ http://mail.python.org/pipermail/python-dev/2003-April/034399.html `PEP305 csv package: from csv import csv?`__ Why does one have to do ``from csv import csv``? Wouldn't it be more reasonable to just do some magic in __init__.py for the csv_ package to do this properly? Well, Skip Montanaro forwarded the question to cvs development list at csv(a)mail.mojam.com and said he probably will make the change in the near future. __ http://mail.python.org/pipermail/python-dev/2003-April/034409.html .. _csv: http://www.python.org/dev/doc/devel/lib/module-csv.html `SF file uploads work now`__ Yes, hell must have frozen over since you can now upload a file when you start a new patch or bug report on SourceForge_. __ http://mail.python.org/pipermail/python-dev/2003-April/034416.html `Unicode`__ Splinter threads: - `OT: Signal/noise ratio <http://mail.python.org/pipermail/python-dev/2003-April/034462.html>`__ Once again another question on python-dev that is not appropriate for the list. But this one spawned questions of whether the mailing list should be renamed (answer: no, since it is fairly well-known what python-dev is for) or go back to having the list being closed and requiring moderator approval for posts from people off the list (answer: no, because the amount of work was just too much of a pain and the amount of off-topic emails has not equated to the filtering work done previously). __ http://mail.python.org/pipermail/python-dev/2003-April/034453.html `Placement of os.fdopen functionality`__ It was suggested to make the fdopen method of the os_ module a class method of 'file'. That was determined to be YAGNI and thus won't happen. __ http://mail.python.org/pipermail/python-dev/2003-April/034380.html .. _os: http://www.python.org/dev/doc/devel/lib/os-newstreams.html `Adding item in front of a list`__ Tim Peters wonders how many people would be made upset if list.insert() supported a negative index argument. __ http://mail.python.org/pipermail/python-dev/2003-April/034518.html `Why is spawn*p* not available on Windows?`__ Shane Halloway might add one of the os.spawn*p*() functions to Windows. __ http://mail.python.org/pipermail/python-dev/2003-April/034473.html `tzset`__ time.tzset() is no longer on Windows because it is broken (and I will behave and not make a joke about how it would be just as broken as the OS or anything because I am unbiased). __ http://mail.python.org/pipermail/python-dev/2003-April/034480.html `backporting string changes to 2.2.3`__ Neal Norwitz updated docs and back-ported changes to the string_ module to bring it in sync with the actual string object. __ http://mail.python.org/pipermail/python-dev/2003-April/034489.html .. _string: http://www.python.org/dev/doc/devel/lib/module-string.html `List wisdom`__ http://www.python.org/cgi-bin/moinmoin/PythonDevWisdom is a wiki page created to contain the random nuggets of wisdom that come up on python-dev. __ http://mail.python.org/pipermail/python-dev/2003-April/034575.html `ValueErrors in range()`__ Fixed the error where range() returned ValueError when it should return TypeError. __ http://mail.python.org/pipermail/python-dev/2003-April/034617.html `_socket efficiencies ideas`__ Marcus Mendenhall wanted to get a patch applied that would allow you to create a socket that could skip a DNS lookup. He also wanted to add the ability to include a '<numeric>' prefix IP addresses to make sure that DNS lookup was skipped. Various ways of trying to cut back on time wasted on unneeded DNS lookups was discussed but no solution was found acceptable. __ http://mail.python.org/pipermail/python-dev/2003-April/034403.html `tp_clear return value`__ tp_clear could stand to return void, but can't change because of backwards-compatibility. Will most likely end up documenting to ignore what is returned by what is put into tp_clear. __ http://mail.python.org/pipermail/python-dev/2003-April/034433.html `More socket questions`__ Someone suggested fixing something that has been solved in Python 2.3. __ http://mail.python.org/pipermail/python-dev/2003-April/034472.html `Embedded python on Win2K, import failures`__ Someone had errors embedding Windows. No real conclusion came out of it. __ http://mail.python.org/pipermail/python-dev/2003-April/034506.html `More int/long integration issues`__ Splintered threads: - `range() as iterator <http://mail.python.org/pipermail/python-dev/2003-April/034530.html>`__ Before Python 3.0 (when xrange() will disappear), there is a good chance that the idiom ``for x in range(): ...`` will be caught by the compiler and compiled into a lazy generator (probably a generator). __ http://mail.python.org/pipermail/python-dev/2003-April/034516.html `Changes to gettext.py for Python 2.3`__ Barry Warsaw suggested some changes to gettext_ but none of them seemed to catch on. But Barry has checkin rights and is one of apparently three people in the world who uses the module so they were added anyway. =) __ http://mail.python.org/pipermail/python-dev/2003-April/034511.html .. _gettext: http://www.python.org/dev/doc/devel/lib/module-gettext.html `Evil setattr hack`__ Someone discovered how to set attributes on built-in types. Guido checked in code to prevent it. __ http://mail.python.org/pipermail/python-dev/2003-April/034535.html `Using temp files and the Internet in regression tests`__ I asked if it was okay to use in regression tests temporary files (answer: yes it is and if you only need one use test.test_support.TESTFN) or sockets (answer: yes as long as test.test_support.is_resource_enabled("network") is True). It led to me being unofficially assigned the task of coming up with documentation for test_support and regrtest for both the library documentation and Lib/test/README. I also got CVS commit privileges on Python itself! I became an official Python developer! Woohoo! __ http://mail.python.org/pipermail/python-dev/2003-April/034538.html `migration away from SourceForge?`__ It was suggested we revisit the idea of moving Python development off of SourceForge_ because of the usual crappy CVS performance and underwhelming tracker performance. There is also the issue that problems with the setup cannot be fixed on our schedule. GForge_ and Roundup_ were both suggested as alternatives. Roundup specifically has gotten a decent amount of support since it is in Python and thus we could get things fixed quickly. Trouble is that it is not polished enough yet and we would need to furnish our own CVS (but Ben Laurie might be gracious enough to help us out on that front with possible hosting at http://www.thebunker.net/ ). If you would like to help get Roundup and the install at http://www.python.org:8080/ up and going, please do so. __ http://mail.python.org/pipermail/python-dev/2003-April/034540.html .. _GForge: http://gforge.org/ .. _Roundup: http://roundup.sf.net/ `How should time.strptime() handle UTC?`__ I asked if anyone thought time.strptime() should recognize UTC and GMT timezones by default for setting whether or not daylight savings was being used. No one has given their opinion yet (do you have one?). __ http://mail.python.org/pipermail/python-dev/2003-April/034543.html `Big trouble in CVS Python`__ CVS Python was crashing on the regression tests. It turned out to be from the reuse of a variable in the code that implements range(). Tim Peters said a "Word to the wise: don't ever try to reuse a variable whose address is passed to PyArg_ParseTuple for anything other than holding what PyArg_ParseTuple does or doesn't store into it". __ http://mail.python.org/pipermail/python-dev/2003-April/034544.html `GIL vs thread state`__ Discovered the docs for PyThreadState_Clear() are incorrect (or at least not very clear). __ http://mail.python.org/pipermail/python-dev/2003-April/034574.html `test_pwd failing`__ test_pwd was failing and now it isn't. __ http://mail.python.org/pipermail/python-dev/2003-April/034626.html `lists v. tuples`__ You can tell whether a comparison function does a 3-way or 2-way (using <); but that is not Pythonic and thus won't be done so as to allow someone to pass either a 2 or 3-way comparison function to list.sort() and have the method figure out what type of sort it is. __ http://mail.python.org/pipermail/python-dev/2003-April/034646.html `LynxOS 4 port`__ Duane Voth wants to get Python ported to the LynxOS on PPC. __ http://mail.python.org/pipermail/python-dev/2003-April/034647.html `sre.c and sre_match()`__ The C code for the re module is not simple. =) __ http://mail.python.org/pipermail/python-dev/2003-April/034653.html +++++++++++++++++++++++++++++++++++++++++++++++++++++ python-dev Summary for 2003-04-16 through 2003-04-30 +++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from April 16, 2003 through April 30, 2003. It is intended to inform the wider Python community of on-going developments on the list and to have an archived summary of each thread started on the list. To comment on anything mentioned here, just post to python-list(a)python.org or `comp.lang.python`_ 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 sixteenth summary written by Brett Cannon (writing history the way I see fit =). 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; its simple and is accepted for `PEP markup`__. 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. __ http://www.python.org/peps/pep-0012.html .. _python-dev: http://www.python.org/dev/ .. _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 .. contents:: .. _last summary: http://www.python.org/dev/summary/2003-04-01_2003-04-15.html ====================== Summary Announcements ====================== So no one responded to my question last time about whether anyone cared if I stopped linking to files in the Python CVS online through ViewCVS. So silence equals what ever answer makes my life easier, so I won't link to files anymore. .. _ViewCVS: http://viewcvs.sf.net/ ================== `2.3b1 release`__ ================== __ http://mail.python.org/pipermail/python-dev/2003-April/034682.html Splinter threads: - `Masks in getargs.c <http://mail.python.org/pipermail/python-dev/2003-April/034693.html>`__ - `CALL_ATTR patch <http://mail.python.org/pipermail/python-dev/2003-April/034712.html>`__ - `Built-in functions as methods <http://mail.python.org/pipermail/python-dev/2003-April/034749.html>`__ - `Tagging the tree <http://mail.python.org/pipermail/python-dev/2003-April/035069.html>`__ - `RELEASED: Python 2.3b1 <http://mail.python.org/pipermail/python-dev/2003-April/035093.html>`__ Guido announced he wanted to get `Python 2.3b1`_ out the door by Friday, April 25 (which he did). He also said if something urgently needed to get in before then to set the priority on the item to 7. The rules for betas is you can apply bug fixes (it is the point of the releases). New unit tests can also be added as long as the entire regression testing suite passes with them in there; since this is a beta any bugs found should be patched along with adding the tests. This led to some patches to come up that some people would like to see get into b1. One is Thomas Heller and his patch at http://www.python.org/sf/595026 which adds new argument masks for PyArg_ParseTuple(). Thomas' patch adds two new masks ('k' and 'K') and modifies some others so that their range checking (if they kept any) were more reasonable. This is when Jack Jansen chimed in saying that he didn't notice any mask that worked between 2.2 and 2.3 that converts 32 bit values without throwing a fit. Basically the changes to the 'h' mask left all of the Mac modules broken. The change was backed out, though, and the issue was solved. Martin v. Löwis wanted to get IDNA (International Domain Names in Applications) in (which he did). UnixWare was (and as of this writing still is) broken. It's being worked on, though, by Tim Rice. The CALL_ATTR patch that Thomas Wouters and I worked on at PyCon came up. We were trying to come up with an opcode to replace the common ``LOAD_ATTR; CALL_FUNCTION`` opcode pair that happens whenever you call a method. The hope was to short-circuit the pushing on to the stack the method object since it gets popped off immediately by CALL_FUNCTION. Initially the patch only worked for classic classes but Thomas has since cleaned it up and added support for new-style classes. To help out Thomas, Guido gave an overview of new-style classes and how descriptors work. Basically a descriptor is what exists in a class' __dict__ and "primarily affects instance attribute lookup". When the attribute lookup finds the descriptor it wants, it calls its __get__ method (tp_descrget slot for C types). The lookup then "binds" this to the instance; this is what separates a bound method from a function since functions are also descriptors. Properties are just descriptors whose __get__ calls whatever you passed for the fget argument. Class attribute lookup also calls __get__ but the instance attribute is made None (or NULL for C code). __set__ is called on a descriptor for instance attribute assignment but not for class attribute assignment. Guido clarified this later somewhat by the example having a descriptor f that when ``f.__get__(obj)`` is called it returns a function g which acts like a curried function (read the Python Cookbook if you don't know what currying_ is). Now when you call ``g(arg1, ...)`` you are basically doing ``f(obj, arg1, ...)``; so this all turns into ``f.__get__(obj)(arg1, ...)``. The problem with the CALL_ATTR patch is that there is turning out to be zero benefit from it beyond from having a nicer opcode for a common operation when the code for working with new-style classes in the code. This could be from cache misses because of the increased size of the interpreter loop or just too many branches to possibly take. As of now the patch is still on SF and has not been applied. .. _Python 2.3b1: http://www.python.org/2.3/ .. _currying: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/52549 ========================= `Super and properties`__ ========================= __ http://mail.python.org/pipermail/python-dev/2003-April/034338.html This thread was initially covered in the `last summary`_. Guido ended up explaining why super() does not work for properties. super() does not stop on the first hit of finding something when that "something" is a data descriptor; it ignores it and just keeps on looking. Now super() does this so that it doesn't end up looking like something it isn't. Think of the case of __class__; if it returned what object's __class__ returned it would cause super to look like something it isn't. Guido figured people wouldn't want to override data descriptors anyway, so this made sense. But now there is a use case for this, so Guido is changing this for Python 2.3 so that data descriptors are properly hit in the inheritance chain by super(). ====================== `Final PEP 311 run`__ ====================== __ http://mail.python.org/pipermail/python-dev/2003-April/034705.html Mark Hammond's `PEP 311`_ has now been implemented! What Mark has done is implement two functions in C; PyGILState_Ensure() and PyGILState_Restore(). Call the first one to get control of the GIL, without having to know its current state, to allow you to use the Python API safely. The second releases the GIL when you are done making calls out to Python. This is a much simpler interface than what was previously needed when you did not need a very fancy threading interface with Python and just needed to hold the GIL. As always, read the PEP to get the full details. .. _PEP 311: http://www.python.org/peps/pep-0311.html ================================================ `summing a bunch of numbers (or "whatevers")`__ ================================================ __ http://mail.python.org/pipermail/python-dev/2003-April/034767.html Splinter threads: - `stats.py <http://mail.python.org/pipermail/python-dev/2003-April/034840.html>`__ - `''.join() again <http://mail.python.org/pipermail/python-dev/2003-April/034857.html>`__ How would use sum a list of numbers? Traditionally there have been two answers. One is to use the operator module and 'reduce' in the idiomatic ``reduce(operator.add, list_of_numbers)``. The other is to do a simple loop:: running_sum = 0 for num in iterable_producing_numbers: running_sum += num Common complaints against the 'reduce' solution are that is just is ugly. People don't like the loop solution because it is long for such a simple operation. And a knock against both is that new users of Python do not necessarily think of either solution initially. So, what to do? Well, Alex Martelli to the rescue. Alex proposed adding a new built-in, 'sum', that would take a list of numbers and return the sum of those numbers. Originally Alex also wanted to special-case the handling of a list of strings so as to prevent having to tell new Python programmers that ``"".join(list_of_strings)`` is the best way to concatenate a bunch of strings and that looping over them is *really* bad (the amount of I/O done in the loop kills performance). But this special-casing was shot down because it seemed rather magical and can still be taught to beginners easily enough ('reduce' tends to require an understanding of functional programming). But the function still got added for numbers. So, as of Python 2.3b1, there is a built-in named 'sum' that has the parameter list "sum(iterable_producing_numbers [, start=0]) -> sum of the numbers given by iterable_producing_numbers". The 'start' parameter allows you to specify an initial value. And since this is a function with a very specific use it is the fastest way you can sum a list of numbers. The question of adding a statistics module came up during this discussion. The thought was presented to come up with a good, basic stats module to have in the stdlib. The arguments against this is that there are already several good stats modules out there so why bother with including one with Python? It would cause some overshadowing of any 3rd-party stats modules. Eventually the "nays" had it and the idea was dropped. And for all his work Alex got CVS commit privileges. Python, the gift that keeps on giving you more responsibility. =) =================================== `When is it okay to cvs remove?`__ =================================== __ http://mail.python.org/pipermail/python-dev/2003-April/035011.html Related threads: - `Rules of a beta release? <http://mail.python.org/pipermail/python-dev/2003-April/035092.html>`__ Being probably the most inexperienced person with CVS commit privileges on Python, I am continuing with my newbie questions in terms of applying patches to the CVS tree (and since I control the Summary I am going to document the answers I get here so I don't have to write them down somewhere else =). This time I asked about when it was appropriate to use ``cvs remove``, specifically if it was reasonable if a file was completely rewritten. The answer was to not bother with it unless you are actually removing the file forever; don't bother if you are just rewriting the file. Also, don't bother with changing the version number when doing a complete rewrite; just make sure to mention in the CVS commit message that it is a rewrite. I also learned that the basic guideline to follow in terms of whether a patch should be put up on SF_ or just committed directly is that if you are unsure about the usefulness or correctness then you should post it on SF. But if you don't think there is anyone who can answer it on SF it will just languish there for eternity. Also learned the rules of a beta release. Basically no changes that would cause someone's code to not work the same way as when the beta was released can be checked in. New tests are okay, though. .. _SF: http://www.sf.net/ ========= Quickies ========= `3-way result of PyObject_IsTrue() considered PITA`__ Raymond Hettinger discovered that PyObject_IsTrue() promises that there is never an error from running the function, which is not how the function performs. Raymond fixed the docs to match the code. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034658.html `Python dies upon printing UNICODE using UTF-8`__ Windows NT 4's support of UTF-8 is broken. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034666.html `shellwords`__ Gustavo Niemeyer asked if there was any chance of getting shellwords_ into the stdlib so as to be able to have POSIX command line word parsing. The basic response was that shlex_ should be enhanced to do what Gustavo wanted. He has since written `patch #722686`_ that implements the features he wanted. It was also discovered that distutils.util.split_quoted comes close. If someone wants to document Distutils utilities it would be greatly appreciated. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034670.html .. _shellwords: http://www.crazy-compilers.com/py-lib/shellwords.html .. _shlex: http://www.python.org/dev/doc/devel/lib/module-shlex.html .. _patch #722686: http://www.python.org/sf/722686 `Changes to gettext.py for Python 2.3`__ This thread was originally covered in the `last summary`_. Barry Warsaw and Martin v. Löwis discussed the gettext_ and whether there should be a way to coerce strings to other encodings. They ended up agreeing on defaulting on Unicode for storing the strings and having .gettext() coerce to an 8-bit string while .ugettext() returns the original Unicode string. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034511.html .. _gettext: http://www.python.org/dev/doc/devel/lib/module-gettext.html `Stackless 3.0 alpha 1 at blinding speed`__ Christian Tismer has done it again; he improved Stackless_ and now has managed to have merged the abilities of Stackless 1 with 2 which has led to 3a. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034708.html .. _Stackless: http://www.stackless.com `Build errors under RH9`__ Python was not building under Red Hat 9, but Martin v. Löwis checked in a fix. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034724.html `Wrappers and keywords`__ Matt LeBlanc asked why there wasn't a nice syntax for doing properties staticmethods and classmethods. The answer is that it was felt it was more important to get the ability to use those new descriptors out there instead of letting a syntax debate hold them up. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034715.html `Startup overhead due to codec usage`__ MA Lemburg and Martin v. Löwis discussed startup time taken up by seeing what encoding is used by the local filesystem. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034742.html `test_pwd failing`__ Initially covered in the `last summary`_. test_grp was failing for the same reasons test_pwd was failing. It has been fixed. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034626.html `Evil setattr hack`__ Someone found a way to set an attribute on a type which is a no-no. The lesson learned here was don't mess with an instance's __dict__ directly; we will let you but if you get burned its your own fault. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034633.html `heapq`__ Splinter threads: - `FIFO data structure? <http://mail.python.org/pipermail/python-dev/2003-April/034790.html>`__ - `heaps <http://mail.python.org/pipermail/python-dev/2003-April/035004.html>`__ The idea of turning the heapq_ module into a class came up, and later led to the idea of having a more proper FIFO (First In, First Out) data structure. Both ideas were shot down. The reason for this was that the stdlib does not need to try to grow every single possible data structure in programming. Guido's design philosophy is to have a few very powerful data structures that other ones can be built off of. This is why the bisect_ and heapq modules just work on standard lists instead of defining a new class. Queue_ is an exception, but it is designed to mediate messages between threads instead of being a general implementation of a queue. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034768.html .. _heapq: http://www.python.org/dev/doc/devel/lib/module-heapq.html .. _bisect: http://www.python.org/dev/doc/devel/lib/module-bisect.html .. _Queue: http://www.python.org/dev/doc/devel/lib/module-Queue.html `New re failures on Windows`__ Splinter threads: - `sre vs gcc <http://mail.python.org/pipermail/python-dev/2003-April/034895.html>`__ The re_ module was failing after some changes were made to it. The pain of it all was that it was failing only on certain platforms running gcc_. Initial attempts were to make it "just work", but then it was stressed that it is more important to find the offending C code and figure out why gcc on certain platforms was compiling bad assembly. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034776.html .. _re: http://www.python.org/dev/doc/devel/lib/module-re.html .. _gcc: http://gcc.gnu.org/ `os.path.walk() lacks 'depth first' option`__ Someone requested that os.path.walk support breadth-first walking (yes, the title of the thread is wrong). The request was deemed not important enough to bother implementing, but Tim Peters did implement a new function named os.walk that is a much improved replacement for os.path.walk and lets you control which direction the traversl goes (top-down or bottom-up). .. __: http://mail.python.org/pipermail/python-dev/2003-April/034792.html `Weekly Python Bug/Patch Summary`__ Skip Montanaro's weekly reminder that there is work to be done! Summary for week 2 can be found `here <http://mail.python.org/pipermail/python-dev/2003-April/035125.html>`__. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034797.html `Hook Extension Module Import?`__ Want to do something that requires a special import hook in C? Then override the __import__ built-in with what you need. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034804.html `Bug/feature/patch policy for optparse.py`__ Greg Ward asked if it would be okay to keep the official version of optparse_ at http://optik.sf.net/ (Optik is the project name for optparse). Guido said sure. The justification for this is that Greg wants Optik to be available to people for use in earlier versions of Python. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034833.html .. _optparse: http://www.python.org/dev/doc/devel/lib/module-optparse.html `LynxOS4 dynamic loading with dlopen() and -ldl`__ LynxOS4 does not like dynamic linking. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034878.html `Embedded python on Win2K, import failures`__ I don't like Windows. And no, this has nothing to do with this single email that is a short continuation of one covered in the `last summary`_. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034506.html `New thread death in test_bsddb3`__ After Mark Hammond's new thread code got checked in the bsddb module broke. Mark went in, though, and using the wonders that is the C preprocessor and NEW_PYGILSTATE_API_EXISTS, Mark fixed the code to use the new PyGILState API as covered in `PEP 311`_ when possible and to use the old solution when needed. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034901.html `Magic number needs upgrade`__ Guido noticed that the PYC magic number needed to be incremented to handle Raymond Hettinger's new bytecode optimizations. But then Guido questioned the need of Raymond's changes. Basically Raymond's changes didn't speed anything up but cleaned up the emitted bytecode. Guido didn't like the idea of adding more code without an actual speed improvement. Since neither this code nor any of the other proposed speedup changes (CALL_ATTR and caching attribute lookup results) are panning out, Guido questioned why Raymond's should get in. Guido suggested rewriting the interpreter from scratch since all new changes seem to be breaking some delicate balance that has developed in it. He also thought putting effort into other things like pysco_. Eventually Raymond's changes were backed out. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034905.html .. _pysco: http://psyco.sf.net/ `draft PEP: Trace and Profile Support for Threads`__ Jeremy Hylton has a draft PEP on how to add hooks for profile and trace code in threads. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034909.html `Data Descriptors on module objects`__ Never going to happen. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035025.html `Metatype conflict among bases?`__ "The metaclass [of a class] must be a subclass of the metaclass of all the bases" of that class. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034910.html `okay to beef up tests on the maintenance branch?`__ Answer: yes! .. __: http://mail.python.org/pipermail/python-dev/2003-April/034939.html `Cryptographic stuff for 2.3`__ AM Kuchling wanted to add an implementation of the AES_ encryption algorithm to the stdlib. After a long discussion the idea was shot down because having crypto that strong in the stdlib would cause export issues for Python. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034957.html .. _AES: http://csrc.nist.gov/encryption/aes/ `vacation`__ Neal Norwitz is on vacation from April 26 till May 6. He pointed out some nagging errors coming up from the `Snake Farm`_ that could use some working on. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034942.html .. _Snake Farm: http://www.lysator.liu.se/xenofarm/python/latest.html `test_getargs2 failures`__ Not anymore. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034944.html `Democracy`__ Guido pointed out a paper on democracy (in the ancient Athenian sense) and the organization of groups at http://www.acm.org/ubiquity/interviews/b_manville_1.html that was interesting. Sparked some discussion on proper comparisons to open source projects and such. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034946.html `Updating PEP 246 for type/class unification, 2.2+, etc.`__ Phillip Eby proposed some changes to `PEP 246`_. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034955.html .. _PEP 246: http://www.python.org/peps/pep-0246.html `why is test_socketserver in expected skips?`__ Skip Montanaro noticed that socketserver was listed as an expected test to be skipped on all platforms sans os2emx even though it works on all platforms with networking (basically all of them). So it was removed from the expected skip list. Skip also tweaked test_support.requires to always pass when the caller is __main__. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034973.html `netrc.py`__ Bram Moolenaar, author of the `greatest editor in the world`_ and AAP_, requested a changed to netrc_ that got implemented. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034983.html .. _greatest editor in the world: http://www.vim.org/ .. _AAP: http://www.a-a-p.org/ .. _netrc: http://www.python.org/dev/doc/devel/lib/module-netrc.html `PyRun_* functions`__ They take FILE* arguments and it is going to stay that way. Just make sure the files are opened with the same library as being built against. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034990.html `Python Developers`__ Related threads: - `Getting mouse position interms of canvas unit. <http://mail.python.org/pipermail/python-dev/2003-April/035149.html>`__ - `2.3b1, and object() <http://mail.python.org/pipermail/python-dev/2003-April/035210.html>`__ Posted to the wrong email list. .. __: http://mail.python.org/pipermail/python-dev/2003-April/034969.html `New test failure on Windows`__ re_ was failing but got fixed. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035009.html `More new Windos test failures`__ Just before `Python 2.3b1`_ got pushed out the door, some last-minute test failures cropped up (some of them were my fault). But they got fixed. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035047.html `should sre.Scanner be exposed through re and documented?`__ re.Scanner shall remain undocumented. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035066.html `LynxOS4 port: need pre-ncurses curses!`__ The LynxOS is hoping curses will go away. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035052.html `test_s?re merge`__ test_re and test_sre have been merged and moved over to unittest_ thanks to Skip Montanaro. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035067.html .. _unittest: http://www.python.org/dev/doc/devel/lib/module-unittest.html `test_ossaudiodev hanging again`__ Some people are still having issues with ossaudiodev tests hanging. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035056.html `bz2 module fails to compile on Solaris 8`__ The joys of being cross-platform. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035068.html `test_logging hangs on Solaris 8`__ Splinter threads: - `test_logging hangs on OS X <http://mail.python.org/pipermail/python-dev/2003-April/035135.html>`__ - `test_logging hangs on Solaris 8 (and 9) <http://mail.python.org/pipermail/python-dev/2003-April/035100.html>`__ The joys of threading and trying to avoid deadlock. A fix has been checked in that seems to fix this on OS X; don't know about Solaris yet. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035065.html `Python 2.3b1 documentation`__ Fred L. Drake, Jr. posted the documentation for Python 2.3b1. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035064.html `Accepted PEPs?`__ Splinter threads: - `Reminder to PEP authors <http://mail.python.org/pipermail/python-dev/2003-April/035109.html>`__ - `proposed amendments to PEP 1 <http://mail.python.org/pipermail/python-dev/2003-April/035161.html>`__ The status of some PEPs got updated along with some proposed changes to `PEP 1`_. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035104.html .. _PEP 1: http://www.python.org/peps/pep-0001.html `Problems w/ Python 2.2-maint and Redhat 9`__ Dealing with some issues of Python 2.2-maint and linking against a dbm. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035120.html `Why doesn't the uu module give you the filename?`__ Someone wanted the uu_ module to let you know what the name of the encoded file is. Was told to post a patch. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035129.html .. _uu: http://www.python.org/dev/doc/devel/lib/module-uu.html `Antigen found CorruptedCompressedUuencodeFile virus`__ The joys of having to watch out for viruses in emails and get false positives. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035130.html `Python 2.3b1 has 20% slower networking?`__ Splinter threads: - `Python-Dev digest, Vol 1 #3221 - 4 msgs <http://mail.python.org/pipermail/python-dev/2003-April/035153.html>`__ Networking throughput did not have as high of a max when in a loop as before. Has been fixed, though. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035132.html `cvs socketmodule.c and IPV6 disabled`__ Discovered some code that couldn't compile because a test for a specific C function was not specific enough. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035146.html `Introduction :)`__ Someone else with the first name of Brett introduced themselves to the list (Brett Kelly). You can tell us apart because I am taller. =) .. __: http://mail.python.org/pipermail/python-dev/2003-April/035162.html `Dictionary tuning`__ Splinter threads: - `Dictionary tuning upto 100,000 entries <http://mail.python.org/pipermail/python-dev/2003-April/035194.html>`__ Raymond Hettinger did a bunch of attempted tuning of dictionary accesses and came up with one solution that managed to be beneficial for large dictionaries and not detrimental for small ones. He basically just caused dictionary sizes to grow by a factor of 4 instead of 2 so as to lower the number of collisions. The objection that came up was that some dictionaries would be larger than they were previously. It looks like it would be applied, but Raymond's notes on everything will most likely end up as a text file in Python. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035151.html `Thoughts on -O`__ It was suggested to change what the -O and -OO command-line switches did since at this moment they don't do much (Guido has even suggested eliminating -O). But the discussion has been partially put on hold until development for Python 2.4 starts. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035165.html `Initialization hook for extenders`__ It has been suggested to add a Py_AtInit() hook to Python to be symmetric with Py_AtExit(). The debate over this is still going. .. __: http://mail.python.org/pipermail/python-dev/2003-April/035226.html

1 0

ANNOUNCE: Released IndexedCatalog 0.5.0
by Johan Dahlin 08 May '03

08 May '03

ANNOUNCE: Released IndexedCatalog 0.5.0 Async Open Source releases today the third public version of IndexedCatalog. IndexedCatalog is an extension to the Zope Object Database (ZODB) that makes object retrieval easier and faster, by indexing all fields by type (string/integer/float/date) and providing a simple query language. http://www.async.com.br/projects/IndexedCatalog/ * Changes: Support for subclassed catalogs Added a new wrapper around ZODB, Shelf, that simplifies database connections. Improved list queries slightly A new tool: dumper that exports and imports data Unicode index support Should work with ZODB4 Support for lazy_numbers, when float convert to integer and vice versa Thanks a lot to Christian Reis for testing, bug fixing and helping with more or less everything and thank to Nicholas Henke for testing and optimization. A blurb about IndexedCatalog follows. --- blurb ------------------------------------------------------------- * Overview IndexedCatalog is an extension to the Zope Object Database (ZODB) developed at Async Open Source that provides indexing and allows queries for objects based on attributes. This is accomplished by indexing all fields by type (string/integer/float) and by implementing a query language. IndexedCatalog is licensed under the Lesser GNU Public License (LGPL). * Features - Provides a Catalog class that stores objects and offers a query interface. - Provides Indexes for Strings, Floats, Integers, Dates and Instances. - Requires very little change to objects for catalogs and indexes to work: basically inherit from IndexedCatalog.IndexedObject, add some special attributes to the Classes, and use catalog.insert() to add the instances to the catalogs. - Supports composite objects, initializing and indexing sub-objects automatically. - Supports queries by type, and allows querying sub-object or referenced object attribute values. - Allows ordering query results by field, both ascending and descending. - Is 100% pure python, and by using Distutils requires minimal effort to install. * Feedback We really would appreciate feedback on a few things: - The efficiency of the indexing and query algorithms, especially sub-string matching. - The new improved query language - All comments are appreciated; don't hesitate to post your opinion. * Download You can download IndexedCatalog from http://www.async.com.br/projects/IndexedCatalog/ * Dependencies Python 2.1.2 or higher or Python 2.2.2 or higher. (Python CVS/2.3 untested) ZODB 1.0.x and 3.x are known to work. ZODB 4 alpha 1 should work, but it's not very well tested. eGenix mx Extensions: mx.DateTime and mx.TextTools. 2.0.2 or later is required * Installing Using standard python distutils: python setup.py install Or just set PYTHONPATH to the directory you unpacked IndexedCatalog in. * Reporting bugs Report bugs, feature requests and all other things related to IndexedCatalog at http://bugs.async.com.br/enter_bug.cgi?product=IndexedCatalog * Contact Johan Dahlin <jdahlin(a)async.com.br> Christian Reis <kiko(a)async.com.br> * About Async Async Open Source is a company devoted to developing custom applications based on open source software, and providing support for other existing open source products. We are active in the OSS community, supporting (and employing) project maintainers, encouraging release of software as open source, and promoting reuse of existing open source products. Async is located in São Carlos, SP, Brazil, and online at http://www.async.com.br/ -- Johan Dahlin <jdahlin(a)async.com.br> Async Open Source

1 0

ANN: Python Imaging Library 1.1.4 beta 2
by PythonWare 07 May '03

07 May '03

PIL 1.1.4 beta 2 is now available from: http://www.pythonware.com/products/pil#pil114 or http://effbot.org/downloads#pil This release is available in source form (look for Imaging tarballs), and as prebuilt installers for Python 2.1, 2.2 and 2.3 (beta 1) on Windows (and this time, all three installers include Tk support!) We expect to release the final version (without any changes to the code) within a week. A list of changes can be found here... http://effbot.org/zone/pil-changes-114.htm ...and a draft handbook can be found here: http://effbot.org/books/imagingbook/ enjoy, the pil team at secret labs ab "Secret Labs AB -- makers of fine pythonware since 1997"

1 0

[ANN] Data Plotting Library DISLIN 8.1
by Michels 07 May '03

07 May '03

I am pleased to announce version 8.1 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, 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 ------------------- Helmut Michels Max-Planck-Institut fuer Aeronomie Phone: +49 5556 979-334 Max-Planck-Str. 2 Fax : +49 5556 979-240 D-37191 Katlenburg-Lindau Mail : michels(a)linmpi.mpg.de

1 0

Meeting Reminder: Zope/Plone Futures
by Paul Prescod 06 May '03

06 May '03

Zope and Plone Futures Fresh out of a Zope and Plone coding sprint, Zope/Plone guru and developer Andy McKay will talk about "what's new" in Zope and Plone and then describe what is upcoming. You can't get more up-to-date information than this! David Ascher and/or Trent Mick will arrange for setup of the meeting. Tuesday April 1, 2003 7:00 PM ActiveState, 580 Granville St.

1 0

ANN: nohtml 1.10 Released
by Tim Daneliuk 06 May '03

06 May '03

nohtml 1.10 is released and available at: http://www.tundraware.com/Software/nohtml/ This program removes HTML attachments in email. It is written in Python and implemented as a filter which uses stdin and stdout. The program is designed primarily to be used in email alias definitions. By piping a given user's email through 'nohtml.py' first, only the textual portion of the message will actually be delivered. This is especially useful if you run mailing lists and want to stop HTML from ever reaching them. ---------------------------------------------------------------------------- Tim Daneliuk tundra(a)tundraware.com PGP Key: http://www.tundraware.com/PGP/TundraWare.PGP.Keys.txt

1 0

EuroPython 2003: Call For Talks Extended
by Michael Hudson 05 May '03

05 May '03

The EuroPython Conference 2003 (EPC2003) returns to Belgium this June, and the conference organizers are now accepting proposals for presentations and tutorials. We expect this year to be even more successful, and we're not just talking about the Chimay. We are looking for participation in the following conference tracks: Python Frameworks, Python Language, Python in Business, Python in Science and Industry, and Zope. Track descriptions are available at <http://www.europython.org/sessions/descriptions>. The deadline for submissions is extended till Monday, May 12. If you haven't done so or are still hesitating, you can still propose a 30 minute talk, a 45 minute talk, or a 90- minute tutorial. To propose a talk or tutorial, please visit the Talk Submission page at <http://www.europython.org/Talks/callFor>. Starting now, if you don't have the time to prepare a full-length talk, we are also seeking people who want to give a 'Lightning Talk': a short (5 minute), focused talk about any Python- or Zope-related subject you fancy! For more information about the conference tracks, please contact the track chairpersons listed at <http://www.europython.org/sessions/descriptions>. For general questions about the conference, please visit the conference website at <http://www.europython.org/>. About EuroPython Conference 2003 EuroPython Conference 2003 is the premiere venue for meeting Python and Zope developers from Europe and beyond. As one of the first community-organized Python and Zope conferences, the EuroPython Conference delivers the atmosphere and information developers want. The conference will be held June 25-27, 2003 in Charleroi, Belgium. Information is available at the EuroPython website at <http://www.europython.org/>. For more information, contact <europython(a)python.org>.

1 0

[ANNOUNCE] Sixth release of PythonCAD now available
by Art Haas 04 May '03

04 May '03

I'd like to announce the sixth release of PythonCAD, a CAD package for open-source software users. As the name implies, PythonCAD is written entirely in Python. The goal of this project is to create a fully scriptable drafting program that will match and eventually exceed features found in commercial CAD software. PythonCAD is released under the GNU Public License (GPL). PythonCAD requires Python 2.2. The interface is GTK 2.0 based, and uses the PyGTK module for interfacing to GTK. The design of PythonCAD is built around the idea of separating the interface from the back end as much as possible. By doing this, it is hoped that both GNOME and KDE interfaces can be added to PythonCAD through usage of the appropriate Python module. Addition of other interfaces will depend on the availability of a Python module for that particular interface and developer interest and action. The sixth release at long last adds the ability to store text in a drawing. The text handling is in its earliest stages of development, but now it is there. There is a new Polyline entity available to use in a drawing now. A Polyline is essentially the same thing as a connected set of segments, with the segments joined at the endpoint of one to another. The ability to mirror objects around an arbitrarily angled construction line has been added in this release as well. This release also has a large number of internal code cleanups. A large amount of code is being moved from the interface specific directory to the general directory. Doing so reduces the potential of code duplication in various interfaces. Another improvement in this release is a reworking of the code used when building or modifying entities through the menu choices. A new set of object classes has been added that are specific for the operation to be performed, and the use of these new classes makes the code to execute the operation simpler to add and understand. The usual amount of code cleanups, bug fixes, tweaks, and documentation additions have been done in this new release as well. Unfortunately there is still no mailing list for PythonCAD just yet. I want to find a site that will accept mail from anyone, not just list subscribers, filter the mail to remove the spam, then send the mail out to the subscribers. Lists on Sourceforge and the GNU Subversions site allow more spam than I want, so I am still looking for options. I cannot stress highly enough how I want the list to be free from junk mail that unfortunately ends up clogging so many mailing lists. So, I am still looking for recommendations about sites that can host the mailing list. Visit the PythonCAD web site for more information about what PythonCAD does and aims to be: http://www.pythoncad.org Come and join me in developing PythonCAD into a world class drafting program! Art Haas -- To announce that there must be no criticism of the President, or that we are to stand by the President, right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt, Kansas City Star, 1918

1 0

ANN: PyObjC 0.9
by Ronald Oussoren 04 May '03

04 May '03

PyObjC 0.9 is now available for download at http://pyobjc.sourceforge.net/ PyObjC is a bridge between Python and Objective-C. It allows full featured Cocoa applications to be written in pure Python. It is also easy to use other frameworks containing Objective-C class libraries from Python and to mix in Objective-C, C and C++ source. Python is a highly dynamic programming language with a shallow learning curve. It combines remarkable power with very clear syntax. The installer package includes a number of Project Builder templates for easily creating new Cocoa-Python projects. Version 0.9 also introduces support for sytax coloring of Python files in Project Builder. PyObjC also supports full introspection of Objective-C classes and direct invocation of Objective-C APIs from the interactive interpreter. PyObjC requires MacOS X 10.2 or later. PyObjC works both with the Apple provided Python installation in MacOS X 10.2 (and later) and with MacPython 2.3b1. Users of MacPython 2.3b1 can install PyObjC though the PackageManager application. PyObjC 0.9 includes many inprovements over earlier versions and users are strongly advised to upgrade. The installer package will automatically upgrade prior releases. PyObjC is released with an open source license.

1 0

[Application] ISOS/v0.7.1a
by Mehmet Gencer 04 May '03

04 May '03

ISOS/v0.7.1a ------------ A bundle of SMTP, POP3, HTTP servers, and a management console. ISOS is a purely Python server for small organizations. It contains e-mail(SMTP & POP3) servers, a simple HTTP server, and a console based management program for controlling services, creating users and e-mail groups. Most suitable for small organizations that has little expertise in such services and software, and mediocre performance considerations Turkish and English interface. GPL licensed. ISOS provides a quick start for e-presence of small organizations/comapnies, if you don't want to pay for MS Exchange server, and lack the experience to get software like Sendmail, Courier and Apache do what you need. Works on both Windows and Linux. URL: http://isos.acikkanal.net/ Download: http://isos.acikkanal.net/index.en.html License: GPL Platform: Linux, Win32 Categories: Servers Mehmet Gencer (mgencer(a)acikkanal.net) http://isos.acikkanal.net/ -- <a href="http://isos.acikkanal.net/">ISOS/v0.7.1a</a> -- A bundle of SMTP, POP3, HTTP servers, and a management console.

1 0

announce: Epylog-0.9.3
by Konstantin Riabitsev 04 May '03

04 May '03

Epylog Log Analyzer =================== What is it: ----------- Epylog is a new log notifier and parser which runs periodically, looks at your logs, processes some of the entries in order to present them in a more comprehensive format, and then mails you the output. It is written specifically for large network clusters where a lot of machines (around 50 and upwards) log to the same loghost using syslog or syslog-ng. The epylog engine should work on most unix systems running Python-2.2 and above, alhough currently the processing modules are only written to work with linux (and particularly Red Hat Linux series 7 and above). However, other unix and linux flavors should work fine, as long as they use standard non-ancient logging facilities and things like PAM. Features: --------- - Threaded for faster network lookups - Unwraps "last message repeated" lines - Mails reports in either html or plain text (or both) - Publishes reports to a file with optional notification via email. - Accepts --last hour/day/week/month command-line arguments - Handles modules written in both Python and other languages (though many "neat" features are not available to external modules) - External module API fully backwards-compatible with DULog Requirements: -------------- The parsing modules are currently only written for linux, so at least at the moment running it on other unixes would not be very efficient (it will still work as long as syslog is used, but many lines will be unparsed). Requires Python-2.2 or above and PyXML (libxml2-python). Works as-is for Red Hat 7.3, 8.0, and 9 (though see a caution on the site for 9), Yellowdog Linux 3.0. Where to get it: ---------------- http://linux.duke.edu/projects/epylog/ Best regards, -- Konstantin ("Icon") Riabitsev Duke Physics Systems Admin, RHCE www.duke.edu/~icon/pubkey.asc

1 0

PEP 1: PEP Purpose and Guidelines
by David Goodger 03 May '03

03 May '03

I am posting this meta-PEP to inform the Python community of a significant recent addition. Formerly, there was no provision for the BDFL to initiate a PEP review, even if the PEP was sure to be accepted; taken literally, the PEP text required the PEP author to request a review. Such a provision has been added with the following text: For a PEP that is pre-determined to be acceptable (e.g., it is an obvious win as-is and/or its implementation has already been checked in) the BDFL may also initiate a PEP review, first notifying the PEP author(s) and giving them a chance to make revisions. A description of the PEP acceptance criteria was also added immediately following the above text. The processed PEP can be found at <http://www.python.org/peps/pep-0001.html>. ====================================================================== PEP: 1 Title: PEP Purpose and Guidelines Version: $Revision: 1.42 $ Last-Modified: $Date: 2003/05/03 16:01:32 $ Author: Barry A. Warsaw, Jeremy Hylton, David Goodger Status: Active Type: Informational Content-Type: text/x-rst Created: 13-Jun-2000 Post-History: 21-Mar-2001, 29-Jul-2002, 03-May-2003 What is a PEP? ============== PEP stands for Python Enhancement Proposal. A PEP is a design document providing information to the Python community, or describing a new feature for Python. The PEP should provide a concise technical specification of the feature and a rationale for the feature. We intend PEPs to be the primary mechanisms for proposing new features, for collecting community input on an issue, and for documenting the design decisions that have gone into Python. The PEP author is responsible for building consensus within the community and documenting dissenting opinions. Because the PEPs are maintained as text files under CVS control, their revision history is the historical record of the feature proposal [1]_. Kinds of PEPs ============= There are two kinds of PEPs. A Standards Track PEP describes a new feature or implementation for Python. An Informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementors are free to ignore Informational PEPs or follow their advice. PEP Work Flow ============= The PEP editors assign PEP numbers and change their status. The current PEP editors are David Goodger and Barry Warsaw. Please send all PEP-related email to <peps(a)python.org>. The PEP process begins with a new idea for Python. It is highly recommended that a single PEP contain a single key proposal or new idea. The more focussed the PEP, the more successfully it tends to be. The PEP editor reserves the right to reject PEP proposals if they appear too unfocussed or too broad. If in doubt, split your PEP into several well-focussed ones. Each PEP must have a champion -- someone who writes the PEP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The PEP champion (a.k.a. Author) should first attempt to ascertain whether the idea is PEP-able. Small enhancements or patches often don't need a PEP and can be injected into the Python development work flow with a patch submission to the SourceForge `patch manager`_ or `feature request tracker`_. The PEP champion then emails the PEP editor <peps(a)python.org> with a proposed title and a rough, but fleshed out, draft of the PEP. This draft must be written in PEP style as described below. If the PEP editor approves, he will assign the PEP a number, label it as Standards Track or Informational, give it status "Draft", and create and check-in the initial draft of the PEP. The PEP editor will not unreasonably deny a PEP. Reasons for denying PEP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Python philosophy. The BDFL (Benevolent Dictator for Life, Guido van Rossum) can be consulted during the approval phase, and is the final arbitrator of the draft's PEP-ability. If a pre-PEP is rejected, the author may elect to take the pre-PEP to the comp.lang.python newsgroup (a.k.a. python-list(a)python.org mailing list) to help flesh it out, gain feedback and consensus from the community at large, and improve the PEP for re-submission. The author of the PEP is then responsible for posting the PEP to the community forums, and marshaling community support for it. As updates are necessary, the PEP author can check in new versions if they have CVS commit permissions, or can email new PEP versions to the PEP editor for committing. Standards Track PEPs consists of two parts, a design document and a reference implementation. The PEP should be reviewed and accepted before a reference implementation is begun, unless a reference implementation will aid people in studying the PEP. Standards Track PEPs must include an implementation -- in the form of code, patch, or URL to same -- before it can be considered Final. PEP authors are responsible for collecting community feedback on a PEP before submitting it for review. A PEP that has not been discussed on python-list(a)python.org and/or python-dev(a)python.org will not be accepted. However, wherever possible, long open-ended discussions on public mailing lists should be avoided. Strategies to keep the discussions efficient include, setting up a separate SIG mailing list for the topic, having the PEP author accept private comments in the early design phases, etc. PEP authors should use their discretion here. Once the authors have completed a PEP, they must inform the PEP editor that it is ready for review. PEPs are reviewed by the BDFL and his chosen consultants, who may accept or reject a PEP or send it back to the author(s) for revision. For a PEP that is pre-determined to be acceptable (e.g., it is an obvious win as-is and/or its implementation has already been checked in) the BDFL may also initiate a PEP review, first notifying the PEP author(s) and giving them a chance to make revisions. For a PEP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the interpreter unduly. Finally, a proposed enhancement must be "pythonic" in order to be accepted by the BDFL. (However, "pythonic" is an imprecise term; it may be defined as whatever is acceptable to the BDFL. This logic is intentionally circular.) See PEP 2 [2]_ for standard library module acceptance criteria. Once a PEP has been accepted, the reference implementation must be completed. When the reference implementation is complete and accepted by the BDFL, the status will be changed to "Final". A PEP can also be assigned status "Deferred". The PEP author or editor can assign the PEP this status when no progress is being made on the PEP. Once a PEP is deferred, the PEP editor can re-assign it to draft status. A PEP can also be "Rejected". Perhaps after all is said and done it was not a good idea. It is still important to have a record of this fact. PEPs can also be replaced by a different PEP, rendering the original obsolete. This is intended for Informational PEPs, where version 2 of an API can replace version 1. PEP work flow is as follows:: Draft -> Accepted -> Final -> Replaced ^ +----> Rejected v Deferred Some Informational PEPs may also have a status of "Active" if they are never meant to be completed. E.g. PEP 1 (this PEP). What belongs in a successful PEP? ================================= Each PEP should have the following parts: 1. Preamble -- RFC 822 style headers containing meta-data about the PEP, including the PEP number, a short descriptive title (limited to a maximum of 44 characters), the names, and optionally the contact info for each author, etc. 2. Abstract -- a short (~200 word) description of the technical issue being addressed. 3. Copyright/public domain -- Each PEP must either be explicitly labelled as placed in the public domain (see this PEP as an example) or licensed under the `Open Publication License`_. 4. Specification -- The technical specification should describe the syntax and semantics of any new language feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Python platforms (CPython, Jython, Python .NET). 5. Motivation -- The motivation is critical for PEPs that want to change the Python language. It should clearly explain why the existing language specification is inadequate to address the problem that the PEP solves. PEP submissions without sufficient motivation may be rejected outright. 6. Rationale -- The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should provide evidence of consensus within the community and discuss important objections or concerns raised during discussion. 7. Backwards Compatibility -- All PEPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The PEP must explain how the author proposes to deal with these incompatibilities. PEP submissions without a sufficient backwards compatibility treatise may be rejected outright. 8. Reference Implementation -- The reference implementation must be completed before any PEP is given status "Final", but it need not be completed before the PEP is accepted. It is better to finish the specification and rationale first and reach consensus on it before writing code. The final implementation must include test code and documentation appropriate for either the Python language reference or the standard library reference. PEP Formats and Templates ========================= There are two PEP formats available to authors: plaintext and reStructuredText_. Plaintext PEPs are written in plain ASCII text, contain minimal structural markup, and should adhere to a rigid style. PEP 9 contains a boilerplate template [3]_ you can use to get started writing your plaintext PEP. ReStructuredText_ PEPs allow for rich markup that is still quite easy to read, but results in much better-looking and more functional HTML. PEP 12 contains a boilerplate template [4]_ for use with reStructuredText PEPs. There is a Python script that converts both styles of PEPs to HTML for viewing on the web [5]_. Parsing and conversion of plaintext PEPs is self-contained within the script. reStructuredText PEPs are parsed and converted by Docutils_ code called from the script. PEP Header Preamble =================== Each PEP must begin with an RFC 822 style header preamble. The headers must appear in the following order. Headers marked with "*" are optional and are described below. All other headers are required. :: PEP: <pep number> Title: <pep title> Version: <cvs version string> Last-Modified: <cvs date string> Author: <list of authors' real names and optionally, email addrs> * Discussions-To: <email address> Status: <Draft | Active | Accepted | Deferred | Rejected | Final | Replaced> Type: <Informational | Standards Track> * Content-Type: <text/plain | text/x-rst> * Requires: <pep numbers> Created: <date created on, in dd-mmm-yyyy format> * Python-Version: <version number> Post-History: <dates of postings to python-list and python-dev> * Replaces: <pep number> * Replaced-By: <pep number> The Author header lists the names, and optionally the email addresses of all the authors/owners of the PEP. The format of the Author header value must be Random J. User <address(a)dom.ain> if the email address is included, and just Random J. User if the address is not given. For historical reasons the format "address(a)dom.ain (Random J. User)" may appear in a PEP, however new PEPs must use the mandated format above, and it is acceptable to change to this format when PEPs are updated. If there are multiple authors, each should be on a separate line following RFC 2822 continuation line conventions. Note that personal email addresses in PEPs will be obscured as a defense against spam harvesters. While a PEP is in private discussions (usually during the initial Draft phase), a Discussions-To header will indicate the mailing list or URL where the PEP is being discussed. No Discussions-To header is necessary if the PEP is being discussed privately with the author, or on the python-list or python-dev email mailing lists. Note that email addresses in the Discussions-To header will not be obscured. The Type header specifies the type of PEP: Informational or Standards Track. The format of a PEP is specified with a Content-Type header. The acceptable values are "text/plain" for plaintext PEPs (see PEP 9 [3]_) and "text/x-rst" for reStructuredText PEPs (see PEP 12 [4]_). Plaintext ("text/plain") is the default if no Content-Type header is present. The Created header records the date that the PEP was assigned a number, while Post-History is used to record the dates of when new versions of the PEP are posted to python-list and/or python-dev. Both headers should be in dd-mmm-yyyy format, e.g. 14-Aug-2001. Standards Track PEPs must have a Python-Version header which indicates the version of Python that the feature will be released with. Informational PEPs do not need a Python-Version header. PEPs may have a Requires header, indicating the PEP numbers that this PEP depends on. PEPs may also have a Replaced-By header indicating that a PEP has been rendered obsolete by a later document; the value is the number of the PEP that replaces the current document. The newer PEP must have a Replaces header containing the number of the PEP that it rendered obsolete. Reporting PEP Bugs, or Submitting PEP Updates ============================================= How you report a bug, or submit a PEP update depends on several factors, such as the maturity of the PEP, the preferences of the PEP author, and the nature of your comments. For the early draft stages of the PEP, it's probably best to send your comments and changes directly to the PEP author. For more mature, or finished PEPs you may want to submit corrections to the SourceForge `bug manager`_ or better yet, the SourceForge `patch manager`_ so that your changes don't get lost. If the PEP author is a SF developer, assign the bug/patch to him, otherwise assign it to the PEP editor. When in doubt about where to send your changes, please check first with the PEP author and/or PEP editor. PEP authors who are also SF committers, can update the PEPs themselves by using "cvs commit" to commit their changes. Remember to also push the formatted PEP text out to the web by doing the following:: % python pep2html.py -i NUM where NUM is the number of the PEP you want to push out. See :: % python pep2html.py --help for details. Transferring PEP Ownership ========================== It occasionally becomes necessary to transfer ownership of PEPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred PEP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the PEP process, or has fallen off the face of the 'net (i.e. is unreachable or not responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the PEP. We try to build consensus around a PEP, but if that's not possible, you can always submit a competing PEP. If you are interested in assuming ownership of a PEP, send a message asking to take over, addressed to both the original author and the PEP editor <peps(a)python.org>. If the original author doesn't respond to email in a timely manner, the PEP editor will make a unilateral decision (it's not like such decisions can't be reversed :). References and Footnotes ======================== .. [1] This historical record is available by the normal CVS commands for retrieving older revisions. For those without direct access to the CVS tree, you can browse the current and past PEP revisions via the SourceForge web site at http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/peps/ .. [2] PEP 2, Procedure for Adding New Modules, Faassen (http://www.python.org/peps/pep-0002.html) .. [3] PEP 9, Sample Plaintext PEP Template, Warsaw (http://www.python.org/peps/pep-0009.html) .. [4] PEP 12, Sample reStructuredText PEP Template, Goodger, Warsaw (http://www.python.org/peps/pep-0012.html) .. [5] The script referred to here is pep2html.py, which lives in the same directory in the CVS tree as the PEPs themselves. Try ``pep2html.py --help`` for details. The URL for viewing PEPs on the web is http://www.python.org/peps/. .. _patch manager: http://sourceforge.net/tracker/?group_id=5470&atid=305470 .. _feature request tracker: http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse .. _Open Publication License: http://www.opencontent.org/openpub/ .. _reStructuredText: http://docutils.sourceforge.net/rst.html .. _Docutils: http://docutils.sourceforge.net/ .. _bug manager: http://sourceforge.net/tracker/?group_id=5470&atid=105470 Copyright ========= This document has been placed in the public domain. -- David Goodger <http://starship.python.net/~goodger> Python Enhancement Proposal (PEP) Editor <http://www.python.org/peps/> (Please cc: all PEP correspondence to <peps(a)python.org>.)

1 0

ANN: numarray-0.5 released
by Todd Miller 03 May '03

03 May '03

Release Notes for numarray-0.5 Numarray is an array processing package designed to efficiently manipulate large multi-dimensional arrays. Numarray is modelled after Numeric and features c-code generated from python template scripts, the capacity to operate directly on arrays in files, and improved type promotions. I. ENHANCEMENTS 1. Universal Function Overhead Reduction The constant time overhead for most universal functions has been reduced by a factor of 10-20. This results in better performance for small arrays. 2. FFT mode and IRAF boundary modes added to Convolve.convolve2d There's now an FFT switch for the 2d convolution function in the Convolve package; when set to 1, convolution is performed via the FFT rather than using the naiive algorithm. In addition, convolve2d now supports boundary modes which are identical to IRAF's convolution function. 3. Numarray is now supported by f2py Numarray numerical arrays can now be used with f2py wrappers for Fortran code. To compile f2py wrapped extensions for numarray, use the switch -DNUMARRAY on the f2py command line. Support is currently restricted to f77 and numerical arrays. II. BUGS FIXED 650926 exotic type coercions 653424 Convolve.boxcar boundary bug 653429 python setup.py build 654669 array index by list 655942 logical operator reductions 657058 inverse real fft bug 677796 byteswap not working 709956 error summing over large boolean arrays 710480 MLab.median makes unnecessary msort call 714537 conjugate function changes its argument See http://sourceforge.net/tracker/?atid=450446&group_id=1369&func=browse for more details. III. CAUTIONS 1. Due to some module renamings, numarray-0.5 will not install correctly on top of an existing numarray installation. Before installing numarray-0.5 remove your old version of numarray. 2. Due to reorganization of the C-API, numarray extensions must be recompiled. 3. For numarray-0.5 and up, the byteswap related methods have been redefined: a.byteswap() swaps but leaves byteorder alone a.togglebyteorder() Does "big" <-> "little" a._byteswap() now an alias for byteswap a._togglebyteorder() deleted 4. round() has been deprecated. Use around() instead. WHERE ----------- Numarray-0.5 windows executable installers, source code, and manual is here: http://sourceforge.net/project/showfiles.php?group_id=1369 Numarray is hosted by Source Forge in the same project which hosts Numeric: http://sourceforge.net/projects/numpy/ The web page for Numarray information is at: http://stsdas.stsci.edu/numarray/index.html Trackers for Numarray Bugs, Feature Requests, Support, and Patches are at the Source Forge project for NumPy at: http://sourceforge.net/tracker/?group_id=1369 REQUIREMENTS ------------------------------ numarray-0.5 requires Python 2.2.2 or greater. AUTHORS, LICENSE ------------------------------ Numarray was written by Perry Greenfield, Rick White, Todd Miller, JC Hsu, Paul Barrett, Phil Hodge at the Space Telescope Science Institute. Thanks go to Jochen Kupper of the University of North Carolina for his work on Numarray and for porting the Numarray manual to TeX format. Thanks also to Edward C. Jones, Francesc Alted, Paul Dubois, Eric Jones, Travis Oliphant, Pearu Peterson and everyone who has contributed with comments and feedback. Numarray is made available under a BSD-style License. See LICENSE.txt in the source distribution for details. -- Todd Miller jmiller(a)stsci.edu

1 0

ANN: apm.py 0.3.0
by Tilo Riemer 01 May '03

01 May '03

Hello, apm.py 0.3.0 is out. DESCRIPTION: apm.py is a python module providing of an uniform and platform independent interface to APM. At the moment it implements only battery relevant functions. WHATS NEW: 1. Support for FreeBSD 4 (tested with FreeBSD 4.8) and OpenBSD (untested) 2. Fix in NetBSD where the charging state could be wrong. HOMEPAGE: http://www.iapp.de/~riemer/projects/apm.py/ Best regards, Tilo

1 0