From: Jacek Generowicz <email@example.com> To: firstname.lastname@example.org Subject: Babel Python sessions severely broken Date: Fri, 9 Mar 2012 19:20:49 +0100 [thread overview] Message-ID: <4f1fbc94-e109-46bf-8ae2-0af04073d8a9@CERNFE22.cern.ch> (raw) Hi, Picking up a few-month-old thread ... On Tue, 21 Jun 2011 10:26:17 -0700, Eric Schulte wrote: > You are suggesting that code to be run "interactively" should be written > to an external file then loaded into the interactive session. This > would certainly work around the syntax limitation of the current setup. > My two concerns here are that > > 1. users who use interactive babel blocks side-by-side with the session > may be used jumping into the session to play with code interactively > and debug, in such cases rather than seeing their code in the session > history they would only see execfile('/tmp/blahblah'). This is (almost) exactly what Emacs' python mode does, so I suspect that many people who wish to work in this way, would be very familiar with this state of affairs. Actually, In modern python modes (Emacs 23, 24, maybe even 22) no clue about any code having been injected into the session appars at all: instead of seeing "execfile(/'tmp/blah')" they see nothing at all. I think that IPyton's emacs-python-mode, might visually inject the whole evaluated code into the session buffer. > Note I do recall discussion on list related to user's reading > their session code in the inferior session buffer. I'd say that that interacting with their code in the session buffer is more important than reading it there (on the grounds of this being the usual python-mode workflow), but reading it there could be good too. > 2. similarly error messages would now point into this temporary file, > rather than back into the session history Yes, this is what happens in current python modes, but M-g M-n and M-g M-p usually manage to send you to the correct place (i.e. your genuine source file, rather than the temporary file) anyway. To see this in action: 1. (In Emacs 23 or 24) Create the following buffer ,----[ foo.py ] | print 1 | print 1/0 | print 2 `---- 2. Ensure that Python mode is enabled for the buffer (Emacs should have switched it on automatically, by observing the .py extension.) 3. C-c C-z (This should start an inferior Python process, and switch to its buffer.) 4. Go back to the foo.py buffer 5. C-c C-c (This should evaluate the whole buffer) The inferior Python buffer should now show something like ,----[ *Python* ] | >>> 1 | Traceback (most recent call last): | File "/tmp/py79095qL", line 2, in <module> | print 1/0 | ZeroDivisionError: integer division or modulo by zero | >>> `---- 6. M-g M-n (This should jump to line 2 in the foo.py buffer) Maybe some of the stuff that's already in python-mode can be reused ? > Basically you would prefer more decoupling from the interpreter I would prefer it to be useable for evaluating normally formatted Python code. In its current state it isn't. That makes it pretty much unuseable for literal programming, creating documentation, tutorials, etc. I don't understand what you mean by "more decoupling from the interpreter". Do you mean "overcoming Python's standard REPL's inability to receive copy-pasted standard Pyton code?". I think that would be a *very* worthwhile thing to support, which is why pretty much anything that pretends to support Python interactivity, goes out of its way to make it possible (Emacs' python-mode, IPython, IDLE are a few obvious examples that come to mind.) > and I'm not sure for the average user if this would be a worthwhile > exchange simply to be able to avoid syntax errors like your > originally mentioned example (which was the first such post I've > seen on this list). The current situation essentially makes Python babel sessions unusable for anything but the most trivial cases. (Or it makes non-trivial use possible at the cost of presening code in a horribly formatted style, one which would be a horror to read.) > I'm disinclined to make such a change without a wider base of support > for the request from the Babel/Python user community Please, please, make it possible to evaluate normal Python code in Python babel sessions. It's really important to understand that the restrictions imposed by Python's plain REPL really are a horrible quirk: I can't imagine anyone preferring the broken (if standard) behaviour, over correct behaviour. Put another way: You won't find many people who take Python interactivity seriously, using the standard REPL. They all use something that gets around the horrible restrictions it imposes. Nobody wants this. > or at least without more complaints about the existing behavior. Please consider this to be a *vehement* complaint about the existing behaviour. :-) (I'd be happy to try to contribute some code to this, but I won't have any time to think about it for, at least, the next 3 weeks.)
next reply other threads:[~2012-03-09 18:21 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-03-09 18:20 Jacek Generowicz [this message] 2012-03-09 20:31 ` Eric Schulte 2012-03-09 21:05 ` Jacek Generowicz 2012-03-09 21:24 ` Eric Schulte
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=4f1fbc94-e109-46bf-8ae2-0af04073d8a9@CERNFE22.cern.ch \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Babel Python sessions severely broken' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).