From fperez.net at gmail.com  Tue Mar  1 04:18:44 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 1 Mar 2011 01:18:44 -0800
Subject: [IPython-dev] Feedback on slides for SIAM CSE presentation?
Message-ID: <AANLkTin74T40T3GWjFrUs3vHaLA83MaJQsypkwUY2_jb@mail.gmail.com>

Hi folks,

At the SIAM CSE 2011 conference, in conjunction with Hans-Petter
Langtangen (you may know his scientific computing books) and Randy
LeVeque, we've oranized a minisymposium on python for scientific
computing, in two parts:

http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=11706
http://meetings.siam.org/sess/dsp_programsess.cfm?SESSIONCODE=11707

As you can see there, we'll have two talks specifically about ipython.
 In the second one, Min will focus on the parallel aspects, while in
the first I'll try do introduce the project and the new interactive
architecture.  If you have any feedback on the slides, I'd appreciate
it (talk time is 25 minutes):

http://fperez.org/tmp/1102_siam_cse_ipython.pdf

Note: I don't expect them to be 'read', as I try to create slides that
complement/support what I'll be saying instead of reading out loud, so
I realize it's not easy to give the best of feedbacks.  But if you see
anything you think can be improved, I'm all ears.

Thanks!

f


From jorgen.stenarson at bostream.nu  Wed Mar  2 14:49:46 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 02 Mar 2011 20:49:46 +0100
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
Message-ID: <4D6E9F5A.3050109@bostream.nu>

Hi,

I'm not sure where I should report this. Should it go into its own issue 
or as a comment on the commit that caused the problem?

Anyway commit 2ccc90d68ac01145ab97 gives unicode errors for lines with a 
bare string containing non-ansi characters:

In [1]: "?"
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in 
position 1: ordinal not in range(128)

/J?rgen


From jorgen.stenarson at bostream.nu  Wed Mar  2 14:52:12 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 02 Mar 2011 20:52:12 +0100
Subject: [IPython-dev] Test failures on master
Message-ID: <4D6E9FEC.1070009@bostream.nu>

Hi,

I'm seeing some test errors and failures on master is this known? As 
usual this is using windows. I believe at least some of them are windows 
related.

/J?rgen


From takowl at gmail.com  Wed Mar  2 15:07:14 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 2 Mar 2011 20:07:14 +0000
Subject: [IPython-dev] Test failures on master
In-Reply-To: <4D6E9FEC.1070009@bostream.nu>
References: <4D6E9FEC.1070009@bostream.nu>
Message-ID: <AANLkTimT5_NHR=KJc7w0HFs2HYYfjxsd+W6_6nHHnTnx@mail.gmail.com>

On 2 March 2011 19:52, J?rgen Stenarson <jorgen.stenarson at bostream.nu>wrote:

> I'm seeing some test errors and failures on master is this known? As
> usual this is using windows. I believe at least some of them are windows
> related.
>

At present, there's one known failure (at least, one that's not skipped on
my machine), in IPython.core: core/tests/test_formatters.py fails with:
...
ImportError: cannot import name DefaultFormatter

Anything else is probably Windows related.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110302/0f46b873/attachment.html>

From takowl at gmail.com  Wed Mar  2 15:08:12 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 2 Mar 2011 20:08:12 +0000
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
References: <4D6E9F5A.3050109@bostream.nu>
	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
Message-ID: <AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>

(Forgot to CC list in my reply...)
On 2 March 2011 19:49, J?rgen Stenarson <jorgen.stenarson at bostream.nu>wrote:

> Anyway commit 2ccc90d68ac01145ab97 gives unicode errors for lines with a
> bare string containing non-ansi characters:
>
> In [1]: "?"
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xe5' in
> position 1: ordinal not in range(128)
>

At present, any command containing non-ascii characters fails (at least for
me). Can you test with my unicode issues branch:

https://github.com/ipython/ipython/pull/252

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110302/5814f194/attachment.html>

From jorgen.stenarson at bostream.nu  Wed Mar  2 15:27:57 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 02 Mar 2011 21:27:57 +0100
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
References: <4D6E9F5A.3050109@bostream.nu>	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
	<AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
Message-ID: <4D6EA84D.1020805@bostream.nu>

Thomas Kluyver skrev 2011-03-02 21:08:
> At present, any command containing non-ascii characters fails (at least
> for me). Can you test with my unicode issues branch:
>

The problem with non-ascii characters disappeared but there are some 
test errors and failures, see below.

/J?rgen

======================================================================
ERROR: Failure: SyntaxError (Non-ASCII character '\xc5' in file 
c:\python\extern
al\ipython-takluyver\IPython\core\tests\test_compilerop.py on line 55, 
but no en
coding declared; see http://www.python.org/peps/pep-0263.html for 
details (test_
compilerop.py, line 55))
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\loader.py", lin
e 379, in loadTestsFromName
     addr.filename, addr.module)
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l
ine 39, in importFromPath
     return self.importFromDir(dir_path, fqname)
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l
ine 86, in importFromDir
     mod = load_module(part_fqname, fh, filename, desc)
   File 
"c:\python\external\ipython-takluyver\IPython\core\tests\test_compilerop.
py", line 55
SyntaxError: Non-ASCII character '\xc5' in file 
c:\python\external\ipython-taklu
yver\IPython\core\tests\test_compilerop.py on line 55, but no encoding 
declared;
  see http://www.python.org/peps/pep-0263.html for details 
(test_compilerop.py, l
ine 55)

======================================================================
ERROR: Failure: SyntaxError (Non-ASCII character '\xc5' in file 
c:\python\extern
al\ipython-takluyver\IPython\core\tests\test_history.py on line 33, but 
no encod
ing declared; see http://www.python.org/peps/pep-0263.html for details 
(test_his
tory.py, line 33))
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\loader.py", lin
e 379, in loadTestsFromName
     addr.filename, addr.module)
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l
ine 39, in importFromPath
     return self.importFromDir(dir_path, fqname)
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l
ine 86, in importFromDir
     mod = load_module(part_fqname, fh, filename, desc)
   File 
"c:\python\external\ipython-takluyver\IPython\core\tests\test_history.py"
, line 33
SyntaxError: Non-ASCII character '\xc5' in file 
c:\python\external\ipython-taklu
yver\IPython\core\tests\test_history.py on line 33, but no encoding 
declared; se
e http://www.python.org/peps/pep-0263.html for details (test_history.py, 
line 33
)

======================================================================
FAIL: IPython.core.tests.test_completer.test_file_completions
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line
183, in runTest
     self.test(*self.arg)
   File 
"c:\python\external\ipython-takluyver\IPython\core\tests\test_completer.p
y", line 152, in test_file_completions
     nt.assert_equal(c, names)
