From vivainio at gmail.com  Thu Nov  5 16:17:21 2009
From: vivainio at gmail.com (Ville M. Vainio)
Date: Thu, 5 Nov 2009 23:17:21 +0200
Subject: [IPython-dev] [IPython-user] autcompletion and trailing space
In-Reply-To: <d38edb550911040300i638ee89fnaad8a0a5cb8ad9f3@mail.gmail.com>
References: <20091104103820.GB22587@SamZwo.iwr.uni-heidelberg.de>
	<d38edb550911040300i638ee89fnaad8a0a5cb8ad9f3@mail.gmail.com>
Message-ID: <46cb515a0911051317u1faa822ld4bf4f70a919b99c@mail.gmail.com>

On Wed, Nov 4, 2009 at 1:00 PM, Lakshman Prasad <scorpion032 at gmail.com> wrote:

> There is a bug reported on this
> already:?https://bugs.launchpad.net/ipython/+bug/470824
> I have added an explained comment.
> Karmic seems to have added the extra space when completion occurs.
> Ideally, a fix for this needs to read the settings file for adding extra
> spaces, as different shells may complete differently.

So you are saying there is a setting that would fix this somewhere? I
thought it's just a bug...

-- 
Ville M. Vainio
http://tinyurl.com/vainio


From jdh2358 at gmail.com  Fri Nov  6 17:24:05 2009
From: jdh2358 at gmail.com (John Hunter)
Date: Fri, 6 Nov 2009 16:24:05 -0600
Subject: [IPython-dev] ipython sphinx directive
Message-ID: <88e473830911061424y35e0d87bxc84eaa0763cd6d8c@mail.gmail.com>

I have been working on a chapter in sphinx, and make liberal use of
the ipython sourecode lexer and matplotlib plot directive Michael D
wrote, with contributions from others.  I am writing in type-along
fashion, so I do a lot of this::

    .. sourcecode:: ipython

       In [193]: X = imread('moonlanding.png')

       In [195]: imshow(X, cmap='gray')
       Out[195]: <matplotlib.image.AxesImage object at 0x97d1acc>


    .. plot::

       import matplotlib.image as mimage
       import matplotlib.pyplot as plt
       X = mimage.imread('moonlanding.png')

       fig = plt.figure()
       ax = fig.add_subplot(111)
       ax.imshow(X, cmap='gray')
       plt.show()

This works great, but as I continue my example, adding new lines of
ipython, I have to always cut and paste the *full* plot code as the
figure is updated, which is tedious and difficult to maintain.  What I
really want is an ipython sphinx mode, preferably one that is pylab
aware, so all I have to do is

    .. ipython_pylab::

           X = imread('moonlanding.png')
           imshow(X, cmap='gray')

and sphinx will pass this to an embedded ipython session, render the
input and output prompts, and insert any figures that are created.
Then I can update the figure in the next block

    .. ipython_pylab::

           clim(0, 300)
           hot()

and get the updated figure in my docs....

I have taken a crack at this in the "ipython_directive" code below.  I
haven't yet tacked the pylab/figure part, being an ipython newbie, and
have just done the basic ipython part.  We have already cracked the
nut of managing pylab figures in the plot directive, so while this
won't be trivial it's not the hardest part I don't think.  What I want
to focus on here is the ipython part.

Since I suspect this will be of interest to a lot of ipython/sphinx
users, I want to get the interface right.  For example, there is a
good argument to allow the sphinx writer to pass complete ipython
blocks in rather than plain python blocks, so the reader of the plain
unrendered rest document would see both the input and output.  The
ipython directive would in this case just grab the input blocks, strip
off the prompts, execute the code, and (possibly) replace the inputs
and outputs in the rendered docs which would provide auto-renumbering.
 There are a lot of things to balance here -- auto-renumbering is nice
but it makes it hard for the doc-writer to refer to specific line
numbers....

For the simplest case, I just handle plain python inputs, and generate
rendered ipython sessions.  Eg, the following sphinx doc::

  =================
  Ipython Directive
  =================

  The ipython directive is a stateful ipython shell for embedding in
  sphinx documents.

  .. ipython::

     x = 2
     x**3

  The state from previous sessions is stored, and standard error is
  trapped

  .. ipython::

     z = x*3   # x is recalled from previous block
     z
     print z   # this doesn't produce output -- how do I capture this?
     q = z[)   # this is a syntax error -- we trap ipy exceptions

  That's it -- next step is supporting pylab with embedded figs!


The sphinx ipython_directive and rendered html are included below and
attached.  For a working directory with everything ready to build for
testing, you can grab:  http://matplotlib.sf.net/ipymode.zip

Suggestions and improvements welcome --  in addition to input on the
interface,  I could use some help from the ipython devs on on how to
configure my Shell to support magics like 'ls' or 'pwd' and 'cd', how
to fix the "print" problem above, integrating pylab plots...

JDH


import sys, os, shutil, imp, warnings, cStringIO, re
try:
    from hashlib import md5
except ImportError:
    from md5 import md5

from docutils.parsers.rst import directives
try:
    # docutils 0.4
    from docutils.parsers.rst.directives.images import align
except ImportError:
    # docutils 0.5
    from docutils.parsers.rst.directives.images import Image
    align = Image.align
import sphinx


sphinx_version = sphinx.__version__.split(".")
# The split is necessary for sphinx beta versions where the string is
# '6b1'
sphinx_version = tuple([int(re.split('[a-z]', x)[0])
                        for x in sphinx_version[:2]])


import IPython



class EmbeddedSphinxShell:
    def __init__(self):

        self.cout = cStringIO.StringIO()

        IPython.Shell.Term.cout = self.cout
        IPython.Shell.Term.cerr = self.cout
        argv = []
        self.user_ns = {}
        self.user_glocal_ns = {}

        self.IP = IPython.ipmaker.make_IPython(
            argv, self.user_ns, self.user_glocal_ns, embedded=True,
            shell_class=IPython.Shell.InteractiveShell,
            rc_override=dict(colors = 'NoColor'))

    def process(self, line):

        self.cout.write('%s%s\n'%(self.IP.outputcache.prompt1, line))
        self.IP.push(line)
        if (self.IP.SyntaxTB.last_syntax_error and
            self.IP.rc.autoedit_syntax):
            print 'OOPS'
            self.IP.edit_syntax_error()


    def astext(self):
        self.cout.seek(0)
        s = self.cout.read()
        self.cout.truncate(0)
        return s



shell = EmbeddedSphinxShell()


def ipython_directive(name, arguments, options, content, lineno,
                   content_offset, block_text, state, state_machine):

    for line in content:
        shell.process(line)

    lines = shell.astext().split('\n')
    if len(lines):
        ipy_lines = ['.. sourcecode:: ipython', '']
        ipy_lines.extend(['    %s'%line for line in lines])
        ipy_lines.append('')

        state_machine.insert_input(
            ipy_lines, state_machine.input_lines.source(0))

def setup(app):
    setup.app = app
    options = {}
    app.add_directive('ipython', ipython_directive, True, (0, 2, 0), **options)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091106/b7169893/attachment.html>

From gael.varoquaux at normalesup.org  Sat Nov  7 04:51:02 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Sat, 7 Nov 2009 10:51:02 +0100
Subject: [IPython-dev] ipython sphinx directive
In-Reply-To: <88e473830911061424y35e0d87bxc84eaa0763cd6d8c@mail.gmail.com>
References: <88e473830911061424y35e0d87bxc84eaa0763cd6d8c@mail.gmail.com>
Message-ID: <20091107095102.GA2068@phare.normalesup.org>

On Fri, Nov 06, 2009 at 04:24:05PM -0600, John Hunter wrote:
> This works great, but as I continue my example, adding new lines of
> ipython, I have to always cut and paste the *full* plot code as the
> figure is updated, which is tedious and difficult to maintain.  What I
> really want is an ipython sphinx mode, preferably one that is pylab
> aware, so all I have to do is

>     .. ipython_pylab::

>            X = imread('moonlanding.png')
>            imshow(X, cmap='gray')

> and sphinx will pass this to an embedded ipython session, render the
> input and output prompts, and insert any figures that are created.
> Then I can update the figure in the next block

>     .. ipython_pylab::

>            clim(0, 300)
>            hot()

> and get the updated figure in my docs....

Very, very useful. I can't give much feedback, because I have no
available mental bandwidth, but I am very happy that you are tackling
this problem.

Ga?l


From jdh2358 at gmail.com  Sat Nov  7 10:21:27 2009
From: jdh2358 at gmail.com (John Hunter)
Date: Sat, 7 Nov 2009 09:21:27 -0600
Subject: [IPython-dev] ipython sphinx directive
In-Reply-To: <20091107095102.GA2068@phare.normalesup.org>
References: <88e473830911061424y35e0d87bxc84eaa0763cd6d8c@mail.gmail.com>
	<20091107095102.GA2068@phare.normalesup.org>
Message-ID: <88e473830911070721i22622c93g62ad2bd9c671eefc@mail.gmail.com>

On Sat, Nov 7, 2009 at 3:51 AM, Gael Varoquaux
<gael.varoquaux at normalesup.org> wrote:

> Very, very useful. I can't give much feedback, because I have no
> available mental bandwidth

That's OK, I don't either <wink>

I did some thinking overnight and have codified my ideas in a proposal
(appropriately in sphinx) included below -- also in html at
http://matplotlib.sourceforge.net/ipymode/_build/html/proposal.html============================
IPython Directive Proposal
============================

I've been debating the merits of two syntaxes for the embedded ipython
interpreter.  The first alternative, call it "plain python" is to feed
literal python code to ipython, so your rest code looks like::

  .. ipython::

     x = 2
     x**3

and your rendered code looks like this::

  In [1]: x = 2

  In [2]: x**3
  Out[2]: 8

The advantages of this are ease of implementation and a true "what you
see is what you get.  However, there are a number of disadvantages.


In the alternative syntax, call it "ipython prompt", The rst document
includes input and output prompts, but the embedded ipython
interpreter detects the input prompt string 'In [\\d]:' and executes
the code.  I'm leaning towards this syntax, fraught as it is with
complexities, for reasons outlined below.  The rest doc would look
like this::

  .. ipython::

     In [1]: x = 'hello world'

     In [2]: x.upper()
     Out[2]: 'HELLO WORLD'

     @verbatim
     In [3]: x.st<TAB>
     x.startswith  x.strip



The advantages of this approach

