What I wrote was so wrong I'm deleting it - I'm looking into how IPython handles this.
On Sep 10, 2014 3:47 AM, "Martin Häcker" notifications@github.com wrote:

Some examples:

def fnord(): pass
fnord # doesn't work
class Foo(object): pass
Foo # doesn't work

Both of these work fine in iPython. Putting these two definitions in a
file and importing them yields the same result - source does not show.

These are reduced examples, in my testing I noticed that I could show the
source of a whole class in my project, but I wasn't able to show most of
the methods on it. Some examples: properties, decorated methods, inherited
methods.

Not sure whats the reason for this, but iPython did work for those most of
the time, so it may be a good idea to fork their method source lookup code
and use it instead of what is in bpython right now.

—
Reply to this email directly or view it on GitHub
#380.

Reading your comment, it may be that there are two issues at play here.

I saw the bug (i.e. bpython not showing the source) when I entered those lines in the interpreter AS WELL AS when I loaded those methods from a file on disk.

Oh huh - not sure what that's about. Loading them from a file is working fine for me now. But generally we should certainly do a better job finding those methods - I'll take a look at what IPython is doing.

@dwt Could you post here an example of a method or property bpython couldn't find if you come across one? Issue #229 is about the first issue you describe, I'm going to put notes about it there.

Please see this example output:

dwt@cirdan ~/Desktop % cat > test.py
def fnord(): pass
class Foo(object): pass
dwt@cirdan ~/Desktop % bpython
>>> from test import *
>>> fnord
<function fnord at 0x108552140>
>>> fnord<f2>
# no source is shown here
>>> Foo
<class 'test.Foo'>
>>> Foo<f2>
# no source is shown here

Does that work for you? For me it doesn't show any source.

I can reproduce in 0.13 bpython-curtsies, but not in plain bpython 0.13, bpython master, or bpython-curtsies master. What are you using?

Strange, I'm pretty sure I'm calling it exactly like it is shown in the snippet above. I was under the impression that by calling bpyton instead of bpython-curtsies I'm not using curtsies?

Can I give any other information to help debug this?

Is this on master, the latest release (0.13) or something else? I agree, $ bpython shouldn't be using curtsies. What os, since I suppose that could be different?

@dwt I'm not sure what else would be useful - your post is pretty clear, I just can't replicated it. Maybe doing a fresh install of either master or stable 0.13 and confirming?

% bpython --version
bpython version 0.13.1 on top of Python 2.7.5
(C) 2008-2014 Bob Farrell, Andreas Stuehrk et al. See AUTHORS for detail.
% uname -a
Darwin cirdan.fritz.box 13.3.0 Darwin Kernel Version 13.3.0: Tue Jun 3 21:27:35 PDT 2014; root:xnu-2422.110.17~1/RELEASE_X86_64 x86_64

bpython was installed via pip install bpython

Something that might be relevant: Function keys are pretty heavily overloaded on macs, and it might be that one of those overloadings prevents the key from reaching the shell. (I'm not sure how I can test that though?)

Still, it would be very helpful if all the functions advertised at the bottom of the screen hat non function key alternatives. (Maybe they do and I just haven't found the docs?)

Jus retested this with the bpython master branch, where I still see the same problem.

However, after exiting from bpython, I see this output:

(bpython)dwt@cirdan ~/Desktop % bpython
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
def fnord(): pass
class Foo(object): pass
class Foo(object): pass
class Foo(object): pass
class Foo(object): pass
class Foo(object): pass
class Foo(object): pass
class Foo(object): pass
class Foo(object): pass
>>> from test import *
>>> >>> >>> 

which seems to suggest that bpython was indeed able to to get the source, but instead failed to display it.

Does that perhaps help pinning this down?

The way I tested:

% mkvirtualenv bpython
% pip install --editable 'git://github.com/bpython/bpython/#egg=bpython'
% cat > test.py
def fnord(): pass
class Foo(object): pass
% bpython
>>> from test import *
>>> fnord<f2 * ~10>
>>> Foo<f2 * ~10>
>>> <ctrl-D>

This is terrific, thanks! I'll look into this tonight.

It looks like bpython is might be using whatever your environmental variable $PAGER is - do you have something unusual in there, like cat? If that's not there, bpython uses less -r - does your less do something unusual?

Hm... as far as I can tell my less is pretty straight forward:

% echo $PAGER
less
% less --version
less 418
Copyright (C) 1984-2007 Mark Nudelman

less comes with NO WARRANTY, to the extent permitted by law.
For information about the terms of redistribution,
see the file named README in the less distribution.
Homepage: http://www.greenwoodsoftware.com/less

I do have this though, maybe that can cause some problems?

% env|grep LESS
LESS_TERMCAP_mb=
LESS_TERMCAP_md=
LESS_TERMCAP_me=
LESS_TERMCAP_se=
LESS_TERMCAP_so=
LESS_TERMCAP_ue=
LESS_TERMCAP_us=
LESS=FSRX

This is caused by F in your LESS. Since all the examples here do not need more than a few lines to display, less immediately closes and bpython takes control again. I don't think there's anything we can do here. Detecting if PAGER is less (or something else that points less) seems quite fragile.

I'm closing this issue for now and will add something about it to the documentation.

Out of interest, is there any reason that the bpython screen is immediately redrawn after the pager exits? If bpython would react more like my shell, then it could show the output of the pager inline until I scrolled it out of the buffer by my bpython interaction.

If I'm not mistaken, that should make bpython handle this output the same way a shell would, which should be very compatible and stable.

Hm, so maybe bpython capture stdout of less and print it out? I like thinking of all the special functionality of bpython (save, show source, open in editor, etc.) as being out-of-band; bpython is a Python interpreter with some overlays. Therefore I don't want results from these in history, I want to pretend they never happened. Curious to hear what other people think.

I have to say that the way I use less in my shell is very much as a tool that allows me easy navigation inside a file that I'm viewing - not as something I switch to outside of the shell that is then deleted when it exits. I think that is really a different way to use pagers that could (should?) be supported by my python shell of choice.