A directive for indentation type, stricter indentation parsing.
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
On Tue, Mar 26, 2019 at 7:04 AM fhsxfhsx <fhsxfhsx@126.com> wrote:
Just as to your example, you can try `textwrap.dedent`
Procedural removal is not cool, because it does not know the parent indentation of the statement that contains the text block, thus it can't resolve automatically string indents that were intentionally indented to include extra space. E.g. this, where "s=" line is already inside an indented block: s = """ Hello world""" Say I use 1 tab for 1 indent - what I want here is to remove 1 tab from each string line AND 1 tab that belongs to code formatting (current indent of the "s=" line). And if you try to guess it from the string itself - it is impossible to resolve all cases, because you still need some criteria - for example you could use criteria "minimal indent inside the string is the indent" but this will again fail if you want extra shift on same level inside the string. E.g. this: s = """ Hello world""" Here I do not want to remove all indents but only as in above - only 1 level inside string and 1 from parent line. Do you get it? So in other words if I want my string blocks aligned within containing blocks, it becomes impossible to resolve all un-indenting cases automatically. Mikhail
On Tue, Mar 26, 2019 at 9:49 PM Mikhail V <mikhailwas@gmail.com> wrote:
This is true if you put your closing quotes on the same line as the last line of text, because then there's no information available. If, instead, you put the final triple-quote delimiter on its own line, you then have the indentation preserved, and can remove just that much indentation from each line. So, yes, you CAN unindent automatically. Point of note: PEP 257 recommends this for docstrings. https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation ChrisA
On Tue, Mar 26, 2019 at 2:02 PM Chris Angelico <rosuav@gmail.com> wrote:
Yes you are right. If closing triple quote is on a separate line , I can use the last line contents and extract it from previous lines. I should have remembered that trick and it is cool actually. So technically I can do it. So my point was that it would be cool to have a dedicated statement for this and so it works on parser level plus would look cleaner (no closing quotes), and no need to care about escaping of """ sequence if it appears inside the string, but I think that would be impossible without the parser knowing the indent method in advance.
So my point was that it would be cool to have a dedicated statement for this
Look in the archives of this list — therewasa rejected proposal for dedented strings as s language feature fairly recently. -CHB
--
Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
On Tue, Mar 26, 2019 at 7:04 AM fhsxfhsx <fhsxfhsx@126.com> wrote:
Just as to your example, you can try `textwrap.dedent`
Procedural removal is not cool, because it does not know the parent indentation of the statement that contains the text block, thus it can't resolve automatically string indents that were intentionally indented to include extra space. E.g. this, where "s=" line is already inside an indented block: s = """ Hello world""" Say I use 1 tab for 1 indent - what I want here is to remove 1 tab from each string line AND 1 tab that belongs to code formatting (current indent of the "s=" line). And if you try to guess it from the string itself - it is impossible to resolve all cases, because you still need some criteria - for example you could use criteria "minimal indent inside the string is the indent" but this will again fail if you want extra shift on same level inside the string. E.g. this: s = """ Hello world""" Here I do not want to remove all indents but only as in above - only 1 level inside string and 1 from parent line. Do you get it? So in other words if I want my string blocks aligned within containing blocks, it becomes impossible to resolve all un-indenting cases automatically. Mikhail
On Tue, Mar 26, 2019 at 9:49 PM Mikhail V <mikhailwas@gmail.com> wrote:
This is true if you put your closing quotes on the same line as the last line of text, because then there's no information available. If, instead, you put the final triple-quote delimiter on its own line, you then have the indentation preserved, and can remove just that much indentation from each line. So, yes, you CAN unindent automatically. Point of note: PEP 257 recommends this for docstrings. https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation ChrisA
On Tue, Mar 26, 2019 at 2:02 PM Chris Angelico <rosuav@gmail.com> wrote:
Yes you are right. If closing triple quote is on a separate line , I can use the last line contents and extract it from previous lines. I should have remembered that trick and it is cool actually. So technically I can do it. So my point was that it would be cool to have a dedicated statement for this and so it works on parser level plus would look cleaner (no closing quotes), and no need to care about escaping of """ sequence if it appears inside the string, but I think that would be impossible without the parser knowing the indent method in advance.
So my point was that it would be cool to have a dedicated statement for this
Look in the archives of this list — therewasa rejected proposal for dedented strings as s language feature fairly recently. -CHB
--
Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython
participants (5)
-
Brett Cannon -
Chris Angelico -
Christopher Barker -
fhsxfhsx -
Mikhail V