Hi,

If the last line of the function is also the last line of the module, it
is ignored. To repro:

1) Create module 'repro'
<module>
def test():
    module_line_2 = None
    module_line_3 = None
    module_line_4 = None
    module_line_5 = None
<end module>

2) Run test:
>>> import repro
>>> import inspect
>>> inspect.getsourcelines(tmp.test)
(['def test():\n', '    module_line_2 = None\n', '    module_line_3 =
None\n', '    module_line_4 = None\n'], 1)

notice no module_line_5.


cheers,

- Rafe

In order to reproduce the reported problem I had to conjure the attached 
repro.py which is missing '\n' on the last line.

I need to double check the language definition, but I feel this is not a 
bug because a file that ends with an unterminated line is not a well-
formed python program.

According to my understanding of

http://docs.python.org/reference/lexical_analysis.html#id1

a newline character is required at the end of the python file.

"I feel this is not a bug because a file that ends with an unterminated
line is not a well-formed python program."

I used Komodo to make the file. Nothing special. I just made a new
python document and used it. If there is a Komodo Bug that is fine, but
if this issue can happen (and it has), then the module should be made
more robust to protect against it happening, shouldn't it?

Rafe,

Can you confirm that behavior on missing end-of-line is indeed your 
issue?  Note that at first I could not even reproduce the problem based 
on your report.

I am attaching a proof-of-concept patch that would arguably improve the 
inspect module by making it more robust in your case.

Note that it is unlikely that a fix along the lines of my patch will be 
considered for bug-fix releases of 2.5.x and 2.6.x series.  If you want 
an immediate solution, you have a better chance convincing Komodo 
developers to fix their text editor (emacs' python mode auto-terminates 
the last line in .py files.)

We are also using inspect.getsourceline() in a large system at my
company and we observed some unreliable behavior in the past which we
never had time to analyze till today. Interesting coincidence, but today
we finally took the effort and traced the issue, and we found that:

getsourceline() does not report the last line of a class definition body
_IF_:
  (1) that line is the last line of the file, _AND_
  (2) that line is not terminated with a newline (\n)

This also answers Alexandre's question: yes, the problem happens only if
the line is unterminated.

I understand that an unterminated line may be non-conforming per Python
specs, but my WingIDE happily saved the file, so I suspect other editors
may just do the same, and I do agree with Rafe that it would be nice if
inspect would be resilient against the missing \n. I assume there would
be no harm, and it could eliminate some angst (it is really not obvious
first why it fails).

I would really love to see this fixed in a patch release on the 2.5+
lines. Any chance?

Just to add to the list of getsource quirks: with the following in x.py,

f = lambda: 0 \
[EOF]

>>> import inspect, x; inspect.getsource(x.f)
Traceback (most recent call last):
..
tokenize.TokenError: ('EOF in multi-line statement', (2, 0))

Same with

def f():
    0 \
[EOF]

You convinced me.  After all, if python interpreter does not complain 
about missing end-of-line and processes the unterminated line, getsource 
should report it.

Here is a patch that passes existing tests and adds a "NoEOF" test case.

I am adding 2.5.3 to the list of versions, but someone will have to 
lobby python-dev to make it happen.

Note that I've modernized the code a little bit by switching from a 
callback tokenizer to the newer token generator.  Hopefully this will 
make it easier to review the code, but I can easily produce an old-style  
patch as well.

The patch has not been accepted for the trunk, so backporting it to
2.5.3 is out of scope at this point.

Ok so we missed the opportunity to backport this to 2.5.3, could we please get it into modern versions of Python, or what?

Martin,

Was there a reason for not accepting this patch for the trunk?

3.2 and 2.7 don't exhibit this issue.  I added a test in r86922.