diff --git a/pep-0000.txt b/pep-0000.txt
index 751776fd9..55eb0500b 100644
--- a/pep-0000.txt
+++ b/pep-0000.txt
@@ -103,6 +103,7 @@ Index by Category
  S  3102  Keyword-Only Arguments                       Talin
  S  3103  A Switch/Case Statement                      GvR
  S  3104  Access to Names in Outer Scopes              Yee
+ S  3105  Make print a function                        Brandl
 
  Finished PEPs (done, implemented in Subversion)
 
@@ -439,6 +440,7 @@ Numerical Index
  S  3102  Keyword-Only Arguments                       Talin
  S  3103  A Switch/Case Statement                      GvR
  S  3104  Access to Names in Outer Scopes              Yee
+ S  3105  Make print a function                        Brandl
 
 Key
 
diff --git a/pep-3105.txt b/pep-3105.txt
new file mode 100644
index 000000000..501a55549
--- /dev/null
+++ b/pep-3105.txt
@@ -0,0 +1,130 @@
+PEP: 3105
+Title: Make print a function
+Version: $Revision$
+Last-Modified: $Date$
+Author: Georg Brandl <g.brandl at gmx.net>
+Status: Draft
+Type: Standards
+Content-Type: text/x-rst
+Created: 19-Nov-2006
+Python-Version: 3.0
+
+
+Abstract
+========
+
+The title says it all -- this PEP proposes a new ``print()`` builtin
+that replaces the ``print`` statement and suggests a specific signature
+for the new function.
+
+
+Rationale
+=========
+
+The ``print`` statement has long appeared on lists of dubious language
+features that are to be removed in Python 3000, such as Guido's "Python
+Regrets" presentation [1]_. As such, the objective of this PEP is not
+new, though it might become much disputed among Python developers.
+
+The following arguments for a ``print()`` function are distilled from a
+python-3000 message by Guido himself [2]_:
+
+* ``print`` is the only application-level functionality that has a
+  statement dedicated to it. Within Python's world, syntax is generally
+  used as a last resort, when something *can't* be done without help from
+  the compiler. Print doesn't qualify for such an exception.
+
+* At some point in application development one quite often feels the need
+  to replace ``print`` output by something more sophisticated, like
+  logging calls or calls into some other I/O library. With a ``print()``
+  function, this is a straightforward string replacement, today it is
+  a mess adding all those parentheses and possibly converting ``>>stream``
+  style syntax.
+
+* Having special syntax for ``print`` puts up a much larger barrier for
+  evolution, e.g. a hypothetical new ``printf()`` function is not too
+  far fetched when it will coexist with a ``print()`` function.
+
+* There's no easy way to convert ``print`` statements into another call
+  if one needs a different separator, not spaces, or none at all.
+  Also, there's no easy way *at all* to conveniently print objects with
+  some other separator than a space.
+
+* If ``print()`` is a function, it would be much easier to replace it within
+  one module (just ``def print(*args):...``) or even throughout a program
+  (e.g. by putting a different function in ``__builtin__.print``). As it is,
+  one can do this by writing a class with a ``write()`` method and
+  assigning that to ``sys.stdout`` -- that's not bad, but definitely a much
+  larger conceptual leap, and it works at a different level than print.
+
+
+Specification
+=============
+
+The signature for ``print()``, taken from various mailings and recently
+posted on the python-3000 list [3]_ is::
+
+    def print(*args, sep=' ', end='\n', file=None)
+
+A call like::
+
+    print(a, b, c, file=sys.stderr)
+
+will be equivalent to today's::
+
+    print >>sys.stderr, a, b, c
+
+while the optional ``sep`` and ``end`` arguments specify what is printed
+between and after the arguments, respectively.
+
+The ``softspace`` feature (a semi-secret attribute on files currently
+used to tell print whether to insert a space before the first item)
+will be removed. Therefore, there will not be a direct translation for
+today's::
+
+    print "a",
+    print
+
+which will not print a space between the ``"a"`` and the newline.
+
+
+Backwards Compatibility
+=======================
+
+The changes proposed in this PEP will render most of today's ``print``
+statements invalid, only those which incidentally feature parentheses
+around all of their arguments will continue to be valid Python syntax
+in version 3.0.
+
+Luckily, as it is a statement in Python 2, ``print`` can be detected
+and replaced reliably and non-ambiguously by an automated tool, so
+there should be no major porting problems (provided someone writes the
+mentioned tool).
+
+
+References
+==========
+
+.. [1] http://www.python.org/doc/essays/ppt/regrets/PythonRegrets.pdf
+
+.. [2] Replacement for print in Python 3.0 (Guido van Rossum)
+       http://mail.python.org/pipermail/python-3000/2006-November/004485.html
+
+.. [3] print() parameters in py3k (Guido van Rossum)
+       http://mail.python.org/pipermail/python-3000/2006-November/004485.html
+
+
+Copyright
+=========
+
+This document has been placed in the public domain.
+
+
+..
+   Local Variables:
+   mode: indented-text
+   indent-tabs-mode: nil
+   sentence-end-double-space: t
+   fill-column: 70
+   coding: utf-8
+   End: