I'm reviewing my tickets (seems a good thing to do with a release imminent), and I'll post up each ticket that merits comment as a separate message.
Ticket #843 has gone into trunk (commit 5361, oliphant) ... but your editor appears to be introducing hard tabs! Hard tab characters are fortunately relatively rare in numpy source, but my patch has gone in with tabs I didn't use.
/me wanders off muttering darkly about the evils of tab characters...
On Tue, Jul 15, 2008 at 1:42 AM, Michael Abbott michael@araneidae.co.uk wrote:
I'm reviewing my tickets (seems a good thing to do with a release imminent), and I'll post up each ticket that merits comment as a separate message.
Ticket #843 has gone into trunk (commit 5361, oliphant) ... but your editor appears to be introducing hard tabs! Hard tab characters are fortunately relatively rare in numpy source, but my patch has gone in with tabs I didn't use.
/me wanders off muttering darkly about the evils of tab characters... ___
Thanks for doing this. If Travis doesn't comment in the next day or two I'll look to making the changes.
Chuck
On Tue, Jul 15, 2008 at 09:59, Charles R Harris charlesr.harris@gmail.com wrote:
On Tue, Jul 15, 2008 at 1:42 AM, Michael Abbott michael@araneidae.co.uk wrote:
I'm reviewing my tickets (seems a good thing to do with a release imminent), and I'll post up each ticket that merits comment as a separate message.
Ticket #843 has gone into trunk (commit 5361, oliphant) ... but your editor appears to be introducing hard tabs! Hard tab characters are fortunately relatively rare in numpy source, but my patch has gone in with tabs I didn't use.
/me wanders off muttering darkly about the evils of tab characters... ___
Thanks for doing this. If Travis doesn't comment in the next day or two I'll look to making the changes.
He's on vacation, so do what you think is best.
On Tue, Jul 15, 2008 at 1:42 AM, Michael Abbott michael@araneidae.co.uk wrote:
I'm reviewing my tickets (seems a good thing to do with a release imminent), and I'll post up each ticket that merits comment as a separate message.
Ticket #843 has gone into trunk (commit 5361, oliphant) ... but your editor appears to be introducing hard tabs! Hard tab characters are fortunately relatively rare in numpy source, but my patch has gone in with tabs I didn't use.
Heh, hard tabs have been removed.
Chuck
On Wed, 16 Jul 2008, Charles R Harris apparently wrote:
Hard tab characters are fortunately relatively rare in numpy source
http://www.rizzoweb.com/java/tabs-vs-spaces.html
Cheers, Alan Isaac
On Wed, 16 Jul 2008, Alan G Isaac wrote:
On Wed, 16 Jul 2008, Charles R Harris apparently wrote:
Michael Abbott actually wrote:
Hard tab characters are fortunately relatively rare in numpy source
Ha ha ha! I'm not going to rise to the bait.
Well, I'll just say: source code is a concrete expression, not an abstraction.
I expect an argument on this topic could be unhealthy...
On Wed, Jul 16, 2008 at 1:33 PM, Michael Abbott michael@araneidae.co.uk wrote:
On Wed, 16 Jul 2008, Alan G Isaac wrote:
On Wed, 16 Jul 2008, Charles R Harris apparently wrote:
Michael Abbott actually wrote:
Hard tab characters are fortunately relatively rare in numpy source
Ha ha ha! I'm not going to rise to the bait.
Well, I'll just say: source code is a concrete expression, not an abstraction.
I expect an argument on this topic could be unhealthy...
In any case, the python standard is four spaces. Linux uses tabs. When in Rome...
Chuck
On Wed, 16 Jul 2008, Charles R Harris apparently wrote:
the python standard is four spaces
It is only a recommendation: http://www.python.org/dev/peps/pep-0008/ (And a misguided one at that. ;-) )
Cheers, Alan Isaac
On Wed, Jul 16, 2008 at 2:48 PM, Alan G Isaac aisaac@american.edu wrote:
On Wed, 16 Jul 2008, Charles R Harris apparently wrote:
the python standard is four spaces
It is only a recommendation: http://www.python.org/dev/peps/pep-0008/ (And a misguided one at that. ;-) )
I see your pep-0008 and raise you pep-3100 ;)
- The C style guide will be updated to use 4-space indents, never tabs. This style should be used for all new files; existing files can be updated only if there is no hope to ever merge a particular file from the Python 2 HEAD. Within a file, the indentation style should be consistent. No other style guide changes are planned ATM.
I'll bet you use Emacs too ;)
Chuck
Alan G Isaac wrote:
It is only a recommendation: http://www.python.org/dev/peps/pep-0008/ (And a misguided one at that. ;-) )
Maybe so, but it is indeed more than a recommendation, it is a de-facto standard. If Python had never allowed mixed tabs and spaces, it might be OK to use tabs for some projects, and spaces for others, but that's water long since under the bridge.
Indentation is syntax in python -- we do need to all do it the same way, and four spaces is the standard -- there simply isn't another reasonable option if you want o share code with anyone else.
-Chris
2008/7/16 Christopher Barker Chris.Barker@noaa.gov:
Indentation is syntax in python -- we do need to all do it the same way, and four spaces is the standard -- there simply isn't another reasonable option if you want o share code with anyone else.
I agree. Let's just end this thread here. It simply can't lead to any useful discussion.
Stéfan
On Wed, 16 Jul 2008, Christopher Barker apparently wrote:
Indentation is syntax in python -- we do need to all do it the same way, and four spaces is the standard -- there simply isn't another reasonable option if you want o share code with anyone else.
Last comment (since this has already gone too long):
There are large projects that accept the use of either convention. (E.g., Zope, if I recall correctly.)
BUT projects set their own style guidelines, and I am NOT in any way proposing that NumPy change. (Not that it would possibly matter if I did so.)
But just to be clear: the common arguments against the use of tabs are demonstrably false and illustrate either ignorance or use of an incapable editor. Nobody with a decent editor will ever have problems with code that consistently uses tabs for indentation---a choice that can easily be signalled by modelines when code is shared on a project that allows both conventions.
Cheers, Alan
participants (6)
-
Alan G Isaac -
Charles R Harris -
Christopher Barker -
Michael Abbott -
Robert Kern -
Stéfan van der Walt