Mailman 3 March 2005 - Python-announce-list

Chicago Python Group, Thurs March 10
by Ian Bicking March 8, 2005

March 8, 2005

The Chicago Python User Group, ChiPy, will have its next meeting on Thursday, March 10, starting at 7pm. For more information on ChiPy see http://chipy.org Presentations ------------- This week we will have two presentations. Robert Ramsdell will talk about SimPy. SimPy (Simulation in Python) is an object-oriented, process-based discrete-event simulation language based on standard Python. It provides the modeler with components of a simulation model including processes, for active components like customers, messages, and vehicles, and resources, for passive components that form limited capacity congestion points like servers, checkout counters, and tunnels. It also provides monitor variables to aid in gathering statistics. Ian Bicking will be presenting on WSGI, WSGIKit, and Python web programming. WSGI is a new Python standard for interfacing between web servers (like Apache or Twisted) and web applications. WSGIKit is a reimplementation of Webware for Python using a series of WSGI components. He will be talking about its design and utilization of WSGI to create cross-framework libraries. Location -------- This month we will be having our first suburban meeting, in Downer's Grove: Acxiom 3333 Finley Road Downer's Grove Near the intersection of I-355 and Buttefield Road. Convenient to Fry's! Parking is plentiful. Some people are carpooling from the city -- contact the mailing list if you are interested.chiPy(a)lonelylion.com About ChiPy ----------- We meet once amonth, on the second Thursday of the month. If you can't come this month, please join our mailing list: http://lonelylion.com/mailman/listinfo/chipy

1 0

python-dev Summary for 2005-02-15 through 2005-02-28
by Brett C. March 8, 2005

