From: Tavis R. <ta...@ca...> - 2001-12-07 03:05:38
|
It seems we're not the only ones having this debate: http://groups.google.com/groups?hl=en&threadm=pan.2001.12.06.13.23.30.752127.1733%40uchicago.edu&prev=/groups%3Fhl%3Den%26group%3Dcomp.lang.python ;) |
From: Ian B. <ian...@co...> - 2001-12-07 04:24:47
|
Google has changed their interface -- that new tree view is quite=0D nice. Especially the little orange bar to indicate where in the=0D thread you are. I haven't seen that before. |
From: Chuck E. <Chu...@ya...> - 2001-12-07 21:46:27
|
On Thursday 06 December 2001 08:16 pm, Tavis Rudd wrote: > It seems we're not the only ones having this debate: > > http://groups.google.com/groups?hl=en&threadm=pan.2001.12.06.13.23.30 >.752127.1733%40uchicago.edu&prev=/groups%3Fhl%3Den%26group%3Dcomp.lang >.python > > ;) Okay, on more positive note without getting into flamewars again, I have been thinking the following, but need help from emacs users in the answers: - Recently, I saw a text file where someone included special comments that apparently emacs picked up automatically and used for configuration. Is that possible? If so, are there settings to get emacs to behave well with Webware source code? eg, indentation = either tabs OR (and this is what I like about other editors) whatever characters were used on the previous line. and maybe tabwidth=4 although that's entirely personal preference. If so, could those settings be put in an .emacsrc in the source directories? eg, will emacs also pick up settings from FILEDIR/.emacsrc? -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-07 23:55:34
Attachments:
Tabcleaner.py
|
Chuck, like Ian said it works fine if you set the tab width to 8 instead of 4. This is the default, in fact. The problem then, however, is that the line wrapping is totally screwed up. This wouldn't be such a problem (and we wouldn't complain so much) if several other conventions were followed in the Webware codebase: * Try to wrap lines at 80 columns (1 tab = 8 columns) * Absolutely wrap lines before 90 (particularly docstrings). The current codebase is absolutely full of run on lines. * Always """ instead of ''' for docstrings. * Include a blank line before and after every docstring. This makes it much easier to re-wrap the docstrings when the content changes. * If a method of function has lots of args list them one or two per-line, instead of having a huge run-on line. If these conventions were followed religously, and there was an automatic test to make sure a file was all tabs or all spaces upon CVS checkin, I'd shut up about SpacesNotTabs and happily work with whatever the original author of the module used. In fact, we really should be dealing with the line-wrapping rather than about tabs ;) On the other hand there is something to be said for consistency. We could make a transition to spaces in less than a minute: python Tabcleaner.py -S -i4 . That would be much easier than adding editor specific comments to every single file and remembering to do it on new files as well. Tavis On Friday 07 December 2001 13:38, Chuck Esterbrook wrote: > Okay, on more positive note without getting into flamewars again, I > have been thinking the following, but need help from emacs users in > the answers: > > - Recently, I saw a text file where someone included special > comments that apparently emacs picked up automatically and used for > configuration. Is that possible? > > If so, are there settings to get emacs to behave well with Webware > source code? eg, indentation = either tabs OR (and this is what I > like about other editors) whatever characters were used on the > previous line. and maybe tabwidth=4 although that's entirely > personal preference. > > If so, could those settings be put in an .emacsrc in the source > directories? eg, will emacs also pick up settings from > FILEDIR/.emacsrc? |
From: Darryl V. <da...@cs...> - 2001-12-08 00:07:44
|
-----Original Message----- what editor do you guys use when programming python? Linux preferred... Thanks -darryl |
From: Chuck E. <Chu...@ya...> - 2001-12-08 00:58:27
|
On Friday 07 December 2001 04:08 pm, Darryl VanDorp wrote: > -----Original Message----- > what editor do you guys use when programming python? > Linux preferred... http://webware.colorstudy.net/twiki/bin/view/Webware/TextEditors |
From: Ian B. <ia...@co...> - 2001-12-07 22:26:51
|
On Fri, Dec 07, 2001 at 01:38:52PM -0800, Chuck Esterbrook wrote: > Okay, on more positive note without getting into flamewars again, I > have been thinking the following, but need help from emacs users in the > answers: > > - Recently, I saw a text file where someone included special comments > that apparently emacs picked up automatically and used for > configuration. Is that possible? Yes, there are some ways you can define Emacs settings on a per-file basis. I can't remember the syntax, but you put it in a specially-formatted comment in the file. It would have to be in all files, I don't believe Emacs picks up configuration files otherwise. I've also found that as long as I leave the tabwidth at 8, the auto-tab-detection works correctly -- i.e., Emacs inserts tabs in files that use tabs, and spaces in files that use spaces. I don't know why it doesn't work with a tabwidth of 4. This isn't pretty, lines wrap poorly, but at least I don't break code that way. The '''-quoted doc strings are still also a problem for Emacs. Ian |
From: Tavis R. <ta...@ca...> - 2001-12-07 22:30:06
|
On Friday 07 December 2001 14:30, Ian Bicking wrote: > The '''-quoted doc strings are still also a problem for Emacs. Those and the unwrapped lines (usually docstrings) actually bother me much more than the tabs. |
From: Chuck E. <Chu...@ya...> - 2001-12-08 00:58:12
|
On Friday 07 December 2001 02:30 pm, Ian Bicking wrote: > I've also found that as long as I leave the tabwidth at 8, the > auto-tab-detection works correctly -- i.e., Emacs inserts tabs in > files that use tabs, and spaces in files that use spaces. I don't > know why it doesn't work with a tabwidth of 4. > [snip] > > The '''-quoted doc strings are still also a problem for Emacs. Psuedo-radical thoughts: - Since emacs' auto-tab-detection almost works except when tabwidth is 4, would it be possible to fix emacs? - Since emacs already handles multi-line strings with double quotes, would it be possible to fix it to handle multi-line strings with single quotes? Presumably, open source can be fixed. I know it's not easy, but there are a lot of Pythoneers using emacs, so getting emacs to deal with the full range of the Python language seems worthwhile. Given that emacs is _almost_ working, I'd like to imagine that getting it to work wouldn't be insane. Who's that guy with the cold hands clutching emacs? ;-) Wouldn't he like to be able to brag that emacs can handle any Python you throw at it? BTW here's the example I found just for reference. <!-- # This is for Emacs' benefit: # Local Variables: *** # mode: fundamental *** # tab-width: 3 *** # End: *** --> No, I don't want to add stuff like that to every file. I was hoping DIR/.emacs was read, but I confirmed with the emacs docs that it's not. On Friday 07 December 2001 05:06 pm, Tavis Rudd wrote: > * Try to wrap lines at 80 columns (1 tab = 8 columns) I'm amenable to that. I was just procrastinating on a proclamation because I'm curious how pydoc deals with different looking doc strings. > * Absolutely wrap lines before 90 (particularly docstrings). The > current codebase is absolutely full of run on lines. Hmm, I'm inclined to let code lines run a little longer, say 130. We presumably all have wide windows when doing serious development and most editors allow wrapping or non-wrapping as you like. > * Always """ instead of ''' for docstrings. See my earlier comment. > * Include a blank line before and after every docstring. This makes > it much easier to re-wrap the docstrings when the content changes. Do you mean: def foo(self): ''' Returns the foo of the bar. ''' return math.sqrt(bar()) ? I have a big distaste for this. My pref is: def foo(self): ''' Returns the foo of the bar. ''' return math.sqrt(bar()) > * If a method of function has lots of args list them one or two > per-line, instead of having a huge run-on line. Does "lots of args" mean past a certain column number or what? > If these conventions were followed religously, and there was an > automatic test to make sure a file was all tabs or all spaces upon > CVS checkin, I'd shut up about SpacesNotTabs and happily work with > whatever the original author of the module used. In fact, we really > should be dealing with the line-wrapping rather than about tabs ;) We'll get there. Let's keep the conversation going. > That would be much easier than adding editor specific comments to > every single file and remembering to do it on new files as well. But should we cater to editors that can't handle the full range of Python? Particularly when they're open source? (You know where I stand on that one.) -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-08 01:28:46
|
On Friday 07 December 2001 16:58, Chuck Esterbrook wrote: > > The '''-quoted doc strings are still also a problem for Emacs. > - Since emacs already handles multi-line strings with double > quotes, would it be possible to fix it to handle multi-line strings > with single quotes? As far as I know this one is related to some deep internals in Emacs or elisp. I've been told that it's not a simple fix. > Psuedo-radical thoughts: > > - Since emacs' auto-tab-detection almost works except when tabwidth > is 4, would it be possible to fix emacs? Fixing Emacs itself it a scary proposition for someone not proficient in Lisp, C or diplomacy. Since all programming editors work with spaces (and I don't mean manually hitting space four times), wouldn't it be much easier to just run that Tabcleaner command and be done with it? > Presumably, open source can be fixed. I know it's not easy, but > there are a lot of Pythoneers using emacs, so getting emacs to deal > with the full range of the Python language seems worthwhile. Given > that emacs is _almost_ working, I'd like to imagine that getting it > to work wouldn't be insane. > > Who's that guy with the cold hands clutching emacs? ;-) > Wouldn't he like to be able to brag that emacs can handle any > Python you throw at it? > On Friday 07 December 2001 05:06 pm, Tavis Rudd wrote: > > * Try to wrap lines at 80 columns (1 tab = 8 columns) > > I'm amenable to that. I was just procrastinating on a proclamation > because I'm curious how pydoc deals with different looking doc > strings. > > > * Absolutely wrap lines before 90 (particularly docstrings). The > > current codebase is absolutely full of run on lines. > > Hmm, I'm inclined to let code lines run a little longer, say 130. > We presumably all have wide windows when doing serious development > and most editors allow wrapping or non-wrapping as you like. Yes, but narrow columns are easier to read and 80 columns is easier to deal with on terminals and in source code listings (i.e. pydoc) > > * Always """ instead of ''' for docstrings. > > See my earlier comment. See mine. This is in the Python style guidelines. > > * Include a blank line before and after every docstring. This > > makes it much easier to re-wrap the docstrings when the content > > changes. > > Do you mean: > > def foo(self): > > ''' > Returns the foo of the bar. > ''' > > return math.sqrt(bar()) No: def foo(self): """Returns the foo of the bar""" return math.sqrt(bar()) It's the same number of lines as what you've been using and it makes autowrapping of the docstring easier (i.e. you don't muck up the surrounding code). It's also in Guido's style guidelines. > > * If a method of function has lots of args list them one or two > > per-line, instead of having a huge run-on line. > > Does "lots of args" mean past a certain column number or what? column 80 > > If these conventions were followed religously, and there was an > > automatic test to make sure a file was all tabs or all spaces > > upon CVS checkin, I'd shut up about SpacesNotTabs and happily > > work with whatever the original author of the module used. In > > fact, we really should be dealing with the line-wrapping rather > > than about tabs ;) > > We'll get there. Let's keep the conversation going. > > That would be much easier than adding editor specific comments to > > every single file and remembering to do it on new files as well. > > But should we cater to editors that can't handle the full range of > Python? Particularly when they're open source? (You know where I > stand on that one.) yada yada yada ... I know the theory but by doing these things we're not harming the code in anyway for other editors. To turn that argument around, how would you like it if someone said: - Webware shouldn't be portable to systems without the fork() system call, because all systems that don't have it suck and should be fixed. - WebKit shouldn't worry about malformed cookies from open source browser X because we shouldn't cater to any one browser. - WebKit authentication shouldn't cater to the whims of those who turn cookies and Javascript off. Tavis |
From: Geoffrey T. <gta...@me...> - 2001-12-08 14:23:49
|
On Friday December 07, 2001 09:38 pm, Tavis Rudd wrote: > On Friday 07 December 2001 16:58, Chuck Esterbrook wrote: > > On Friday 07 December 2001 05:06 pm, Tavis Rudd wrote: > > > * Try to wrap lines at 80 columns (1 tab = 8 columns) > > > > I'm amenable to that. I was just procrastinating on a proclamation > > because I'm curious how pydoc deals with different looking doc > > strings. > > > > > * Absolutely wrap lines before 90 (particularly docstrings). The > > > current codebase is absolutely full of run on lines. > > > > Hmm, I'm inclined to let code lines run a little longer, say 130. > > We presumably all have wide windows when doing serious development > > and most editors allow wrapping or non-wrapping as you like. > > Yes, but narrow columns are easier to read and 80 columns is easier > to deal with on terminals and in source code listings (i.e. pydoc) I agree with Chuck on this one. 80 columns is only half the width of my screen. I'd prefer to make use of my whole screen, thank you very much :-) The problem with limiting yourself to 80-column lines is that then you find yourself shortening variable names just so you can make things fit within 80 columns. You have a lot more multi-line continuations, which reduces readability. And I never code on an 80-column terminal, and I can't remember the last time I actually printed out some code to read, so those arguments don't sway me at all. - Geoff |
From: Tavis R. <ta...@ca...> - 2001-12-08 19:06:03
|
On Saturday 08 December 2001 06:26, Geoffrey Talvola wrote: > On Friday December 07, 2001 09:38 pm, Tavis Rudd wrote: > > Yes, but narrow columns are easier to read and 80 columns is > > easier to deal with on terminals and in source code listings > > (i.e. pydoc) > > I agree with Chuck on this one. 80 columns is only half the width > of my screen. I'd prefer to make use of my whole screen, thank you > very much :-) That's the whole point, many tools are designed on this assumption and have dockbars down the left side or use multiple vertical frames. 80 might be a bit zealous, but code does get ugly in many tools when wider than 80. > The problem with limiting yourself to 80-column lines is that then > you find yourself shortening variable names just so you can make > things fit within 80 columns. You have a lot more multi-line > continuations, which reduces readability. I disagree about readability. My code follows the 80/90 column rule and I never find my self shortening varnames to make things fit. Line continuations with slashes aren't all that pretty, but there's always another way of wrapping ---> parenthesized statements This is bloody hard to read: assert not self._factoryByExt.has_key(ext), 'Extension (%s) for factory (%s) was already used by factory (%s)' % (ext, self._factoryByExt[ext].name(), factory.name()) while this isn't: assert not self._factoryByExt.has_key(ext), ( "Extension (%s) for factory (%s) was " "already used by factory (%s)" % (ext, self._factoryByExt[ext].name(), factory.name()) ) It's longer, but at least you can see what's going on in single glance. This is more readable dispatcher = _SSLDispatcher(self, service, serviceName, address, sslContext=sslContext, manageService=manageService, settings=settings) than: dispatcher = _SSLDispatcher(self, service, serviceName, address, sslContext=sslContext, manageService=manageService, settings=settings) > And I never code on an > 80-column terminal, and I can't remember the last time I actually > printed out some code to read, so those arguments don't sway me at > all. What about reading the output of grep in a shell window where each line is prefaced with the name of the file and the line num. I do this very frequently when trying to grok code and anything longer than 90 makes it harder to find what I'm looking for. And how about viewcvs.cgi when you're using the diff view? ... or any other multi-column diff tool. And how about pasting code snippets into an email? When I mentioned source code listings I was referring to listings that are inluded as part of Developers' Guides and even Users' guides. Code wider than 80 looks hideous in a pdf. ;) whew, I didn't realize I cared that much about it ... Tavis |
From: Ian B. <ia...@co...> - 2001-12-08 18:00:45
|
On Fri, 2001-12-07 at 18:58, Chuck Esterbrook wrote: > On Friday 07 December 2001 02:30 pm, Ian Bicking wrote: > > I've also found that as long as I leave the tabwidth at 8, the > > auto-tab-detection works correctly -- i.e., Emacs inserts tabs in > > files that use tabs, and spaces in files that use spaces. I don't > > know why it doesn't work with a tabwidth of 4. > > > [snip] > > > > The '''-quoted doc strings are still also a problem for Emacs. > > Psuedo-radical thoughts: > > - Since emacs' auto-tab-detection almost works except when tabwidth is > 4, would it be possible to fix emacs? Probably. Since the autodetection works fine, and all of my own code uses 4 spaces, I'm not as concerned. Not enough to go browsing through the elisp looking for a bug -- and probably one that's subtle, since it interacts with something deep in Emacs (the width that tabs are displayed at). > - Since emacs already handles multi-line strings with double quotes, > would it be possible to fix it to handle multi-line strings with single > quotes? Double quotes work the same as single: the difference is that single quotes are often not matched inside a doc string, e.g., '''don't use this'''. Changing ''' to """ should be easy, and it pretty much fixes this. > > * Absolutely wrap lines before 90 (particularly docstrings). The > > current codebase is absolutely full of run on lines. > > Hmm, I'm inclined to let code lines run a little longer, say 130. We > presumably all have wide windows when doing serious development and > most editors allow wrapping or non-wrapping as you like. I use 80-columns. It's leaves me just a tiny bit shy of being able to have two windows side-by-side. 80 is conventional. Most lines easily fit in under 80, so if you use 130 you're just going to have a lot of empty space on your screen. In an endline-sensitive language, wrapping *can't* be as pretty as manually putting in newlines -- if it was, you wouldn't be able to tell that there were semantic differences in some instances. In the case of Emacs, wrapped lines get cut off at exactly 80 (or whatever width your window is), without any attention to word boundaries. I imagine lots of editors are the same -- and if they *aren't* like that, I'd be afraid of damaging my code by not realizing where the newlines were. > > * Include a blank line before and after every docstring. This makes > > it much easier to re-wrap the docstrings when the content changes. Even in my own code, I usually insert the newline, wrap, and remove it again, despite the inconvenience. I don't like having excessive vertical whitespace -- M-Up and M-Down work better if you have just the right amount of whitespace. > > * If a method of function has lots of args list them one or two > > per-line, instead of having a huge run-on line. > > Does "lots of args" mean past a certain column number or what? I think there's a justification for long lines when you are doing lots of composition of functions or something -- at least indenting the way Emacs does, it is often no advantage to split lines. But when you have lots of arguments it's really easy to split lines, so why not? e.g., this will often go over 80 columns and is hard to fix: self.myInstanceVar = self.namespace().getVar(self.findVarName(self.request().field('fieldName', None)))) Some might say temporary variables are called for, or it's bad programming style... but I tend to do this sort of thing quite often, and there's no decent way of splitting that line to shorten it. Ian |
From: Clark C . E. <cc...@cl...> - 2001-12-08 20:15:03
|
I have $.02 to contribute: 1. According to the python spec, a TAB moves the column to the nearest multiple of 8. Therefore, "\n \t" and "\n\t" and "\n \t" and "\n " are all considered equivalent under the python parse rules. So. If you set your tab-stop every 4 columns, it can cause you no end of grief. Some of the recent webware code i've used relies on above rules..., there are numerous "\n \t" lines. If you do a tab expansion on those lines other than by the standard unix rules employed by the Python parser, your code becomes buggy. 2. I almost exclusively use 80 column terminals. I use big fonts so that I can easily see the text (my eyes strain after a few min of coding) As such, I try to word-wrap by 76 characters since this is the RFC822 wrap column (makes e-mailing code in-line nice), and always by 80. I do believe that I have not made significant improvements in the webware code beacuse I find it painful to read and edit. Using 8 spaces is a huge amount of space for me, damn near 1/10th of my screen. And typical webware code is word-wrapped well past 100 columns. This looks like gibberish on my editor that uses "C" style word wrapping. I strongly pray that the code be re-formatted to use four spaces and word-wrapped sooner per the Python style guides. Best, Clark |
From: Chuck E. <Chu...@ya...> - 2001-12-09 16:13:19
|
On Saturday 08 December 2001 10:03 am, Ian Bicking wrote: > tell that there were semantic differences in some instances. In the > case of Emacs, wrapped lines get cut off at exactly 80 (or whatever > width your window is), without any attention to word boundaries. I > imagine lots of editors are the same -- and if they *aren't* like > that, I'd be afraid of damaging my code by not realizing where the > newlines were. Emacs wraps lines by character (instead of word) and AFAIK offers no option to not wrap. However, you can easily make the window bigger and most editors (UltraEdit, kate, wing, etc.) either allow a non-wrap mode or simply don't wrap in the first place. On Saturday 08 December 2001 12:16 pm, Tavis Rudd wrote: > That's the whole point, many tools are designed on this assumption > and have dockbars down the left side or use multiple vertical frames. > 80 might be a bit zealous, but code does get ugly in many tools when > wider than 80. I just tested this theory with emacs, kate and wingide. The code never gets ugly in kate and wingide, because they don't wrap. The code does get ugly in emacs because of wrapping. Not to mention the up and down arrow keys in emacs are paragraph-oriented instead of visible-line-oriented. (bleck) In general, I'm not seeing that tools are designed around the assumption that text files stop at 80 columns. In all three products, sizing the window to be wide enough for 130 characters actually felt excessive to me, but 110-120 felt fine. I have 19" monitor with 1152x864. The thing of it is, using editors that allow me to not wrap, I don't really care how long some code lines go on. Should we even dictate that code lines _must_ be wrapped at a column width? Is this another emacs-only issue? Feel free to speak up. But if we decide "yes", it will be something bigger and more modern than 80. On Saturday 08 December 2001 12:39 pm, Clark C . Evans wrote: > You forgot one... those of us with poor eyes > that are forced to use 80 columns and big monitors. That works fine in wingide as well. In fact I made the font size so large I could only see 70 columns. I could still see what was going on in Application.py and get around just fine. -Chuck |
From: Darryl V. <da...@cs...> - 2001-12-09 16:16:25
|
There was a previous message about the link to Webware v.5 on the webware site. It's the right hand Side where it gives a little description of webware Then points to v.5 download. Regards, Darryl |
From: Chuck E. <Chu...@ya...> - 2001-12-09 20:27:21
|
On Sunday 09 December 2001 08:17 am, Darryl VanDorp wrote: > There was a previous message about the link to > Webware v.5 on the webware site. It's the right hand > Side where it gives a little description of webware > Then points to v.5 download. > > Regards, > Darryl Thanks! I always flip bits (like 'left' and 'right'). Fixed. -Chucks |
From: Ian B. <ia...@co...> - 2001-12-09 18:33:34
|
On Sun, 2001-12-09 at 10:13, Chuck Esterbrook wrote: > In general, I'm not seeing that tools are designed around the > assumption that text files stop at 80 columns. > > In all three products, sizing the window to be wide enough for 130 > characters actually felt excessive to me, but 110-120 felt fine. I have > 19" monitor with 1152x864. > > The thing of it is, using editors that allow me to not wrap, I don't > really care how long some code lines go on. Should we even dictate that > code lines _must_ be wrapped at a column width? Is this another > emacs-only issue? > > Feel free to speak up. But if we decide "yes", it will be something > bigger and more modern than 80. I don't think lines shouldn't be *allowed* to go over 80 columns -- it happens sometimes, and sometimes it isn't easier to read the code just because you've arbitrarily put in some newlines. Consistency is the hobgoblin of small minds and all that. However, I think 80 columns is conventional, and generally appropriate. I don't *want* to make my editor wider than 80 columns, because that is a waste of space. I have better things to do with the rest of my screen than sport a bit chunk of whitespace for that minority of lines that go long. Choosing something other than 80 columns seems arbitrary. 80 is the convention for most code and email. As a result, I will *not* set up my environment for Webware code to the detriment of all the other code I work with. I will not make my font small, or my windows wide. I will not change whatever setting it is in Emacs that controls how wide the wrapping command works at. And why should I? And not just me, but everyone else? There's *nothing wrong* with standard Python conventions! Why can't we just use those? I am going to keep writing my code pretty much to Python coding standards, because I think that is the Right Thing -- not necessarily because those standards are the best, most logical, or most aesthetic standards. I'm going to do that because that makes my code most accessible to the general Python community, and means my code will fit in with most code from other sources. I'm going to set up my editor and general environment to do that. This shouldn't be a controversial choice. A lot of other people have chosen that too... and when they do, Webware code looks ugly to them. Instead of asking us to change our environments, shouldn't Webware just go along to get along? It seems like hubris to do otherwise. Ian |
From: Tavis R. <ta...@ca...> - 2001-12-09 18:46:54
|
On Sunday 09 December 2001 08:13, Chuck Esterbrook wrote: > On Saturday 08 December 2001 12:16 pm, Tavis Rudd wrote: > > That's the whole point, many tools are designed on this > > assumption and have dockbars down the left side or use multiple > > vertical frames. 80 might be a bit zealous, but code does get > > ugly in many tools when wider than 80. > > I just tested this theory with emacs, kate and wingide. The code > never gets ugly in kate and wingide, because they don't wrap. The > code does get ugly in emacs because of wrapping. Not to mention the > up and down arrow keys in emacs are paragraph-oriented instead of > visible-line-oriented. (bleck) I wasn't thinking about Emacs as one of these tools; rather: * grep on the command line * viewcvs diff screens on the web * any other visual diff tool * syncmail, the cvs checkin notifier which sends diffs as emails. Emails wrap at 76 columns in most clients. * KDevelop > In general, I'm not seeing that tools are designed around the > assumption that text files stop at 80 columns. stop thinking of text files ... rather 'source files' which are higly sensitive to newlines. > In all three products, sizing the window to be wide enough for 130 > characters actually felt excessive to me, but 110-120 felt fine. I > have 19" monitor with 1152x864. 80 is THE standard. Like Ian said anything else is being arbitrary without good reason. > The thing of it is, using editors that allow me to not wrap, I > don't really care how long some code lines go on. Should we even > dictate that code lines _must_ be wrapped at a column width? Is > this another emacs-only issue? This is nothing to do with emacs. 80 columns is a well established standard, for bloody good reasons. Why deviate? As far as I know, Webware is the only large Open Source Python project that: - uses Tabs - has run-on lines - consistently uses ''' instead of """ for docstrings. Why don't we just follow the well established style guidelines for Python and end this debate once and for all? ----From the Python Style Guidelines [Guido] Maximum Line Length There are still many devices around that are limited to 80 character lines. The default wrapping on such devices looks ugly. Therefore, please limit all lines to a maximum of 79 characters (Emacs wraps lines that are exactly 80 characters long.) The preferred way of wrapping long lines is by using Python's implied line continuation inside parentheses, brackets and braces. If necessary, you can add an extra pair of parentheses around an expression, but sometimes using a backslash looks better. Make sure to indent the continued line appropriately. Emacs Python-mode does this right. Some examples: |
From: Chuck E. <Chu...@ya...> - 2001-12-09 19:00:13
|
On Sunday 09 December 2001 10:36 am, Ian Bicking wrote: > And why should I? And not just me, but everyone else? There's > *nothing wrong* with standard Python conventions! Why can't we just > use those? > > I am going to keep writing my code pretty much to Python coding > standards, because I think that is the Right Thing -- not necessarily > because those standards are the best, most logical, or most aesthetic > standards. I'm going to do that because that makes my code most > accessible to the general Python community, and means my code will > fit in with most code from other sources. I'm going to set up my > editor and general environment to do that. > > This shouldn't be a controversial choice. A lot of other people have > chosen that too... and when they do, Webware code looks ugly to them. > Instead of asking us to change our environments, shouldn't Webware > just go along to get along? It seems like hubris to do otherwise. > > Ian You say "not just me, but everyone else" to which I'm very surprised. Almost all of my colleagues: - use windows that are wider than 80 columns - have plenty of screenspace - do lots of editing every day - have editors that can wrap or not - have editors that use "previous line indentation" - infrequently paste existing code in e-mail messages - do not edit in terminals for more than a 5 minute fix - do not print source code Scaling everything down to the most extreme people (the guy using an 80 column terminal who prints and e-mails all of his code) hurts for those who aren't (those with the space, the friendly editor and the inclination to use them). Whereever you draw the line, someone is gaining and someone is losing. That's where the constroversy comes from. Also, instead of changing how I code in Python, shouldn't editors like emacs do the right thing? Python is the first language I've used where I was expected to cater to a single editor (and one with source) instead of expecting the editor to handle the language's text files. That seems like hubris. You say "no, I won't do this and I won't do that for your source", but then expect me to say "yes, I'll do this and I'll do that for one problematic editor". That seems unbalanced. And for the most part, Webware is Pythonic, but with any project there is balance to be striked between conforming to the herd and doing what's best. There is no hubris in that general philosophy at least. -Chuck |
From: Ian B. <ia...@co...> - 2001-12-09 19:57:58
|
On Sun, 2001-12-09 at 13:00, Chuck Esterbrook wrote: > Scaling everything down to the most extreme people (the guy using an 80 > column terminal who prints and e-mails all of his code) hurts for those > who aren't (those with the space, the friendly editor and the > inclination to use them). Whereever you draw the line, someone is > gaining and someone is losing. That's where the constroversy comes from. > > Also, instead of changing how I code in Python, shouldn't editors like > emacs do the right thing? Python is the first language I've used where > I was expected to cater to a single editor (and one with source) > instead of expecting the editor to handle the language's text files. > That seems like hubris. > > You say "no, I won't do this and I won't do that for your source", but > then expect me to say "yes, I'll do this and I'll do that for one > problematic editor". That seems unbalanced. I am saying you should do these things because they are compatible with the dominant style in the larger Python community. I set up my environment to fit with those conventions -- perhaps it isn't a flexible enough environment for you, but as long as code stays more-or-less within those basic conventions my environment works quite well for me. If all Python code used tabs, then I could set up Emacs to use tabs just fine too. When I have to go back and forth it becomes problematic. By going against the dominant style, you force me to choose how I will set up my environment. When I spoke of hubris, I was refering to this: making someone choose between Webware and almost all the other Python code out there. When I was first using Webware, I actually did try to stick to guidelines. I changed Emacs so it would do tabs by default. I even converted a fair bit of my own code. But I eventually went back, because then it was annoying when I was editing code from other sources. The result is it's fine for me to edit other code, but annoying for me to deal with Webware code. It also means that packages designed specifically for use with Webware -- Cheetah and FunFormKit -- are not going to be written to Webware style guidelines. There are reasons I like 80 columns and spaces for indentation. But really, that's not the important issue. If a concensus had grown to do these things otherwise, I would not complain and I would adapt the configuration of my tools. For big issues -- like whether to have all attribute access be through functions -- the arguments for it are significant. I happen to agree with it -- but even if I didn't, I'd be able to understand that any incongruity with other code was for a real purpose. It's because these small style issues are so small that they seem more annoying. Really, no justification for or against them seems to stack up against convention and compatibility. Ian |
From: Chuck E. <Chu...@ya...> - 2001-12-09 19:28:20
|
On Sunday 09 December 2001 11:57 am, Tavis Rudd wrote: > On Sunday 09 December 2001 08:13, Chuck Esterbrook wrote: > > On Saturday 08 December 2001 12:16 pm, Tavis Rudd wrote: > > > That's the whole point, many tools are designed on this > > > assumption and have dockbars down the left side or use multiple > > > vertical frames. 80 might be a bit zealous, but code does get > > > ugly in many tools when wider than 80. > > > > I just tested this theory with emacs, kate and wingide. The code > > never gets ugly in kate and wingide, because they don't wrap. The > > code does get ugly in emacs because of wrapping. Not to mention the > > up and down arrow keys in emacs are paragraph-oriented instead of > > visible-line-oriented. (bleck) > > I wasn't thinking about Emacs as one of these tools; rather: > > * grep on the command line commandLine.width does not equal 80. I don't know what makes you think it is... And with the filename embedded on a grep *.py you're back to wrapping on an 80 column terminal anyway. > * viewcvs diff screens on the web Doesn't this scale as you shrink or enlarge your browser? I thought it was just "normal" HTML that word wrapped? > * any other visual diff tool They're all set to 80? I don't believe that. As one example, NeXTstep's didn't care how wide your file was and that was a damn good thing since .csv and logs are often wider. > * syncmail, the cvs checkin notifier which sends diffs as emails. > Emails wrap at 76 columns in most clients. Now you just pointed out that 80 is NOT the standard.... BTW Most if not all of the e-mail clients I have used wrap incoming messages to the window/terminal width, not to a pretermined value like "76". I think you're mostly thinking of outgoing messages. And in that case I think it's more like 72 not 76. > * KDevelop Don't know much about it; haven't tested it like the others. Does anyone use it for Python? > > In general, I'm not seeing that tools are designed around the > > assumption that text files stop at 80 columns. > > stop thinking of text files ... rather 'source files' which are > higly sensitive to newlines. Which are not hurt by command line tools like grep, cvs diff, But your width=80 solution leaves me wrapping lines much more often than I should have to bother with, and lots of unused real estate. > > In all three products, sizing the window to be wide enough for 130 > > characters actually felt excessive to me, but 110-120 felt fine. I > > have 19" monitor with 1152x864. > > 80 is THE standard. Like Ian said anything else is being arbitrary > without good reason. No, wait, I thought you said 76.... ;-) The reason is to use the resources you have. Besides, when viewing a file that is wider than your display, there shouldn't be any problems. And there aren't any with a slew of editors, save for emacs, which has other problems as well. > This is nothing to do with emacs. 80 columns is a well established > standard, for bloody good reasons. Why deviate? As far as I know, > Webware is the only large Open Source Python project that: > - uses Tabs > - has run-on lines > - consistently uses ''' instead of """ for docstrings. And emacs is the only editor out of many that can't handle it. How ridiculous. The earlier points about grep, e-mail, etc. don't hold water so we're still left with emacs as the problem. > Why don't we just follow the well established style guidelines for > Python and end this debate once and for all? > > ----From the Python Style Guidelines [Guido] > Maximum Line Length > > There are still many devices around that are limited to 80 > character lines. The default wrapping on such devices looks > ugly. Therefore, please limit all lines to a maximum of 79 characters > (Emacs wraps lines that are exactly 80 characters long.) Because I don't have funky "devices" from the 1980's. I have mutliple editors, horizontal scrolling, resizable windows and terminals, different font sizes and programs that can wrap to visible boundaries. In fact, I'm inundated with these capabilities in almost every program and on every Linux distro. Getting back to constructive solutions: I have always found pros and cons to various editors and use whichever editor suits me best. On Linux I use kate, gedit, pico and wing depending on the situation and project. I could go back to each project and demand they change their style until all projects look good in all editors. I think that would be silly. Would it kill Tavis and Ian to run one of the other editors when using Webware source? You've already rejected lobbying for emacs to be fixed and fixing emacs. You've even rejected what I thought were easy solutions like "make window bigger" and "tweak fonts". And it really is just one program we're talking about. -Chuck |
From: Tavis R. <ta...@ca...> - 2001-12-09 19:54:26
|
---> I'd be happy to settle for 90 columns. On Sunday 09 December 2001 11:28, Chuck Esterbrook wrote: > On Sunday 09 December 2001 11:57 am, Tavis Rudd wrote: > > On Sunday 09 December 2001 08:13, Chuck Esterbrook wrote: > > > On Saturday 08 December 2001 12:16 pm, Tavis Rudd wrote: > > > > That's the whole point, many tools are designed on this > > > > assumption and have dockbars down the left side or use > > > > multiple vertical frames. 80 might be a bit zealous, but code > > > > does get ugly in many tools when wider than 80. > > > > > > I just tested this theory with emacs, kate and wingide. The > > > code never gets ugly in kate and wingide, because they don't > > > wrap. The code does get ugly in emacs because of wrapping. Not > > > to mention the up and down arrow keys in emacs are > > > paragraph-oriented instead of visible-line-oriented. (bleck) > > > > I wasn't thinking about Emacs as one of these tools; rather: > > > > * grep on the command line > > commandLine.width does not equal 80. I don't know what makes you > think it is... True, but grep prefaces each output line with the name of the file and the line num and it doesn't wrap. Therefore I can't see the full output line when running fullscreen 1024X800 if the lines are much longer than 80. > > * viewcvs diff screens on the web > > Doesn't this scale as you shrink or enlarge your browser? I thought > it was just "normal" HTML that word wrapped? Which screws up the indentation. > > * any other visual diff tool > > They're all set to 80? I don't believe that. No, I meant they use multiple pane view and it is easier to read their output when each pane takes up roughly half my screen. > > * syncmail, the cvs checkin notifier which sends diffs as emails. > > Emails wrap at 76 columns in most clients. > > Now you just pointed out that 80 is NOT the standard.... True, but 80, 72, 76 are all pretty close. > > > In general, I'm not seeing that tools are designed around the > > > assumption that text files stop at 80 columns. > > > > stop thinking of text files ... rather 'source files' which are > > higly sensitive to newlines. > > Which are not hurt by command line tools like grep, cvs diff, > But your width=80 solution leaves me wrapping lines much more often > than I should have to bother with, and lots of unused real estate. Why are you so concerned about maximizing horizontal screen real estate? I find it easier to read any kind of text with narrow rather than wide columns. > The reason is to use the resources you have. Besides, when viewing > a file that is wider than your display, there shouldn't be any > problems. And there aren't any with a slew of editors, save for > emacs, which has other problems as well. Emacs doesn't cause me any problem with text less than 110 columns wide, it's the other tools I listed that do cause problems. > The earlier points about grep, e-mail, etc. don't hold water so > we're still left with emacs as the problem. They do hold water and Emacs doesn't cause problems for me in this respect so long as the code is less than 110. Grep, email, etc. do actually cause me problems with wide lines. > Would it kill Tavis and Ian to run one of the other editors when It isn't just me and Ian. Numerous people have commented about this on the Webware lists since I've been subscribed. Clark yesterday for instance. > using Webware source? You've already rejected lobbying for emacs to > be fixed and fixing emacs. You've even rejected what I thought were > easy solutions like "make window bigger" and "tweak fonts". Like I've said above and in the last message, this is not an Emacs problem. It's the other tools that bother me. ---> I'd be happy to settle for 90 columns. |
From: Tavis R. <ta...@ca...> - 2001-12-09 20:00:46
|
Chuck, I'd be happy to go with 90, or even 100, as a standard maximum line width for Webware so we can end this debate and get back to more productive things. Either would be better than the no-wrapping situation in the current codebase. Tavis |
From: Chuck E. <Chu...@ya...> - 2001-12-09 20:21:20
|
On Sunday 09 December 2001 01:11 pm, Tavis Rudd wrote: > Chuck, > I'd be happy to go with 90, or even 100, as a standard maximum line > width for Webware so we can end this debate and get back to more > productive things. Either would be better than the no-wrapping > situation in the current codebase. > Tavis Well at least we kept it on -devel. In the pre-devel days we would have lost half our -discuss members. :-) In any case, I agree, but what I had in mind as the most productive next step was the doc string issues. But this has to be discussed as well because I have some questions: Off the top of my head I remember you mentioning: def foo(self): '''Returns a bar.''' return self My problem is that multi-paragraph strings look strange because the first is indented but the others aren't. def foo(self): '''Returns a bar. Override to customize the baz.''' return self So my pref is: def foo(sefl): ''' Returns a bar. Override to customize the baz. ''' return self I like this because the delimiters, paragraphs and code all line up and look neat (as in 'clean'). Obviously, both use the same # of lines. Questions: - You mentioned it is easier to word wrap the first style. Did you mean for the editor or when you wrap it by hand or what? What does that mean? (Sorry if I missed a clarification; I'm still catching up on messages.) - How well does pydoc work with these styles? - when spewing HTML - when browsing via a terminal - How would the emacs developers react to a request to fully support syntax highlight of Python strings? - If the reaction is negative, we'll switch to """ That's all I can think of. I'll research the last two. -Chuck |