[Python-ideas] Transportable indent level markers. /// ; ; ; \\\

[MRAB]

On 13/12/2011 00:01, Ron Adam wrote:
> On Mon, 2011-12-12 at 23:15 +0000, MRAB wrote:
>> On 12/12/2011 22:07, Ron Adam wrote:
>>>
>>> While typing this reply to the "Alternate Suite Delineation Syntax For
>>> Python?" thread.  I realized that having things  all on a single line
>>> isn't important or needed!!!  Yes, it's not needed for templates, or
>>> code generation.  So this is an alternate to the alternate.
>>>
>>> What is needed is a uniform way to represent indenting that is easy to
>>> transport to (ie paste into) code with different indent levels.
>>>
>>>
>>> INDENT LEVEL MARKERS:
>>> ----------------------
>>> Offer a new way to spell<indent+1>,<indent+0>, and<indent-1>.
>>>
>>> To make that work, we need to use unique character sequences that aren't
>>> already used.  After some thought, I came up with these indent-markers.
>>>
>>>       ///   # indent level +1
>>>       ;;;   # indent level +0
>>>       \\\   # indent level -1
>>>
>>> These are unique enough to be easy to see, and the tripled versions of
>>> them aren't really that bad as we already have triple quotes, and they
>>> would be less than the white space they are replacing in most cases.
>>>
>>> So this isn't brackets, or braces. It would be just an alternate
>>> spelling in already valid python. It should not effect the parser,
>>> grammar, or interpreter in any way if it is done in pythons
>>> tokenizer.  :-)
>>>
>> [snip]
>> -1
>>
>> If the problem is with leading whitespace being stripped, then what
>> about the non-breaking space ("\xA0")? We all use Unicode now, don't
>> we? :-)
>
> Think bigger!  ie... easy automated program content and construction.
>
> You have this string...
>
> foo_bit.py
> """
> def foo(*args):
>      result =<do something with args>
>      return result
> x = foo(a, b, c)
> """
>
> And you want it to be inserted in this string automatically with the
> least amount of processing.  (with another program you have.)
>
> bar_bit.py
> """
>      ...
>      def bar(a, b, c):
>          ...
> <insert foo_bit.py here>
>          ...
>          return x
>      ...
> """
> (where ... means more lines of python code.)
>
>
> Now if you do a quick simple substitution you get.
>
> """
>      ...
>      def bar(a, b, c):
>          ...
> def foo(*args):
>      result =<do something with args>
>      return result
> x = foo(a, b, c)
>          ...
>          return x
>      ...
> """
>
OK, let's suppose that bar_bit.py is a template file with an insertion
point:

bar_bit.py
"""
      ...
      def bar(a, b, c):
          ...
          <insert here>
          ...
          return x
      ...
"""

I would expect the inserted code to be indented by however much the
"<insert here>" is indented:

"""
      ...
      def bar(a, b, c):
          ...
          def foo(*args):
               result =<do something with args>
               return result
          x = foo(a, b, c)
          ...
          return x
      ...
"""

> Which won't work and is why template programs need to
> do a lot of pre and post processing to get things right.
>
> If foo_bit.py was like this...
>
> """
> ;;; def foo(*args):
> ;;;    result =<do something with args>
> ;;;    return result
> ;;; x = foo(a, b, c)
> """
>
> Then you would get...
>
> """
>      ...
>      def bar(a, b, c):
>          ...
> ;;; def foo(*args):
> ;;;    result =<do something with args>
> ;;;    return result
> ;;; x = foo(a, b, c)
>          ...
>          return x
>      ...
> """
>
> And the tokenizer in python could read that directly as ...
>
>      ...
>      def bar(a, b, c):
>          ...
>          def foo(*args):
>              result =<do something with args>
>              return result
>          x = foo(a, b, c)
>          ...
>          return x
>      ...
>
> Which would make doing things like this really easy instead of really
> tricky.
>
> The indent level of bar.py won't matter because the indent marker ';;;'
> says to use the current level of indent before this line.
>
> Does that make more sense now?
>
I still think it looks messy and that it's the responsibility of the
templater to fix the indentation.