March 8, 2005

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-02-15_2005-02-28.html] ===================== Summary Announcements ===================== ------------------------ Status of the candidates ------------------------ It looks like all three candidates for taking over the Summaries (Tony Meyer, Steven Bethard, and Tim Lesher) have agreed to actually do the Summaries together. SO no break in the Summaries and I don't have to agonize over choosing a successor. ----------- PyCon Looms ----------- PyCon_ is coming soon! .. _PyCon: http://www.pycon.org/ ========= Summaries ========= ------------- PEP movements ------------- `PEP 309`_ is now final since the 'functional' module has now been checked into Python. .. _PEP 309: http://www.python.org/peps/pep-0309.html Contributing threads: - `PEP 309 enhancements <http://mail.python.org/pipermail/python-dev/2005-February/051785.html>`__ - `PEP 309 <http://mail.python.org/pipermail/python-dev/2005-February/051789.html>`__ ------------------------------------------------------ Indices for slices other objects with __int__ not okay ------------------------------------------------------ Travis Oliphant asked if it would be possible to patch slicing so that any object that defines __int__ could be used. Guido didn't like this idea, though. Float, for instance, has __int__ defined. Guido admitted he "unfortunately copied a design mistake from C here". He said he might add a __trunc__ magic method in Python 3000 for objects that really can't be viewed as an int but are willing to have data loss to give one. Contributing threads: - `Fixing _PyEval_SliceIndex so that integer-like objects can be used <http://mail.python.org/pipermail/python-dev/2005-February/051669.html>`__ - `Fix _PyEval_SliceIndex (Take two) <http://mail.python.org/pipermail/python-dev/2005-February/051672.html>`__ -------------------------------------------- Why can't ``class C(): pass`` be acceptable? -------------------------------------------- No reason. =) So as of Python 2.5 it is acceptable to have empty parentheses for class definitions. It does create a classic class and not a new-style one. Contributing threads: - `Requesting that a class be a new-style class <http://mail.python.org/pipermail/python-dev/2005-February/051691.html>`__ ---------------------------------- What basestring is truly meant for ---------------------------------- What is basestring for? According to Guido it is purely for unicode and str to inherit from to help with checks in code where either type is acceptable. It is *not* meant to be used as a base class for any other classes. Contributing threads: - `UserString <http://mail.python.org/pipermail/python-dev/2005-February/051710.html>`__ ------------------------------------------------------ Quickly opening an SF bug/patch in Firefox/Thunderbird ------------------------------------------------------ Martin v. Löwis posted a way to use the DictionarySearch_ plug-in for Mozilla to launch a browser with the highlighted patch/bug #. See the email for the thread on how to get it to work. .. _DictionarySearch: http://dictionarysearch.mozdev.org/download.php/http://downloads.mozdev.org… Contributing threads: - `Quick access to Python bug reports in Thunderbird <http://mail.python.org/pipermail/python-dev/2005-February/051804.html>`__ -------------------------------- Optimizing ``x in [1, 2, 3]`` -------------------------------- Raymond Hettinger has been trying to teach the peepholer some new tricks to optimize ``x in [1, 2, 3]`` and the like into a faster operation. Initially he got it to change the list to a tuple. He then tried turning the list into a frozenset, but that had the unforeseen issue of breaking semantics since it then required the object being checked for to be hashable. So Raymond suggested introducing a SearchSet that tried the comparison as a frozenset first, and upon failure of hashing, to old way of just looking at each item in the list. But this seemed like overkill since most lists would be small; probably usually under 4 items. But Fredrik Lundh suggested expanding it to ``x == 1 or x == 2 or x == 3``. This seemed like a performance boost when the items of the list were lists since the COMPARE_OP opcode special-cases comparing ints. But for other instances it probably isn't worth it unless more special-casing is done in the opcodes. Contributing threads: - `Prospective Peephole Transformation <http://mail.python.org/pipermail/python-dev/2005-February/051651.html>`__ ------------------ A DupStore opcode? ------------------ Raymond Hettinger suggested a new opcode called DupStore that would replace load;store opcode pairs. Guido questioned if this was leading down a road of adding too much extra code for little benefit. Off this a discussion about speeding up frame allocation, an area viewed as needing some optimization, started up. Contributing threads: - `Store x Load x --> DupStore <http://mail.python.org/pipermail/python-dev/2005-February/051716.html>`__ --------------------------------------- Slow unit tests should be distinguished --------------------------------------- note:: written by Tony Meyer Guido clarified that unit tests should distinguish between "regular" tests and slow ones by use of the unit test 'resource' keys, as a result of Peter Åstrand asking for comments about `bug #1124637`_, which complained that test_subprocess is too slow. The suggested solution was to add another resource for subprocess, so that generally a quick version would run, but a longer, more thorough test would run with -uall or -usubprocess. Along the way, it was discovered that the reason that Windows already ran test_subprocess quickly was because there was code special-casing it to be fast. The resource solution was checked in, although Windows was left special-cased. .. _bug #1124637: http://www.python.org/sf/1124637 Contributing threads: - `[ python-Bugs-1124637 ] test_subprocess is far too slow (fwd) <http://mail.python.org/pipermail/python-dev/2005-February/051618.html>`__ ----------------------------------- Clarification of the '5 for 1' deal ----------------------------------- note:: written by Tony Meyer It seems that the offer that some python-dev'ers have made to review a patch in exchange for reviews of five (originally ten) other patches is finally being taken up by various people. However, python-dev traffic has increased with patch and bug reviews, and the question was posed whether reviews should be posted in general, or only for this specific deal. The answer is that the comments should also be entered via the SourceForge tracking system, but that a brief message covering a bunch (rather than individual) of reviews is acceptable for python-dev, at least for now. New reports should almost never be posted to python-dev, however, and should be entered via the tracking system. This offer isn't official policy, but a reference to it will be added to Brett's summary of the development process. However, people should also remember that it may take developers some time to find time to deal with reviews, and so have patience after posting their review. Contributing threads: - `discourage patch reviews to the list? <http://mail.python.org/pipermail/python-dev/2005-February/051475.html>`__ - `Some old patches <http://mail.python.org/pipermail/python-dev/2005-February/051705.html>`__ - `Five review rule on the /dev/ page? <http://mail.python.org/pipermail/python-dev/2005-February/051633.html>`__ =============== Skipped Threads =============== + pymalloc on 2.1.3 + Exceptions *must*? be old-style classes? + subclassing PyCFunction_Type + Windows Low Fragementation Heap yields speedup of ~15% + string find(substring) vs. substring in string + Some old patches + Comment regarding PEP 328 ======== Epilogue ======== ------------ Introduction ------------ This is a summary of traffic on the `python-dev mailing list`_ from February 15, 2005 through February 28, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the fifty-nineth summary written by Brett Cannon (two more to go!). To contact me, please send email to brett at python.org. Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. If you are looking for a way to expand your knowledge of Python's development and inner-workings, consider writing the python-dev Summaries yourself! I am willing to hand over the reins to someone who is willing to do a comparable or better job of writing the Summaries. If you are interested, please email me at brett at python.org. -------------------- Commenting on Topics -------------------- 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`_! ------------------------- How to Read the Summaries ------------------------- The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it. I do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow me to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-02-01_2005-02-14.html .. _original text file: http://www.python.org/dev/summary/2005-02-15_2005-02-28.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

