Mailman 3 September 2004 - Python-announce-list

ANN: SQLObject 0.6 (and 0.5.3)
by Ian Bicking 22 Sep '04

22 Sep '04

I've made a long-overdue release of SQLObject 0.6, and a final bug-fix release for the 0.5 series. What is SQLObject ================= SQLObject is an object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL, PostgreSQL, SQLite, and Firebird. It also has newly added support for Sybase and MaxDB (also known as SAPDB). Where is SQLObject ================== Site: http://sqlobject.org Mailing list: https://lists.sourceforge.net/mailman/listinfo/sqlobject-discuss Archives: http://news.gmane.org/gmane.comp.python.sqlobject Download: http://prdownloads.sourceforge.net/sqlobject/SQLObject-0.6.tar.gz?download News and changes: http://sqlobject.org/docs/News.html What's New ========== In 0.5.3: some small bug fixes, and an important fix when iterating over selects in threaded environments. In 0.6: The "SQLObject" module has been renamed "sqlobject". To fetch objects from the database, use MyClass.get(id) (instead of MyClass(id)). To create/insert objects, use MyClass(col=value, ...) (instead of MyClass.new(col=value, ...)). Better support for constraints. Connections given using URLs, like 'mysql://user:pass@localhost/dbname' Optional lazy updates -- SQL UPDATE executed only on demand. For a more complete list, please see the news: http://sqlobject.org/docs/News.html -- Ian Bicking / ianb(a)colorstudy.com / http://blog.ianbicking.org

1 0

1 day to early registration deadline for Middleware'04
by Middleware 04 22 Sep '04

22 Sep '04

********************************************************** ***** 1 day left to early registration deadline for ***** ***** ACM/IFIP/USENIX Middleware 2004 ***** ********************************************************** ACM/IFIP/USENIX Middleware 2004 Call for Participation Renaissance Toronto Hotel at SkyDome Toronto, Ontario, Canada October 18th - 22nd, 2004 http://www.eecg.utoronto.ca/middleware2004/ Important Dates: Early Registration Rate Ends: 22 September 2004 Last Day to Pre-Register: 06 October 2004 Hotel Cut-Off Date: 25 September 2004 Hotel room reservations (Canada/US): 1-800-237-1512 Program Summary: For details and exact dates see: http://www.eecg.utoronto.ca/middleware2004/ Keynotes: How Wrong Can You Be? Getting Lost on the Road to Massive Scalability Werner Vogels, Director of Systems Research, Amazon.com Experiences Building a 24x7 Real-time ASP Service at Citrix Online Thorsten von Eicken, Chief Architect, Citrix Online Aspect-Oriented Programming - The promise and the controversy Gregor Kiczales, University of British Columbia Main conference program Single-track conference with 26 technical paper presentations and 6 work-in-progress presentations. For details see http://www.eecg.toronto.edu/middleware2004/programstruct.htm Tutorials (Monday and Tuesday): Building Distributed .NET Applications - Technologies, Architecture, Comparison with J2EE. By Michael Stal, Siemens AG Germany (Monday, full day.) Getting Started with Aspect-Oriented Programming for Middleware. By Yvonne Coady, University of Victoria, Canada (Monday, morning.) Middleware and Data Management for Sensor Networks. By Nalini Venkatasubramanian, University of California, Irvine, USA and Sharad Mehrotra,University of California, Irvine, USA (Tuesday, morning.) Enterprise Integration Patterns: Asynchronous Messaging Architectures in Practice. By Gregor Hohpe, ThoughtWorks Inc., USA (Tuesday, morning.) Data Grid Management Systems. By Arun Swaran Jagatheesan, University of California, San Diego, USA (Tuesday, afternoon.) DDS: The Real-Time Publish-Subscribe Standard for Data Distribution By Gerardo Pardo-Castellote, Real-Time Innovations Inc., USA (Tuesday, afternoon.) Workshops (Monday and Tuesday): 2nd Workshop on Middleware for Grid Computing. Organizers: Bruno Schulze - National Scientific Computing Laboratory (Brazil) and Radha Nandkumar - NCSA/UIUC (USA) (Monday, October 18th.) 2nd Workshop on Middleware for Pervasive and Ad-Hoc Computing Organizer: Paddy Nixon - Strathclyde University (UK) (Monday, October 18th.) 3rd Workshop on Adaptive and Reflective Middleware. Organizer: Fabio Costa, Federal University of Goi�s - (Brazil) and Nanbor Wang - Tech-X Corporation (USA) (Tuesday, October 19th.) 1st Middleware Doctoral Symposium. Organizers: Edward Curry - National University of Ireland (Ireland) and Doug Lea - SUNY Oswego (USA) (Tuesday, October 19th.) ---

