Why I'm not ready to switch to BPython (at least not yet)

[alexande...@gmail.com]

I usually avoid tool upgrades - because nothing ever works like you want it to, and the upgrade to tool X save 10seconds per task A, ends up costing an entire day of configuration. But it finally seemed time to switch from the default python interactive shell to something else. The two alternatives are IPython and Bpython. Both of which support a bunch of rather advanced features - and neither of which support some very obvious things.
a) Lack of CodeBlock history recall
One of these very obvious things (and among the more pressing reasons to switch from the default Pyton Interactive Shell) is code block rather than line wise recall - Javascript consoles do this, the default Julia interactive console does this, It's a very obvious and needed feature and one that's very noticeably lacking (and I'm sure I'm not the only one).
b) Autocomplete has very unusable completion options
For one, I don't think most people need to see the command arguments and __doc__ for the print it or abs functions while they are typing them - but setting 'auto_display_list': False, will still do single tab completion - which more properly should only display the list on tab and complete on double-tab if there is more than one possible option (i.e. the way fish shell tab-completion works). FUZZY, SUBSTRING, completion produce completely unusable results, there is no frequency based history completion.
c) various minor complaints
-The key-combo to exit b-python doesn't work if the line is not empty - (in regular python interactive shell, the first keyboard interrupt will wipe the current line, the second one will exit) - and there doesn't seem to be a regular interrupt (wiping the line is not the same, if you want to cancel a whole block of input).
-Ctrl arrows no longer move one word left or right.
-History is shared - this might be nice, maybe 20% of the time, but if you are working on two completely different things in different sessions it's very awkward to have one session's history show up in another.
-Sparse documentation

I don't mean this to sound like a rant or anything of the sort, I really want to like BPython, I like it's simplicity better than IPython, and over-time if I keep using Bpython I would probably work on some of these things. At any-rate I didn't want to start a bunch of separate threads for what might be very possibly my own subjective criticisms.

[Bob Farrell]

Hi Alexander,

Thanks for sharing your thoughts. As I'm sure you understand, free software being what it is, it's quite rare to get something that feels like a finished, polished product if you're not paying for it. I'm the original author of bpython and I haven't touched the code in several years. The remaining development is slow, driven by a handful of people who like the project enough to contribute their time to it. There's no real incentive to make it suit anyone other the people who work on it.

I don't really use Python much any more (I only code at work, and work has moved away from Python) so I have very little incentive to improve the project. I think it's easy to mistake a handful of people who like a project and don't mind adding a few tweaks to it now and then for a professional team of developers working under a project leader. Sending us an email telling us why you don't use it is unlikely to make us do anything to improve it (more accurately: make it suit you) because whether you use it or not frankly makes no real difference to us. I only say that because it's true; it's not supposed to sound snarky ! :)

So, in one sentence, I'm afraid it comes down to the all-too-familiar response you've probably seen dozens of times: if you don't like it, fork it and fix it yourself. We'll gladly accept pull requests. :)

Hope your holiday season is treating you well; all the best !

P.S. if you wanted to donate something in the region of $3000 I would probably be interested in picking up the issues you mentioned. I hope that puts it in perspective for you. ;)

--
You received this message because you are subscribed to the Google Groups "bpython" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bpython+u...@googlegroups.com.
To post to this group, send email to bpy...@googlegroups.com.
Visit this group at http://groups.google.com/group/bpython.
For more options, visit https://groups.google.com/d/optout.

[Thomas Ballinger]

Hi Alexander,

Thanks for the feedback. As Bob says, it's unlikely all these things will be fixed soon. I'd like to add your comments to the appropriate issues (github.com/bpython/bpython/issues) or create new ones, but won't have time to do this myself until January 15th. If you do work on any of these before then, let us know and we may be able to save you some time by providing background or suggesting a direction. You might try bpython-curtsies (via pip install bpython[curtsies] or similar and then running bpython-curtsies) and/or use the master branch instead of the last release, as both of these address some portion of the issues you bring up.

Tom

[alexande...@gmail.com]

Hello Bob,
Thanks for the reply. No, I definitely was not expecting an enterprise finished product - although to be honest if the a majority of tools I used were not free and cost say $5-10 (for the simpler tools), they would probably pay for themselves several magnitudes of times over in productivity. I don't know why open-source became embryonically-linked with 'free' software, probably because it's hard to have a non-free business model, but I'm very unconvinced it's a good thing (i.e. I think it's a very common case that thousands of users could have saved an hour if the original developer put in thirty more hours, but alas there is no incentive model for it), Anyways. - Best holiday wishes to you as well -

@Thomas
Sure thing, I just didn't want to come up out of no where and open multiple issues on Github, which may not even be considered to be issues (I mean maybe the author(s) would have felt strongly that code recall should be line and not block based, for all I know).
Separate history sessions (with an option to share history, or load from an existing session should be easy).
Code-block recall and frequency based tab completion shouldn't be too bad.
I have no idea about the Ctrl-Arrowkeys (since there appears to be already an open topic on this mailing list about it, without a conclusive response).

[Thomas Ballinger]

Hi Alexander,

I have some time now so I'll update you on the status of these.

a) Lack of CodeBlock history recall
One of these very obvious things (and among the more pressing reasons to switch from the default Pyton Interactive Shell) is code block rather than line wise recall - Javascript consoles do this, the default Julia interactive console does this, It's a very obvious and needed feature and one that's very noticeably lacking (and I'm sure I'm not the only one). 

See https://github.com/bpython/bpython/issues/22 - this is the least likely of the changes to propose to make it through IMHO - but it's frequently asked for enough that having an option for it would be popular. I personally like the way the Julia REPL uses different keys for line vs block history, but ptpython's IPython Notebook-like approach is cool too - if that were adopted it'd have to be a mode because it's very different behavior.

b) Autocomplete has very unusable completion options
For one, I don't think most people need to see the command arguments and __doc__ for the print it or abs functions while they are typing them - but setting 'auto_display_list': False, will still do single tab completion - which more properly should only display the list on tab and complete on double-tab if there is more than one possible option (i.e. the way fish shell tab-completion works). FUZZY, SUBSTRING, completion produce completely unusable results, there is no frequency based history completion. 

I've killed fuzzy and substring in master, but wouldn't be averse to adding them again. `auto_display_list` doesn't work properly right now - it should either be deprecated or fixed (https://github.com/bpython/bpython/issues/74). I personally really like auto_display_list=True behavior (the default) but it would be great if False worked too.

 

c) various minor complaints
-The key-combo to exit b-python doesn't work if the line is not empty - (in regular python interactive shell, the first keyboard interrupt will wipe the current line, the second one will exit)

fixed in master 

- and there doesn't seem to be a regular interrupt (wiping the line is not the same, if you want to cancel a whole block of input).

fixed in curtsies, not master bpython though 

 
-Ctrl arrows no longer move one word left or right.

regression that should be fixed - please open an issue 

 
-History is shared - this might be nice, maybe 20% of the time, but if you are working on two completely different things in different sessions it's very awkward to have one session's history show up in another. 

You should open an issue and make the case for this - I don't see it personally. 

-Sparse documentation

YES! This should absolutely be fixed. At this point even a blog post describing bpython use would be terrific too.

If I were implementing multiline completion I would do it in bpython-curtsies, as I think it would be easier, and bpython-curtsies is (hopefully, probably) the future default bpython. However it's not currently suitable for this, and I'm hoping to work on getting it ready in February.

cleverer autocompletion would be interesting - bpython-curtsies has the simplest possible version of this already such that hitting right arrow completes the last possible version - maybe that's the interface you'd want to use instead of the list box below?

Tom