Dr. Dobb's Python-URL! - weekly Python news and links (Mar 7)
by Cameron Laird March 7, 2005

March 7, 2005

QOTW: "Really, of course, the only things you need to make explicit are the ones that readers don't understand." -- Steve Holden "Working with unicode objects in Python is so transparent, it's easy to forget about what a C extension would likely want." -- Kevin Dangoor "You take leadership in a small area, and you keep it as long as you care to." -- Max M, on the slender rewards of open-source authorship Even with everything else going on at PyCon2005--dynamite speakers, thrilling Sprints, and so on--the most newsworthy event of the week likely will be revelations about IronPython's schedule. When will it be possible to create .NET services in Python? Keep in mind that PythonNet already lets Python applications be .NET clients: http://www.zope.org/Members/Brian/PythonNet/index_html http://python.org/pycon/2005/keynotes.html Brett C. begins his farewell tour from python-dev summation: http://groups-beta.google.com/group/comp.lang.python/msg/99e13efba90ca590 Python has a Security Response Team, python-dev has new summarizers, CPython might soon have a new "throwaway list" optimization, and those only hint at the range of progress python-dev has made in the last fortnight: http://www.python.org/dev/summary/2005-02-01_2005-02-14.html Skip Montanaro and Diez Roggisch write with precision on use of urllib, and particularly its user-agent refinement: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/5… Python is a good extension language, in the sense that an application or parts of it can be made scriptable under the control of an end-user. It's easy to do so--but be careful to promote "safe plugging": http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/6… Jeff Epler exhibits a definition which automates remote control of Tkinter processes: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/2… ChaosKCW offers timings and brief commentary on alternative wrappings of SQL access with iterables and generators: http://groups-beta.google.com/group/comp.lang.python/msg/7ff516d7d9387dad Python is flexible. You can create applications, you can work interactively, you can interactively manage applications, you can create applications that offer interaction under programmatic control, you can ...: http://groups-beta.google.com/group/comp.lang.python/browse_thread/thread/7… One of the fundamentals of Python's origin was that the language play well with others (an innovation, in that context). Among the many instances of teamwork between Python and other languages that turn up daily is Python's success in development of assemblers: http://groups-beta.google.com/group/comp.lang.python.announce/browse_thread… ======================================================================== Everything Python-related you want is probably one or two clicks away in these pages: Python.org's Python Language Website is the traditional center of Pythonia http://www.python.org Notice especially the master FAQ http://www.python.org/doc/FAQ.html PythonWare complements the digest you're reading with the marvelous daily python url http://www.pythonware.com/daily Mygale is a news-gathering webcrawler that specializes in (new) World-Wide Web articles related to Python. http://www.awaretek.com/nowak/mygale.html While cosmetically similar, Mygale and the Daily Python-URL are utterly different in their technologies and generally in their results. For far, FAR more Python reading than any one mind should absorb, much of it quite interesting, several pages index much of the universe of Pybloggers. http://lowlife.jp/cgi-bin/moin.cgi/PythonProgrammersWeblog http://www.planetpython.org/ http://mechanicalcat.net/pyblagg.html comp.lang.python.announce announces new Python software. Be sure to scan this newsgroup weekly. http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python.announce 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 Kurt B. Kaiser publishes a weekly report on faults and patches. http://www.google.com/groups?as_usubject=weekly%20python%20patch Cetus collects Python hyperlinks. http://www.cetus-links.org/oo_python.html Python FAQTS http://python.faqts.com/ The Cookbook is a collaborative effort to capture useful and interesting recipes. http://aspn.activestate.com/ASPN/Cookbook/Python Among several Python-oriented RSS/RDF feeds available are http://www.python.org/channews.rdf http://bootleg-rss.g-blog.net/pythonware_com_daily.pcgi http://python.de/backend.php For more, see http://www.syndic8.com/feedlist.php?ShowMatch=python&ShowStatus=all The old Python "To-Do List" now lives principally in a SourceForge reincarnation. http://sourceforge.net/tracker/?atid=355470&group_id=5470&func=browse http://python.sourceforge.net/peps/pep-0042.html The online Python Journal is posted at pythonjournal.cognizor.com. editor(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. del.icio.us presents an intriguing approach to reference commentary. It already aggregates quite a bit of Python intelligence. http://del.icio.us/tag/python *Py: the Journal of the Python Language* http://www.pyzine.com Archive probing tricks of the trade: http://groups.google.com/groups?oi=djq&as_ugroup=comp.lang.python&num=100 http://groups.google.com/groups?meta=site%3Dgroups%26group%3Dcomp.lang.pyth… Previous - (U)se the (R)esource, (L)uke! - messages are listed here: http://www.ddj.com/topics/pythonurl/ (requires subscription) http://groups-beta.google.com/groups?q=python-url+group:comp.lang.python*&s… 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

