[Python-ideas] A directive for indentation type, stricter indentation parsing.

Mikhail V mikhailwas at gmail.com
Mon Mar 25 12:32:26 EDT 2019


Not a proposal yet, but some thoughts:
I think it would help in a longer perspective if a user could
include a directive in the header of the source code file that
defines indentation character(s) for this source file. So this
source would be parsed strictly by this char (or sequence).

E.g.:

    # indent "\t"
    ...

Would force the Python parser to use exactly 1 tab for 1 indent level.

    # indent "    "
    ...

Would accordingly force the parser to use exactly 4 spaces for
1 indent level.

Frankly I don't have much proof in hand for that will be a good
addition, but intuitively I suppose it would help with some possible
future features and in general, ease the development of source
processors.

One possible example: if a potential future feature would require
a statement, and moreover require it to be indentation-aware?
Lets take e.g. a multi-line string:

    s = """
        Hello
        world
        """
    print (s)

    >>>

        Hello
        world


Here it is not so intuitive (unless you already know) how the string would
be parsed (given that Python blocks are actually indentation-based).
So if one would want to try introduce a new indent-aware string type and
look into possible parsing disambiguation scenarios - it will be not an
easy task.
E.g. say one proposes a syntax for auto-unindented string block:

    s = !!!
        Hello
        world
    print (s)
    >>>
    Hello
    world

(no leading newline, no leading indent in resulting string, which is a bit more
expected result IMO).

Then it seems one can define the parsing rule unambiguously _only_
if one has a strictly defined character sequence for the indent level
(e.g.  1 tab or 4 spaces, but not both).
Thus it seems such a directive would be a prerequisite for such feature.

And in general, I think it could help to make automatic conversions from one
type of indentation to other easier.



Mikhail


More information about the Python-ideas mailing list