[pypy-commit] pypy.org extradoc: Typo in capitalization. Regen.

arigo noreply at buildbot.pypy.org
Mon Feb 13 10:33:58 CET 2012


Author: Armin Rigo <arigo at tunes.org>
Branch: extradoc
Changeset: r330:068ecf60cdf8
Date: 2012-02-13 10:33 +0100
http://bitbucket.org/pypy/pypy.org/changeset/068ecf60cdf8/

Log:	Typo in capitalization. Regen.

diff --git a/performance.html b/performance.html
--- a/performance.html
+++ b/performance.html
@@ -99,10 +99,22 @@
 might be worthwhile to consider rewriting it as a pure Python version
 that uses something like <tt class="docutils literal">ctypes</tt> for the interface.</li>
 <li><strong>Missing RPython modules</strong>: A few modules of the standard library
-(like <tt class="docutils literal">csv</tt> and <tt class="docutils literal">cPickle</tt>) are in C in CPython, but in pure Python
-in PyPy.  Sometimes the JIT is able to do a good job on them, and
-sometimes not. In most cases (like <tt class="docutils literal">csv</tt> and <tt class="docutils literal">cPickle</tt>), we're slower
-than cPython, with the notable exception of <tt class="docutils literal">json</tt> and <tt class="docutils literal">heapq</tt>.</li>
+(like <tt class="docutils literal">csv</tt> and <tt class="docutils literal">cPickle</tt>) are written in C in CPython, but written
+natively in pure Python in PyPy.  Sometimes the JIT is able to do a
+good job on them, and sometimes not.  In most cases (like <tt class="docutils literal">csv</tt> and
+<tt class="docutils literal">cPickle</tt>), we're slower than CPython, with the notable exception of
+<tt class="docutils literal">json</tt> and <tt class="docutils literal">heapq</tt>.</li>
+<li><strong>Abuse of itertools</strong>: The itertools module is often &ldquo;abused&rdquo; in the
+sense that it is used for the wrong purposes.  From our point of view,
+itertools is great if you have iterations over millions of items, but
+not for most other cases.  It gives you 3 lines in functional style
+that replace 10 lines of Python loops (longer but arguably much easier
+to read).  The pure Python version is generally not slower even on
+CPython, and on PyPy it allows the JIT to work much better &ndash; simple
+Python code is fast.  The same argument also applies to <tt class="docutils literal">filter()</tt>,
+<tt class="docutils literal">reduce()</tt>, and to some extend <tt class="docutils literal">map()</tt> (although the simple case
+is JITted), and to all usages of the <tt class="docutils literal">operator</tt> module we can think
+of.</li>
 </ul>
 <p>We generally consider things that are slower on PyPy than CPython to be bugs
 of PyPy.  If you find some issue that is not documented here,
diff --git a/source/performance.txt b/source/performance.txt
--- a/source/performance.txt
+++ b/source/performance.txt
@@ -66,7 +66,7 @@
   (like ``csv`` and ``cPickle``) are written in C in CPython, but written
   natively in pure Python in PyPy.  Sometimes the JIT is able to do a
   good job on them, and sometimes not.  In most cases (like ``csv`` and
-  ``cPickle``), we're slower than cPython, with the notable exception of
+  ``cPickle``), we're slower than CPython, with the notable exception of
   ``json`` and ``heapq``.
 
 * **Abuse of itertools**: The itertools module is often "abused" in the


More information about the pypy-commit mailing list