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
[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
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
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.
[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
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
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
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
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.