1 0

SIP v4.1 Released (C/C++ Wrapper Generator)
by Phil Thompson 20 Sep '04

20 Sep '04

Riverbank Computing is pleased to announce the release of SIP v4.1 available from http://www.riverbankcomputing.co.uk/. SIP is a tool for generating Python modules that wrap C or C++ libraries. It is similar to SWIG. Its main use to date has been to generate PyQt and PyKDE. While SIP has been around since 1998, this is the first major release that is fully documented (see http://www.river-bank.demon.co.uk/docs/sip/sipref.html). SIP is licensed under the Python License and runs on Windows, UNIX, Linux and MacOS/X. SIP requires Python v2.3 or later (SIP v3.x is available to support earlier versions of Python). This release includes the following changes: - a new cast() function in the sip module - a number of small enhancements to the C++ support - the build system supports MSVC.NET. Other features of SIP include: - support for Python new-style classes - generated modules are quick to import, even for large libraries - support for Qt's signal/slot mechanism - thread support - the ability to re-implement C++ abstract and virtual methods in Python - the ability to define Python classes that derive from abstract C++ classes - the ability to spread a class hierarchy across multiple Python modules - support for C++ namespaces - support for C++ exceptions - support for C++ operators - an extensible build system written in Python that supports over 50 platform/compiler combinations.

1 0

Dr. Dobb's Python-URL! - weekly Python news and links (Sep 20)
by Cameron Laird 20 Sep '04

20 Sep '04

QOTW: "The advantage of using slices to extract a single element is that it avoids IndexErrors for empty lists." Raymond Hettinger http://groups.google.com/groups?th=44bd04fe85d02c19 "Usually when you feel that you need to generate instances with certain names you are on the wrong track in translating the problem you need to solve into a program. " Istvan Albert http://groups.google.com/groups?frame=left&th=6ce53556b4307fb5 Michael Sparks, David Mertz, Patrick Maupin, Bengt Richter, and others deepen discussion, mentioned last week, of greenlets, co-routines, and related matters. Particularly note explanations of confusing labels. http://groups.google.com/groups?frame=left&th=ca4b3ec6501d42aa Bengt Richter and Lonnie Princehouse provide substantial examples of Python-based (lexical) parsing. http://groups.google.com/groups?frame=left&th=795e46367a16d38 'Need to track every object in the solar system? Erik Max Francis' Python coding makes it "simple but useful". http://groups.google.com/groups?th=744df8e93a7a5e5e Opportunity: if you'll be at this year's SANE in Amsterdam, help proselytize at the Python Software Foundation stand. http://groups.google.com/groups?th=c916b2fefd4e878d Wayne Pierce bases nascent Security Advisor's security auditing on filesystem and service scans. Python makes it all comprehensible. http://groups.google.com/groups?th=4387aeb99f5c49d2 Alex Martelli provides a model for "self-updating" Python-coded software. http://groups.google.com/groups?selm=1gkazd2.1qm3g0u1l6b7lmN%25aleaxit%40ya… Of course, for Alex, "somedict.get(x, x) [is] a *frequent* Python idiom". http://groups.google.com/groups?frame=left&th=3c7dc03a05fa8d1 Yet another distribution? Ubuntu Linux is an ambitious and Python-oriented one. http://www.ubuntulinux.org/ ======================================================================== Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce Brett Cannon continues the marvelous tradition established by Andrew Kuchling and Michael Hudson of intelligently summarizing action on the python-dev mailing list once every other week. http://www.python.org/dev/summary/ The Python Package Index catalogues packages. http://www.python.org/pypi/ The somewhat older Vaults of Parnassus ambitiously collects references to all sorts of Python resources. http://www.vex.net/~x/parnassus/ Much of Python's real work takes place on Special-Interest Group mailing lists http://www.python.org/sigs/ The Python Business Forum "further[s] the interests of companies that base their business on ... Python." http://www.python-in-business.org Python Success Stories--from air-traffic control to on-line match-making--can inspire you or decision-makers to whom you're subject with a vision of what the language makes practical. http://www.pythonology.com/success The Python Software Foundation (PSF) has replaced the Python Consortium as an independent nexus of activity. It has official responsibility for Python's development and maintenance. http://www.python.org/psf/ Among the ways you can support PSF is with a donation. http://www.python.org/psf/donate.html Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://python.sourceforge.net/peps/pep-0042.html The online Python Journal is posted at pythonjournal.cognizor.com. editor(a)pythonjournal.com and editor(a)pythonjournal.cognizor.com welcome submission of material that helps people's understanding of Python use, and offer Web presentation of your work. *Py: the Journal of the Python Language* http://www.pyzine.com Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.pyth… Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ http://purl.org/thecliff/python/url.html (dormant) or http://groups.google.com/groups?oi=djq&as_q=+Python-URL!&as_ugroup=comp.lan… Suggestions/corrections for next week's posting are always welcome. E-mail to <Python-URL(a)phaseit.net> should get through. To receive a new issue of this posting in e-mail each Monday morning (approximately), ask <claird(a)phaseit.net> to subscribe. Mention "Python-URL!". -- The Python-URL! Team-- Dr. Dobb's Journal (http://www.ddj.com) is pleased to participate in and sponsor the "Python-URL!" project.

