Bug report
Bug description:
Problem Description
The antigravity standard library module executes an immediate side-effect upon import. It invokes the webbrowser module to launch an external browser session to show a webcomic. While historically included as an Easter egg, running executable environment changes immediately during an import phase interrupts active developer workflows, breaks focus during tutorial or code troubleshooting sessions, and creates problematic behavior in headless, automated, or CI/CD environments.
A core principle of technical documentation is not to try to be funny or cute, especially when the developer is trying to troubleshoot a problem. When someone's trying to debug a problem, they last thing they're interested in is someone's delightful sense of whimsy—much less having some irrelevant module being invoked without so much as a permission request. Leave the Easter eggs to the bunny.
Steps to Reproduce
Run the following statement in an interactive interpreter or local script:
import antigravity
Expected Behavior
Importing a standard library module should strictly expose APIs or load code logic into memory. It should not execute external environment mutations or launch desktop applications without explicit function invocation by the developer.
Actual Behavior
A default web browser immediately opens external web infrastructure, seizing system window focus and breaking the active coding environment loop.
Proposed Resolution
Refactor antigravity.py to decouple the browser invocation from the initial import sequence. Move the webbrowser.open() call inside an explicit function (e.g., antigravity.show()) so that the application-launching behavior must be intentionally requested rather than triggered silently by an import statement.
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS
Bug report
Bug description:
Problem Description
The antigravity standard library module executes an immediate side-effect upon import. It invokes the webbrowser module to launch an external browser session to show a webcomic. While historically included as an Easter egg, running executable environment changes immediately during an import phase interrupts active developer workflows, breaks focus during tutorial or code troubleshooting sessions, and creates problematic behavior in headless, automated, or CI/CD environments.
A core principle of technical documentation is not to try to be funny or cute, especially when the developer is trying to troubleshoot a problem. When someone's trying to debug a problem, they last thing they're interested in is someone's delightful sense of whimsy—much less having some irrelevant module being invoked without so much as a permission request. Leave the Easter eggs to the bunny.
Steps to Reproduce
Run the following statement in an interactive interpreter or local script:
import antigravity
Expected Behavior
Importing a standard library module should strictly expose APIs or load code logic into memory. It should not execute external environment mutations or launch desktop applications without explicit function invocation by the developer.
Actual Behavior
A default web browser immediately opens external web infrastructure, seizing system window focus and breaking the active coding environment loop.
Proposed Resolution
Refactor antigravity.py to decouple the browser invocation from the initial import sequence. Move the webbrowser.open() call inside an explicit function (e.g., antigravity.show()) so that the application-launching behavior must be intentionally requested rather than triggered silently by an import statement.
CPython versions tested on:
CPython main branch
Operating systems tested on:
macOS