From: "Ken Manheimer" <ken.manheimer@gmail.com>
Cc: Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se>,
Stefan Monnier <monnier@iro.umontreal.ca>,
emacs-devel@gnu.org
Subject: Re: python-mode: make sure output is not eaten
Date: Fri, 25 Aug 2006 15:53:56 -0400 [thread overview]
Message-ID: <2cd46e7f0608251253s3d4dbf47y3f011435d6092b28@mail.gmail.com> (raw)
In-Reply-To: <E37BF3DF-DA04-415D-B764-E5B75E7D84EB@acm.org>
On 8/24/06, Steven Huwig <steven.huwig@gmail.com> wrote:
>
> On Aug 23, 2006, at 12:04 AM, Stefan Monnier wrote:
> >
> > Yes, of course. BTW do you have any idea why the current code uses
> > "\n\n"?
>
> Might it be because the Python interactive interpreter needs the extra
> newline due to significant whitespace? E.g.
>
> >>> for i in range(1,5):
> ... print i,
> ...
> 1 2 3 4
i haven't looked at the code in question, but have a salient point to
offer. the handling of interactively entered python code is different
than the processing of source code from a file, specifically in that
the end of top-level blocks is detected by an empty line of input.
this is necessary because, during interaction, you don't want to
require people to enter the first line of the subsequent top-level
construct to determine that the previous top-level construct has
concluded. instead, it's assumed they've concluded when an empty line
is encountered.
i suspect that the "\n\n" you all are referring to is specifically to
provide that newline.
> a DEDENT token is created by the unindented second newline, closing
> the block. A single newline cannot do that as it is also the
> statement terminator.
... and a double newline doesn't have this effect for file input,
where the interpreter/compiler *can* wait for the first line of the
next top-level construct, or end-of-file.
> [...]
--
ken
ken.manheimer@gmail.com
http://myriadicity.net
next prev parent reply other threads:[~2006-08-25 19:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-21 20:16 python-mode: make sure output is not eaten Slawomir Nowaczyk
2006-08-22 6:10 ` Stefan Monnier
2006-08-22 18:26 ` Slawomir Nowaczyk
2006-08-23 4:04 ` Stefan Monnier
2006-08-25 0:18 ` Steven Huwig
2006-08-25 0:34 ` Steven Huwig
2006-08-25 1:29 ` Steven Huwig
2006-08-25 9:03 ` Slawomir Nowaczyk
2006-08-25 19:53 ` Ken Manheimer [this message]
2006-08-25 20:10 ` Stefan Monnier
2006-08-25 9:03 ` Slawomir Nowaczyk
2006-08-25 22:53 ` Stefan Monnier
2006-08-26 12:41 ` Slawomir Nowaczyk
2006-08-26 14:48 ` Stefan Monnier
2006-08-26 22:22 ` Slawomir Nowaczyk
2006-08-28 21:43 ` Stefan Monnier
2006-08-30 21:08 ` Slawomir Nowaczyk
2006-08-30 22:10 ` Stefan Monnier
2006-08-31 11:19 ` Slawomir Nowaczyk
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.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2cd46e7f0608251253s3d4dbf47y3f011435d6092b28@mail.gmail.com \
--to=ken.manheimer@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=slawomir.nowaczyk.847@student.lu.se \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.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).