2 feature requests: os.getcwd() -> <notebook dir>, __name__ -> '__main__'

[ack]

To make Reinteract even better :-) , I would like to plead my case for
two new features:

1. Make the current directory be the notebook directory.
This would allow read() and write() with relative paths to access
files contained within the notebook, which is very intuitive.
Currently, the output of `open('eggs', 'w').write('spam')` disappears
into the unknown until you realize that 'the unknown' is actually your
home directory, not the current notebook.
Also, setting the current directory to the current notebook allows you
to keep data files with the notebook, move notebooks around (and maybe
send them off to other people to play with) without them having to
change hard-coded paths all over the place.

2. Have the value of __name__ be '__main__'.
This would make things behave more like they do in an interactive
Python session, especially when copy-pasting existing Python scripts
into a worksheet, or preparing worksheets for use as stand-alone
Python scripts.

Any comments?

Kind regards,

ack

[Robert Schroll]

On 11/23/2011 03:49 PM, ack wrote:
> 1. Make the current directory be the notebook directory.
> This would allow read() and write() with relative paths to access
> files contained within the notebook, which is very intuitive.
> Currently, the output of `open('eggs', 'w').write('spam')` disappears
> into the unknown until you realize that 'the unknown' is actually your
> home directory, not the current notebook.
> Also, setting the current directory to the current notebook allows you
> to keep data files with the notebook, move notebooks around (and maybe
> send them off to other people to play with) without them having to
> change hard-coded paths all over the place.

This was mentioned as a solution to another bug
(https://bugzilla.gnome.org/show_bug.cgi?id=659342), and it strikes me
as a reasonable thing to do. What makes this more complicated than a
single os.chdir() call is that Reinteract can have several notebooks
open in the same process. The current directory would need to be
adjusted each time another notebook is executed. I don't know offhand
if this would lead to race conditions when two notebooks execute in
different threads. We would also need to consider what should happen
when the user calls os.chdir() from within the notebook.

My recommendation would to have the current directory tracked as part of
the worksheet state. It could start off as the notebook directory but
be modified for the worksheet only, instead of leaking across all open
worksheets as it does now. I don't know whether it's better to try to
intercept os.chdir() calls or provide a custom reinteract.chdir() function.

>
> 2. Have the value of __name__ be '__main__'.
> This would make things behave more like they do in an interactive
> Python session, especially when copy-pasting existing Python scripts
> into a worksheet, or preparing worksheets for use as stand-alone
> Python scripts.

I'll admit that I don't really see a need for this. But doing so
wouldn't hurt anything, so why not.

Thanks for the input,
Robert

[ack]

Thanks for considering this :-)

I do have a question: why do Reinteract notebooks have to share the
same namespace?
I have looked at a few of the Web-based Python shells like SymPy Live,
and they all run their interactive sessions in their own private
namespaces. Wouldn't that make things a lot easier, with less risk of
actions in one worksheet 'polluting' the namespace of another?

Also, why do all notebooks have to share the same process? I often
open a notebook by clicking on its index file or one of its
worksheets. Doesn't that start a new Reinteract process anyway?

-ack

[Owen Taylor]

On Sun, Nov 27, 2011 at 7:38 PM, ack <a.c.k...@gmail.com> wrote:
> Thanks for considering this :-)
>
> I do have a question: why do Reinteract notebooks have to share the
> same namespace?
> I have looked at a few of the Web-based Python shells like SymPy Live,
> and they all run their interactive sessions in their own private
> namespaces. Wouldn't that make things a lot easier, with less risk of
> actions in one worksheet 'polluting' the namespace of another?

Can you explain in more detail what you mean by this; I don't really
quite follow.

> Also, why do all notebooks have to share the same process? I often
> open a notebook by clicking on its index file or one of its
> worksheets. Doesn't that start a new Reinteract process anyway?

Yes, currently it does.

On some platforms (e.g. Windows, at least up to Windows Vista), that's
pretty much OK - every toplevel window acts entirely separately.

On other platforms (Mac, GNOME), applications are expected to behave
as "applications" - e.g., on the Mac, there's a single menu bar for
the application, it appears once in alt-Tab, there's a Quit menu item,
etc. On those platforms, it really doesn't make sense to have a new
process for the GUI of a second notebook, and it's really a bug if you
can get a second process.

So, I don't see using two front-end GUI processes as a general
solution to, e.g., being able to compute in one notebook when working
on another notebook without any interference or performance penalty.
(Also: it's more likely that you want to work on another worksheet in
the _same_ notebook, then some completely different notebook...)

- Owen

[Robert Schroll]

On 11/28/2011 08:52 AM, Owen Taylor wrote:
> On Sun, Nov 27, 2011 at 7:38 PM, ack<a.c.k...@gmail.com> wrote:
>> Thanks for considering this :-)
>>
>> I do have a question: why do Reinteract notebooks have to share the
>> same namespace?
>> I have looked at a few of the Web-based Python shells like SymPy Live,
>> and they all run their interactive sessions in their own private
>> namespaces. Wouldn't that make things a lot easier, with less risk of
>> actions in one worksheet 'polluting' the namespace of another?
>
> Can you explain in more detail what you mean by this; I don't really
> quite follow.

I suspect the question is, why are the same module objects shared
between all worksheets? The simple answer is, because that's how Python
works. Modules are singletons, and so the same object shows up whenever
you import a given module.

Thus, the question becomes, why are all worksheets executed in the same
process? It's convenient to have the GUI (front-end) and the worksheet
(back-end) in the same process, since that makes it easy to pass Python
objects (notably CustomResults) between the two. That said, there are
some long-range plans to split up the front- and back-ends, which would
address this issue
(http://groups.google.com/group/reinteract/browse_thread/thread/4373612b64c2f5d3#).

But I think it's also worthwhile to consider why it's a problem to have
this behavior. The only problem I see is that modules sometimes contain
state, and it's odd for a change in that state to propagate across all
worksheets. But a module with internal state breaks the Reinteract
model for a single worksheet anyway, since Reinteract can't track the
changes to that internal state. When faced with such a module, I think
the better approach is to wrap it in another module that hides the
internal state changes. As an example, matplotlib keeps track of a lot
of state within itself. Therefore, you don't use matplotlib directly
with Reinteract -- you use replot or refigure2, which try to provide a
(somewhat more) stateless interface.

Robert