pydoc.synopsis() attempts to find a module's doc string
by parsing the module text. But the parser only
recognizes strings created with """ and r""". Any other
docstring is ignored.

I've attached a patch against Python 2.4.1 that fixes
pydoc to recognize ''' and r''' strings but really it
should recognize any allowable string format.

Logged In: YES
user_id=45338

PEP-257 recommends: "For consistency, always use """triple
double quotes""" around docstrings." I think that's why
this was originally written to only look for triple
double-quotes.

Are there a large number of modules written using
triple-single quotes for the module docstring?

Logged In: YES
user_id=49695

I don't know if there are a large number of modules with
triple-single-quoted docstrings. Pydoc will search any
module in site-packages at least, so you have to consider
third-party modules.

At best pydoc is inconsistent - the web browser display uses
the __doc__attribute but search and apropos use synopsis().
It's a pretty simple change to recognize any triple-quoted
string, it seems like a good idea to me...

I have attached a revised patch that uses a regex match so
it works with e.g. uR""" and other variations of triple-quoting.

FWIW this bug report was motivated by this thread on
comp.lang.python:
http://groups-beta.google.com/group/comp.lang.python/browse_frm/thread/e5cfccb7c9a168d7/1c1702e71e1939b0?q=triple&rnum=1#1c1702e71e1939b0

Logged In: YES
user_id=45338

I think you're right that if it works for the module summary
(using __doc__) then it should work with synopsis().
However, the patch you've added doesn't address the problem
properly; instead of handling """ correctly and ignoring
''', it handles both kinds of docstrings incorrectly because
it will accept ''' as a match for """ or """ as a match for '''.

I'll look at fixing this soon, but feel free to keep
prodding me until it gets fixed.

Logged In: YES
user_id=1015686

I started the thread to which Kent referred. I am aware of
PEP-257's recommendation of triple-double quotes. My
(perhaps wrong-headed) construal of that PEP is that it
isn't sufficiently rule-giving that I would have expected
other tools to reject triple-single quotes.
At any rate, since triple-single are syntactically
acceptable, it would seem better if they were accepted on
equal footing with triple-double. I can well understand that
this would be a v. low priority issue, though. Call it a
RFE. :-)

Source still has the snippet in patch (didn't test behavior).

The standard library has moved on quite a bit since this patch was written...

1. source_synopsis() should be using the tokeniser module when reading the docstring. The current implementation is broken in more ways than just those noted here (e.g. it completely ignores the declared encoding)

(The reason for not using full compilation is that you would then have to either *run* the compiled code or else compile to the AST and interrogate that, which is technically implementation dependent)

2. For 3.3+, synopsis should be using importlib to get the source code rather than assuming filesystem imports. That's probably better handled in a separate issue, though.

Oops, I somehow ended up looking at an old revision of pydoc.py

The current version *is* using tokenize.open and importlib in synopsis(), so those aspects of my comments are incorrect.

However, the point that pydoc should probably be using the tokenize module to do the parsing inside source_synopsis remains valid. There's no good reason to continue duplicating a subset of that text processing logic within pydoc.

I've rewritten the source_synopsis function to use the tokenize module.

It should now work with triple single quotes and hopefully all the other cases where __doc__ returns a string.

Since tokenize.tokenize needs a file object that is opened in binary mode, in the case of a StringIO object, i am reading the whole object and converting it to a BytesIO object. I don't know if that is the right way. Also, the only instance i could find where source_synopsis is called with a StringIO object is in the ModuleScanner.run method. Maybe we could tweak this call to pass a byte-stream object to avoid the overhead of re-conversion?

All the current tests pass.

+ except:
+ pass
...
+ except TypeError:
+ return None

I don't understand these try/except. First, "except: pass" must never be used, only catch specific exceptions (ex: AttributeError). Can you explain why you expect a TypeError?

If your patch fixes a bug, you must add a new unit test to test_pydoc to check for non-regression.

I've updated my patch with the review changes and tests.

tokenize.detect_encoding throws a TypeError if the file object passed to it is in text mode. However, i've realized catching this is not necessary as i now check for TextIOBase instead of just StringIO before.

Do you have any plan to work on patch for 2.7?
Apparently your patch is only for 3.x.

Added patch for 2.7. Please review.

I tried pydoc_2.7.patch with the following test file and
found source_synopsis returns \x escaped string instead of \u escaped one.

# -- coding: utf-8 --

u"""ツ"""

class Spam(object):
    u"""ツ"""

>>> import utf8
>>> utf8.__doc__
u'\u30c4'
>>> print(utf8.__doc__)
ツ
>>> import pydoc
>>> pydoc.source_synopsis(file('utf8.py'))
u'\xe3\x83\x84'
>>> print pydoc.source_synopsis(file('utf8.py'))
�
>>> print pydoc.source_synopsis(file('utf8.py')).encode('latin-1')
ツ

Hi Victor, can you give this another look?

This issue is 14 years old, inactive for 5 years, has 3 patches: it's far from being "newcomer friendly", I remove the "Easy" label.

@vstinner Can i take a stab at it? Do you accept a patch ?

Finally, 20 years later, it has been fixed.

Pydoc now uses tokenizer to extract the first logical line that can be a docstring, and then parses it with ast.literal_eval().

An advantage over myfirst_2.patch is that it supports more Python syntax (concatenated string literals and parentheses). An advantage over parsing the whole file is that it is faster and can work with future Python versions which can have new keywords, operators or syntax constructions. It also handles syntax warnings.

Good job, @srinivasreddy!