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

Inject a flag variable into the global namespace to indicate to a script that it’s running inside bpython #795

Open
fish2000 opened this issue Feb 4, 2020 · 1 comment
Assignees
Labels
Milestone

Comments

@fish2000
Copy link

@fish2000 fish2000 commented Feb 4, 2020

It would be very advantageous if one could easily discern whether or not the execution environment is bpython.

For example, in IPython, the REPL environment sets a global variable __IPYTHON__ to True. This allows for trivial tests like e.g.:

try:
    __IPYTHON__
except NameError:
    in_ipython = False
else:
    in_ipython = True

Contrastingly, I just tried to programmatically figure out if my script was running in bpython or not, and the experience was… wanting. I tried the following three rubrics:

  1. BPYTHON = type(sys.stdout).__module__.startswith('bpython')
  2. BPYTHON = 'bpython' in sys.argv[0]
  3. BPYTHON = '__console__' in sys.modules

The first two methods work in the interactive REPL but don’t work in code loaded using the -i flag – presumably because it runs both before sys.stdout and friends have been wrapped, and before sys.argv has been mutated. The last method does seem to work, but it feels extremely janky and fragile and I don’t trust it to survive the next volley of bpython internals-refactoring.

So: can we get an officially-sanctioned method of determining that bpython is our host? That would be amazing, assuredly. It’s a great REPL, I use it every day – this’d make it even more betterer. Indeed!

@supakeen supakeen self-assigned this Apr 11, 2020
@supakeen
Copy link
Member

@supakeen supakeen commented Apr 11, 2020

Hey hey, what's the usecase for this? If there's a good one there's no problem in adding this.

Is using PYTHONSTARTUP a workaround for now?

@supakeen supakeen added this to the release-0.20 milestone Apr 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.