1 0

ANN: TG Framework - Milestone Release 1.0a1
by TechGame Framework 20 Sep '04

20 Sep '04

=========================================== ANN: TG Framework - Milestone Release 1.0a1 =========================================== The `TechGame Framework for Python`_ is a toolkit for skinning (building) GUIs using a blend of XML, CSS, and Python. The workflow using this framework is similar to standard GUI development with a twist of web design thrown in. The `skinning framework`_ is a generalized engine to build objects from XML. To this engine, we have added an XML namespace 'TG.skinning.toolkits.wx' for our binding with the excellent `wxPython libraries`_. Using the skinning framework to factor your wxPython GUI into an XML form allows for a nice layer of insulation between GUI manipulation and model code. And once that separation is accomplished, you can even go to the point of replacing your GUI skin dynamically. Additionally, employing the `CSS facilities`_ allows you to localize choices about the look and feel of interfaces across the breadth of your application. Then, *when* you change your mind, you can quickly test your ideas by changing the stylesheet. Or, in a more sophisticated application, change styles to match the platform you are running on. If you are interested, please read more about the TG Framework at the `project website`_, as well as download the `1.0a1 Milestone Release`_. You also might be interested in our `CSS tools`_ separate from the framework. They are packaged in parallel with the framework, and can also be found on the `release page`_. .. _1.0a1 Milestone Release: .. _release page: http://www.techgame.net/projects/Framework/wiki/MilestoneRelease1.0a1 .. _TechGame Framework for Python: .. _project website: http://www.techgame.net/projects/Framework/wiki/WikiStart .. _CSS tools: .. _CSS facilities: http://www.techgame.net/projects/Framework/wiki/CSSEngine .. _skinning framework: http://www.techgame.net/projects/Framework/wiki/SkinningFramework .. _wxPython libraries: http://wxpython.org This framework is not... ======================== This framework is **not** intended to be a tool to convert code between different GUI toolkits. Rather, think of it binding XML, CSS and Python to specific GUI toolkits; namely wxPython. However, there is no reason bindings cannot be written for PyQT, or PyGTK, or win32, or Tkinter! Please contact us if you are interested in doing so, and we will do our best to support your effort! About the 1.0a1 Release ======================= This is our first alpha release, and we confess that our documentation is pretty much non-existent. So very sorry! (It took longer to write the release documents than the first CSS parser!) Look forward to better documentation in 1.0a2! However, despite the alpha release, the skinning engine is quite mature, with this being the fourth evolution of the technology. Major alpha areas are the CSS Engine and the URI Resolution tools. License ======= The TechGame Framework is OSI Certified Open Source Software using a `BSD-style license`_. .. _BSD-style license: http://www.techgame.net/projects/Framework/wiki/License Contact ======= Please send questions, comments, patches, and suggestions to *framework* at *TechGame.net*. Please open `new tickets`_ for bugs you find. .. _new tickets: http://www.techgame.net/projects/Framework/newticket :: <P><A HREF="http://techgame.net/projects/Framework/wiki"> TechGame Framework</A> - a toolkit for skinning GUIs using a blend of XML, CSS, and Python. (19-Sep-04) </P>

1 0

python-dev Summary for 2004-08-16 through 2004-08-31
by Brett C 19 Sep '04

19 Sep '04