ANNOUNCE: PyGTK 2.6.0
by Johan Dahlin March 7, 2005

March 7, 2005

I am pleased to announce version 2.6.0 of the Python bindings for GTK. The new release is available from ftp.gnome.org as and its mirrors as soon as its synced correctly: http://ftp.gnome.org/pub/GNOME/sources/pygtk/2.6/pygtk-2.6.0.tar.gz Major changes: Gtk+ 2.6 API, new classes: GtkAboutDialog, GtkIconView, GtkCellView, GtkFileChooserButton. GInterfaces can now be implemented. Overriding GTK+ virtual methods is now supported. Better support for GMainloop support, so you don't need to run gtk.main to be able to use signals and gobjects. Deprecated gtk.TRUE,gtk.FALSE, gtk.idle_add, gtk.idle_remove, gtk.timeout_add, gtk.timeout_remove, gtk.input_add, gtk.input_add_full, gtk.input_remove Thanks to (this release would not have been possible without you!): Hans Breuer, Gustavo J. A. M. Carneiro, Raphael Kubo da Costa John Ehresman, John Finlay, Cedric Gustin, James Henstridge Adam Hooper, Alan Horkan, Mark McLoughlin, Christian Robottom Reis Manish Singh and Gian Mario Tagliaretti What's new since 2.5.4: - win32 fixes (Cedric Gustin) - remove unnecessary casting (Manish Singh) - updated examples (Johan) Blurb: GTK is a toolkit for developing graphical applications that run on POSIX systems such as Linux, Windows and MacOS X (provided that the X server for MacOS X has been installed). It provides a comprehensive set of GUI widgets, can display Unicode bidi text. It links into the Gnome Accessibility Framework through the ATK library. PyGTK provides a convenient wrapper for the GTK+ library for use in Python programs, and takes care of many of the boring details such as managing memory and type casting. When combined with PyORBit and gnome-python, it can be used to write full featured Gnome applications. Like the GTK+ library itself PyGTK is licensed under the GNU LGPL, so is suitable for use in both free software and proprietary applications. It is already in use in many applications ranging from small single purpose scripts up to large full features applications. PyGTK requires GTK+ >= 2.6 and Python >= 2.3 to build. Bug reports, as always, should go to Bugzilla; check out http://pygtk.org/developer.html and http://pygtk.org/feedback.html for links to posting and querying bug reports for PyGTK. -- Johan Dahlin johan(a)gnome.org

1 0

PyAr - Python Argentina 7th Meeting, this Thursday
by Batista, Facundo March 7, 2005

March 7, 2005