* there are some things, illustrated by prompt 3, that we will not be
  able to do in ipython embedded in sphinx, eg illustrating tab
  completion which requires interactive keystrokes and readline.  I
  propose an ``@verbatim`` pseudo-decorator to inform ipython to simply
  put the input and output into the rest document verbatim (modulo
  prompt numbering, see below)

* one of the strengths of rest is that is is human readable in the
  plain text form.  If we input plain python w/o the output prompts::

    .. ipython::

       import numpy as np
       x = np.arange(10)
       x.mean()
       x.std()


  but then refer to the output in the rest narrative like 'the numpy
  array method ``std`` computes the standard deviation of the array as
  2.87', it is hard for the reader and writer of the plain text
  document to follow along.  Also, it is more work for the doc writer,
  who is likely coding the examples in ipython as he works, to paste
  in the code session verbatim -- it was a fair amount of work to
  strip off the input and output prompts, and strip the output, for
  the example above.  Much more natural is to just paste::

    .. ipython::

       In [5]: import numpy as np

       In [6]: x = np.arange(10)

       In [7]: x.mean()
       Out[7]: 4.5

       In [8]: x.std()
       Out[8]: 2.8722813232690143

But there are subtleties and complexities with this approach as well.
These include

* how do we handle numbering?  I'm pretty sure we want auto-numbering.
  With real-world experience writing a chapter using ipython session
  dumps heavily, I find that you frequently want to change a thing or
  two, and the prompt numbering gets out of whack.  Or you come back
  later with a fresh ipython session and insert something into the
  middle of the chapter and your ipython prompt numbers are
  non-monotonic.  So I propose auto-numbering, even for ``@verbatim``
  inputs, where the embedded interpreter will use your input and
  output, but will use its internal prompt counter.  I am punting on
  use of things like ``_10`` to refer to the 10th output -- too hard.
  However, we often want to refer to the input and output line number
  in our narrative text, like "the ``std`` on input line ``In [8]``
  does such-and-such" which we cannot easily do with auto-numbering.
  One solution is to support a new role, something like::


    .. ipython::

       In [7]: x.mean()
       Out[7]: 4.5

       .. _std_x:
       In [8]: x.std()
       Out[8]: 2.8722813232690143


  which we can refer to in our text like::

     the ``std`` call on input line ``In [:iref:`std_x`]`` does such and such.

  a little perl-esque and ugly, but may get the job done.

* What should be rendered for output: the session output or the
  ipython interpreter output.  Normally these should be identical, and
  in fact we can and should support an ``@doctest`` decorator or something
  like that, but there are a number of cases when they will not be
  identical.  One obvious one is when we are dealing with random
  numbers::

    .. ipython::

       In [11]: x = np.random.rand(10)

       In [12]: x.max()
       Out[12]: 0.86805905876197698

  There is an obvious solution here which is to seed the generator
  deterministically, but there are other cases like grabbing a file
  from a web server that may be updated daily (eg stock prices from
  Yahoo Finance) which will also lead to different data at doc build
  time, so we should at least deal with the issue of how to handle
  non-deterministic data.

  I think the only workable solution is to use *ipython's* output and
  not the user output.  Because when we start making figures, the user
  text output and the figure data will not necessarily agree for
  non-deterministic output.  So essentially, I think it is incumbent
  on the doc writer to insure deterministic output.

  We can support a ``@suppress`` decorator and/or argument so the doc writer
  can set up the ipython session to insure deterministic output with
  stuff they may not want reflected in the rendered doc.  Eg, to
  suppress and entire block during a setup phase, we could employ a
  ``:suppress:`` option::


    .. ipython::
       :suppress:

       In [6]: from pylab import *

       In [7]: ion()

       In [8]: import numpy.random

       In [9]: numpy.random.seed(2358)

  Or if grabbing data from a URL which may change, but which we want
  to insure is deterministic (at least to the best of our abilities),
  we could filter the date range to be deterministic but hide some of
  the work using ``@suppress`` for single lines or ``:suppress:`` for
  entire blocks::

    .. ipython::

       In [17]: url = 'http://ichart.finance.yahoo.com/table.csv?s=CROX\
	  ....: &d=9&e=22&f=2009&g=d&a=1&b=8&c=2006&ignore=.csv'

       In [19]: import urllib

       In [21]: fname, msg = urllib.urlretrieve(url)

       In [24]: import matplotlib.mlab as mlab

       In [26]: r = mlab.csv2rec(fname)

    .. ipython::
       :suppress:

       # make sure the date range is deterministic
       In [28]: import datetime

       In [29]: startdate = datetime.date(2006,1,1)

       In [30]: enddate = datetime.date(2009,11,6)

       In [31]: mask = (r.date>=startdate) & (r.date<=enddate)

       In [32]: r = r[mask]



What to do about figures?
-------------------------

In matplotlib's ``plot_directive``, we automatically insert all the
figures that are generated in the plot code into the rest document.
This is very convenient, and may be the approach we want to take in
the ``ipython_directive``, but we may want to consider alternatives.
The ``plot_directive`` works because it is aware of the matplotlib
figure manager which is a pylab helper hidden to normal users.  We
might want to avoid all such magic in ipython mode, and have the user
do everything.  Eg::

    .. ipython::
       :suppress:

       In [4]: import matplotlib
       In [5]: matplotlib.use('Agg')
       In [6]: from pylab import *
       In [7]: ion()

and then when they make a plot::

    .. ipython::

	 In [45]: plot([1,2,3])
	 Out[45]: [<matplotlib.lines.Line2D object at 0xa00e6cc>]

         @suppress
	 In [46]: savefig('_static/myfig.png')

and then we *explicitly* refer to it with an image directive::

    .. image:: _static/myfig.pnh
       :width: 4in

This has the advantage of explicit is better than implicit, but it is
tricky to find the ``_static`` dir, particularly if someone has
navigated in ipython away from the base directory.  We might circumvent
this by supporting a special ``$STATIC`` argument, which the embedded
ipython interpreter would replace with the actual ``_static``
directory.  Thus we could do, from any dir::

    @suppress
    In [46]: savefig('$STATIC/myfig.png')

However, there is still a potential gotcha.  I find in my rendered
PDFs, when I have interleaved a bunch of ``.. sourcecode:: ipython``
and ``..plot::`` commands, that the figures can easily get separated
from the ipython sessions they are associated with.  This is a
familiar problem to LaTeX users: latex will insert the figures at
semi-random spots, and it might be helpful to let the code generation
inside the ipython directive generate both the code and figure
insertion in case there are some latex mode bindings we can do to try
and keep these associated with one another via minipages or even
simple code/figure numbering.  With this in mind, I propose some
special magic, syntax to be determined::

    @insert_fig width=4in
    In [46]: savefig('myfig.png')

which will both save the fig to the static directory and insert it
into the document.

Proposed pseudo-decorators
---------------------------

``@suppress``
    execute the ipython input block, but suppress the input and output
    block from the rendered output.


``@verbatim``
    insert the input and output block in verbatim, but auto-increment
    the line numbers.  Internally, the interpreter will be fed an
    empty string, so it is a no-op that keeps line numbering
    consistent

``@insert_fig``
    save the figure to the static directory and insert it into the
    document, possibly binding it into a minipage and/or putting
    code/figure label/references to associate the code and the figure.
    Takes args to pass to the image directive (scale, width, etc can
    be kwargs)

``@doctest``
    Compare the pasted in output in the ipython block with the output
    generated at doc build time, and raise errors if they don't match.
    We may also want a ``:doctest:`` option to the ipython directive
    to test the entire block.

Special roles
-------------

``iref``
    ipython input blocks can be tagged with the standard label syntax,
    eg ``.. _std_x:`` and later referred to with :iref:`std_x` which
    will insert the *number* of the referenced prompt into the
    narrative text.


Proposed options
------------------

``:doctest:``
    Doctest the entire block


``:suppress:``
    Execute the entire block in the ipython session but insert nothing


From gokhansever at gmail.com  Sat Nov  7 23:56:16 2009
From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_Sever?=)
Date: Sat, 7 Nov 2009 22:56:16 -0600
Subject: [IPython-dev] "__builtins__.True = False" causes weird behaviours
Message-ID: <49d6b3500911072056u79462dc9h98d6d881eea5077a@mail.gmail.com>

Hello,

After reading the "Breaking the Universe in Python 2.6" section (Pg. 414) in
Mark Lutz's Learning Python 4th Edition. Two issues appeared as shown below:
*
1-) If I start ipython -pylab the mentioned assignment completely blocks the
session. Only stopping or killing the process ends the current session.*

[gsever at ccn Desktop]$ ipython -pylab
 Logging to /home/gsever/.ipython/2009-11-07.py

Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
Type "copyright", "credits" or "license" for more information.

IPython 0.10 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

  Welcome to pylab, a matplotlib-based Python environment.
  For more information, type 'help(pylab)'.

I[1]: __builtins__.True = False
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.6/threading.py", line 522, in __bootstrap_inner
    self.run()
  File "/home/gsever/Desktop/python-repo/ipython/IPython/Shell.py", line
760, in run
    self.IP.mainloop(self._banner)
  File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
1760, in mainloop
    self.interact(banner)
  File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
1998, in interact
    more = self.push(line)
  File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
2302, in push
    more = self.runsource('\n'.join(self.buffer), self.filename)
  File "/home/gsever/Desktop/python-repo/ipython/IPython/Shell.py", line
431, in runsource
    completed_ev.wait()
  File "/usr/lib/python2.6/threading.py", line 393, in wait
    self.__cond.wait(timeout)
  File "/usr/lib/python2.6/threading.py", line 230, in wait
    raise RuntimeError("cannot wait on un-aquired lock")
RuntimeError: cannot wait on un-aquired lock

Unhandled exception in thread started by <bound method
IPShellMatplotlibQt4.__bootstrap of <IPShellMatplotlibQt4(Thread-1, started
-1230734480)>>
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)

/usr/lib/python2.6/threading.pyc in __bootstrap(self)
    495         # if a non-daemonic encounters this, something else is
wrong.

    496         try:
--> 497             self.__bootstrap_inner()
    498         except:
    499             if self.__daemonic and _sys is None:

/usr/lib/python2.6/threading.pyc in __bootstrap_inner(self)
    568         finally:
    569             with _active_limbo_lock:
--> 570                 self.__stop()
    571                 try:
    572                     # We don't call self.__delete() because it also


/usr/lib/python2.6/threading.pyc in __stop(self)
    579         self.__block.acquire()
    580         self.__stopped = True
