[wingide-users] Indent analysis confused

Michael Foord fuzzyman at voidspace.org.uk
Wed Nov 4 12:06:18 MST 2009


Tom Stambaugh wrote:
> PyDoc and the various other tools that use docstrings (such as the 
> "Source Assistant" of WingIDE) are likely to at least be stressed if 
> not broken, because I would expect the un-indented second line of 
> hashes to potentially violate the syntactically-significant whitespace 
> grammar of Python. I know that comments are supposed to be invisible, 
> but as you can see from the indent manager they really aren't.

Syntactically comments don't affect Python code and neither do they 
affect docstrings. Tools that use introspection or parse trees to find 
docstrings won't be affected.

Michael

>
> I'm thinking of the various tricks for filling tool-tips and such. 
> They expect to find a triple-quoted docstring immediately after the 
> function definition. I'm under the impression that they use indent 
> level to help differentiate class and module docstrings method and 
> function docstrings. I am impressed that Source Assistant was *not* 
> confused by your example, even though the indent manager was.
>
> A simple workaround for the indent manager is to insert whitespace 
> ahead of the second row of hashes, like this:
>
> ##################
> def close():
>   ##################
>   """A really great docstring."""
>   doPythonStuffHere()
>
> I don't know if this is acceptable to your client, but it seems to fix 
> the indent problem. If you love symmetry, you can indent BOTH 
> hashrows, and REALLY emphasize the visual break -- like this:
>
>   ##################
> def close():
>   ##################
>   """A really great docstring."""
>   doPythonStuffHere()
>
> Michael Foord wrote:
>> Tom Stambaugh wrote:
>>> I think what Mark is suggesting is that this "coding standard" was 
>>> rendered obsolete by editors of at least two decades ago
>>
>> It is for breaking up the code visually when looking at it (the human 
>> reader), these are not yet obsolete but maybe in the future.
>>
>>> and breaks most Python tools (such as document generators). 
>> Which document generator would it break?
>>
>>> The indent problem with Wing is just the beginning -- it is the 
>>> first molecule of the tip of a very large iceberg of problems.
>> Can you suggest any others then, I'm having a hard time imagining 
>> what breaks when you put comments in your code...
>>
>> As to showing them what modern IDEs are capable of, this problem with 
>> indentation is sadly only proving the reverse. ;-)
>>
>> All the best,
>>
>> Michael
>>
>>>
>>> Of course, if you have a time-and-materials contract that pays you 
>>> by the hour for correcting the mess this will create, you're very 
>>> much in luck.
>>>
>>> Enjoy...
>>> Tom
>>>
>>> Michael Foord wrote:
>>>> Mark Jones wrote:
>>>>> Sounds like it might be time to show them what fancy new editors 
>>>>> can do.....
>>>> Eh?
>>>>
>>>> Michael
>>>>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>> *From:* Michael Foord <fuzzyman at voidspace.org.uk>
>>>>> *To:* Wing Users <wingide-users at wingware.com>
>>>>> *Sent:* Wed, November 4, 2009 9:26:32 AM
>>>>> *Subject:* [wingide-users] Indent analysis confused
>>>>>
>>>>> Hello all,
>>>>>
>>>>> In my new job the coding standard is to put comment markers above 
>>>>> and below every function / method definition. Thusly:
>>>>>
>>>>> ##################
>>>>> def close():
>>>>> ##################
>>>>>
>>>>> This breaks the indent analysis. On the first blank line after the 
>>>>> method / function definition tab won't indent relative to the 
>>>>> definition.
>>>>>
>>>>> Thanks
>>>>>
>>>>> Michael
>>>>>
>>>>> -- http://www.ironpythoninaction.com/
>>>>>
>>>>> _________________________________________________
>>>>> Wing IDE users list
>>>>> http://wingware.com/lists/wingide
>>>>
>>>>
>>>
>>
>>
>


-- 
http://www.ironpythoninaction.com/



More information about the wingide-users mailing list