From fperez.net at gmail.com Wed Oct 5 21:22:55 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 5 Oct 2011 18:22:55 -0700 Subject: [IPython-dev] IPython notebooks: the next frontier in long-distance parenting Message-ID: A few days ago I taught a workshop at Berkeley for some folks where I showed the notebook, and one of the attendees was here visiting away from his home. This morning I received this cool note: I also wanted to share with you an ipython anecdote, that shows the multiple uses of your python efforts. Last Sunday morning, while still in Berkeley, my daughter texted me for some urgent help with her math homework. They're doing some simple functions, tables and graphs, but pretty hard stuff to explain and show over the phone. Ipython notebook to the rescue! I did the examples she needed help with in the notebook, including some tables, graphs, printed results and comments. Saved it and sent her by email. Daughter was happy, and daddy felt less bad about traveling the globe instead of helping the kids with their homework. Happy days. All thanks to the ipython notebook, and a certain Dr. Perez! Next time I?ll have her log on to the notebook remotely :-) #### I really got a kick out of that, but wanted to share it because the real credit is certainly not mine. Best, f From pivanov314 at gmail.com Thu Oct 6 16:48:38 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Thu, 6 Oct 2011 13:48:38 -0700 Subject: [IPython-dev] IPython notebooks: the next frontier in long-distance parenting In-Reply-To: References: Message-ID: > I really got a kick out of that, but wanted to share it because the > real credit is certainly not mine. It certainly isn't! The daughter's father is the one that did the actual work! :) cool anecdote, -- Paul Ivanov 314 address only used for lists, off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From ipython-dev at mlists.thewrittenword.com Fri Oct 7 01:17:51 2011 From: ipython-dev at mlists.thewrittenword.com (Albert Chin) Date: Fri, 7 Oct 2011 00:17:51 -0500 Subject: [IPython-dev] 0.11 on RHEL5/x86 Message-ID: <20111007051750.GA5882@china> I built ipython-0.11 on RHEL5/x86. Executing "ipython" works. Executing "ipython qtconsole" exhibits the following failure. Any idea on how to resolve it? I'm using nose-1.0.0, pygments-1.4, sphinx-1.0.8, zeromq-2.1.9, pyzmq-2.1.9, qt-4.4.3, sip-4.9.3, and PyQt-4.6.2. $ ipython qtconsole [IPKernelApp] To connect another client to this kernel, use: [IPKernelApp] --existing --shell=51973 --iopub=51966 --stdin=56682 --hb=36345 --------------------------------------------------------------------------- AttributeError Python 2.6.6: /usr/packages/python26/bin/python Fri Oct 7 05:06:53 2011 A problem occured executing Python code. Here is the sequence of function calls leading up to the error, with the most recent (innermost) call last. /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc in _document_contents_change(self=, position=0, removed=1, added=0) 602 """ Shows a prompt for the interpreter given an 'execute_reply' message. 603 """ 604 self._show_interpreter_prompt() 605 606 #------ Signal handlers ---------------------------------------------------- 607 608 def _document_contents_change(self, position, removed, added): 609 """ Called whenever the document's content changes. Display a call tip 610 if appropriate. 611 """ 612 # Calculate where the cursor should be *after* the change: 613 position += added 614 615 document = self._control.document() 616 if position == self._get_cursor().position(): --> 617 self._call_tip() /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc in _call_tip(self=) 498 499 else: 500 self._append_plain_text('Kernel process is either remote or ' 501 'unspecified. Cannot restart.\n') 502 503 #--------------------------------------------------------------------------- 504 # 'FrontendWidget' protected interface 505 #--------------------------------------------------------------------------- 506 507 def _call_tip(self): 508 """ Shows a call tip, if appropriate, at the current cursor location. 509 """ 510 # Decide if it makes sense to show a call tip 511 cursor = self._get_cursor() 512 cursor.movePosition(QtGui.QTextCursor.Left) --> 513 if cursor.document().characterAt(cursor.position()) != '(': 514 return False 515 context = self._get_context(cursor) 516 if not context: 517 return False 518 519 # Send the metadata request to the kernel 520 name = '.'.join(context) 521 msg_id = self.kernel_manager.shell_channel.object_info(name) 522 pos = self._get_cursor().position() 523 self._request_info['call_tip'] = self._CallTipRequest(msg_id, pos) 524 return True 525 526 def _complete(self): 527 """ Performs completion at the current cursor location. 528 """ AttributeError: 'QTextCursor' object has no attribute 'document' -- albert chin (china at thewrittenword.com) From benjaminrk at gmail.com Fri Oct 7 01:30:33 2011 From: benjaminrk at gmail.com (MinRK) Date: Thu, 6 Oct 2011 22:30:33 -0700 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: <20111007051750.GA5882@china> References: <20111007051750.GA5882@china> Message-ID: On Thu, Oct 6, 2011 at 22:17, Albert Chin < ipython-dev at mlists.thewrittenword.com> wrote: > I built ipython-0.11 on RHEL5/x86. Executing "ipython" works. > Executing "ipython qtconsole" exhibits the following failure. Any idea > on how to resolve it? I'm using nose-1.0.0, pygments-1.4, > sphinx-1.0.8, zeromq-2.1.9, pyzmq-2.1.9, qt-4.4.3, sip-4.9.3, and > PyQt-4.6.2. > I believe the qtconsole requires PyQt-4.7 (released 01/2010). This is enforced in trunk, but not 0.11, resulting in opaque errors like this on old PyQt or PySide. -MinRK > > $ ipython qtconsole > [IPKernelApp] To connect another client to this kernel, use: > [IPKernelApp] --existing --shell=51973 --iopub=51966 --stdin=56682 > --hb=36345 > --------------------------------------------------------------------------- > AttributeError Python 2.6.6: /usr/packages/python26/bin/python > Fri Oct 7 05:06:53 2011 > A problem occured executing Python code. Here is the sequence of function > calls leading up to the error, with the most recent (innermost) call last. > /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc > in > _document_contents_change(self= object>, position=0, removed=1, added=0) > 602 """ Shows a prompt for the interpreter given an > 'execute_reply' message. > 603 """ > 604 self._show_interpreter_prompt() > 605 > 606 #------ Signal handlers > ---------------------------------------------------- > 607 > 608 def _document_contents_change(self, position, removed, added): > 609 """ Called whenever the document's content changes. Display > a call tip > 610 if appropriate. > 611 """ > 612 # Calculate where the cursor should be *after* the change: > 613 position += added > 614 > 615 document = self._control.document() > 616 if position == self._get_cursor().position(): > --> 617 self._call_tip() > > /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc > in > _call_tip(self= object>) > 498 > 499 else: > 500 self._append_plain_text('Kernel process is either remote > or ' > 501 'unspecified. Cannot > restart.\n') > 502 > 503 > #--------------------------------------------------------------------------- > 504 # 'FrontendWidget' protected interface > 505 > #--------------------------------------------------------------------------- > 506 > 507 def _call_tip(self): > 508 """ Shows a call tip, if appropriate, at the current cursor > location. > 509 """ > 510 # Decide if it makes sense to show a call tip > 511 cursor = self._get_cursor() > 512 cursor.movePosition(QtGui.QTextCursor.Left) > --> 513 if cursor.document().characterAt(cursor.position()) != '(': > 514 return False > 515 context = self._get_context(cursor) > 516 if not context: > 517 return False > 518 > 519 # Send the metadata request to the kernel > 520 name = '.'.join(context) > 521 msg_id = self.kernel_manager.shell_channel.object_info(name) > 522 pos = self._get_cursor().position() > 523 self._request_info['call_tip'] = > self._CallTipRequest(msg_id, pos) > 524 return True > 525 > 526 def _complete(self): > 527 """ Performs completion at the current cursor location. > 528 """ > > AttributeError: 'QTextCursor' object has no attribute 'document' > > -- > albert chin (china at thewrittenword.com) > _______________________________________________ > 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: From ipython-dev at mlists.thewrittenword.com Fri Oct 7 02:09:42 2011 From: ipython-dev at mlists.thewrittenword.com (Albert Chin) Date: Fri, 7 Oct 2011 01:09:42 -0500 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: References: <20111007051750.GA5882@china> Message-ID: <20111007060942.GC14523@thewrittenword.com> On Thu, Oct 06, 2011 at 10:30:33PM -0700, MinRK wrote: > On Thu, Oct 6, 2011 at 22:17, Albert Chin > wrote: > > I built ipython-0.11 on RHEL5/x86. Executing "ipython" works. > Executing "ipython qtconsole" exhibits the following failure. Any idea > on how to resolve it? I'm using nose-1.0.0, pygments-1.4, > sphinx-1.0.8, zeromq-2.1.9, pyzmq-2.1.9, qt-4.4.3, sip-4.9.3, and > PyQt-4.6.2. > > I believe the qtconsole requires PyQt-4.7 (released 01/2010). This is > enforced in trunk, but not 0.11, resulting in opaque errors like this on > old PyQt or PySide. I just upgraded from sip-4.9.3 to sip-4.12.4 and from PyQt-4.6.2 to PyQt-4.8.5 and get the same error. > -MinRK > A > > $ ipython qtconsole > [IPKernelApp] To connect another client to this kernel, use: > [IPKernelApp] --existing --shell=51973 --iopub=51966 --stdin=56682 > --hb=36345 > --------------------------------------------------------------------------- > AttributeError A A A A Python 2.6.6: > /usr/packages/python26/bin/python > A A A A A A A A A A A A A A A A A A A A A A A A > A Fri Oct A 7 05:06:53 2011 > A problem occured executing Python code. A Here is the sequence of > function > calls leading up to the error, with the most recent (innermost) call > last. > /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc > in > _document_contents_change(self= object>, position=0, removed=1, added=0) > A A 602 A A A A """ Shows a prompt for the interpreter given an > 'execute_reply' message. > A A 603 A A A A """ > A A 604 A A A A self._show_interpreter_prompt() > A A 605 > A A 606 A A #------ Signal handlers > ---------------------------------------------------- > A A 607 > A A 608 A A def _document_contents_change(self, position, removed, > added): > A A 609 A A A A """ Called whenever the document's content changes. > Display a call tip > A A 610 A A A A A A if appropriate. > A A 611 A A A A """ > A A 612 A A A A # Calculate where the cursor should be *after* the > change: > A A 613 A A A A position += added > A A 614 > A A 615 A A A A document = self._control.document() > A A 616 A A A A if position == self._get_cursor().position(): > --> 617 A A A A A A self._call_tip() > > /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc > in > _call_tip(self= object>) > A A 498 > A A 499 A A A A else: > A A 500 A A A A A A self._append_plain_text('Kernel process is > either remote or ' > A A 501 A A A A A A A A A A A A A A A A A A > 'unspecified. Cannot restart.\n') > A A 502 > A A 503 A A > #--------------------------------------------------------------------------- > A A 504 A A # 'FrontendWidget' protected interface > A A 505 A A > #--------------------------------------------------------------------------- > A A 506 > A A 507 A A def _call_tip(self): > A A 508 A A A A """ Shows a call tip, if appropriate, at the > current cursor location. > A A 509 A A A A """ > A A 510 A A A A # Decide if it makes sense to show a call tip > A A 511 A A A A cursor = self._get_cursor() > A A 512 A A A A cursor.movePosition(QtGui.QTextCursor.Left) > --> 513 A A A A if cursor.document().characterAt(cursor.position()) > != '(': > A A 514 A A A A A A return False > A A 515 A A A A context = self._get_context(cursor) > A A 516 A A A A if not context: > A A 517 A A A A A A return False > A A 518 > A A 519 A A A A # Send the metadata request to the kernel > A A 520 A A A A name = '.'.join(context) > A A 521 A A A A msg_id = > self.kernel_manager.shell_channel.object_info(name) > A A 522 A A A A pos = self._get_cursor().position() > A A 523 A A A A self._request_info['call_tip'] = > self._CallTipRequest(msg_id, pos) > A A 524 A A A A return True > A A 525 > A A 526 A A def _complete(self): > A A 527 A A A A """ Performs completion at the current cursor > location. > A A 528 A A A A """ > > AttributeError: 'QTextCursor' object has no attribute 'document' > -- > albert chin (china at thewrittenword.com) > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- albert chin (china at thewrittenword.com) From benjaminrk at gmail.com Fri Oct 7 02:21:40 2011 From: benjaminrk at gmail.com (MinRK) Date: Thu, 6 Oct 2011 23:21:40 -0700 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: <20111007060942.GC14523@thewrittenword.com> References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> Message-ID: On Thu, Oct 6, 2011 at 23:09, Albert Chin < ipython-dev at mlists.thewrittenword.com> wrote: > On Thu, Oct 06, 2011 at 10:30:33PM -0700, MinRK wrote: > > On Thu, Oct 6, 2011 at 22:17, Albert Chin > > wrote: > > > > I built ipython-0.11 on RHEL5/x86. Executing "ipython" works. > > Executing "ipython qtconsole" exhibits the following failure. Any > idea > > on how to resolve it? I'm using nose-1.0.0, pygments-1.4, > > sphinx-1.0.8, zeromq-2.1.9, pyzmq-2.1.9, qt-4.4.3, sip-4.9.3, and > > PyQt-4.6.2. > > > > I believe the qtconsole requires PyQt-4.7 (released 01/2010). This is > > enforced in trunk, but not 0.11, resulting in opaque errors like this > on > > old PyQt or PySide. > > I just upgraded from sip-4.9.3 to sip-4.12.4 and from PyQt-4.6.2 to > PyQt-4.8.5 and get the same error. > Did you upgrade Qt itself? Maybe we depend on a relatively recent Qt as well. -MinRK > > > -MinRK > > A > > > > $ ipython qtconsole > > [IPKernelApp] To connect another client to this kernel, use: > > [IPKernelApp] --existing --shell=51973 --iopub=51966 --stdin=56682 > > --hb=36345 > > > --------------------------------------------------------------------------- > > AttributeError A A A A Python 2.6.6: > > /usr/packages/python26/bin/python > > A A A A A A A A A A A A A A A A A A A A A A A > A > > A Fri Oct A 7 05:06:53 2011 > > A problem occured executing Python code. A Here is the sequence of > > function > > calls leading up to the error, with the most recent (innermost) call > > last. > > > /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc > > in > > > _document_contents_change(self= > object>, position=0, removed=1, added=0) > > A A 602 A A A A """ Shows a prompt for the interpreter given an > > 'execute_reply' message. > > A A 603 A A A A """ > > A A 604 A A A A self._show_interpreter_prompt() > > A A 605 > > A A 606 A A #------ Signal handlers > > ---------------------------------------------------- > > A A 607 > > A A 608 A A def _document_contents_change(self, position, > removed, > > added): > > A A 609 A A A A """ Called whenever the document's content > changes. > > Display a call tip > > A A 610 A A A A A A if appropriate. > > A A 611 A A A A """ > > A A 612 A A A A # Calculate where the cursor should be *after* > the > > change: > > A A 613 A A A A position += added > > A A 614 > > A A 615 A A A A document = self._control.document() > > A A 616 A A A A if position == self._get_cursor().position(): > > --> 617 A A A A A A self._call_tip() > > > > > /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc > > in > > > _call_tip(self= > object>) > > A A 498 > > A A 499 A A A A else: > > A A 500 A A A A A A self._append_plain_text('Kernel process > is > > either remote or ' > > A A 501 A A A A A A A A A A A A A A A A A A > > 'unspecified. Cannot restart.\n') > > A A 502 > > A A 503 A A > > > #--------------------------------------------------------------------------- > > A A 504 A A # 'FrontendWidget' protected interface > > A A 505 A A > > > #--------------------------------------------------------------------------- > > A A 506 > > A A 507 A A def _call_tip(self): > > A A 508 A A A A """ Shows a call tip, if appropriate, at the > > current cursor location. > > A A 509 A A A A """ > > A A 510 A A A A # Decide if it makes sense to show a call tip > > A A 511 A A A A cursor = self._get_cursor() > > A A 512 A A A A cursor.movePosition(QtGui.QTextCursor.Left) > > --> 513 A A A A if > cursor.document().characterAt(cursor.position()) > > != '(': > > A A 514 A A A A A A return False > > A A 515 A A A A context = self._get_context(cursor) > > A A 516 A A A A if not context: > > A A 517 A A A A A A return False > > A A 518 > > A A 519 A A A A # Send the metadata request to the kernel > > A A 520 A A A A name = '.'.join(context) > > A A 521 A A A A msg_id = > > self.kernel_manager.shell_channel.object_info(name) > > A A 522 A A A A pos = self._get_cursor().position() > > A A 523 A A A A self._request_info['call_tip'] = > > self._CallTipRequest(msg_id, pos) > > A A 524 A A A A return True > > A A 525 > > A A 526 A A def _complete(self): > > A A 527 A A A A """ Performs completion at the current cursor > > location. > > A A 528 A A A A """ > > > > AttributeError: 'QTextCursor' object has no attribute 'document' > > -- > > albert chin (china at thewrittenword.com) > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- > albert chin (china at thewrittenword.com) > _______________________________________________ > 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: From ipython-dev at mlists.thewrittenword.com Fri Oct 7 03:22:51 2011 From: ipython-dev at mlists.thewrittenword.com (Albert Chin) Date: Fri, 7 Oct 2011 02:22:51 -0500 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> Message-ID: <20111007072251.GD14523@thewrittenword.com> On Thu, Oct 06, 2011 at 11:21:40PM -0700, MinRK wrote: > On Thu, Oct 6, 2011 at 23:09, Albert Chin > wrote: > > On Thu, Oct 06, 2011 at 10:30:33PM -0700, MinRK wrote: > > A A On Thu, Oct 6, 2011 at 22:17, Albert Chin > > A A wrote: > > > > A A A I built ipython-0.11 on RHEL5/x86. Executing "ipython" works. > > A A A Executing "ipython qtconsole" exhibits the following failure. > Any idea > > A A A on how to resolve it? I'm using nose-1.0.0, pygments-1.4, > > A A A sphinx-1.0.8, zeromq-2.1.9, pyzmq-2.1.9, qt-4.4.3, sip-4.9.3, > and > > A A A PyQt-4.6.2. > > > > A A I believe the qtconsole requires PyQt-4.7 (released 01/2010). > This is > > A A enforced in trunk, but not 0.11, resulting in opaque errors like > this on > > A A old PyQt or PySide. > > I just upgraded from sip-4.9.3 to sip-4.12.4 and from PyQt-4.6.2 to > PyQt-4.8.5 and get the same error. > > Did you upgrade Qt itself? A Maybe we depend on a relatively recent Qt as > well. No. We just upgraded PyQt and sip. We're still running against qt-4.4.3. Upgrading Qt is a bit more work. Do we need qt-4.7.x for qtconsole? > A > > > A A -MinRK > > A A A > > > > A A A $ ipython qtconsole > > A A A [IPKernelApp] To connect another client to this kernel, use: > > A A A [IPKernelApp] --existing --shell=51973 --iopub=51966 > --stdin=56682 > > A A A --hb=36345 > > A A > A --------------------------------------------------------------------------- > > A A A AttributeError A A A A A A A A Python 2.6.6: > > A A A /usr/packages/python26/bin/python > > A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A A > A A A A A A A A A A A A A A A A > > A A A A A Fri Oct A 7 05:06:53 2011 > > A A A A problem occured executing Python code. A Here is the > sequence of > > A A A function > > A A A calls leading up to the error, with the most recent > (innermost) call > > A A A last. > > A A > A /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc > > A A A in > > A A > A _document_contents_change(self= > A A A object>, position=0, removed=1, added=0) > > A A A A A A 602 A A A A A A A A """ Shows a prompt for the > interpreter given an > > A A A 'execute_reply' message. > > A A A A A A 603 A A A A A A A A """ > > A A A A A A 604 A A A A A A A A self._show_interpreter_prompt() > > A A A A A A 605 > > A A A A A A 606 A A A A #------ Signal handlers > > A A A ---------------------------------------------------- > > A A A A A A 607 > > A A A A A A 608 A A A A def _document_contents_change(self, > position, removed, > > A A A added): > > A A A A A A 609 A A A A A A A A """ Called whenever the document's > content changes. > > A A A Display a call tip > > A A A A A A 610 A A A A A A A A A A A A if appropriate. > > A A A A A A 611 A A A A A A A A """ > > A A A A A A 612 A A A A A A A A # Calculate where the cursor should > be *after* the > > A A A change: > > A A A A A A 613 A A A A A A A A position += added > > A A A A A A 614 > > A A A A A A 615 A A A A A A A A document = self._control.document() > > A A A A A A 616 A A A A A A A A if position == > self._get_cursor().position(): > > A A A --> 617 A A A A A A A A A A A A self._call_tip() > > > > A A > A /usr/packages/ipython011/lib/IPython/frontend/qt/console/frontend_widget.pyc > > A A A in > > A A > A _call_tip(self= > A A A object>) > > A A A A A A 498 > > A A A A A A 499 A A A A A A A A else: > > A A A A A A 500 A A A A A A A A A A A > A self._append_plain_text('Kernel process is > > A A A either remote or ' > > A A A A A A 501 A A A A A A A A A A A A A A A A A A A A A A A A A > A A A A A A A A A A > > A A A 'unspecified. Cannot restart.\n') > > A A A A A A 502 > > A A A A A A 503 A A A > > A A > A #--------------------------------------------------------------------------- > > A A A A A A 504 A A A A # 'FrontendWidget' protected interface > > A A A A A A 505 A A A > > A A > A #--------------------------------------------------------------------------- > > A A A A A A 506 > > A A A A A A 507 A A A A def _call_tip(self): > > A A A A A A 508 A A A A A A A A """ Shows a call tip, if > appropriate, at the > > A A A current cursor location. > > A A A A A A 509 A A A A A A A A """ > > A A A A A A 510 A A A A A A A A # Decide if it makes sense to show a > call tip > > A A A A A A 511 A A A A A A A A cursor = self._get_cursor() > > A A A A A A 512 A A A A A A A > A cursor.movePosition(QtGui.QTextCursor.Left) > > A A A --> 513 A A A A A A A A if > cursor.document().characterAt(cursor.position()) > > A A A != '(': > > A A A A A A 514 A A A A A A A A A A A A return False > > A A A A A A 515 A A A A A A A A context = self._get_context(cursor) > > A A A A A A 516 A A A A A A A A if not context: > > A A A A A A 517 A A A A A A A A A A A A return False > > A A A A A A 518 > > A A A A A A 519 A A A A A A A A # Send the metadata request to the > kernel > > A A A A A A 520 A A A A A A A A name = '.'.join(context) > > A A A A A A 521 A A A A A A A A msg_id = > > A A A self.kernel_manager.shell_channel.object_info(name) > > A A A A A A 522 A A A A A A A A pos = self._get_cursor().position() > > A A A A A A 523 A A A A A A A A self._request_info['call_tip'] = > > A A A self._CallTipRequest(msg_id, pos) > > A A A A A A 524 A A A A A A A A return True > > A A A A A A 525 > > A A A A A A 526 A A A A def _complete(self): > > A A A A A A 527 A A A A A A A A """ Performs completion at the > current cursor > > A A A location. > > A A A A A A 528 A A A A A A A A """ > > > > A A A AttributeError: 'QTextCursor' object has no attribute > 'document' > > A A A -- > > A A A albert chin (china at thewrittenword.com) > > A A A _______________________________________________ > > A A A IPython-dev mailing list > > A A A IPython-dev at scipy.org > > A A A http://mail.scipy.org/mailman/listinfo/ipython-dev > > > _______________________________________________ > > IPython-dev mailing list > > IPython-dev at scipy.org > > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- > albert chin (china at thewrittenword.com) > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev -- albert chin (china at thewrittenword.com) From fperez.net at gmail.com Fri Oct 7 03:24:19 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 7 Oct 2011 00:24:19 -0700 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: <20111007072251.GD14523@thewrittenword.com> References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> <20111007072251.GD14523@thewrittenword.com> Message-ID: On Fri, Oct 7, 2011 at 12:22 AM, Albert Chin wrote: > > No. We just upgraded PyQt and sip. We're still running against > qt-4.4.3. Upgrading Qt is a bit more work. Do we need qt-4.7.x for > qtconsole? Unfortunately it's quite possible that's the case. To be honest, we never tested against older versions of Qt itself, so we're not exactly sure. But none of the problems you report have appeared in linuxes running more recent Qt, so that's the most likely culprit, I'm afraid. best, f From ipython-dev at mlists.thewrittenword.com Fri Oct 7 17:56:11 2011 From: ipython-dev at mlists.thewrittenword.com (Albert Chin) Date: Fri, 7 Oct 2011 16:56:11 -0500 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> <20111007072251.GD14523@thewrittenword.com> Message-ID: <20111007215611.GA5436@china> On Fri, Oct 07, 2011 at 12:24:19AM -0700, Fernando Perez wrote: > On Fri, Oct 7, 2011 at 12:22 AM, Albert Chin > wrote: > > > > No. We just upgraded PyQt and sip. We're still running against > > qt-4.4.3. Upgrading Qt is a bit more work. Do we need qt-4.7.x for > > qtconsole? > > Unfortunately it's quite possible that's the case. To be honest, we > never tested against older versions of Qt itself, so we're not exactly > sure. But none of the problems you report have appeared in linuxes > running more recent Qt, so that's the most likely culprit, I'm afraid. Just tested qt-4.7.4 with latest PyQt and it works. Thanks! -- albert chin (china at thewrittenword.com) From fperez.net at gmail.com Fri Oct 7 19:25:51 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 7 Oct 2011 16:25:51 -0700 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: <20111007215611.GA5436@china> References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> <20111007072251.GD14523@thewrittenword.com> <20111007215611.GA5436@china> Message-ID: On Fri, Oct 7, 2011 at 2:56 PM, Albert Chin wrote: > Just tested qt-4.7.4 with latest PyQt and it works. Thanks! Great, glad to hear that. Now we also know what the actual Qt dependency is, so we can better inform people. Thanks for the patience and feedback. Best, f From benjaminrk at gmail.com Fri Oct 7 19:49:52 2011 From: benjaminrk at gmail.com (MinRK) Date: Fri, 7 Oct 2011 16:49:52 -0700 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> <20111007072251.GD14523@thewrittenword.com> <20111007215611.GA5436@china> Message-ID: On Fri, Oct 7, 2011 at 16:25, Fernando Perez wrote: > On Fri, Oct 7, 2011 at 2:56 PM, Albert Chin > wrote: > > Just tested qt-4.7.4 with latest PyQt and it works. Thanks! > > Great, glad to hear that. Now we also know what the actual Qt > dependency is, so we can better inform people. Thanks for the > patience and feedback. > I can add it to the qt import check, but we don't actually know where the line is drawn - it's just somewhere between 4.4.3 and 4.7.4, which is a pretty long time. > > Best, > > f > _______________________________________________ > 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: From fperez.net at gmail.com Fri Oct 7 21:35:24 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 7 Oct 2011 18:35:24 -0700 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> <20111007072251.GD14523@thewrittenword.com> <20111007215611.GA5436@china> Message-ID: On Fri, Oct 7, 2011 at 4:49 PM, MinRK wrote: > I can add it to the qt import check, but we don't actually know where the > line is drawn - it's just somewhere between 4.4.3 and 4.7.4, which is a > pretty long time. I guess we could just be a little over-conservative and do 4.7, but I don't know if that may shut out unnecessarily users who can't easily update say 4.5 or 4.6 where for all we know it works fine. An OK compromise would be to issue a *warning* for qt < 4.7, about possible issues. It will only bug a small subset of users, and those may actually be helped by it. Cheers, f From fperez.net at gmail.com Fri Oct 7 23:30:18 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 7 Oct 2011 20:30:18 -0700 Subject: [IPython-dev] Thinking about 0.12... Message-ID: Hi folks, I just wanted to get a feel from people about an 0.12 release soon. We've had ~150 closed issues (~90 PRs) since our last release, and there's a ton of new functionality, including the notebook that's looking very slick (http://i.imgur.com/WIkWG.png) and full python3 support. Furthermore, an EPD release is around the corner and the window to get into ubuntu 12.04, which is a long-term release, will close soon. So I'd rather push for a release really soon, delaying some issues to 0.13, rather than waiting for much longer. Especially b/c I know that some of us are all right now on *minimal* time availability, so we can't really promise massive pushes on many issues for the next few weeks. But I'd like to hear from others. Are there any issues in the tracker that you consider show-stoppers and aren't labeled critical priority? If so please let us know, as at this point we're only likely to look into open Pull Requests and critical issues. Cheers, f From pivanov314 at gmail.com Sat Oct 8 04:41:12 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Sat, 8 Oct 2011 01:41:12 -0700 Subject: [IPython-dev] Thinking about 0.12... In-Reply-To: References: Message-ID: On Fri, Oct 7, 2011 at 8:30 PM, Fernando Perez wrote: > But I'd like to hear from others. ?Are there any issues in the tracker > that you consider show-stoppers and aren't labeled critical priority? > If so please let us know, as at this point we're only likely to look > into open Pull Requests and critical issues. I'd really like to see terminal-based two-process working in 0.12, see https://github.com/ipython/ipython/pull/708 which currently has no labels. maybe I should look into pitching in on that front... -- Paul Ivanov 314 address only used for lists, ?off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From benjaminrk at gmail.com Sat Oct 8 18:22:46 2011 From: benjaminrk at gmail.com (MinRK) Date: Sat, 8 Oct 2011 15:22:46 -0700 Subject: [IPython-dev] Thinking about 0.12... In-Reply-To: References: Message-ID: On Sat, Oct 8, 2011 at 01:41, Paul Ivanov wrote: > On Fri, Oct 7, 2011 at 8:30 PM, Fernando Perez > wrote: > > But I'd like to hear from others. Are there any issues in the tracker > > that you consider show-stoppers and aren't labeled critical priority? > > If so please let us know, as at this point we're only likely to look > > into open Pull Requests and critical issues. > > I'd really like to see terminal-based two-process working in 0.12, see > https://github.com/ipython/ipython/pull/708 which currently has no > labels. > That would be great! If you fix the weird signal-handling issue, the only thing really missing should be an interface for the extra commands, like restarting/interrupting the kernel. But the signal behavior is really a show-stopper as it is. I just don't have time to work on that, so if you pick it up, it would be great to have in 0.12. -MinRK > > maybe I should look into pitching in on that front... > -- > Paul Ivanov > 314 address only used for lists, off-list direct email at: > http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 > _______________________________________________ > 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: From fperez.net at gmail.com Sat Oct 8 21:04:34 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 8 Oct 2011 18:04:34 -0700 Subject: [IPython-dev] Thinking about 0.12... In-Reply-To: References: Message-ID: On Sat, Oct 8, 2011 at 3:22 PM, MinRK wrote: > > On Sat, Oct 8, 2011 at 01:41, Paul Ivanov wrote: >> >> I'd really like to see terminal-based two-process working in 0.12, see >> https://github.com/ipython/ipython/pull/708 which currently has no >> labels. > > That would be great! ?If you fix the weird signal-handling issue, the only > thing really missing should be an interface for the extra commands, like > restarting/interrupting the kernel. But the signal behavior is really a > show-stopper as it is. > I just don't have time to work on that, so if you pick it up, it would be > great to have in 0.12. Eventually we'll probably want to refactor the various classes that handle these guys a bit further, to simplify the construction of one- or two- process versions of the main clients, but this would be a great start. Let us know how it goes and if you need any help, we can also meet up on campus to discuss it hands-on. Cheers, f From benjaminrk at gmail.com Sat Oct 8 21:15:30 2011 From: benjaminrk at gmail.com (MinRK) Date: Sat, 8 Oct 2011 18:15:30 -0700 Subject: [IPython-dev] Thinking about 0.12... In-Reply-To: References: Message-ID: On Sat, Oct 8, 2011 at 18:04, Fernando Perez wrote: > On Sat, Oct 8, 2011 at 3:22 PM, MinRK wrote: > > > > On Sat, Oct 8, 2011 at 01:41, Paul Ivanov wrote: > >> > >> I'd really like to see terminal-based two-process working in 0.12, see > >> https://github.com/ipython/ipython/pull/708 which currently has no > >> labels. > > > > That would be great! If you fix the weird signal-handling issue, the > only > > thing really missing should be an interface for the extra commands, like > > restarting/interrupting the kernel. But the signal behavior is really a > > show-stopper as it is. > > I just don't have time to work on that, so if you pick it up, it would be > > great to have in 0.12. > > Eventually we'll probably want to refactor the various classes that > handle these guys a bit further, to simplify the construction of one- > or two- process versions of the main clients, but this would be a > great start. > > Let us know how it goes and if you need any help, we can also meet up > on campus to discuss it hands-on. > Yes, and the more two-process clients we have, the better we will understand what might need to be reorganized. So please do complain about design weirdness you encounter, and anything that might make developing new clients easier. Right now, we have The QtConsole, notebook, and Paul's vim-client. -MinRK > Cheers, > > f > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans_meine at gmx.net Sun Oct 9 08:25:49 2011 From: hans_meine at gmx.net (Hans Meine) Date: Sun, 9 Oct 2011 14:25:49 +0200 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> <20111007072251.GD14523@thewrittenword.com> <20111007215611.GA5436@china> Message-ID: Hi! Am 08.10.2011 um 03:35 schrieb Fernando Perez: > On Fri, Oct 7, 2011 at 4:49 PM, MinRK wrote: >> I can add it to the qt import check, but we don't actually know where the >> line is drawn - it's just somewhere between 4.4.3 and 4.7.4, which is a >> pretty long time. > > I guess we could just be a little over-conservative and do 4.7, but I > don't know if that may shut out unnecessarily users who can't easily > update say 4.5 or 4.6 where for all we know it works fine. Indeed, the (really good!) Qt documentation quickly reveals that the posted exception would already vanish with 4.5: http://doc.qt.nokia.com/stable/qtextcursor.html#document (Of course, different issues could arise after that.) Let me also note as an explanation for the PyQt-only upgrade that PyQt is backwards-compatible with all (OK, many ;-) ) previous Qt versions and will "just export what?s there" in the given Qt version. HTH, Hans From fperez.net at gmail.com Sun Oct 9 14:22:30 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 9 Oct 2011 11:22:30 -0700 Subject: [IPython-dev] 0.11 on RHEL5/x86 In-Reply-To: References: <20111007051750.GA5882@china> <20111007060942.GC14523@thewrittenword.com> <20111007072251.GD14523@thewrittenword.com> <20111007215611.GA5436@china> Message-ID: On Sun, Oct 9, 2011 at 5:25 AM, Hans Meine wrote: > Indeed, the (really good!) Qt documentation quickly reveals that the posted exception would already vanish with 4.5: > http://doc.qt.nokia.com/stable/qtextcursor.html#document > > (Of course, different issues could arise after that.) OK, that's a useful data point, thanks. We might end up testing that soon at a workshop I'll be teaching on an older suse box, so if I learn anything more precise, we'll update our checks. Cheers, f From fperez.net at gmail.com Sun Oct 9 16:51:08 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 9 Oct 2011 13:51:08 -0700 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior Message-ID: Hi folks, I was doing some build tests, and since I have mathjax in my local tree, it's getting included by default in the tree. Fair enough, I thought: just add a prune rule to the MANIFEST.in file, and it's all good. But for the life of me, I can't get anything to work in there, it looks like on my system, the manifest.in file is just getting ignored! The relevant section reads: graft IPython prune IPython/deathrow prune IPython/frontend/html/notebook/static/mathjax but that mathjax directory is still getting copied over to the build dir when running `setup.py build`. Furthermore, I don't even see a MANIFEST file be generated at all anymore, which I don't understand. >From reading the official docs: http://docs.python.org/distutils/sourcedist.html#manifest-related-options I don't understand at all why there's no manifest file being created, or why the manifest.in rules are being ignored. This is the behavior I'm seeing on ubuntu 10.10 and 11.10 boxes, both with python 2.6 and 2.7... We need to understand this one, because ignoring the various rules in the manifest.in will make the downloads unnecessarily large... I'm pretty stumped, so any ideas would be very much appreciated. Cheers f From pivanov314 at gmail.com Mon Oct 10 02:23:22 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Sun, 9 Oct 2011 23:23:22 -0700 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior In-Reply-To: References: Message-ID: On Sun, Oct 9, 2011 at 1:51 PM, Fernando Perez wrote: > Hi folks, > > I was doing some build tests, and since I have mathjax in my local > tree, it's getting included by default in the tree. ?Fair enough, I > thought: just add a prune rule to the MANIFEST.in file, and it's all > good. ?But for the life of me, I can't get anything to work in there, > it looks like on my system, the manifest.in file is just getting > ignored! ?The relevant section reads: > > graft IPython > prune IPython/deathrow > prune IPython/frontend/html/notebook/static/mathjax > > but that mathjax directory is still getting copied over to the build > dir when running `setup.py build`. ?Furthermore, I don't even see a > MANIFEST file be generated at all anymore, which I don't understand. > > >From reading the official docs: > > http://docs.python.org/distutils/sourcedist.html#manifest-related-options > > I don't understand at all why there's no manifest file being created, > or why the manifest.in rules are being ignored. > > This is the behavior I'm seeing on ubuntu 10.10 and 11.10 boxes, both > with python 2.6 and 2.7... > > We need to understand this one, because ignoring the various rules in > the manifest.in will make the downloads unnecessarily large... > > I'm pretty stumped, so any ideas would be very much appreciated. I took a brief look - it looks like something about distribute and setuptools being used together. Wit this: 23:20 at ipython(master)$ git diff diff --git a/setup2.py b/setup2.py index 1c12356..0c340b9 100755 --- a/setup2.py +++ b/setup2.py @@ -193,7 +193,7 @@ data_files = find_data_files() # For some commands, use setuptools. Note that we do NOT list install here! # If you want a setuptools-enhanced install, just run 'setupegg.py install' -needs_setuptools = set(('develop', 'sdist', 'release', 'bdist_egg', 'bdist_rpm', +needs_setuptools = set(('develop', 'release', 'bdist_egg', 'bdist_rpm', 'bdist', 'bdist_dumb', 'bdist_wininst', 'install_egg_info', 'build_sphinx', 'egg_info', 'easy_install', 'upload', )) 23:21 at ipython(master)$ python setup.py sdist --manifest-only mkdir -p build/html build/doctrees sphinx-build -b html -d build/doctrees source build/html Running Sphinx v1.0.7 loading pickled environment... not yet created building [html]: targets for 217 source files that are out of date updating environment: 217 added, 0 changed, 0 removed ^C^Cing sources... [ 2%] api/generated/IPython.config.configurable make: *** [html] Error 1 ============================================================================ BUILDING IPYTHON python: 2.7.2 |EPD 7.1-2 (32-bit)| (default, Jul 27 2011, 13:29:32) [GCC 4.0.1 (Apple Inc. build 5493)] platform: darwin OPTIONAL DEPENDENCIES sphinx: 1.0.7 pygments: 1.4 nose: 1.0.0 pexpect: no (required for running standalone doctests) pyzmq: 2.1.7 readline: yes running sdist running check warning: sdist: standard file not found: should have one of README, README.txt reading manifest template 'MANIFEST.in' warning: no previously-included files found matching 'docs/#*' no previously-included directories found matching 'docs/gh-pages' warning: no previously-included files matching '*~' found anywhere in distribution warning: no previously-included files matching '*.flc' found anywhere in distribution warning: no previously-included files matching '.dircopy.log' found anywhere in distribution warning: no previously-included files matching '.svn' found anywhere in distribution warning: no previously-included files matching '.bzr' found anywhere in distribution warning: no previously-included files matching '.hgignore' found anywhere in distribution writing manifest file 'MANIFEST' 23:21 at ipython(master)$ best, -- Paul Ivanov 314 address only used for lists, ?off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From pivanov314 at gmail.com Mon Oct 10 15:56:06 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Mon, 10 Oct 2011 12:56:06 -0700 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior In-Reply-To: References: Message-ID: On Sun, Oct 9, 2011 at 11:23 PM, Paul Ivanov wrote: > On Sun, Oct 9, 2011 at 1:51 PM, Fernando Perez wrote: >> >> I'm pretty stumped, so any ideas would be very much appreciated. > > I took a brief look - it looks like something about distribute and > setuptools being used together. I poked around some more: looks like importing setuptools changes distutils.dist.Distribution to point to setuptools.dist.Distribution, and also does the same with command.sdist, with setuptools' version not implementing user_options like 'manifest-only' (see setuptools/dist.py:642-644) Compare just the --help sdist command with and without importing setuptools. $ python setup.py --help sdist without setuptools: --- Options for 'sdist' command: --template (-t) name of manifest template file [default: MANIFEST.in] --manifest (-m) name of manifest file [default: MANIFEST] --use-defaults include the default file set in the manifest [default; disable with --no-defaults] --no-defaults don't include the default file set --prune specifically exclude files/directories that should not be distributed (build tree, RCS/CVS dirs, etc.) [default; disable with --no-prune] --no-prune don't automatically exclude anything --manifest-only (-o) just regenerate the manifest and then stop (implies --force-manifest) --force-manifest (-f) forcibly regenerate the manifest and carry on as usual. Deprecated: now the manifest is always regenerated. --formats formats for source distribution (comma-separated list) --keep-temp (-k) keep the distribution tree around after creating archive file(s) --dist-dir (-d) directory to put the source distribution archive(s) in [default: dist] --metadata-check Ensure that all required elements of meta-data are supplied. Warn if any missing. [default] --owner (-u) Owner name used when creating a tar file [default: current user] --group (-g) Group name used when creating a tar file [default: current group] --help-formats list available distribution formats --- When setuptools is imported, the help string is much shorter, and shows none of the usual user_options. --- Options for 'sdist' command: --formats formats for source distribution (comma-separated list) --keep-temp (-k) keep the distribution tree around after creating archive file(s) --dist-dir (-d) directory to put the source distribution archive(s) in [default: dist] --help-formats list available distribution formats --- I guess if setuptools really is needed to be imported, one way to get back the functionality would be to reverse-monkeypatch distutils' Distribution back in using the following patch (or something like it, perhaps only if '--manifest-only' or '-o' flags are passed): diff --git a/setup2.py b/setup2.py index 1c12356..3a37c6c 100755 --- a/setup2.py +++ b/setup2.py @@ -212,6 +212,10 @@ if len(needs_setuptools.intersection(sys.argv)) > 0: setuptools_extra_args = {} if 'setuptools' in sys.modules: + # reverse monkeypatch setuptools/dist.py:643-644 + import distutils + for module in distutils.dist, distutils.core, distutils.cmd: + module.Distribution = setuptools.dist._Distribution setuptools_extra_args['zip_safe'] = False setuptools_extra_args['entry_points'] = find_scripts(True) setup_args['extras_require'] = dict( Doing the above, however, will cause these warnings to start showing up distutils/dist.py:267: UserWarning: Unknown distribution option: 'install_requires' warnings.warn(msg) distutils/dist.py:267: UserWarning: Unknown distribution option: 'extras_require' warnings.warn(msg) python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'zip_safe' warnings.warn(msg) python2.7/distutils/dist.py:267: UserWarning: Unknown distribution option: 'entry_points hth, -- Paul Ivanov 314 address only used for lists, ?off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From fperez.net at gmail.com Mon Oct 10 16:20:22 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 10 Oct 2011 13:20:22 -0700 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior In-Reply-To: References: Message-ID: Hey Paul, On Mon, Oct 10, 2011 at 12:56 PM, Paul Ivanov wrote: > > I poked around some more: looks like importing setuptools changes > distutils.dist.Distribution to point to setuptools.dist.Distribution, > and also does the same with command.sdist, with setuptools' version > not implementing user_options like 'manifest-only' (see > setuptools/dist.py:642-644) Many thanks for digging this one out. My distutils-foo is rusty. I had the habit of, whenever observing weird behavior where distutils is deviating from the stated documentation, doing a quick print 'setuptools' in sys.modules just to know. Since setuptools does so much by monkeypatching, once you see it's been imported you can at least be on the lookout. I'm actually not sure that we *need* setuptools in the sdist command, I can't really remember why it was put there. Does anyone recall? My instinct would be to *not* use setuptools for sdist, but I don't want to make that change right now. There's a good chance we put that in because we needed it for something... Can anyone think/remember why that was the case? Cheers, f From pivanov314 at gmail.com Mon Oct 10 16:45:03 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Mon, 10 Oct 2011 13:45:03 -0700 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior In-Reply-To: References: Message-ID: On Mon, Oct 10, 2011 at 1:20 PM, Fernando Perez wrote: > I'm actually not sure that we *need* setuptools in the sdist command, > I can't really remember why it was put there. ?Does anyone recall? > > My instinct would be to *not* use setuptools for sdist, but I don't > want to make that change right now. ?There's a good chance we put that > in because we needed it for something... ?Can anyone think/remember > why that was the case? Found it here: 702b2cb74608995f2aad56c95daae620ff2d5711 which points to the discussion on this old bug: https://bugs.launchpad.net/ipython/+bug/504968 It comes from Gael's joblib - where Gael still has 'sdist' listed under "For some commands, use setuptools" (https://github.com/joblib/joblib/blob/master/setup.py) -- Paul Ivanov 314 address only used for lists, ?off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From gael.varoquaux at normalesup.org Mon Oct 10 16:50:36 2011 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 10 Oct 2011 22:50:36 +0200 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior In-Reply-To: References: Message-ID: <20111010205036.GC3943@phare.normalesup.org> On Mon, Oct 10, 2011 at 01:45:03PM -0700, Paul Ivanov wrote: > It comes from Gael's joblib - where Gael still has 'sdist' listed > under "For some commands, use setuptools" > (https://github.com/joblib/joblib/blob/master/setup.py) Hum, I am not sure why. Maybe because I do a sphinx_build for the sdist. If you find out more about what side effects having setuptools in for the sdist does, I am interested. Gael From pivanov314 at gmail.com Mon Oct 10 16:59:12 2011 From: pivanov314 at gmail.com (Paul Ivanov) Date: Mon, 10 Oct 2011 13:59:12 -0700 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior In-Reply-To: <20111010205036.GC3943@phare.normalesup.org> References: <20111010205036.GC3943@phare.normalesup.org> Message-ID: On Mon, Oct 10, 2011 at 1:50 PM, Gael Varoquaux wrote: > Hum, I am not sure why. Maybe because I do a sphinx_build for the sdist. > If you find out more about what side effects having setuptools in for the > sdist does, I am interested. See my reply an hour ago - none of the distutils sdist options are available for the setuptools version one: Fernando originally was puzzled by why "sdist --manifest-only" wasn't working - but it turns out that once setuptools is imported, none of the following guys are available: --template (-t) name of manifest template file [default: MANIFEST.in] --manifest (-m) name of manifest file [default: MANIFEST] --use-defaults include the default file set in the manifest [default; disable with --no-defaults] --no-defaults don't include the default file set --prune specifically exclude files/directories that should not be distributed (build tree, RCS/CVS dirs, etc.) [default; disable with --no-prune] --no-prune don't automatically exclude anything --manifest-only (-o) just regenerate the manifest and then stop (implies --force-manifest) --force-manifest (-f) forcibly regenerate the manifest and carry on as usual. Deprecated: now the manifest is always regenerated. --metadata-check Ensure that all required elements of meta-data are supplied. Warn if any missing. [default] --owner (-u) Owner name used when creating a tar file [default: current user] --group (-g) Group name used when creating a tar file [default: current group] -- Paul Ivanov 314 address only used for lists, ?off-list direct email at: http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 From gael.varoquaux at normalesup.org Mon Oct 10 17:04:57 2011 From: gael.varoquaux at normalesup.org (Gael Varoquaux) Date: Mon, 10 Oct 2011 23:04:57 +0200 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior In-Reply-To: References: <20111010205036.GC3943@phare.normalesup.org> Message-ID: <20111010210457.GD3943@phare.normalesup.org> On Mon, Oct 10, 2011 at 01:59:12PM -0700, Paul Ivanov wrote: > On Mon, Oct 10, 2011 at 1:50 PM, Gael Varoquaux > wrote: > > Hum, I am not sure why. Maybe because I do a sphinx_build for the sdist. > > If you find out more about what side effects having setuptools in for the > > sdist does, I am interested. > See my reply an hour ago Yes, I got it after recieving this email, which explains my answer, a bit off. >- none of the distutils sdist options are available for the setuptools >version one That's pretty bad. I am not going to change anything in joblib because I depend on build_sphinx for releasing, and it will cause the loading of setuptools anyhow. However, it does seem that sdist should as much as possible not load setuptools. It seems to me that removing 'sdist' from the list of keywords triggering setuptools in IPython would be the right thing to do. G From fperez.net at gmail.com Mon Oct 10 18:02:52 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Mon, 10 Oct 2011 15:02:52 -0700 Subject: [IPython-dev] Help needed: stumped by odd MANIFEST.in/distutils behavior In-Reply-To: <20111010210457.GD3943@phare.normalesup.org> References: <20111010205036.GC3943@phare.normalesup.org> <20111010210457.GD3943@phare.normalesup.org> Message-ID: Thanks to both for the detective work! On Mon, Oct 10, 2011 at 2:04 PM, Gael Varoquaux wrote: > It seems to me that removing 'sdist' from > the list of keywords triggering setuptools in IPython would be the right > thing to do. OK, that's very useful feedback: knowing the reason behind your use of it (the sphinx_build), I agree with the above. I'll push that fix in a minute then, it's tiny and will make getting ready for an 0.12 release smother. Cheers, f From cekees at gmail.com Thu Oct 13 12:02:03 2011 From: cekees at gmail.com (Chris Kees) Date: Thu, 13 Oct 2011 11:02:03 -0500 Subject: [IPython-dev] notebook with password authentication Message-ID: Did I understand correctly that the notebook can be configured to require a password? If so, could somebody point me to the documentation on how to do that? I can't seem to find the correction option to add to my 'ipython notebook' command. -Chris From satra at mit.edu Thu Oct 13 12:10:02 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Thu, 13 Oct 2011 12:10:02 -0400 Subject: [IPython-dev] notebook with password authentication In-Reply-To: References: Message-ID: hi chris, thanks. i've now added an issue which will extend the documentation. indeed there is vary basic authentication available and is highly recommended to do this over an SSL connection. for security reasons this password cannot be provided on the command line and has to be encoded in the notebook config file. here is the relevant section from my ipython_notebook_config.py the documentation for creating the certificate file is on the web. http://ipython.org/ipython-doc/dev/interactive/htmlnotebook.html --- # The full path to an SSL/TLS certificate file. c.IPythonNotebookApp.certfile = u'/users/satra/mycert.pem' # The FQDN or IP for WebSocket connections. The default will work fine when the # server is listening on localhost, but this needs to be set if the ip option is # used. It will be used as the hostname part of the WebSocket url: # ws://hostname/path. c.IPythonNotebookApp.ws_hostname = 'fullname.mit.edu' # The IP address the notebook server will listen on. c.IPythonNotebookApp.ip = '*' c.IPythonNotebookApp.password = u'password' --- cheers, satra On Thu, Oct 13, 2011 at 12:02 PM, Chris Kees wrote: > Did I understand correctly that the notebook can be configured to > require a password? If so, could somebody point me to the > documentation on how to do that? I can't seem to find the correction > option to add to my 'ipython notebook' command. -Chris > _______________________________________________ > 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: From cekees at gmail.com Thu Oct 13 12:41:41 2011 From: cekees at gmail.com (Chris Kees) Date: Thu, 13 Oct 2011 11:41:41 -0500 Subject: [IPython-dev] notebook with password authentication In-Reply-To: References: Message-ID: Thanks! It's working with ssl now. On Oct 13, 2011, at 11:10 AM, Satrajit Ghosh wrote: > hi chris, > > thanks. i've now added an issue which will extend the documentation. > > indeed there is vary basic authentication available and is highly recommended to do this over an SSL connection. for security reasons this password cannot be provided on the command line and has to be encoded in the notebook config file. > > here is the relevant section from my ipython_notebook_config.py > > the documentation for creating the certificate file is on the web. > > http://ipython.org/ipython-doc/dev/interactive/htmlnotebook.html > > --- > # The full path to an SSL/TLS certificate file. > c.IPythonNotebookApp.certfile = u'/users/satra/mycert.pem' > > # The FQDN or IP for WebSocket connections. The default will work fine when the > # server is listening on localhost, but this needs to be set if the ip option is > # used. It will be used as the hostname part of the WebSocket url: > # ws://hostname/path. > c.IPythonNotebookApp.ws_hostname = 'fullname.mit.edu' > > # The IP address the notebook server will listen on. > c.IPythonNotebookApp.ip = '*' > > c.IPythonNotebookApp.password = u'password' > --- > > cheers, > > satra > > > > On Thu, Oct 13, 2011 at 12:02 PM, Chris Kees wrote: > Did I understand correctly that the notebook can be configured to > require a password? If so, could somebody point me to the > documentation on how to do that? I can't seem to find the correction > option to add to my 'ipython notebook' command. -Chris > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > _______________________________________________ > 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: From mark.voorhies at ucsf.edu Thu Oct 13 20:05:56 2011 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Thu, 13 Oct 2011 17:05:56 -0700 Subject: [IPython-dev] %page help(x) Message-ID: <201110131705.56624.mark.voorhies@ucsf.edu> I'd like to send the results of help(myclass) (i.e., the class and method docstrings) to the qtconsole pager. "myclass?', "myclass??", and "%pdoc myclass" are all not what I'm looking for. Is this a thing? If not, which module should I be hacking on? Thanks, Mark From fperez.net at gmail.com Thu Oct 13 20:24:23 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 13 Oct 2011 17:24:23 -0700 Subject: [IPython-dev] %page help(x) In-Reply-To: <201110131705.56624.mark.voorhies@ucsf.edu> References: <201110131705.56624.mark.voorhies@ucsf.edu> Message-ID: Hey Mark, On Thu, Oct 13, 2011 at 5:05 PM, Mark Voorhies wrote: > I'd like to send the results of help(myclass) (i.e., the class and method docstrings) > to the qtconsole pager. ?"myclass?', "myclass??", and "%pdoc myclass" are all not > what I'm looking for. ?Is this a thing? ?If not, which module should I be hacking on? > help() is a part of the python stdlib, you can see the code by typing help?? at the ipython prompt. It will show you that it's a little wrapper around pydoc.help. So you could simply write your own function/magic that uses this helper but instead of letting it display its results, fetches them and calls the ipython pager. Let us know if you need further details. Cheers, f From benjaminrk at gmail.com Thu Oct 13 21:05:23 2011 From: benjaminrk at gmail.com (MinRK) Date: Thu, 13 Oct 2011 18:05:23 -0700 Subject: [IPython-dev] PyZMQ 2.1.10 Message-ID: ZeroMQ cut 2.1.10 last week, and I followed suit today, cutting PyZMQ 2.1.10. The principal relevance of this for IPython is that IPython 0.11 uses a string comparison for checking the pyzmq version, but this obviously doesn't work once you get into double digits. This was fixed in master quite a while ago, so updating to IPython master (or using pyzmq 2.1.9 or dev) will avoid the issue. But the situation is that IPython's zmq code (parallel and qtconsole) will raise ImportErrors with pyzmq 2.1.10. If you must use IPython 0.11 and a bdist of pyzmq, you can force pyzmq to install 2.1.9 with `easy_install pyzmq==2.1.9`. -MinRK From fperez.net at gmail.com Thu Oct 13 21:30:38 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 13 Oct 2011 18:30:38 -0700 Subject: [IPython-dev] [IPython-User] PyZMQ 2.1.10 In-Reply-To: References: Message-ID: On Thu, Oct 13, 2011 at 6:05 PM, MinRK wrote: > If you must use IPython 0.11 and a bdist of pyzmq, you can force pyzmq > to install 2.1.9 with `easy_install pyzmq==2.1.9`. Alternatively, if you know you have pyzmq 2.1.10 and don't want to upgrade IPython at this moment, a quick and dirty fix is to manually edit the file IPython/zmq/__init__.py, and comment out or delete these lines towards the top: if pyzmq_version < minimum_pyzmq_version: raise ImportError("IPython.zmq requires pyzmq >= %s, but you have %s"%( minimum_pyzmq_version, pyzmq_version)) That should do the trick (ugly but effective). Cheers, f From mark.voorhies at ucsf.edu Thu Oct 13 21:59:36 2011 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Thu, 13 Oct 2011 18:59:36 -0700 Subject: [IPython-dev] %page help(x) In-Reply-To: References: <201110131705.56624.mark.voorhies@ucsf.edu> Message-ID: <201110131859.37181.mark.voorhies@ucsf.edu> On Thursday, October 13, 2011 05:24:23 pm Fernando Perez wrote: > Hey Mark, > > On Thu, Oct 13, 2011 at 5:05 PM, Mark Voorhies wrote: > > I'd like to send the results of help(myclass) (i.e., the class and method docstrings) > > to the qtconsole pager. "myclass?', "myclass??", and "%pdoc myclass" are all not > > what I'm looking for. Is this a thing? If not, which module should I be hacking on? > > > > help() is a part of the python stdlib, you can see the code by typing > help?? at the ipython prompt. It will show you that it's a little > wrapper around pydoc.help. So you could simply write your own > function/magic that uses this helper but instead of letting it display > its results, fetches them and calls the ipython pager. > > Let us know if you need further details. > > Cheers, > > f > Thanks! --Mark P.S.: If I get this working, is it worth a pull request, or is this the sort of thing that should live in personal magic? From fperez.net at gmail.com Thu Oct 13 22:36:39 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 13 Oct 2011 19:36:39 -0700 Subject: [IPython-dev] %page help(x) In-Reply-To: <201110131859.37181.mark.voorhies@ucsf.edu> References: <201110131705.56624.mark.voorhies@ucsf.edu> <201110131859.37181.mark.voorhies@ucsf.edu> Message-ID: On Thu, Oct 13, 2011 at 6:59 PM, Mark Voorhies wrote: > P.S.: If I get this working, is it worth a pull request, or is this the sort of thing > that should live in personal magic? I never use help myself, so I'd never really cared. But I now see that in the qtconsole, help() is kind of useless, because it doesn't know how to page. It's going to be equally useless in the notebook. So perhaps the right solution is to build our own replacement for the built-in help(), that is smarter about the clients it's in and that in the long run could also format doctrings into html with TeX, etc... I don't know how far you want to take it, but there's definitely potential here to improve the situation regarding interactive help. I'd suggest you play with it locally first, and if you think you do want to build something more robust/general, then we'd definitely be happy to take a PR for it. Cheers, f From mattpap at gmail.com Thu Oct 13 23:31:48 2011 From: mattpap at gmail.com (Mateusz Paprocki) Date: Thu, 13 Oct 2011 20:31:48 -0700 Subject: [IPython-dev] Custom exception handling Message-ID: Hi, I was working on an extension to SymPy that would allow us to automatically construct missing symbols in interactive isympy sessions (IPython based) (see here [1]) and I found some confusing to me code in IPython/core/interactiveshell.py. The docstring of InteractiveShell.set_custom_exc says that `handler` argument must be a function that returns a structured traceback. However, in InteractiveShell.run_code the code for handling custom exceptions simply calls self.CustomTB(...) and ignores the result [2]. This code also shadows custom exception handling code from InteractiveShell.showtraceback, which doesn't ignore return value from self.CustomTB(), but contains undefined variable `ctb` [3] (should be `stb`). I wanted to submit a pull request fixing this, but I'm not sure how to proceed. I wanted to remove custom exception handling code from InteractiveShell.run_code and in InteractiveShell.showtraceback add a case for None return value from self.CustomTB(...) (which would mean "do nothing and return immediately", to maintain compatibility), and of course fix `ctb`. I was also thinking about another special case where custom exception handler decides that IPython should proceed with displaying a traceback (False return value would be used for this). This would be useful in my case, because I don't want to do any traceback formatting in the handler, just construct and injects symbols if necessary. btw. If you see a better way to solve the problem that is solved by [1], I'm looking forward to your suggestions. Mateusz [1] https://github.com/sympy/sympy/pull/643 [2] https://github.com/ipython/ipython/blob/master/IPython/core/interactiveshell.py#L2438 [3] https://github.com/ipython/ipython/blob/master/IPython/core/interactiveshell.py#L1562 -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Sat Oct 15 16:00:03 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 15 Oct 2011 21:00:03 +0100 Subject: [IPython-dev] Potential projects Message-ID: Hi all, I've started a wiki page with ideas for relatively self-contained projects that interested contributors could work on. It's a bit sparse at the moment, so please add some things you'd like to see, but don't have time to work on yourself. http://wiki.ipython.org/Potential_projects I'd like this to be for quite specific deliverable things, rather than nebulous goals. So 'write a tool to handle use case xyz' is suitable, but 'improve the documentation' isn't (although it's probably something people always can do). Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Oct 15 17:13:28 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 15 Oct 2011 14:13:28 -0700 Subject: [IPython-dev] Potential projects In-Reply-To: References: Message-ID: On Sat, Oct 15, 2011 at 1:00 PM, Thomas Kluyver wrote: > > I've started a wiki page with ideas for relatively self-contained projects > that interested contributors could work on. It's a bit sparse at the moment, > so please add some things you'd like to see, but don't have time to work on > yourself. > > http://wiki.ipython.org/Potential_projects > > I'd like this to be for quite specific deliverable things, rather than > nebulous goals. So 'write a tool to handle use case xyz' is suitable, but > 'improve the documentation' isn't (although it's probably something people > always can do). Great, thanks! One concrete, and high-value topic to have there would be our recent discussion of the python readline capability implementation. I'll try to summarize it later today, unless you beat me to it :) (we had a recent thread on-list that I haven't had a chance to get back to, as the PR flood has been keeping me pretty much maxed out). Cheers, f From takowl at gmail.com Sat Oct 15 17:33:25 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 15 Oct 2011 22:33:25 +0100 Subject: [IPython-dev] Potential projects In-Reply-To: References: Message-ID: On 15 October 2011 22:13, Fernando Perez wrote: > One concrete, and high-value topic to have there would be our recent > discussion of the python readline capability implementation. I'll try > to summarize it later today, unless you beat me to it :) (we had a > recent thread on-list that I haven't had a chance to get back to, as > the PR flood has been keeping me pretty much maxed out). > Thanks, Fernando. I've done a summary of it and tracked down that thread, but feel free to add more info if you want. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Oct 15 17:40:07 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 15 Oct 2011 14:40:07 -0700 Subject: [IPython-dev] Potential projects In-Reply-To: References: Message-ID: On Sat, Oct 15, 2011 at 2:33 PM, Thomas Kluyver wrote: > > Thanks, Fernando. I've done a summary of it and tracked down that thread, > but feel free to add more info if you want. Thanks! I'm trying to wrap up some nb work this afternoon, so I really appreciate your help. f From andresete.chaos at gmail.com Sat Oct 15 17:43:01 2011 From: andresete.chaos at gmail.com (=?ISO-8859-1?Q?Omar_Andr=E9s_Zapata_Mesa?=) Date: Sat, 15 Oct 2011 16:43:01 -0500 Subject: [IPython-dev] Potential projects In-Reply-To: References: Message-ID: Great Thomas, I think another potential project is to write an ncurses or urwid interface, more complete than the current terminal That could have a layout with windows to view others online users, the history, chat, variables in namespace, menu for restart kernel, save/load session, export code, code completion (similar to bpython) etc... I learning http://excess.org/urwid/ with simple examples at the moment but I am planning to write something for ipython. On Sat, Oct 15, 2011 at 4:40 PM, Fernando Perez wrote: > On Sat, Oct 15, 2011 at 2:33 PM, Thomas Kluyver wrote: > > > > Thanks, Fernando. I've done a summary of it and tracked down that thread, > > but feel free to add more info if you want. > > Thanks! I'm trying to wrap up some nb work this afternoon, so I > really appreciate your help. > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > -- Omar Andres Zapata Mesa Fundamental Interaction Phenomenology Gruop (Gfif) Head Developer http://gfif.udea.edu.co Gfif Developers (Gfif Dev) Division of computer science http://gfifdev.udea.edu.co System Engineering Student Universidad de Antioquia At Medellin - Colombia Usuario Linux #490962 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Oct 15 17:50:17 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 15 Oct 2011 14:50:17 -0700 Subject: [IPython-dev] 0.12, concrete plans; help welcome! Message-ID: Hey folks, trying to keep the ball in motion towards 0.12 here... I had a look and we only have two issues tagged critical/0.12, and both of these actually are already tied to in-progress PRs. So it looks like if we make headway on our open PRs in the next week or two, we should be able to cut 0.12 in time for Ubuntu 12.04 (it's a long-term support one, so it would be very nice to get in there with the notebook). So a few things those on this list can help us with: - if you see an issue on the tracker that is NOT tagged 0.12/critical but you think should be a blocker, please let us know and we'll consider it. - if you can test things out from git master, bang on the notebook and the qt console and report what breaks/doesn't work, that would be great. Particularly if you spot anything bad enough that it should be considered a blocker, yell loudly. - we need more eyes on the open PRs, and there's a little bit for everyone: Qt, console, notebook, internals. Helping test/review an existing PR gives the core team more confidence on how to move forward, and is a great way to get acquainted with the codebase, so don't be shy! Anyone can comment on a PR, and we really value new pairs of eyes on them. As a rule of thumb, a PR with 20 or 30 comments is likely to have an already complicated discussion going on so you may want to skip those on a first pass, unless you happen to care/know about the topic. But one with very little feedback could really benefit from your eyes, there's a few that still have 0 comments. It actually looks like we're in reasonable shape for a release in a few weeks, though I know right now Brian and Min are both swamped enough that they have super limited bandwidth. But with a bit of help from everyone, this release won't be nearly as painful as 0.11 was, and I think we'll make many people happy out there with the notebook and the improvements to the Qt console (there's an excellent PR for that at https://github.com/ipython/ipython/pull/813). Cheers, f From fperez.net at gmail.com Sat Oct 15 17:59:09 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 15 Oct 2011 14:59:09 -0700 Subject: [IPython-dev] Potential projects In-Reply-To: References: Message-ID: Hi Omar, 2011/10/15 Omar Andr?s Zapata Mesa : > I think another potential project is to write an ncurses or urwid interface, > more complete than the current terminal > That could have a layout with windows to view others online users, the > history, chat, variables in namespace, ?menu for restart kernel, save/load > session, ?export code, code completion (similar to bpython) etc... > I learning?http://excess.org/urwid/? with simple examples at the moment but > I am planning to write something for ipython. Yes, we've talked for a long time about a curses front end, that would be super welcome by anyone working in a server environment... Search the list for archives for 'Wendell' and you'll find discussions with him about this topic. A few things to note: - I spoke a while ago with the author of bpython (http://bpython-interpreter.org) about possible collaboration, and he sounded interested. I don't know how easy it would be to use the bpython code in a way that could benefit both projects, but Bob sounds like a great guy who's happy to share his work, so it's definitely worth spending some effort into understanding the possibilities here. In addition, bpython is MIT licensed, so even if it's not possible to fully share the whole architecture, it would be OK for IPython to take snippets from bpython. - If you get going with this, I suggest just starting a fresh repository as a standalone, installable application, similar to how Paul Ivanov has developed the vim-ipython client (https://github.com/ivanov/vim-ipython). This will make it easier for you to develop initially without the complexity of the entire IPython tree, and for this client to grow and stabilize on its own. In the long run I do see a curses client as something we should ship inside ipython, but at this point ipython is big and complex enough that I think it's saner/easier to develop new clients (vim, curses, etc) on their own for a while. We already have a big enough task with the three 'core' ones (console, qtconsole, notebook) for our small team. Once the vim/curses clients mature and are fully stable, it might make sense to fold them into the IPython tree, but there's no need to make that decision quite yet, and I think Paul's experience shows that the development in a lightweight, standalone tree can work quite well. Cheers, f From takowl at gmail.com Sat Oct 15 18:22:20 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 15 Oct 2011 23:22:20 +0100 Subject: [IPython-dev] Potential projects In-Reply-To: References: Message-ID: 2011/10/15 Omar Andr?s Zapata Mesa > I think another potential project is to write an ncurses or urwid > interface, more complete than the current terminal Thanks, Omar. I've added this to the projects page too - remember to make a note there if you start work on it. Best wishes, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Sat Oct 15 18:27:19 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sat, 15 Oct 2011 23:27:19 +0100 Subject: [IPython-dev] 0.12, concrete plans; help welcome! In-Reply-To: References: Message-ID: On 15 October 2011 22:50, Fernando Perez wrote: > - we need more eyes on the open PRs, and there's a little bit for > everyone: Qt, console, notebook, internals. Helping test/review an > existing PR gives the core team more confidence on how to move > forward, and is a great way to get acquainted with the codebase, so > don't be shy! Anyone can comment on a PR, and we really value new > pairs of eyes on them. As a rule of thumb, a PR with 20 or 30 > comments is likely to have an already complicated discussion going on > so you may want to skip those on a first pass, unless you happen to > care/know about the topic. But one with very little feedback could > really benefit from your eyes, there's a few that still have 0 > comments. > I jotted down a quick set of things to look for in a pull request: http://wiki.ipython.org/The_perfect_pull_request It's pretty terse at the moment, so feel free to flesh it out. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.stenarson at bostream.nu Tue Oct 18 16:00:48 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 18 Oct 2011 22:00:48 +0200 Subject: [IPython-dev] Tk pylab annoyance Message-ID: <4E9DDAF0.8030509@bostream.nu> Hi, when starting ipython --pylab=tk I loose focus from the terminal window at startup. Unless I press some key during startup before the prompt appears. Anyone else seeing this? I'm on windows 7 python 2.6 and with ipython master. Anyone got any ideas what could cause this? /J?rgen From jorgen.stenarson at bostream.nu Tue Oct 18 16:56:22 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 18 Oct 2011 22:56:22 +0200 Subject: [IPython-dev] multiline history Message-ID: <4E9DE7F6.5090103@bostream.nu> Hi, why have multiline history become the default in the terminal (master)? At least on windows this makes no sense since pyreadline can not edit more than one line. /J?rgen From benjaminrk at gmail.com Tue Oct 18 17:01:52 2011 From: benjaminrk at gmail.com (MinRK) Date: Tue, 18 Oct 2011 14:01:52 -0700 Subject: [IPython-dev] multiline history In-Reply-To: <4E9DE7F6.5090103@bostream.nu> References: <4E9DE7F6.5090103@bostream.nu> Message-ID: On Tue, Oct 18, 2011 at 13:56, J?rgen Stenarson wrote: > Hi, > > why have multiline history become the default in the terminal (master)? I think because demand for it was vociferous. > > At least on windows this makes no sense since pyreadline can not edit > more than one line. Then we should probably make the default Bool(sys.platform != 'win32'), rather than strictly True. > > /J?rgen > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From takowl at gmail.com Tue Oct 18 17:02:15 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Tue, 18 Oct 2011 22:02:15 +0100 Subject: [IPython-dev] multiline history In-Reply-To: <4E9DE7F6.5090103@bostream.nu> References: <4E9DE7F6.5090103@bostream.nu> Message-ID: On 18 October 2011 21:56, J?rgen Stenarson wrote: > why have multiline history become the default in the terminal (master)? > > At least on windows this makes no sense since pyreadline can not edit > more than one line. > After some discussion on IRC, we decided it was the better default, because it's fiddly to reconstruct even a couple of lines if there are 20 other lines since, and at least on Unix, you can go across multiple lines, although it's not very convenient. Maybe the default needs to be platform dependent. But if you're using multiline editing a lot, we strongly encourage people to use the Qt console instead. Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jorgen.stenarson at bostream.nu Tue Oct 18 17:05:37 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Tue, 18 Oct 2011 23:05:37 +0200 Subject: [IPython-dev] bzr to git migration Message-ID: <4E9DEA21.9010001@bostream.nu> Hi Fernando, I'm planning to move pyreadline over to github. Did you ever write up how you did the migration from launchpad to github? I'm wondering how to get all the branches into a single git repo properly. All bzr to git documents I've seen focus on a single bzr branch. /J?rgen From fperez.net at gmail.com Tue Oct 18 16:06:33 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 18 Oct 2011 13:06:33 -0700 Subject: [IPython-dev] Tk pylab annoyance In-Reply-To: <4E9DDAF0.8030509@bostream.nu> References: <4E9DDAF0.8030509@bostream.nu> Message-ID: On Tue, Oct 18, 2011 at 1:00 PM, J?rgen Stenarson wrote: > > when starting ipython --pylab=tk I loose focus from the terminal window > at startup. Unless I press some key during startup before the prompt > appears. Anyone else seeing this? I'm on windows 7 python 2.6 and with > ipython master. > > Anyone got any ideas what could cause this? I suspect it's the creation of the tk root window by matplotlib. I don't know if the focus behavior of Tk is user controllable, sorry. If nobody from the mpl list responds here, perhaps you could ping their list in case one of their devs knows that codepath better. If there's anything we can do from ipython to influence that behavior, I'd love to hear, because I've been annoyed by it in the past too. From matthew.brett at gmail.com Tue Oct 18 20:29:31 2011 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 18 Oct 2011 17:29:31 -0700 Subject: [IPython-dev] bzr to git migration In-Reply-To: <4E9DEA21.9010001@bostream.nu> References: <4E9DEA21.9010001@bostream.nu> Message-ID: Hi, On Tue, Oct 18, 2011 at 2:05 PM, J?rgen Stenarson wrote: > Hi Fernando, > > I'm planning to move pyreadline over to github. Did you ever write up > how you did the migration from launchpad to github? I'm wondering how to > get all the branches into a single git repo properly. > > All bzr to git documents I've seen focus on a single bzr branch. I migrated the nipy repository from bzr to git, but took care to merge everything into a single branch before I did it. However, I think, that if you do the standard git->bzr migration, and it picks up all the commit times and dates, then you will be able to apply the same migration script to several branches, and then pull them into one git repo, because commits that are identical in bzr should be identical in git. I mean something like: mkdir git_branch1 my_migration_script.sh bzr_branch1 git_branch1 # converts bzr_branch1 to git repo mkdir git_branch2 my_migration_script.sh bzr_branch2 git_branch2 # convert bzr_branch2 to git repo cd git_branch2 git remote add branch1_repo ../git_branch1 git fetch branch1_repo git branch branch1 branch1_repo/master - if you see what I mean? If I'm wrong, then git remote add branch1_repo ../git_branch1 git fetch branch1_repo will say something like 'warning, no commits in common'... Best, Matthew From fperez.net at gmail.com Tue Oct 18 19:42:22 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 18 Oct 2011 16:42:22 -0700 Subject: [IPython-dev] bzr to git migration In-Reply-To: <4E9DEA21.9010001@bostream.nu> References: <4E9DEA21.9010001@bostream.nu> Message-ID: Hi Jorgen, On Tue, Oct 18, 2011 at 2:05 PM, J?rgen Stenarson wrote: > I'm planning to move pyreadline over to github. Did you ever write up > how you did the migration from launchpad to github? I'm wondering how to > get all the branches into a single git repo properly. > > All bzr to git documents I've seen focus on a single bzr branch. I never wrote anything up for real, but I do have a copy of the script I used: #!/bin/bash # Convert the ipython repo into a git one. set -e bzrepo=$HOME/ipython/repo branches="master 0.8 0.9 0.10 0.10.1" gitrepo=ipython-git rm -rf $gitrepo mkdir $gitrepo cd $gitrepo t0=$(date) git init for br in $branches do echo New branch from bzr: upstream-$br git bzr add upstream-$br $bzrepo/$br git bzr fetch upstream-$br git co -b $br bzr/upstream-$br done git gc git remote add mainline git at github.com:ipython/ipython.git echo "Started at: $t0" echo "Ended at : $(date)" # #git push origin master #### That might get you going with the code. My issues migration script is here: https://gist.github.com/835577 but github has changed its api since, so it will need some tweaking on the upload part for the new api. I hope this is useful to get started... Glad to have you coming over to github! BTW, you're welcome to create a separate organization for pyreadline, but if you'd like, I'm happy to make a pyreadline repo under the ipython organization and make you owner of it. There's little overhead in managing a separate org, but for a small project that is so closely tied to ipython, it may make sense to have it in the ipython org. Ultimately it's your call, just let me know if you want it. Cheers, f From asmeurer at gmail.com Wed Oct 19 02:53:29 2011 From: asmeurer at gmail.com (Aaron Meurer) Date: Wed, 19 Oct 2011 00:53:29 -0600 Subject: [IPython-dev] bzr to git migration In-Reply-To: References: <4E9DEA21.9010001@bostream.nu> Message-ID: On Tue, Oct 18, 2011 at 5:42 PM, Fernando Perez wrote: > Hi Jorgen, > > On Tue, Oct 18, 2011 at 2:05 PM, J?rgen Stenarson > wrote: >> I'm planning to move pyreadline over to github. Did you ever write up >> how you did the migration from launchpad to github? I'm wondering how to >> get all the branches into a single git repo properly. >> >> All bzr to git documents I've seen focus on a single bzr branch. > > I never wrote anything up for real, but I do have a copy of the script I used: > > > #!/bin/bash > # Convert the ipython repo into a git one. > set -e > > bzrepo=$HOME/ipython/repo > branches="master 0.8 0.9 0.10 0.10.1" > gitrepo=ipython-git > > rm -rf $gitrepo > mkdir $gitrepo > cd $gitrepo > > t0=$(date) > git init > for br in $branches > do > ? ?echo New branch from bzr: upstream-$br > ? ?git bzr add upstream-$br $bzrepo/$br > ? ?git bzr fetch upstream-$br > ? ?git co -b $br bzr/upstream-$br > done > git gc > git remote add mainline git at github.com:ipython/ipython.git > > echo "Started at: $t0" > echo "Ended at ?: $(date)" > > # > #git push origin master > > #### > > That might get you going with the code. ?My issues migration script is here: > > https://gist.github.com/835577 > > but github has changed its api since, so it will need some tweaking on > the upload part for the new api. > > I hope this is useful to get started... > > Glad to have you coming over to github! ?BTW, you're welcome to create > a separate organization for pyreadline, but if you'd like, I'm happy > to make a pyreadline repo under the ipython organization and make you > owner of it. ?There's little overhead in managing a separate org, but > for a small project that is so closely tied to ipython, it may make > sense to have it in the ipython org. ?Ultimately it's your call, just > let me know if you want it. > > Cheers, > > f I'd highly recommend putting it under an organization either way, rather than just under your personal account (you can have a fork there if you won't always push directly to the main repo). It looks much more professional to see something like github.com/pyreadline/pyreadline than github.com/someusername/pyreadline. It's also easier to remember :) Aaron Meurer From dave.hirschfeld at gmail.com Wed Oct 19 04:08:31 2011 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Wed, 19 Oct 2011 08:08:31 +0000 (UTC) Subject: [IPython-dev] multiline history References: <4E9DE7F6.5090103@bostream.nu> Message-ID: J?rgen Stenarson bostream.nu> writes: > > Hi, > > why have multiline history become the default in the terminal (master)? > > At least on windows this makes no sense since pyreadline can not edit > more than one line. > > /J?rgen > Hmm, that's slightly strange - I'm running the latest git checkout of IPython with 32bit Python 2.7.2 on Win7 x64 and the multiline edit seems to be working great for me (and is a major improvement from pre-0.11). When I scroll up through the history I get the multiline history coming up with the cursor at the top. I can then continue to scroll up through the history or can move down through the multiline block and change the contents. To re-execute I just go to the end of the multiline block and press enter. It might be because I've got access to most unix commands through the RTools and Git packages which are both on my path. Regards, Dave From dave.hirschfeld at gmail.com Wed Oct 19 04:15:34 2011 From: dave.hirschfeld at gmail.com (Dave Hirschfeld) Date: Wed, 19 Oct 2011 08:15:34 +0000 (UTC) Subject: [IPython-dev] multiline history References: <4E9DE7F6.5090103@bostream.nu> Message-ID: Dave Hirschfeld gmail.com> writes: > > J?rgen Stenarson bostream.nu> writes: > > > > > Hi, > > > > why have multiline history become the default in the terminal (master)? ^^^^^^^^^ > > > > At least on windows this makes no sense since pyreadline can not edit > > more than one line. > > > > /J?rgen > > > > Hmm, that's slightly strange - I'm running the latest git checkout of IPython > with 32bit Python 2.7.2 on Win7 x64 and the multiline edit seems to be working > great for me (and is a major improvement from pre-0.11). > Sorry for the noise, missed the terminal part - multiline works fine in the QtConsole for me but I haven't tried the terminal. -Dave From fperez.net at gmail.com Tue Oct 18 19:34:35 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Tue, 18 Oct 2011 16:34:35 -0700 Subject: [IPython-dev] multiline history In-Reply-To: References: <4E9DE7F6.5090103@bostream.nu> Message-ID: On Tue, Oct 18, 2011 at 2:01 PM, MinRK wrote: > Then we should probably make the default Bool(sys.platform != > 'win32'), rather than strictly True. Good idea, done and pushed. Sorry about that Jorgen :) Glad to have you keeping us in check for things that may inadvertently damage the user experience on win32, please keep letting us know when things like this happen, and we'll do our best to correct them right away. Cheers, f From fperez.net at gmail.com Wed Oct 19 11:21:30 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 19 Oct 2011 08:21:30 -0700 Subject: [IPython-dev] bzr to git migration In-Reply-To: References: <4E9DEA21.9010001@bostream.nu> Message-ID: On Tue, Oct 18, 2011 at 11:53 PM, Aaron Meurer wrote: > I'd highly recommend putting it under an organization either way, > rather than just under your personal account (you can have a fork > there if you won't always push directly to the main repo). ?It looks > much more professional to see something like > github.com/pyreadline/pyreadline than > github.com/someusername/pyreadline. ?It's also easier to remember :) +1, whether you go with a new pyreadline or under ipython, definitely do this. Cheers, f From fperez.net at gmail.com Wed Oct 19 11:20:49 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 19 Oct 2011 08:20:49 -0700 Subject: [IPython-dev] multiline history In-Reply-To: References: <4E9DE7F6.5090103@bostream.nu> Message-ID: On Wed, Oct 19, 2011 at 1:15 AM, Dave Hirschfeld wrote: > > Sorry for the noise, missed the terminal part - multiline works fine in the > QtConsole for me but I haven't tried the terminal. No worries. Indeed, just to clarify, all the above is about the terminal console. The qt console implements proper, full-blown multiline editing, and is indeed the right environment for that. What we're talking about is a bit of a hack we use to give a *limited measure* of multiline editing within the confines of what's possible in a single-line environment like a pure terminal. We do that by cramming a multiline block into a single line with embedded \n (newlines). It kinda-sorta works, but is obviously no substitute for real multline editing as provided by the qtconsole, the notebook, or a curses environment such as bpython. All of these have full 2-d control of the cursor, which is what you really want to edit multiple lines of text. Cheers, f From jorgen.stenarson at bostream.nu Wed Oct 19 13:11:50 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 19 Oct 2011 19:11:50 +0200 Subject: [IPython-dev] multiline history In-Reply-To: References: <4E9DE7F6.5090103@bostream.nu> Message-ID: <4E9F04D6.4080905@bostream.nu> Fernando Perez skrev 2011-10-19 01:34: > On Tue, Oct 18, 2011 at 2:01 PM, MinRK wrote: >> Then we should probably make the default Bool(sys.platform != >> 'win32'), rather than strictly True. > > Good idea, done and pushed. > > Sorry about that Jorgen :) Glad to have you keeping us in check for > things that may inadvertently damage the user experience on win32, > please keep letting us know when things like this happen, and we'll do > our best to correct them right away. I had to add some missing functions in the pyreadline API that the multiline patch uses. It looks like this will not be an issue with this change. /J?rgen From fperez.net at gmail.com Wed Oct 19 12:22:30 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 19 Oct 2011 09:22:30 -0700 Subject: [IPython-dev] Mostly off-line until next week Message-ID: Howdy, quick heads-up: I've been trying to quickly flush PRs as much as possible to get us in shape for 0.12, but I'll need to go mostly offline for a few days due to a work trip. I'll have email access, but will be fairly busy teaching until Monday. Cheers, f From jorgen.stenarson at bostream.nu Wed Oct 19 15:45:12 2011 From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=) Date: Wed, 19 Oct 2011 21:45:12 +0200 Subject: [IPython-dev] bzr to git migration In-Reply-To: References: <4E9DEA21.9010001@bostream.nu> Message-ID: <4E9F28C8.1060405@bostream.nu> Fernando Perez skrev 2011-10-19 17:21: > On Tue, Oct 18, 2011 at 11:53 PM, Aaron Meurer wrote: >> I'd highly recommend putting it under an organization either way, >> rather than just under your personal account (you can have a fork >> there if you won't always push directly to the main repo). It looks >> much more professional to see something like >> github.com/pyreadline/pyreadline than >> github.com/someusername/pyreadline. It's also easier to remember :) > > +1, whether you go with a new pyreadline or under ipython, definitely do this. > > Cheers, > > f It is now up on github.com/pyreadline/pyreadline /J?rgen From fperez.net at gmail.com Wed Oct 19 15:47:01 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 19 Oct 2011 12:47:01 -0700 Subject: [IPython-dev] bzr to git migration In-Reply-To: <4E9F28C8.1060405@bostream.nu> References: <4E9DEA21.9010001@bostream.nu> <4E9F28C8.1060405@bostream.nu> Message-ID: On Wed, Oct 19, 2011 at 12:45 PM, J?rgen Stenarson wrote: > It is now up on github.com/pyreadline/pyreadline Congratulations! Your first git commit should be to add a README :) Cheers, f From pablo.winant at gmail.com Thu Oct 20 15:35:43 2011 From: pablo.winant at gmail.com (Pablo Winant) Date: Thu, 20 Oct 2011 21:35:43 +0200 Subject: [IPython-dev] Remote connection to IPython kernel Message-ID: Hi all, I am trying to run an Ipython server on a distant machine with SSH (preferably the notebook) but I couldn't figure out how to do. So far, I have tried two approaches: - run a webnotebook on the server, listening on 127.0.0.1:8888, tunnel the port to my machine mymachine:9999 and access it with my local browser. With this setup, I can see a list of notebooks and can apparently edit them but no cell is evaluated. It looks very strange to me as the notebook works correctly if I use a browser running on the server. Is it a websocket problem (both browsers are recent enough) - try to adapt the follow the instructions given in the doc for the connection over ssh. However, when I run the kernel on the server, it doesn't print the list of ports anymore but gives the name of a json file. I understand this is the new system to store connection informations but I don't know how to use it over the network. I tried --existing --ssh=myserver but it doesn't work (yet ?). Is there currently a way to run a kernel over ssh ? I understand the target is moving quite fast and I am following the progress with great interest. Best regards, Pablo -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Thu Oct 20 16:06:03 2011 From: benjaminrk at gmail.com (MinRK) Date: Thu, 20 Oct 2011 13:06:03 -0700 Subject: [IPython-dev] Remote connection to IPython kernel In-Reply-To: References: Message-ID: On Thu, Oct 20, 2011 at 12:35, Pablo Winant wrote: > Hi all, > > I am trying to run an Ipython server on a distant machine with SSH > (preferably the notebook) but I couldn't figure out how to do. So far, I > have tried two approaches: > > - run a webnotebook on the server, listening on 127.0.0.1:8888, tunnel > the port to my machine mymachine:9999 and access it with my local browser. > With this setup, I can see a list of notebooks and can apparently edit them > but no cell is evaluated. It looks very strange to me as the notebook works > correctly if I use a browser running on the server. Is it a websocket > problem (both browsers are recent enough) > This, I think, is a bug. The websockets are created on the original addr ( 127.0.0.1:888) as resolved by the browser, so if you tunnel the connection to a different port, the websocket connections never establish. I can reproduce this failure tunnelling 8888 to 9999, and it works tunneling 8888 to 8888. > > - try to adapt the follow the instructions given in the doc for the > connection over ssh. However, when I run the kernel on the server, it > doesn't print the list of ports anymore but gives the name of a json file. I > understand this is the new system to store connection informations but I > don't know how to use it over the network. I tried --existing > --ssh=myserver but it doesn't work (yet ?). > The notebook does not handle kernels over ssh, only the qtconsole. > > Is there currently a way to run a kernel over ssh ? I understand the target > is moving quite fast and I am following the progress with great interest. > (assuming git master) If you start a kernel on one machine, it creates a connection file in the security directory. Send that file to the client from which you want to connect (or if you are already connected locally, view its contents with `%connect_info`, and use `ipython qtconsole --existing /path/to/kernel-foo.json --ssh myserver`. It is no longer possible to just copy/paste ports, because that had security issues. Files, at least, can be made private. -MinRK > Best regards, > > Pablo > > _______________________________________________ > 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: From fperez.net at gmail.com Fri Oct 21 11:21:55 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 21 Oct 2011 08:21:55 -0700 Subject: [IPython-dev] Remote connection to IPython kernel In-Reply-To: References: Message-ID: Hey Min, On Thu, Oct 20, 2011 at 1:06 PM, MinRK wrote: > This, I think, is a bug. ?The websockets are created on the original addr > (127.0.0.1:888) as resolved by the browser, so if you tunnel the connection > to a different port, the websocket connections never establish. ?I can > reproduce this failure tunnelling 8888 to 9999, and it works tunneling 8888 > to 8888. Do we have an issue tracking this, or was it fixed in your flurry of commits yesterday? Cheers, f From carl.input at gmail.com Fri Oct 21 12:30:34 2011 From: carl.input at gmail.com (Carl Smith) Date: Fri, 21 Oct 2011 17:30:34 +0100 Subject: [IPython-dev] Remote connection to IPython kernel In-Reply-To: References: Message-ID: I signed up to the mailing list hoping to help out, but I rarely understand a word of what you guys are going on about. It all sounds a bit like something from Neuromancer. '''...so if you tunnel the connection to a different port, the websocket connections never establish.''' Your work is hugely appreciated though, I can't work without IPython. Thank you. On 21 October 2011 16:21, Fernando Perez wrote: > Hey Min, > > On Thu, Oct 20, 2011 at 1:06 PM, MinRK wrote: >> This, I think, is a bug. ?The websockets are created on the original addr >> (127.0.0.1:888) as resolved by the browser, so if you tunnel the connection >> to a different port, the websocket connections never establish. ?I can >> reproduce this failure tunnelling 8888 to 9999, and it works tunneling 8888 >> to 8888. > > Do we have an issue tracking this, or was it fixed in your flurry of > commits yesterday? > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > From warren.weckesser at enthought.com Sat Oct 22 13:49:22 2011 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sat, 22 Oct 2011 12:49:22 -0500 Subject: [IPython-dev] Output of, e.g., type(a) Message-ID: Hi all, ipython is doing some magic with the output of 'type(a)' (using 0.11.rc1 in EPD): In [1]: a = 1 In [2]: type(a) Out[2]: int In [3]: str(type(a)) Out[3]: "" In [4]: repr(type(a)) Out[4]: "" The output in line 2 is nicer, but it makes it appear that the builtin 'type' behaves in a way that it does not. My attempts (possibly too brief) to find documentation or discussion of this feature have not been fruitful. Can anyone point me to the relevant docs, or mailing list discussions? Thanks. Warren -------------- next part -------------- An HTML attachment was scrubbed... URL: From warren.weckesser at enthought.com Sat Oct 22 13:58:57 2011 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sat, 22 Oct 2011 12:58:57 -0500 Subject: [IPython-dev] Output of, e.g., type(a) In-Reply-To: References: Message-ID: On Sat, Oct 22, 2011 at 12:49 PM, Warren Weckesser < warren.weckesser at enthought.com> wrote: > Hi all, > > ipython is doing some magic with the output of 'type(a)' (using 0.11.rc1 in > EPD): > > In [1]: a = 1 > > In [2]: type(a) > Out[2]: int > > In [3]: str(type(a)) > Out[3]: "" > > In [4]: repr(type(a)) > Out[4]: "" > > The output in line 2 is nicer, but it makes it appear that the builtin > 'type' behaves in a way that it does not. My attempts (possibly too brief) > to find documentation or discussion of this feature have not been fruitful. > Can anyone point me to the relevant docs, or mailing list discussions? > Thanks. > Of course, three minutes after sending that email, I find the '%pprint' command for toggling pretty-printing. That's enough to answer my question. Warren > > Warren > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Sat Oct 22 14:22:06 2011 From: benjaminrk at gmail.com (MinRK) Date: Sat, 22 Oct 2011 11:22:06 -0700 Subject: [IPython-dev] Output of, e.g., type(a) In-Reply-To: References: Message-ID: On Sat, Oct 22, 2011 at 10:49, Warren Weckesser < warren.weckesser at enthought.com> wrote: > Hi all, > > ipython is doing some magic with the output of 'type(a)' (using 0.11.rc1 in > EPD): > > In [1]: a = 1 > > In [2]: type(a) > Out[2]: int > > In [3]: str(type(a)) > Out[3]: "" > > In [4]: repr(type(a)) > Out[4]: "" > > The output in line 2 is nicer, but it makes it appear that the builtin > 'type' behaves in a way that it does not. My attempts (possibly too brief) > to find documentation or discussion of this feature have not been fruitful. > Can anyone point me to the relevant docs, or mailing list discussions? > Thanks. > To turn of *all* pretty printing, use %pprint to toggle (as I now see you have discovered) output formatting is all handled by the new display system, which is unfortunately not very well documented, but is implemented primarily in IPython.core.formatters . But here's the gist: IPython has a collection of various formatters for various representations of objects (svg, png, html, latex, plaintext, etc.). Terminal IPython obviously only uses plaintext. To get the relevant formatter in the terminal: formatter = get_ipython().display_formatter.formatters['text/plain'] And this has a dictionary by *type* of functions to call for given types: formatter.type_printers And you can register new type printers with: formatter.for_type(type, myfunc) Where myfunc needs to obey the `(obj,p,cycle)` pattern in IPython.lib.pretty . If you don't like a particular type's pretty output, you can force it to fallback on repr by just deleting the relevant key from the type_printers dict, or explicitly registering a new printer that writes repr: formatter.for_type(type, lambda obj, p, cycle: p.text(repr(obj)) -MinRK > Warren > > > _______________________________________________ > 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: From benjaminrk at gmail.com Sat Oct 22 14:23:40 2011 From: benjaminrk at gmail.com (MinRK) Date: Sat, 22 Oct 2011 11:23:40 -0700 Subject: [IPython-dev] Output of, e.g., type(a) In-Reply-To: References: Message-ID: I should note that the best documentation we do have is in the display_protocol notebook in docs/examples/notebooks. On Sat, Oct 22, 2011 at 11:22, MinRK wrote: > > > On Sat, Oct 22, 2011 at 10:49, Warren Weckesser < > warren.weckesser at enthought.com> wrote: > >> Hi all, >> >> ipython is doing some magic with the output of 'type(a)' (using 0.11.rc1 >> in EPD): >> >> In [1]: a = 1 >> >> In [2]: type(a) >> Out[2]: int >> >> In [3]: str(type(a)) >> Out[3]: "" >> >> In [4]: repr(type(a)) >> Out[4]: "" >> >> The output in line 2 is nicer, but it makes it appear that the builtin >> 'type' behaves in a way that it does not. My attempts (possibly too brief) >> to find documentation or discussion of this feature have not been fruitful. >> Can anyone point me to the relevant docs, or mailing list discussions? >> Thanks. >> > > To turn of *all* pretty printing, use %pprint to toggle (as I now see you > have discovered) > > output formatting is all handled by the new display system, which is > unfortunately not very well documented, but is implemented primarily in > IPython.core.formatters > . > > But here's the gist: > > IPython has a collection of various formatters for various representations > of objects (svg, png, html, latex, plaintext, etc.). Terminal IPython > obviously only uses plaintext. To get the relevant formatter in the > terminal: > > formatter = get_ipython().display_formatter.formatters['text/plain'] > > And this has a dictionary by *type* of functions to call for given types: > > formatter.type_printers > > And you can register new type printers with: > > formatter.for_type(type, myfunc) > > Where myfunc needs to obey the `(obj,p,cycle)` pattern in > IPython.lib.pretty > . > > If you don't like a particular type's pretty output, you can force it to > fallback on repr by just deleting the relevant key from the type_printers > dict, or explicitly registering a new printer that writes repr: > > formatter.for_type(type, lambda obj, p, cycle: p.text(repr(obj)) > > -MinRK > > >> Warren >> >> >> _______________________________________________ >> 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: From robert.kern at gmail.com Sat Oct 22 14:36:56 2011 From: robert.kern at gmail.com (Robert Kern) Date: Sat, 22 Oct 2011 19:36:56 +0100 Subject: [IPython-dev] Output of, e.g., type(a) In-Reply-To: References: Message-ID: On 10/22/11 6:58 PM, Warren Weckesser wrote: > > > On Sat, Oct 22, 2011 at 12:49 PM, Warren Weckesser > > wrote: > > Hi all, > > ipython is doing some magic with the output of 'type(a)' (using 0.11.rc1 in > EPD): > > In [1]: a = 1 > > In [2]: type(a) > Out[2]: int > > In [3]: str(type(a)) > Out[3]: "" > > In [4]: repr(type(a)) > Out[4]: "" > > The output in line 2 is nicer, but it makes it appear that the builtin > 'type' behaves in a way that it does not. My attempts (possibly too brief) > to find documentation or discussion of this feature have not been fruitful. > Can anyone point me to the relevant docs, or mailing list discussions? Thanks. > > > > Of course, three minutes after sending that email, I find the '%pprint' command > for toggling pretty-printing. That's enough to answer my question. The default pretty-printers are defined starting here: https://github.com/ipython/ipython/blob/master/IPython/lib/pretty.py#L463 These were the defaults for the upstream, third-party pretty.py (with a just a bug-fix for the re objects, IIRC). I happen to like this one, but if there is a consensus that it is more confusing than pretty, I'm happy to consider changing it. -- 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 warren.weckesser at enthought.com Sat Oct 22 15:20:40 2011 From: warren.weckesser at enthought.com (Warren Weckesser) Date: Sat, 22 Oct 2011 14:20:40 -0500 Subject: [IPython-dev] Output of, e.g., type(a) In-Reply-To: References: Message-ID: On Sat, Oct 22, 2011 at 1:36 PM, Robert Kern wrote: > On 10/22/11 6:58 PM, Warren Weckesser wrote: > > > > > > On Sat, Oct 22, 2011 at 12:49 PM, Warren Weckesser > > > > wrote: > > > > Hi all, > > > > ipython is doing some magic with the output of 'type(a)' (using > 0.11.rc1 in > > EPD): > > > > In [1]: a = 1 > > > > In [2]: type(a) > > Out[2]: int > > > > In [3]: str(type(a)) > > Out[3]: "" > > > > In [4]: repr(type(a)) > > Out[4]: "" > > > > The output in line 2 is nicer, but it makes it appear that the > builtin > > 'type' behaves in a way that it does not. My attempts (possibly too > brief) > > to find documentation or discussion of this feature have not been > fruitful. > > Can anyone point me to the relevant docs, or mailing list > discussions? Thanks. > > > > > > > > Of course, three minutes after sending that email, I find the '%pprint' > command > > for toggling pretty-printing. That's enough to answer my question. > > The default pretty-printers are defined starting here: > > > https://github.com/ipython/ipython/blob/master/IPython/lib/pretty.py#L463 > > These were the defaults for the upstream, third-party pretty.py (with a > just a > bug-fix for the re objects, IIRC). I happen to like this one, but if there > is a > consensus that it is more confusing than pretty, I'm happy to consider > changing it. > It's fine by me, now that I know it is just one of the pretty-printing hooks. Warren > -- > 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: From satra at mit.edu Sun Oct 23 20:31:50 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Sun, 23 Oct 2011 20:31:50 -0400 Subject: [IPython-dev] notebook.keyfile Message-ID: hi, what does the notebook.keyfile do? cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjaminrk at gmail.com Sun Oct 23 20:44:36 2011 From: benjaminrk at gmail.com (MinRK) Date: Sun, 23 Oct 2011 17:44:36 -0700 Subject: [IPython-dev] notebook.keyfile In-Reply-To: References: Message-ID: I think it just gets passed on to ssl.wrap_socket. It's only necessary when the certificate file itself does not also contain the key. -MinRK On Sun, Oct 23, 2011 at 17:31, Satrajit Ghosh wrote: > hi, > > what does the notebook.keyfile do? > > cheers, > > satra > > > _______________________________________________ > 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: From guillaume.pichard at sogeti.com Mon Oct 24 07:51:17 2011 From: guillaume.pichard at sogeti.com (Guillaume Pichard) Date: Mon, 24 Oct 2011 13:51:17 +0200 Subject: [IPython-dev] How IPython achieve embedding of matplotlib figure ? Message-ID: <20111024135117.5u4zdzmkg0kccww4@mail.sogeti.com> Hello, I would like to replicate the Pylab feature from IPython (embedded matplotlib figures) in my own application. I'm using Python embedded in C++ using the Python C-API. What I would like to know is how IPython achieve this feature and how can I replicate it with my own Python code ? I saw that there are using displayhook, but how can IPython catch output from matplotlib functions ? I would be greatful if you could give me some pointers on how to do this feature. Regards, Guillaume. From zachary.pincus at yale.edu Mon Oct 24 13:29:12 2011 From: zachary.pincus at yale.edu (Zachary Pincus) Date: Mon, 24 Oct 2011 13:29:12 -0400 Subject: [IPython-dev] ipython -i not default? Message-ID: <5A24009A-9B6C-4A5E-B959-0E216CF93DD0@yale.edu> Hi all, I recently updated to 0.12.dev, and noticed a minor change in that running code as "ipython script.py" by default does not leave one in interactive mode -- now you need to run as "ipython -i script.py". Is that change intentional/permanent? (Maybe to do non-interactive cluster-computing usage models?) Thanks, Zach From benjaminrk at gmail.com Mon Oct 24 13:41:46 2011 From: benjaminrk at gmail.com (MinRK) Date: Mon, 24 Oct 2011 10:41:46 -0700 Subject: [IPython-dev] ipython -i not default? In-Reply-To: <5A24009A-9B6C-4A5E-B959-0E216CF93DD0@yale.edu> References: <5A24009A-9B6C-4A5E-B959-0E216CF93DD0@yale.edu> Message-ID: On Mon, Oct 24, 2011 at 10:29, Zachary Pincus wrote: > Hi all, > > I recently updated to 0.12.dev, and noticed a minor change in that running > code as "ipython script.py" by default does not leave one in interactive > mode -- now you need to run as "ipython -i script.py". Is that change > intentional/permanent? (Maybe to do non-interactive cluster-computing usage > models?) > Yes, this is intentional. I think the goal was to match Python itself. > > Thanks, > Zach > _______________________________________________ > 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: From takowl at gmail.com Tue Oct 25 20:38:06 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 26 Oct 2011 01:38:06 +0100 Subject: [IPython-dev] Integrating pandas into pylab Message-ID: I don't know if this is the right forum for this, but to kick off some discussion: I see Pylab as a unfied interface for scientific programming in Python (as in http://www.scipy.org/PyLab), not just as a matplotlib API. I think Wes' pandas package is becoming indispensable for this sort of thing - in particular the DataFrame class. I won't belabour its advantages, but I believe it's the best way to handle data in a 'table' form, which is ubiquitous in my field. So I'd like to see it integrated into (broad sense) Pylab - in particular, I think the names read_csv, read_table and DataFrame should be available without another import. Another possible target is the related scikits.statsmodels package ( http://pypi.python.org/pypi/scikits.statsmodels/), but I'm less familiar with that. I think there's also some broader questions - pylab is a submodule of matplotlib, a command line flag for IPython, an idea on the scipy wiki, and a seemingly unmaintained "place to release Python tools" on Sourceforge. Who should actually be in the driving seat? Do we need a new name for the Pylab I'm talking about, just to avoid confusion? I've also heard people talk about the 'SciPy stack', although that name seems a bit odd, as I have little need for the scipy package itself. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ellisonbg at gmail.com Tue Oct 25 21:53:18 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Tue, 25 Oct 2011 18:53:18 -0700 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: One on hand, one of Python's core philosophies is that namespaces are great things and that we should use more of them. One the other hand, there is no doubt that for new users, the numpy, scipy and matplotlib namespaces are a bit overwhelming. I was talking to a faculty member in the physics department just today. I got him running the IPython notebook and he loves it. He has used Python before, but he remarked how horribly confusing it is to try and figure out where something is located in the numpy/scipy/matplotlib hierarchies. The somewhat fuzzy line between numpy and scipy doesn't help and the existing pylab namespace in matplotlib partially helps, but partially hurts as it is by no means complete. Thinking off the top of my head... * pylab should be a standalone project.that serves as a top-level namespace for numpy/scipy/matplotlib. * It should be removed from matplotlib. * The --pylab flag in IPython should do a "from pylab import *" * The community should create documentation for pylab that should i) be in addition to the existing documentation ii) focused on new users and iii) refer to the existing docs for further details. The last thing we want is for users to have to try to figure out that pylab.ndarray is actually numpy.ndarray and then look the docs up for that. * The documentation should be created in a manner that will allow us to create IPython notebooks for each function/class that documents its usage and shows examples. With the upcoming ReST cells in the IPython notebook this should not be difficult. * IPython should have an integrated, pretty and searchable way for users to browse the pylab documentation. Mathematica's documentation is a worthy target in this respect. * The pylab namespace should be big. It should include basically everything you get in Mathematica or Matlab. The only thing we would have trouble including would be sympy, as it defines symbolic versions of many of the functions in numpy. I don't see a way around that unless we wrote functions that were smart that could call numpy or sympy's version by inspecting their inputs. But sympy is a very large project so I would probably vote to keep sympy out of the pylab namespace and have pylab focus on numerical rather than symbolic things. * At least starting out, pylab should focus only on numpy/scipy/matplotlib and over time should only include tools that are used community wide and recognized as "standard" While I love Pandas, I don't think it has risen to that level yet. * I think IPython would be a fantastic place to host this. Ready, set, go... Cheers, Brian On Tue, Oct 25, 2011 at 5:38 PM, Thomas Kluyver wrote: > I don't know if this is the right forum for this, but to kick off some > discussion: > > I see Pylab as a unfied interface for scientific programming in Python (as > in http://www.scipy.org/PyLab), not just as a matplotlib API. I think Wes' > pandas package is becoming indispensable for this sort of thing? - in > particular the DataFrame class. I won't belabour its advantages, but I > believe it's the best way to handle data in a 'table' form, which is > ubiquitous in my field. So I'd like to see it integrated into (broad sense) > Pylab - in particular, I think the names read_csv, read_table and DataFrame > should be available without another import. Another possible target is the > related scikits.statsmodels package > (http://pypi.python.org/pypi/scikits.statsmodels/), but I'm less familiar > with that. > > I think there's also some broader questions - pylab is a submodule of > matplotlib, a command line flag for IPython, an idea on the scipy wiki, and > a seemingly unmaintained "place to release Python tools" on Sourceforge. Who > should actually be in the driving seat? Do we need a new name for the Pylab > I'm talking about, just to avoid confusion? I've also heard people talk > about the 'SciPy stack', although that name seems a bit odd, as I have > little need for the scipy package itself. > > Thanks, > Thomas > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From takowl at gmail.com Wed Oct 26 06:10:00 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 26 Oct 2011 11:10:00 +0100 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: I think I pretty much agree with what you're saying, vis-a-vis it being a standalone project, with good documentation, bringing in a wide range of names from different packages. I don't think it's a problem, though, to bring in something like pandas that isn't yet so widely used. It's a classic newcomer trap: you know you need this 'table' functionality (especially if you've used R, where it's built in), but how do you search for it? I spent a few months using my own (crap) implementation before I discovered other people had already done it much better. To my mind, this functionality just needs to be there, and if there's not yet a standard package to do it, we should pick the best available and promote it as the new standard. I'll get in touch with the matplotlib guys, and look at setting up a repository for standalone pylab. Thanks, Thomas > * It should be removed from matplotlib. > * The --pylab flag in IPython should do a "from pylab import *" > * The community should create documentation for pylab that should i) > be in addition to the existing documentation ii) focused on new users > and iii) refer to the existing docs for further details. The last > thing we want is for users to have to try to figure out that > pylab.ndarray is actually numpy.ndarray and then look the docs up for > that. > * The documentation should be created in a manner that will allow us > to create IPython notebooks for each function/class that documents its > usage and shows examples. With the upcoming ReST cells in the IPython > notebook this should not be difficult. > * IPython should have an integrated, pretty and searchable way for > users to browse the pylab documentation. Mathematica's documentation > is a worthy target in this respect. > * The pylab namespace should be big. It should include basically > everything you get in Mathematica or Matlab. The only thing we would > have trouble including would be sympy, as it defines symbolic versions > of many of the functions in numpy. I don't see a way around that > unless we wrote functions that were smart that could call numpy or > sympy's version by inspecting their inputs. But sympy is a very large > project so I would probably vote to keep sympy out of the pylab > namespace and have pylab focus on numerical rather than symbolic > things. > * At least starting out, pylab should focus only on > numpy/scipy/matplotlib and over time should only include tools that > are used community wide and recognized as "standard" While I love > Pandas, I don't think it has risen to that level yet. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdh2358 at gmail.com Wed Oct 26 09:25:02 2011 From: jdh2358 at gmail.com (John Hunter) Date: Wed, 26 Oct 2011 08:25:02 -0500 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: I'm in agreement with most of the ideas here. As the author of pylab, I've caught a lot of flack for dumping everything into a single namespace as it is unpythonic, and in classes Fernando and I have been pretty careful of late to use namespaces, and mpl facilitates this by factoring the plotting part of pylab into pyplot. It's a little more confusing for students at first, but ultimately it helps the students to know where things come from when they move from the interactive environment to scripting. That said, the major problem is that the current organization of the major packages is not logical or intuitive. numpy has arrays, algorithms and IO, scipy has algorithms and IO, matplotlib has plotting and algorithms and IO, pandas has datastructures, IO, algorithms and plotting (albeit all organized around the dataframe). And so on. I think there is room for a namespace package that integrates across these and makes it more intuitive. The proper top level namespaces are something like: array (or statstructures more generally), algo, plot, io. In this model, you would pull the relevant components from numpy, scipy, mpl, pandas, scikits, ETS, etc into the relevant namespaces. Making everything work together would be exceedingly tricky... Note this is pretty much what scipy used to be: at some point they jettisoned plotting and focused on the algo part. It's also a hard and big project and may not attract much usage. If someone pursues this, I would not call it pylab, as this will just foster confusion. Forgetting about the big problem, and focusing on Thomas original and much more limited question of getting pandas into pylab, there are three easy solutions: * matplotlib.pylab can conditionally try/import * from pandas. This is the path of least resistance, and several of our developers may object because they want less, not more, namespace dumping. Nonetheless, it can probably be done. * ipython can have it's own configurable "pylab" import which does an import * from matplotlib.pylab and anything else you or the users want by default. The downside of configurable is that it makes it easier to share histories, etc. * pandas could be incorporated into numpy. This is my favorite solution since it would get pandas onto as many desktops as soon as possible and we could all write code that relies on it being there. Obviously pandas is on a much faster release schedule than numpy right now, and should live on its own, but in six months time or so when Wes is ready to take a breather, it would be great to see pandas incorporated. Then matplotlib.pylab would get it by default. >> * It should be removed from matplotlib. This is highly unlikely. We are loathe to break backwards compatibility, and this would be *major* breakage. It's easier and less confusing to simply use a different name. JDH From takowl at gmail.com Wed Oct 26 09:43:10 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 26 Oct 2011 14:43:10 +0100 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: Thanks John, On 26 October 2011 14:25, John Hunter wrote: > If someone pursues this, I would not call it pylab, as this > will just foster confusion. > I kind of agree with this, although it's a bit unfortunate, because I think people already see pylab as a unified interface to scientific Python stuff. I guess we should think about what else it might be called. Do we want the name to refer to Python (as Pylab, Scipy, etc. do), or to sound more generic (like matplotlib)? There's also a case to be made for a distinctive but non-descriptive name (like Pandas, Python, R, Sage, and countless others). Suggestions on postcards, please... Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From hans_meine at gmx.net Wed Oct 26 11:00:52 2011 From: hans_meine at gmx.net (Hans Meine) Date: Wed, 26 Oct 2011 17:00:52 +0200 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: <201110261700.52466.hans_meine@gmx.net> Am Mittwoch, 26. Oktober 2011, 15:43:10 schrieb Thomas Kluyver: > On 26 October 2011 14:25, John Hunter wrote: > > If someone pursues this, I would not call it pylab, as this > > will just foster confusion. > > I kind of agree with this, although it's a bit unfortunate, because I think > people already see pylab as a unified interface to scientific Python stuff. Really?? I always saw pylab as a MatLab-oriented, high-level frontend for MPLs plotting capabilities, no more, no less. OTOH, having numpy stuff loaded with "ipython --pylab" made sense to me and was welcomed convenience, but I would never rely on numpy stuff being in the pylab namespace. Of course, I only speak for a part of the audience. For me, ipython is the unifying project for interactive work, and I can live fine with the current namespaces in scripts I write (of course, never [ab]using 'from foo import *', which would render pyflakes useless anyway). Have a nice day, Hans From ellisonbg at gmail.com Wed Oct 26 13:03:01 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 26 Oct 2011 10:03:01 -0700 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: On Wed, Oct 26, 2011 at 6:25 AM, John Hunter wrote: > I'm in agreement with most of the ideas here. ?As the author of pylab, > I've caught a lot of flack for dumping everything into a single > namespace as it is unpythonic, and in classes Fernando and I have been > pretty careful of late to use namespaces, and mpl facilitates this by > factoring the plotting part of pylab into pyplot. ?It's a little more > confusing for students at first, but ultimately it helps the students > to know where things come from when they move from the interactive > environment to scripting. > > That said, the major problem is that the current organization of the > major packages is not logical or intuitive. ?numpy has arrays, > algorithms and IO, scipy has algorithms and IO, matplotlib has > plotting and algorithms and IO, pandas has datastructures, IO, > algorithms and plotting (albeit all organized around the dataframe). > And so on. ?I think there is room for a namespace package that > integrates across these and makes it more intuitive. ?The proper top > level namespaces are something like: array (or statstructures more > generally), algo, plot, io. ?In this model, you would pull the > relevant components from numpy, scipy, mpl, pandas, scikits, ETS, etc > into the relevant namespaces. I would not want to make the new namespace nested - it should be flat like the current pylab is. I think the main point here is that we are competing with Matlab, Mathematica, etc. which all have completely flat namespaces. Not that we want to copy everything these packages do, but for new users, non-technical folks, undergraduates the entire idea of namespaces is confusing. This problem (for these users) is namspaces themselves, not just that the existing ones are confusing. > ?Making everything work together would > be exceedingly tricky... ?Note this is pretty much what scipy used to > be: at some point they jettisoned plotting and focused on the algo > part. ?It's also a hard and big project and may not attract much > usage. What are the main areas that would make it tricky? I don't have enough experience with numpy/scipy/matplotlib to know this. > ?If someone pursues this, I would not call it pylab, as this > will just foster confusion. I understand why you would not want to separate pylab from matplotlib, but I don't see that creating yet another namespace would help the problem. Confusion would only increase as people would continually ask "what's the difference between pylab and *?" > Forgetting about the big problem, and focusing on Thomas original and > much more limited question of getting pandas into pylab, there are > three easy solutions: > > * matplotlib.pylab can conditionally try/import * from pandas. ?This > is the path of least resistance, and several of our developers may > object because they want less, not more, namespace dumping. > Nonetheless, it can probably be done. > > * ipython can have it's own configurable "pylab" import which does an > import * from matplotlib.pylab and anything else you or the users want > by default. ?The downside of configurable is that it makes it easier > to share histories, etc. > > * pandas could be incorporated into numpy. ?This is my favorite > solution since it would get pandas onto as many desktops as soon as > possible and we could all write code that relies on it being there. > Obviously pandas is on a much faster release schedule than numpy right > now, and should live on its own, but in six months time or so when Wes > is ready to take a breather, it would be great to see pandas > incorporated. ?Then matplotlib.pylab would get it by default. > > >>> * It should be removed from matplotlib. > > This is highly unlikely. ?We are loathe to break backwards > compatibility, and this would be *major* breakage. ?It's easier and > less confusing to simply use a different name. This makes sense. Given this, I propose that the existing pylab module in matplotlib be developed into a more general namespace for this type of thing. In that process care can be taken to not break backwards compat. I think this is logical as pylab already does import * from a good number of things. Cheers, Brian > JDH > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From satra at mit.edu Wed Oct 26 13:36:30 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Wed, 26 Oct 2011 13:36:30 -0400 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: hi all, > > That said, the major problem is that the current organization of the > > major packages is not logical or intuitive. numpy has arrays, > > algorithms and IO, scipy has algorithms and IO, matplotlib has > > plotting and algorithms and IO, pandas has datastructures, IO, > > algorithms and plotting (albeit all organized around the dataframe). > > And so on. I think there is room for a namespace package that > > integrates across these and makes it more intuitive. The proper top > > level namespaces are something like: array (or statstructures more > > generally), algo, plot, io. In this model, you would pull the > > relevant components from numpy, scipy, mpl, pandas, scikits, ETS, etc > > into the relevant namespaces. > > I would not want to make the new namespace nested - it should be flat > like the current pylab is. I think the main point here is that we are > competing with Matlab, Mathematica, etc. which all have completely > flat namespaces. Not that we want to copy everything these packages > do, but for new users, non-technical folks, undergraduates the entire > idea of namespaces is confusing. This problem (for these users) is > namspaces themselves, not just that the existing ones are confusing. > i don't think what confuses new users is whether the namespace is flat or nested, but where to get the functionality that they are looking for and if in the nested namespace there are multiple implementations of the functionality, which one to use. even in matlab, which has a flat namespace, users need to do 'lookfor' to search for available functions. and in cases where additional toolboxes are installed which may have the same function filename, it's a nightmare. so i think the notion of namespace is crucial in the scientific computing world and the import statement is not the biggest block that new users face. most often, it is: 'which function solves my problem?'. for example, *once* you know 'plot', 'hist' and 'imshow' are in pyplot, it's really trivial for most users to type: --- import matplotlib.pyplot as plt or from matplotlib.pyplot import plot, hist, imshow --- i agree with john that having namespaces like: stats io plot linalg might actually be useful in categorizing and looking for functionality, which i believe was the one of the intents of namespaces in the first place. if the goal is to provide matlab compatibility and assume that function names and their calling structures are identical, then the flat namespace helps. however, beyond some routines, this is impossible to maintain. i think scientific computing in python would do very well if some mechanism like 'lookfor' provided users (especially new users) a good way to find functionality. i don't think the flat namespace solves this problem. cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From takowl at gmail.com Wed Oct 26 14:38:05 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Wed, 26 Oct 2011 19:38:05 +0100 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: > > > This is highly unlikely. We are loathe to break backwards > > compatibility, and this would be *major* breakage. It's easier and > > less confusing to simply use a different name. > > This makes sense. Given this, I propose that the existing pylab > module in matplotlib be developed into a more general namespace for > this type of thing. In that process care can be taken to not break > backwards compat. I think this is logical as pylab already does > import * from a good number of things. > I don't think matplotlib is really a natural home for a combined interface to a variety of libraries. It seems more natural to maintain it as a distinct thing. Also, as the discussion is showing, we might not want to keep the same structure as mpl.pylab - in which case it will need to be separate so we don't break backwards compatibility. And then I think a different name is best to avoid confusion resulting from there being two pylabs. With regards to the flat vs. structured namespace debate, I wonder if there is a middle ground - exposing some key functions (like plot()) in the flat namespace, and having others in (sensibly named) namespaces. However, then we need to somehow decide which functions merit being directly available. I've not used matlab or mathematica, but compared to R, we have the advantage of methods, which are relatively easy to discover via tab completion. For instance, I added Pandas' isnull()/notnull() functions as methods to Series objects (columns), so there's less need to expose those functions in a flat namespace. Given that we're going to be importing the major namespaces, I don't think newcomers will find it too difficult to type "io.read_csv('myfile.csv')", versus the equivalent without io. The key, as Satrajit says, is that there's some way to find out about these functions. I don't think this necessarily needs to be in-program: searchable, readable online docs in a single location would be a good start. In fact, I think 99% of the work for what I'm proposing is documentation - doing the namespace(s) will be relatively easy once we decide on the structure. Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark.voorhies at ucsf.edu Wed Oct 26 14:06:36 2011 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Wed, 26 Oct 2011 11:06:36 -0700 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: <201110261106.37056.mark.voorhies@ucsf.edu> On Wednesday, October 26, 2011 10:36:30 am Satrajit Ghosh wrote: > i think scientific computing in python would do very well if some mechanism > like 'lookfor' provided users (especially new users) a good way to find > functionality. i don't think the flat namespace solves this problem. > > cheers, > > satra > pydoc.ModuleScanner can do keyword searches of modules. As is, it's a bit slow, searches only synopsis lines, and is a bit fragile (e.g., raises an uncaught exception when scanning one of the modules from the Ubuntu pymol package), but it might be a good starting point. Or perhaps it would be easier to hook into the module scanning that IPython does for tab-completion of import? I use help.search() in R for exactly this purpose, so I certainly think it would be useful. (For matplotlib and networkx, I currently search through pydoc in firefox or grep the sources). --Mark From mark.voorhies at ucsf.edu Wed Oct 26 16:33:10 2011 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Wed, 26 Oct 2011 13:33:10 -0700 Subject: [IPython-dev] %page help(x) In-Reply-To: References: <201110131705.56624.mark.voorhies@ucsf.edu> <201110131859.37181.mark.voorhies@ucsf.edu> Message-ID: <201110261333.10798.mark.voorhies@ucsf.edu> On Thursday, October 13, 2011 07:36:39 pm Fernando Perez wrote: > On Thu, Oct 13, 2011 at 6:59 PM, Mark Voorhies wrote: > > P.S.: If I get this working, is it worth a pull request, or is this the sort of thing > > that should live in personal magic? > > I never use help myself, so I'd never really cared. But I now see > that in the qtconsole, help() is kind of useless, because it doesn't > know how to page. It's going to be equally useless in the notebook. > > So perhaps the right solution is to build our own replacement for the > built-in help(), that is smarter about the clients it's in and that in > the long run could also format doctrings into html with TeX, etc... > > I don't know how far you want to take it, but there's definitely > potential here to improve the situation regarding interactive help. > I'd suggest you play with it locally first, and if you think you do > want to build something more robust/general, then we'd definitely be > happy to take a PR for it. > > Cheers, > > f > Sounds good. For the impatient, here's a naive working version: def magic_help(self, s): """Retrieve the pydoc help for an object and display it through a pager. """ info = self._ofind(s) if info['found']: import pydoc page.page(pydoc.plain(pydoc.render_doc(info["obj"]))) else: print 'Object `%s` not found' % s --Mark From ellisonbg at gmail.com Wed Oct 26 16:36:01 2011 From: ellisonbg at gmail.com (Brian Granger) Date: Wed, 26 Oct 2011 13:36:01 -0700 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: Satra, On Wed, Oct 26, 2011 at 10:36 AM, Satrajit Ghosh wrote: > hi all, > >> >> > That said, the major problem is that the current organization of the >> > major packages is not logical or intuitive. ?numpy has arrays, >> > algorithms and IO, scipy has algorithms and IO, matplotlib has >> > plotting and algorithms and IO, pandas has datastructures, IO, >> > algorithms and plotting (albeit all organized around the dataframe). >> > And so on. ?I think there is room for a namespace package that >> > integrates across these and makes it more intuitive. ?The proper top >> > level namespaces are something like: array (or statstructures more >> > generally), algo, plot, io. ?In this model, you would pull the >> > relevant components from numpy, scipy, mpl, pandas, scikits, ETS, etc >> > into the relevant namespaces. >> >> I would not want to make the new namespace nested - it should be flat >> like the current pylab is. ?I think the main point here is that we are >> competing with Matlab, Mathematica, etc. which all have completely >> flat namespaces. ?Not that we want to copy everything these packages >> do, but for new users, non-technical folks, undergraduates the entire >> idea of namespaces is confusing. ?This problem (for these users) is >> namspaces themselves, not just that the existing ones are confusing. > > i don't think what confuses new users is whether the namespace is flat or > nested, but where to get the functionality that they are looking for and if > in the nested namespace there are multiple implementations of the > functionality, which one to use. I think we are talking about different sets of users: * I am referring to *complete newbies* that have 0 programming experience, barely know what a for loop is and are struggling to figure out how to index a numpy array. Examples would be your typical 1st-3rd year undergraduate student in engineering, physics, chemistry, biology, etc. I spend my days surrounded by these type of users (I teach undergraduate university physics) and it is completely overwhelming for them to learn a new programming language along with a set of libraries for numerical work. Asking them to track which functions come from which namespaces and get the imports right for each of them each time they write a new script is simply too great a cognitive load. These users need a flat namespace they can import * from and, as you point out, a convenient way of searching that namespace to find what they need. * You are picturing users that have extensive technical backgrounds, likely grad students, postdocs or beyond who are new to Python or numpy/scipy/matplotlib but not new to programming, text editors, command prompt, etc. For these users I completely agree with your analysis. Asking these users to understand and manage namespaces is not much of a problem and it is mostly an issue of helping them to find what they are looking for. > even in matlab, which has a flat namespace, users need to do 'lookfor' to > search for available functions. and in cases where additional toolboxes are > installed which may have the same function filename, it's a nightmare. > so i think the notion of namespace is crucial in the scientific computing > world and the import statement is not the biggest block that new users face. > most often, it is: 'which function solves my problem?'. for example,?*once* > you know 'plot', 'hist' and 'imshow' are in pyplot, it's really trivial for > most users to type: > --- > import matplotlib.pyplot as plt > or > from matplotlib.pyplot import plot, hist, imshow > --- For your "advanced" new users I agree, but surely not for the class of new users I am thinking about. > i agree with john that having namespaces like: > stats > io > plot > linalg > might actually be useful in categorizing and looking for functionality, > which i believe was the one of the intents of namespaces in the first place. I agree. > if the goal is to provide matlab compatibility and assume that function > names and their calling structures are identical, then the flat namespace > helps. however, beyond some routines, this is impossible to maintain. > i think scientific computing in python would do very well if some mechanism > like 'lookfor' provided users (especially new users) a good way to find > functionality. i don't think the flat namespace solves this problem. I agree that the lookfor functionality is needed regardless of what happens with the namespaces and could be implemented equally well for flat or nested namespaces. In summary, there are three mostly-orthogonal issues: 1) The need for the flat namespace for truly beginning users. 2) The need to consolidate/organize the existing messy and overlapping namespaces of numpy/scipy/matplotlib. 3) The need for lookfor type functionality for all users. It is possible that 1 and 2 could be solved in a single package. There could be well organized io, linalg, algo, etc submodules and an "all" module that imports everything for users that need/want it. Cheers, Brian > cheers, > satra > > > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev > > -- Brian E. Granger Cal Poly State University, San Luis Obispo bgranger at calpoly.edu and ellisonbg at gmail.com From fperez.net at gmail.com Wed Oct 26 20:24:15 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Wed, 26 Oct 2011 17:24:15 -0700 Subject: [IPython-dev] %page help(x) In-Reply-To: <201110261333.10798.mark.voorhies@ucsf.edu> References: <201110131705.56624.mark.voorhies@ucsf.edu> <201110131859.37181.mark.voorhies@ucsf.edu> <201110261333.10798.mark.voorhies@ucsf.edu> Message-ID: On Wed, Oct 26, 2011 at 1:33 PM, Mark Voorhies wrote: > Sounds good. ?For the impatient, here's a naive working version: Great material for a cookbook recipe! wiki.ipython.org/Cookbook Cheers, f From hans_meine at gmx.net Thu Oct 27 04:37:18 2011 From: hans_meine at gmx.net (Hans Meine) Date: Thu, 27 Oct 2011 10:37:18 +0200 Subject: [IPython-dev] %page help(x) In-Reply-To: <201110261333.10798.mark.voorhies@ucsf.edu> References: <201110131705.56624.mark.voorhies@ucsf.edu> <201110261333.10798.mark.voorhies@ucsf.edu> Message-ID: <201110271037.18900.hans_meine@gmx.net> Am Mittwoch, 26. Oktober 2011, 22:33:10 schrieb Mark Voorhies: > Sounds good. For the impatient, here's a naive working version: > > def magic_help(self, s): > """Retrieve the pydoc help for an object and display it through a > pager. """ > info = self._ofind(s) > if info['found']: > import pydoc > page.page(pydoc.plain(pydoc.render_doc(info["obj"]))) > else: > print 'Object `%s` not found' % s Would be interesting to see how easy it is to let this render HTML for the notebook! (Actually, I?d like to add such render capabilities e.g. for image objects anyhow.) Have a nice day, Hans From satra at mit.edu Thu Oct 27 09:52:01 2011 From: satra at mit.edu (Satrajit Ghosh) Date: Thu, 27 Oct 2011 09:52:01 -0400 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: hi brian, thanks for the clarification. yes we are talking of two different levels of new users. In summary, there are three mostly-orthogonal issues: > > 1) The need for the flat namespace for truly beginning users. > 2) The need to consolidate/organize the existing messy and overlapping > namespaces of numpy/scipy/matplotlib. > 3) The need for lookfor type functionality for all users. > > It is possible that 1 and 2 could be solved in a single package. > There could be well organized io, linalg, algo, etc submodules and an > "all" module that imports everything for users that need/want it. > i like this approach and i agree with thomas that most of 3) could be solved via documentation. we might just want to be clever about it and have it in the docstring+code :) cheers, satra -------------- next part -------------- An HTML attachment was scrubbed... URL: From jdh2358 at gmail.com Thu Oct 27 10:45:53 2011 From: jdh2358 at gmail.com (John Hunter) Date: Thu, 27 Oct 2011 09:45:53 -0500 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: On Wed, Oct 26, 2011 at 12:03 PM, Brian Granger wrote: >> ?Making everything work together would >> be exceedingly tricky... ?Note this is pretty much what scipy used to >> be: at some point they jettisoned plotting and focused on the algo >> part. ?It's also a hard and big project and may not attract much >> usage. > > What are the main areas that would make it tricky? ?I don't have > enough experience with numpy/scipy/matplotlib to know this. What I was thinking about is you have these different data structures (arrays, structured arrays, record arrays, dataframes) potentially all being located in "datastructures" or "io", and then users are trying to call "algo.something" methods on them, or pass them to "plot" methods, and these methods may be specialized for one type of structure but not another. Eg, matplotlib.mlab.csv2rec, pandas read_csv, and np.loadtxt can all parse a CSV file and are candidates for inclusion into an IO module. But each returns a different data structure. To the naive user, they are back where they started, needing to understand numpy, matplotlib, scipy and pandas in order to understand what they got back from the io function. And then passing it off to a stats function or plotting routine would require further understanding of what kind of data structure that interface supports. Unless you wanted to wrap and encapsulate the underlying APIs like SAGE does, a huge task, you don't really get around the many packages with overlapping functionality problem by reorganizing the namespaces. JDH From asmeurer at gmail.com Thu Oct 27 12:28:31 2011 From: asmeurer at gmail.com (Aaron Meurer) Date: Thu, 27 Oct 2011 10:28:31 -0600 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: On Thu, Oct 27, 2011 at 7:52 AM, Satrajit Ghosh wrote: > hi brian, > thanks for the clarification. yes we are talking of two different levels of > new users. >> >> In summary, there are three mostly-orthogonal issues: >> >> 1) The need for the flat namespace for truly beginning users. >> 2) The need to consolidate/organize the existing messy and overlapping >> namespaces of numpy/scipy/matplotlib. >> 3) The need for lookfor type functionality for all users. >> >> It is possible that 1 and 2 could be solved in a single package. >> There could be well organized io, linalg, algo, etc submodules and an >> "all" module that imports everything for users that need/want it. > > i like this approach and i agree with thomas that most of 3) could be solved > via documentation. we might just want to be clever about it and have it in > the docstring+code :) > cheers, > satra I think IPython could help on this front. Instead of relying on good "See Also" sections in docstrings (though those are important too), it would be useful to have an IPython magic that searched the docstring of every name in the present namespace (pardon me if this already exists, I didn't find anything like it in %magic). That way, it would be easy for users to just import everything from pylab (or whatever), and try to find functions related to whatever functionality they are interested in. This would be somewhat of an equivalent of the built-in help for a GUI program like Matlab or R GUI. And of course, the GUI versions of IPython could (and should) have more GUI oriented versions of this. Aaron Meurer From fperez.net at gmail.com Thu Oct 27 14:10:10 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 27 Oct 2011 11:10:10 -0700 Subject: [IPython-dev] %page help(x) In-Reply-To: <201110271037.18900.hans_meine@gmx.net> References: <201110131705.56624.mark.voorhies@ucsf.edu> <201110261333.10798.mark.voorhies@ucsf.edu> <201110271037.18900.hans_meine@gmx.net> Message-ID: On Thu, Oct 27, 2011 at 1:37 AM, Hans Meine wrote: > Would be interesting to see how easy it is to let this render HTML for the > notebook! ?(Actually, I?d like to add such render capabilities e.g. for image > objects anyhow.) It should 'just work': if you send html to the notebook, as long as it doesn't have a section or headers an just the html itself, the nb should render it fine... Cheers, f From fperez.net at gmail.com Thu Oct 27 14:17:06 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 27 Oct 2011 11:17:06 -0700 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: On Thu, Oct 27, 2011 at 9:28 AM, Aaron Meurer wrote: > I think IPython could help on this front. ?Instead of relying on good > "See Also" sections in docstrings (though those are important too), it > would be useful to have an IPython magic that searched the docstring > of every name in the present namespace (pardon me if this already > exists, I didn't find anything like it in %magic). > > That way, it would be easy for users to just import everything from > pylab (or whatever), and try to find functions related to whatever > functionality they are interested in. ?This would be somewhat of an > equivalent of the built-in help for a GUI program like Matlab or R > GUI. ?And of course, the GUI versions of IPython could (and should) > have more GUI oriented versions of this. Absolutely. Now that we have frontends capable of presenting this information in a richer manner, I hope someone will pitch in and contribute a good system for help searching/introspection. Even if initially we don't match the fantastic Mathematica help browser, the 'where do I find a function to do X' question is one of the most significant stumbling blocks newcomers face. Just yesterday I was lecturing at Berkeley (mostly grad students and postdocs, but new to Python) and this came up persistently. Cheers, f From ccordoba12 at gmail.com Thu Oct 27 23:18:02 2011 From: ccordoba12 at gmail.com (=?UTF-8?B?Q2FybG9zIEPDs3Jkb2Jh?=) Date: Thu, 27 Oct 2011 22:18:02 -0500 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: References: Message-ID: <4EAA1EEA.1000502@gmail.com> I think EPD distributed a magic called %whoosh which let you do full text searching in docstrings which is roughly the equivalent to lookfor. I'll try to add it to Spyder during the next year and you can read about it here: http://pypi.python.org/pypi/WhooshDoc/1.0 About the flat namespace, it's a great idea, specially to use it with the new ipython notebook (maybe as a profile, at least at the beginning). I think it would be better if it could be accompanied by a comprehensive Py4Science book which described what you can get from it. Something similar to the Mathematica book, with topics like these: 1. Core Language A Python intro from the scientific point of view 2. Data structures: Vectors/Matrices = Numpy arrays Tabular Data = DataFrame 3. Linear algebra dot, cross, norm, etc 4, Symbolic Mathematics Variables = Sympy symbols Integration/derivation/ODEs 5. Probability Distributions = Scipy.stats Random numbers = numpy.random 6. Graphics 2D = mpl.plot 3D = mayavi.mlab 3D interactive = VPython 7. Interfaces IPython lookfor and a book like this one will be a great improvement for any newbie trying to get started with python. Cheers and keep up the good flow of ideas, Carlos El jue 27 oct 2011 13:17:06 COT, Fernando Perez escribi?: > On Thu, Oct 27, 2011 at 9:28 AM, Aaron Meurer wrote: >> I think IPython could help on this front. Instead of relying on good >> "See Also" sections in docstrings (though those are important too), it >> would be useful to have an IPython magic that searched the docstring >> of every name in the present namespace (pardon me if this already >> exists, I didn't find anything like it in %magic). >> >> That way, it would be easy for users to just import everything from >> pylab (or whatever), and try to find functions related to whatever >> functionality they are interested in. This would be somewhat of an >> equivalent of the built-in help for a GUI program like Matlab or R >> GUI. And of course, the GUI versions of IPython could (and should) >> have more GUI oriented versions of this. > > Absolutely. Now that we have frontends capable of presenting this > information in a richer manner, I hope someone will pitch in and > contribute a good system for help searching/introspection. Even if > initially we don't match the fantastic Mathematica help browser, the > 'where do I find a function to do X' question is one of the most > significant stumbling blocks newcomers face. Just yesterday I was > lecturing at Berkeley (mostly grad students and postdocs, but new to > Python) and this came up persistently. > > Cheers, > > f > _______________________________________________ > IPython-dev mailing list > IPython-dev at scipy.org > http://mail.scipy.org/mailman/listinfo/ipython-dev From fperez.net at gmail.com Thu Oct 27 23:50:06 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Thu, 27 Oct 2011 20:50:06 -0700 Subject: [IPython-dev] Integrating pandas into pylab In-Reply-To: <4EAA1EEA.1000502@gmail.com> References: <4EAA1EEA.1000502@gmail.com> Message-ID: 2011/10/27 Carlos C?rdoba : > I think EPD distributed a magic called %whoosh which let you do full > text searching in docstrings which is roughly the equivalent to > lookfor. I'll try to add it to Spyder during the next year and you can > read about it here: > > http://pypi.python.org/pypi/WhooshDoc/1.0 Cool, I'd forgotten about this, and I don't think I knew Robert had written a magic to go along with it! I hope we can stabilize the nb enough for release soon, so that we can get cracking on the reST/sphinx support and other machinery needed for book-type ideas. Cheers, f From kevin.buchs at gmail.com Fri Oct 28 17:24:31 2011 From: kevin.buchs at gmail.com (Kevin Buchs) Date: Fri, 28 Oct 2011 16:24:31 -0500 Subject: [IPython-dev] ipython qt on Windows Message-ID: I haven't been able to run the Qt console on MS Windows XP since ipython 0.11 was released (.rc versions worked). I decided to clean things up and retry today. I did an install of python2.7 from python.org. Next, easy_install . That gave a few warnings about "no previously included files ..." a few times, but it finished without error. When I tried to run either of these ways: 1. C:\Python27\Scripts\ipython-qtconsole.exe or 2. C:\Python27\Python.exe C:\Python27\Scripts\ipython-qtconsole-script I got 1. nothing, 2. complaint about missing pygments.styles. Did easy_install pygments. Then 2. complaint about missing pyzmq >= 2.1.4. Did easy_install pyzmq, which installed version 2.1.10. Then 2. complaint saying it "requires pyzmq >= 2.1.4, but you have 2.1.10". Math doesn't work out. Then 1. nothing. I tried an .msi install of version 2.1.4 of pyzmq, but still got the complaint about 2.1.10 not >= 2.1.4, so I suppose I have to try to figure out how to uninstall 2.1.10. Am I making some mistakes here? -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Fri Oct 28 17:27:41 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 28 Oct 2011 14:27:41 -0700 Subject: [IPython-dev] ipython qt on Windows In-Reply-To: References: Message-ID: Hi Kevin, On Fri, Oct 28, 2011 at 2:24 PM, Kevin Buchs wrote: > Then 2. complaint saying it "requires pyzmq >= 2.1.4, but you have 2.1.10". > Math doesn't work out. > Then 1. nothing. > I tried an .msi install of version 2.1.4 of pyzmq, but still got the > complaint about 2.1.10 not >= 2.1.4, so I suppose I have to try to figure > out how to uninstall 2.1.10. > Am I making some mistakes here? Unfortunately, you're being bitten by a bug in our 0.11 version regarding the zmq version check: we were doing simple, lexicographic checking, where 10 comes before 4. This has been fixed but only in IPython master. A few days ago I built a Windows binary installer of 0.12 which has this bug already fixed: http://archive.ipython.org/testing/ipython-0.12.dev.win32-setup.exe Let us know if that helps. Cheers, f From fperez.net at gmail.com Fri Oct 28 19:40:13 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Fri, 28 Oct 2011 16:40:13 -0700 Subject: [IPython-dev] How IPython achieve embedding of matplotlib figure ? In-Reply-To: <20111024135117.5u4zdzmkg0kccww4@mail.sogeti.com> References: <20111024135117.5u4zdzmkg0kccww4@mail.sogeti.com> Message-ID: On Mon, Oct 24, 2011 at 4:51 AM, Guillaume Pichard wrote: > > What I would like to know is how IPython achieve this feature and how > can I replicate it with my own Python code ? I saw that there are > using displayhook, but how can IPython catch output from matplotlib > functions ? > > I would be greatful if you could give me some pointers on how to do > this feature. We have a custom matplotlib backend that ships the figures encoded as data in a JSON payload over ZeroMQ. Then, each client (Qt console, Web notebook) is responsible for decoding these messages and deciding how to display this output. The relevant pieces of server-side code are: https://github.com/ipython/ipython/blob/master/IPython/zmq/pylab/backend_inline.py https://github.com/ipython/ipython/blob/master/IPython/core/displaypub.py And each client has its own display logic, here's the Qt client capable of displaying png/svg images: https://github.com/ipython/ipython/blob/master/IPython/frontend/qt/console/rich_ipython_widget.py I hope this helps... Best, f From takowl at gmail.com Sat Oct 29 19:57:10 2011 From: takowl at gmail.com (Thomas Kluyver) Date: Sun, 30 Oct 2011 00:57:10 +0100 Subject: [IPython-dev] Run code at startup Message-ID: One of the commonest uses of config files is to specify code to be run in IPython's startup, e.g. to define extra magic commands, or to import modules in the user namespace. At present, this is a bit awkward: you can embed your code within a string in exec_lines, or you can save it in a separate file and add it to exec_files. In both cases, users might also get caught out by the inheritance that allows separate or joint configuration of the terminal and the ZMQShell. I proposed in #914 that we offer a simpler way to do this. Min's written a neat implementation that will check for .py and .ipy files in a directory like .ipython/profile_default/startup/ . I think this is a big improvement - if people want a custom magic command, they can simply drop a file into a folder, without delving into the config at all. Does anyone see a reason not to add this feature? The code can be seen here: https://github.com/minrk/ipython/compare/ipython:master...minrk:startup Thanks, Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From fperez.net at gmail.com Sat Oct 29 20:15:45 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sat, 29 Oct 2011 17:15:45 -0700 Subject: [IPython-dev] Run code at startup In-Reply-To: References: Message-ID: On Sat, Oct 29, 2011 at 4:57 PM, Thomas Kluyver wrote: > I proposed in #914 that we offer a simpler way to do this. Min's written a > neat implementation that will check for .py and .ipy files in a directory > like .ipython/profile_default/startup/ . I think this is a big improvement - > if people want a custom magic command, they can simply drop a file into a > folder, without delving into the config at all. Does anyone see a reason not > to add this feature? No objection from me, I agree it's simpler both to explain and to do for users... For simplicity of the mental model, the semantics of putting foo.py in startup/ should be in every respect identical to those of adding it to exec_files. That is, files in startup/ should be run by the same code that handles the exec_files list, so the behavior regarding errors, listing of contents by %who, etc, is the same. It's basically a simpler way to set exec_files by having a conventional startup/ directory, which is OK by me. Cheers, f From massimodisasha at gmail.com Sun Oct 30 09:18:15 2011 From: massimodisasha at gmail.com (massimo di stefano) Date: Sun, 30 Oct 2011 13:18:15 +0000 Subject: [IPython-dev] Ipython - dev on debian sid (zmq suppport) Message-ID: Hi All, i'm tring to install Ipython (git version) on my linux debian (sid 64 bit) unlucky i'm not able to add the zmq support, because of a mismatch in the dependence. the message i had is about the zmq version : IPython.zmq requires pyzmq >= 2.1.4, but you have 2.1.10 i guess there is something wrong ... 2.1.10 should be > 2.1.4 , is it ? the configure script return the same worning : epi at epinux:~/ipython$ python setup.py build ============================== ============================================== BUILDING IPYTHON python: 2.7.2+ (default, Oct 5 2011, 10:41:47) [GCC 4.6.1] platform: linux2 OPTIONAL DEPENDENCIES sphinx: 1.1 pygments: 1.4 /usr/local/lib/python2.7/dist-packages/nose-1.1.2-py2.7.egg/nose/plugins/manager.py:405: UserWarning: Module argparse was already imported from /usr/lib/python2.7/argparse.pyc, but /usr/lib/python2.7/dist-packages is being added to sys.path import pkg_resources nose: 1.1.2 pexpect: 2.3 pyzmq: no (have 2.1.10, but require >= 2.1.4 for qtconsole and parallel computing capabilities) readline: yes running build running build_py creating build Please, have you any clue on what's going wrong ? Many thanks for any help! --Massimo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jtaylor.debian at googlemail.com Sun Oct 30 09:22:24 2011 From: jtaylor.debian at googlemail.com (Julian Taylor) Date: Sun, 30 Oct 2011 14:22:24 +0100 Subject: [IPython-dev] Ipython - dev on debian sid (zmq suppport) In-Reply-To: References: Message-ID: <4EAD4F90.8030707@googlemail.com> On 10/30/2011 02:18 PM, massimo di stefano wrote: > Hi All, > > i'm tring to install Ipython (git version) on my linux debian (sid 64 bit) > unlucky i'm not able to add the zmq support, > because of a mismatch in the dependence. > the message i had is about the zmq version : > > IPython.zmq requires pyzmq >= 2.1.4, but you have 2.1.10 > > i guess there is something wrong ... 2.1.10 should be > 2.1.4 , is it ? > > the configure script return the same worning : > > > Please, have you any clue on what's going wrong ? > This is issue 870: https://github.com/ipython/ipython/issues/870 The startup bug should be fixed with the latest git. The message at configure time is not fixed yet, but you can ignore that. Debian sid does not have pyzmq 2.1.10 yet, thus it is not yet fixed in the debian package. A fixed ipython will be uploaded at the same time as pyzmq 2.1.10. Best Regards, Julian Taylor -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: OpenPGP digital signature URL: From massimodisasha at gmail.com Sun Oct 30 10:56:07 2011 From: massimodisasha at gmail.com (massimo di stefano) Date: Sun, 30 Oct 2011 14:56:07 +0000 Subject: [IPython-dev] Ipython - dev on debian sid (zmq suppport) In-Reply-To: <4EAD6168.3050901@googlemail.com> References: <4EAD4F90.8030707@googlemail.com> <4EAD6168.3050901@googlemail.com> Message-ID: i removed the file "/usr/local/bin/ipython-qtconsole" now it is no more generated by the build (i guess fo the missed zmq dep.) i downloaded ipython with this line : git clone https://github.com/ipython/ipython.git (few minutes ago) then i tried to reinstall it ... but no lucky epi at epinux:~/ipython$ ipython-qtconsole bash: /usr/local/bin/ipython-qtconsole: File o directory non esistente epi at epinux:~/ipython$ ipython netbook [TerminalIPythonApp] File not found: u'netbook' epi at epinux:~/ipython$ ipython Python 2.7.2+ (default, Oct 5 2011, 10:41:47) Type "copyright", "credits" or "license" for more information. IPython 0.12.dev -- An enhanced Interactive Python. ? -> Introduction and overview of IPython's features. %quickref -> Quick reference. help -> Python's own help system. object? -> Details about 'object', use 'object??' for extra details. In [1]: 2011/10/30 Julian Taylor > On 10/30/2011 03:35 PM, massimo di stefano wrote: > > Hi Julian, > > > > i tried to upgrade my local ipython, i checked the version on my distro > > > > > > File > > > "/usr/local/lib/python2.7/dist-packages/ipython-0.11-py2.7.egg/IPython/zmq/__init__.py", > > line 25, in > > minimum_pyzmq_version, pyzmq_version)) > > ImportError: IPython.zmq requires pyzmq >= 2.1.4, but you have 2.1.10 > > > > > > > > make sure to install the latest git version. > Especially this file must be the newest: > > /usr/local/lib/python2.7/dist-packages/ipython-0.11-py2.7.egg/IPython/zmq/__init__.py > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tomspur at fedoraproject.org Sun Oct 30 12:08:49 2011 From: tomspur at fedoraproject.org (Thomas Spura) Date: Sun, 30 Oct 2011 17:08:49 +0100 Subject: [IPython-dev] Ipython - dev on debian sid (zmq suppport) In-Reply-To: References: <4EAD4F90.8030707@googlemail.com> <4EAD6168.3050901@googlemail.com> Message-ID: <20111030170849.544761af@fedoraproject.org> On Sun, 30 Oct 2011 14:56:07 +0000 massimo di stefano wrote: > i removed the file "/usr/local/bin/ipython-qtconsole" > now it is no more generated by the build (i guess fo the missed zmq > dep.) > > i downloaded ipython with this line : > > git clone https://github.com/ipython/ipython.git > > (few minutes ago) > > then i tried to reinstall it ... but no lucky > > epi at epinux:~/ipython$ ipython-qtconsole > bash: /usr/local/bin/ipython-qtconsole: File o directory non esistente Could you try "ipython qtconsole"? > epi at epinux:~/ipython$ ipython netbook > [TerminalIPythonApp] File not found: u'netbook' I'm not sure, what you wanted to do. Did you mean "ipython notebook"? Tom From massimodisasha at gmail.com Sun Oct 30 12:50:11 2011 From: massimodisasha at gmail.com (gmail) Date: Sun, 30 Oct 2011 12:50:11 -0400 Subject: [IPython-dev] Ipython - dev on debian sid (zmq suppport) In-Reply-To: <20111030170849.544761af@fedoraproject.org> References: <4EAD4F90.8030707@googlemail.com> <4EAD6168.3050901@googlemail.com> <20111030170849.544761af@fedoraproject.org> Message-ID: <0A37054F-B2D0-4DE3-9DC0-4BC9369DDEBF@gmail.com> THanks guys, i feel so bad .. i misspelled netbook instead of notebook my apologize ? notebook and qtconsole are up and running! thanks for all. Il giorno Oct 30, 2011, alle ore 12:08 PM, Thomas Spura ha scritto: > On Sun, 30 Oct 2011 14:56:07 +0000 > massimo di stefano wrote: > >> i removed the file "/usr/local/bin/ipython-qtconsole" >> now it is no more generated by the build (i guess fo the missed zmq >> dep.) >> >> i downloaded ipython with this line : >> >> git clone https://github.com/ipython/ipython.git >> >> (few minutes ago) >> >> then i tried to reinstall it ... but no lucky >> >> epi at epinux:~/ipython$ ipython-qtconsole >> bash: /usr/local/bin/ipython-qtconsole: File o directory non esistente > > Could you try "ipython qtconsole"? > >> epi at epinux:~/ipython$ ipython netbook >> [TerminalIPythonApp] File not found: u'netbook' > > I'm not sure, what you wanted to do. Did you mean "ipython notebook"? > > Tom From mark.voorhies at ucsf.edu Sun Oct 30 14:58:51 2011 From: mark.voorhies at ucsf.edu (Mark Voorhies) Date: Sun, 30 Oct 2011 11:58:51 -0700 Subject: [IPython-dev] Run code at startup In-Reply-To: References: Message-ID: <201110301158.52000.mark.voorhies@ucsf.edu> On Saturday, October 29, 2011 05:15:45 pm Fernando Perez wrote: > On Sat, Oct 29, 2011 at 4:57 PM, Thomas Kluyver wrote: > > I proposed in #914 that we offer a simpler way to do this. Min's written a > > neat implementation that will check for .py and .ipy files in a directory > > like .ipython/profile_default/startup/ . I think this is a big improvement - > > if people want a custom magic command, they can simply drop a file into a > > folder, without delving into the config at all. Does anyone see a reason not > > to add this feature? > > No objection from me, I agree it's simpler both to explain and to do > for users... > > For simplicity of the mental model, the semantics of putting foo.py in > startup/ should be in every respect identical to those of adding it to > exec_files. That is, files in startup/ should be run by the same code > that handles the exec_files list, so the behavior regarding errors, > listing of contents by %who, etc, is the same. > > It's basically a simpler way to set exec_files by having a > conventional startup/ directory, which is OK by me. > > Cheers, > > f (pasting from https://github.com/ipython/ipython/issues/914) Min's implementation (e80f7aa) works for me for defining local magic. Compared to finding and editing ipython_config.py, this is _way easier to figure out. It might be nice to reference this in either the '%quickref' or '%magic' documentation so that it's easy to discover from an interactive session. --Mark From fperez.net at gmail.com Sun Oct 30 15:04:06 2011 From: fperez.net at gmail.com (Fernando Perez) Date: Sun, 30 Oct 2011 12:04:06 -0700 Subject: [IPython-dev] Run code at startup In-Reply-To: <201110301158.52000.mark.voorhies@ucsf.edu> References: <201110301158.52000.mark.voorhies@ucsf.edu> Message-ID: On Sun, Oct 30, 2011 at 11:58 AM, Mark Voorhies wrote: > It might be nice to reference this in either the '%quickref' or '%magic' documentation > so that it's easy to discover from an interactive session. +1 Cheers f From benjaminrk at gmail.com Sun Oct 30 16:17:30 2011 From: benjaminrk at gmail.com (MinRK) Date: Sun, 30 Oct 2011 13:17:30 -0700 Subject: [IPython-dev] Run code at startup In-Reply-To: References: <201110301158.52000.mark.voorhies@ucsf.edu> Message-ID: On Sun, Oct 30, 2011 at 12:04, Fernando Perez wrote: > On Sun, Oct 30, 2011 at 11:58 AM, Mark Voorhies > wrote: > > It might be nice to reference this in either the '%quickref' or '%magic' > documentation > > so that it's easy to discover from an interactive session. > > +1 > Okay, I'll do a formal PR, then after a rebase and adding some docs. > > Cheers > > f > _______________________________________________ > 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: From benjaminrk at gmail.com Sun Oct 30 17:01:45 2011 From: benjaminrk at gmail.com (MinRK) Date: Sun, 30 Oct 2011 14:01:45 -0700 Subject: [IPython-dev] Run code at startup In-Reply-To: References: <201110301158.52000.mark.voorhies@ucsf.edu> Message-ID: PR #950 issued. On Sun, Oct 30, 2011 at 13:17, MinRK wrote: > > > On Sun, Oct 30, 2011 at 12:04, Fernando Perez wrote: > >> On Sun, Oct 30, 2011 at 11:58 AM, Mark Voorhies >> wrote: >> > It might be nice to reference this in either the '%quickref' or >> '%magic' documentation >> > so that it's easy to discover from an interactive session. >> >> +1 >> > > Okay, I'll do a formal PR, then after a rebase and adding some docs. > > >> >> Cheers >> >> f >> _______________________________________________ >> 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: From hagy at gatech.edu Mon Oct 31 15:36:01 2011 From: hagy at gatech.edu (Matt Hagy) Date: Mon, 31 Oct 2011 15:36:01 -0400 (EDT) Subject: [IPython-dev] Fork to create an IPcluster with engines and clients being a mix of Python 2.6 & 2.7 (bytecode translation utilities) In-Reply-To: <0b0ded86-2028-42cb-8409-fe2eb5079932@mail6.gatech.edu> Message-ID: <97c036f2-708b-4d32-a922-7a9bf39e1966@mail6.gatech.edu> Hi All, To support an IPcluster containing both Python 2.6 & 2.7 engines and 2.6 clients I incorporated a small bytecode translation utility into my fork of IPython. If anyone else is interested you can find the fork at: https://github.com/matthagy/ipython (Nothing else has been changed yet, and everything is up to date with the master branch of IPython). It?s likely not worth pulling this niche feature into IPython, although it may be useful to at least detect when an engine is attempting to run incompatible byte code from a different client Python version. Otherwise you learn of this issue the hard way with the engine-interpreter crashing. This can be accomplished with a very small addition to the CannedFunction class in IPython.utils.pickleutil module. One simply records the version of Python in which the function is canned, and at uncanning this can be checked for incompatibilities. See: https://github.com/matthagy/ipython/blob/master/IPython/utils/pickleutil.py#L72 If anyone is interested the added module IPython.utils.codetranslation is a general translation framework that includes byteplay-derived disassemblers and assemblers for 2.4 ? 2.7. This may be of negligible use in IPython as at least 2.6 is required, and hence only the 2.6 -> 2.7 translation has been developed. One could easily code up the additional translations if needed in other projects. -Matt P.S. Thanks ipython dev team for the great tools. I?ve been using the IPython shell for 4 years and have recently found the parallel tools to be incredibly useful.