python-dev Summary for 2004-08-16 through 2004-08-31 ++++++++++++++++++++++++++++++++++++++++++++++++++++ This is a summary of traffic on the `python-dev mailing list`_ from August 16, 2004 through August 31, 2004. It is intended to inform the wider Python community of on-going developments on the list. To comment on anything mentioned here, just post to `comp.lang.python`_ (or email python-list(a)python.org which is a gateway to the newsgroup) with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join `python-dev`_! This is the forty-seventh summary written by Brett Cannon (new type of coverage, same kind of sarcasm). To contact me, please send email to brett at python.org ; I do not have the time to keep up on comp.lang.python and thus do not always catch follow-ups posted there. All summaries are archived at http://www.python.org/dev/summary/ . Please note that this summary is written using reStructuredText_ which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it, although I suggest learning reST; it's simple and is accepted for `PEP markup`_ and gives some perks for the HTML output. Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _PEP Markup: http://www.python.org/peps/pep-0012.html The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation on new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to forward the development and use of Python. But the PSF_ cannot do this without donations. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation (you can donate through PayPal or by check) helps. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. contents:: .. _last summary: http://www.python.org/dev/summary/2004-08-16_2004-08-31.html .. _original text file: http://www.python.org/dev/summary/2004-08-16_2004-08-31.ht ===================== Summary Announcements ===================== After asking people last week about how they wanted me to change the python-dev Summary as as to allow me to retain my free time, all respondents unanimously went with the option of letting me choose what I wanted to cover. That made me happy for a couple of reasons. One is that it makes the summaries more enjoyable for me since I mostly cover stuff I like and thus should be less bored at points while writing. It also flattering in a way that people trusted what I would cover enough to not want to suggest what I should cover. It also allows me to spend more time on python-dev participating than sitting on the sidelines dreading have to summarize some 100 email thread on whether we should move over to VC 7 or something (can you tell I was bored out of my skull by that thread?). So this summary starts the new coverage style. As you can see it is much shorter than normal since I didn't try to be as thorough (7 pages compared to the usual 10-20). But I think this style allows what I do summarize to have more details than it would normally have; quality over quantity. I have reintroduced the "Skipped Threads" section of the Summaries so people can see what I skipped in case there is something they might want to read that I just didn't care about. In places where I remember something partially relevant I added a sentence on it so it isn't just a list of subject lines. Enjoy. ========= Summaries ========= ------------- PEP movements ------------- `PEP 3000`_ (Python 3.0 Plans) came into creation. This text's point of existence is to list changes known to be planned for Python 3.0 and not hypothetical (Guido suggested all hypothetical talk call the version Python 3000, partially for marketing purposes). Plus I am a co-author and it finally completes my time in the `School of Hard Knocks`_. =) `PEP 333`_ (Python Web Server Gateway Interface v1.0) proposes a "standard interface between web servers and Python web applications or frameworks, to promote web application portability across a variety of web servers". `PEP 309`_ (Partial Function Application) was updated with some details. `PEP 334`_ (Simple Coroutines via SuspendIteration) came into existence to suggest coming up with some form of lightweight coroutines. .. _School of Hard Knocks: http://mail.python.org/pipermail/python-dev/2002-September/028725.html .. _PEP 3000: http://www.python.org/peps/pep-3000.html .. _PEP 333: http://www.python.org/peps/pep-0333.html .. _PEP 309: http://www.python.org/peps/pep-0309.html .. _PEP 334: http://www.python.org/peps/pep-0334.html Contributing threads: - `Minimal 'stackless' PEP using generators? <http://mail.python.org/pipermail/python-dev/2004-August/048239.html>`__ -------------------------------- Decorators "issue" mostly solved -------------------------------- While the hubbub over using a character for decorators was brewing, people began suggesting reserving a character that would never be used in Python for anything. The thought was that people who wanted to use a character to represent application-specific information could use the reserved symbol and not have to worry about clashing with possible future features like Leo and IPython are with the use of '@'. But no reservation of a character occurred. Towards the end of the month, to meet the a3 deadline, a unified proposal from the community came forward led by Robert Brewer and Michael Sparks. They pushed the J2 proposal:: using: somedecorator staticmethod def func(): pass Guido contemplated the proposal, saying "it got pretty darn close" to being accepted, but in the end decided not to. For Guido's full reasoning see http://mail.python.org/pipermail/python-dev/2004-September/048518.html . But he said he had two key issues. One was the indentation "suggests that its contents should be a sequence of statement, but in fact it is not". Issue two was that using a keyword to start a line was a real attention grabber and that "using" did not deserve this. The topic of how the whole decorators situation was handled was touched upon. He realized that "dramatic changes must be discussed with the community at large". He was also impressed by how the community pulled together to propose an alternative as it did and hopes to see more proposals of the same quality in the future. So now what? Guido said that he would be willing to change the character used for decorators for 2.4b1 . That means if '@' drives you nuts but something else like '!' works for you then speak up and try to get the community to rally behind it. Contributing threads: - `Decorator order implemented backwards? <http://mail.python.org/pipermail/python-dev/2004-August/047512.html>`__ - `Considering decorator syntax on an individual feature <http://mail.python.org/pipermail/python-dev/2004-August/048081.html>`__ - `PEP 318: Suggest we drop it <http://mail.python.org/pipermail/python-dev/2004-August/048025.html>`__ - `__metaclass__ and __author__ are already decorators <http://mail.python.org/pipermail/python-dev/2004-August/048176.html>`__ - `Reserved Characters <http://mail.python.org/pipermail/python-dev/2004-August/048166.html>`__ - `PEP 318: Can't we all just get along? <http://mail.python.org/pipermail/python-dev/2004-August/048213.html>`__ - `Multiple decorators per line <http://mail.python.org/pipermail/python-dev/2004-August/048227.html>`__ - `Important decorator proposal on c.l.p. <http://mail.python.org/pipermail/python-dev/2004-August/048332.html>`__ - `Re: [Python-checkins] python/nondist/peps pep-0318.txt... <http://mail.python.org/pipermail/python-dev/2004-August/048323.html>`__ - `CO_FUTURE_DECORATORS <http://mail.python.org/pipermail/python-dev/2004-August/048354.html>`__ - `decorators: If you go for it, go all the way!!! :) <http://mail.python.org/pipermail/python-dev/2004-August/048378.html>`__ - `Re: Re: def fn (args) [dec,dec]: <http://mail.python.org/pipermail/python-dev/2004-August/048432.html>`__ - `J2 proposal final <http://mail.python.org/pipermail/python-dev/2004-August/048428.html>`__ - `(my) revisions to PEP318 finally done. <http://mail.python.org/pipermail/python-dev/2004-August/048471.html>`__ - `Rejecting the J2 decorators proposal <http://mail.python.org/pipermail/python-dev/2004-September/048518.html>`__ ----------------------------------------------------------- When should something be put under the great powers of -O ? ----------------------------------------------------------- Python has had a simple peephole optimizer in the compiler since 2.3 that optimized imported bytecode. Raymond Hettinger moved it up, though, so that the optimization would be saved to .pyc files and thus remove the need to repeat the process every time. Guido questioned this move. He thought that since it was an optimization it should fall under the -O command-line option. But then people came forward to suggest that Raymond's move was good, saying that the cost of the optimization was non-existent and thus should be used. I brought up the point that a definition of what should be considered an optimization; anything that changes the initial opcode, or something that takes extra time/memory or changes semantics? Tim Peters stepped forward and said that since the optimizations were so simple that he thought they should be kept. David Abrahams also came forward and said they should be kept to get more testing on them since they were not complex and thus did not influence debugging of code. In the end Raymond's change was kept in place. Contributing threads: - `Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320 <http://mail.python.org/pipermail/python-dev/2004-August/048032.html>`__ ---------------------------------------- 2.4a3 out the doors so kick those tires! ---------------------------------------- `Python 2.4a3`_ has been released. As usual, please download it, run the regression tests, and report any errors you get. Since this will be the last alpha this is your last chance to get new features in before b1 comes out. The use of priorities on the SourceForge tracker has also been clarified. Anything set to 9 **must** be dealt with before the next release. Priority 8 is to be dealt with before b1; it changes functionality so if it isn't in by b1 it won't be in until the next version. Priority 7 is for something that should get in before the final release. Anthony Baxter also gained sole control of setting the priority so as to keep the settings consistent. .. _Python 2.4a3: http://www.python.org/2.4/ Contributing threads: - `2.4a3 release is September 2, SF tracker keywords <http://mail.python.org/pipermail/python-dev/2004-August/048078.html>`__ ------------------- Talking about bytes ------------------- Stemming from a conversation about moving Python over to Unicode only for string representation for 3.0, the discussion of a bytes type came up. People were saying they used str to store binary data and that if str went away or no longer represented straight binary data (since Unicode has different encodings the values can change while meaning the same thing in terms of characters) they would need a way to deal with this. The idea that the array module solved this was basically dismissed since it seemed more built-in support was needed for convenience. It also meant more flexibility in terms of what interfaces were implemented. There was also some issues with getting array to work the exact way people wanted it to. The next question was whether literal support was needed. Would you really need to write something like ``b"\x66\x6f\x6f"`` instead of ``bytes([0x66, 0x6f, 0x6f])``? How all of this would play with Unicode ended up being discussed. In the end it seemed that one could encode and decode back and forth but that all work with character should be in Unicode and only decoded into bytes on the I/O barrier (writing to disk or the network, for instance) to minimize any possible encoding errors and to make usage easier. Mutability came up. Being mutable would be handy, but it killed its usage as a dictionary key. It was suggested that bytes hash to a tuple of integers representing the bytes, but nothing more was said. But in general almost everyone agreed that having the bytes type be mutable was best. `PEP 332`_ was sketched out during the early part of this discussion, but has not been updated since it died down. .. _PEP 332: http://www.python.org/peps/pep-0332.html Contributing threads: - `adding a bytes sequence type to Python <http://mail.python.org/pipermail/python-dev/2004-August/047722.html>`__ - `Byte string class hierarchy <http://mail.python.org/pipermail/python-dev/2004-August/048027.html>`__ -------------------------------------------- String substitution sure is a touchy subject -------------------------------------------- PEP 292`_ (Simpler String Substitutions) got a huge amount of discussion this past two weeks. Ignoring the syntax discussions (that was decided long ago before the PEP was accepted and had consensus and thus was a moot point) and the discussion of whether a trailing ``$`` at the end of the substitution pattern should be considered an error or not (it is), a couple of topics were discussed. To make this summary easier to follow, realize that the class that implements PEP 292 is named "Template" and thus I will just refer to the implementation by that name. The first topic was over whether Template should return Unicode objects. The side supporting it pointed out that Python 3.0 was going to be using Unicode for strings exclusively so it would be good to start using them now. It also went with the initial design of PEP 292 which was to help with i18n where Unicode is constantly used. People against, though, didn't want to suddenly be given a Unicode object when a string was used for template string passed in. That would be too surprising and lead to inconsistent usage thanks to sudden mixing of strings and Unicode objects in code. This issue was resolved by no longer subclassing unicode but making it easy to subclass Template so as to add direct Unicode support with ease. The second issue was other the design of the API. Originally Template was a class that overrode __mod__ to make it work like string interpolation works now for str and unicode. But then some people felt a class was too heavy-handed if there was no way to change the way Template worked through a subclass. This obviously led to a desire for functions to do the work for both Template and SafeTemplate (similar class to Template that left in substitution points if they didn't match any values in the dict passed in). In the end the class design was kept thanks to Tim Peters and metaclasses. Tim came up with a neat way to have the regex be generated at class creation time through a metaclass and thus allow subclasses to change how Template matched substitution points and such, all without a performance hit at instance creation time. Use of __mod__ and the SafeTemplate class were removed and Template grew substitute and safe_substitute methods. Practically everyone at this point seems happy with the design so it has been implemented and checked in. .. _PEP 292: http://www.python.org/peps/pep-0292.html Contributing threads: - `Update PEP 292 <http://mail.python.org/pipermail/python-dev/2004-August/048160.html>`__ - `PEP 292 - Simpler String Substitutions <http://mail.python.org/pipermail/python-dev/2004-August/048236.html>`__ - `Alternative Implementation for PEP 292: Simple String Substitutions <http://mail.python.org/pipermail/python-dev/2004-August/048406.html>`__ - `Alternative placeholder delimiters for PEP 292 <http://mail.python.org/pipermail/python-dev/2004-August/048469.html>`__ ------------------------------------------- Private names considered rude in the stdlib ------------------------------------------- Anthony Baxter suggested banning use of mangled private names (names starting with ``__``) in the stdlib. His argument was that they are a hack and the stdlib is supposed to act as a good example and that name mangling was not good. Guido essentially agreed with the caveat that some uses of private names is justified such as if a private name is storing the equivalent of a 'friend' function from C++. Contributing threads: - `__mangled in stdlib considered poor form <http://mail.python.org/pipermail/python-dev/2004-August/048444.html>`__ =============== Skipped Threads =============== Warnocked (i.e., emails that get essentially no response) emails very insignificant threads are not listed - Find out whether PyEval_InitThreads has been called? - Unifying Long Integers and Integers: baseint - test_tempfile failure on Mac OSX - Deprecate sys.exitfunc? - multiple instances of python on XP - Adding 'lexists()' to os.path - #ifdeffery - Weekly Python Bug/Patch Summary - problem with pymalloc on the BeOS port. - Proposed change to logging - sre.py backward compatibility and PEP 291 - Dealing with test__locale failure on OS X before a3 - os.urandom API - Decoding incomplete unicode Basically culminated into new stateful UTF-8 and UTF-16 decoders but that's all I know =) - Decimal module portability to 2.3? Decimal is compatible with 2.3 at least until 2.5 - Python icons If you think you can come up with a good icon for the Windows installer please let c.l.py know and it might get used - [Python-checkins] python/dist/src/Lib/test test_string.py, 1.25, 1.26 - list += string??

