> Why all the hating on docstrings? What have docstrings done wrong? 

Oh, I don't hate docstrings. I just want to move it from code object to function object.
Remove docstring during unmarshal is your idea, not mine.

My main motivation is reducing code size. See this example.

```
class Foo:
    def name(self):
        """Return my name"""
        return self._name

    def set_name(self, name):
        """Set my name"""
        self._name = name

    def age(self):
        """Return my age"""
        return self._age

    def set_age(self, age):
        """Set my age"""
        self._age = age

>>> Foo.name.__code__.co_consts
('Return my name',)
>>> Foo.set_name.__code__.co_consts
('Set my name', None)
>>> Foo.age.__code__.co_consts
('Return my age',)
>>> Foo.set_age.__code__.co_consts
('Set my age', None)
```

If docstring is not in co_consts, all co_consts are empty tuple. The empty tuple is nearly zero-cost because its a singleton.

When comparing adding code.co_doc vs func.__doc__, "we can release old docstring" is a (small) pros. But it is no my main motivation.

Classes and modules don't use co_consts[0] anyway. So setting `func.__doc__` is better for consistency too.


> I know there's the -OO flag that strips docstrings, but it doesn't work well and I think it was a mistake.

Some libraries (e.g. SQLAlchemy) have very huge docstrings. `-OO` can save 10% RAM.

I like an idea adding per-file flag for "don't remove docstring in -OO mode", because docstrings can be used runtime in some cases (e.g. docopt).
But it is out of scope of this issue.