The Argentine Python User Group, PyAr, will have its seventh meeting this Thursday, January 10th at 7:00pm. Agenda ------ Despite our agenda tends to be rather open, this time we would like to cover these topics: - See how the code evolved from the ideas generated in of our first sprint. - Define how we will promote ourselves in PyCon 2005. Where ----- We're meeting at Hip Hop Bar, Hipólito Yirigoyen 640, Ciudad de Buenos Aires, starting at 19hs. We will be in the back room, so please ask the barman for us. About PyAr ---------- For more information on PyAr see http://pyar.decode.com.ar (in Spanish), or join our mailing list (Also in Spanish. For instructions see http://pyar.decode.com.ar/Members/ltorre/listademail) We meet on the second Thursday of every month. . Facundo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ADVERTENCIA. La información contenida en este mensaje y cualquier archivo anexo al mismo, son para uso exclusivo del destinatario y pueden contener información confidencial o propietaria, cuya divulgación es sancionada por la ley. Si Ud. No es uno de los destinatarios consignados o la persona responsable de hacer llegar este mensaje a los destinatarios consignados, no está autorizado a divulgar, copiar, distribuir o retener información (o parte de ella) contenida en este mensaje. Por favor notifíquenos respondiendo al remitente, borre el mensaje original y borre las copias (impresas o grabadas en cualquier medio magnético) que pueda haber realizado del mismo. Todas las opiniones contenidas en este mail son propias del autor del mensaje y no necesariamente coinciden con las de Telefónica Comunicaciones Personales S.A. o alguna empresa asociada. Los mensajes electrónicos pueden ser alterados, motivo por el cual Telefónica Comunicaciones Personales S.A. no aceptará ninguna obligación cualquiera sea el resultante de este mensaje. Muchas Gracias.

1 0

python-dev Summary for 2005-02-01 through 2005-02-14
by Brett C. March 7, 2005

March 7, 2005