AssertionError: [] != 
['c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpd8x4nk\\foo1',
  'c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpd8x4nk\\foo2']
 >>  raise self.failureException, \
           (None or '%r != %r' % ([], 
['c:\\docume~1\\jstenar\\lokala~1\\temp\\tm
pd8x4nk\\foo1', 'c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpd8x4nk\\foo2']))


======================================================================
FAIL: Test various directory handling operations.
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line
183, in runTest
     self.test(*self.arg)
   File 
"c:\python\external\ipython-takluyver\IPython\core\tests\test_magic.py",
line 293, in test_dirops
     nt.assert_equal(curpath(), ipdir)
AssertionError: '/docume~1/jstenar/lokala~1/temp' != u'C:\\Documents and 
Setting
s\\jstenar\\.ipython'
 >>  raise self.failureException, \
           (None or '%r != %r' % ('/docume~1/jstenar/lokala~1/temp', 
u'C:\\Docume
nts and Settings\\jstenar\\.ipython'))

-------------------- >> begin captured stdout << ---------------------
[Error 123] Felaktig syntax f?r filnamn, katalognamn eller volymetikett: 
'"C:/Do
cuments and Settings/jstenar/.ipython"'
c:\docume~1\jstenar\lokala~1\temp

--------------------- >> end captured stdout << ----------------------

----------------------------------------------------------------------
Ran 270 tests in 2.891s

FAILED (SKIP=3, errors=2, failures=2)
**********************************************************************
IPython test group: IPython.extensions
.
----------------------------------------------------------------------
Ran 1 test in 0.000s

OK
**********************************************************************
IPython test group: IPython.frontend
......
----------------------------------------------------------------------
Ran 6 tests in 0.063s

OK
**********************************************************************
IPython test group: IPython.lib
....E
======================================================================
ERROR: Failure: ImportError (No module named pexpect)
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\loader.py", lin
e 379, in loadTestsFromName
     addr.filename, addr.module)
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l
ine 39, in importFromPath
     return self.importFromDir(dir_path, fqname)
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\importer.py", l
ine 86, in importFromDir
     mod = load_module(part_fqname, fh, filename, desc)
   File 
"c:\python\external\ipython-takluyver\IPython\lib\tests\test_irunner.py",
  line 15, in <module>
     from IPython.lib import irunner
   File "c:\python\external\ipython-takluyver\IPython\lib\irunner.py", 
line 39, i
n <module>
     import pexpect
ImportError: No module named pexpect


From takowl at gmail.com  Wed Mar  2 15:44:37 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 2 Mar 2011 20:44:37 +0000
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <4D6EA84D.1020805@bostream.nu>
References: <4D6E9F5A.3050109@bostream.nu>
	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
	<AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
	<4D6EA84D.1020805@bostream.nu>
Message-ID: <AANLkTi=qz02EAvqZ6HqsqVM4+ff8bh_vvWUhzF+q0E_0@mail.gmail.com>

On 2 March 2011 20:27, J?rgen Stenarson <jorgen.stenarson at bostream.nu>wrote:

> Thomas Kluyver skrev 2011-03-02 21:08:
> > At present, any command containing non-ascii characters fails (at least
> > for me). Can you test with my unicode issues branch:
> >
>
> The problem with non-ascii characters disappeared but there are some
> test errors and failures, see below.
>

OK, the first two are easy ones, I'd just forgotten to add the encoding
declaration to the necessary files (I guess it's a platform difference that
it didn't complain for me). I've pushed an update.

The next two I'm not sure about - it looks like some of our directory code
isn't properly platform independent. Finally, pexpect is a dependency error
- it should fall back to using IPython.external.pexpect.

I've also rebased the branch, so it's up to date with trunk - can I ask you
to test again with that? You might have to delete your copy of the branch
and refetch it.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110302/8c9c79f2/attachment.html>

From jorgen.stenarson at bostream.nu  Wed Mar  2 15:59:20 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Wed, 02 Mar 2011 21:59:20 +0100
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <AANLkTi=qz02EAvqZ6HqsqVM4+ff8bh_vvWUhzF+q0E_0@mail.gmail.com>
References: <4D6E9F5A.3050109@bostream.nu>
	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
	<AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
	<4D6EA84D.1020805@bostream.nu>
	<AANLkTi=qz02EAvqZ6HqsqVM4+ff8bh_vvWUhzF+q0E_0@mail.gmail.com>
Message-ID: <4D6EAFA8.1000103@bostream.nu>

Thomas Kluyver skrev 2011-03-02 21:44:
 >
> I've also rebased the branch, so it's up to date with trunk - can I ask
> you to test again with that? You might have to delete your copy of the
> branch and refetch it.
>
> Thomas

Hi,

these are the errors I get for the IPython.core tests
/J?rgen

======================================================================
ERROR: IPython.core.tests.test_history.test_history
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line
183, in runTest
     self.test(*self.arg)
   File 
"c:\python\external\ipython-takluyver\IPython\core\tests\test_history.py"
, line 41, in test_history
     ip.reload_history()
   File 
"c:\python\external\ipython-takluyver\IPython\core\interactiveshell.py",
line 1259, in reload_history
     self.history_manager.reload_history()
   File "c:\python\external\ipython-takluyver\IPython\core\history.py", 
line 176,
  in reload_history
     self.populate_readline_history()
   File "c:\python\external\ipython-takluyver\IPython\core\history.py", 
line 145,
  in populate_readline_history
     h = h.encode(sys.stdin.encoding or "utf-8")
   File "C:\Python26\lib\encodings\cp1252.py", line 12, in encode
     return codecs.charmap_encode(input,errors,encoding_table)
UnicodeEncodeError: 'charmap' codec can't encode characters in position 
6-7: cha
racter maps to <undefined>
-------------------- >> begin captured stdout << ---------------------
test c:\docume~1\jstenar\lokala~1\temp\tmp2fb59q\history.json

--------------------- >> end captured stdout << ----------------------

======================================================================
FAIL: IPython.core.tests.test_completer.test_file_completions
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line
183, in runTest
     self.test(*self.arg)
   File 
"c:\python\external\ipython-takluyver\IPython\core\tests\test_completer.p
y", line 152, in test_file_completions
     nt.assert_equal(c, names)
AssertionError: [] != 
['c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpo2gmyx\\foo1',
  'c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpo2gmyx\\foo2']
 >>  raise self.failureException, \
           (None or '%r != %r' % ([], 
['c:\\docume~1\\jstenar\\lokala~1\\temp\\tm
po2gmyx\\foo1', 'c:\\docume~1\\jstenar\\lokala~1\\temp\\tmpo2gmyx\\foo2']))


======================================================================
FAIL: Test various directory handling operations.
----------------------------------------------------------------------
Traceback (most recent call last):
   File 
"C:\Python26\lib\site-packages\nose-0.11.1-py2.6.egg\nose\case.py", line
183, in runTest
     self.test(*self.arg)
   File 
"c:\python\external\ipython-takluyver\IPython\core\tests\test_magic.py",
line 293, in test_dirops
     nt.assert_equal(curpath(), ipdir)
AssertionError: '/python/external/ipython-takluyver/IPython' != 
u'C:\\Documents
and Settings\\jstenar\\.ipython'
 >>  raise self.failureException, \
           (None or '%r != %r' % 
('/python/external/ipython-takluyver/IPython', u
'C:\\Documents and Settings\\jstenar\\.ipython'))

-------------------- >> begin captured stdout << ---------------------
[Error 123] Felaktig syntax f?r filnamn, katalognamn eller volymetikett: 
'"C:/Do
cuments and Settings/jstenar/.ipython"'
C:\python\external\ipython-takluyver\IPython

--------------------- >> end captured stdout << ----------------------

----------------------------------------------------------------------


From benjaminrk at gmail.com  Wed Mar  2 16:02:22 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 2 Mar 2011 13:02:22 -0800
Subject: [IPython-dev] Test failures on master
In-Reply-To: <AANLkTimT5_NHR=KJc7w0HFs2HYYfjxsd+W6_6nHHnTnx@mail.gmail.com>
References: <4D6E9FEC.1070009@bostream.nu>
	<AANLkTimT5_NHR=KJc7w0HFs2HYYfjxsd+W6_6nHHnTnx@mail.gmail.com>
Message-ID: <AANLkTikHg5Vvhqd-AQsWFTiLScXrPNdWOpJooxTn5=NA@mail.gmail.com>

test_formatters is fixed in trunk, as of a41b73bf.  The Unicode bug is
the only one I currently see in IPython.core on OSX

On Wed, Mar 2, 2011 at 12:07, Thomas Kluyver <takowl at gmail.com> wrote:
> On 2 March 2011 19:52, J?rgen Stenarson <jorgen.stenarson at bostream.nu>
> wrote:
>>
>> I'm seeing some test errors and failures on master is this known? As
>> usual this is using windows. I believe at least some of them are windows
>> related.
>
> At present, there's one known failure (at least, one that's not skipped on
> my machine), in IPython.core: core/tests/test_formatters.py fails with:
> ...
> ImportError: cannot import name DefaultFormatter
>
> Anything else is probably Windows related.
>
> Thomas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From benjaminrk at gmail.com  Wed Mar  2 16:55:43 2011
From: benjaminrk at gmail.com (MinRK)
Date: Wed, 2 Mar 2011 13:55:43 -0800
Subject: [IPython-dev] Test failures on master
In-Reply-To: <AANLkTik10VrN-M4fowbnMJCrH6BNaa4=VjAnZUyDqoAz@mail.gmail.com>
References: <4D6E9FEC.1070009@bostream.nu>
	<AANLkTimT5_NHR=KJc7w0HFs2HYYfjxsd+W6_6nHHnTnx@mail.gmail.com>
	<AANLkTikHg5Vvhqd-AQsWFTiLScXrPNdWOpJooxTn5=NA@mail.gmail.com>
	<AANLkTik10VrN-M4fowbnMJCrH6BNaa4=VjAnZUyDqoAz@mail.gmail.com>
Message-ID: <AANLkTim+F15b+zuatBmVgXTUdiLnoQvS30BezJLwiEwu@mail.gmail.com>

The same bug fixed by your unicode-issues branch, if I am not
mistaken.  It doesn't raise on Ubuntu in iptest, because importing gtk
sets sys.defaultencoding to utf8.

======================================================================
ERROR: test_unicode
(IPython.core.tests.test_inputsplitter.InputSplitterTestCase)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/Users/minrk/dev/ip/trunk/IPython/core/tests/test_inputsplitter.py",
line 367, in test_unicode
    self.isp.push("u'\xc3\xa9'")
  File "/Users/minrk/dev/ip/trunk/IPython/core/inputsplitter.py", line
381, in push
    self._store(lines)
  File "/Users/minrk/dev/ip/trunk/IPython/core/inputsplitter.py", line
614, in _store
    setattr(self, store, self._set_source(buffer))
  File "/Users/minrk/dev/ip/trunk/IPython/core/inputsplitter.py", line
617, in _set_source
    return ''.join(buffer).encode(self.encoding)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position
2: ordinal not in range(128)

----------------------------------------------------------------------

This will still fail on Ubuntu if you run just that test alone with:

nosetests -vvsx IPython/core/tests/test_inputsplitter.py

-MinRK


On Wed, Mar 2, 2011 at 13:38, Thomas Kluyver <takowl at gmail.com> wrote:
> On 2 March 2011 21:02, MinRK <benjaminrk at gmail.com> wrote:
>>
>> test_formatters is fixed in trunk, as of a41b73bf. ?The Unicode bug is
>> the only one I currently see in IPython.core on OSX
>>
>
> Which Unicode bug is that? I get no failures in IPython.core on Ubuntu.
>
> Thomas
>


From takowl at gmail.com  Wed Mar  2 17:08:42 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Wed, 2 Mar 2011 22:08:42 +0000
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <4D6EAFA8.1000103@bostream.nu>
References: <4D6E9F5A.3050109@bostream.nu>
	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
	<AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
	<4D6EA84D.1020805@bostream.nu>
	<AANLkTi=qz02EAvqZ6HqsqVM4+ff8bh_vvWUhzF+q0E_0@mail.gmail.com>
	<4D6EAFA8.1000103@bostream.nu>
Message-ID: <AANLkTimj1CUBBCWvqCeM8r2DJV+kEYvX6AngbuXa8r9S@mail.gmail.com>

On 2 March 2011 20:59, J?rgen Stenarson <jorgen.stenarson at bostream.nu>wrote:

> Hi,
>
> these are the errors I get for the IPython.core tests
>
[snip]

OK, I think the first one must be trying to encode a character that you
couldn't actually type at a standard Windows console. I don't know if there
is a correct behaviour here. Maybe I should simply replace the characters
tested with some from the upper half of cp1252.

To clarify, are the other two failing only on this branch, or are they some
of the failures you mentioned in trunk?

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110302/2b0fc44b/attachment.html>

From jorgen.stenarson at bostream.nu  Wed Mar  2 18:05:03 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Thu, 03 Mar 2011 00:05:03 +0100
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <AANLkTimj1CUBBCWvqCeM8r2DJV+kEYvX6AngbuXa8r9S@mail.gmail.com>
References: <4D6E9F5A.3050109@bostream.nu>
	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
	<AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
	<4D6EA84D.1020805@bostream.nu>
	<AANLkTi=qz02EAvqZ6HqsqVM4+ff8bh_vvWUhzF+q0E_0@mail.gmail.com>
	<4D6EAFA8.1000103@bostream.nu>
	<AANLkTimj1CUBBCWvqCeM8r2DJV+kEYvX6AngbuXa8r9S@mail.gmail.com>
Message-ID: <4D6ECD1F.2050703@bostream.nu>

Thomas Kluyver skrev 2011-03-02 23:08:
> On 2 March 2011 20:59, J?rgen Stenarson <jorgen.stenarson at bostream.nu
> <mailto:jorgen.stenarson at bostream.nu>> wrote:
>
>     Hi,
>
>     these are the errors I get for the IPython.core tests
>
> [snip]
>
> OK, I think the first one must be trying to encode a character that you
> couldn't actually type at a standard Windows console. I don't know if
> there is a correct behaviour here. Maybe I should simply replace the
> characters tested with some from the upper half of cp1252.
>
> To clarify, are the other two failing only on this branch, or are they
> some of the failures you mentioned in trunk?
>
> Thomas

I believe the other two are the same as in trunk.

/J?rgen


From takowl at gmail.com  Wed Mar  2 20:10:11 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 3 Mar 2011 01:10:11 +0000
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <4D6ECD1F.2050703@bostream.nu>
References: <4D6E9F5A.3050109@bostream.nu>
	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
	<AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
	<4D6EA84D.1020805@bostream.nu>
	<AANLkTi=qz02EAvqZ6HqsqVM4+ff8bh_vvWUhzF+q0E_0@mail.gmail.com>
	<4D6EAFA8.1000103@bostream.nu>
	<AANLkTimj1CUBBCWvqCeM8r2DJV+kEYvX6AngbuXa8r9S@mail.gmail.com>
	<4D6ECD1F.2050703@bostream.nu>
Message-ID: <AANLkTik-nDh4YwZ3v13eZCrswfN+Uac1MfEsNVSEAqVn@mail.gmail.com>

On 2 March 2011 23:05, J?rgen Stenarson <jorgen.stenarson at bostream.nu>wrote:

> I believe the other two are the same as in trunk.


OK, we'll look at those separately.

In terms of the Unicode question, can someone with more Windows experience
than me fill me in:
- If sys.stdin.encoding is cp1252, is it possible to enter a character
outside that set at the shell at all?
- If so, how can it be stored in readline so that it will match lookups
including the same character? I could encode as utf-8, but I assume that
that won't match things at the console if stdin is in cp1252?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110303/8d644a6c/attachment.html>

From takowl at gmail.com  Fri Mar  4 05:32:26 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 4 Mar 2011 10:32:26 +0000
Subject: [IPython-dev] Google summer of code
Message-ID: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>

Have we already, and do we want to, apply for Google summer of code
projects? The deadline for mentoring organisations is now just one week away
(Friday 11 March).

http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110304/5f604b40/attachment.html>

From jorgen.stenarson at bostream.nu  Fri Mar  4 15:00:32 2011
From: jorgen.stenarson at bostream.nu (=?ISO-8859-1?Q?J=F6rgen_Stenarson?=)
Date: Fri, 04 Mar 2011 21:00:32 +0100
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <AANLkTimsP-NqrkCmt_kQVsAuoXUqdNzEGLNrs4Kv6G3g@mail.gmail.com>
References: <4D6E9F5A.3050109@bostream.nu>
	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
	<AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
	<4D6EA84D.1020805@bostream.nu>
	<AANLkTi=qz02EAvqZ6HqsqVM4+ff8bh_vvWUhzF+q0E_0@mail.gmail.com>
	<4D6EAFA8.1000103@bostream.nu>
	<AANLkTimj1CUBBCWvqCeM8r2DJV+kEYvX6AngbuXa8r9S@mail.gmail.com>
	<4D6ECD1F.2050703@bostream.nu>
	<AANLkTik-nDh4YwZ3v13eZCrswfN+Uac1MfEsNVSEAqVn@mail.gmail.com>
	<4D6FEA75.2060208@bostream.nu>
	<AANLkTimsP-NqrkCmt_kQVsAuoXUqdNzEGLNrs4Kv6G3g@mail.gmail.com>
Message-ID: <4D7144E0.4010300@bostream.nu>

Thomas Kluyver skrev 2011-03-03 21:37:
> On 3 March 2011 19:22, J?rgen Stenarson <jorgen.stenarson at bostream.nu
> <mailto:jorgen.stenarson at bostream.nu>> wrote:
>
>     yes it is possible to enter other character codes but you have to
>     use the unicode functions in the api to read them properly. It is
>     for the 8-bit api that the encoding is valid.
>
>
>   OK, I'm not entirely following what you mean here. If I did a =
> raw_input(), and entered a non-cp1252 character, what ends up in a? Does
> it mysteriously turn the output into a unicode object? Or does it
> produce some odd string of bytes?
>
>  > In pyreadline we are using the wide api and are returning unicode
> strings, however I have not tested that extensively so there may be bugs
> in that handling.
>
> OK, does that mean that we should add unicode strings to add_history,
> rather than byte strings? Only I think readline in Python 2 on Linux
> choked on unicode when it contained non-ascii characters. Or is there an
> encoding we should use instead of cp1252?
>
> Thomas

Hi,

looking into it in more detail, pyreadline can return unicode strings 
but the call the hook that raw_input uses gets a regular string in 
return that has been encoded using .encode(pyreadline_codepage, u"replace").

I have attached a script and a screenshot of a session that demonstrates 
the difference between using raw_input and calling readline directly.

As things are now, using raw_input you should not receive any characters 
outside the current encoding because they will be converted to ? before 
being returned to raw_input.

/J?rgen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repl.png
Type: image/png
Size: 4196 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110304/baa76356/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: repl.py
Type: application/x-python
Size: 123 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110304/baa76356/attachment.bin>

From takowl at gmail.com  Fri Mar  4 17:38:56 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 4 Mar 2011 22:38:56 +0000
Subject: [IPython-dev] Bug caused by commit 2ccc90d68ac01145ab97
In-Reply-To: <4D7144E0.4010300@bostream.nu>
References: <4D6E9F5A.3050109@bostream.nu>
	<AANLkTikhqCGvWN+c-3W4oChZCFLbwnUveCprShHxD=_D@mail.gmail.com>
	<AANLkTinZwUEe4A=dWaC3u+nka+x+e3cvQ8s1i0wVcqpw@mail.gmail.com>
	<4D6EA84D.1020805@bostream.nu>
	<AANLkTi=qz02EAvqZ6HqsqVM4+ff8bh_vvWUhzF+q0E_0@mail.gmail.com>
	<4D6EAFA8.1000103@bostream.nu>
	<AANLkTimj1CUBBCWvqCeM8r2DJV+kEYvX6AngbuXa8r9S@mail.gmail.com>
	<4D6ECD1F.2050703@bostream.nu>
	<AANLkTik-nDh4YwZ3v13eZCrswfN+Uac1MfEsNVSEAqVn@mail.gmail.com>
	<4D6FEA75.2060208@bostream.nu>
	<AANLkTimsP-NqrkCmt_kQVsAuoXUqdNzEGLNrs4Kv6G3g@mail.gmail.com>
	<4D7144E0.4010300@bostream.nu>
Message-ID: <AANLkTinB7nWOHF=mkpcZqEKKTp8OXbvFvjAPhDBLcxGS@mail.gmail.com>

On 4 March 2011 20:00, J?rgen Stenarson <jorgen.stenarson at bostream.nu>wrote:

> As things are now, using raw_input you should not receive any characters
> outside the current encoding because they will be converted to ? before
> being returned to raw_input.
>

OK, thanks. So, I think the sensible thing is to just do the test with
characters from the upper half of cp1252. I've tweaked the test to do that,
can you pull the update and test it again?

I think this means the test will fail on Windows if the code page is set to
something other than cp1252. I don't see an obvious way round that, I think
we'll just have to make a note that it's a known failure case. The actual
code should be correct for other code pages, just not the example in the
test.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110304/61ade18c/attachment.html>

From takowl at gmail.com  Tue Mar  8 08:29:00 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 8 Mar 2011 13:29:00 +0000
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
Message-ID: <AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>

Brief reminder about this: if we want to have summer of code projects this
year, we need to apply by *this Friday*. I'd hate for us to miss it just
because it dropped off the radar.

Thomas

On 4 March 2011 10:32, Thomas Kluyver <takowl at gmail.com> wrote:

> Have we already, and do we want to, apply for Google summer of code
> projects? The deadline for mentoring organisations is now just one week away
> (Friday 11 March).
>
>
> http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp
>
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110308/047b06e1/attachment.html>

From jbaker at zyasoft.com  Tue Mar  8 08:40:14 2011
From: jbaker at zyasoft.com (Jim Baker)
Date: Tue, 8 Mar 2011 06:40:14 -0700
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
	<AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>
Message-ID: <AANLkTi=7G=NFSvuXrXgDk=DpYrGic2kyVFhhZMdmj8or@mail.gmail.com>

FWIW - it would seem to me that it would be much easier to go through the
PSF as the mentoring organization for SOC, given the variety of Python
projects that have been sponsored in the past. In particular, given that
IPython is not incidentally written in Python, but actively support Python
usage and development makes it a good fit for the PSF.

(This of course assumes the PSF is accepted yet again. It would seem
likely.)

On Tue, Mar 8, 2011 at 6:29 AM, Thomas Kluyver <takowl at gmail.com> wrote:

> Brief reminder about this: if we want to have summer of code projects this
> year, we need to apply by *this Friday*. I'd hate for us to miss it just
> because it dropped off the radar.
>
> Thomas
>
>
> On 4 March 2011 10:32, Thomas Kluyver <takowl at gmail.com> wrote:
>
>> Have we already, and do we want to, apply for Google summer of code
>> projects? The deadline for mentoring organisations is now just one week away
>> (Friday 11 March).
>>
>>
>> http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp
>>
>> Thomas
>>
>
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110308/d8fa792e/attachment.html>

From ellisonbg at gmail.com  Tue Mar  8 12:54:47 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Tue, 8 Mar 2011 09:54:47 -0800
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTi=7G=NFSvuXrXgDk=DpYrGic2kyVFhhZMdmj8or@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
	<AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>
	<AANLkTi=7G=NFSvuXrXgDk=DpYrGic2kyVFhhZMdmj8or@mail.gmail.com>
Message-ID: <AANLkTimxQvMTQ7-hYnCsv7S6UXPZGk=n_4QOf-kyB+fj@mail.gmail.com>

If there is not a huge amount of momentum this year, I think sticking
with the PSF for now makes sense.  Has anyone talked with Arc Riley
about this year.  He is starting the process for other PSF projects
(like sympy) and we should email him.

"Arc Riley" <arcriley at gmail.com>,

Brian

On Tue, Mar 8, 2011 at 5:40 AM, Jim Baker <jbaker at zyasoft.com> wrote:
> FWIW - it would seem to me that it would be much easier to go through the
> PSF as the mentoring organization for SOC, given the variety of Python
> projects that have been sponsored in the past. In particular, given that
> IPython is not incidentally written in Python, but actively support Python
> usage and development makes it a good fit for the PSF.
> (This of course assumes the PSF is accepted yet again. It would seem
> likely.)
>
> On Tue, Mar 8, 2011 at 6:29 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>>
>> Brief reminder about this: if we want to have summer of code projects this
>> year, we need to apply by *this Friday*. I'd hate for us to miss it just
>> because it dropped off the radar.
>>
>> Thomas
>>
>> On 4 March 2011 10:32, Thomas Kluyver <takowl at gmail.com> wrote:
>>>
>>> Have we already, and do we want to, apply for Google summer of code
>>> projects? The deadline for mentoring organisations is now just one week away
>>> (Friday 11 March).
>>>
>>>
>>> http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp
>>>
>>> Thomas
>>
>>
>> _______________________________________________
>> 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
>
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com


From fperez.net at gmail.com  Tue Mar  8 15:15:35 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 8 Mar 2011 12:15:35 -0800
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTimxQvMTQ7-hYnCsv7S6UXPZGk=n_4QOf-kyB+fj@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
	<AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>
	<AANLkTi=7G=NFSvuXrXgDk=DpYrGic2kyVFhhZMdmj8or@mail.gmail.com>
	<AANLkTimxQvMTQ7-hYnCsv7S6UXPZGk=n_4QOf-kyB+fj@mail.gmail.com>
Message-ID: <AANLkTikt_hiNfy8Vc=CMu9cY-xTmWVp84mUxaa2hZAWU@mail.gmail.com>

On Tue, Mar 8, 2011 at 9:54 AM, Brian Granger <ellisonbg at gmail.com> wrote:
> If there is not a huge amount of momentum this year, I think sticking
> with the PSF for now makes sense. ?Has anyone talked with Arc Riley
> about this year. ?He is starting the process for other PSF projects
> (like sympy) and we should email him.

If we want to go for gsoc this year, I'd vote for simply using the
psf, I don't think we really need to be a separate mentoring
organization, we simply don't have enough available hands for that.

It's not even totally clear to me that we have the bandwidth to mentor
students: the core devs are stretched pretty thin as it is, and gsoc
mentoring, when done right, requires a real commitment of time on the
mentor's part.  In the ideal case that investment pays off in the long
run in terms of getting good new project members actively
participating, but that's not guaranteed while the upfront cost is a
given.

One question is, who would be interested in participating as a
student?  I know some people have expressed interest before, including
Kunal and Omar; I'd like to know if Thomas would like to be a student.
 Thomas, you've made enormous contributions to the project in a short
amount of time and would thus be a perfect candidate, but I don't know
how that could interfere with your studies over the summer, case in
which it would be a no-go...

Cheers,

f


From takowl at gmail.com  Tue Mar  8 18:43:16 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 8 Mar 2011 23:43:16 +0000
Subject: [IPython-dev] Google Summer of Code
Message-ID: <AANLkTiniAN1Jm8woHiy3ePYJGvsePnow4t=1Gxtmsfcy@mail.gmail.com>

Hi all,

If you're a student, and you'd like to lend a hand with IPython this summer,
you might want to consider applying for Google Summer of Code. If you've not
come across it before, GSoC is an initiative to pay student programmers to
work with open source projects. For more details, have a look at the GSoC
website: http://www.google-melange.com/

There's a lot changing in IPython as we work towards 0.11, including new
frontends, a new parallel computing architecture, and a Python 3 port. If
you're interested, please e-mail the development list (ipython-dev at scipy.org)
with a little bit about yourself, your programming experience, and any
aspect of IPython you'd particularly like to work on (although we can supply
ideas if you're keen but uncertain). We're currently planning to take just
one student this year, so let us know why that should be you.

If you know (or teach) students who might be interested in spending their
summer writing Python, please forward this on to them.

Thanks,
Thomas Kluyver (on behalf of the core dev team)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110308/497c6e96/attachment.html>

From andresete.chaos at gmail.com  Tue Mar  8 20:32:47 2011
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Tue, 8 Mar 2011 20:32:47 -0500
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTikt_hiNfy8Vc=CMu9cY-xTmWVp84mUxaa2hZAWU@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
	<AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>
	<AANLkTi=7G=NFSvuXrXgDk=DpYrGic2kyVFhhZMdmj8or@mail.gmail.com>
	<AANLkTimxQvMTQ7-hYnCsv7S6UXPZGk=n_4QOf-kyB+fj@mail.gmail.com>
	<AANLkTikt_hiNfy8Vc=CMu9cY-xTmWVp84mUxaa2hZAWU@mail.gmail.com>
Message-ID: <AANLkTi=gb-EQt6LU12ay2Xain5y14ZOb+5zfF=uJ_v-t@mail.gmail.com>

hi all.
This year I want to apply to GSoC again, the idea is to write a web
interface for ipython using ajax, based in the interface of James Gao.
I am improving the James's prototype and I have many bugs fixed and many
new  features added, let me show you the in the git's repo
https://github.com/omazapa/ipython/tree/ipajax with all ready to test this
new prototype and let me show in the next days  the blog with all ideas and
proposal for GSoC.

Prototype Features:
- indentation supported
- tab completion working
- Shitf + Enter working to run commands
- buttons for minimize code blocks
- buttons for close code blocks
- and so many bugs fixed


If you have suggestions to my application please let met know.
Thanks


On Tue, Mar 8, 2011 at 3:15 PM, Fernando Perez <fperez.net at gmail.com> wrote:

> On Tue, Mar 8, 2011 at 9:54 AM, Brian Granger <ellisonbg at gmail.com> wrote:
> > If there is not a huge amount of momentum this year, I think sticking
> > with the PSF for now makes sense.  Has anyone talked with Arc Riley
> > about this year.  He is starting the process for other PSF projects
> > (like sympy) and we should email him.
>
> If we want to go for gsoc this year, I'd vote for simply using the
> psf, I don't think we really need to be a separate mentoring
> organization, we simply don't have enough available hands for that.
>
> It's not even totally clear to me that we have the bandwidth to mentor
> students: the core devs are stretched pretty thin as it is, and gsoc
> mentoring, when done right, requires a real commitment of time on the
> mentor's part.  In the ideal case that investment pays off in the long
> run in terms of getting good new project members actively
> participating, but that's not guaranteed while the upfront cost is a
> given.
>
> One question is, who would be interested in participating as a
> student?  I know some people have expressed interest before, including
> Kunal and Omar; I'd like to know if Thomas would like to be a student.
>  Thomas, you've made enormous contributions to the project in a short
> amount of time and would thus be a perfect candidate, but I don't know
> how that could interfere with your studies over the summer, case in
> which it would be a no-go...
>
> Cheers,
>
> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Omar Andres Zapata Mesa
Head Developer Phenomenology of Fundamental Interactions Group (Gfif)
http://gfif.udea.edu.co
Division of computer science Gfif Developers (Gfif Dev)
http://gfifdev.udea.edu.co
Systems Engineering Student
Universidad de Antioquia At Medellin - Colombia
Usuario Linux  #490962
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110308/f72905f0/attachment.html>

From fperez.net at gmail.com  Tue Mar  8 21:19:59 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 8 Mar 2011 18:19:59 -0800
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTi=gb-EQt6LU12ay2Xain5y14ZOb+5zfF=uJ_v-t@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
	<AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>
	<AANLkTi=7G=NFSvuXrXgDk=DpYrGic2kyVFhhZMdmj8or@mail.gmail.com>
	<AANLkTimxQvMTQ7-hYnCsv7S6UXPZGk=n_4QOf-kyB+fj@mail.gmail.com>
	<AANLkTikt_hiNfy8Vc=CMu9cY-xTmWVp84mUxaa2hZAWU@mail.gmail.com>
	<AANLkTi=gb-EQt6LU12ay2Xain5y14ZOb+5zfF=uJ_v-t@mail.gmail.com>
Message-ID: <AANLkTimqKtHL-q2LGKkamZf5nHsGRb79FSednqarJ0kH@mail.gmail.com>

Hi Omar,

2011/3/8 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
>
> If you have suggestions to my application please let met know.

Working on this would be great, but there's something I mentioned to
you that will come up when others review your gsoc application, and
that you need to consider: completing last year's work so that the
console client is fully functional on top of the zmq code.  Your
improvements that we merged to the logging code were a good first
step, but there's still a bunch of work to do.

The issue is that a second-year student is expected to have
accomplished more than a first-timer.  We all know that taking on a
gsoc student doesn't guarantee that all the code will end up in the
project, but for a student to return to a project, there needs to be
clear evidence that over the previous year he did manage to contribute
significantly.

We'd talked about this a while ago, and as I said, the logging work is
a great first step, but I think you'll need to really complete the
rest of the console work.  Otherwise, it will be very hard for your
application to go through (remember, these will be reviewed by many
others from the PSF, who have access to your entire public commit
history both in your branches and in ipython).

I don't want to discourage you, just to give you a realistic picture
of the expectations of the program.

Best,

f


From andresete.chaos at gmail.com  Tue Mar  8 21:27:44 2011
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Tue, 8 Mar 2011 21:27:44 -0500
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTimqKtHL-q2LGKkamZf5nHsGRb79FSednqarJ0kH@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
	<AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>
	<AANLkTi=7G=NFSvuXrXgDk=DpYrGic2kyVFhhZMdmj8or@mail.gmail.com>
	<AANLkTimxQvMTQ7-hYnCsv7S6UXPZGk=n_4QOf-kyB+fj@mail.gmail.com>
	<AANLkTikt_hiNfy8Vc=CMu9cY-xTmWVp84mUxaa2hZAWU@mail.gmail.com>
	<AANLkTi=gb-EQt6LU12ay2Xain5y14ZOb+5zfF=uJ_v-t@mail.gmail.com>
	<AANLkTimqKtHL-q2LGKkamZf5nHsGRb79FSednqarJ0kH@mail.gmail.com>
Message-ID: <AANLkTikQo_uGupsjMRCeb5P96vcaS_XEcjS_WYc41vfq@mail.gmail.com>

Hi Fernando.
I am working in the terminal's frontend in this moment and I think I can
have it ready in the next days for review.
O.

2011/3/8 Fernando Perez <fperez.net at gmail.com>

> Hi Omar,
>
> 2011/3/8 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
> >
> > If you have suggestions to my application please let met know.
>
> Working on this would be great, but there's something I mentioned to
> you that will come up when others review your gsoc application, and
> that you need to consider: completing last year's work so that the
> console client is fully functional on top of the zmq code.  Your
> improvements that we merged to the logging code were a good first
> step, but there's still a bunch of work to do.
>
> The issue is that a second-year student is expected to have
> accomplished more than a first-timer.  We all know that taking on a
> gsoc student doesn't guarantee that all the code will end up in the
> project, but for a student to return to a project, there needs to be
> clear evidence that over the previous year he did manage to contribute
> significantly.
>
> We'd talked about this a while ago, and as I said, the logging work is
> a great first step, but I think you'll need to really complete the
> rest of the console work.  Otherwise, it will be very hard for your
> application to go through (remember, these will be reviewed by many
> others from the PSF, who have access to your entire public commit
> history both in your branches and in ipython).
>
> I don't want to discourage you, just to give you a realistic picture
> of the expectations of the program.
>
> Best,
>
> f
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110308/339ced91/attachment.html>

From fperez.net at gmail.com  Tue Mar  8 21:29:24 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 8 Mar 2011 18:29:24 -0800
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTikQo_uGupsjMRCeb5P96vcaS_XEcjS_WYc41vfq@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
	<AANLkTikJ68YrD5ez9D=HVFsCYDzAS7cp976wBoQVD09_@mail.gmail.com>
	<AANLkTi=7G=NFSvuXrXgDk=DpYrGic2kyVFhhZMdmj8or@mail.gmail.com>
	<AANLkTimxQvMTQ7-hYnCsv7S6UXPZGk=n_4QOf-kyB+fj@mail.gmail.com>
	<AANLkTikt_hiNfy8Vc=CMu9cY-xTmWVp84mUxaa2hZAWU@mail.gmail.com>
	<AANLkTi=gb-EQt6LU12ay2Xain5y14ZOb+5zfF=uJ_v-t@mail.gmail.com>
	<AANLkTimqKtHL-q2LGKkamZf5nHsGRb79FSednqarJ0kH@mail.gmail.com>
	<AANLkTikQo_uGupsjMRCeb5P96vcaS_XEcjS_WYc41vfq@mail.gmail.com>
Message-ID: <AANLkTi=quEwQJwdQ-xViTtNqvfkbWrA+XLYJzxquT6w1@mail.gmail.com>

2011/3/8 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>:
> I am working in the terminal's frontend in this moment and I think I can
> have it ready in the next days for review.

OK, that's excellent news then!  As I said, I don't want to discourage
you, just to give you all the information you'll need if you want to
put forward a good, competitive application.

Cheers,

f


From fperez.net at gmail.com  Tue Mar  8 21:42:38 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 8 Mar 2011 18:42:38 -0800
Subject: [IPython-dev] Google summer of code
In-Reply-To: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
References: <AANLkTi=qT_Q9Rr4q-uXHRK085i-xG4dGzHau+A1xKWj_@mail.gmail.com>
Message-ID: <AANLkTi=V+NAyngWvYfE5p2w_=_-ueLcLPQrv0eYQqiZ8@mail.gmail.com>

Howdy,

On Fri, Mar 4, 2011 at 2:32 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> Have we already, and do we want to, apply for Google summer of code
> projects? The deadline for mentoring organisations is now just one week away
> (Friday 11 March).
>
> http://www.google-melange.com/gsoc/org_app/take/gsoc_program/google/gsoc2011/orgapp

BTW, if we go for the psf, the relevant page is:

http://wiki.python.org/moin/SummerOfCode/2011

and we'd need to fill out this application to be a psf-umbrella project:

https://spreadsheets.google.com/viewform?formkey=dHh3WFNGYzkyWWE0ZjM1eFFoUUVGWmc6MQ

Cheers,

f


From takowl at gmail.com  Sat Mar 12 13:45:27 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sat, 12 Mar 2011 18:45:27 +0000
Subject: [IPython-dev] Prefiltering input - where and how?
Message-ID: <AANLkTimc_yatsm7G_L=b-zy1X8VASZzWu1QxP98Kr1qa@mail.gmail.com>

Hi all,

Robert found that calling macros caused problems with my new history system,
and suggested that they be expanded by prefiltering, so that the translated
history stores the macro content each time it's called. My attempt to do
that is here:
https://github.com/takluyver/ipython/tree/expand-macro

However, I ran into trouble with the execution model - it seems to compile
the macro in "single" mode, so only the first line gets executed. So I
peered into the execution code, and ended up somewhat confused. I'm hoping
someone can clarify:
- How much preprocessing is (and should be) done by IPython.core.prefilter
versus IPython.core.inputsplitter?
- As far as I can see in the code, only a single line statement actually
gets passed to prefilter. Yet prefiltering still seems to be going on if I
enter a multiline block - and I'm not quite sure how
- Should prefiltering be in the frontend or the core? I'm guessing the core,
but there's some prefiltering code in the terminal frontend, although I
think it's dead, because:
- Why does TerminalInteractiveShell have two raw_input methods defined? I'm
guessing the first one is older code: can I delete it to simplify matters?
It's still there in version control if we need to refer to it.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110312/f54c7f40/attachment.html>

From fperez.net at gmail.com  Sat Mar 12 16:57:28 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 12 Mar 2011 13:57:28 -0800
Subject: [IPython-dev] Prefiltering input - where and how?
In-Reply-To: <AANLkTimc_yatsm7G_L=b-zy1X8VASZzWu1QxP98Kr1qa@mail.gmail.com>
References: <AANLkTimc_yatsm7G_L=b-zy1X8VASZzWu1QxP98Kr1qa@mail.gmail.com>
Message-ID: <AANLkTikMq7N+_2f1we6B+TtJmS7nrqiy9VdSEjPKwGec@mail.gmail.com>

Hi Thomas,

On Sat, Mar 12, 2011 at 10:45 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> Hi all,
>
> Robert found that calling macros caused problems with my new history system,
> and suggested that they be expanded by prefiltering, so that the translated
> history stores the macro content each time it's called. My attempt to do
> that is here:
> https://github.com/takluyver/ipython/tree/expand-macro
>
> However, I ran into trouble with the execution model - it seems to compile
> the macro in "single" mode, so only the first line gets executed. So I
> peered into the execution code, and ended up somewhat confused. I'm hoping
> someone can clarify:

Ah, welcome to some of our prettiest code ;)

I'll do my best to explain, and any improvements on this front will be
very much welcome.  Things are somewhat cleaner than they used to be,
but I think with one more round of work we'll have finally a fairly
comprehensible system.

> - How much preprocessing is (and should be) done by IPython.core.prefilter
> versus IPython.core.inputsplitter?

prefilter is the OLD code, going all the way back to IPython's
beginning, where all processing was done in-line as the user typed it.
 inputsplitter was a recent attempt at rationalizing input handling,
that by and large has succeeded (even if it can still use some
cleanup).  The idea in inputsplitter is to first apply a set of static
transformations that are independent of anything in the user's
namespace, and which can all be tested/validated in a standalone
fashion.  This includes all explicitly escaped magics and similar
things, even in multiline blocks.  The old prefilter code was purely
line-oriented and very stateful, hence very difficult to test in
isolation.

> - As far as I can see in the code, only a single line statement actually
> gets passed to prefilter. Yet prefiltering still seems to be going on if I
> enter a multiline block - and I'm not quite sure how

Yes, all multiline blocks are transformed by inputsplitter.  If
there's a single-line input, it does get fed to prefilter, though,
since only single-line statements are allowed to execute things like
magics without prefixes.

The idea was: for single-line statements, we want the convenience of
things like 'run foo' without the '%' prefix.  But that requires
checking the current namespace, so that must be done by a method of
the actual engine that has the namespace, and that's what the old
prefilter code does.

All multiline statements are *only* processed by the inputsplitter
code, which has a reasonable test suite and can be validated in
isolation, as it is completely specified in terms of static
transformations that do not depend on any namespace.

> - Should prefiltering be in the frontend or the core? I'm guessing the core,
> but there's some prefiltering code in the terminal frontend, although I
> think it's dead, because:

Yes, prefiltering should be done in the core, because that's where the
actual namespace is.  For all we know, a frontend might not even be
python (i.e. JavaScript in a browser), and we don't want to add
communication calls for prefiltering, I think that would be
unnecessary added complexity.

> - Why does TerminalInteractiveShell have two raw_input methods defined? I'm
> guessing the first one is older code: can I delete it to simplify matters?
> It's still there in version control if we need to refer to it.

Yup, the older one is leftover, feel free to clean it.

Ultimately we do want to:

- improve inputsplitter further (it's still a bit convoluted, though
at least well specified and tested).
- shrink prefilter to the absolute minimum.  In the interest of
caution, when we wrote the inputsplitter code we left most of the old
stuff in place, but much of that is likely now unused.  There should
only be a tiny amount of code that applies the dynamic transforms all
in one place and nothing else.

This code has been refactored but we've tiptoed around deleting
anything, because it's so much at the heart of the execution loop.
But it's been a few months since we've been using the new system
mostly without problems, so I think now it's OK to be a bit more
aggressive in removing anything you see as good cleanup candidate.

I'm working this weekend on accumulated things for my day job, but
feel free to ping me if you need to meet on IRC/skype for short
questions on any of this, I don't want to stall you out.

Thanks!

f


From takowl at gmail.com  Sat Mar 12 19:22:56 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 13 Mar 2011 00:22:56 +0000
Subject: [IPython-dev] Prefiltering input - where and how?
In-Reply-To: <AANLkTikMq7N+_2f1we6B+TtJmS7nrqiy9VdSEjPKwGec@mail.gmail.com>
References: <AANLkTimc_yatsm7G_L=b-zy1X8VASZzWu1QxP98Kr1qa@mail.gmail.com>
	<AANLkTikMq7N+_2f1we6B+TtJmS7nrqiy9VdSEjPKwGec@mail.gmail.com>
Message-ID: <AANLkTinSp-WAon2je9Q7txt-t_uFJ=O3RGPNnCJwx168@mail.gmail.com>

Thanks for explaining all that, Fernando - it's very useful. So am I right
in thinking that the macro code should stay in prefilter, as it's dependent
on the namespace? And that the static transformers in IPython.core.prefilter
are redundant and can come out?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110313/8204ad15/attachment.html>

From fperez.net at gmail.com  Sat Mar 12 19:37:49 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 12 Mar 2011 16:37:49 -0800
Subject: [IPython-dev] Prefiltering input - where and how?
In-Reply-To: <AANLkTinSp-WAon2je9Q7txt-t_uFJ=O3RGPNnCJwx168@mail.gmail.com>
References: <AANLkTimc_yatsm7G_L=b-zy1X8VASZzWu1QxP98Kr1qa@mail.gmail.com>
	<AANLkTikMq7N+_2f1we6B+TtJmS7nrqiy9VdSEjPKwGec@mail.gmail.com>
	<AANLkTinSp-WAon2je9Q7txt-t_uFJ=O3RGPNnCJwx168@mail.gmail.com>
Message-ID: <AANLkTinZcpW8mqysg7MbvppkkLbu5H6qPVeTLoQ1FVP7@mail.gmail.com>

On Sat, Mar 12, 2011 at 4:22 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> Thanks for explaining all that, Fernando - it's very useful. So am I right
> in thinking that the macro code should stay in prefilter, as it's dependent
> on the namespace? And that the static transformers in IPython.core.prefilter
> are redundant and can come out?

Yes, from where I stand, I think that's correct.  Keep in mind however
that this is both core and brittle, nasty code, so tiptoe carefully.
If you can think of a small test to add before making a significant
change that would help validate what you're about to do, by all means
do so.

Thanks again for tackling the hard stuff!

f


From takowl at gmail.com  Sat Mar 12 19:41:07 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 13 Mar 2011 00:41:07 +0000
Subject: [IPython-dev] Prefiltering input - where and how?
In-Reply-To: <AANLkTinSp-WAon2je9Q7txt-t_uFJ=O3RGPNnCJwx168@mail.gmail.com>
References: <AANLkTimc_yatsm7G_L=b-zy1X8VASZzWu1QxP98Kr1qa@mail.gmail.com>
	<AANLkTikMq7N+_2f1we6B+TtJmS7nrqiy9VdSEjPKwGec@mail.gmail.com>
	<AANLkTinSp-WAon2je9Q7txt-t_uFJ=O3RGPNnCJwx168@mail.gmail.com>
Message-ID: <AANLkTikrohFunwxHz-Ex=JsDF3i_-kT5Vw+yUA7mq5bO@mail.gmail.com>

On 13 March 2011 00:22, Thomas Kluyver <takowl at gmail.com> wrote:

> Thanks for explaining all that, Fernando - it's very useful. So am I right
> in thinking that the macro code should stay in prefilter, as it's dependent
> on the namespace? And that the static transformers in IPython.core.prefilter
> are redundant and can come out?
>

Also, I see that run_one_block calls run_code with a string. Am I right in
thinking that it should call run_source, which expects strings?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110313/b15e5b83/attachment.html>

From fperez.net at gmail.com  Sat Mar 12 19:47:56 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 12 Mar 2011 16:47:56 -0800
Subject: [IPython-dev] Prefiltering input - where and how?
In-Reply-To: <AANLkTikrohFunwxHz-Ex=JsDF3i_-kT5Vw+yUA7mq5bO@mail.gmail.com>
References: <AANLkTimc_yatsm7G_L=b-zy1X8VASZzWu1QxP98Kr1qa@mail.gmail.com>
	<AANLkTikMq7N+_2f1we6B+TtJmS7nrqiy9VdSEjPKwGec@mail.gmail.com>
	<AANLkTinSp-WAon2je9Q7txt-t_uFJ=O3RGPNnCJwx168@mail.gmail.com>
	<AANLkTikrohFunwxHz-Ex=JsDF3i_-kT5Vw+yUA7mq5bO@mail.gmail.com>
Message-ID: <AANLkTi=aHU+CMrkMm1gxE+M6x2fxOXvA9c9O_Y9_6QUj@mail.gmail.com>

On Sat, Mar 12, 2011 at 4:41 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> Also, I see that run_one_block calls run_code with a string. Am I right in
> thinking that it should call run_source, which expects strings?
>

See you on IRC where I can help out...

f


From fperez.net at gmail.com  Sat Mar 12 19:53:15 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 12 Mar 2011 16:53:15 -0800
Subject: [IPython-dev] Prefiltering input - where and how?
In-Reply-To: <AANLkTikrohFunwxHz-Ex=JsDF3i_-kT5Vw+yUA7mq5bO@mail.gmail.com>
References: <AANLkTimc_yatsm7G_L=b-zy1X8VASZzWu1QxP98Kr1qa@mail.gmail.com>
	<AANLkTikMq7N+_2f1we6B+TtJmS7nrqiy9VdSEjPKwGec@mail.gmail.com>
	<AANLkTinSp-WAon2je9Q7txt-t_uFJ=O3RGPNnCJwx168@mail.gmail.com>
	<AANLkTikrohFunwxHz-Ex=JsDF3i_-kT5Vw+yUA7mq5bO@mail.gmail.com>
Message-ID: <AANLkTikpjWGb_Y8US9ZryS0RDYbeY89mTibDuESGeJ8B@mail.gmail.com>

On Sat, Mar 12, 2011 at 4:41 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> Also, I see that run_one_block calls run_code with a string. Am I right in
> thinking that it should call run_source, which expects strings?
>

For the record in case anyone searches later, Thomas was correct but
that change was already committed:

https://github.com/ipython/ipython/commit/de4ba654e16782f96cab589c411fccdd9e5eb167

He was just working off an older branch.  Indeed, the old use of
run_code there was a bug.

Good eye :)

f


From fperez.net at gmail.com  Sat Mar 12 21:36:32 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 12 Mar 2011 18:36:32 -0800
Subject: [IPython-dev] %doctest_mode in qtconsole
In-Reply-To: <AANLkTinVWnZ0g=R=RePFgQpx-JvkDkv9Gx5gxaUjwDZc@mail.gmail.com>
References: <AANLkTinVWnZ0g=R=RePFgQpx-JvkDkv9Gx5gxaUjwDZc@mail.gmail.com>
Message-ID: <AANLkTikk9+rtJtCybX-BvxJ-b8MvRjL8TbnQdKgXmDYc@mail.gmail.com>

Hey Brian,

On Sun, Jan 9, 2011 at 10:08 AM, Brian Granger <ellisonbg at gmail.com> wrote:
>
> I am updating some of flags that control pretty printing and that led
> me to the %doctest_mode magic. ?Updating the version of this for the
> terminal based IPython went find, but when I did the qtconsole
> version, I noticed that the frontend doesn't handle the prompt mode
> changes that are sent back in the payload. ?I could have sworn that
> this was implemented and that %doctest_mode worked fully in the
> qtconsole. ?What is the status of this?

sorry, just caught up with this... No, you remember wrong: in fact,
the doctest_mode magic was about the only thing we didn't correctly
port over to the qt console, and precisely for this reason.  Since it
involves changing the prompt handling, and we've decided to make
prompts a client-side thing rather than hardcode them in the kernel,
it will require some design/thinking about how we want to communicate
this kind of information to clients, as well as code in the Qt client
to do something about it.

That was pretty much the only magic we left out from functioning
correctly in the Qt console, I'm afraid.

Cheers,

f


From fperez.net at gmail.com  Sun Mar 13 03:06:49 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sat, 12 Mar 2011 23:06:49 -0800
Subject: [IPython-dev] 0.10.2.rc1 ready for testing.
Message-ID: <AANLkTikMjP7UZ=q9A6Oj92bqvPy3EAvGW4ZdmP5nER98@mail.gmail.com>

Hi everyone,

while we want to get 0.11 out asap, all non-github users out there,
including all distros (linux, epd, pythonxy, etc) are still using the
0.10.x series, and we'd like to ensure it's in as good shape as
possible with our *very* limited manpower.

I've put up at

http://ipython.scipy.org/dist/testing/

the files for a release candidate for 0.10.2.  I've gone through our
bug tracker and applied everything that had a patch/pull
request/solution that listed explicitly 0.10, so that should catch
most things.  I think I closed around 15 new bugs quickly, though I
also managed to find this nasty bit in master/0.11 while testing:
https://github.com/ipython/ipython/issues/290.  If anyone wants to
tackle that, by all means...  Thanks to everyone who had included
solutions or patches in the bug reports, I used many of those and
tried to ensure proper credit in the commit messages.

I'll be happy to apply any further small, self-contained, tested fixes
if you have them, but we can't really embark on any major work for
0.10.2.

The nasty gtk blocking problem we had is, to the best of my knowledge,
fully fixed here (thanks to P. Ivanov, M. Voorhies and others who
helped!).

I'll leave this up for a week or so, would appreciate reports of any
problems you may find.  Hopefully there won't be many, as I tried to
apply only clear fixes over 0.10.1, and no new features, but you never
know.

If all goes well, and time permitting, we can use this to cut 0.10.2
next week.  This will allow the core team to focus now on merging all
the remaining work and pull requests to really push 0.11 out, where
all the major development of the last 18 months has gone.

Cheers,

f


From pivanov314 at gmail.com  Sun Mar 13 07:13:19 2011
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Sun, 13 Mar 2011 04:13:19 -0700
Subject: [IPython-dev] 0.10.2.rc1 ready for testing.
In-Reply-To: <AANLkTikMjP7UZ=q9A6Oj92bqvPy3EAvGW4ZdmP5nER98@mail.gmail.com>
References: <AANLkTikMjP7UZ=q9A6Oj92bqvPy3EAvGW4ZdmP5nER98@mail.gmail.com>
Message-ID: <20110313111319.GU3658@ykcyc>

Fernando Perez, on 2011-03-12 23:06,  wrote:
> The nasty gtk blocking problem we had is, to the best of my knowledge,
> fully fixed here (thanks to P. Ivanov, M. Voorhies and others who
> helped!).

speaking of which, I feel like I'm going cross-eyed with this bug,
so maybe this isn't a problem and should be considered user error
(I'll sleep on it before I look at what behavior should be
expected from matplotlib when the rcParam['interactive'] is set
to False), but the following short little script screws
up GTK threading, for me.

-----
import matplotlib
matplotlib.use("GTKAgg")
import matplotlib.pyplot as plt
#plt.interactive(True) # uncomment to fix
plt.plot(range(10))
plt.show() # looks fine
plt.close()
plt.plot([2,1,2]) # this will timeout
plt.show() # grey window, no toolbar drawn
-----

I think in our testing, Mark and I only checked if the first
figure worked, not the second. The above script doesn't seem to
cause issues if called with -pylab (which makes me think the
above just falls under user error) or when using just -wthread
with matplotlib.use("WXAgg").

I just wanted to send a brief note, hopefully it'll all be clear
in the morning.
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110313/efeaba38/attachment.sig>

From takowl at gmail.com  Sun Mar 13 12:26:04 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 13 Mar 2011 16:26:04 +0000
Subject: [IPython-dev] Multiple outputs per input line
Message-ID: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>

I realised that it's possible to get multiple outputs from a single input
line. Most trivially, you can do "for a in range(5): a", to produce 5
outputs. At present, this crashes my sqlite-history branch if output logging
is enabled, because it expects each output item to have a unique session and
line number. In fact, the session output history doesn't really expect it
either: it only stores the last result.

It should be simple enough to catch the error in writing to the database,
and only store the first result, or to use an SQL update statement so we
only store the last result. Is that good enough for what I think is a fairly
unusual case? Or do we want to work out a way of storing all the outputs
from a command? Robert, logging output to the database was your suggestion,
so perhaps you've got an opinion?

(Of course, I can relax the restriction that session and line number must
together be unique, but then getting useful information from the database
becomes trickier.)

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110313/dbd6fa85/attachment.html>

From fperez.net at gmail.com  Sun Mar 13 16:56:00 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Sun, 13 Mar 2011 13:56:00 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
Message-ID: <AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>

On Sun, Mar 13, 2011 at 9:26 AM, Thomas Kluyver <takowl at gmail.com> wrote:
> I realised that it's possible to get multiple outputs from a single input
> line. Most trivially, you can do "for a in range(5): a", to produce 5
> outputs. At present, this crashes my sqlite-history branch if output logging
> is enabled, because it expects each output item to have a unique session and
> line number. In fact, the session output history doesn't really expect it
> either: it only stores the last result.
>
> It should be simple enough to catch the error in writing to the database,
> and only store the first result, or to use an SQL update statement so we
> only store the last result. Is that good enough for what I think is a fairly
> unusual case? Or do we want to work out a way of storing all the outputs
> from a command? Robert, logging output to the database was your suggestion,
> so perhaps you've got an opinion?
>
> (Of course, I can relax the restriction that session and line number must
> together be unique, but then getting useful information from the database
> becomes trickier.)

One thing we could do (that's what mathematica uses) is to simply
increase the counter every time an *output* is produced.   The logic
does get a little more complex, but it lets us retain uniqueness
throughout.  What do you think?

f


From takowl at gmail.com  Sun Mar 13 18:11:10 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 13 Mar 2011 22:11:10 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
Message-ID: <AANLkTim0Kn4iPSc=XwcTk-JeKR2M84-TF-0kBvuy1Lse@mail.gmail.com>

On 13 March 2011 20:56, Fernando Perez <fperez.net at gmail.com> wrote:

> One thing we could do (that's what mathematica uses) is to simply
> increase the counter every time an *output* is produced.   The logic
> does get a little more complex, but it lets us retain uniqueness
> throughout.  What do you think?
>

But many inputs don't produce any output, so we'd have to increment the
counter on every input or output, which just feels...unwieldy. I think the
numbering system we've got now, with one number per input cell, makes most
sense. It means if you do "%macro thing 5-10", you know you're getting 6
commands. That said, I've never used Mathematica, so I don't know how neatly
it works there.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110313/be247cf6/attachment.html>

From benjaminrk at gmail.com  Sun Mar 13 18:17:40 2011
From: benjaminrk at gmail.com (MinRK)
Date: Sun, 13 Mar 2011 15:17:40 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTim0Kn4iPSc=XwcTk-JeKR2M84-TF-0kBvuy1Lse@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTim0Kn4iPSc=XwcTk-JeKR2M84-TF-0kBvuy1Lse@mail.gmail.com>
Message-ID: <AANLkTikEofdjLyQ9D99a6PYczgmG7Eke8uH3k5_90r6S@mail.gmail.com>

output is a separate table, right?

I think I'm in favor of the input-id not being unique in the output
table, and just returning a list (None if len 0, or the element if the
list is length 1).

-MinRK

On Sun, Mar 13, 2011 at 15:11, Thomas Kluyver <takowl at gmail.com> wrote:
> On 13 March 2011 20:56, Fernando Perez <fperez.net at gmail.com> wrote:
>>
>> One thing we could do (that's what mathematica uses) is to simply
>> increase the counter every time an *output* is produced. ? The logic
>> does get a little more complex, but it lets us retain uniqueness
>> throughout. ?What do you think?
>
> But many inputs don't produce any output, so we'd have to increment the
> counter on every input or output, which just feels...unwieldy. I think the
> numbering system we've got now, with one number per input cell, makes most
> sense. It means if you do "%macro thing 5-10", you know you're getting 6
> commands. That said, I've never used Mathematica, so I don't know how neatly
> it works there.
>
> Thomas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>


From takowl at gmail.com  Sun Mar 13 18:30:30 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Sun, 13 Mar 2011 22:30:30 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTikEofdjLyQ9D99a6PYczgmG7Eke8uH3k5_90r6S@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTim0Kn4iPSc=XwcTk-JeKR2M84-TF-0kBvuy1Lse@mail.gmail.com>
	<AANLkTikEofdjLyQ9D99a6PYczgmG7Eke8uH3k5_90r6S@mail.gmail.com>
Message-ID: <AANLkTi=DXOX1mv44zuA2JMtgJNXMcBPyi-5TphkkFivT@mail.gmail.com>

On 13 March 2011 22:17, MinRK <benjaminrk at gmail.com> wrote:

> output is a separate table, right?
>

Right.

I think I'm in favor of the input-id not being unique in the output
> table, and just returning a list (None if len 0, or the element if the
> list is length 1).
>

I would still return a list for a single item, because it makes the code
more consistent (e.g. you can do "\n".join(outputitems)). But if we go down
that route, I'll probably serialise the list as JSON and store it in single
rows - then the input and output tables can still be connected using SQL
join, rather than some fancy Python logic.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110313/8dedc267/attachment.html>

From ellisonbg at gmail.com  Mon Mar 14 01:32:32 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Sun, 13 Mar 2011 22:32:32 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
Message-ID: <AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>

> On Sun, Mar 13, 2011 at 9:26 AM, Thomas Kluyver <takowl at gmail.com> wrote:
>> I realised that it's possible to get multiple outputs from a single input
>> line. Most trivially, you can do "for a in range(5): a", to produce 5
>> outputs. At present, this crashes my sqlite-history branch if output logging
>> is enabled, because it expects each output item to have a unique session and
>> line number. In fact, the session output history doesn't really expect it
>> either: it only stores the last result.

Our model of output is that it is a continuous stream that can happen
at any moment in time and which can be completely uncorrelated with
particular input lines.  The history should reflect this reality.

>> It should be simple enough to catch the error in writing to the database,
>> and only store the first result, or to use an SQL update statement so we
>> only store the last result. Is that good enough for what I think is a fairly
>> unusual case? Or do we want to work out a way of storing all the outputs
>> from a command? Robert, logging output to the database was your suggestion,
>> so perhaps you've got an opinion?

If we are going to log output, we should log everything in stream format.

>> (Of course, I can relax the restriction that session and line number must
>> together be unique, but then getting useful information from the database
>> becomes trickier.)
>
> One thing we could do (that's what mathematica uses) is to simply
> increase the counter every time an *output* is produced. ? The logic
> does get a little more complex, but it lets us retain uniqueness
> throughout. ?What do you think?

I think that would get quite difficult.  Mathematica's notion of
output is very specific and concrete (they basically trigger a
displayhook on every assignment).  Our notion of "output" now is very
dynamic - especially when you mix multiple frontends into the picture.

Brian

> f
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com


From fperez.net at gmail.com  Mon Mar 14 04:11:48 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 14 Mar 2011 01:11:48 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
Message-ID: <AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>

On Sun, Mar 13, 2011 at 10:32 PM, Brian Granger <ellisonbg at gmail.com> wrote:
> I think that would get quite difficult. ?Mathematica's notion of
> output is very specific and concrete (they basically trigger a
> displayhook on every assignment). ?Our notion of "output" now is very
> dynamic - especially when you mix multiple frontends into the picture.
>

Remember, we're talking here about the outputs that get produced by
the displayhook, for those we do have numbers we can track (because
they stem from sys.displayhook firing).  You're completely correct
that we can't number display side effects, like print statements or
any of the products of the new display system.  But the return value
of computations, which is what Out[N] contains, we can track.

The logic for getting mathematica-like numbering is pretty easy:

- prior to code execution, the kernel sets an offset in the display hook to 0.
- on each call to displayhook, it does:
  execution_counter += offset
  offset+=1

With this, in all cases where only a single call is made to
displayhook get matching numbers, but if a displayhook fires multiple
times for a single input, then the counter is incremented accordingly.

This would let us have always unambiguous storage of outputs by number
even if multiple outputs were produced.  The only change would be that
in such a scenario, the next input wouldn't be 'previous+1' but
instead it would be incremented by as many outputs as came out.

Because Python isn't a purely functional language, we'll always have a
distinction between the Out[] things that we can see go by on
displayhook and other uncontrolled side-effects (prints, plots, etc).
But so far, having numbered outputs for functional results has served
us well, so this would simply be a matter of refining that to better
handle the multi-output cases (which today we don't handle very well,
as Thomas discovered).

Cheers,

f


From fperez.net at gmail.com  Mon Mar 14 04:13:13 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 14 Mar 2011 01:13:13 -0700
Subject: [IPython-dev] 0.10.2.rc1 ready for testing.
In-Reply-To: <20110313111319.GU3658@ykcyc>
References: <AANLkTikMjP7UZ=q9A6Oj92bqvPy3EAvGW4ZdmP5nER98@mail.gmail.com>
	<20110313111319.GU3658@ykcyc>
Message-ID: <AANLkTikuQdNd7mE9bkH8WYBPiMeRz-WrCRMSMq+u-PPv@mail.gmail.com>

Hey Paul,

On Sun, Mar 13, 2011 at 4:13 AM, Paul Ivanov <pivanov314 at gmail.com> wrote:
> Fernando Perez, on 2011-03-12 23:06, ?wrote:
>> The nasty gtk blocking problem we had is, to the best of my knowledge,
>> fully fixed here (thanks to P. Ivanov, M. Voorhies and others who
>> helped!).
>
> speaking of which, I feel like I'm going cross-eyed with this bug,
> so maybe this isn't a problem and should be considered user error
> (I'll sleep on it before I look at what behavior should be
> expected from matplotlib when the rcParam['interactive'] is set
> to False), but the following short little script screws
> up GTK threading, for me.
>
> -----
> import matplotlib
> matplotlib.use("GTKAgg")
> import matplotlib.pyplot as plt
> #plt.interactive(True) # uncomment to fix
> plt.plot(range(10))
> plt.show() # looks fine
> plt.close()
> plt.plot([2,1,2]) # this will timeout
> plt.show() # grey window, no toolbar drawn
> -----
>
> I think in our testing, Mark and I only checked if the first
> figure worked, not the second. The above script doesn't seem to
> cause issues if called with -pylab (which makes me think the
> above just falls under user error) or when using just -wthread
> with matplotlib.use("WXAgg").

Keep in mind that what you describe is perfectly OK: we never expected
the above to work without -pylab.  So as long as things do work
correctly when people do call -pylab, without any blocking or other
issues, we're in the clear.

Does that make sense?

f


From takowl at gmail.com  Mon Mar 14 06:59:59 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 14 Mar 2011 10:59:59 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
Message-ID: <AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>

On 14 March 2011 08:11, Fernando Perez <fperez.net at gmail.com> wrote:

>
> This would let us have always unambiguous storage of outputs by number
> even if multiple outputs were produced.  The only change would be that
> in such a scenario, the next input wouldn't be 'previous+1' but
> instead it would be incremented by as many outputs as came out.
>

To my mind, the principle of least surprise suggests that inputs should be
consecutively numbered, and output numbers should match up to their input
numbers. That also makes it simple to later match up corresponding inputs
and outputs. Of course, we could match up based on interleaving a sequence
of input and output, but it seems needlessly complex.

I can see how I'd implement storing multiple outputs if we want to do so -
the outputs from one input command would go together in a list. If we think
this is worth doing, I'll go and write it. I'm just checking whether we want
the extra complexity, because I don't believe I've ever used multiple
outputs until I was fiddling around yesterday.

In fact, having thought about how I would do it, I'll code it up in a bit,
and we can discuss a real system, rather than a hypothetical one.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110314/1771c037/attachment.html>

From takowl at gmail.com  Mon Mar 14 09:38:28 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 14 Mar 2011 13:38:28 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>
Message-ID: <AANLkTimSKfEmun2mwQ1f8V=QBH7b9ht=KEFFOLP-qXaZ@mail.gmail.com>

On 14 March 2011 10:59, Thomas Kluyver <takowl at gmail.com> wrote:

> In fact, having thought about how I would do it, I'll code it up in a bit,
> and we can discuss a real system, rather than a hypothetical one.


Right, that kept me occupied over lunch. Take a look at the code:
https://github.com/takluyver/ipython/commit/498d9f5596113a9817b9a2fa4a14314c14bb7439

Informal tests suggest that it's behaving as expected, but by all means pull
the code and hunt for corner cases. If we're happy with this approach, I'll
add some simple unit testing.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110314/0ffafd05/attachment.html>

From robert.kern at gmail.com  Mon Mar 14 12:39:16 2011
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 14 Mar 2011 11:39:16 -0500
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTimSKfEmun2mwQ1f8V=QBH7b9ht=KEFFOLP-qXaZ@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>	<AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>
	<AANLkTimSKfEmun2mwQ1f8V=QBH7b9ht=KEFFOLP-qXaZ@mail.gmail.com>
Message-ID: <illgbk$bq1$1@dough.gmane.org>

On 3/14/11 8:38 AM, Thomas Kluyver wrote:
> On 14 March 2011 10:59, Thomas Kluyver <takowl at gmail.com
> <mailto:takowl at gmail.com>> wrote:
>
>     In fact, having thought about how I would do it, I'll code it up in a bit,
>     and we can discuss a real system, rather than a hypothetical one.
>
>
> Right, that kept me occupied over lunch. Take a look at the code:
> https://github.com/takluyver/ipython/commit/498d9f5596113a9817b9a2fa4a14314c14bb7439
>
> Informal tests suggest that it's behaving as expected, but by all means pull the
> code and hunt for corner cases. If we're happy with this approach, I'll add some
> simple unit testing.

I really don't think we want the Out[] variable to have lists of things. That's 
really annoying for the most common case and would break long-standing usage. 
Having multiple displayhook calls is almost always an accident (e.g. usually you 
make a function call for its side effects even if it returns something not 
None), not an intentional act. I think the current behavior is perfectly fine:

In [1]: for i in range(3):
    ...:     i
    ...:
Out[1]: 0
Out[1]: 1
Out[1]: 2

In [2]: Out[1]
Out[2]: 2


That said, for the recording of displayhook outputs in *history*, we may as well 
record all of the the things sent to the displayhook. In the SQLite history, you 
can do this by just using a dummy autoincrementing primary key for the table and 
letting the (session, line) columns be non-unique.

-- 
Robert Kern

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



From fperez.net at gmail.com  Mon Mar 14 12:50:53 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Mon, 14 Mar 2011 09:50:53 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <illgbk$bq1$1@dough.gmane.org>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>
	<AANLkTimSKfEmun2mwQ1f8V=QBH7b9ht=KEFFOLP-qXaZ@mail.gmail.com>
	<illgbk$bq1$1@dough.gmane.org>
Message-ID: <AANLkTik2c3JUNjC8is4XaEFXsvVvJA4bdfAYQ4FhPkAR@mail.gmail.com>

On Mon, Mar 14, 2011 at 9:39 AM, Robert Kern <robert.kern at gmail.com> wrote:
> I really don't think we want the Out[] variable to have lists of things. That's
> really annoying for the most common case and would break long-standing usage.

Totally agreed.

Cheers,

f


From ellisonbg at gmail.com  Mon Mar 14 13:01:04 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 14 Mar 2011 10:01:04 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
Message-ID: <AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>

Hi,

>> I think that would get quite difficult. ?Mathematica's notion of
>> output is very specific and concrete (they basically trigger a
>> displayhook on every assignment). ?Our notion of "output" now is very
>> dynamic - especially when you mix multiple frontends into the picture.
>>
>
> Remember, we're talking here about the outputs that get produced by
> the displayhook, for those we do have numbers we can track (because
> they stem from sys.displayhook firing). ?You're completely correct
> that we can't number display side effects, like print statements or
> any of the products of the new display system. ?But the return value
> of computations, which is what Out[N] contains, we can track.

I am a bit confused then.  I thought we had removed the possibility
for displayhook to be called more than once per input.  I seem to
remember that you removed that when you were working on the input
splitter and execution logic last summer.  What am I missing.  I do
agree that it is a bit different if we are only talking about the
displayhook part of the logic.

> The logic for getting mathematica-like numbering is pretty easy:
>
> - prior to code execution, the kernel sets an offset in the display hook to 0.
> - on each call to displayhook, it does:
> ?execution_counter += offset
> ?offset+=1

Yep.

> With this, in all cases where only a single call is made to
> displayhook get matching numbers, but if a displayhook fires multiple
> times for a single input, then the counter is incremented accordingly.

This is definitely an unambiguous way of handling it. I have always
found it a bit awkward to have Out incrementing this way in
Mathematica though.

> This would let us have always unambiguous storage of outputs by number
> even if multiple outputs were produced. ?The only change would be that
> in such a scenario, the next input wouldn't be 'previous+1' but
> instead it would be incremented by as many outputs as came out.

Right.

> Because Python isn't a purely functional language, we'll always have a
> distinction between the Out[] things that we can see go by on
> displayhook and other uncontrolled side-effects (prints, plots, etc).
> But so far, having numbered outputs for functional results has served
> us well, so this would simply be a matter of refining that to better
> handle the multi-output cases (which today we don't handle very well,
> as Thomas discovered).

I agree, but let's clarify why the multiple Out per In is even
relevant (I thought it was impossible now).

Cheers,

Brian

> Cheers,
>
> f
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com


From robert.kern at gmail.com  Mon Mar 14 13:03:40 2011
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 14 Mar 2011 12:03:40 -0500
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
Message-ID: <illhpc$jcp$1@dough.gmane.org>

On 3/14/11 12:01 PM, Brian Granger wrote:
> Hi,
>
>>> I think that would get quite difficult.  Mathematica's notion of
>>> output is very specific and concrete (they basically trigger a
>>> displayhook on every assignment).  Our notion of "output" now is very
>>> dynamic - especially when you mix multiple frontends into the picture.
>>>
>>
>> Remember, we're talking here about the outputs that get produced by
>> the displayhook, for those we do have numbers we can track (because
>> they stem from sys.displayhook firing).  You're completely correct
>> that we can't number display side effects, like print statements or
>> any of the products of the new display system.  But the return value
>> of computations, which is what Out[N] contains, we can track.
>
> I am a bit confused then.  I thought we had removed the possibility
> for displayhook to be called more than once per input.  I seem to
> remember that you removed that when you were working on the input
> splitter and execution logic last summer.  What am I missing.  I do
> agree that it is a bit different if we are only talking about the
> displayhook part of the logic.

Well, if you removed it, it's back. Try 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 takowl at gmail.com  Mon Mar 14 13:04:34 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 14 Mar 2011 17:04:34 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTimQPXtowszx=Xi3CYVBTC-=OHyZK3wtj+icC0yZ@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>
	<AANLkTimSKfEmun2mwQ1f8V=QBH7b9ht=KEFFOLP-qXaZ@mail.gmail.com>
	<illgbk$bq1$1@dough.gmane.org>
	<AANLkTimQPXtowszx=Xi3CYVBTC-=OHyZK3wtj+icC0yZ@mail.gmail.com>
Message-ID: <AANLkTi=vwEAdBysyePJWQASVPnpeV_pQXO0XVxttOes-@mail.gmail.com>

[Apologies, meant to post this to list. Thanks, Robert, for pointing it out]

On 14 March 2011 16:53, Thomas Kluyver <takowl at gmail.com> wrote:

> On 14 March 2011 16:39, Robert Kern <robert.kern at gmail.com> wrote:
>
>> I really don't think we want the Out[] variable to have lists of things.
>> That's
>> really annoying for the most common case and would break long-standing
>> usage.
>> Having multiple displayhook calls is almost always an accident (e.g.
>> usually you
>> make a function call for its side effects even if it returns something not
>> None), not an intentional act. I think the current behavior is perfectly
>> fine:
>>
>
> At present, the Out variable in the user namespace is the same object as
> the stored output history from the current session. I think the best way is
> if I separate these.
>
>
>> That said, for the recording of displayhook outputs in *history*, we may
>> as well
>> record all of the the things sent to the displayhook. In the SQLite
>> history, you
>> can do this by just using a dummy autoincrementing primary key for the
>> table and
>> letting the (session, line) columns be non-unique.
>>
>
> I tried this, but it would need additional logic in Python to display the
> inputs and outputs in the right sequence. I prefer the system I've written,
> where (session, line) is unique, and the outputs for each command are
> serialised as JSON. Inputs and outputs are conveniently paired by SQL JOIN,
> and it's trivial to display them correctly.
>
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110314/47b55e68/attachment.html>

From ellisonbg at gmail.com  Mon Mar 14 13:10:22 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 14 Mar 2011 10:10:22 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <illhpc$jcp$1@dough.gmane.org>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
Message-ID: <AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>

>>>> I think that would get quite difficult. ?Mathematica's notion of
>>>> output is very specific and concrete (they basically trigger a
>>>> displayhook on every assignment). ?Our notion of "output" now is very
>>>> dynamic - especially when you mix multiple frontends into the picture.
>>>>
>>>
>>> Remember, we're talking here about the outputs that get produced by
>>> the displayhook, for those we do have numbers we can track (because
>>> they stem from sys.displayhook firing). ?You're completely correct
>>> that we can't number display side effects, like print statements or
>>> any of the products of the new display system. ?But the return value
>>> of computations, which is what Out[N] contains, we can track.
>>
>> I am a bit confused then. ?I thought we had removed the possibility
>> for displayhook to be called more than once per input. ?I seem to
>> remember that you removed that when you were working on the input
>> splitter and execution logic last summer. ?What am I missing. ?I do
>> agree that it is a bit different if we are only talking about the
>> displayhook part of the logic.
>
> Well, if you removed it, it's back. Try it.

I wasn't the one that removed this originally (Fernando did the work
after discussions with Evan and myself), but you are right:

In [2]: for i in range(5):
   ...:     i
   ...:
Out[2]: 0
Out[2]: 1
Out[2]: 2
Out[2]: 3
Out[2]: 4

Is this a deliberate move back to this or an unwanted regression?

Cheers,

Brian


From takowl at gmail.com  Mon Mar 14 13:20:29 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 14 Mar 2011 17:20:29 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
Message-ID: <AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>

OK, once again, code:
https://github.com/takluyver/ipython/commit/0c7eb96f95bbe19b30171d9a51262ec4a01656f0

As Robert suggests, this keeps only the last of several outputs in Out / _oh
in the user namespace, while keeping all outputs to be retrieved by %hist.
Again, I've done fairly superficial tests.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110314/b6cc5617/attachment.html>

From robert.kern at gmail.com  Mon Mar 14 13:22:49 2011
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 14 Mar 2011 12:22:49 -0500
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTi=vwEAdBysyePJWQASVPnpeV_pQXO0XVxttOes-@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>	<AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>	<AANLkTimSKfEmun2mwQ1f8V=QBH7b9ht=KEFFOLP-qXaZ@mail.gmail.com>	<illgbk$bq1$1@dough.gmane.org>	<AANLkTimQPXtowszx=Xi3CYVBTC-=OHyZK3wtj+icC0yZ@mail.gmail.com>
	<AANLkTi=vwEAdBysyePJWQASVPnpeV_pQXO0XVxttOes-@mail.gmail.com>
Message-ID: <illit9$2hf$1@dough.gmane.org>

On 3/14/11 12:04 PM, Thomas Kluyver wrote:
> [Apologies, meant to post this to list. Thanks, Robert, for pointing it out]
>
> On 14 March 2011 16:53, Thomas Kluyver <takowl at gmail.com
> <mailto:takowl at gmail.com>> wrote:
>
>     On 14 March 2011 16:39, Robert Kern <robert.kern at gmail.com
>     <mailto:robert.kern at gmail.com>> wrote:
>
>         I really don't think we want the Out[] variable to have lists of things.
>         That's
>         really annoying for the most common case and would break long-standing
>         usage.
>         Having multiple displayhook calls is almost always an accident (e.g.
>         usually you
>         make a function call for its side effects even if it returns something not
>         None), not an intentional act. I think the current behavior is perfectly
>         fine:
>
>
>     At present, the Out variable in the user namespace is the same object as the
>     stored output history from the current session. I think the best way is if I
>     separate these.
>
>         That said, for the recording of displayhook outputs in *history*, we may
>         as well
>         record all of the the things sent to the displayhook. In the SQLite
>         history, you
>         can do this by just using a dummy autoincrementing primary key for the
>         table and
>         letting the (session, line) columns be non-unique.
>
>
>     I tried this, but it would need additional logic in Python to display the
>     inputs and outputs in the right sequence. I prefer the system I've written,
>     where (session, line) is unique, and the outputs for each command are
>     serialised as JSON. Inputs and outputs are conveniently paired by SQL JOIN,
>     and it's trivial to display them correctly.

You would just ORDER BY the autoincrementing primary key.

But anyways, as Brian points out, we did decide some time ago that exactly one 
output should go to the displayhook, and the current behavior is probably a 
regression. For the SQLite history, just use the last one.

-- 
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 takowl at gmail.com  Mon Mar 14 13:40:02 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 14 Mar 2011 17:40:02 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <illit9$2hf$1@dough.gmane.org>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>
	<AANLkTimSKfEmun2mwQ1f8V=QBH7b9ht=KEFFOLP-qXaZ@mail.gmail.com>
	<illgbk$bq1$1@dough.gmane.org>
	<AANLkTimQPXtowszx=Xi3CYVBTC-=OHyZK3wtj+icC0yZ@mail.gmail.com>
	<AANLkTi=vwEAdBysyePJWQASVPnpeV_pQXO0XVxttOes-@mail.gmail.com>
	<illit9$2hf$1@dough.gmane.org>
Message-ID: <AANLkTi=AKNrPg+BmA8m96fbtVWBpRhd_nKJB5ZmsWv7d@mail.gmail.com>

On 14 March 2011 17:22, Robert Kern <robert.kern at gmail.com> wrote:

> You would just ORDER BY the autoincrementing primary key.
>

Indeed. And then fold together the outputs matching a single input. But I
prefer it the way I've done it.

 But anyways, as Brian points out, we did decide some time ago that exactly
> one
> output should go to the displayhook, and the current behavior is probably a
> regression. For the SQLite history, just use the last one.
>

OK. I'll leave it as is for now, because I can get the multiple outputs at a
plain Python prompt, so it doesn't seem immediately "wrong". If we do remove
that possibility, I'll put it back to assuming single outputs.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110314/ba8e41f4/attachment.html>

From robert.kern at gmail.com  Mon Mar 14 14:44:01 2011
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 14 Mar 2011 13:44:01 -0500
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>	<illhpc$jcp$1@dough.gmane.org>	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
Message-ID: <illnlj$5kr$1@dough.gmane.org>

On 3/14/11 12:20 PM, Thomas Kluyver wrote:
> OK, once again, code:
> https://github.com/takluyver/ipython/commit/0c7eb96f95bbe19b30171d9a51262ec4a01656f0
>
> As Robert suggests, this keeps only the last of several outputs in Out / _oh in
> the user namespace, while keeping all outputs to be retrieved by %hist. Again,
> I've done fairly superficial tests.

I'm not sure what you are doing here. Out/_oh should be storing the actual 
objects. The history should be storing the formatted text from the displayhook; 
you should not try to use repr() on those objects afterwards. That records the 
wrong thing.

-- 
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 robert.kern at gmail.com  Mon Mar 14 14:46:30 2011
From: robert.kern at gmail.com (Robert Kern)
Date: Mon, 14 Mar 2011 13:46:30 -0500
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTi=AKNrPg+BmA8m96fbtVWBpRhd_nKJB5ZmsWv7d@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>	<AANLkTinuRecbmC0d9CS-ww_5MLmR6ZJAOm0+Bux5HM5T@mail.gmail.com>	<AANLkTimSKfEmun2mwQ1f8V=QBH7b9ht=KEFFOLP-qXaZ@mail.gmail.com>	<illgbk$bq1$1@dough.gmane.org>	<AANLkTimQPXtowszx=Xi3CYVBTC-=OHyZK3wtj+icC0yZ@mail.gmail.com>	<AANLkTi=vwEAdBysyePJWQASVPnpeV_pQXO0XVxttOes-@mail.gmail.com>	<illit9$2hf$1@dough.gmane.org>
	<AANLkTi=AKNrPg+BmA8m96fbtVWBpRhd_nKJB5ZmsWv7d@mail.gmail.com>
Message-ID: <illnq6$5kr$2@dough.gmane.org>

On 3/14/11 12:40 PM, Thomas Kluyver wrote:
> On 14 March 2011 17:22, Robert Kern <robert.kern at gmail.com
> <mailto:robert.kern at gmail.com>> wrote:
>
>     You would just ORDER BY the autoincrementing primary key.
>
>
> Indeed. And then fold together the outputs matching a single input. But I prefer
> it the way I've done it.
>
>     But anyways, as Brian points out, we did decide some time ago that exactly one
>     output should go to the displayhook, and the current behavior is probably a
>     regression. For the SQLite history, just use the last one.
>
>
> OK. I'll leave it as is for now, because I can get the multiple outputs at a
> plain Python prompt, so it doesn't seem immediately "wrong". If we do remove
> that possibility, I'll put it back to assuming single outputs.

I think you can consider that possibility removed. We did discuss this in the 
past, so I suspect that the remaining behavior is a regression. Trying to keep 
multiple outputs in the history seems to be adding too much complexity for no 
real gain.

-- 
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 takowl at gmail.com  Mon Mar 14 18:22:51 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 14 Mar 2011 22:22:51 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <illnlj$5kr$1@dough.gmane.org>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
	<illnlj$5kr$1@dough.gmane.org>
Message-ID: <AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>

On 14 March 2011 18:44, Robert Kern <robert.kern at gmail.com> wrote:

> I'm not sure what you are doing here. Out/_oh should be storing the actual
> objects. The history should be storing the formatted text from the
> displayhook;
> you should not try to use repr() on those objects afterwards. That records
> the
> wrong thing.
>

That should now be what it's doing. Specifically, in displayhook,
update_user_ns puts the actual object into Out[n] (and will update it on any
subsequent calls, so the final output is stored). log_output then puts the
text/plain representation of the object into a list of outputs, and when the
execution is complete, all the outputs are stored in the database.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110314/b6a9d605/attachment.html>

From pivanov314 at gmail.com  Tue Mar 15 12:14:41 2011
From: pivanov314 at gmail.com (Paul Ivanov)
Date: Tue, 15 Mar 2011 09:14:41 -0700
Subject: [IPython-dev] 0.10.2.rc1 ready for testing.
In-Reply-To: <AANLkTikuQdNd7mE9bkH8WYBPiMeRz-WrCRMSMq+u-PPv@mail.gmail.com>
References: <AANLkTikMjP7UZ=q9A6Oj92bqvPy3EAvGW4ZdmP5nER98@mail.gmail.com>
	<20110313111319.GU3658@ykcyc>
	<AANLkTikuQdNd7mE9bkH8WYBPiMeRz-WrCRMSMq+u-PPv@mail.gmail.com>
Message-ID: <20110315161441.GD3658@ykcyc>

Fernando Perez, on 2011-03-14 01:13,  wrote:
> Keep in mind that what you describe is perfectly OK: we never expected
> the above to work without -pylab.  So as long as things do work
> correctly when people do call -pylab, without any blocking or other
> issues, we're in the clear.
> 
> Does that make sense?

It does, thanks for clarifying and helping me retain my sanity :) 
(-pylab works as advertised)

Is running iptest still the preferred way of testing IPython?

I get one Twisted related error that's probably my fault.

*****************************************************************************
IPython test group: trial
/home/pi/usr/local/bin/trial:4: UserWarning: Unbuilt egg for pytz
[unknown version] (/usr/lib/python2.6/dist-packages)
  import pkg_resources
Traceback (most recent call last):
  File "/home/pi/usr/local/bin/trial", line 4, in <module>
    import pkg_resources
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line
2659, in <module>
    parse_requirements(__requires__), Environment()
  File "/usr/lib/python2.6/dist-packages/pkg_resources.py", line
546, in resolve
    raise DistributionNotFound(req)
pkg_resources.DistributionNotFound: Twisted==8.1.0
*****************************************************************************

because 
>>> import twisted
>>> twisted.__version__
'10.0.0'

best,
-- 
Paul Ivanov
314 address only used for lists,  off-list direct email at:
http://pirsquared.org | GPG/PGP key id: 0x0F3E28F7 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110315/819cc9d1/attachment.sig>

From fperez.net at gmail.com  Tue Mar 15 13:38:59 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Tue, 15 Mar 2011 10:38:59 -0700
Subject: [IPython-dev] 0.10.2.rc1 ready for testing.
In-Reply-To: <20110315161441.GD3658@ykcyc>
References: <AANLkTikMjP7UZ=q9A6Oj92bqvPy3EAvGW4ZdmP5nER98@mail.gmail.com>
	<20110313111319.GU3658@ykcyc>
	<AANLkTikuQdNd7mE9bkH8WYBPiMeRz-WrCRMSMq+u-PPv@mail.gmail.com>
	<20110315161441.GD3658@ykcyc>
Message-ID: <AANLkTi=9YWfPZkTmGihTraV4PYCf_TPGzMvB=W6UdUBu@mail.gmail.com>

On Tue, Mar 15, 2011 at 9:14 AM, Paul Ivanov <pivanov314 at gmail.com> wrote:
> It does, thanks for clarifying and helping me retain my sanity :)
> (-pylab works as advertised)

OK, thanks for checking.

> Is running iptest still the preferred way of testing IPython?

Yes, though I have to admit that the test suite for 0.10.x may have
fallen into a bit of disrepair.  I'll see if I can clean it up, but
I'm seriously pressed for time and want to put what resources I have
into the 0.11 work... We've kept the changes in 0.10.2 so isolated and
small that hopefully no regressions have been introduced.  Bad
practice, I know, but I just don't have the time to maintain both
branches in full, and just need to get 0.11 out asap.

Thanks for your feedback!

f


From takowl at gmail.com  Thu Mar 17 10:03:17 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Thu, 17 Mar 2011 14:03:17 +0000
Subject: [IPython-dev] Magic repeat commands
Message-ID: <AANLkTi=bQDkJi+U2obV4+NSnDfg7vt9oL5GMCvUk8xD3@mail.gmail.com>

I started looking at magic_rep, while reworking the history. It's struck me
that it's not a very intuitive behaviour - it can either bring a line to the
prompt, or execute code, and it overlaps with the magic_r function. So I'd
like to propose a cleaner separation - let's have one magic command to
repeat or rerun a command, and another to bring a line to the prompt.

If we were starting with a clean slate, I would call these %repeat/%rep to
run commands, and %recall/%rec to bring them to the prompt. But I think %rep
is probably more often used to "recall" a line, so perhaps it would be
better to leave it in this role, and call the new repeat function something
like %rerun.

More specifically, the recall function, whatever we call it, would have the
following behaviour:
- With no arguments, put the last output (_) at the prompt
- If the argument is a string variable in the user namespace, put the value
of that variable at the prompt (so you could recall Out[4]). I think this
should be possible using eval.
- If the argument specifies one or more cells in the history, join them into
a single cell and put this at the prompt. (Or should we just take the first
cell instead of combining them?)
- Otherwise, search through the history, and recall the most recent line
containing the search term.

The repeat/rerun function would accept similar options and arguments to
%history (except those relating to output), and would retrieve lines in the
same way, except that the search option (-g) would only retrieve the most
recent match. Specifying no arguments would get the cell immediately before
it. These lines would then be run in exec mode (single mode for single
blocks?)

It makes sense to do this in my sqlite-history branch, because I need to
modify these commands to work with the new history system anyway. Are there
any thoughts or objections? If I separate the functions, what names would
you like them to be under?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110317/61f3516f/attachment.html>

From ellisonbg at gmail.com  Mon Mar 21 13:50:20 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 21 Mar 2011 10:50:20 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
	<illnlj$5kr$1@dough.gmane.org>
	<AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>
Message-ID: <AANLkTimRKhrCg-t6f1wj=Mm2GTpqM83kBhW6eQW1Hf48@mail.gmail.com>

I know Fernando is super busy with buying a hours this week, and he is
most familiar with the input splitter logic, but did anyone figure out
the regression that is triggering the display hook multiple times?

Cheers,

Brian

On Mon, Mar 14, 2011 at 3:22 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> On 14 March 2011 18:44, Robert Kern <robert.kern at gmail.com> wrote:
>>
>> I'm not sure what you are doing here. Out/_oh should be storing the actual
>> objects. The history should be storing the formatted text from the
>> displayhook;
>> you should not try to use repr() on those objects afterwards. That records
>> the
>> wrong thing.
>
> That should now be what it's doing. Specifically, in displayhook,
> update_user_ns puts the actual object into Out[n] (and will update it on any
> subsequent calls, so the final output is stored). log_output then puts the
> text/plain representation of the object into a list of outputs, and when the
> execution is complete, all the outputs are stored in the database.
>
> Thomas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com


From takowl at gmail.com  Mon Mar 21 14:28:34 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 21 Mar 2011 18:28:34 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTimRKhrCg-t6f1wj=Mm2GTpqM83kBhW6eQW1Hf48@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
	<illnlj$5kr$1@dough.gmane.org>
	<AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>
	<AANLkTimRKhrCg-t6f1wj=Mm2GTpqM83kBhW6eQW1Hf48@mail.gmail.com>
Message-ID: <AANLkTi=mEbTX_J3S05_305_bvk-vm3ooSCb-5Eu1N2M-@mail.gmail.com>

My best guess is that it's not actually a regression - I've seen code in
run_cell that ensures that only one block in a cell can fire displayhook,
which could be what has been described. But it doesn't affect the situation
in which that block causes displayhook to fire several times. As far as I
know, the only way to achieve that would be to catch things in displayhook,
append them to a list, and then display them only after computation has
finished.

Thomas

On 21 March 2011 17:50, Brian Granger <ellisonbg at gmail.com> wrote:

> I know Fernando is super busy with buying a hours this week, and he is
> most familiar with the input splitter logic, but did anyone figure out
> the regression that is triggering the display hook multiple times?
>
> Cheers,
>
> Brian
>
> On Mon, Mar 14, 2011 at 3:22 PM, Thomas Kluyver <takowl at gmail.com> wrote:
> > On 14 March 2011 18:44, Robert Kern <robert.kern at gmail.com> wrote:
> >>
> >> I'm not sure what you are doing here. Out/_oh should be storing the
> actual
> >> objects. The history should be storing the formatted text from the
> >> displayhook;
> >> you should not try to use repr() on those objects afterwards. That
> records
> >> the
> >> wrong thing.
> >
> > That should now be what it's doing. Specifically, in displayhook,
> > update_user_ns puts the actual object into Out[n] (and will update it on
> any
> > subsequent calls, so the final output is stored). log_output then puts
> the
> > text/plain representation of the object into a list of outputs, and when
> the
> > execution is complete, all the outputs are stored in the database.
> >
> > Thomas
> >
> > _______________________________________________
> > IPython-dev mailing list
> > IPython-dev at scipy.org
> > http://mail.scipy.org/mailman/listinfo/ipython-dev
> >
> >
>
>
>
> --
> Brian E. Granger, Ph.D.
> Assistant Professor of Physics
> Cal Poly State University, San Luis Obispo
> bgranger at calpoly.edu
> ellisonbg at gmail.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110321/6073b289/attachment.html>

From Fernando.Perez at berkeley.edu  Mon Mar 21 14:32:42 2011
From: Fernando.Perez at berkeley.edu (Fernando Perez)
Date: Mon, 21 Mar 2011 11:32:42 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTi=mEbTX_J3S05_305_bvk-vm3ooSCb-5Eu1N2M-@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
	<illnlj$5kr$1@dough.gmane.org>
	<AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>
	<AANLkTimRKhrCg-t6f1wj=Mm2GTpqM83kBhW6eQW1Hf48@mail.gmail.com>
	<AANLkTi=mEbTX_J3S05_305_bvk-vm3ooSCb-5Eu1N2M-@mail.gmail.com>
Message-ID: <AANLkTimAXB4t+fGMrYVaXX8byz5bTsHOSmm+7SV9sWFZ@mail.gmail.com>

Hey guys,

On Mon, Mar 21, 2011 at 11:28, Thomas Kluyver <takowl at gmail.com> wrote:
> My best guess is that it's not actually a regression - I've seen code in
> run_cell that ensures that only one block in a cell can fire displayhook,
> which could be what has been described. But it doesn't affect the situation
> in which that block causes displayhook to fire several times. As far as I
> know, the only way to achieve that would be to catch things in displayhook,
> append them to a list, and then display them only after computation has
> finished.

sorry, I can't look into this until tomorrow...

Thomas, there should be code in there to prevent displayhook from
firing based on the compilation mode: when code is compiled in
'single' mode, displayhook will fire, but if it's compiled in 'exec'
mode, it won't.  There's actually different bytecode produced by
python itself based on the mode flag.

I thought I had made sure that for multiline blocks we always produced
'exec' mode, but something must have slipped through the cracks...

Cheers,

f


From ellisonbg at gmail.com  Mon Mar 21 14:38:36 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 21 Mar 2011 11:38:36 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTimAXB4t+fGMrYVaXX8byz5bTsHOSmm+7SV9sWFZ@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
	<illnlj$5kr$1@dough.gmane.org>
	<AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>
	<AANLkTimRKhrCg-t6f1wj=Mm2GTpqM83kBhW6eQW1Hf48@mail.gmail.com>
	<AANLkTi=mEbTX_J3S05_305_bvk-vm3ooSCb-5Eu1N2M-@mail.gmail.com>
	<AANLkTimAXB4t+fGMrYVaXX8byz5bTsHOSmm+7SV9sWFZ@mail.gmail.com>
Message-ID: <AANLkTi==nbYRwMgUiYq3Mnkg9s4OFMMPi2=gDwUygfrq@mail.gmail.com>

Thomas,

Can you open an issue for this regression so we can track it?

Thanks!

Brian

On Mon, Mar 21, 2011 at 11:32 AM, Fernando Perez
<Fernando.Perez at berkeley.edu> wrote:
> Hey guys,
>
> On Mon, Mar 21, 2011 at 11:28, Thomas Kluyver <takowl at gmail.com> wrote:
>> My best guess is that it's not actually a regression - I've seen code in
>> run_cell that ensures that only one block in a cell can fire displayhook,
>> which could be what has been described. But it doesn't affect the situation
>> in which that block causes displayhook to fire several times. As far as I
>> know, the only way to achieve that would be to catch things in displayhook,
>> append them to a list, and then display them only after computation has
>> finished.
>
> sorry, I can't look into this until tomorrow...
>
> Thomas, there should be code in there to prevent displayhook from
> firing based on the compilation mode: when code is compiled in
> 'single' mode, displayhook will fire, but if it's compiled in 'exec'
> mode, it won't. ?There's actually different bytecode produced by
> python itself based on the mode flag.
>
> I thought I had made sure that for multiline blocks we always produced
> 'exec' mode, but something must have slipped through the cracks...
>
> Cheers,
>
> f
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com


From takowl at gmail.com  Mon Mar 21 14:39:59 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 21 Mar 2011 18:39:59 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTimAXB4t+fGMrYVaXX8byz5bTsHOSmm+7SV9sWFZ@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
	<illnlj$5kr$1@dough.gmane.org>
	<AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>
	<AANLkTimRKhrCg-t6f1wj=Mm2GTpqM83kBhW6eQW1Hf48@mail.gmail.com>
	<AANLkTi=mEbTX_J3S05_305_bvk-vm3ooSCb-5Eu1N2M-@mail.gmail.com>
	<AANLkTimAXB4t+fGMrYVaXX8byz5bTsHOSmm+7SV9sWFZ@mail.gmail.com>
Message-ID: <AANLkTik8_EVmEY-Dom5QVWaiaBwyWuJKcrpBpXd7_0=o@mail.gmail.com>

On 21 March 2011 18:32, Fernando Perez <Fernando.Perez at berkeley.edu> wrote:

> I thought I had made sure that for multiline blocks we always produced
> 'exec' mode, but something must have slipped through the cracks...
>

A single block is compiled in single mode, regardless of how many lines it
has. If there are several blocks, the last one is compiled in single mode if
it is <= 2 lines long.

However, even with a single line, you can do:

for a in range(5): a

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110321/8892a5c4/attachment.html>

From Fernando.Perez at berkeley.edu  Mon Mar 21 14:55:25 2011
From: Fernando.Perez at berkeley.edu (Fernando Perez)
Date: Mon, 21 Mar 2011 11:55:25 -0700
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTik8_EVmEY-Dom5QVWaiaBwyWuJKcrpBpXd7_0=o@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
	<illnlj$5kr$1@dough.gmane.org>
	<AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>
	<AANLkTimRKhrCg-t6f1wj=Mm2GTpqM83kBhW6eQW1Hf48@mail.gmail.com>
	<AANLkTi=mEbTX_J3S05_305_bvk-vm3ooSCb-5Eu1N2M-@mail.gmail.com>
	<AANLkTimAXB4t+fGMrYVaXX8byz5bTsHOSmm+7SV9sWFZ@mail.gmail.com>
	<AANLkTik8_EVmEY-Dom5QVWaiaBwyWuJKcrpBpXd7_0=o@mail.gmail.com>
Message-ID: <AANLkTincDSe=U+K28J0xRWO-BoUPLtOX+nSkGC4ZsPgy@mail.gmail.com>

On Mon, Mar 21, 2011 at 11:39, Thomas Kluyver <takowl at gmail.com> wrote:
> A single block is compiled in single mode, regardless of how many lines it
> has. If there are several blocks, the last one is compiled in single mode if
> it is <= 2 lines long.

Ah, yes!  I remember now...

> However, even with a single line, you can do:
>
> for a in range(5): a

True.

The solution is technically easy, I guess we just need to decide a
policy.  I'd implemented the current one thinking it was a good
balance between seeing displayhook output in the most common cases and
not getting multiple ones otherwise. But we can certainly revisit
this.

And we could go back to always compiling in single mode, if we want.
Though that would trigger multiple Out[] results when running calls
like matplotlib plots, that are intended for their side effects but
still return a value.  That was  a big driver of deciding to silence
things somewhat...

best

f


From takowl at gmail.com  Mon Mar 21 15:02:58 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Mon, 21 Mar 2011 19:02:58 +0000
Subject: [IPython-dev] Multiple outputs per input line
In-Reply-To: <AANLkTincDSe=U+K28J0xRWO-BoUPLtOX+nSkGC4ZsPgy@mail.gmail.com>
References: <AANLkTimgrRLeAiqR=MS4GG75x5GK3BP+c3oE485=qbZi@mail.gmail.com>
	<AANLkTi=o1GXAYdJRVeWTjWffkA1EwzqzA3m1SHP7XQPe@mail.gmail.com>
	<AANLkTinBkzCnOGstX7fdq_F4FBjb42y92=dsJBHme3pT@mail.gmail.com>
	<AANLkTinYw4H8J+asSfMJo058vh2GrW+27RTOma0J0vxx@mail.gmail.com>
	<AANLkTi=W-iG7dFccnaYQ0wCCKrOAkyfGqF99RMCOCPvV@mail.gmail.com>
	<illhpc$jcp$1@dough.gmane.org>
	<AANLkTimcwWEsbcqmMU4+__9ETFX-DE1AB-xGUQ+76sBd@mail.gmail.com>
	<AANLkTimcULGQT2dpwXmAdOTDgmvejZnsEd3-td8fsfvH@mail.gmail.com>
	<illnlj$5kr$1@dough.gmane.org>
	<AANLkTi=GwJAgKiXNeyH0b6dbpFG5-36HqNZoBV1aqDcS@mail.gmail.com>
	<AANLkTimRKhrCg-t6f1wj=Mm2GTpqM83kBhW6eQW1Hf48@mail.gmail.com>
	<AANLkTi=mEbTX_J3S05_305_bvk-vm3ooSCb-5Eu1N2M-@mail.gmail.com>
	<AANLkTimAXB4t+fGMrYVaXX8byz5bTsHOSmm+7SV9sWFZ@mail.gmail.com>
	<AANLkTik8_EVmEY-Dom5QVWaiaBwyWuJKcrpBpXd7_0=o@mail.gmail.com>
	<AANLkTincDSe=U+K28J0xRWO-BoUPLtOX+nSkGC4ZsPgy@mail.gmail.com>
Message-ID: <AANLkTimjXf__i2BHnn8ENGgy5oJZRx_-r3ar-VoiVbGp@mail.gmail.com>

On 21 March 2011 18:55, Fernando Perez <Fernando.Perez at berkeley.edu> wrote:

> The solution is technically easy, I guess we just need to decide a
> policy.  I'd implemented the current one thinking it was a good
> balance between seeing displayhook output in the most common cases and
> not getting multiple ones otherwise. But we can certainly revisit
> this.
>
> And we could go back to always compiling in single mode, if we want.
> Though that would trigger multiple Out[] results when running calls
> like matplotlib plots, that are intended for their side effects but
> still return a value.  That was  a big driver of deciding to silence
> things somewhat...
>

I think the current system is probably about right, in that it should show
output when people expect it, and keep quiet when they don't. But it doesn't
prevent multiple calls to displayhook, so although it's a fairly unusual
case, we need to at least handle it gracefully.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110321/1b6c660f/attachment.html>

From takowl at gmail.com  Mon Mar 21 22:35:45 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 22 Mar 2011 02:35:45 +0000
Subject: [IPython-dev] Grab current namespace for magic commands
Message-ID: <AANLkTikOw=APq1-HZ_47H6Uz+iDySLihzT31KFuhDDFF@mail.gmail.com>

At sagedays29, I've been pointed at an issue (
http://trac.sagemath.org/sage_trac/ticket/10933) where people want to use
the %time magic command inside a function. However, magic_time evaluates its
argument in the main user_ns namespace, not the namespace of the function.

I believe it's possible to get the relevant namespace by using
inspect.stack(). If we do this in interactiveshell.magic(), we can get a
reference to the frame from which magic() was called, and then evaluate the
code with the locals and globals of that frame. Does this sound like
something worth doing, or an awkward kludge? Is there a nicer way to do this
that I've overlooked?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110322/40bf9492/attachment.html>

From ellisonbg at gmail.com  Mon Mar 21 23:03:42 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 21 Mar 2011 20:03:42 -0700
Subject: [IPython-dev] Grab current namespace for magic commands
In-Reply-To: <AANLkTikOw=APq1-HZ_47H6Uz+iDySLihzT31KFuhDDFF@mail.gmail.com>
References: <AANLkTikOw=APq1-HZ_47H6Uz+iDySLihzT31KFuhDDFF@mail.gmail.com>
Message-ID: <AANLkTimyRA7nh2w+iCPwJZQvH3gkFF7NqSPFO8xrT+Go@mail.gmail.com>

Thomas,

I think there is another issue, and that is the status of magic
command in multiline input blocks.  Fernando, what is the status of
that type of thing?  I think it works fine IIRC.

> At sagedays29, I've been pointed at an issue
> (http://trac.sagemath.org/sage_trac/ticket/10933) where people want to use
> the %time magic command inside a function. However, magic_time evaluates its
> argument in the main user_ns namespace, not the namespace of the function.

I think this does make sense if we are going to allow magics to work
inside functions.  Probably have locals be the function's scope and
globals be user_ns?

> I believe it's possible to get the relevant namespace by using
> inspect.stack(). If we do this in interactiveshell.magic(), we can get a
> reference to the frame from which magic() was called, and then evaluate the
> code with the locals and globals of that frame. Does this sound like
> something worth doing, or an awkward kludge? Is there a nicer way to do this
> that I've overlooked?

Sounds good to me as long as multiline magics are working as expected.

Cheers,

Brian

> Thanks,
> Thomas
>
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com


From takowl at gmail.com  Tue Mar 22 12:04:13 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 22 Mar 2011 16:04:13 +0000
Subject: [IPython-dev] Grab current namespace for magic commands
In-Reply-To: <AANLkTimyRA7nh2w+iCPwJZQvH3gkFF7NqSPFO8xrT+Go@mail.gmail.com>
References: <AANLkTikOw=APq1-HZ_47H6Uz+iDySLihzT31KFuhDDFF@mail.gmail.com>
	<AANLkTimyRA7nh2w+iCPwJZQvH3gkFF7NqSPFO8xrT+Go@mail.gmail.com>
Message-ID: <AANLkTi=WrXzMcz0fXXYB0LQ7XYge3ZWN1v_UH5_wmHeo@mail.gmail.com>

On 22 March 2011 03:03, Brian Granger <ellisonbg at gmail.com> wrote:

>
> I think there is another issue, and that is the status of magic
> command in multiline input blocks.  Fernando, what is the status of
> that type of thing?


Jumping in, because I've looked at the relevant code recently: explicit
magic commands (%time a+b) are handled in multiline input blocks. Auto-magic
(time a+b) is only handled in a single line cell, or a single line block at
the end of a multi-block cell. Fernando, please correct me if that's not
right, or I've missed anything out.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110322/d57c4b82/attachment.html>

From takowl at gmail.com  Thu Mar 24 22:07:53 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 25 Mar 2011 02:07:53 +0000
Subject: [IPython-dev] IPython & Unicode
Message-ID: <AANLkTindJ3p_ekgTDC_rA8J40DRSCy_P5u_39wu9faqd@mail.gmail.com>

Hi J?rgen,

We've merged the unicode issues branch into master, and unicode now seems to
be behaving properly, at least in Linux. Can you let us know if you get
unicode related issues in trunk?

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110325/3dc16f65/attachment.html>

From fperez.net at gmail.com  Fri Mar 25 01:36:56 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Thu, 24 Mar 2011 22:36:56 -0700
Subject: [IPython-dev] [sage-devel] Fernando Perez's talk today at Sage
	Days 29
In-Reply-To: <AANLkTin0iSDA1Tt5EaEAf0rFvWk8c3_1kYSwAAJXMj3B@mail.gmail.com>
References: <AANLkTin0iSDA1Tt5EaEAf0rFvWk8c3_1kYSwAAJXMj3B@mail.gmail.com>
Message-ID: <AANLkTinZsiYw1QG-9KA92MqdCh66T8QZ-a5Ya1x7F4tJ@mail.gmail.com>

Hi all,

On Thu, Mar 24, 2011 at 10:16 PM, William Stein <wstein at gmail.com> wrote:
> Hi,
>
> Today Fernando Perez gave a very inspiring and enthusiastic talk today
> at Sage Days 29 on Scientific Computing using Python, including a
> historical introduction with a story about how he accidentally
> unplugged the internet for the entire country of Colombia when he was
> a grad student. ? You can watch the video of the talk here:
> http://www.youtube.com/watch?v=1j_HxD4iLn8

Thanks for putting the video up!  The slides are here:

http://fperez.org/talks/1103_uwashington.pdf

Cheers,

f

ps - for those interested, these days have been *very* productive for
IPython.  This page:

http://wiki.sagemath.org/days29/bugs

has the list of issues we've closed since Monday (50 and counting),
and today we had a very good discussion with Jason Grout and others
from the Sage team about IPython's messaging protocol.  Many thanks to
William for the invitation and support!


From benjaminrk at gmail.com  Mon Mar 28 14:42:56 2011
From: benjaminrk at gmail.com (MinRK)
Date: Mon, 28 Mar 2011 11:42:56 -0700
Subject: [IPython-dev] GitHub Issues display
Message-ID: <AANLkTi=WmuVvhp8ENev_wP93MiFq5KHrA6s4VPeMsb_h@mail.gmail.com>

For anyone who may be frustrated by the fact that our liberal
application of labels obscures the display of the actual title of
issues, I posted a tiny userstyle that simply doubles the height of
the field,
allowing it to fit an extra line.

http://userstyles.org/styles/45768/github-more-space-for-issue-titles

-MinRK


From ellisonbg at gmail.com  Mon Mar 28 16:00:43 2011
From: ellisonbg at gmail.com (Brian Granger)
Date: Mon, 28 Mar 2011 13:00:43 -0700
Subject: [IPython-dev] GitHub Issues display
In-Reply-To: <AANLkTi=WmuVvhp8ENev_wP93MiFq5KHrA6s4VPeMsb_h@mail.gmail.com>
References: <AANLkTi=WmuVvhp8ENev_wP93MiFq5KHrA6s4VPeMsb_h@mail.gmail.com>
Message-ID: <AANLkTi=OYACZWPxNAMA-mTaXmY6of0hkb3x50hFgHyTT@mail.gmail.com>

Yes!

Brian

On Mon, Mar 28, 2011 at 11:42 AM, MinRK <benjaminrk at gmail.com> wrote:
> For anyone who may be frustrated by the fact that our liberal
> application of labels obscures the display of the actual title of
> issues, I posted a tiny userstyle that simply doubles the height of
> the field,
> allowing it to fit an extra line.
>
> http://userstyles.org/styles/45768/github-more-space-for-issue-titles
>
> -MinRK
> _______________________________________________
> 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 andresete.chaos at gmail.com  Tue Mar 29 10:15:35 2011
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Tue, 29 Mar 2011 09:15:35 -0500
Subject: [IPython-dev] Ipython frontend for two process
Message-ID: <AANLkTik76+Mh0ZwgXRAf8XLv9vRAByuPYpkXyZTdWfZS@mail.gmail.com>

Hi all.

I am working in a terminal frontend for two process model
https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal
<https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal>I
have some features working fine, like indentation, prompt numeration and
timing  in process execution.
I am have problems in tab-completion, meybe some guidance help me to fix
this bug.

the timeline for the GSoC project delivery is very soon and maybe do not
reach to get everything ready to apply, anyway I'll be working on the
frontend.
Thanks



-- 
Omar Andres Zapata Mesa
Universidad de Antioquia At Medellin - Colombia
Usuario Linux  #490962
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110329/b3aa8706/attachment.html>

From takowl at gmail.com  Tue Mar 29 10:34:45 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Mar 2011 15:34:45 +0100
Subject: [IPython-dev] Ipython frontend for two process
In-Reply-To: <AANLkTik76+Mh0ZwgXRAf8XLv9vRAByuPYpkXyZTdWfZS@mail.gmail.com>
References: <AANLkTik76+Mh0ZwgXRAf8XLv9vRAByuPYpkXyZTdWfZS@mail.gmail.com>
Message-ID: <AANLkTimCU-UB_fUya288GqQmJ1CyuJ3NCLT518CA9_2x@mail.gmail.com>

2011/3/29 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>

> Hi all.
>
> I am working in a terminal frontend for two process model
>
> https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal
> <https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal>I
> have some features working fine, like indentation, prompt numeration and
> timing  in process execution.
> I am have problems in tab-completion, meybe some guidance help me to fix
> this bug.
>

When I test it, entering any command gives me the traceback below. Am I
setting it up wrong? I'm installing in a virtualenv, then running python
ipython/IPython/frontend/terminal/frontend.py.

Thanks,
Thomas
----
Traceback (most recent call last):
  File "ipython/IPython/frontend/terminal/frontend.py", line 270, in
<module>
    frontend.start()
  File "ipython/IPython/frontend/terminal/frontend.py", line 117, in start
    self.interact()
  File "ipython/IPython/frontend/terminal/frontend.py", line 101, in
interact
    self._execute(self._splitter.source,False)
  File "ipython/IPython/frontend/terminal/frontend.py", line 136, in
_execute
    self.handle_xreq_channel()
  File "ipython/IPython/frontend/terminal/frontend.py", line 141, in
handle_xreq_channel
    if self.km.xreq_channel.was_called():
  File
"/home/thomas/code/virtualenvs/ipy-term-2proc/lib/python2.6/site-packages/IPython/frontend/terminal/kernelmanager.py",
line 40, in was_called
    return self.queue.not_empty()
TypeError: '_Condition' object is not callable
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110329/332b48ed/attachment.html>

From andresete.chaos at gmail.com  Tue Mar 29 11:12:04 2011
From: andresete.chaos at gmail.com (=?UTF-8?Q?Omar_Andr=C3=A9s_Zapata_Mesa?=)
Date: Tue, 29 Mar 2011 10:12:04 -0500
Subject: [IPython-dev] Ipython frontend for two process
In-Reply-To: <AANLkTimCU-UB_fUya288GqQmJ1CyuJ3NCLT518CA9_2x@mail.gmail.com>
References: <AANLkTik76+Mh0ZwgXRAf8XLv9vRAByuPYpkXyZTdWfZS@mail.gmail.com>
	<AANLkTimCU-UB_fUya288GqQmJ1CyuJ3NCLT518CA9_2x@mail.gmail.com>
Message-ID: <AANLkTikZFMJ1WxGJ_4tg0xt9o6grfofi+q4SM-SCJhmv@mail.gmail.com>

Hi Thomas,
Update you code, the bug was fixed.
Thanks for the review.

2011/3/29 Thomas Kluyver <takowl at gmail.com>

> 2011/3/29 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>
>
>> Hi all.
>>
>> I am working in a terminal frontend for two process model
>>
>> https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal
>> <https://github.com/omazapa/ipython/tree/frontend-logging/IPython/frontend/terminal>I
>> have some features working fine, like indentation, prompt numeration and
>> timing  in process execution.
>> I am have problems in tab-completion, meybe some guidance help me to fix
>> this bug.
>>
>
> When I test it, entering any command gives me the traceback below. Am I
> setting it up wrong? I'm installing in a virtualenv, then running python
> ipython/IPython/frontend/terminal/frontend.py.
>
> Thanks,
> Thomas
> ----
> Traceback (most recent call last):
>   File "ipython/IPython/frontend/terminal/frontend.py", line 270, in
> <module>
>     frontend.start()
>   File "ipython/IPython/frontend/terminal/frontend.py", line 117, in start
>     self.interact()
>   File "ipython/IPython/frontend/terminal/frontend.py", line 101, in
> interact
>     self._execute(self._splitter.source,False)
>   File "ipython/IPython/frontend/terminal/frontend.py", line 136, in
> _execute
>     self.handle_xreq_channel()
>   File "ipython/IPython/frontend/terminal/frontend.py", line 141, in
> handle_xreq_channel
>     if self.km.xreq_channel.was_called():
>   File
> "/home/thomas/code/virtualenvs/ipy-term-2proc/lib/python2.6/site-packages/IPython/frontend/terminal/kernelmanager.py",
> line 40, in was_called
>     return self.queue.not_empty()
> TypeError: '_Condition' object is not callable
>
>


-- 
Omar Andres Zapata Mesa
Universidad de Antioquia At Medellin - Colombia
Usuario Linux  #490962
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110329/c2f4a228/attachment.html>

From takowl at gmail.com  Tue Mar 29 12:26:38 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Tue, 29 Mar 2011 17:26:38 +0100
Subject: [IPython-dev] Ipython frontend for two process
In-Reply-To: <AANLkTikZFMJ1WxGJ_4tg0xt9o6grfofi+q4SM-SCJhmv@mail.gmail.com>
References: <AANLkTik76+Mh0ZwgXRAf8XLv9vRAByuPYpkXyZTdWfZS@mail.gmail.com>
	<AANLkTimCU-UB_fUya288GqQmJ1CyuJ3NCLT518CA9_2x@mail.gmail.com>
	<AANLkTikZFMJ1WxGJ_4tg0xt9o6grfofi+q4SM-SCJhmv@mail.gmail.com>
Message-ID: <AANLkTikw+pHH+7BZqznbfrDpRWMrKtYtviA=Dx7wUJ=3@mail.gmail.com>

2011/3/29 Omar Andr?s Zapata Mesa <andresete.chaos at gmail.com>

> Hi Thomas,
> Update you code, the bug was fixed.
> Thanks for the review.
>

Thanks, that's working now. As for tab completion, if you look in
IPython/core/completer.py, at line 865, uncomment the DEBUG = True line, and
it should give you more info on what's going wrong.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110329/085f4fcd/attachment.html>

From fperez.net at gmail.com  Wed Mar 30 04:25:39 2011
From: fperez.net at gmail.com (Fernando Perez)
Date: Wed, 30 Mar 2011 01:25:39 -0700
Subject: [IPython-dev] Short summary post on Sage Days visit
Message-ID: <AANLkTi=aULq1CP8ivJ8F=HNsyW9P-E7VQQzw4588yFHH@mail.gmail.com>

Hi folks,

a quick summary of last week's Sage Days work from my perspective:

http://blog.fperez.org/2011/03/ipython-and-scientific-python-go-to.html

Thanks again to William for the workshop!

Cheers,

f


From takowl at gmail.com  Thu Mar 31 19:25:05 2011
From: takowl at gmail.com (Thomas Kluyver)
Date: Fri, 1 Apr 2011 00:25:05 +0100
Subject: [IPython-dev] Pushed to master...
Message-ID: <AANLkTimqyqqTBpbCvYAajZR-dH6H_OPckEdPSuw5LzvT@mail.gmail.com>

Apologies for pushing my experimental change directly to master. I had the
wrong branch checked out. I've pushed another commit to undo it - I
understand that it's bad practice to remove a commit once it's been
published.

Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ipython-dev/attachments/20110401/216d5715/attachment.html>