"Edward Loper" <edloper at gradient.cis.upenn.edu> wrote in message news:41145C05.1020501 at gradient.cis.upenn.edu... > The new "vertical bar" syntax was proposed recently, and has gotten > almost unanimously positive feedback. In particular, of 17 responses > to the syntax, only one has been negative (see table, below). Add another +1. Verticle rules have been used before to tie several lines together, either as continuation lines or as sub-lines. > |classmethod > |accepts(int, int) > |returns(float) > def foo(arg1, arg2): > ... > > def foo(arg1, arg2): > |classmethod > |accepts(int, int) > |returns(float) > ... > (I prefer the second, but would be happy with either.) Both logically and visually, I prefer the second also. By logically, I mean that it is more meaningful to me to read the decorators after reading that we are defining a function. My main objection is that I like the idea that the header is definition time info and the body is run time code. I consider the doc string in the body to be a wart, not a precedence to by copied, but maybe I should think of the body as starting after the last | or the closing ''' :-). > The one negative comment was that "|" can look similar to "I" or "l", > depending on the font; but it's only an issue for some fonts, and it > should be largely mitigated by syntax-highlighting. Is a space allowed after the prefic character, whatever it might be? With def foo(): | classmethod | accepts(int,int) | returns(float) the visual similarity to I doesn't matter much. Actual typos leading to test such as 'I returns' are guaranteed syntax errors, whereas a name such as Ireturns is not. The space even more clearly matches standard usage of a vertical rule and more clearly denotes the list as hanging off of 'def', so I would be tempted to require the space. Terry J. Reedy
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4