--> 581         self.__block.notify_all()
    582         self.__block.release()
    583

/usr/lib/python2.6/threading.pyc in notifyAll(self)
    287
    288     def notifyAll(self):
--> 289         self.notify(len(self.__waiters))
    290
    291     notify_all = notifyAll

/usr/lib/python2.6/threading.pyc in notify(self, n)
    270     def notify(self, n=1):
    271         if not self._is_owned():
--> 272             raise RuntimeError("cannot notify on un-aquired lock")
    273         __waiters = self.__waiters
    274         waiters = __waiters[:n]

RuntimeError: cannot notify on un-aquired
lock---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)

/home/gsever/Desktop/python-repo/ipython/IPython/Shell.pyc in on_timer(self)
   1075     def on_timer(self):
   1076         update_tk(self.tk)
-> 1077         result = self.IP.runcode()
   1078         self.timer.start(self.TIMEOUT)
   1079         return result

/home/gsever/Desktop/python-repo/ipython/IPython/Shell.pyc in runcode(self)
    491                 CODE_RUN = False
    492                 # allow runsource() return from wait

--> 493                 completed_ev.set()
    494
    495

/usr/lib/python2.6/threading.pyc in set(self)
    376         try:
    377             self.__flag = True
--> 378             self.__cond.notify_all()
    379         finally:
    380             self.__cond.release()

/usr/lib/python2.6/threading.pyc in notifyAll(self)
    287
    288     def notifyAll(self):
--> 289         self.notify(len(self.__waiters))
    290
    291     notify_all = notifyAll

/usr/lib/python2.6/threading.pyc in notify(self, n)
    270     def notify(self, n=1):
    271         if not self._is_owned():
--> 272             raise RuntimeError("cannot notify on un-aquired lock")
    273         __waiters = self.__waiters
    274         waiters = __waiters[:n]

RuntimeError: cannot notify on un-aquired lock

*
2-) Testing just with regular ipython. This time it gets even more bizarre.
*

In[1] It lets to do the assignment.
In[2] A simple calculation results ok
In[3] Tab-completion is blocked
In[4] ? cannot retrieve the documentation
In[5] exit() doesn't leave the session

[gsever at ccn Desktop]$ ipython
 Logging to /home/gsever/.ipython/2009-11-07.py

Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
Type "copyright", "credits" or "license" for more information.

IPython 0.10 -- An enhanced Interactive Python.
?         -> Introduction and overview of IPython's features.
%quickref -> Quick reference.
help      -> Python's own help system.
object?   -> Details about 'object'. ?object also works, ?? prints more.

I[1]: __builtins__.True = False

I[2]: 2*5
O[2]: 10

I[3]: import a
---------------------------------------------------------------------------
ImportError                               Traceback (most recent call last)

/home/gsever/Desktop/<ipython console> in <module>()

ImportError: No module named a

I[4]: __builtins__.?
---------------------------------------------------------------------------
KeyError                                  Traceback (most recent call last)

/home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
multiline_prefilter(self, line, continue_prompt)
   2456         out = []
   2457         for l in line.rstrip('\n').split('\n'):
-> 2458             out.append(self._prefilter(l, continue_prompt))
   2459         return '\n'.join(out)
   2460

/home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
_prefilter(self, line, continue_prompt)
   2438         #print 'pre <%s> iFun <%s> rest <%s>' % (pre,iFun,theRest)
# dbg

   2439
-> 2440         return prefilter.prefilter(line_info, self)
   2441
   2442

/home/gsever/Desktop/python-repo/ipython/IPython/prefilter.pyc in
prefilter(line_info, ip)
    149         handler = check(line_info, ip)
    150         if handler:
--> 151             return handler(line_info)
    152
    153     return ip.handle_normal(line_info)

/home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
handle_help(self, line_info)
   2627             if line:
   2628                 #print 'line:<%r>' % line  # dbg

-> 2629                 self.magic_pinfo(line)
   2630             else:
   2631                 page(self.usage,screen_lines=self.rc.screen_length)

/home/gsever/Desktop/python-repo/ipython/IPython/Magic.pyc in
magic_pinfo(self, parameter_s, namespaces)
    658         else:
    659             self._inspect('pinfo', oname, detail_level=detail_level,

*** ERROR: EOF in multi-line statement

--> 660                           namespaces=namespaces)

*** ERROR: EOF in multi-line statement

    661
    662     def magic_pdef(self, parameter_s='', namespaces=None):

/home/gsever/Desktop/python-repo/ipython/IPython/Magic.pyc in _inspect(self,
meth, oname, namespaces, **kw)
    714             return 'not found'
    715
--> 716         info = Struct(self._ofind(oname, namespaces))
    717
    718         if info.found:

/home/gsever/Desktop/python-repo/ipython/IPython/ipstruct.pyc in
__init__(self, dict, **kw)
    125         # safety-checked __setitem__

    126         for k,v in dict.items():
--> 127             self[k] = v
    128
    129

/home/gsever/Desktop/python-repo/ipython/IPython/ipstruct.pyc in
__setitem__(self, key, value)
    135             raise KeyError(

*** ERROR: EOF in multi-line statement

    136             "Can't create unknown attribute %s - Check for typos, or
use allow_new_attr to create new attributes!" %
--> 137             key)

*** ERROR: EOF in multi-line statement

    138
    139         self.__dict__[key] = value

KeyError: "Can't create unknown attribute obj - Check for typos, or use
allow_new_attr to create new attributes!"

I[5]: exit()
Do you really want to exit ([y]/n)? y

I[6]: # Still in IPython


*3) Using the default interpreter:*

[gsever at ccn Desktop]$ python
Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
[GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> __builtins__.True = False
>>> __builtins__.True == True
True
>>> True == False
True

The book says this type of assignment is not allowed in Python 3. So far,
this is the weirdest issue I have ever seen relating to the IPython.

-- 
G?khan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091107/da10e62e/attachment.html>

From ellisonbg.net at gmail.com  Sun Nov  8 00:34:33 2009
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sat, 7 Nov 2009 21:34:33 -0800
Subject: [IPython-dev] "__builtins__.True = False" causes weird
	behaviours
In-Reply-To: <49d6b3500911072056u79462dc9h98d6d881eea5077a@mail.gmail.com>
References: <49d6b3500911072056u79462dc9h98d6d881eea5077a@mail.gmail.com>
Message-ID: <6ce0ac130911072134rcfadda3ld750a3c0b7de7eb@mail.gmail.com>

He he.  The good news is that trunk fixes most of this...

In [2]: __builtins__.True = False

In [3]: __builtins__.True == False
Out[3]: True

But exiting doesn't work:

In [4]: Exit

In [5]:

The reason exiting doesn't work is that ask_exit is called by Exit, exit()
and quit():

    def ask_exit(self):
        """ Call for exiting. Can be overiden and used as a callback. """
        self.exit_now = True

But if True is False, self.exit_now won't trigger the exit.

The funny thing is that doing the opposite really screws things up:

In [1]: __builtins__.False = True
   ...:
   ...:
   ...:
   ...:
   ...:   # stuck  forever indented...

But, just because you can hit your head with a hammer, doesn't mean you
should...;-)

Cheers,

Brian



On Sat, Nov 7, 2009 at 8:56 PM, G?khan Sever <gokhansever at gmail.com> wrote:

