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
_______________________________________________
Webware-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-devel
