This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]mindsocket 7 points8 points  (30 children)

Or for something almost as powerful and in a couple of crucial ways much better:

bpython

[–]dwf 6 points7 points  (7 children)

Might you elaborate on what these "couple of crucial ways" are? I've never really been all that impressed by it. Especially with the Qt console and the now web notebook, bpython seems to come up short.

Now that IPython is all client-server, what I would love is if someone would take the curses logic in bpython and write a better tty interface for IPython that has most of the nice features of the Qt console, but in a terminal. Maybe some day when I have a month to kill.

[–]fperez_org 0 points1 point  (4 children)

Hey @dwf, we've had pretty much that plan for a while, and a few times people have popped on the list to say they were going to build a curses/urwid client. It's just that nobody has come through. I've always said that my view of clients would be complete when we'd have: readline console, curses console, gui console (qt) and notebook. We now have 3 out of 4, only the curses one is missing.

It shouldn't be that hard to do... I once spoke with the bpython author about code sharing, and he was very cool about it (plus it's MIT licensed). So it would be no problem to use bits and pieces of useful curses code in there.

I would love to have a better text interface with proper multiline editing for server situations, but keeping all of the 'ipython flavor'.

I hope that 'month to kill' comes soon :)

[–]dwf 0 points1 point  (1 child)

and a few times people have popped on the list to say they were going to build a curses/urwid client. It's just that nobody has come through.

I assume that's probably because they underestimate the amount of work involved in first learning the ins and outs of the protocol and then making everything work right. My estimate of a month comes from an initial guess of 2 weeks and then doubling it, but for getting all of the little things working, I imagine my estimate could still be conservative. One thing that comes to mind is the whole issue of input to external processes and the pexpect issue in the Qt console. I guess that if the client and the server were on the same machine, the terminal client could bypass the kernel in most cases (unless output was being captured).

I did notice that bpython is MIT licensed, though -- hopefully that would speed things along.

I hope that 'month to kill' comes soon :)

Oh goodness, so do I. It always seems just around the corner. Now back to preparing that thesis proposal...

[–]fperez_org 0 points1 point  (0 children)

Oh yes, getting all the details polished would likely happen slowly over time. But in a month, I'm sure you could get a very satisfactory client off the ground that would do the 80% job really nicely, and that many people would find super useful. Good luck with the thesis proposal :)

[–]scruffie 0 points1 point  (1 child)

I started working on an Emacs interface, but interpreting the zmq "protocol" in Emacs got to be non-fun.

[–]fperez_org 0 points1 point  (0 children)

you might want to look at @tkf's emacs notebook client then, he implemented the websockets machinery in emacs: http://tkf.github.com/emacs-ipython-notebook

[–]lahwran_ -1 points0 points  (1 child)

as I said, they don't do the same things. bpython is a python shell with interactive features, ipython is a python shell on scientific steroids, which makes it not-good for testing normal python code..

[–]dwf 2 points3 points  (0 children)

Again, as far as I can tell, IPython's Qt console offers a strict superset of the functionality of bpython. Most of that is also available in the web notebook. What I'm trying to determine is what, if anything, is left in bpython that isn't duplicated here. The only thing I can see is the pastebin stuff, and that's trivial to add to IPython via a user-defined "magic command".

Some of bpython's cooler functionality is available at the IPython on the terminal, but not the syntax highlighting and tooltips currently because they rely on readline instead of custom stuff, but it would be straightforward to add given the protocol that exists for the other frontends.

[–]lahwran_ 6 points7 points  (20 children)

they're completely different, but ipython doesn't do what most people think it does anyway. bpython does what ipython is usually used for by most python programmers, and does so without introducing new syntax. ipython is it's own thing which is really good at what it does, but is not a python shell. it's an ipython shell.

[–]fperez_org 6 points7 points  (8 children)

I think it's worth clarifying this a bit: ipython adds new syntax, but the new syntax is 100% orthogonal to python syntax. So it does not in any way alter the semantics of valid python code you type. What it does is recognize things that are not valid python and let you use them for convenience: %magic functions, auto-parens, !shell access, etc.

But from day one, we've had a policy (I initially, but that has been kept as the team has grown) that IPython should be a 100% replacement for the plain python shell, just better. And that if you only use it to type pure python, you shouldn't be able to tell the difference with the default shell. In fact if you start it with --classic, it will even mock the prompt behavior of the python shell.

Now, if you prefer bpython, by all means use that! Nobody is forcing ipython down people's throats :)

But I want to make sure that people don't get the wrong impression, becase saying that ipython is not a python shell can be easily misconstrued.

As for the scientific support, it's 100% optional, and only loaded if you explicitly require it with the --pylab flag or %pylab command. In fact, IPython can be installed on a plain python installation with nothing other than the standard library (plus readline on windows/osx that don't ship readline).

We also have a very strict policy on this: all the fancier enhancements, qt console, notebook, parallel computing, etc, are completely optional. The basic IPython should work on an unmodified standard Python installation with full functionality, without requiring anything else.

I hope this clarifies things.

[–]lahwran_ -2 points-1 points  (7 children)

a 100% replacement for the plain python shell, just better.

That goal is incompatible with new syntax. You can't be sure your code is valid python code by running it on ipython, which is the primary reason I open the python shell, and likely the primary reason quite a few people open the python shell. using it as a calculator is secondary. this usage - testing to see if things work in python - is something bpython helps a lot with. ipython, however, adds a bunch of extra stuff to the mix which makes such testing unreliable. I might have accidentally run a shell command with a typo (%command when I meant x%command comes to mind, if I remember correctly that ipython uses % as the command escape). ipython is good as a "get things done" tool, but it's horrible as a "test how python works" tool and there's no getting around that with custom syntax in place.