> Hello,
>
> After reading the "Breaking the Universe in Python 2.6" section (Pg. 414)
> in Mark Lutz's Learning Python 4th Edition. Two issues appeared as shown
> below:
> *
> 1-) If I start ipython -pylab the mentioned assignment completely blocks
> the session. Only stopping or killing the process ends the current session.
> *
>
> [gsever at ccn Desktop]$ ipython -pylab
>  Logging to /home/gsever/.ipython/2009-11-07.py
>
> Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.10 -- An enhanced Interactive Python.
> ?         -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help      -> Python's own help system.
> object?   -> Details about 'object'. ?object also works, ?? prints more.
>
>   Welcome to pylab, a matplotlib-based Python environment.
>   For more information, type 'help(pylab)'.
>
> I[1]: __builtins__.True = False
> Exception in thread Thread-1:
> Traceback (most recent call last):
>   File "/usr/lib/python2.6/threading.py", line 522, in __bootstrap_inner
>     self.run()
>   File "/home/gsever/Desktop/python-repo/ipython/IPython/Shell.py", line
> 760, in run
>     self.IP.mainloop(self._banner)
>   File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
> 1760, in mainloop
>     self.interact(banner)
>   File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
> 1998, in interact
>     more = self.push(line)
>   File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
> 2302, in push
>     more = self.runsource('\n'.join(self.buffer), self.filename)
>   File "/home/gsever/Desktop/python-repo/ipython/IPython/Shell.py", line
> 431, in runsource
>     completed_ev.wait()
>   File "/usr/lib/python2.6/threading.py", line 393, in wait
>     self.__cond.wait(timeout)
>   File "/usr/lib/python2.6/threading.py", line 230, in wait
>     raise RuntimeError("cannot wait on un-aquired lock")
> RuntimeError: cannot wait on un-aquired lock
>
> Unhandled exception in thread started by <bound method
> IPShellMatplotlibQt4.__bootstrap of <IPShellMatplotlibQt4(Thread-1, started
> -1230734480)>>
> ---------------------------------------------------------------------------
> RuntimeError                              Traceback (most recent call last)
>
> /usr/lib/python2.6/threading.pyc in __bootstrap(self)
>     495         # if a non-daemonic encounters this, something else is
> wrong.
>
>     496         try:
> --> 497             self.__bootstrap_inner()
>     498         except:
>     499             if self.__daemonic and _sys is None:
>
> /usr/lib/python2.6/threading.pyc in __bootstrap_inner(self)
>     568         finally:
>     569             with _active_limbo_lock:
> --> 570                 self.__stop()
>     571                 try:
>     572                     # We don't call self.__delete() because it also
>
>
> /usr/lib/python2.6/threading.pyc in __stop(self)
>     579         self.__block.acquire()
>     580         self.__stopped = True
> --> 581         self.__block.notify_all()
>     582         self.__block.release()
>     583
>
> /usr/lib/python2.6/threading.pyc in notifyAll(self)
>     287
>     288     def notifyAll(self):
> --> 289         self.notify(len(self.__waiters))
>     290
>     291     notify_all = notifyAll
>
> /usr/lib/python2.6/threading.pyc in notify(self, n)
>     270     def notify(self, n=1):
>     271         if not self._is_owned():
> --> 272             raise RuntimeError("cannot notify on un-aquired lock")
>     273         __waiters = self.__waiters
>     274         waiters = __waiters[:n]
>
> RuntimeError: cannot notify on un-aquired
> lock---------------------------------------------------------------------------
> RuntimeError                              Traceback (most recent call last)
>
> /home/gsever/Desktop/python-repo/ipython/IPython/Shell.pyc in
> on_timer(self)
>    1075     def on_timer(self):
>    1076         update_tk(self.tk)
> -> 1077         result = self.IP.runcode()
>    1078         self.timer.start(self.TIMEOUT)
>    1079         return result
>
> /home/gsever/Desktop/python-repo/ipython/IPython/Shell.pyc in runcode(self)
>     491                 CODE_RUN = False
>     492                 # allow runsource() return from wait
>
> --> 493                 completed_ev.set()
>     494
>     495
>
> /usr/lib/python2.6/threading.pyc in set(self)
>     376         try:
>     377             self.__flag = True
> --> 378             self.__cond.notify_all()
>     379         finally:
>     380             self.__cond.release()
>
> /usr/lib/python2.6/threading.pyc in notifyAll(self)
>     287
>     288     def notifyAll(self):
> --> 289         self.notify(len(self.__waiters))
>     290
>     291     notify_all = notifyAll
>
> /usr/lib/python2.6/threading.pyc in notify(self, n)
>     270     def notify(self, n=1):
>     271         if not self._is_owned():
> --> 272             raise RuntimeError("cannot notify on un-aquired lock")
>     273         __waiters = self.__waiters
>     274         waiters = __waiters[:n]
>
> RuntimeError: cannot notify on un-aquired lock
>
> *
> 2-) Testing just with regular ipython. This time it gets even more bizarre.
> *
>
> In[1] It lets to do the assignment.
> In[2] A simple calculation results ok
> In[3] Tab-completion is blocked
> In[4] ? cannot retrieve the documentation
> In[5] exit() doesn't leave the session
>
> [gsever at ccn Desktop]$ ipython
>  Logging to /home/gsever/.ipython/2009-11-07.py
>
> Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
> Type "copyright", "credits" or "license" for more information.
>
> IPython 0.10 -- An enhanced Interactive Python.
> ?         -> Introduction and overview of IPython's features.
> %quickref -> Quick reference.
> help      -> Python's own help system.
> object?   -> Details about 'object'. ?object also works, ?? prints more.
>
> I[1]: __builtins__.True = False
>
> I[2]: 2*5
> O[2]: 10
>
> I[3]: import a
> ---------------------------------------------------------------------------
> ImportError                               Traceback (most recent call last)
>
> /home/gsever/Desktop/<ipython console> in <module>()
>
> ImportError: No module named a
>
> I[4]: __builtins__.?
> ---------------------------------------------------------------------------
> KeyError                                  Traceback (most recent call last)
>
> /home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
> multiline_prefilter(self, line, continue_prompt)
>    2456         out = []
>    2457         for l in line.rstrip('\n').split('\n'):
> -> 2458             out.append(self._prefilter(l, continue_prompt))
>    2459         return '\n'.join(out)
>    2460
>
> /home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
> _prefilter(self, line, continue_prompt)
>    2438         #print 'pre <%s> iFun <%s> rest <%s>' % (pre,iFun,theRest)
> # dbg
>
>    2439
> -> 2440         return prefilter.prefilter(line_info, self)
>    2441
>    2442
>
> /home/gsever/Desktop/python-repo/ipython/IPython/prefilter.pyc in
> prefilter(line_info, ip)
>     149         handler = check(line_info, ip)
>     150         if handler:
> --> 151             return handler(line_info)
>     152
>     153     return ip.handle_normal(line_info)
>
> /home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
> handle_help(self, line_info)
>    2627             if line:
>    2628                 #print 'line:<%r>' % line  # dbg
>
> -> 2629                 self.magic_pinfo(line)
>    2630             else:
>    2631                 page(self.usage,screen_lines=self.rc.screen_length)
>
> /home/gsever/Desktop/python-repo/ipython/IPython/Magic.pyc in
> magic_pinfo(self, parameter_s, namespaces)
>     658         else:
>     659             self._inspect('pinfo', oname,
> detail_level=detail_level,
>
> *** ERROR: EOF in multi-line statement
>
> --> 660                           namespaces=namespaces)
>
> *** ERROR: EOF in multi-line statement
>
>     661
>     662     def magic_pdef(self, parameter_s='', namespaces=None):
>
> /home/gsever/Desktop/python-repo/ipython/IPython/Magic.pyc in
> _inspect(self, meth, oname, namespaces, **kw)
>     714             return 'not found'
>     715
> --> 716         info = Struct(self._ofind(oname, namespaces))
>     717
>     718         if info.found:
>
> /home/gsever/Desktop/python-repo/ipython/IPython/ipstruct.pyc in
> __init__(self, dict, **kw)
>     125         # safety-checked __setitem__
>
>     126         for k,v in dict.items():
> --> 127             self[k] = v
>     128
>     129
>
> /home/gsever/Desktop/python-repo/ipython/IPython/ipstruct.pyc in
> __setitem__(self, key, value)
>     135             raise KeyError(
>
> *** ERROR: EOF in multi-line statement
>
>     136             "Can't create unknown attribute %s - Check for typos,
> or use allow_new_attr to create new attributes!" %
> --> 137             key)
>
> *** ERROR: EOF in multi-line statement
>
>     138
>     139         self.__dict__[key] = value
>
> KeyError: "Can't create unknown attribute obj - Check for typos, or use
> allow_new_attr to create new attributes!"
>
> I[5]: exit()
> Do you really want to exit ([y]/n)? y
>
> I[6]: # Still in IPython
>
>
> *3) Using the default interpreter:*
>
> [gsever at ccn Desktop]$ python
> Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
> [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> __builtins__.True = False
> >>> __builtins__.True == True
> True
> >>> True == False
> True
>
> The book says this type of assignment is not allowed in Python 3. So far,
> this is the weirdest issue I have ever seen relating to the IPython.
>
> --
> G?khan
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091107/76f35ea3/attachment.html>

From gokhansever at gmail.com  Sun Nov  8 13:09:42 2009
From: gokhansever at gmail.com (=?UTF-8?Q?G=C3=B6khan_Sever?=)
Date: Sun, 8 Nov 2009 12:09:42 -0600
Subject: [IPython-dev] "__builtins__.True = False" causes weird
	behaviours
In-Reply-To: <6ce0ac130911072134rcfadda3ld750a3c0b7de7eb@mail.gmail.com>
References: <49d6b3500911072056u79462dc9h98d6d881eea5077a@mail.gmail.com>
	<6ce0ac130911072134rcfadda3ld750a3c0b7de7eb@mail.gmail.com>
Message-ID: <49d6b3500911081009l39836cc8q402a25b56e6ba1e9@mail.gmail.com>

On Sat, Nov 7, 2009 at 11:34 PM, Brian Granger <ellisonbg.net at gmail.com>wrote:

> He he.  The good news is that trunk fixes most of this...
>
> In [2]: __builtins__.True = False
>
> In [3]: __builtins__.True == False
> Out[3]: True
>
> But exiting doesn't work:
>
> In [4]: Exit
>
> In [5]:
>
> The reason exiting doesn't work is that ask_exit is called by Exit, exit()
> and quit():
>
>     def ask_exit(self):
>         """ Call for exiting. Can be overiden and used as a callback. """
>         self.exit_now = True
>
> But if True is False, self.exit_now won't trigger the exit.
>
> The funny thing is that doing the opposite really screws things up:
>
> In [1]: __builtins__.False = True
>    ...:
>    ...:
>    ...:
>    ...:
>    ...:   # stuck  forever indented...
>
> But, just because you can hit your head with a hammer, doesn't mean you
> should...;-)
>
> Cheers,
>
> Brian
>
>
>
Good morning :)

How do you fix these in the trunk? Raising an exception if a user enters any
of the forbidden assignments ?

Fortunately not many out who has the obsession of defining True as False.
Somewhat I connect this to Wittgenstein's belief that "There are no
philosophical questions, but only language puzzles."



