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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to