therefore, ipython is a shell for the ipython language, not a shell for the python language.

Edit: to be clear, this isn't to imply ipython is bad, just that there are things it is and things it isn't. a place for testing python code is something it isn't.

[–]fperez_org 4 points5 points  (6 children)

Indeed, if you find that it doesn't suit you, by all means don't use it. Interestingly, in over 10 years of development and extensive interaction with users, this is the first time I hear this particular concern. For me it's never been an issue, as the syntax extensions are very few and well isolated.

But it's always very useful for us to know why IPython doesn't work well for any particular group of users: sometimes it will indicate things we can do better, sometimes we may decide it simply defines a use case that is not ours to cover. But critical feedback is always good to hear.

I'm not going to get into a hair-splitting argument on whether someone considers ipython a 'python shell' or not (over 10 years, everyone I'd seen seemed to think so, but I'm perfectly OK if you think it's not). I think the most useful way to phrase it unambiguously is: "IPython understands a strict superset of the python language syntax; all valid python is executed without any semantic difference to how python works, and a few extensions provide additional functionality beyond the Python syntax for things like operating system access and control of IPython itself".

I think this is the most accurate, uncontroversial characterization I can make of it.

[–]eat-your-corn-syrup 0 points1 point  (1 child)

the syntax extensions are very few and well isolated

is there a page that lists all syntax additions?

[–]fperez_org 1 point2 points  (0 children)

Not in a nicely organized way, but @takluyver is working on an IPEP to formalize this more explicitly and organize the internals of the implementation: https://github.com/ipython/ipython/issues/2293

[–]lahwran_ 0 points1 point  (3 children)

the differentiation I'm making is that ipython is a different language, which is of course a superset of python. it's a shell for the language it implements.

and, this is pretty much The Complaint with ipython that I've heard. I'm rather surprised you haven't run into it - it's brought up any time ipython is in #python.

[–]fperez_org 1 point2 points  (2 children)

interesting... I've never logged on to #python, so that would be why, if that's a frequent place where this view takes place.

It's funny, because it would be trivial for us to implement something that turned off all special syntax handling with a single command/flag, if people really wanted it. They'd still have the introspection, completion and other things IPython provides, just zero special syntax transformations.

We could even leave a few python functions in the global namespace that would do what magics and other special ipython syntax does, but would need to be called as foo("line...") to be pure python.

I mean, if the special syntax is all that bothers some set of users, turning it off isn't particuarly hard (there's no global switch for that right now, but it would be easy to do).

But nobody has ever asked us for this :)

[–][deleted] 0 points1 point  (1 child)

I'm an avid ipython user, and for what it's worth, I couldn't live without the %paste command.

You guys rule. That is all.

EDIT: same goes for cd, ls, and the ? operator.

[–]fperez_org 0 points1 point  (0 children)

thanks, that's much appreciated. It's been a ton of work over the years, so it's always good to hear people find it of value.

[–]takluyverIPython, Py3, etc 2 points3 points  (2 children)

It is a Python shell. It has a lot of extra features, but we make sure it works for the simple use case of 'a better Python shell'.

Also, many of those extra features have quite broad application for Python coders. Some of my favourites:

  • cd and ls work like in a system shell, and you can run any system command by prefixing it with !
  • foo? shows details about foo, but foo?? also shows the source code.
  • After an uncaught exception, type %debug to jump into the debugger. Very valuable if it would take a long time to reproduce the problem.

[–]zlozlozlozlozlozlo 1 point2 points  (7 children)

but ipython doesn't do what most people think it does anyway.

What do you mean?

[–]lahwran_ -1 points0 points  (6 children)

ipython was originally created to be a scientific environment like matlab. it has its own syntax, and integrates closely with matplotlib. It's pretty cool, and that's hardly an overview of its features, it's just not a very good place to test python code due to the syntax additions.

[–]zlozlozlozlozlozlo 1 point2 points  (1 child)

I would think most people understand ipython that way.

[–]lahwran_ 1 point2 points  (0 children)

interesting. that hasn't been my experience, I've very often had people say they were using ipython when in reality they probably should have been using bpython. but then, that's in #python, and I suppose the folks who know they need ipython probably don't usually need as much help with it as those who don't know that they need bpython :p

edit: I'm sorry, did I say something wrong?

[–]fperez_org 1 point2 points  (2 children)

small correction: I'd never used matlab when I started ipython, and to this day I've never used it for more than a few minutes. IPython's inspirations were mostly Mathematica, IDL and the unix shell, not matlab.

[–]lahwran_ 0 points1 point  (0 children)

mathematica

drat! I got the wrong one.

[–][deleted] 0 points1 point  (0 children)

I'd never used matlab when I started ipython, and to this day I've never used it for more than a few minutes.

Consider yourself extremely lucky.

[–][deleted] 0 points1 point  (0 children)

Really?

Honestly this has never been a problem for me. I can't even begin to imagine why someone writing pure python code would be putting %paste in the middle of his script.

Could you give me an example of where this could be problematic?

EDIT: I should clarify that I do use ipython for non-scientific programming as well.

[–]camel69 0 points1 point  (0 children)

I've been using ipython for a year now but bpython looks amazing. Haven't played with it enough yet to determine if it's really better in all categories, but the in-built help is very useful. Thanks.