>
> On Sat, Nov 7, 2009 at 8:56 PM, G?khan Sever <gokhansever at gmail.com>wrote:
>
>> Hello,
>>
>> After reading the "Breaking the Universe in Python 2.6" section (Pg. 414)
>> in Mark Lutz's Learning Python 4th Edition. Two issues appeared as shown
>> below:
>> *
>> 1-) If I start ipython -pylab the mentioned assignment completely blocks
>> the session. Only stopping or killing the process ends the current session.
>> *
>>
>> [gsever at ccn Desktop]$ ipython -pylab
>>  Logging to /home/gsever/.ipython/2009-11-07.py
>>
>> Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
>> Type "copyright", "credits" or "license" for more information.
>>
>> IPython 0.10 -- An enhanced Interactive Python.
>> ?         -> Introduction and overview of IPython's features.
>> %quickref -> Quick reference.
>> help      -> Python's own help system.
>> object?   -> Details about 'object'. ?object also works, ?? prints more.
>>
>>   Welcome to pylab, a matplotlib-based Python environment.
>>   For more information, type 'help(pylab)'.
>>
>> I[1]: __builtins__.True = False
>> Exception in thread Thread-1:
>> Traceback (most recent call last):
>>   File "/usr/lib/python2.6/threading.py", line 522, in __bootstrap_inner
>>     self.run()
>>   File "/home/gsever/Desktop/python-repo/ipython/IPython/Shell.py", line
>> 760, in run
>>     self.IP.mainloop(self._banner)
>>   File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
>> 1760, in mainloop
>>     self.interact(banner)
>>   File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
>> 1998, in interact
>>     more = self.push(line)
>>   File "/home/gsever/Desktop/python-repo/ipython/IPython/iplib.py", line
>> 2302, in push
>>     more = self.runsource('\n'.join(self.buffer), self.filename)
>>   File "/home/gsever/Desktop/python-repo/ipython/IPython/Shell.py", line
>> 431, in runsource
>>     completed_ev.wait()
>>   File "/usr/lib/python2.6/threading.py", line 393, in wait
>>     self.__cond.wait(timeout)
>>   File "/usr/lib/python2.6/threading.py", line 230, in wait
>>     raise RuntimeError("cannot wait on un-aquired lock")
>> RuntimeError: cannot wait on un-aquired lock
>>
>> Unhandled exception in thread started by <bound method
>> IPShellMatplotlibQt4.__bootstrap of <IPShellMatplotlibQt4(Thread-1, started
>> -1230734480)>>
>>
>> ---------------------------------------------------------------------------
>> RuntimeError                              Traceback (most recent call
>> last)
>>
>> /usr/lib/python2.6/threading.pyc in __bootstrap(self)
>>     495         # if a non-daemonic encounters this, something else is
>> wrong.
>>
>>     496         try:
>> --> 497             self.__bootstrap_inner()
>>     498         except:
>>     499             if self.__daemonic and _sys is None:
>>
>> /usr/lib/python2.6/threading.pyc in __bootstrap_inner(self)
>>     568         finally:
>>     569             with _active_limbo_lock:
>> --> 570                 self.__stop()
>>     571                 try:
>>     572                     # We don't call self.__delete() because it
>> also
>>
>>
>> /usr/lib/python2.6/threading.pyc in __stop(self)
>>     579         self.__block.acquire()
>>     580         self.__stopped = True
>> --> 581         self.__block.notify_all()
>>     582         self.__block.release()
>>     583
>>
>> /usr/lib/python2.6/threading.pyc in notifyAll(self)
>>     287
>>     288     def notifyAll(self):
>> --> 289         self.notify(len(self.__waiters))
>>     290
>>     291     notify_all = notifyAll
>>
>> /usr/lib/python2.6/threading.pyc in notify(self, n)
>>     270     def notify(self, n=1):
>>     271         if not self._is_owned():
>> --> 272             raise RuntimeError("cannot notify on un-aquired lock")
>>     273         __waiters = self.__waiters
>>     274         waiters = __waiters[:n]
>>
>> RuntimeError: cannot notify on un-aquired
>> lock---------------------------------------------------------------------------
>> RuntimeError                              Traceback (most recent call
>> last)
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/Shell.pyc in
>> on_timer(self)
>>    1075     def on_timer(self):
>>    1076         update_tk(self.tk)
>> -> 1077         result = self.IP.runcode()
>>    1078         self.timer.start(self.TIMEOUT)
>>    1079         return result
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/Shell.pyc in
>> runcode(self)
>>     491                 CODE_RUN = False
>>     492                 # allow runsource() return from wait
>>
>> --> 493                 completed_ev.set()
>>     494
>>     495
>>
>> /usr/lib/python2.6/threading.pyc in set(self)
>>     376         try:
>>     377             self.__flag = True
>> --> 378             self.__cond.notify_all()
>>     379         finally:
>>     380             self.__cond.release()
>>
>> /usr/lib/python2.6/threading.pyc in notifyAll(self)
>>     287
>>     288     def notifyAll(self):
>> --> 289         self.notify(len(self.__waiters))
>>     290
>>     291     notify_all = notifyAll
>>
>> /usr/lib/python2.6/threading.pyc in notify(self, n)
>>     270     def notify(self, n=1):
>>     271         if not self._is_owned():
>> --> 272             raise RuntimeError("cannot notify on un-aquired lock")
>>     273         __waiters = self.__waiters
>>     274         waiters = __waiters[:n]
>>
>> RuntimeError: cannot notify on un-aquired lock
>>
>> *
>> 2-) Testing just with regular ipython. This time it gets even more
>> bizarre. *
>>
>> In[1] It lets to do the assignment.
>> In[2] A simple calculation results ok
>> In[3] Tab-completion is blocked
>> In[4] ? cannot retrieve the documentation
>> In[5] exit() doesn't leave the session
>>
>> [gsever at ccn Desktop]$ ipython
>>  Logging to /home/gsever/.ipython/2009-11-07.py
>>
>> Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
>> Type "copyright", "credits" or "license" for more information.
>>
>> IPython 0.10 -- An enhanced Interactive Python.
>> ?         -> Introduction and overview of IPython's features.
>> %quickref -> Quick reference.
>> help      -> Python's own help system.
>> object?   -> Details about 'object'. ?object also works, ?? prints more.
>>
>> I[1]: __builtins__.True = False
>>
>> I[2]: 2*5
>> O[2]: 10
>>
>> I[3]: import a
>>
>> ---------------------------------------------------------------------------
>> ImportError                               Traceback (most recent call
>> last)
>>
>> /home/gsever/Desktop/<ipython console> in <module>()
>>
>> ImportError: No module named a
>>
>> I[4]: __builtins__.?
>>
>> ---------------------------------------------------------------------------
>> KeyError                                  Traceback (most recent call
>> last)
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
>> multiline_prefilter(self, line, continue_prompt)
>>    2456         out = []
>>    2457         for l in line.rstrip('\n').split('\n'):
>> -> 2458             out.append(self._prefilter(l, continue_prompt))
>>    2459         return '\n'.join(out)
>>    2460
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
>> _prefilter(self, line, continue_prompt)
>>    2438         #print 'pre <%s> iFun <%s> rest <%s>' %
>> (pre,iFun,theRest)  # dbg
>>
>>    2439
>> -> 2440         return prefilter.prefilter(line_info, self)
>>    2441
>>    2442
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/prefilter.pyc in
>> prefilter(line_info, ip)
>>     149         handler = check(line_info, ip)
>>     150         if handler:
>> --> 151             return handler(line_info)
>>     152
>>     153     return ip.handle_normal(line_info)
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/iplib.pyc in
>> handle_help(self, line_info)
>>    2627             if line:
>>    2628                 #print 'line:<%r>' % line  # dbg
>>
>> -> 2629                 self.magic_pinfo(line)
>>    2630             else:
>>    2631
>> page(self.usage,screen_lines=self.rc.screen_length)
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/Magic.pyc in
>> magic_pinfo(self, parameter_s, namespaces)
>>     658         else:
>>     659             self._inspect('pinfo', oname,
>> detail_level=detail_level,
>>
>> *** ERROR: EOF in multi-line statement
>>
>> --> 660                           namespaces=namespaces)
>>
>> *** ERROR: EOF in multi-line statement
>>
>>     661
>>     662     def magic_pdef(self, parameter_s='', namespaces=None):
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/Magic.pyc in
>> _inspect(self, meth, oname, namespaces, **kw)
>>     714             return 'not found'
>>     715
>> --> 716         info = Struct(self._ofind(oname, namespaces))
>>     717
>>     718         if info.found:
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/ipstruct.pyc in
>> __init__(self, dict, **kw)
>>     125         # safety-checked __setitem__
>>
>>     126         for k,v in dict.items():
>> --> 127             self[k] = v
>>     128
>>     129
>>
>> /home/gsever/Desktop/python-repo/ipython/IPython/ipstruct.pyc in
>> __setitem__(self, key, value)
>>     135             raise KeyError(
>>
>> *** ERROR: EOF in multi-line statement
>>
>>     136             "Can't create unknown attribute %s - Check for typos,
>> or use allow_new_attr to create new attributes!" %
>> --> 137             key)
>>
>> *** ERROR: EOF in multi-line statement
>>
>>     138
>>     139         self.__dict__[key] = value
>>
>> KeyError: "Can't create unknown attribute obj - Check for typos, or use
>> allow_new_attr to create new attributes!"
>>
>> I[5]: exit()
>> Do you really want to exit ([y]/n)? y
>>
>> I[6]: # Still in IPython
>>
>>
>> *3) Using the default interpreter:*
>>
>> [gsever at ccn Desktop]$ python
>> Python 2.6 (r26:66714, Jun  8 2009, 16:07:26)
>> [GCC 4.4.0 20090506 (Red Hat 4.4.0-4)] on linux2
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> __builtins__.True = False
>> >>> __builtins__.True == True
>> True
>> >>> True == False
>> True
>>
>> The book says this type of assignment is not allowed in Python 3. So far,
>> this is the weirdest issue I have ever seen relating to the IPython.
>>
>> --
>> G?khan
>>
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>>
>>
>


-- 
G?khan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091108/d98a3a6d/attachment.html>

From jdh2358 at gmail.com  Sun Nov  8 13:18:17 2009
From: jdh2358 at gmail.com (John Hunter)
Date: Sun, 8 Nov 2009 12:18:17 -0600
Subject: [IPython-dev] ipython sphinx directive
In-Reply-To: <88e473830911070721i22622c93g62ad2bd9c671eefc@mail.gmail.com>
References: <88e473830911061424y35e0d87bxc84eaa0763cd6d8c@mail.gmail.com>
	<20091107095102.GA2068@phare.normalesup.org>
	<88e473830911070721i22622c93g62ad2bd9c671eefc@mail.gmail.com>
Message-ID: <88e473830911081018t312c61dbt1caac66eee6b5dcd@mail.gmail.com>

On Sat, Nov 7, 2009 at 9:21 AM, John Hunter <jdh2358 at gmail.com> wrote:
> On Sat, Nov 7, 2009 at 3:51 AM, Gael Varoquaux
> <gael.varoquaux at normalesup.org> wrote:
>
>> Very, very useful. I can't give much feedback, because I have no
>> available mental bandwidth
>
> That's OK, I don't either <wink>
>
> I did some thinking overnight and have codified my ideas in a proposal
> (appropriately in sphinx) included below -- also in html at
> http://matplotlib.sourceforge.net/ipymode/_build/html/proposal.html

OK, I've implemented 95% of the proposal;  pylab/pyplot is supported,
as are multi-line inputs and outputs, and the verbatim, doctest and
suppress directives.

A demo document is included below, which is rendered at
http://matplotlib.sourceforge.net/ipymode/_build/html/ipy_demo.html,
and the ipython_directive is attached.  Stuff that still needs work:

  * A bit of cleaning needs to be done, since I am currently mixing in
ipython and matplotlib functionality and I suspect some will want a
clean segregation, but that will not be too hard.

  *  I have yet to implement the ifre's from the proposal, but will
take a look at that shortly.

  * Another big piece that I don't know how to handle yet are the
magics like 'cd', 'pwd', 'ls'.

  * on the doctest I am currently raising an exception on failure
which breaks the build.  I should be inserting some red ERROR code in
the rendered docs, probably.

  * there are several limitations -- I hard code the prompt fmts, I
assume two blank new lines breaks an input/output block (some string
output might have multiple new lines in it), I have some internal
hacks arising from my limited understanding of ipy API,

Very exciting stuff!


=================
Ipython Directive
=================

The ipython directive is a stateful ipython shell for embedding in
sphinx documents.  It knows about standard ipython prompts, and
extracts the input and output lines.  These prompts will be renumbered
starting at ``1``.  The inputs will be fed to an embedded ipython
interpreter and the outputs from that interpreter will be inserted as
well.