[The HTML version of this Summary is available at http://www.python.org/dev/summary/2005-02-01_2005-02-14.html] ===================== Summary Announcements ===================== -------------------------- Giving myself a gold watch -------------------------- As some of you may have already heard or read, I am retiring from writing the python-dev Summaries after sending out the March 16 - 31 summary. It has been a long time coming and it required a kick in the ass (graciously supplied by Steve Holden) to finally make me let go of doing this and let someone else take over. The joy of the Summaries has dwindled over the 2.5 years I have been doing this. I was only doing them to be helpful. But now I would rather put my time and effort I have for Python into coding work rather than the Summaries. I would like to think I can be more productive and helpful as a programmer than a writer. And so there will only be three more regular Summaries after this written by yours truly. But do not worry about the Summaries dying! When I announced this (see http://mail.python.org/pipermail/python-dev/2005-March/051823.html for the thread that led to this), three individuals stepped forward to pick up the work once I step down. Steven Bethard, Tony Meyer, and Tim Lesher are being considered for picking up where I left off. There is the possibility that they will actually write the Summaries together as a team. As for my last Summary, expect a more expository one with my random thoughts on PyCon, Python, and anything else that comes to mind that I feel like using this space to abuse. You have Scott David Daniels to thank for that format idea for my final hurrah. ------------ Go to PyCon! ------------ I just booked my hotel room for PyCon_. You going to be there so I can shake your hand, thanking you for supporting Python? .. _PyCon: http://www.pycon.org/ ========= Summaries ========= ------------------------------------- Python Security Response Team founded ------------------------------------- For those of you who don't know, a security hole was found in XML-RPC servers in the stdlib that use register_instance; details at http://www.python.org/security/PSF-2005-001/ . In response to this, Guido has now formed the 'Python Security Response Team`_. This group's job is to respond to any and all security issues that come up as quickly as possible and to issue a patch in a timely fashion. .. _Python Security Response Team: http://www.python.org/security/ Contributing threads: - `Wanted: members for Python Security Response Team <http://mail.python.org/pipermail/python-dev/2005-February/051414.html>`__ ------------------------------ Licensing issues in the stdlib ------------------------------ It was reported to python-dev that 'profiler' and 'md5 do not conform to the Debian Free Software Guidelines. The specific issue was derived works using Python. This is obviously not a good thing. Things are in the works, though. The hope is to get the copyrights signed over and all of this cleared up. At worst the modules will be replaced with code licensed to the Python Software Foundation. If you care to accelerate this by writing replacements please do so. Contributing threads: - `license issues with profiler.py and md5.h/md5c.c <http://mail.python.org/pipermail/python-dev/2005-February/051450.html>`__ --------------------------------------------------- Replacing list of constants with tuple of constants --------------------------------------------------- note: written by Tim Lesher Skip Montanaro noticed that Raymond Hettinger had made a number of library checkins replacing lists with tuples in constructs like ``for a in [1, 2, 3]:`` and ``if a in [1, 2, 3]:``. He agreed with the motivation (the peephole optimizer can convert a tuple of constants into a single constant, eliminating construction time), but questioned hardcoding the optimization. Instead, he suggested teaching the optimizer about "throwaway" lists in ``for`` and ``if`` statements. Guido agreed with the sentiment. Raymond accepted the suggestion, and checked in code to implement it. There were some issues, though, but those will be covered in the next Summary. Contributing threads: - `list of constants -> tuple of constants <http://mail.python.org/pipermail/python-dev/2005-February/051442.html>`__ ------------------- Complex I/O problem ------------------- note: written by Tim Lesher Neal Becker asked why the result of printing a complex number is not an acceptable input to constructing a complex. For example, ``print complex(2,2)`` yields ``'(2+2j)'``; but ``complex('(2+2j)')`` throws a ValueError. A. M. Kuchling responded that many types, including 'str' and 'file' share this behavior, and that in any event, parsing string representations is a job more suited to 'eval' than to classes themselves. Guido `reiterated the rules`_ for str() (used by 'print') and repr(). Since both complex.__str__ and complex.__repr__ pass the eval() test, he pronounced it fine. .. _reiterated the rules: http://mail.python.org/pipermail/python-dev/2005-February/051390.html Contributing threads: - `complex I/O problem <http://mail.python.org/pipermail/python-dev/2005-February/051388.html>`__ ----------------------------- 2.3.5 and 2.4.1 release plans ----------------------------- note: written by Steve Bethard Anthony Baxter, Alex Martelli and Tim Peters squelched a bug where deepcopy failed on instances of types that lacked an ``__mro__`` attribute. The patch was pretty straight-forward (use inspect.getmro instead of cls.__mro__), but coming up with a test case was hard -- creating a Python object that doesn't have an __mro__ takes some complicated C code like that of Zope's ExtensionClass. Fortunately, John Lenton's c.l.py_ suggestion to simply raise an AttributeError for __mro__ in __getattribute__ properly tickled the bug, and 2.3.5 was cleared for release. Contributing Threads: - `2.3.5 and 2.4.1 release plans <http://mail.python.org/pipermail/python-dev/2005-February/thread.html>`__ ------------------------------------------------------------------------------------- Clarification sought about including a multidimensional array object into Python core ------------------------------------------------------------------------------------- note: written by Steve Bethard Travis Oliphant and others looked into the issues of including an array object (like that of Numeric or numarray) in Python core. Guido seemed hesitant, concerned that as Numeric_ and numarray_ continue to co-exist, the array object wouldn't be the "best of breed" (one of the requirements for inclusion in Python core). Travis explained that most of the disagreements are over ufunc objects, not the basic array object itself, so it wouldn't be unreasonable to include the array object without the ufunc object if necessary. There was also some suggestion that, at least for basic arithmetic operations, Numeric and numarray mostly agree, so a stripped-down ufunc object for these operations might also be inclusion-worthy. In an aside that grew decidedly un-aside-ish, Paul F. Dubois, Guido and David Ascher explained why matrix should not inherit from arrayobject -- this would complicate __new__ and cause confusion when mixed operands (arrays and matrices) are given to a binary op like multiplication. .. _Numeric: http://numeric.scipy.org/ .. _numarray: http://www.stsci.edu/resources/software_hardware/numarray Contributing Threads: - `Clarification sought about including a multidimensional array object into Python core <http://mail.python.org/pipermail/python-dev/2005-February/051474.html>`__ - `Numeric life as I see it <http://mail.python.org/pipermail/python-dev/2005-February/051493.html>`__ -------------------------------------- More licensing issues - redistribution -------------------------------------- note:: written by Tony Meyer As most people know, one of the major changes between the Windows builds of Python 2.3 and 2.4 is that 2.4 is built with VC7, rather than VC6. One of the consequences of this change is that 2.4 links with the Microsoft DLL msvcr71.dll, which only some people have, rather than msvcr.dll, which pretty much all Windows users have. The Windows Python 2.4 distribution installs msvcr71.dll, so it's there when needed. However, those building frozen applications (e.g. with py2exe) need to ensure that their users have msvcr71.dll. After going through the EULA's for both the commercial and free-to-use Microsoft compilers, it seems that redistributing mscvr71.dll is acceptable, if the re-distributor owns a copy of the commercial (not free) compiler, includes an EULA agreement in one of various forms (e.g. 'click-wrap'), and follows various other minor conditions (note that just about every message in this thread contains "IANAL, but"). This leaves those without VC7 unable to redistribute msvcr71.dll, unless, as some suggested, distributing a frozen Python application can be considered as redistributing Python (and the various other minor conditions are followed). In an interesting twist, it appears that the official Windows Python 2.4 distribution is in breach of the EULA, as a 'click-wrap' license is required, and is not present. This element of the thread died without reaching a conclusion, however. If you *are* a lawyer (with expertise in this area), and would like to comment, then please do! Contributing threads: - `Is msvcr71.dll re-redistributable? <http://mail.python.org/pipermail/python-dev/2005-February/051393.html>`__ ---------------------------------- Avoiding signs in memory addresses ---------------------------------- note:: written by Tony Meyer Troels Walsted Hansen pointed out that builtin_id() can return a negative number in Python 2.4 (and can generate a warning in 2.3). Some 2.3 modules (but no 2.4 ones) have code to work around this, but Troels suggested that a better solution would be to simply have builtin_id() return an unsigned long integer. The consensus was that this would be a good idea, although nothing has been checked in yet, and so this will probably stagnate without someone submitting a patch (or at least a bug report). Contributing threads: - `builtin_id() returns negative numbers <http://mail.python.org/pipermail/python-dev/2005-February/051559.html>`__ =============== Skipped Threads =============== + Son of PEP 246, redux + Re: PEP 246: LiskovViolation as a name + Re: [Python-checkins] python/dist/src/Python future.c, 2.14, 2.15 + Other library updates + Re: python/dist/src/Lib rfc822.py,1.78,1.79 + Patch review: [ 1098732 ] Enhance tracebacks and stack traces with vars + Re: [Python-checkins] python/dist/src/Python compile.c, 2.343, 2.344 + Re: [Python-checkins] python/dist/src/Lib xmlrpclib.py, 1.38, 1.39 + ViewCVS on SourceForge is broken ======== Epilogue ======== ------------ Introduction ------------ This is a summary of traffic on the `python-dev mailing list`_ from February 01, 2005 through February 14, 2005. It is intended to inform the wider Python community of on-going developments on the list on a semi-monthly basis. An archive_ of previous summaries is available online. An `RSS feed`_ of the titles of the summaries is available. You can also watch comp.lang.python or comp.lang.python.announce for new summaries (or through their email gateways of python-list or python-announce, respectively, as found at http://mail.python.org). This is the fifty-eighth summary written by Brett Cannon (3 more after this one). To contact me, please send email to brett at python.org. Do *not* post to comp.lang.python if you wish to reach me. The `Python Software Foundation`_ is the non-profit organization that holds the intellectual property for Python. It also tries to advance the development and use of Python. If you find the python-dev Summary helpful please consider making a donation. You can make a donation at http://python.org/psf/donations.html . Every penny helps so even a small donation with a credit card, check, or by PayPal helps. If you are looking for a way to expand your knowledge of Python's development and inner-workings, consider writing the python-dev Summaries yourself! I am willing to hand over the reins to someone who is willing to do a comparable or better job of writing the Summaries. If you are interested, please email me at brett at python.org. -------------------- Commenting on Topics -------------------- 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`_! ------------------------- How to Read the Summaries ------------------------- The in-development version of the documentation for Python can be found at http://www.python.org/dev/doc/devel/ and should be used when looking up any documentation for new code; otherwise use the current documentation as found at http://docs.python.org/ . PEPs (Python Enhancement Proposals) are located at http://www.python.org/peps/ . To view files in the Python CVS online, go to http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/ . Reported bugs and suggested patches can be found at the SourceForge_ project page. Please note that this summary is written using reStructuredText_. Any unfamiliar punctuation is probably markup for reST_ (otherwise it is probably regular expression syntax or a typo =); you can safely ignore it. I do suggest learning reST, though; it's simple and is accepted for `PEP markup`_ and can be turned into many different formats like HTML and LaTeX. Unfortunately, even though reST is standardized, the wonders of programs that like to reformat text do not allow me to guarantee you will be able to run the text version of this summary through Docutils_ as-is unless it is from the `original text file`_. .. _python-dev: http://www.python.org/dev/ .. _SourceForge: http://sourceforge.net/tracker/?group_id=5470 .. _python-dev mailing list: http://mail.python.org/mailman/listinfo/python-dev .. _c.l.py: .. _comp.lang.python: http://groups.google.com/groups?q=comp.lang.python .. _PEP Markup: http://www.python.org/peps/pep-0012.html .. _Docutils: http://docutils.sf.net/ .. _reST: .. _reStructuredText: http://docutils.sf.net/rst.html .. _PSF: .. _Python Software Foundation: http://python.org/psf/ .. _last summary: http://www.python.org/dev/summary/2005-01-16_2005-01-31.html .. _original text file: http://www.python.org/dev/summary/2005-02-01_2005-02-14.ht .. _archive: http://www.python.org/dev/summary/ .. _RSS feed: http://www.python.org/dev/summary/channews.rdf

1 0

pyvm - a portable python virtual machine
by Antonio Cavallo March 5, 2005

March 5, 2005

pyvm 1.4.9 ========== "More batteries to your python" Introduction: pyvm is a relocatable python binary distribution containing several modules. Its main aim is to provide all this without requiring root access. Features: * pyqt (widget set) * pygtk (widget set) * nummarray (array and matematical) * pyqwt (plot widget in qt) * matplotlib (plot function similar tomatlab) * Imaging (a digital imaging library) * elementree (xml library) * and many many more. Download: http://pyvm.sourceforge.net Copyright: MIT for the building script, other licence terms apply to the singular package (see the docs) Author: Antonio Cavallo pyvm(a)mailsnare.com

1 0

Final PyCon Keynote from Google Speaker
by Steve Holden March 4, 2005

March 4, 2005

Dear Python Colleague: I am happy to say that we have now completed the PyCon DC 2005 keynote speaker lineup, and that the final keynote will be given by Greg Stein, an engineering manager wirh Google's Blogger group, who will be speaking on "Python at Google" Greg is also known to many in the open source world as the chairman of the Apache Foundation, and he is a significant contributor to Subversion, WebDAV and Python. With the opening keynote from a Microsoft speaker, the second keynote from Guido van Rossum (the inventor of Python) and the last keynote from Google, PyCon is beginning to demonstrate just how significant Python has become in the modern world of software and Internet services. I hope you will join me in DC from March 23-25, and possibly attend the four-day sprint being held immediately before the conference. Pre- conference registration is available via http://www.python.org//pycon/2005/register.html This is going to be a great opportunity for all those with an interest in Python to see just how far the language has come. regards Steve Holden Chairman, PyCON DC 2005 -- PyCon DC 2005: The third Python Community Conference http://www.pycon.org/ http://www.python.org/pycon/ The scoop on Python implementations and applications

1 0

BayPIGgies: March 10, 7:30pm (FINAL MEETING AT STANFORD)
by Aahz March 4, 2005

March 4, 2005

WARNING: the last meeting of BayPIGgies at Stanford is currently scheduled for March. Our host, Danny Yoo, is leaving Stanford, and we need to find a new location. If you wish to assist with the search, please join the BayPIGgies mailing list. Meanwhile, let's all give hearty thanks to Danny for helping us find a stable meeting location for so long! The next meeting of BayPIGgies will be Thurs, March 10 at 7:30pm. Donovan Preston will lead a discussion about using Python with OS X, including integrating with PyObjC and GNUStep. BayPIGgies meetings are in Stanford, California. For more information and directions, see http://www.baypiggies.net/ Before the meeting, we may meet at 6pm for dinner in downtown Palo Alto. Discussion of dinner plans is handled on the BayPIGgies mailing list. Advance notice: The April 14 meeting agenda has not been set. Please send e-mail to baypiggies(a)baypiggies.net if you want to suggest an agenda -- and a meeting place! -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death." --GvR

1 0

ANN: numarray-1.2.3
by Todd Miller March 3, 2005

March 3, 2005

numarray-1.2.3 is a bugfix release for numarray-1.2.2 which fixes a problem with universal function setup caching which noticeably impaired 1.2.2 small array performance. Get it if you are new to numarray, haven't upgraded to 1.2.2 yet, or use a lot of small arrays. numarray-1.2.3 is here: http://sourceforge.net/project/showfiles.php?group_id=1369&package_id=32367 Thanks to Ralf Juengling for quietly reporting this and working with me to identify and fix the problem.

1 0