[Idle-dev] The '>>> ' prompt is bad

[Guido van Rossum]

On Wed, Jun 20, 2012 at 4:51 PM, Alan Gauld <alan.gauld at btinternet.com> wrote:
> On 17/06/12 02:12, Terry Reedy wrote:
>
>> That is exactly what I mean. The first four *fixed width* characters are
>> off limits to the user.
>
>
> OK, I see what you mean now. And that's a by-product of the DOS box only
> allowing mono-spaced fonts (I think, its been a while since I used Windows
> DOS boxes!)
>
>
>>>>  >>> and consequently the first indent may not look like an indent.
>>>> Indeed, with Lucida Sans Unicode, '...     ' is *shorter* than '>>> ',
>>>> so that the first indent is visually a dedent! This is not acceptible.
>>>
>>>
>>> But better than the current situation with no secondary prompt - at
>>> least you can see that there is some kind of indent wrt the prompt.
>>
>>
>> I consider having the first indented line start to the *left* of the
>> unindented line above to be worse than the current situation.
>
>
> But that is the current situation in IDLE? With no secondary prompt the
> first indented line often starts to the left of the unindented line above.

Really? For me, Idle's shell window defaults to one TAB for
indentation, and that's intentional. Since a tab is 8 spaces, this
indents the first indented line 4 spaces beyond the first indented
line. In the interactive prompt, you rarely need more, but if you do,
you'll get 8-space indents.

>>> But in Python anyone who uses non mono-spaced fonts for coding is asking
>>> for trouble IMHO!
>>
>>
>> I do it regularly, with little problem. In Python 3, both text and
>> identifiers are unicode. I do not know that there are any fixed-pitch
>> unicode fonts. It would make ascii chars spaced too far apart.
>
>
> Hmm, you've lost me there. What difference does Unicode make to the display?
> Surely Unicode only affects how many bits are used to store the characters
> not how they are displayed?

Some unicode characters are so much wider than the latin alphabet that
displaying them all at the same width would make no sense. Check out
any Chinese website.

>> has to accommodate Python 3.x code, which include unicode identifiers as
>> well as strings.
>
>
> Sure, Python can work with non mono-spaced fonts - always has - but they can
> mess up indentation so that off-by-one-space errors are hard to spot. (Not
> so big an issue if you always use tabs for indents I guess...but that's
> another debate! :-)

Actually detecting off-by-one-space errors isn't the biggie here. It's
the indentation of continuation lines inside parentheses (e.g. calls).
Most programmers carefully indent the parameters to be aligned with
the first character inside the most recent unclosed left-paren (Emacs
does this automatically for me). But this habit almost universally
only works with monospaced fonts. For example (from zipfile.py:

    def __init__(self, fileobj, mode, zipinfo, decrypter=None,
                 close_fileobj=False):
        self._fileobj = fileobj
        ...

The intent is that 'close_fileobj' starts at the same position as 'self'.

This is why I still prefer monospace fonts.

--Guido

> --
> Alan G
> Author of the Learn to Program web site
> http://www.alan-g.me.uk/
>
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev



-- 
--Guido van Rossum (python.org/~guido)