Inada Naoki <songofaca...@gmail.com> added the comment:
> 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.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue36521>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
