Alexander Schmolck | 1 Mar 02:20
Picon

Is ipython too nosy?

Hi,

I would have expected that ipython's (default) policy when the user enters a
line that constitutes a valid python expression and presses return would be to
evaluate the whole expression and not attempt any form of introspection on any
of the constituents.

Not so:

    Python 2.4.4 (#2, Jan 13 2007, 17:50:26) 
    Type "copyright", "credits" or "license" for more information.

    IPython 0.7.3 -- An enhanced Interactive Python.
    ?       -> Introduction to IPython's features.
    %magic  -> Information about IPython's 'magic' % functions.
    help    -> Python's own help system.
    object? -> Details about 'object'. ?object also works, ?? prints more.

    In [1]: class foo(object):
        def __getattr__(self,attr):
            print 'getattr: ', attr; return lambda *args, **kwargs: 'nada'

       ...:    ...:    ...: 
    In [2]: f=foo()

    In [3]: f.bar()
    getattr:  bar()
    getattr:  bar
    Out[3]: 'nada'

(Continue reading)

Fernando Perez | 1 Mar 03:46
Picon
Gravatar

Re: Detecting interactive mode reliably

On 2/28/07, Francesc Altet <faltet <at> carabos.com> wrote:
> Hi,
>
> I'm trying to discover a way to detect whether the python interpreter
> has been called interactively or not. My goal is to avoid costly
> initialization calls in case the a program is not run interactively.
>
> To be more specific, I only need to know whether the interpreter has the
> readline() features activated or not. If they are (and only in this
> case) then I need to preload some attributes on certain classe for easy
> interactive introspection (i.e. using the TAB key).
>
> Anyone has a clue on how to do this? (should be valid for Win as well)

>>> 'readline' in sys.modules
True

Does that do what you want?

Cheers,

f
Fernando Perez | 1 Mar 03:52
Picon
Gravatar

Re: Is ipython too nosy?

Hey Alex,

On 01 Mar 2007 01:20:01 +0000, Alexander Schmolck <a.schmolck <at> gmx.net> wrote:
> Hi,
>
> I would have expected that ipython's (default) policy when the user enters a
> line that constitutes a valid python expression and presses return would be to
> evaluate the whole expression and not attempt any form of introspection on any
> of the constituents.

Life is complicated :)  I don't have time right now for a detailed
discussion, unfortunately, but could you please try SVN trunk (r >=
2122)?  Its behavior should be a LOT better than before (attribs.py
contains your little class definition):

tlon[test]> ip
Python 2.4.4c1 (#2, Oct 11 2006, 21:51:02)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.4.svn.r2120 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: run attribs.py
getattr:  bar

In [2]: f.this('is bad')
getattr:  this
(Continue reading)

aldarion | 1 Mar 07:25
Picon

Re: IPython Color help on windows cmd shell

Hey Fernando,
ctypes can be download from sf.net,
Just FYI.
 
On 3/1/07, Fernando Perez <fperez.net <at> gmail.com> wrote:
so that others can get it easily, since the main site seems down.
Cheers,

f

_______________________________________________
IPython-user mailing list
IPython-user <at> scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-user



_______________________________________________
IPython-user mailing list
IPython-user <at> scipy.org
http://lists.ipython.scipy.org/mailman/listinfo/ipython-user
Alexander Schmolck | 1 Mar 22:00
Picon

Re: Is ipython too nosy?

Hi Fernando,

thanks for the feedback.

"Fernando Perez" <fperez.net <at> gmail.com> writes:

> I don't have time right now for a detailed discussion, unfortunately, but
> could you please try SVN trunk (r >= 2122)? 

Thanks -- I'll give it a try in the next couple of days.

> So in general it is a good idea to have objects that respond as
> robustly as possible to getattr() calls.

Agreed, but you'll have to admit that mlabwrap might be forgiven for not
handling access to attribues like "this('is" well ;) 

Anyway, I've changed mlabwrap to make sure such attribute lookup won't cause
spurious error messages now and I'll upload it soon.

> However, the points you made were most certainly bugs, and I hope they
> are resolved now.  Please let me know how it goes for you.

BTW just as a half baked idea -- have you considered just running
tokenizer.generate_tokens over the input lines (provided they don't start with
"!") for ipython and work from that? I haven't found some quick overview of
the syntax extensions ipython supports, but I would suspect the ones I am
aware of could be implemented on top of a tokenstream from generate_tokens[1]
and that this might make for simpler and more robust code and possibly a nicer
interface for syntactic extensions. One benefit is that you'd get future
lexical syntax supported for free, the other would be that IIRC in the past
there have been possibly confusing bugs that resulted from ipython tokenizing
things in a somewhat ad hoc manner at unexepcted occassions (such as this
one), which presumably mostly involved getting confused by strings.

