Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove code from prefilter that duplicates functionality in inputsplitter #2299

Merged
merged 2 commits into from Aug 13, 2012

Conversation

takluyver
Copy link
Member

This is the first step towards implementing IPEP 2 (#2293). I have removed all the static transformations from prefilter, because we're relying on the equivalent functionality in inputsplitter.

It turns out that the one part of the code still relying on prefilter for those transformations was the ipython-doctest machinery. For now, I've pointed that to a helper function from the magics for the terminal frontend, but I'll move that function into core later.

My intention is that this is merged before other work on IPEP 2, but if people prefer, I can just do the other bits in this branch and then merge in one go.

@takluyver
Copy link
Member Author

Test results for commit e1d0b7e merged into master (9e49929)
Platform: linux2

  • python2.7: OK (libraries not available: azure oct2py pymongo wx wx.aui)
  • python3.2: OK (libraries not available: azure oct2py pymongo wx wx.aui)

Not available for testing: python2.6

@travisbot
Copy link

This pull request passes (merged e1d0b7e into 9e49929).

@takluyver
Copy link
Member Author

Beat you to it, @travisbot .

@fperez
Copy link
Member

fperez commented Aug 13, 2012

Awesome! This is all pure cleanup, hence pure gain on the road to IPEP 2. I don't see any problems with it as-is, since all tests pass.

The one thing that should be done before merging is adding a note to the what'snew doc in the backwards-incompatible section, indicating the removal of this functionality. I just want to make sure we don't forget later on...

@travisbot
Copy link

This pull request passes (merged b60f2ea into 9e49929).

@takluyver
Copy link
Member Author

Thanks, I've added a note to the docs.

@fperez
Copy link
Member

fperez commented Aug 13, 2012

With the doc update this is good to go, thanks!! Merging now.

fperez added a commit that referenced this pull request Aug 13, 2012
…orms

Remove code from prefilter that duplicates functionality in inputsplitter

This is the first step towards implementing IPEP 2 (#2293). Removed all the static transformations from prefilter, because we're relying on the equivalent functionality in inputsplitter.

Note that this is a backwards-incompatible change for anyone who might have relied on the low-level details of the prefiltering machinery.  Regular users of the IPython applications themselves will not see any changes in behavior.
@fperez fperez merged commit 06a7a57 into ipython:master Aug 13, 2012
@ellisonbg
Copy link
Member

@takluyver I won't probably have time to participate in the inputsplitter/prefilter discussions much, but I just wanted to say thanks for tackling this cleanup. We have been meaning to get to it for a long time.

@jasongrout
Copy link
Member

Not surprisingly, and purely FYI, this broke Sage (which transforms text to implement its own magics, like %load).

@takluyver
Copy link
Member Author

I'm a little surprised - what broke? Were you subclassing the transformers
that we removed?

On 25 August 2012 15:02, Jason Grout notifications@github.com wrote:

Not surprisingly, and purely FYI, this broke Sage (which transforms text
to implement its own magics, like %load).


Reply to this email directly or view it on GitHubhttps://github.com//pull/2299#issuecomment-8023535.

@jasongrout
Copy link
Member

I'm not sure exactly what broke yet. Here is the error:


  File "<ipython-input-1-cc43a855c09f>", line 1
    %load "/Users/grout/.sage//init.sage"
    ^
SyntaxError: invalid syntax

sage: 

So apparently our %load magic no longer works. We do various things with prefilter somethings, and I'm sure there are other hacks. Our comprehensive patch is at https://gist.github.com/3466520. The part starting at line 443 seems interesting, and lines 720-790 also seem interesting.

@takluyver
Copy link
Member Author

The reason I'm confused is that we haven't removed any of the architecture

  • if you defined any of your own prefilter transformers, they should still
    work in the same way. And our inputsplitter machinery should still catch
    %load, assuming you're using that. If you call our run_cell, the code
    should be fed to inputsplitter.

I'm finding the patch a bit confusing, because it's the changes to update
from IPython 0.10. Can you summarise the current state of how user input
gets to execution? Or point me to the current code for that integrates
IPython >= 0.11

@jasongrout
Copy link
Member

I'm coming back to this now. The code (after all patches are applied) is here: https://bitbucket.org/jasongrout/sage-library/src/dcb6b8d0028d/sage/misc/interpreter.py

@jasongrout
Copy link
Member

Okay, it seems that we are making a call that looks like IPython.frontend.terminal.interactiveshell.TerminalInteractiveShell.run_cell('%load test.py') (for example, in https://bitbucket.org/jasongrout/sage-library/src/dcb6b8d0028d/sage/misc/interpreter.py#cl-258 or https://bitbucket.org/jasongrout/sage-library/src/dcb6b8d0028d/sage/misc/interpreter.py#cl-1220). This ran the %load magic before this pull request, and seems to complain about a syntax error after this pull request. Does that match up with changes in this pull request?

@jasongrout
Copy link
Member

Also, apparently the IPython %load magic may have changed from 0.10? Instead of executing the loaded file immediately, it seems to now just paste in the file. I don't have an old version of IPython to check if this was a change in behavior---does anyone know off the top of their head?

@fperez
Copy link
Member

fperez commented Sep 7, 2012

On Fri, Sep 7, 2012 at 12:41 AM, Jason Grout notifications@github.comwrote:

Also, apparently the IPython %load magic may have changed from 0.10?
Instead of executing the loaded file immediately, it seems to now just
paste in the file. I don't have an old version of IPython to check if this
was a change in behavior---does anyone know off the top of their head?

Jason, there was no %load magic in ipython 0.10 at all, that was something
added by sage. IPython now has a %load magic of its own, so you may be
seeing a conflict here between the ipython %load and the sage one.

@jasongrout
Copy link
Member

Okay, that explains at least part of the problem: it looks like when we upgraded to ipython, we punted to ipython's %load, which has different semantics than our %load.

I think maybe the way to resolve this issue is to write our own %load magic for our backwards compatibility. Then we don't have to worry about the issue from this pull request either, because we won't be calling back to IPython's %load.

I'm curious: Is there an IPython equivalent for loading and executing a file without pasting it in for editing? For example, I've used Sage's load to load a file across the web like a library.

@fperez
Copy link
Member

fperez commented Sep 7, 2012

On Fri, Sep 7, 2012 at 1:22 AM, Jason Grout notifications@github.comwrote:

I'm curious: Is there an IPython equivalent for loading and executing a
file without pasting it in for editing? For example, I've used Sage's load
to load a file across the web like a library.

%run does that, but it only works for local files. That it doesn't work
for remote ones is just an oversight, easily cured with the right flavor of
PR ;)

@jasongrout
Copy link
Member

That might make sense for us to just make %load an alias for %run, and write the code to get %run up to speed... :)

@fperez
Copy link
Member

fperez commented Sep 7, 2012

On Fri, Sep 7, 2012 at 1:30 AM, Jason Grout notifications@github.comwrote:

That might make sense for us to just make %load an alias for %run, and
write the code to get %run up to speed... :)

That would be great!

mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
…-transforms

Remove code from prefilter that duplicates functionality in inputsplitter

This is the first step towards implementing IPEP 2 (ipython#2293). Removed all the static transformations from prefilter, because we're relying on the equivalent functionality in inputsplitter.

Note that this is a backwards-incompatible change for anyone who might have relied on the low-level details of the prefiltering machinery.  Regular users of the IPython applications themselves will not see any changes in behavior.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants