[Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line triggered by continuation in Shell

SourceForge.net noreply@sourceforge.net
Mon, 03 Mar 2003 05:16:13 -0800


Bugs item #695861, was opened at 2003-03-01 22:40
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579

Category: None
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: David Harris (edcdave)
>Assigned to: Kurt B. Kaiser (kbk)
Summary: Unnecessary blank line triggered by continuation in Shell

Initial Comment:
Windows XP, IDLEfork 0.9a2, Python 2.2.2

The following interactive session generates an 
unexpected blank line:

>>> word = 'letters'
>>> for c in word: print c,
                        # continuation line, pressed Enter
l e t t e r s
>>> 'h' in word
                       # unexpected blank line
0
>>> 'e' in word
1
>>>


IDLE 0.8 does not generate the unexpected blank line. 
The behavior seems to be triggered by a prior need for a 
continuation line.

----------------------------------------------------------------------

>Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-03 08:16

Message:
Logged In: YES 
user_id=6380

You need a way to force a call to Py_FlushLine() after the
subprocess is finished. Unfortunately I don't know how to
force that without writing C code. In Python 2.3, we could
move the call in sys_displayhook() up so that it is executed
even when o equals None; then you could call
sys.displayhook(None) at the end.

Would that work? I'd be willing to add that to Python 2.3b1.
(I hope IDLEfork will be ready for inclusion in Python by
then too.)

----------------------------------------------------------------------

Comment By: Kurt B. Kaiser (kbk)
Date: 2003-03-02 20:18

Message:
Logged In: YES 
user_id=149084

Somewhat simplified:

Python 2.2.2 (#1, Mar  2 2003, 00:38:54) 
[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2
Type "copyright", "credits" or "license" for more information.
IDLEfork 0.9a2
>>> print 1,
1
>>> 1

1
>>> 1
1

When the code for '1' is executed the subprocess is sending
a request to print \n before its request to print '1'.   It seems that
the whitespace character is being held off somehow and 
replaced with a newline if the following statement isn't a "print".
Curious it doesn't happen with IDLE0.8.  

This is a little hard to debug and not too important compared to
some other things so I'm lowering the priority and putting it on 
the back burner.  If you want to dig in and supply a patch I'll
bet you learn a bit about Python before you're done  :-)  

----------------------------------------------------------------------

Comment By: David Harris (edcdave)
Date: 2003-03-02 12:52

Message:
Logged In: YES 
user_id=72287

I think I understand. The comma is contributing to the 
behavior, but I'm not sure that's the whole story. For example,

>>> print "test",
test
>>> print "test"
 test
>>> print "test"
test

The second output has a leading space (induced by the first 
command?). But why didn't I get a blank line like the original 
example?

My apologies for submitting what seems to be a superficial 
bug. I'm very new to Python, but I have 20 years experience 
in C and others. When I saw the on-again/off-again behavior of 
the blank line, I imagined a situation where a variable was not 
reset (which could have a wider impact than the display).

----------------------------------------------------------------------

Comment By: Guido van Rossum (gvanrossum)
Date: 2003-03-02 07:51

Message:
Logged In: YES 
user_id=6380

It's not a continuation line. More likely it's that the
subprocess where your code runs has an unterminated output
line for which both it and IDLE's stdout provide an extra
newline at some later point.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579