.. ipython::

   In [136]: x = 2

   In [137]: x**3
   Out[137]: 8

The state from previous sessions is stored, and standard error is
trapped.  At doc build time, ipython's output and std err will be
inserted, and prompts will be renumbered.  So the prompt below should
be ``In [3]:`` in the rendered docs.

.. ipython::

  In [138]: z = x*3   # x is recalled from previous block

  In [139]: z
  Out[139]: 6

  In [140]: print z
  --------> print(z)
  6

  In [141]: q = z[)   # this is a syntax error -- we trap ipy exceptions
  ------------------------------------------------------------
     File "<ipython console>", line 1
       q = z[)   # this is a syntax error -- we trap ipy exceptions
	     ^
  SyntaxError: invalid syntax


The embedded interpeter supports some limited markup.  For example,
you can put comments in your ipython sessions, which are reported
verbatim.  There are some handy "pseudo-decorators" that let you
doctest the output.  The inputs are fed to an embbedded ipython
session and the outputs from the ipython session are inserted into
your doc.  If the output in your doc and in the ipython session don't
match on a doctest assertion, an error will be


.. ipython::

   In [1]: x = 'hello world'

   # this will raise an error if the ipython output is different
   @doctest
   In [2]: x.upper()
   Out[2]: 'HELLO WORLD'

   # some readline features cannot be supported, so we allow
   # "verbatim" blocks, which are dumped in verbatim except prompts
   # are continuously numbered
   @verbatim
   In [3]: x.st<TAB>
   x.startswith  x.strip


Multi-line input is supported.

.. ipython::

   In [130]: url = 'http://ichart.finance.yahoo.com/table.csv?s=CROX\
      .....: &d=9&e=22&f=2009&g=d&a=1&br=8&c=2006&ignore=.csv'

   In [131]: print url.split('&')
   --------> print(url.split('&'))
   ['http://ichart.finance.yahoo.com/table.csv?s=CROX', 'd=9', 'e=22',
'f=2009', 'g=d', 'a=1', 'b=8', 'c=2006', 'ignore=.csv']

   In [60]: import urllib


You can do doctesting on multi-line output as well.  Just be careful
when using non-deterministic inputs like random numbers in the ipython
directive, because your inputs are ruin through a live interpreter, so
if you are doctesting random output you will get an error.  Here we
"seed" the random number generator for deterministic output, and we
suppress the seed line so it doesn't show up in the rendered output

.. ipython::

   In [133]: import numpy.random

   @suppress
   In [134]: numpy.random.seed(2358)

   @doctest
   In [135]: np.random.rand(10,2)
   Out[135]:
   array([[ 0.64524308,  0.59943846],
	  [ 0.47102322,  0.8715456 ],
	  [ 0.29370834,  0.74776844],
	  [ 0.99539577,  0.1313423 ],
	  [ 0.16250302,  0.21103583],
	  [ 0.81626524,  0.1312433 ],
	  [ 0.67338089,  0.72302393],
	  [ 0.7566368 ,  0.07033696],
	  [ 0.22591016,  0.77731835],
	  [ 0.0072729 ,  0.34273127]])


Another demonstration of multi-line input and output

.. ipython::

   In [106]: print x
   --------> print(x)
   jdh

   In [109]: for i in range(10):
      .....:     print i
      .....:
      .....:
   0
   1
   2
   3
   4
   5
   6
   7
   8
   9


Most of the "pseudo-decorators" can be used an options to ipython
mode.  For example, to setup maptlotlib pylab but suppress the output,
you can do.  When using the matplotlib ``use`` directive, it should
occur before any import of pylab.  This will not show up in the
rendered docs, but the commands will be executed in the embedded
interpeter and subsequent line numbers will be incremented to reflect
the inputs::


  .. ipython::
     :suppress:

     In [144]: from pylab import *

     In [145]: ion()

.. ipython::
   :suppress:

   In [144]: from pylab import *

   In [145]: ion()

Likewise, you can set ``:doctest:`` or ``:verbatim:`` to apply these
settings to the entire block.


You can create one or more pyplot plots and insert them with the
``@savefig`` decorator.

.. ipython::

   @savefig plot_simple.png width=4in
   In [151]: plot([1,2,3]);

   # use a semicolon to suppress the output
   @savefig hist_simple.png width=4in
   In [151]: hist(np.random.randn(10000), 100);

In a subsequent session, we can update the current figure with some
text, and then resave

.. ipython::


   In [151]: ylabel('number')

   In [152]: title('normal distribution')

   @savefig hist_with_text.png
   In [153]: grid(True)




That's all folks!


From jdh2358 at gmail.com  Sun Nov  8 13:22:14 2009
From: jdh2358 at gmail.com (John Hunter)
Date: Sun, 8 Nov 2009 12:22:14 -0600
Subject: [IPython-dev] ipython sphinx directive
In-Reply-To: <88e473830911081018t312c61dbt1caac66eee6b5dcd@mail.gmail.com>
References: <88e473830911061424y35e0d87bxc84eaa0763cd6d8c@mail.gmail.com>
	<20091107095102.GA2068@phare.normalesup.org>
	<88e473830911070721i22622c93g62ad2bd9c671eefc@mail.gmail.com>
	<88e473830911081018t312c61dbt1caac66eee6b5dcd@mail.gmail.com>
Message-ID: <88e473830911081022q2e2af3a9i78df1a4213746dcc@mail.gmail.com>

On Sun, Nov 8, 2009 at 12:18 PM, John Hunter <jdh2358 at gmail.com> wrote:

> A demo document is included below, which is rendered at
> http://matplotlib.sourceforge.net/ipymode/_build/html/ipy_demo.html,
> and the ipython_directive is attached. ?Stuff that still needs work:

Forgot the attachment...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ipython_directive.py
Type: text/x-python
Size: 13798 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091108/c2cdad0f/attachment.py>

From ellisonbg.net at gmail.com  Sun Nov  8 16:26:02 2009
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Sun, 8 Nov 2009 13:26:02 -0800
Subject: [IPython-dev] "__builtins__.True = False" causes weird
	behaviours
In-Reply-To: <49d6b3500911081009l39836cc8q402a25b56e6ba1e9@mail.gmail.com>
References: <49d6b3500911072056u79462dc9h98d6d881eea5077a@mail.gmail.com>
	<6ce0ac130911072134rcfadda3ld750a3c0b7de7eb@mail.gmail.com>
	<49d6b3500911081009l39836cc8q402a25b56e6ba1e9@mail.gmail.com>
Message-ID: <6ce0ac130911081326xb8375ceq186c2fdcea63042d@mail.gmail.com>

> Good morning :)
>
> How do you fix these in the trunk? Raising an exception if a user enters
> any of the forbidden assignments ?
>
>
I didn't!  It was random chance that it got fixed.  I have been doing a lot
of work on the trunk this summer and one of the big things I did was
completely refactor the threaded shells (-pylab).   My guess is that that
code relied on True not being False and didn't handle the failure properly.
But, all that code is gone now...


> Fortunately not many out who has the obsession of defining True as False.
> Somewhat I connect this to Wittgenstein's belief that "There are no
> philosophical questions, but only language puzzles."
>
>

Yes, this is the type of thing that Java geeks would laugh at.

Cheers,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091108/2091af5e/attachment.html>

From gael.varoquaux at normalesup.org  Sun Nov  8 18:42:00 2009
From: gael.varoquaux at normalesup.org (Gael Varoquaux)
Date: Mon, 9 Nov 2009 00:42:00 +0100
Subject: [IPython-dev] Parallel computing syntactic sugar
Message-ID: <20091108234200.GO28471@phare.normalesup.org>

I have been wanting to discuss tricks I use to make my parallel-computing
life easier for a while, but always fell short of time. I managed to do a
blog post about it tonight:

http://gael-varoquaux.info/blog/?p=119

It might be of interest to people on this list;

Discussion welcomed.

Ga?l


From ellisonbg.net at gmail.com  Wed Nov 11 19:29:26 2009
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 11 Nov 2009 16:29:26 -0800
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
Message-ID: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>

Hi,

I am running into an issue with paths and unicode strings in IPython.
Currently, in 99% of IPython's code base
we use str for *everything*.  But, there are a few things that are unicode
(get_ipython_dir, get_home_dir, some others).
The inconsistency is giving me some trouble and I need to decide if I should
be using str or unicode for files, paths, dirs.

So, I would like us to come up with a more consistent plan for unicode/str.
This is especially relevant for the Python 3.0
transition, where the str type goes away (only unicode and bytes).

Here is what I am thinking:

* Sometimes soon, we begin to do the transition from str-> unicode.
Basically, 99% of strings in IPython should be unicode.  That is
everything that is not a path, file, directory, etc.

* Starting now, every path, filename, etc should be unicode?  I am not as
sure about this one...
The Python 3 docs here:

http://docs.python.org/3.1/library/os.path.html

say the most general thing is to use bytes on unix/linux/os x and unicode on
Windows for paths,
files, dirs.  That seems like a huge pain though and would mean we have to
provide some sort
of abstraction layer for these things.  It would be so nice to simply use
unicode everywhere.
But, that means there are some paths that we can't represent on unix.

Does anyone have experience with Python 3.0 in this regard yet?

Cheers,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091111/c679fd1c/attachment.html>

From ellisonbg.net at gmail.com  Wed Nov 11 19:39:00 2009
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 11 Nov 2009 16:39:00 -0800
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
In-Reply-To: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>
References: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>
Message-ID: <6ce0ac130911111639l4fd1bcai2df4733f0fe669d8@mail.gmail.com>

Here is a much more complete description of the unicode issues related to
the python 2->3 transition.

http://docs.python.org/dev/3.0/howto/unicode.html#unicode-howto

Cheers,

Brian

On Wed, Nov 11, 2009 at 4:29 PM, Brian Granger <ellisonbg.net at gmail.com>wrote:

> Hi,
>
> I am running into an issue with paths and unicode strings in IPython.
> Currently, in 99% of IPython's code base
> we use str for *everything*.  But, there are a few things that are unicode
> (get_ipython_dir, get_home_dir, some others).
> The inconsistency is giving me some trouble and I need to decide if I
> should be using str or unicode for files, paths, dirs.
>
> So, I would like us to come up with a more consistent plan for
> unicode/str.  This is especially relevant for the Python 3.0
> transition, where the str type goes away (only unicode and bytes).
>
> Here is what I am thinking:
>
> * Sometimes soon, we begin to do the transition from str-> unicode.
> Basically, 99% of strings in IPython should be unicode.  That is
> everything that is not a path, file, directory, etc.
>
> * Starting now, every path, filename, etc should be unicode?  I am not as
> sure about this one...
> The Python 3 docs here:
>
> http://docs.python.org/3.1/library/os.path.html
>
> say the most general thing is to use bytes on unix/linux/os x and unicode
> on Windows for paths,
> files, dirs.  That seems like a huge pain though and would mean we have to
> provide some sort
> of abstraction layer for these things.  It would be so nice to simply use
> unicode everywhere.
> But, that means there are some paths that we can't represent on unix.
>
> Does anyone have experience with Python 3.0 in this regard yet?
>
> Cheers,
>
> Brian
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091111/6708e6a9/attachment.html>

From robert.kern at gmail.com  Wed Nov 11 19:46:30 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 11 Nov 2009 18:46:30 -0600
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
In-Reply-To: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>
References: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>
Message-ID: <hdflt7$dh0$1@ger.gmane.org>

On 2009-11-11 18:29 PM, Brian Granger wrote:

> * Starting now, every path, filename, etc should be unicode?  I am not
> as sure about this one...
> The Python 3 docs here:
>
> http://docs.python.org/3.1/library/os.path.html
>
> say the most general thing is to use bytes on unix/linux/os x and
> unicode on Windows for paths,
> files, dirs.  That seems like a huge pain though and would mean we have
> to provide some sort
> of abstraction layer for these things.  It would be so nice to simply
> use unicode everywhere.
> But, that means there are some paths that we can't represent on unix.

These should be enormously rare, I think. By and large, we are mostly concerned 
with representing ~/, right? I think it is reasonable to only support (encoded) 
Unicode file paths and not support *completely* arbitrary file paths. I doubt we 
will get a single bug report.

Also, perhaps it's not worth noting, but OS X appears to require UTF-8 encoding 
of filenames. I.e., one should use unicode strings in Python to represent them.

-- 
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



From ellisonbg.net at gmail.com  Wed Nov 11 20:10:24 2009
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Wed, 11 Nov 2009 17:10:24 -0800
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
In-Reply-To: <hdflt7$dh0$1@ger.gmane.org>
References: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>
	<hdflt7$dh0$1@ger.gmane.org>
Message-ID: <6ce0ac130911111710x58771376o5413e243ad14ea9a@mail.gmail.com>

> These should be enormously rare, I think. By and large, we are mostly
> concerned
> with representing ~/, right? I think it is reasonable to only support
> (encoded)
> Unicode file paths and not support *completely* arbitrary file paths. I
> doubt we
> will get a single bug report.
>

Yes, I think they are rare.  I need to learn more about unicode.  When you
say we should
support encoded unicode paths,  does that mean the current get_home_dir
(which calls
decode) would have to change?

It does things like:

return homedir.decode(sys.getfilesystemencoding())

Should we just return unicode(homedir) instead?  I guess I can no longer
avoid learning
about unicode...


> Also, perhaps it's not worth noting, but OS X appears to require UTF-8
> encoding
> of filenames. I.e., one should use unicode strings in Python to represent
> them.
>
>
Seems like unicode is the way to go then.  Thanks for the info.

Cheers,

Brian


> --
> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091111/aac0e5b3/attachment.html>

From robert.kern at gmail.com  Wed Nov 11 22:06:39 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Wed, 11 Nov 2009 21:06:39 -0600
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
In-Reply-To: <6ce0ac130911111710x58771376o5413e243ad14ea9a@mail.gmail.com>
References: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>	<hdflt7$dh0$1@ger.gmane.org>
	<6ce0ac130911111710x58771376o5413e243ad14ea9a@mail.gmail.com>
Message-ID: <hdfu3v$un4$2@ger.gmane.org>

Brian Granger wrote:
> 
>     These should be enormously rare, I think. By and large, we are
>     mostly concerned
>     with representing ~/, right? I think it is reasonable to only
>     support (encoded)
>     Unicode file paths and not support *completely* arbitrary file
>     paths. I doubt we
>     will get a single bug report.
> 
> 
> Yes, I think they are rare.  I need to learn more about unicode.  When 
> you say we should
> support encoded unicode paths,  does that mean the current get_home_dir 
> (which calls
> decode) would have to change?

What I meant was that we should support the subset of UNIX paths (which are 
bytes on the file system) that are validly encoded forms of Unicode strings 
under some encoding and not just arbitrary bytes.

> It does things like:
> 
> return homedir.decode(sys.getfilesystemencoding())
> 
> Should we just return unicode(homedir) instead? 

unicode(some_bytes) will only work if some_bytes are pure ASCII. You need to 
explicitly .decode() in order to decode the correct encoding. I think that our 
functions should consume and return unicode strings. If they internally call 
APIs that only consume or return bytes, then we would encode/decode as above.

> I guess I can no longer 
> avoid learning
> about unicode...

Bad developer! :-)

-- 
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



From fperez.net at gmail.com  Thu Nov 12 03:55:21 2009
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 12 Nov 2009 00:55:21 -0800
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
In-Reply-To: <6ce0ac130911111710x58771376o5413e243ad14ea9a@mail.gmail.com>
References: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com> 
	<hdflt7$dh0$1@ger.gmane.org>
	<6ce0ac130911111710x58771376o5413e243ad14ea9a@mail.gmail.com>
Message-ID: <db6b5ecc0911120055i70b1e800l7d5bafcd44fafb6f@mail.gmail.com>

On Wed, Nov 11, 2009 at 5:10 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Should we just return unicode(homedir) instead?? I guess I can no longer
> avoid learning
> about unicode...

In solidarity I'm starting my education on this topic.  I suspect  we
won't make one iota of progress on eventual py3 port work if we don't
understand this better.  I found this tutorial online I'll try to read
tomorrow, feel free to suggest any others that you may like:

http://www.joelonsoftware.com/articles/Unicode.html

Cheers,

f


From scorpion032 at gmail.com  Thu Nov 12 04:01:39 2009
From: scorpion032 at gmail.com (Lakshman Prasad)
Date: Thu, 12 Nov 2009 14:31:39 +0530
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
In-Reply-To: <db6b5ecc0911120055i70b1e800l7d5bafcd44fafb6f@mail.gmail.com>
References: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>
	<hdflt7$dh0$1@ger.gmane.org>
	<6ce0ac130911111710x58771376o5413e243ad14ea9a@mail.gmail.com>
	<db6b5ecc0911120055i70b1e800l7d5bafcd44fafb6f@mail.gmail.com>
Message-ID: <d38edb550911120101k1fea107as5566951e62c4be2e@mail.gmail.com>

>
> feel free to suggest any others that you may like:


Mark pilgrim tells a good story on strings/unicode encoding et all.
http://diveintopython3.org/strings.html

On Thu, Nov 12, 2009 at 2:25 PM, Fernando Perez <fperez.net at gmail.com>wrote:

> On Wed, Nov 11, 2009 at 5:10 PM, Brian Granger <ellisonbg.net at gmail.com>
> wrote:
> > Should we just return unicode(homedir) instead?  I guess I can no longer
> > avoid learning
> > about unicode...
>
> In solidarity I'm starting my education on this topic.  I suspect  we
> won't make one iota of progress on eventual py3 port work if we don't
> understand this better.  I found this tutorial online I'll try to read
> tomorrow, feel free to suggest any others that you may like:
>
> http://www.joelonsoftware.com/articles/Unicode.html
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Regards,
Lakshman
becomingguru.com
lakshmanprasad.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091112/cff199fb/attachment.html>

From robert.kern at gmail.com  Thu Nov 12 11:41:49 2009
From: robert.kern at gmail.com (Robert Kern)
Date: Thu, 12 Nov 2009 10:41:49 -0600
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
In-Reply-To: <db6b5ecc0911120055i70b1e800l7d5bafcd44fafb6f@mail.gmail.com>
References: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>
	<hdflt7$dh0$1@ger.gmane.org>	<6ce0ac130911111710x58771376o5413e243ad14ea9a@mail.gmail.com>
	<db6b5ecc0911120055i70b1e800l7d5bafcd44fafb6f@mail.gmail.com>
Message-ID: <hdhdsf$86k$1@ger.gmane.org>

On 2009-11-12 02:55 AM, Fernando Perez wrote:
> On Wed, Nov 11, 2009 at 5:10 PM, Brian Granger<ellisonbg.net at gmail.com>  wrote:
>> Should we just return unicode(homedir) instead?  I guess I can no longer
>> avoid learning
>> about unicode...
>
> In solidarity I'm starting my education on this topic.  I suspect  we
> won't make one iota of progress on eventual py3 port work if we don't
> understand this better.  I found this tutorial online I'll try to read
> tomorrow, feel free to suggest any others that you may like:
>
> http://www.joelonsoftware.com/articles/Unicode.html

Some Python-specific tutorials:

   http://farmdev.com/talks/unicode/
   http://www.youtube.com/watch?v=cecJ9o5GGmw

   http://effbot.org/zone/unicode-objects.htm

   http://effbot.org/zone/unicode-objects.htm

-- 
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



From ellisonbg.net at gmail.com  Thu Nov 12 13:33:10 2009
From: ellisonbg.net at gmail.com (Brian Granger)
Date: Thu, 12 Nov 2009 10:33:10 -0800
Subject: [IPython-dev] IPython and unicode (planning ahead for Py3k)
In-Reply-To: <hdhdsf$86k$1@ger.gmane.org>
References: <6ce0ac130911111629v7769b791g1d10329867528b73@mail.gmail.com>
	<hdflt7$dh0$1@ger.gmane.org>
	<6ce0ac130911111710x58771376o5413e243ad14ea9a@mail.gmail.com>
	<db6b5ecc0911120055i70b1e800l7d5bafcd44fafb6f@mail.gmail.com>
	<hdhdsf$86k$1@ger.gmane.org>
Message-ID: <6ce0ac130911121033s65794bf2l467ca4295d679f0c@mail.gmail.com>

Fernando and Robert,

Thanks for the refs, I will start the read up.  The good news is that I have
started to
move all our paths, files, dirs over the unicode and nothing has exploded
yet.

Cheers,

Brian

On Thu, Nov 12, 2009 at 8:41 AM, Robert Kern <robert.kern at gmail.com> wrote:

