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

Custom banner for apython #20

Closed
gnachman opened this issue May 11, 2018 · 6 comments
Closed

Custom banner for apython #20

gnachman opened this issue May 11, 2018 · 6 comments

Comments

@gnachman
Copy link
Contributor

I plan to use aioconsole's apython for an interactive REPL for iTerm2's upcoming Python scripting API. It's almost perfect, except that customizing the banner is not possible. In order to keep things simple, I would like not to ship my own implementation of your apython script, since I expect it may change over time. Would you be open to adding --banner to apython.py?

Thanks for a great module!

@vxgmichel
Copy link
Owner

Hi @gnachman, and thanks for creating this issue!

Would you be open to adding --banner to apython.py?

Definitely! I think it makes sense to expose all the optional arguments provided by aioconsole.run_console and aioconsole.set_interactive_policy through the apython script:

def run_console(*, locals=None, banner=None, serve=None):

Right now banner and locals are missing, so I'm planning to add them both (using ast.literal_eval for the locals dictionary).

Also I'm quite intrigued by the use of aioconsole in your project, I'll have a look at the corresponding issues on the iTerm2 repo :)

Thanks again!

@gnachman
Copy link
Contributor Author

You can play with it in the nightly build. Select Open Python REPL from the Scripts menu.

Do you have any sense for whether apython will be robust to future changes in the Python language? I'd like to let people write scripts without having to put them in a function, but I'm worried that whatever mechanism aioconsole uses to allow await at the top level might not work forever.

@vxgmichel
Copy link
Owner

Do you have any sense for whether apython will be robust to future changes in the Python language?

The project relies on many part of the standard library but most of it can be expected to remain backward compatible. There are a few exceptions though:

  • asyncio is a bit more stable than before, but it's still subject to changes.

  • the readline integration in the apython script relies heavily on cpython implementation details (see input_with_stderr_prompt, issue Support readline or equivalent alternatives #7 and PR Add readline support #9)

  • the asynchronous code execution is quite subtle, as you probably noticed, considering your last comment:

    I'm worried that whatever mechanism aioconsole uses to allow await at the top level might not work forever.

    My feeling about this is that the use of the ast module makes the asynchronous execution quite robust, except for this manual indentation handling which I'll try to replace some day.

    In any case, I'd expect asynchronous code execution to be added to the language at some point (since it is clearly not trivial). I did not make a feature request yet and I don't know if someone did it either, but it would probably be good to start a discussion with the core devs at some point.

Also, feel free to have a look at PR #21 to see if it fits your needs. Do you need a new release once this PR is merged?

@gnachman
Copy link
Contributor Author

That makes sense. I think it makes sense to start with aioconsole as the REPL but still require people to write regular Python code for their "real" scripts.

I commented on #21 but yes, please do make a new release once this is merged. I have to distribute a standalone python environment and it's built by pulling packages with pip and zipping up the result.

@vxgmichel
Copy link
Owner

That makes sense. I think it makes sense to start with aioconsole as the REPL but still require people to write regular Python code for their "real" scripts.

Sounds good!

I commented on #21 but yes, please do make a new release once this is merged. I have to distribute a standalone python environment and it's built by pulling packages with pip and zipping up the result.

No problem!

@vxgmichel
Copy link
Owner

vxgmichel commented May 17, 2018

PR #21 is merged and v0.1.8 is now released.

Thanks again!

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

No branches or pull requests

2 participants