1 0

Re: fledgling Python online forum
by sheldonplankton＠yahoo.com 19 Sep '04

19 Sep '04

Hi, I am back from vacation and its looks like we had a power outage. This also caused my ISP to assign me a new IP address. Snakehanders is now at http://216.175.112.88. We could really use a regular home. Can anyone make a suggestion? Thanks for you support! Plankton sheldonplankton(a)yahoo.com (Sheldon Plankton) wrote in message news:<mailman.3192.1094913557.5135.python-announce-list(a)python.org>... > Hi, > > I have put together a prototype of a Python Programmmers forum. > It is similar to perlmonk.org, yet not as advanced in functionality. > If such a site might interest you please visit it at http://66.32.187.134 > I haven't chosen where I'll eventually host the site. Why not take a look > and post a commment? > > Thanks > Plankton

1 0

ANN: BOTEC 0.2 -- An astrophysical and orbital mechanics calculator
by Erik Max Francis 19 Sep '04

19 Sep '04

Summary BOTEC is a simple astrophysical and orbital mechanics calculator, including a database of all named Solar System objects. Overview BOTEC is intended as a simple but useful calculator to assist with making astrophysical, orbital mechanics, and space navigation calculations. As the origin of the acronym applies, BOTEC is more of a "back-of-the-envelope calculator" rather than an industrial-strength calculator, although this may change in the future. BOTEC is primarily intended for people familiar with physics and Python, and as such is unlikely to be useful to the average enduser. BOTEC really consists of two parts: The BOTEC software, which knows what to do with the data, and the Solar System data itself, which is represented in a large data file (a Python pickle, actually). This is deliberately modularized so that the Solar System data BOTEC uses can be updated independently of thet software, and also that alternative data files (*e.g.*, hypothetical stellar systems for fictional purposes) can be supported. All values are strictly in SI units. Getting the software The current version of botec is 0.2. The latest version of the software is available in a tarball here: http://www.alcyone.com/software/botec/botec-latest.tar.gz. The official URL for this Web site is http://www.alcyone.com/software/botec/. Requirements BOTEC requires Python 2.3. In its present state, BOTEC will also not be of much use to endusers not familiar with Python, or people without some basic working knowledge of physics, astrophysics, orbital mechanics, and space navigation. License This code is released under the GPL. ... Author This module was written by "Erik Max Francis", http://www.alcyone.com/max/. If you use this software, have suggestions for future releases, or bug reports, I'd love to hear about it. Version Version 0.2 $Date: 2004/09/18 $ $Author: max $ -- __ Erik Max Francis && max(a)alcyone.com && http://www.alcyone.com/max/ / \ San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis \__/ Let he who does not know what war is go to war. -- (a Spanish proverb)