> On 2009-11-12 02:55 AM, Fernando Perez wrote:
> > On Wed, Nov 11, 2009 at 5:10 PM, Brian Granger<ellisonbg.net at gmail.com>
>  wrote:
> >> Should we just return unicode(homedir) instead?  I guess I can no longer
> >> avoid learning
> >> about unicode...
> >
> > In solidarity I'm starting my education on this topic.  I suspect  we
> > won't make one iota of progress on eventual py3 port work if we don't
> > understand this better.  I found this tutorial online I'll try to read
> > tomorrow, feel free to suggest any others that you may like:
> >
> > http://www.joelonsoftware.com/articles/Unicode.html
>
> Some Python-specific tutorials:
>
>   http://farmdev.com/talks/unicode/
>   http://www.youtube.com/watch?v=cecJ9o5GGmw
>
>   http://effbot.org/zone/unicode-objects.htm
>
>   http://effbot.org/zone/unicode-objects.htm
>
> --
> 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
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20091112/e64a68de/attachment.html>

From Fernando.Perez at berkeley.edu  Mon Nov 16 05:31:23 2009
From: Fernando.Perez at berkeley.edu (Fernando Perez)
Date: Mon, 16 Nov 2009 02:31:23 -0800
Subject: [IPython-dev] weird bug -- any ideas
In-Reply-To: <85e81ba30911131436j23210c40j9fe899614eb58baf@mail.gmail.com>
References: <85e81ba30911131436j23210c40j9fe899614eb58baf@mail.gmail.com>
Message-ID: <96de71860911160231j3b6fa2cevef8c3ca565efbe6a@mail.gmail.com>

On Fri, Nov 13, 2009 at 2:36 PM, William Stein <wstein at gmail.com> wrote:
> If any Ipython devs have Sage installed perhaps you could try looking at
>
> ? http://trac.sagemath.org/sage_trac/ticket/7449
>
> and see if anything pops into your head. ?It's a weird bug in
> introspection where it uses *all* RAM on whatever computer it's run
> on. ?The strange thing is that exactly the same thing in the Sage
> notebook works fine (which doesn't use Ipython, but uses similar code
> to implement something similar).
>
> Anyway, any hints are appreciated. ? I don't read ipython-dev, so
> maybe this message will bounce -- anyway, respond to me directly if
> you have any thoughts.

Very weird... The funny thing is, the introspection actually finished
very fast: if you do

Ctrl-C

you get the information fine (I just tried).  So something *at the
end* of the introspection is hanging, and it slowly but surely uses up
all RAM.

One thing I can tell you is that upgrading to 0.10 won't help, I just
tried updating the sage ipython to 0.10 and the problem is still
there.

I'll try to have a look and see if I can understand where this is coming from.

The fact that Ctrl-C cleanly stops the crazy loop *without* a
KeyboardInterrupt makes me think that ipython is trying to introspect
the MS object and some C code is going into a mad loop (otherwise we'd
see the Python signal handler showing a traceback).  Do you have any
other bugs related to this type of object that sound along those
lines?

We'll keep looking...

f


From Fernando.Perez at berkeley.edu  Mon Nov 16 06:28:54 2009
From: Fernando.Perez at berkeley.edu (Fernando Perez)
Date: Mon, 16 Nov 2009 03:28:54 -0800
Subject: [IPython-dev] weird bug -- any ideas
In-Reply-To: <96de71860911160231j3b6fa2cevef8c3ca565efbe6a@mail.gmail.com>
References: <85e81ba30911131436j23210c40j9fe899614eb58baf@mail.gmail.com> 
	<96de71860911160231j3b6fa2cevef8c3ca565efbe6a@mail.gmail.com>
Message-ID: <96de71860911160328h30dfdc76kafbd3f43357ca53a@mail.gmail.com>

On Mon, Nov 16, 2009 at 2:31 AM, Fernando Perez
<Fernando.Perez at berkeley.edu> wrote:
> The fact that Ctrl-C cleanly stops the crazy loop *without* a
> KeyboardInterrupt makes me think that ipython is trying to introspect
> the MS object and some C code is going into a mad loop (otherwise we'd
> see the Python signal handler showing a traceback). ?Do you have any
> other bugs related to this type of object that sound along those
> lines?

Half-right. IPython is swallowing the kbd interrupt, but the bug is in
sage, it's the fact that len(MS) never returns:

sage: MS = MatrixSpace(QQ,6,6,sparse=True); MS
Full MatrixSpace of 6 by 6 sparse matrices over Rational Field
sage: len(MS)
^C---------------------------------------------------------------------------
KeyboardInterrupt                         Traceback (most recent call last)

/home/fperez/ipython/repo/kernel-config-lp/docs/<ipython console> in <module>()

/opt/sage/local/lib/python2.6/site-packages/sage/structure/parent.so
in sage.structure.parent.Parent.__len__
(sage/structure/parent.c:5533)()

/opt/sage/local/lib/python2.6/site-packages/sage/structure/parent.so
in sage.structure.parent.Parent.list (sage/structure/parent.c:4995)()

/opt/sage/local/lib/python2.6/site-packages/sage/matrix/matrix_space.pyc
in __iter__(self)
    751             while True:
    752                 for iv in
sage.combinat.integer_vector.IntegerVectors(weight,
number_of_entries):
--> 753                     yield self(entries=[base_elements[i] for i
in iv], rows=True)
    754
    755                 weight += 1

/opt/sage/local/lib/python2.6/site-packages/sage/matrix/matrix_space.pyc
in __call__(self, entries, coerce, copy, rows)
    371             copy = False
    372         elif self.__is_sparse and isinstance(entries, (list, tuple)):
--> 373             entries = list_to_dict(entries, self.__nrows,
self.__ncols, rows=rows)
    374             coerce = True
    375             copy = False

/opt/sage/local/lib/python2.6/site-packages/sage/matrix/matrix_space.pyc
in list_to_dict(entries, nrows, ncols, rows)
   1240                 d[(row,col)] = x
   1241             else:
-> 1242                 d[(col,row)] = x
   1243     return d
   1244

/opt/sage/local/lib/python2.6/site-packages/sage/interfaces/get_sigs.pyc
in my_sigint(x, n)
      7
      8 def my_sigint(x, n):
----> 9     raise KeyboardInterrupt
     10
     11 def my_sigfpe(x, n):

KeyboardInterrupt:


It seems that the ms object implements __len__, but this function
never returns.  It's just that ipython was calling len() on it.

Cheers,

f


From hans_meine at gmx.net  Wed Nov 18 08:01:17 2009
From: hans_meine at gmx.net (Hans Meine)
Date: Wed, 18 Nov 2009 14:01:17 +0100
Subject: [IPython-dev] ipython sphinx directive
In-Reply-To: <88e473830911070721i22622c93g62ad2bd9c671eefc@mail.gmail.com>
References: <88e473830911061424y35e0d87bxc84eaa0763cd6d8c@mail.gmail.com>
	<20091107095102.GA2068@phare.normalesup.org>
	<88e473830911070721i22622c93g62ad2bd9c671eefc@mail.gmail.com>
Message-ID: <200911181401.19956.hans_meine@gmx.net>

Hi John,

nice plan that you're following, I am looking forward to the result of this.

On Saturday 07 November 2009 16:21:27 John Hunter wrote:
> In the alternative syntax, call it "ipython prompt", The rst document
> includes input and output prompts, but the embedded ipython
> interpreter detects the input prompt string 'In [\\d]:' and executes
> the code.  I'm leaning towards this syntax, [...]

+1

> * one of the strengths of rest is that is is human readable in the
>   plain text form. [...]

Exactly.

> * how do we handle numbering?  I'm pretty sure we want auto-numbering.

+1

>   With real-world experience writing a chapter using ipython session
>   dumps heavily, I find that you frequently want to change a thing or
>   two, and the prompt numbering gets out of whack.

Exactly.

>   Or you come back
>   later with a fresh ipython session and insert something into the
>   middle of the chapter and your ipython prompt numbers are
>   non-monotonic.  So I propose auto-numbering, even for ``@verbatim``
>   inputs, where the embedded interpreter will use your input and
>   output, but will use its internal prompt counter.

Yes, please.

>   I am punting on
>   use of things like ``_10`` to refer to the 10th output -- too hard.
>   However, we often want to refer to the input and output line number
>   in our narrative text, like "the ``std`` on input line ``In [8]``
>   does such-and-such" which we cannot easily do with auto-numbering.
>   One solution is to support a new role, something like::
>
>
>     .. ipython::
>
>        In [7]: x.mean()
>        Out[7]: 4.5
>
>        .. _std_x:
>        In [8]: x.std()
>        Out[8]: 2.8722813232690143
>
>
>   which we can refer to in our text like::
>
>      the ``std`` call on input line ``In [:iref:`std_x`]`` does such and
> such.
>
>   a little perl-esque and ugly, but may get the job done.

+1

BTW: I recently found this nice HTML/CSS/JS trick:
  http://diveintopython3.org/packaging.html
Look at the examples, e.g. under 16.2, where there are circled numbers 
referenced below.  When you move the mouse over them, they get highlighted 
together.

> * What should be rendered for output: the session output or the
>   ipython interpreter output.  [...]
>   I think the only workable solution is to use *ipython's* output and
>   not the user output.

Sounds reasonable to me, as do the proposed pseudo-decorators.

Have a nice day,
  Hans



From fperez.net at gmail.com  Thu Nov 19 04:50:18 2009
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 19 Nov 2009 01:50:18 -0800
Subject: [IPython-dev] ipython sphinx directive
In-Reply-To: <200911181401.19956.hans_meine@gmx.net>
References: <88e473830911061424y35e0d87bxc84eaa0763cd6d8c@mail.gmail.com> 
	<20091107095102.GA2068@phare.normalesup.org>
	<88e473830911070721i22622c93g62ad2bd9c671eefc@mail.gmail.com> 
	<200911181401.19956.hans_meine@gmx.net>
Message-ID: <db6b5ecc0911190150o5c1f3943ud3a2f76aa3b7980@mail.gmail.com>

Hans Meine wrote:
> Hi John,
>
> nice plan that you're following, I am looking forward to the result of this.

We'll definitely be including this, hopefully in a bugfix 0.10.1
release, and definitely (once updated to the new apis) in 0.11.

> BTW: I recently found this nice HTML/CSS/JS trick:
>   http://diveintopython3.org/packaging.html
> Look at the examples, e.g. under 16.2, where there are circled numbers
> referenced below.  When you move the mouse over them, they get highlighted
> together.

Very nice, thanks for the pointer!

Cheers,

f