[Python-Dev] python-dev Summary for 2005-02-15 through 2005-02-28 [draft]

[Brett C.]

Decided to just plow through the next Summary so that I was finally caught up.

I am not expecting the candidates for taking of the Summaries to write stuff 
for this one (although I wouldn't mind it  =).  The idea of having them work 
together to write the Summaries has been proposed, but this is going out before 
I have heard back.

Depending on the number of people who send in edits, this could go out the same 
time as the 2005-02-01 Summary or I might wait until Monday night so people who 
only check mail on weekdays have a chance to look at this.

-------------------------------------

=====================
Summary Announcements
=====================

------------------------
Status of the candidates
------------------------
XXX

-----------
PyCon Looms
-----------
PyCon_ is coming!  Be there or be a Java or Perl coder!

.. _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 <>`__
   - `PEP 309 <>`__

------------------------------------------------------
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 <>`__
   - `Fix _PyEval_SliceIndex (Take two) <>`__


--------------------------------------------
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 <>`__


----------------------------------
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 <>`__

------------------------------------------------------
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/dictionarysearch/dictionarysearch_0.8.xpi

Contributing threads:
   - `Quick access to Python bug reports in Thunderbird <>`__


--------------------------------
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 <>`__

------------------
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 <>`__



===============
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
+ [ python-Bugs-1124637 ] test_subprocess is far too slow (fwd)
+ Five review rule on the /dev/ page?
+ Some old patches
+ Comment regarding PEP 328