1 0

Middleware'04 Call for Participation and Program Update
by Middleware 04 17 Sep '04

17 Sep '04

ACM/IFIP/USENIX Middleware 2004 Call for Participation Renaissance Toronto Hotel at SkyDome Toronto, Ontario, Canada October 18th - 22nd, 2004 http://www.eecg.utoronto.ca/middleware2004/ Important Dates: Early Registration Rate Ends: 22 September 2004 Last Day to Pre-Register: 06 October 2004 Hotel Cut-Off Date: 25 September 2004 Hotel room reservations (Canada/US): 1-800-237-1512 Program Summary: For details and exact dates see: http://www.eecg.utoronto.ca/middleware2004/ Keynotes: How Wrong Can You Be? Getting Lost on the Road to Massive Scalability Werner Vogels, Director of Systems Research, Amazon.com Experiences Building a 24x7 Real-time ASP Service at Citrix Online Thorsten von Eicken, Chief Architect, Citrix Online Aspect-Oriented Programming - The promise and the controversy Gregor Kiczales, University of British Columbia Main conference program Single-track conference with 26 technical paper presentations and 6 work-in-progress presentations. For details see http://www.eecg.toronto.edu/middleware2004/programstruct.htm Tutorials (Monday and Tuesday): Building Distributed .NET Applications - Technologies, Architecture, Comparison with J2EE. By Michael Stal, Siemens AG Germany (Monday, full day.) Getting Started with Aspect-Oriented Programming for Middleware. By Yvonne Coady, University of Victoria, Canada (Monday, morning.) Middleware and Data Management for Sensor Networks. By Nalini Venkatasubramanian, University of California, Irvine, USA and Sharad Mehrotra,University of California, Irvine, USA (Tuesday, morning.) Enterprise Integration Patterns: Asynchronous Messaging Architectures in Practice. By Gregor Hohpe, ThoughtWorks Inc., USA (Tuesday, morning.) Data Grid Management Systems. By Arun Swaran Jagatheesan, University of California, San Diego, USA (Tuesday, afternoon.) DDS: The Real-Time Publish-Subscribe Standard for Data Distribution By Gerardo Pardo-Castellote, Real-Time Innovations Inc., USA (Tuesday, afternoon.) Workshops (Monday and Tuesday): 2nd Workshop on Middleware for Grid Computing. Organizers: Bruno Schulze - National Scientific Computing Laboratory (Brazil) and Radha Nandkumar - NCSA/UIUC (USA) (Monday, October 18th.) 2nd Workshop on Middleware for Pervasive and Ad-Hoc Computing Organizer: Paddy Nixon - Strathclyde University (UK) (Monday, October 18th.) 3rd Workshop on Adaptive and Reflective Middleware. Organizer: Fabio Costa, Federal University of Goi�s - (Brazil) and Nanbor Wang - Tech-X Corporation (USA) (Tuesday, October 19th.) 1st Middleware Doctoral Symposium. Organizers: Edward Curry - National University of Ireland (Ireland) and Doug Lea - SUNY Oswego (USA) (Tuesday, October 19th.) ---