cheers,

alex

Footnotes: 
[1]  The tokenizer will just spit out error tokens rather than just die so
     occurrences of "tokens" such as "!" that don't occur in legal python, so
     as long as you don't define lots of compound tokens (e.g. :==>) or a
     special string literal syntax that isn't a subset of python strings, it
     might also work reasonably well for dealing with "extended" python-like
     syntaxes.
Fernando Perez | 1 Mar 22:41
Picon
Gravatar

Re: Is ipython too nosy?

On 01 Mar 2007 21:00:22 +0000, Alexander Schmolck <a.schmolck <at> gmx.net> wrote:
> Hi Fernando,
>
> thanks for the feedback.
>
> "Fernando Perez" <fperez.net <at> gmail.com> writes:
>
> > I don't have time right now for a detailed discussion, unfortunately, but
> > could you please try SVN trunk (r >= 2122)?

r >= 2124.  Brown-paper bag bugs...

> > So in general it is a good idea to have objects that respond as
> > robustly as possible to getattr() calls.
>
> Agreed, but you'll have to admit that mlabwrap might be forgiven for not
> handling access to attribues like "this('is" well ;)

Oh, absolutely.  I did agree that was a bug, no doubt.  And fixed it (I think :)

> BTW just as a half baked idea -- have you considered just running
> tokenizer.generate_tokens over the input lines (provided they don't start with
> "!") for ipython and work from that? I haven't found some quick overview of
> the syntax extensions ipython supports, but I would suspect the ones I am
> aware of could be implemented on top of a tokenstream from generate_tokens[1]
> and that this might make for simpler and more robust code and possibly a nicer
> interface for syntactic extensions. One benefit is that you'd get future
> lexical syntax supported for free, the other would be that IIRC in the past
> there have been possibly confusing bugs that resulted from ipython tokenizing
> things in a somewhat ad hoc manner at unexepcted occassions (such as this
> one), which presumably mostly involved getting confused by strings.

I have thought about it, but never really done anything.  Over the
next few weeks, after 0.7.4 is released (need to coordinate that with
the trunk team) I'm going to start moving trunk code over for a merge
with the saw branch.  Once all that restructuring is done and works,
we can think about ideas along these lines.  What I mean is: /I/ don't
have time right now to do it, but if you keep thinking about it, feel
free to drop a line, patch or put up a wiki page with notes.

regards,

f
Brian Granger | 1 Mar 23:12
Picon

Fwd: Is ipython too nosy?

> > BTW just as a half baked idea -- have you considered just running
> > tokenizer.generate_tokens over the input lines (provided they don't start with
> > "!") for ipython and work from that? I haven't found some quick overview of
> > the syntax extensions ipython supports, but I would suspect the ones I am
> > aware of could be implemented on top of a tokenstream from generate_tokens[1]
> > and that this might make for simpler and more robust code and possibly a nicer
> > interface for syntactic extensions. One benefit is that you'd get future
> > lexical syntax supported for free, the other would be that IIRC in the past
> > there have been possibly confusing bugs that resulted from ipython tokenizing
> > things in a somewhat ad hoc manner at unexepcted occassions (such as this
> > one), which presumably mostly involved getting confused by strings.

I had a number of good discussions with people at Pycon last week
about moving in this direction with ipython's extended syntax.  The
main challenge is that ipython's syntax is not a static grammar.  This
is partly what makes it so powerful and yet simple.  But it does
complicate parsing it.

Brian
Thomas Heller | 2 Mar 08:09

Re: IPython Color help on windows cmd shell

Fernando Perez schrieb:
> On 2/28/07, eric jones <eric <at> enthought.com> wrote:
>> Hey Fernando,
>>
>> Your screen shot is down right beautiful.
>>
>> As for the build, I'm unfortunately stuck in 2.4 world for at least
>> another month or two.  We're already shipping ctypes as an egg, so I
>> don't think that should be a problem...  Bryce, how hard is it to update
>> the eggs we distribute to the SVN versions of the packages he mentions?
>> It sounds like it would be an improvement for everyone.  If it is
>> complicated, then we'll take Fernando up on the offer to put 2.4 build
>> up on the site for us.
> 
> OK, Stefan was nice enough to send me a ctypes win32 installer for
> py24, which I put up here:
> 
> http://ipython.scipy.org/dist/testing/
> 
> so that others can get it easily, since the main site seems down.

