On Mon, Aug 10, 2009 at 8:43 AM, Kiran Kedlaya <ksk...@gmail.com> wrote:
>
> What would you expect from the following input into the notebook?
>
> CELL 1:
> u = 2+2
> u = 2+3
>
> CELL 2:
> print u
>
> If you try something like this at a command line, the first line gives
> an error due to the spaces in front.
No it doesn't, at least not for me.
flat wstein$ sage
----------------------------------------------------------------------
| Sage Version 4.1, Release Date: 2009-07-09 |
| Type notebook() for the GUI, and license() for information. |
----------------------------------------------------------------------
Loading Sage library. Current Mercurial branch is: heckeindex
sage: u = 2+2
sage: u = 2+3
sage: print u
5
I know it won't give an error, because on the command line all spaces and
sage: and >>> prompts are stripped from the left for non-continuation lines.
However, you might have meant the pure python command line, which does give
an error:
flat:kamienny wstein$ sage -python
Python 2.6.2 (r262:71600, Jul 8 2009, 17:42:25)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> u = 2 + 2
File "<stdin>", line 1
u = 2 + 2
^
IndentationError: unexpected indent
>>>
> But on my notebook server
> (running 4.1), the first cell evaluates without an error, and the
> second one returns 4, not 5. ?!
>
> Kiran
This must be a bug in the notebook, related to exec compile, which the
notebook uses to evaluate cells. Here's the code that actually gets
executed:
----------------------------------------------------------------
flat:code wstein$ pwd
/Users/wstein/.sage/sage_notebook/worksheets/admin/222/code
flat:code wstein$ more 16.py
# -*- coding: utf_8 -*-
from __future__ import with_statement
print "^Ab14"
os.chdir("/Users/wstein/.sage/sage_notebook/worksheets/admin/222/cells/5")
sage.server.notebook.interact.SAGE_CELL_ID=5
_sage_const_3 = Integer(3); _sage_const_2 = Integer(2)
exec compile(ur'u = _sage_const_2 +_sage_const_2\u000a u = _sage_const_2
+_sage_const_3' + '\n',
'', 'single')
print "^Ae14"
----------------------------------------------------------------
The code if you get rid of the spaces to the left we get:
flat:code wstein$ more 23.py
...
_sage_const_3 = Integer(3); _sage_const_2 = Integer(2)
u = _sage_const_2 +_sage_const_2
exec compile(ur'u = _sage_const_2 +_sage_const_3' + '\n', '', 'single')
-------------------------
Notice that "exec compile" is supposed to only be used on the *last* line of
input. The reason for this is so that the display print hook is called,
e.g., so if you type
a = 5
a + 1
b = 7
a + b
in a notebook cell, at least you'll see 12 (=a+b) come out. You will not
see 6 from "a+1" though. So the problem you're seeing is because the code
in the notebook to determine "the last line of code" takes account special
cases when the last line is indented, so e.g., the following would work:
for z in range(10):
z
and print out each of the z's (just like "for z in range(10): z"). In fact,
the above is turned into:
_sage_const_5 = Integer(5)
exec compile(ur'for z in range(_sage_const_5 ):\u000a z' + '\n', '',
'single')
The problem is that when we input
u = 2 +2
u = 2 + 3
both indented, then everything is combined into one single exec compile, and
surprisingly we have in pure python:
>>> _sage_const_3 =3; _sage_const_2 = 2>>> exec compile(ur'u = _sage_const_2
+_sage_const_2\u000a u = _sage_const_2 +_sage_const_3' + '\n',
... '', 'single')>>>
>>> u
4
I'm surprised this doesn't set u to 5. It might have something to do with
the "\u000a" which is the unicode character for linefeed. Basically, I
find the following behavior of Python's exec command really
weird/broken/surprising. I would expect an error in the latter two cases:
>>> exec compile(ur'for z in range(5):\u000a z', '','single')0
1
2
3
4
>>> exec compile(ur'u=2+2\u000a u=3+3', '','single')
>>> print u
4
>>> exec compile(ur'u=10\u000a u=3+*fr%Acn @#!^2n2azzz3', '','single')
>>> print u
10
I hope a Python interpreter expert such as Robert Bradshaw can comment on
this. In the meantime, if I were to spend more time on this now (which I
won't), I would read the docs for exec and compile carefully, then probably
just find a way to program around this surprising (to me) case in
server/notebook/worksheet.py (which generates the exec compile code that is
run above).
This is now trac #6729:
http://trac.sagemath.org/sage_trac/ticket/6729
Since this is a notebook bug I've cc'd the codenode list, since probably
they have some brilliant vastly better way of telling Python to evaluate a
block of code, which completely avoids this whole problem. If so, please
do tell.
-- William
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
