python-dev Summary for 2005-02-01 through 2005-02-14 [draft]
OK, so this one is really short. Beyond the fact that I am probably doing this too late at night I also want to give the three people who have stepped forward to take over for me when I stopped writing the Summaries multiple chances to pick up on any of the Skipped Threads or even flesh out any of my thread summaries more. I have asked them to post their writing here to make the choosing of a successor a little on the open side. Hope to send this out Sunday night. ------------------------------- ===================== 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. I honestly have no clue how the heck I am going to choose between the three of them. 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 <>`__ ------------------------------ 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 <>`__ =============== Skipped Threads =============== + complex I/O problem + Is msvcr71.dll re-redistributable? + Son of PEP 246, redux + Re: PEP 246: LiskovViolation as a name + 2.3.5 and 2.4.1 release plans + Re: [Python-checkins] python/dist/src/Python future.c, 2.14, 2.15 + list of constants -> tuple of constants + 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 + builtin_id() returns negative numbers + Clarification sought about including a multidimensional array object into Python core
Here are sample summaries of two "skipped threads". If anyone has comments, criticisms, or rotten tomatoes, let me know. --------------------------------------------------- Replacing list of constants with tuple of constants --------------------------------------------------- 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. Contributing threads: - `list of constants -> tuple of constants <http://mail.python.org/pipermail/python-dev/2005-February/051442.html>`__ ------------------- Complex I/O problem ------------------- Neal Becker asked why the result of printing a ``complex`` 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>`__ -- Tim Lesher <tlesher@gmail.com>
Here's another two skipped threads. Ditto Tim Lesher's "comments, criticisms, or rotten tomatoes" request. =) ------------------------------------- 2.3.5 and 2.4.1 release plans ------------------------------------- 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 ticked 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 ------------------------------------- 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 expectations 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. 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>`__ Steve Bethard -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy
Both entries so far look very good. Perhaps writing python-dev summaries could be a rotating position? -- Aahz (aahz@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
On Fri, Mar 04, 2005, John J Lee wrote:
On Fri, 4 Mar 2005, Aahz wrote:
Both entries so far look very good. Perhaps writing python-dev summaries could be a rotating position?
Or even a joint effort? It's up to the contributors, of course: just a thought...
That was my original thought, too, then I remembered just how much work coordinating is.... ;-) -- Aahz (aahz@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
Aahz wrote:
On Fri, Mar 04, 2005, John J Lee wrote:
On Fri, 4 Mar 2005, Aahz wrote:
Both entries so far look very good. Perhaps writing python-dev summaries could be a rotating position?
Or even a joint effort? It's up to the contributors, of course: just a thought...
That was my original thought, too, then I remembered just how much work coordinating is.... ;-)
Maybe the contributors could claim threads to summarise shortly after the threads start? That might reduce the burden of needing to follow *every* thread. . . then Skipped Threads would contain any threads that nobody claimed. JJL's last comment applies to me, too, naturally :) Regards, Nick. -- Nick Coghlan | ncoghlan@email.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.skystorm.net
Aahz wrote:
Both entries so far look very good. Perhaps writing python-dev summaries could be a rotating position?
Good idea that several people have now suggested to me. I have emailed Tim, Steve, and Tony to see what they think. It wouldn't surprise me if this happens if for any other reason than the shock at how long these Summaries can take. =) -Brett
participants (6)
-
Aahz -
Brett C. -
John J Lee -
Nick Coghlan -
Steven Bethard -
Tim Lesher