[Python-Dev] python-dev Summary for 2005-02-01 through 2005-02-14 [draft]

[Tim Lesher]

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 at gmail.com>