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

Drop fakemodule #3622

Merged
merged 7 commits into from Sep 18, 2013
Merged

Drop fakemodule #3622

merged 7 commits into from Sep 18, 2013

Conversation

takluyver
Copy link
Member

[ not for 1.0 ]

After PR #3555, I don't think we have any need for our FakeModule class, so this removes it in favour of just using ModuleType.

There shouldn't be any user-visible benefit, so we could leave this until after release if we're going into stability mode. On the other hand, it changes an (undocumented) API, so we might prefer to do this before 1.0.

@@ -209,7 +208,8 @@ def store(self, parameter_s=''):
raise UsageError("Unknown variable '%s'" % args[0])

else:
if isinstance(inspect.getmodule(obj), FakeModule):
modname = getattr(inspect.getmodule(obj), '__name__', '')
if modname == '__main__':
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This also fixes a minor bug with %store - it should print an error if you try to %store a class/instance/function defined in the interactive namespace. But the implementation was based on us using FakeModule for the interactive namespace, which we weren't since I reorganised the interactive namespace machinery some time ago.

This isn't perfect, since if you %run subdir/a.py, things defined in that script will have the module name a, which isn't importable, but it won't warn for those. We could mark modules created for %run with some extra attribute that %store checks, but I'm not sure that it's necessary.

@fperez
Copy link
Member

fperez commented Jul 13, 2013

It's late and I have to catch a flight in the morning, so I can't really review this in detail.

But I want to record a huge +1 from me on this idea: FakeModule has been a constant source of weird and obscure bugs over the years, and if we can get all the behavior we need without it, by all means go for it.

However, I remember introducing it because certain behaviors with %run wouldn't work in the same manner than a plain python script at the shell without this hack. I would like to think that all those reasons are now tested, so that if your changes don't break the test suite we're golden. But that may be wishful thinking...

So please double, triple-check every imaginable scope/pickling/etc issue you can think of that could be affected by this...

I'm almost thinking we should defer this to post 1.0 just to be safe, since it's more of a cleanup than a burning necessity... I just don't want to get hit by an obscure but nasty bug introduced by this that would force us into a rapid 1.0.1....

@ivanov
Copy link
Member

ivanov commented Jul 13, 2013

So please double, triple-check every imaginable scope/pickling/etc issue you can think of that could be affected by this...

and do this by adding tests to the test suite, naturally... :)

@takluyver
Copy link
Member Author

Thanks. I'm happy to leave it until after 1.0, then.

I'll do my best to try bizarre corner cases with this.

@minrk
Copy link
Member

minrk commented Jul 15, 2013

👍 to putting this in the "immediately post-1.0" stack.

@Carreau
Copy link
Member

Carreau commented Aug 10, 2013

This need a rebase.

@takluyver
Copy link
Member Author

Done, it was just a docs conflict.

@Carreau
Copy link
Member

Carreau commented Aug 16, 2013

:-( Need rebase again

@Carreau
Copy link
Member

Carreau commented Aug 19, 2013

... to putting this in the "immediately post-1.0" stack.

Does this means that now it has been rebased it should be merged ?

(not that I'm alway +1 on merging soon to test)

@takluyver
Copy link
Member Author

I've added a couple more tests, for the -n and -e options to %run. I think the test suite for run is fairly good now, so this is probably safe to merge.

# Since '%run foo' emulates 'python foo.py' at the cmd line, we must
# set the __file__ global in the script's namespace
# TK: Is this necessary in interactive mode?
prog_ns['__file__'] = filename
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think matching plain Python is a good idea - interactive Python has no file, whereas script or execfile defines it.

minrk added a commit that referenced this pull request Sep 18, 2013
Drop fakemodule

After PR #3555, I don't think we have any need for our FakeModule class, so this removes it in favour of just using ModuleType.

There shouldn't be any user-visible benefit, so we could leave this until after release if we're going into stability mode. On the other hand, it changes an (undocumented) API, so we might prefer to do this before 1.0.
@minrk minrk merged commit 2e41dab into ipython:master Sep 18, 2013
mattvonrocketstein pushed a commit to mattvonrocketstein/ipython that referenced this pull request Nov 3, 2014
Drop fakemodule

After PR ipython#3555, I don't think we have any need for our FakeModule class, so this removes it in favour of just using ModuleType.

There shouldn't be any user-visible benefit, so we could leave this until after release if we're going into stability mode. On the other hand, it changes an (undocumented) API, so we might prefer to do this before 1.0.
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