Peter Cock wrote: > On Thu, Sep 1, 2011 at 9:00 PM, Trevor Wennblom <tre...@well.com> wrote: > > ... > > given that python has syntactically significant whitespace, i also > > try to maintain the convention of indentation with four-spaces. > > i've noticed this isn't consistent within the codebase, but does > > seem to be the preferred style such as in `lib/galaxy/datatypes/`. > > > > python comes packaged with the script `reindent.py`: > > > > ... > > > > this is recommended practice per PEP 8: > > http://www.python.org/dev/peps/pep-0008/ > > > > ... > > > > would anyone be opposed to me fixing up the current codebase > > to adhere to this? running `reindent.py` on the files is easy enough, > > i'm willing to step through the files (`opendiff` / `FileMerge.app`) > > and verify no unlikely syntactic changes have occurred. i can also > > deliver changes in gradual "chunked" pull requests to ease > > current developers getting possibly bit by merge issues. > > +1 on correcting any tabs to spaces in the Galaxy Python code. > Doing this in chunked commits makes good sense too - although > if you can get one of the Galaxy team to do this directly it might > be quicker.
It is the Galaxy Team's intent to use four-space indents, anything else is a mistake and we try to fix 'em as we see 'em. Nobody has yet taken the time to fix them all (i.e. with reindent.py) but such fixes would be welcome. > Personally I'd like to go further and fix the non-PEP8 white > space in most of the Galaxy Python code, e.g. > > function ( argument ) > > rather than: > > function(argument). There are a lot of parts of PEP 8 that I doubt we want to adhere to strictly. I agree it's annoying to find varying styles, but the space inside parentheses is not one I get too worked up about. FWIW, I prefer function( argument ) and I tend to see that style out of most of the rest of the team. > Chatting to some of the Galaxy team at BOSC/ISMB 2011 > there is some support for this internally. Again, there are > automated tools to do this. > > > would anyone be willing to add the appropriate hooks to > > the central repository as well? > > As long as there are no false positives identified during > the initial tab/space conversion that seems sensible to > prevent new tabs creeping in. But not essential. We can't add custom hooks to the bitbucket repository and we don't have an intermediate local repository that we all push changesets through. --nate > > Peter > > ___________________________________________________________ > Please keep all replies on the list by using "reply all" > in your mail client. To manage your subscriptions to this > and other Galaxy lists, please use the interface at: > > http://lists.bx.psu.edu/ > ___________________________________________________________ Please keep all replies on the list by using "reply all" in your mail client. To manage your subscriptions to this and other Galaxy lists, please use the interface at: http://lists.bx.psu.edu/