FYI, the starship which has ctypes homepage is down, but the downloads
are still available in the SF download section:
http://sourceforge.net/projects/ctypes

> With that, I got the attached screenshot, after installing on a clean
> system (I removed the py25 installation first), in this order:
> 
> 1. Python2.4 from Python.org
> 2. Ctypes from the above link.
> 3. Win32 extensions from https://sourceforge.net/projects/pywin32/
> 4. pyreadline and IPython from the above link.
> 
> So the system /does work/ for py24 and py25.  I'll leave it to Bryce
> to shoehorn this into your egg magic.

BTW: There seems to be a problem in IPython with unicode __doc__ strings;
this is on WinXP:

c:\svn\theller>ipy25
Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
Type "copyright", "credits" or "license" for more information.

IPython 0.7.4.svn.r2120 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: class X(object):
   ...:     u"the doc string"
   ...:
   ...:

In [2]: x = X()

In [3]: x??
T y p eX B a s e   C < c l a s s   ' _ _ mS t r i n g    < _ _ m a i n _ _ . X   o b j e cN a m e s pI n t e r a D o c s
 t r i n g   [ s o u r c e   f        t h e   d o

In [4]:
Do you really want to exit ([y]/n)? y

c:\svn\theller>

Thomas
Fernando Perez | 2 Mar 08:38
Picon
Gravatar

Re: IPython Color help on windows cmd shell

On 3/2/07, Thomas Heller <theller <at> ctypes.org> wrote:

> FYI, the starship which has ctypes homepage is down, but the downloads
> are still available in the SF download section:
> http://sourceforge.net/projects/ctypes

Thanks for the pointer, another user had also mentioned it.  I deleted
the copy at scipy then, no point in duplicating it if the original
really is available.

> BTW: There seems to be a problem in IPython with unicode __doc__ strings;
> this is on WinXP:
>
> c:\svn\theller>ipy25
> Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)]
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.7.4.svn.r2120 -- An enhanced Interactive Python.
> ?       -> Introduction to IPython's features.
> %magic  -> Information about IPython's 'magic' % functions.
> help    -> Python's own help system.
> object? -> Details about 'object'. ?object also works, ?? prints more.
>
> In [1]: class X(object):
>    ...:     u"the doc string"
>    ...:
>    ...:
>
> In [2]: x = X()
>
> In [3]: x??
> T y p eX B a s e   C < c l a s s   ' _ _ mS t r i n g    < _ _ m a i n _ _ . X   o b j e cN a m e s pI n t e r a D o c s
>  t r i n g   [ s o u r c e   f        t h e   d o

Mmh, very odd.  I don't see that at all under Linux:

maqroll[~]> ip5
Python 2.5 (r25:51908, Oct  6 2006, 15:22:41)
Type "copyright", "credits" or "license" for more information.

IPython 0.7.4.svn.r2120 -- An enhanced Interactive Python.
?       -> Introduction to IPython's features.
%magic  -> Information about IPython's 'magic' % functions.
help    -> Python's own help system.
object? -> Details about 'object'. ?object also works, ?? prints more.

In [1]: class X(object):
   ...:     u"the docstring"
   ...:

In [2]: x=X()

In [3]: x??
Type:           X
Base Class:     <class '__main__.X'>
String Form:    <__main__.X object at 0x407e2d4c>
Namespace:      Interactive
Docstring [source file open failed]:
    the docstring

I know so little about windows that I honestly don't have a clue as to
what the problem could be.  Any suggestions?

Regards,

f
Robert Kern | 2 Mar 08:56
Picon
Gravatar

Re: IPython Color help on windows cmd shell

Fernando Perez wrote:
> On 3/2/07, Thomas Heller <theller <at> ctypes.org> wrote:

>> In [1]: class X(object):
>>    ...:     u"the doc string"
>>    ...:
>>    ...:
>>
>> In [2]: x = X()
>>
>> In [3]: x??
>> T y p eX B a s e   C < c l a s s   ' _ _ mS t r i n g    < _ _ m a i n _ _ . X   o b j e cN a m e s pI n t e r a D o c s
>>  t r i n g   [ s o u r c e   f        t h e   d o
> 
> Mmh, very odd.  I don't see that at all under Linux:

> I know so little about windows that I honestly don't have a clue as to
> what the problem could be.  Any suggestions?

Various (GUI terminal, font) combinations, on all platforms, want to render
"Unicode" characters as double-width.

--

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

Gmane