1 0

ctypes 0.9.1 released
by Thomas Heller 16 Sep '04

16 Sep '04

ctypes 0.9.1 released - Sept 14, 2004 ===================================== Overview ctypes is a ffi (Foreign Function Interface) package for Python 2.3 and higher. ctypes allows to call functions exposed from dlls/shared libraries and has extensive facilities to create, access and manipulate simple and complicated C data types in Python - in other words: wrap libraries in pure Python. It is even possible to implement C callback functions in pure Python. ctypes runs on Windows, MacOS X, Linux, Solaris, FreeBSD. It may also run on other systems, provided that libffi supports this platform. On windows, ctypes contains a ctypes.com package which allows to call and implement custom COM interfaces. Changes in 0.9.1 ctypes 0.9.1 should be fully compatible again with Gary Bishop's readline module which is also used by IPython. ctypes changes The internal conversions that ctypes does between unicode and strings can now use a specified encoding and error handling. A set_conversion_mode() function allows to set them, it returns the previous values. The inital values are ('mbcs', 'ignore') on Windows, and ('ascii', 'strict') on other systems. When internal processing of an argument for a function call fails, the new ctypes.ArgumentError is raised. CDLL and its subclasses now accept an optional second handle parameter. If this is supplied, it is used instead of calling LoadLibrary() or dlopen() to get one. Sometimes objects have been freed too early when calling functions where argtypes have been set. Fixed the create_unicode_buffer function - it was returning c_char arrays instead of c_wchar arrays. Both create_string_buffer and create_unicode_buffer can now be called with string and unicode instances, they will do the needed conversions themselves. ctypes now allows calling Python C api functions. The 'pythonapi' symbol should be used to access these functions, this will automatically use the correct calling convention and exception handling. The 'py_object' type is the ctypes variant of 'PyObject *'. This feature should also work if you are using a static python build. It is now possible to call cdecl functions with more arguments than the length of the argtypes sequence specifies - this allows to provide functions like sprintf() with a proper prototype. It is now possible to create strings or unicode strings if you have the integer address by calling c_char_p(address) or c_wchar_p(address). Integers can also be assigned to structure fields of type c_char_p and c_wchar_p. c_char_p and c_wchar_p both accept strings and unicode strings - if needed they are encoded or decoded using 'strict' error handling. The _ctypes.call_function function, although private and deprecated, has been put back in - it is used by Gary Bishop's readline module. Array and pointer instances now support slicing, for pointers only getslice is implemented (setslice is too dangerous, probably). Slices are represented as lists of the elements, except for character and unicode character pointer and arrays, where strings resp. unicode strings are used instead. On windows, the include files were missing from the source distribution. The alignment function was not exported by the ctypes module. It returns the alignment requirements in bytes of a type or instance. ctypes.com changes Applied a patch from Bruce Dodson which fixes an infinite loop in readtlb.py if a typelib references types defined in another typelib. readtlb still generates bad code for such cases, but the results could be edited by hand if the dependencies can be sorted out. ctypes now caches the types that WINFUNCTYPE and CFUNCTYPE creates, to avoid unneeeded creation of classes. This makes importing files containing a lot of COM interfaces (like the ones that the readtlb tool generates) a lot (10 x) faster. COM servers now print a short usage message when they are run without the /regserver or /unregserver flag. VARIANT does now handle the COM DATE type (VT_DATE) as Python datetime. VARIANT now handles integers and longs correctly - if longs are too large they are stored as doubles (VT_R8). Integers are now stored as VT_I4 instead of VT_INT. Detailed changelogs are in CVS: <http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/ChangeLog?rev=HEAD> <http://cvs.sourceforge.net/viewcvs.py/ctypes/ctypes/win32/com/ChangeLog?rev…> Future plans The ultimate purpose of the 0.9 release series is to shake out the remaining bugs, especially on platforms I have no access to, and to target a rock stable ctypes 1.0 release. When ctypes 1.0 is released, the com framework will be split off into a separate framework named 'comtypes'. Download Downloads are available in the sourceforge files section <http://sourceforge.net/project/showfiles.php?group_id=71702> Separate source distributions are available for windows and non-windows systems. Please use the .zip file for Windows (it contains the ctypes.com framework), and use the .tar.gz file for non-Windows systems (it contains the complete cross-platform libffi sources). Binary windows installers, which contain compiled extension modules, are also available, be sure to download the correct one for the Python version you are using. Homepage <http://starship.python.net/crew/theller/ctypes/> Enjoy, Thomas

1 0