Re: PEP8 and 4 spaces
On Tue, 08 Jul 2014 11:22:25 +1000, Ben Finney wrote:
A group of (a particular amount of) U+0020 characters is visually
indistinguishable from a U+0009 character, when the default semantics
are applied to each.
Hmmm. I'm not sure there actually *is* such a thing as default
semantics for tabs. If you look at a tab character in a font, it
probably looks like a single space, but that depends on the font
designer. But if you look at it in a text editor, it will probably look
like eight spaces, unless it looks like four, or some other number, and
if you look at it in a word processor, it will probably look like a jump
to the next tab stop command. In a spreadsheet application, it will be a
cell separator and consequently doesn't look like anything at all. I
don't think any of those things count as default semantics.
The point being, tabs are *control characters*, like newlines and
carriage returns and form feeds, not regular characters like spaces and
A or λ. Since indent is an *instruction* rather than a character,
it is best handled with a control character.
In any case, if we limit ourselves to text editors, only a specific
number of spaces will be visually indistinguishable from a tab, where the
number depends on which column you start with:
x x # Tab
x x # Seven spaces
x x# Six spaces
xx # Eight spaces
Even in a proportional font, the last two should be distinguishable from
the first two. Admittedly, that does leave the case where N spaces (for
some 1 = N = 8) looks like a tab. That's a probably, but it's not the
only one:
* End of line is a problem. I know of *at least* the following seven
conventions for end-of-line:
- ASCII line feed, \n (Unix etc.)
- ASCII carriage return, \r (Acorn, ZX Spectrum, Apple, etc.)
- ASCII \r\n (CP/M, DOS, Windows, Symbian, Palm, etc.)
- ASCII \n\r (RISC OS)
- ASCII Record Separator, \x1E (QNX)
- EBCDIC New Line, \N{NEXT LINE} in Unicode (IBM mainframes)
- ATASCII \x9B (Atari)
* Form feeds are a problem, since they are invisible, but still get used
(by Vim or Emacs, I forget which) to mark sections of text.
* Issues to do with word-wrapping and hyphenation, or lack thereof, are a
problem.
* Encoding issues are a problem.
* There are other invisible characters than spaces (non-breaking space,
em-space, en-space, thin space).
The solution is to use a smarter editor. For example, an editor might
draw a horizontal rule to show a form feed on a line of its own, or
highlight unexpected carriage return characters with ^M, or display tabs
in a different colour from spaces, or overlay it with a \x09 glyph. Or an
editor might be smart enough to automatically do what the current
paragraph or block does: if the block is already indented with tabs,
pressing tab inserts a tab, but if it is indented with spaces, pressing
tab inserts spaces.
Isn't this why you recommend people use a programmer's editor rather than
Notepad? A good editor should handle these things for you automatically,
or at least with a minimum amount of manual effort.
The former is a control character, which has specific semantics
associated with it; the latter is a printable character, which is
usually printed and interpreted as itself (although in this particular
case, the printed representation is hard to see on most output
devices).
And those specific semantics make the display of those characters easily
confused. That is why it's generally a bad idea to use U+0009 in text
edited by humans.
I disagree. Using tabs is no more a bad idea than using a formfeed, or
having support for multiple encodings.
This mailing list doesn't seem to mind that lines beginning with ASCII
SPC characters are semantically different from lines beginning with
ASCII LF characters, although many detractors of Python seem unduly
fixated on it.
The salient difference being that U+000A LINE FEED is easily visually
distinguished from a short sequence of U+0020 SPACE characters. This
avoids the confusion, and makes use of both together unproblematic.
True, but that's *only* because your editor chooses to follow the
convention display a LINE FEED by starting a new line rather than by
the convention display the (invisible or zero-width) glyph of the LINE
FEED. If editors were to standardise on the convention display a
HORIZONTAL TAB character as visibly distinct from a sequence of
spaces (e.g. by shading the background a different colour, or overlying
it with an arrow) then we would not be having this discussion.
In other words, it is the choice of editors to be *insufficiently smart*
about tabs that causes the problem. There is a vicious circle here:
* editors don't handle tabs correctly
* which leads to (some) people believing that tabs are bad and should
be avoided
* which leads to editors failing to handle tabs correctly, because tabs
are bad and should be avoided.
A pity really.
Re: PEP8 and 4 spaces
On Tue, Jul 8, 2014 at 6:48 PM, Steven D'Aprano st...@pearwood.info wrote: If editors were to standardise on the convention display a HORIZONTAL TAB character as visibly distinct from a sequence of spaces (e.g. by shading the background a different colour, or overlying it with an arrow) DeScribe Word Processor has (had? it hasn't been developed in about a decade... but it still runs just fine) a whole lot of visual guides for metacharacters, which can be turned on or off. Normally, we prefer not to have a little dot to mark every 0x20 space, but you can have 'em if you want 'em; tabs get shown as diamonds; paragraph markers as pilcrows; line breaks as a small circle; and so on. (The difference between a paragraph and a line break isn't a normal one in most text editors, so I'd be looking at representing U+000A newlines with a pilcrow, probably.) Obviously you need a means of distinguishing the end-of-line marker from an actual character, since PILCROW SIGN is a perfectly acceptable character; but if the metacharacters are shown in, say, a pale blue, rather than the usual black text, it'd be easy enough. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Steven D'Aprano st...@pearwood.info: * editors don't handle tabs correctly But you said yourself: I'm not sure there actually *is* such a thing as default semantics for tabs. What is correct handling of ASCII TAB characters in a text file? The unix tradition is to let the TTY interpret the TABs. Utilities such as ed, cat, diff or gcc don't interpret or process TABs in any way but simply output them together with the rest of the text. And the TTY tradition is to have TAB stops at every 8 columns (by default). So this question has little to do with text editors except in that your editor should display your program roughly the same way as lpr prints it out. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Tue, Jul 8, 2014 at 7:09 PM, Marko Rauhamaa ma...@pacujo.net wrote: The unix tradition is to let the TTY interpret the TABs. Utilities such as ed, cat, diff or gcc don't interpret or process TABs in any way but simply output them together with the rest of the text. Not quite; tools like diff that put a character at the beginning of the line are likely to be tab-aware, and gcc is certainly going to comprehend them (at least to the extent of treating them as whitespace). And I think less takes notice of them, too, so it's only the very simplest tools like cat that actually ignore them or treat them as single characters (or even bytes). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Chris Angelico ros...@gmail.com:
Not quite; tools like diff that put a character at the beginning of
the line are likely to be tab-aware,
No, just tried it again: diff outputs tabs as tabs.
$ diff abc def
1,2c1,2
abc
abc
---
def
def
where line 1 begins with a tab and line 2 begins with 8 spaces in each
file.
and gcc is certainly going to comprehend them
$ gcc -c test.c
test.c:1:2: error: expected identifier or ‘(’ at end of input
where test.c contains
TAB(LF
IOW, gcc reports that the open parenthesis is in column 2.
(at least to the extent of treating them as whitespace).
Sure, but that doesn't concern the tab stops in any way.
And I think less takes notice of them, too,
How?
so it's only the very simplest tools like cat that actually ignore
them or treat them as single characters (or even bytes).
They all seem to be simple. At least Python is:
$ python3 -c 'print ('
File string, line 1
print(
^
SyntaxError: unexpected EOF while parsing
where the caret is pointing at the wrong visual column.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Tue, Jul 8, 2014 at 9:13 PM, Marko Rauhamaa ma...@pacujo.net wrote:
Chris Angelico ros...@gmail.com:
Not quite; tools like diff that put a character at the beginning of
the line are likely to be tab-aware,
No, just tried it again: diff outputs tabs as tabs.
$ diff abc def
1,2c1,2
abc
abc
---
def
def
where line 1 begins with a tab and line 2 begins with 8 spaces in each
file.
Check out its -t and -T options; diff is definitely tab-aware.
and gcc is certainly going to comprehend them
$ gcc -c test.c
test.c:1:2: error: expected identifier or ‘(’ at end of input
where test.c contains
TAB(LF
IOW, gcc reports that the open parenthesis is in column 2.
It's easier to number the positions that way, in the same way that you
would number lines - by how many times you have to hit down or right
arrow to get there. In my MUD client, I measure text positions in
characters (within a line; a particular position is identified by
(line, char), because lines are generally far more important than
overall positions), even when tabs are involved; a tab simply counts
as one character, even though it displays as up to eight times the
width. Actually, I'm currently contemplating a reworking of how that's
all mapped out, which would mean that *any* character is allowed to
take up *any* width, including zero, in which case the only
significance is that a tab takes up a variable width depending on
where it is in the line (which is already coped with).
And I think less takes notice of them, too,
How?
Shrink your terminal down to some weird width like 45, create a file
with long lines including tabs, 'less' the file, and use the right
arrow key to scroll horizontally. It takes note of tabs and renders
them properly.
so it's only the very simplest tools like cat that actually ignore
them or treat them as single characters (or even bytes).
They all seem to be simple. At least Python is:
$ python3 -c 'print ('
File string, line 1
print(
^
SyntaxError: unexpected EOF while parsing
where the caret is pointing at the wrong visual column.
If someone cares enough to write a patch, I'm sure the traceback
renderer could be improved. But how many people actually use tabs
inside code like that?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Steven D'Aprano st...@pearwood.info writes: On Tue, 08 Jul 2014 11:22:25 +1000, Ben Finney wrote: A group of (a particular amount of) U+0020 characters is visually indistinguishable from a U+0009 character, when the default semantics are applied to each. Hmmm. I'm not sure there actually *is* such a thing as default semantics for tabs. It was likely never standardised, but yes, default semantics are long established for the HT (Horizontal Tab) control code in a text stream URL:https://en.wikipedia.org/wiki/Tab_key#Tab_characters. The default semantics are that an HT (Horizontal Tabulation) control code is an instruction to introduce enough horizontal space such that the following character appears at the next multiple-of-8 column. These semantics assume a fixed character width, which is itself a default semantic of the display of computer text; variable-width is a deviation from the default. If you look at a tab character in a font I'm not talking about glyphs (for a control code, there isn't much sense talking about a default glyph), I'm talking about the default semantics of how they affect display. But if you look at it in a text editor, it will probably look like eight spaces, unless it looks like four, or some other number, and if you look at it in a word processor, it will probably look like a jump to the next tab stop command. Right. Programs that conform to the established default semantics for an HT (U+0009) code point will shift to the next tab stop to display the following character. Tab stops themselves are, in fixed-width character layout (which is itself the historical default), spaced apart by multiples of 8 character columns. I don't think any of those things count as default semantics. I hope my position is clearer. The point being, tabs are *control characters*, like newlines and carriage returns and form feeds, not regular characters like spaces and A or λ. Since indent is an *instruction* rather than a character, it is best handled with a control character. Right. And those control codes affect display of the text, and there are default semantics for those codes: what those control codes specifically mean. The HT code has the default display semantic of “display the following character at the next horizontal tab stop”. The solution is to use a smarter editor. The recipient's choice of editor program is not within the control of the author. Furthermore, it's expecting that the recipient will deviate from the default display semantics of the text as received. The author should write the text such that the default semantics are useful, and/or avoid text where the default semantics are undesirable or unreliably implemented. In this case: If the programmer doesn't like U+0009 resulting in text aligned at multiple-of-8 tab stops, or doesn't like the fact that recipients may have tab stops set differently, then I don't care what editor the author uses; they should avoid putting U+0009 into text. That said, a smarter text editor program *can* be a solution for “I don't like the default semantics *as displayed on my computer*”. If a programmer wants to deviate from the defaults, and can convince others on a rational and non-coercive basis to go along with their non-default preferences, they all have my blessing. If they want their preferences to override the default more broadly, they need a better argument than “it just looks better to me”. Isn't this why you recommend people use a programmer's editor rather than Notepad? I don't see how recommending a better editor for the *author* addresses how the *recipient*'s device renders the text. so no, that's not a reason why I recommend the author use a programmer's editor. True, but that's *only* because your editor chooses to follow the convention display a LINE FEED by starting a new line rather than by the convention display the (invisible or zero-width) glyph of the LINE FEED. If editors were to standardise on the convention display a HORIZONTAL TAB character as visibly distinct from a sequence of spaces (e.g. by shading the background a different colour, or overlying it with an arrow) then we would not be having this discussion. If things were different, they'd be different. I'm talking about default display semantics of the U+0009 code as they are. -- \ “I used to be an airline pilot. I got fired because I kept | `\ locking the keys in the plane. They caught me on an 80 foot | _o__)stepladder with a coathanger.” —Steven Wright | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Dan Sommers d...@tombstonezero.net writes: On Mon, 07 Jul 2014 11:00:59 +1000, Ben Finney wrote: […] a poor design decision (a line beginning with U+0020 SPACE is semantically different from a line beginning with U+0009 CHARACTER TABULATION) can be irrevocable – the syntax can't be changed now, without breaking compatibility for countless makefiles out there already – and cause endless confusion and wasted effort dealing with it. When makefile syntax came into being, there were ASCII TAB characters, with a value of 9, and ASCII SPC characters, with a value of 32 (and there may not even have been those). A group of (a particular amount of) U+0020 characters is visually indistinguishable from a U+0009 character, when the default semantics are applied to each. The former is a control character, which has specific semantics associated with it; the latter is a printable character, which is usually printed and interpreted as itself (although in this particular case, the printed representation is hard to see on most output devices). And those specific semantics make the display of those characters easily confused. That is why it's generally a bad idea to use U+0009 in text edited by humans. This mailing list doesn't seem to mind that lines beginning with ASCII SPC characters are semantically different from lines beginning with ASCII LF characters, although many detractors of Python seem unduly fixated on it. The salient difference being that U+000A LINE FEED is easily visually distinguished from a short sequence of U+0020 SPACE characters. This avoids the confusion, and makes use of both together unproblematic. -- \ “Come on Milhouse, there’s no such thing as a soul! It’s just | `\ something they made up to scare kids, like the Boogie Man or | _o__) Michael Jackson.” —Bart, _The Simpsons_ | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: Flashlights [was Re: PEP8 and 4 spaces]
On Saturday, July 5, 2014 5:15:32 AM UTC-5, Steven D'Aprano wrote: (By the way, outside of the USA, flashlights in the rest of the English- speaking world are usually called torches, so called because, like the old-fashioned burning torch, they provide light.) Well Steven all i can hope is that one day you and i will be working on a project together, and you will ask me for a touch, and when i return with a petrol soaked rag burning on the end of twig and proceed to light your hair on fire, hopefully at that moment, you will THEN gain a healthy respect for logical naming conventions! You see, just as a proper programming language utilize the punishments of Exceptions for illogical behaviors, life utilizes the power of pain for even greater effect. Ah, what's that old adage about doing the same things over and over but expecting different results? Oh well, maybe someone can chime in... SHALL WE RINSE AND REPEAT MR.D'APRANO? A few minutes googling would have given you the answer: flashlights are called flashlights because originally you could only flash them on and off. Due to the high power requirements and the low battery capacities at the time, leaving the torch switched on would burn out the filament, exhaust the battery, or both. So what you're telling me is that in the early days of the portable light the function of the device was so terrible that the best all one could hope for was limited intermittent functionality with a great chance of destroying the device simply in the course of its normal use? Wow, and people actually paid money for these devices? Sounds like window 95 all over again! SNIP HISTORY LESSON *yawn* So far from being an illogical term, the name flashlight actually gives you a glimpse into the historical background of the invention. Yes, because when my power goes out, and i need to get to the electrical panel during a torrential rainstorm, at 2am in the morning, after a long day working in the company of idiots, and then coming home to a nagging significant other, and then my dog dies... whist i tromp through the mud and the muck, at least my mind will be at peace knowing the historical significance of an illogical naming convention coined for a device that was so impractical as to render itself completely useless... THANKS FLASHLIGHT @_@! -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Thu, Jul 3, 2014 at 10:31 AM, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. I recently converted from tabs to spaces. I probably still have some code that uses tabs, but most of my personal stuff has been converted. I like tabs. Tabs work better for me than spaces, because I know how to use them. Also, some make tools insist on tabs. Also, where many people like 4 spaces or 8 spaces, I prefer tabs expanded to 3 columns. But I finally acknowledged that some very smart people don't understand tabs, or don't want to learn how to use them. Also, I figured out how to get python files to use spaces and Makefile's to use tabs, using some slight vim configuration. So I'm using 4 spaces now. It's nice not having to ignore the relevant pep8 and pylint warnings anymore. And I don't miss tabs nearly as much as I thought I would. In fact, I'm not sure I miss them at all. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Sun, Jul 6, 2014 at 1:25 PM, Dan Stromberg drsali...@gmail.com wrote: I like tabs. Tabs work better for me than spaces, because I know how to use them. Also, some make tools insist on tabs. Those tools are just as broken as the ones that only work with spaces. Fortunately, I can't even remember the last time I had to edit a Makefile. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
In article mailman.11557.1404674726.18130.python-l...@python.org, Dan Stromberg drsali...@gmail.com wrote: On Thu, Jul 3, 2014 at 10:31 AM, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. I recently converted from tabs to spaces. I probably still have some code that uses tabs, but most of my personal stuff has been converted. I like tabs. Tabs work better for me than spaces, because I know how to use them. Also, some make tools insist on tabs. Why should the fact that Make requires tabs affect how you edit Python code? -- https://mail.python.org/mailman/listinfo/python-list
Re: OT: Flashlights [was Re: PEP8 and 4 spaces]
On Mon, Jul 7, 2014 at 1:41 AM, Rick Johnson rantingrickjohn...@gmail.com wrote: Well Steven all i can hope is that one day you and i will be working on a project together, and you will ask me for a touch, and when i return with a petrol soaked rag burning on the end of twig and proceed to light your hair on fire, hopefully at that moment, you will THEN gain a healthy respect for logical naming conventions! Let's reverse that. Suppose you're the one who is asking for something to illuminate your task - what item will you request? Remember, the person who provides it will be exactly what you're suggesting of yourself - a literal-minded genie. http://tvtropes.org/pmwiki/pmwiki.php/Main/LiteralGenie http://tvtropes.org/pmwiki/pmwiki.php/Main/JackassGenie ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Dan Stromberg drsali...@gmail.com writes: But I finally acknowledged that some very smart people don't understand tabs, or don't want to learn how to use them. One day, you may reach the further realisation that those same very smart people *do* understand tabs, and *do* know how to use them — and nevertheless choose not to put them in source code, for good reasons. Also, I figured out how to get python files to use spaces and Makefile's to use tabs, using some slight vim configuration. The makefile syntax is one of the excellent examples of why it's a terrible idea to use tab characters in source code. It's also an excellent example of how a poor design decision (a line beginning with U+0020 SPACE is semantically different from a line beginning with U+0009 CHARACTER TABULATION) can be irrevocable – the syntax can't be changed now, without breaking compatibility for countless makefiles out there already – and cause endless confusion and wasted effort dealing with it. Using a mature, well-customised, language-agnostic programmer's editor does make it much better: Vim and Emacs can both seamlessly handle “tabs are forbidden by default” as a configuration choice, along with “tabs are necessary in make files, using spaces in the wrong place is an error” at the same time. So I'm using 4 spaces now. It's nice not having to ignore the relevant pep8 and pylint warnings anymore. And I don't miss tabs nearly as much as I thought I would. In fact, I'm not sure I miss them at all. Hooray! Welcome to the light :-) -- \ “The best ad-libs are rehearsed.” —Graham Kennedy | `\ | _o__) | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Mon, 07 Jul 2014 11:00:59 +1000, Ben Finney wrote: The makefile syntax is one of the excellent examples of why it's a terrible idea to use tab characters in source code. Hmmm... I'm not sure that conclusion follows. I think that makefile syntax is an example of why it is a terrible idea to give spaces and tabs different semantics, not that tabs themselves are harmful. It's also an excellent example of how a poor design decision (a line beginning with U+0020 SPACE is semantically different from a line beginning with U+0009 CHARACTER TABULATION) can be irrevocable Yes. Design your public APIs cleanly and clearly from the start. The story of makefiles is a warning of the dark side to release early, release often, and the dangers of using alpha software in production: [quote] Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history. -- Stuart Feldman [end quote] -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Mon, Jul 7, 2014 at 12:28 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: The story of makefiles is a warning of the dark side to release early, release often, and the dangers of using alpha software in production: [quote] Why the tab in column 1? Yacc was new, Lex was brand new. I hadn't tried either, so I figured this would be a good excuse to learn. After getting myself snarled up with my first stab at Lex, I just did something simple with the pattern newline-tab. It worked, it stayed. And then a few weeks later I had a user population of about a dozen, most of them friends, and I didn't want to screw up my embedded base. The rest, sadly, is history. -- Stuart Feldman [end quote] Perhaps. Or perhaps it's a warning about the importance of version 0 of a piece of software: you release early, release often, but you start with version 0.1, where the standard backward compat guarantees don't hold. You get some feedback, and then when you finally release version 1.0, you start promising not to mess people's stuff up; but before that, anything might change. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Mon, 07 Jul 2014 11:00:59 +1000, Ben Finney wrote: The makefile syntax is one of the excellent examples of why it's a terrible idea to use tab characters in source code. It's also an excellent example of how a poor design decision (a line beginning with U+0020 SPACE is semantically different from a line beginning with U+0009 CHARACTER TABULATION) can be irrevocable – the syntax can't be changed now, without breaking compatibility for countless makefiles out there already – and cause endless confusion and wasted effort dealing with it. When makefile syntax came into being, there were ASCII TAB characters, with a value of 9, and ASCII SPC characters, with a value of 32 (and there may not even have been those). The former is a control character, which has specific semantics associated with it; the latter is a printable character, which is usually printed and interpreted as itself (although in this particular case, the printed representation is hard to see on most output devices). This mailing list doesn't seem to mind that lines beginning with ASCII SPC characters are semantically different from lines beginning with ASCII LF characters, although many detractors of Python seem unduly fixated on it. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Jul 4, 2014, at 11:29, Lie Ryan lie.1...@gmail.com wrote: On 04/07/14 07:55, Gregory Ewing wrote: Steven D'Aprano wrote: That's exactly the problem with tabs - whatever you think your code looks like with tabs, other people will see quite different picture. Why do you consider this a problem? It's a problem if you try to use tabs for lining things up in a tabular fashion in your source code. The solution is not to use tabs for that -- only use tabs for indentation, and use spaces for everything else. Or, as PEP 8 suggests, don't try to line things up in the first place. PEP8 suggests using this style of method invocation: obj.method(foo, bar, baz) which is an effect impossible to do correctly with tabs alone. If you want to follow this style strictly, you end up having to either mix tabs and spaces, or just use spaces, or as I prefer it, avoid the issue altogether: obj.method( foo, bar, baz, ) Ok, here's irony. I'm looking at that thinking what the heck is he talking about?!?. And then my brain catches up. My mail reader is of course modern and does not use a mono space font. So the value of the along ed indent is lost anyway. But wasn't that what spaces were supposed to give us over tabs, some separation from the trading betwixt different editors? Chuckle. Travis Griggs -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Sat, Jul 5, 2014 at 12:47 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: Of course, I'm anxiously await my friend to ask for a drop light -- oh boy, that will be fun! :^) Just wait till you get into theatre, and people start asking for parcans, domes, bubbles, gobos, gels, and workers. If you can't learn a little technical terminology for the field you're in, you're in the wrong universe. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Rick Johnson wrote: Why is a handheld light called a flashlight? It does not flash, According to Wikipedia, originally it did: Early flashlights ran on zinc–carbon batteries, which could not provide a steady electric current and required periodic 'rest' to continue functioning. Because these early flashlights also used energy-inefficient carbon-filament bulbs, resting occurred at short intervals. Consequently, they could be used only in brief flashes, hence the common American name flashlight. Of course, in sane parts of the world, we call them torches. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Sat, 05 Jul 2014 20:57:14 +1200, Gregory Ewing wrote: Rick Johnson wrote: Why is a handheld light called a flashlight? It does not flash, According to Wikipedia, originally it did: Early flashlights ran on zinc–carbon batteries, which could not provide a steady electric current and required periodic 'rest' to continue functioning. Because these early flashlights also used energy-inefficient carbon-filament bulbs, resting occurred at short intervals. Consequently, they could be used only in brief flashes, hence the common American name flashlight. Of course, in sane parts of the world, we call them torches. :-) +1 don't just use the correct tool fro the job use the correct name for the tool ;-) -- If your bread is stale, make toast. -- https://mail.python.org/mailman/listinfo/python-list
OT: Flashlights [was Re: PEP8 and 4 spaces]
On Fri, 04 Jul 2014 19:47:45 -0700, Rick Johnson wrote: [A continuation of my last reply...] Here is a recent situation that occurred to me that showcases the tendency of humans to carelessly bind illogical terms to common objects, I think you mean the tendency of certain people to go off half-cocked and mistake their own ignorance for knowledge. Since I personally don't know why flashlights are called that name, it clearly MUST BE that there is no reason for that name!!! (By the way, outside of the USA, flashlights in the rest of the English- speaking world are usually called torches, so called because, like the old-fashioned burning torch, they provide light.) thereby creating a inverse esoteric of ubiquitous illogic, in this case, the term: flash-light. A few minutes googling would have given you the answer: flashlights are called flashlights because originally you could only flash them on and off. Due to the high power requirements and the low battery capacities at the time, leaving the torch switched on would burn out the filament, exhaust the battery, or both. The Oxford Dictionary also points out that flashlight is a term used for signalling and warning lights, such as in lighthouses. It doesn't say whether the signalling use inspired, or was inspired by, the hand-held flashlight. I expect that, since electric lighthouses are more than two decades older than flashlights, that usage came first. Both the flashlight and the flash bulb were first patented in 1899, and it is possible that the name of one was influenced by the name of the other. Flash bulbs used an electrically-ignited filament of magnesium to provide a single, extremely bright, flash of light. They replaced the older system of a small trough of flash powder (a mixture of magnesium and potassium chlorate) ignited in the air. So far from being an illogical term, the name flashlight actually gives you a glimpse into the historical background of the invention. Of course everyone knows that a flash light does not flash, Everybody is wrong. I have torches (flashlights) with a flash function, where they flash on and off. I've also owned torches where they had a switch to turn them on and give a steady, hands-free light, and a second button that only generated light while it was held down. so why do we continue to propagate such foolish terms? Not a foolish term, merely a sign that technology marches on. Well, for the same reason language designers keep giving us illogical terms like function and class, but i digress. Oh my, I can hardly wait to hear this. It ought to be good. The point is we go around the world falsely believing we have a strong grasp of the simple things Speak for yourself. Oh, I see you are! -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Fri, Jul 4, 2014 at 8:00 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: Strangly, I rather fancy the idea of using tabs in code,,, which allow each viewer to view the code in his or her level of indention,,, however, i cannot justify using a tab as a replacement for a space. Tabs should be used for tabular data (aka: speadsheets), and since code is NOT tabular data, we would be wise to use the space char for indention. I find it a little curious that nobody ever seems to advocate the use of vertical tabs instead of repeated newlines. It should offer the same benefit as horizontal tabs, namely that one could then independently configure one's editor to separate adjacent code elements with the desired number of blank lines. But I suppose that nobody finds that useful enough to bother with in the vertical case. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
In article mailman.11525.1404586681.18130.python-l...@python.org, Ian Kelly ian.g.ke...@gmail.com wrote: On Fri, Jul 4, 2014 at 8:00 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: Strangly, I rather fancy the idea of using tabs in code,,, which allow each viewer to view the code in his or her level of indention,,, however, i cannot justify using a tab as a replacement for a space. Tabs should be used for tabular data (aka: speadsheets), and since code is NOT tabular data, we would be wise to use the space char for indention. I find it a little curious that nobody ever seems to advocate the use of vertical tabs instead of repeated newlines. It should offer the same benefit as horizontal tabs, namely that one could then independently configure one's editor to separate adjacent code elements with the desired number of blank lines. But I suppose that nobody finds that useful enough to bother with in the vertical case. Personally, I'm holding out for U+00A0 being a valid character in an identifier. Intercourse this underscore stuff. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 2014-07-05 19:57, Ian Kelly wrote: On Fri, Jul 4, 2014 at 8:00 PM, Rick Johnson rantingrickjohn...@gmail.com wrote: Strangly, I rather fancy the idea of using tabs in code,,, which allow each viewer to view the code in his or her level of indention,,, however, i cannot justify using a tab as a replacement for a space. Tabs should be used for tabular data (aka: speadsheets), and since code is NOT tabular data, we would be wise to use the space char for indention. I find it a little curious that nobody ever seems to advocate the use of vertical tabs instead of repeated newlines. It should offer the same benefit as horizontal tabs, namely that one could then independently configure one's editor to separate adjacent code elements with the desired number of blank lines. But I suppose that nobody finds that useful enough to bother with in the vertical case. I do see the occasional person using form feeds to separate sections of code. -- Robert Kern I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth. -- Umberto Eco -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 07/04/2014 08:54 AM, Marko Rauhamaa wrote: Grant Edwards invalid@invalid.invalid: Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. Often one person writes the code and another person fixes bugs in it or adds features to it. So if one uses tabs and the other refrains from using them, you'll get the mixed style you abhor. Even if we accepted that to be bad style, there's nothing on the screen that would warn against such usage: the lines seemingly align perfectly, and the code runs as expected. Or more likely the lines seemingly align perfectly and the code does not compile and run, or worse it does run but does not do the right thing. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 05/07/2014 23:03, Michael Torrie wrote: On 07/04/2014 08:54 AM, Marko Rauhamaa wrote: Grant Edwards invalid@invalid.invalid: Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. Often one person writes the code and another person fixes bugs in it or adds features to it. So if one uses tabs and the other refrains from using them, you'll get the mixed style you abhor. Even if we accepted that to be bad style, there's nothing on the screen that would warn against such usage: the lines seemingly align perfectly, and the code runs as expected. Or more likely the lines seemingly align perfectly and the code does not compile and run, or worse it does run but does not do the right thing. Some commentators lead me to believe that the latter is perfectly acceptable so long as the code runs quickly. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Sun, Jul 6, 2014 at 4:57 AM, Ian Kelly ian.g.ke...@gmail.com wrote: I find it a little curious that nobody ever seems to advocate the use of vertical tabs instead of repeated newlines. It should offer the same benefit as horizontal tabs, namely that one could then independently configure one's editor to separate adjacent code elements with the desired number of blank lines. But I suppose that nobody finds that useful enough to bother with in the vertical case. How often do you ever have multiple consecutive blank lines? My newlines are either single (line end) or in pairs (one blank line), and I don't remember having anything else (at least, not intentionally). Greater separation than a blank line is provided by comments, not more whitespace. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Sun, 06 Jul 2014 09:27:59 +1000, Chris Angelico wrote: How often do you ever have multiple consecutive blank lines? My newlines are either single (line end) or in pairs (one blank line), and I don't remember having anything else (at least, not intentionally). Greater separation than a blank line is provided by comments, not more whitespace. ChrisA http://legacy.python.org/dev/peps/pep-0008/#id15 says: Separate top-level function and class definitions with two blank lines. With docstrings occurring inside function definitions, this happens quite a bit. Dan -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Sun, Jul 6, 2014 at 11:18 AM, Dan Sommers d...@tombstonezero.net wrote: On Sun, 06 Jul 2014 09:27:59 +1000, Chris Angelico wrote: How often do you ever have multiple consecutive blank lines? My newlines are either single (line end) or in pairs (one blank line), and I don't remember having anything else (at least, not intentionally). Greater separation than a blank line is provided by comments, not more whitespace. ChrisA http://legacy.python.org/dev/peps/pep-0008/#id15 says: Separate top-level function and class definitions with two blank lines. With docstrings occurring inside function definitions, this happens quite a bit. Ah, okay. Still, it's not something that scales up much, the way horizontal whitespace does. You go to 2 blanks, and extras (sparingly) between groups, but it's not like indentation, where nesting naturally requires progressively more space. If you're nesting groups of functions like that, you probably should be using something other than whitespace (maybe separate files?). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Steven D'Aprano wrote: Disadvantages of tabs: - Many standard Unix/Linux/POSIX tools have a hard time dealing with tabs. I call such tools *broken*, They're not broken, they're just using a different set of conventions. Unix traditionally uses tab characters as a form of space compression. The meaning of a tab is fixed, and configurable indentation is done by inserting a suitable combination of tabs and spaces. As long as *all* your tools follow that convention, everything is fine. The problems arise when you mix in tools that use different conventions. The truly broken tools IMO are things like mail handlers that shrink away in terror when they see a tab and remove it altogether. There's no excuse for that, as far as I can see. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Steven D'Aprano wrote: That's exactly the problem with tabs - whatever you think your code looks like with tabs, other people will see quite different picture. Why do you consider this a problem? It's a problem if you try to use tabs for lining things up in a tabular fashion in your source code. The solution is not to use tabs for that -- only use tabs for indentation, and use spaces for everything else. Or, as PEP 8 suggests, don't try to line things up in the first place. I know it's ironic that tabs are no good for tabulation. But it's unavoidable in a plain text format that doesn't carry any metadata about how to interpret the tabs. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
wxjmfa...@gmail.com: Le vendredi 4 juillet 2014 08:35:04 UTC+2, Gregory Ewing a écrit : The truly broken tools IMO are things like mail handlers that shrink away in terror when they see a tab and remove it altogether. There's no excuse for that, as far as I can see. Yes, and you can extend this to the editors, which deliberately missusing the tabulation rules by inserting something else, eg. spaces (U+0020, 'SPACE'). A worthy flame war with top-class trolling mixed in. How could I stay out? My esteemed editor never misuses the tabulation rules as I have instructed it to never insert TAB characters in files: (custom-set-variables '(indent-tabs-mode nil)) Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Thu, Jul 3, 2014 at 7:31 PM, Tobiah tshep...@rcsreg.com wrote: Anyway, I gave up the 80 char line length long ago, having little feeling for some dolt on a Weiss terminal that for some reason needs to edit my code. And yet, you did not give up an even more insane line length limit, in e-mail. The longest line in your original message is a measly 57 characters long. The median line length is 46 characters. Which is pretty insane, and ultra-hard to read. You can do more in e-mail. Each line of characters MUST be no more than 998 characters, and SHOULD be no more than 78 characters, excluding the CRLF. That's the standard, [RFC 5322][]; the exact same quote appeared back in [RFC 2822][]. However, many places actually want you to use a bit less; common values include 70 or 72. But still, it is MUCH more roomy and readable than the value you use. Here are the line lengths in the original message: [47, 45, 45, 46, 46, 47, 45, 5, 46, 43, 46, 47, 47, 49, 31, 57, 52, 34, 42, 23] [RFC 5322]: http://tools.ietf.org/html/rfc5322#section-2.1.1 [RFC 2822]: http://tools.ietf.org/html/rfc2822#section-2.1.1 -- Chris “Kwpolska” Warrick http://kwpolska.tk PGP: 5EAAEA16 stop html mail | always bottom-post | only UTF-8 makes sense -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
In article c1n08qfhvj...@mid.individual.net, Gregory Ewing greg.ew...@canterbury.ac.nz wrote: As long as *all* your tools follow that convention, everything is fine. The problems arise when you mix in tools that use different conventions. The problem is, tools always get mixed. I use emacs. The next guy uses vi. Somebody else uses Sublime. The list goes on and on. You will never control what tools other people use. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 07/04/2014 04:47 PM, Roy Smith wrote: As long as*all* your tools follow that convention, everything is fine. The problems arise when you mix in tools that use different conventions. The problem is, tools always get mixed. I use emacs. The next guy uses vi. Somebody else uses Sublime. The list goes on and on. You will never control what tools other people use. This may be the subject of a PEP: What tool will you use :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 2014-07-03, Emile van Sebille em...@fenx.com wrote: On 7/3/2014 2:23 PM, Tobiah wrote: I think your suggestion of having GIT handle the transformations is the way we'll go. nothing to quibble or worry about. Well put spaces in the repository since it still seems to be the community's preference and I'll convert to tabs with GIT on the fly. Problem solved. Just watch out for mixed tabs and spaces in the same file -- a tab counts as eight spaces and can be used interchangeably in python2. Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Grant Edwards invalid@invalid.invalid: Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. Often one person writes the code and another person fixes bugs in it or adds features to it. So if one uses tabs and the other refrains from using them, you'll get the mixed style you abhor. Even if we accepted that to be bad style, there's nothing on the screen that would warn against such usage: the lines seemingly align perfectly, and the code runs as expected. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 04/07/2014 15:28, Grant Edwards wrote: On 2014-07-03, Emile van Sebille em...@fenx.com wrote: On 7/3/2014 2:23 PM, Tobiah wrote: I think your suggestion of having GIT handle the transformations is the way we'll go. nothing to quibble or worry about. Well put spaces in the repository since it still seems to be the community's preference and I'll convert to tabs with GIT on the fly. Problem solved. Just watch out for mixed tabs and spaces in the same file -- a tab counts as eight spaces and can be used interchangeably in python2. Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. Yet another reason to switch to Python 3. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Sat, Jul 5, 2014 at 12:54 AM, Marko Rauhamaa ma...@pacujo.net wrote: Grant Edwards invalid@invalid.invalid: Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. Often one person writes the code and another person fixes bugs in it or adds features to it. So if one uses tabs and the other refrains from using them, you'll get the mixed style you abhor. Even if we accepted that to be bad style, there's nothing on the screen that would warn against such usage: the lines seemingly align perfectly, and the code runs as expected. That depends on your editor. SciTE, for instance, will give a warning any time indentation changes wrongly; if you mix tabs and spaces, there'll be error markers at the beginning of each change (so if there's one line with eight spaces amid a sea of tabs, that line and the one below it will be marked). ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 04/07/2014 15:54, Marko Rauhamaa wrote: Grant Edwards invalid@invalid.invalid: Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. Often one person writes the code and another person fixes bugs in it or adds features to it. So if one uses tabs and the other refrains from using them, you'll get the mixed style you abhor. Even if we accepted that to be bad style, there's nothing on the screen that would warn against such usage: the lines seemingly align perfectly, and the code runs as expected. Marko Only for the very old fashioned Python 2, the modern Python 3 has booted mixed tabs and spaces into touch. -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 04/07/2014 14:59, Mihamina Rakotomandimby wrote: On 07/04/2014 04:47 PM, Roy Smith wrote: As long as*all* your tools follow that convention, everything is fine. The problems arise when you mix in tools that use different conventions. The problem is, tools always get mixed. I use emacs. The next guy uses vi. Somebody else uses Sublime. The list goes on and on. You will never control what tools other people use. This may be the subject of a PEP: What tool will you use :-) I'll nominate our resident unicode expert to write the PEP as he's also an expert on tools. Consider his superb use of the greatly loved google groups for example. Sadly I understand that he has yet to master the intricacies of pip, but I'm sure that'll come with practice, or has he given up? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Mark Lawrence breamore...@yahoo.co.uk: Only for the very old fashioned Python 2, the modern Python 3 has booted mixed tabs and spaces into touch. Since Python 3 (alas!) got into the business of booting, it should have booted tabs altogether. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Isn't this an old discussion? Just configure your editor properly. In my team we all use spaces, but I'll be damned if I need to type 12 spaces in a row. I'll just configured Sublime to insert spaces instead of tabs. Problem solved. On Fri, Jul 4, 2014 at 12:12 PM, Mark Lawrence breamore...@yahoo.co.uk wrote: On 04/07/2014 14:59, Mihamina Rakotomandimby wrote: On 07/04/2014 04:47 PM, Roy Smith wrote: As long as*all* your tools follow that convention, everything is fine. The problems arise when you mix in tools that use different conventions. The problem is, tools always get mixed. I use emacs. The next guy uses vi. Somebody else uses Sublime. The list goes on and on. You will never control what tools other people use. This may be the subject of a PEP: What tool will you use :-) I'll nominate our resident unicode expert to write the PEP as he's also an expert on tools. Consider his superb use of the greatly loved google groups for example. Sadly I understand that he has yet to master the intricacies of pip, but I'm sure that'll come with practice, or has he given up? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list -- George R. C. Silva SIGMA Consultoria http://www.consultoriasigma.com.br/ -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 7/4/2014 7:57 AM, Mark Lawrence wrote: On 04/07/2014 15:28, Grant Edwards wrote: On 2014-07-03, Emile van Sebille em...@fenx.com wrote: snip Just watch out for mixed tabs and spaces in the same file -- a tab counts as eight spaces and can be used interchangeably in python2. Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. Yet another reason to switch to Python 3. For new projects, sure. But since the v1.5 days I've deployed the current python version a dozen times a year on various one-offs so that I'm sure I've got every python version deployed somewhere, and they just run, so why fix something that works. Or upgrade it when a three line fix addresses the issue. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 04/07/2014 16:57, Emile van Sebille wrote: On 7/4/2014 7:57 AM, Mark Lawrence wrote: On 04/07/2014 15:28, Grant Edwards wrote: On 2014-07-03, Emile van Sebille em...@fenx.com wrote: snip Just watch out for mixed tabs and spaces in the same file -- a tab counts as eight spaces and can be used interchangeably in python2. Definitely. Indenting with tabs vs. spaces is mostly personal preference (though spaces are better!). But, mixing the two is right out, and should be stomped on hard. Yet another reason to switch to Python 3. For new projects, sure. But since the v1.5 days I've deployed the current python version a dozen times a year on various one-offs so that I'm sure I've got every python version deployed somewhere, and they just run, so why fix something that works. Or upgrade it when a three line fix addresses the issue. Emile Surely the issue of mixing tabs and spaces is much more important than working systems? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Surely the issue of mixing tabs and spaces is much more important than working systems? :) Python 3 considers tabs as an error and refuses to work. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
In article mailman.11497.1404486912.18130.python-l...@python.org, George Silva georger.si...@gmail.com wrote: Isn't this an old discussion? Just configure your editor properly. In my team we all use spaces, but I'll be damned if I need to type 12 spaces in a row. I'll just configured Sublime to insert spaces instead of tabs. Problem solved. On emacs, I used auto-indent mode. I hit tab, and it automatically inserts the correct number of spaces (where correct is language-specific; for Python, it uses the pep-8 rules). It also does syntax highlighting, parenthesis and quote matching, keyword recognition, etc. I assume any sane editor has similar functionality. I see my coworkers using vim, sublime, eclipse, and X-code. They all appear to do these things, and I would thus classify any of them as sane editors. I'm sure there are others. If the tool you're (in the generic sense of you) using doesn't have this type of basic language support, you should reconsider your choice of tool. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Fri, 04 Jul 2014 09:19:24 -0700, Maciej Dziardziel wrote: Surely the issue of mixing tabs and spaces is much more important than working systems? :) Python 3 considers tabs as an error and refuses to work. Incorrect. [steve@ando ~]$ python3 Python 3.3.0rc3 (default, Sep 27 2012, 18:44:58) [GCC 4.1.2 20080704 (Red Hat 4.1.2-52)] on linux Type help, copyright, credits or license for more information. === startup script executed === py code = ... def func(): ... \treturn 23 ... ... print( func() + 1000 ) ... py py exec(code) 1023 -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
I assume any sane editor has similar functionality. I see my coworkers using vim, sublime, eclipse, and X-code. They all appear to do these things, and I would thus classify any of them as sane editors. I'm sure there are others. If the tool you're (in the generic sense of you) using doesn't have this type of basic language support, you should reconsider your choice of tool Could not agree more :D -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 04/07/14 07:55, Gregory Ewing wrote: Steven D'Aprano wrote: That's exactly the problem with tabs - whatever you think your code looks like with tabs, other people will see quite different picture. Why do you consider this a problem? It's a problem if you try to use tabs for lining things up in a tabular fashion in your source code. The solution is not to use tabs for that -- only use tabs for indentation, and use spaces for everything else. Or, as PEP 8 suggests, don't try to line things up in the first place. PEP8 suggests using this style of method invocation: obj.method(foo, bar, baz) which is an effect impossible to do correctly with tabs alone. If you want to follow this style strictly, you end up having to either mix tabs and spaces, or just use spaces, or as I prefer it, avoid the issue altogether: obj.method( foo, bar, baz, ) -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 4 July 2014 15:54:50 BST, Marko Rauhamaa ma...@pacujo.net wrote: Even if we accepted that to be bad style, there's nothing on the screen that would warn against such usage: the lines seemingly align perfectly, and the code runs as expected. If using vim, set list and listchars, you get to highlight tabs and trailing spaces. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
In article mailman.11507.1404498596.18130.python-l...@python.org, Lie Ryan lie.1...@gmail.com wrote: PEP8 suggests using this style of method invocation: obj.method(foo, bar, baz) which is an effect impossible to do correctly with tabs alone. If course you can do it with tabs. Just make sure all your method names are 7 letters long :-) -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 04/07/2014 20:04, Roy Smith wrote: In article mailman.11507.1404498596.18130.python-l...@python.org, Lie Ryan lie.1...@gmail.com wrote: PEP8 suggests using this style of method invocation: obj.method(foo, bar, baz) which is an effect impossible to do correctly with tabs alone. If course you can do it with tabs. Just make sure all your method names are 7 letters long :-) When the homework gets handed in I guess the lecturer will know who's read this thread :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Lie Ryan wrote: PEP8 suggests using this style of method invocation: obj.method(foo, bar, baz) which is an effect impossible to do correctly with tabs alone. Yes, PEP 8 is self-contradictory in that regard. I also happen to think that recommendation is insane for other reasons as well, and cheerfully ignore it. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Roy Smith wrote: The problem is, tools always get mixed. I use emacs. The next guy uses vi. Somebody else uses Sublime. The list goes on and on. You will never control what tools other people use. Yes, but my point is that none of the tools are broken, they're just incompatible. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 2014-07-05 11:17, Gregory Ewing wrote: PEP8 suggests using this style of method invocation: obj.method(foo, bar, baz) which is an effect impossible to do correctly with tabs alone. Yes, PEP 8 is self-contradictory in that regard. I also happen to think that recommendation is insane for other reasons as well, and cheerfully ignore it. To be fair, in the same section[1] that example is given, it also suggests # More indentation included to distinguish this from the rest. def long_function_name( var_one, var_two, var_three, var_four): print(var_one) # Hanging indents should add a level. foo = long_function_name( var_one, var_two, var_three, var_four) both of which can be done with arbitrary indentation without the need to mix tabs+spaces or use a non-integer multiple of indentation-spaces. I just use these two in all instances and (as you, Greg, advise), cheerfully ignore [the first form] The only time I intentionally violate the don't do these section # Arguments on first line forbidden when not using vertical alignment. foo = long_function_name(var_one, var_two, var_three, var_four) is when defining options in optparse: parser.add_option(-v, --verbose, help=be prolix, action=store_true, dest=verbose, default=False, ) as I find that a little easier to read when I'm scanning large blocks of parser.add_option(...) calls, having the option stick out to the right. -tkc [1] http://legacy.python.org/dev/peps/pep-0008/#indentation -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Thursday, July 3, 2014 12:31:04 PM UTC-5, Tobiah wrote: Coworker takes PEP8 as gospel and uses 4 spaces snip I'm saddened that every one of these little tabs versus spaces arguments revolve more around selfishness and less around an understanding of what a tabs and spaces actually *are*, because, how can you solve a problem when you're unable to understand the fundamental dicotomoy of this relationship between tabs and spaces? I believe the whole issue can be boiled down into: Use the correct tool for the job. And there in lies the rub, before we can make the *choice*, we must comprehend the *differences*. What is a space Duh! What is a tab We all know tabs are used to present text in tabular form (aka: tables), however, tabs are much more than merely a concatenation-of-N-spaces. Not only do tabs allow a user to control alignments via the mechanical process of pressing the tab key, tabs also allow a more powerful and precise hook into the underlying mechinism of vertical alignments via rules defined by the user. AND THIS LAST POINT IS THE TRUE POWER OF TABS! Yes, tabs are an extrapolation of spaces, but they are also more powerful than a space could ever be. If we imagine spaces and backspaces to be like *addtion* and *subtraction*, we can extrapolate that tabs and um, well, backtabs to be like *multiplication* and *division* -- not in a quantitve sense of course, but in an exponentially more powerful sense. Tabs or spaces? And now we must answer the burning question. Not that my habits really matter but I myself use only spaces and NEVER tabs, and i only use four spaces, never more, never less,,, and i don't use spaces because i prefer spaces over tabs, no, i use spaces because spaces are going to render the same in all editors. Strangly, I rather fancy the idea of using tabs in code,,, which allow each viewer to view the code in his or her level of indention,,, however, i cannot justify using a tab as a replacement for a space. Tabs should be used for tabular data (aka: speadsheets), and since code is NOT tabular data, we would be wise to use the space char for indention. from brain import logic -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
[A continuation of my last reply...] Here is a recent situation that occurred to me that showcases the tendency of humans to carelessly bind illogical terms to common objects, thereby creating a inverse esoteric of ubiquitous illogic, in this case, the term: flash-light. Illuminating the illogical: A friend and myself where working outside and as the light began to fade he realized we needed a light source, so he called out: SOMEBODY GET ME A FLASH-LIGHT! As i was heading in to grab a flashlight i realized the bombastic insanity of such a term. Why is a handheld light called a flashlight? It does not flash, in fact, its main purpose is to provide a consistent light source that is easy to carry, whereas flashing would be quite annoying! *And just then that mischievous little inner voice started whispering in my ear, giving me ideas, Muahahah!* So i returned to my friend who was already quite annoyed with his repair project, and started flashing the light on and off. He quickly turned around and demanded: What the hell are you doing?, to which i replied, You asked for a flash-light, yes? Of course everyone knows that a flash light does not flash, so why do we continue to propagate such foolish terms? Well, for the same reason language designers keep giving us illogical terms like function and class, but i digress. The point is we go around the world falsely believing we have a strong grasp of the simple things, when in fact, a whole world of illogic infects our understanding of even the most basic aspects of our lives. Of course, I'm anxiously await my friend to ask for a drop light -- oh boy, that will be fun! :^) -- https://mail.python.org/mailman/listinfo/python-list
PEP8 and 4 spaces
Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. The sole thing you get with spaces as far as I can tell, is that someone loading the code into Notepad will still see a 4 character indent. That may be true, but that same person is going to have a difficult time editing the code. Anyway, I gave up the 80 char line length long ago, having little feeling for some dolt on a Weiss terminal that for some reason needs to edit my code. I feel rather the same about the spaces and tabs, given that most people seem to be using editors these days that are configurable to show tabs a four characters. Any evidence out there that this part of PEP8 is becoming more optional or even obsolete, as I've heard others say about the 80 char line length? Just need ammo for when the hammer of code unification comes down. Thanks, Tobiah -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Fri, Jul 4, 2014 at 3:31 AM, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast rules. 2) Tabs let different people display the indents at different widths. You want it to look like four spaces? No problem. You think it looks better at eight? Fine, set your display to eight. Easy. 3) Perhaps most importantly: You don't have to unify. Let your source control system do the work for you. In git, that's the smudge/clean filters and gitattributes; I don't know the mechanics in hg, but I'm sure it'll exist; in other systems, you might have to rig something up, or dig through the docs. But you should be able to settle on one thing in source control and let everyone check out files in whatever way they like. Personally, I like, use, and recommend, tabs - but the next best thing to tabs is a consistent number of spaces (preferably four). But if you can't make your tools handle the difference, you're going to be putting unnecessary strains on the humans. Let the humans work with whatever they prefer. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
In article mailman.11462.1404408676.18130.python-l...@python.org, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. [...] Just need ammo for when the hammer of code unification comes down. There are so many battles to fight that are worth fighting. This isn't one of them. Just go with pep-8 and move on to solving real problems. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Tobiah wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. The sole thing you get with spaces as far as I can tell, is that someone loading the code into Notepad will still see a 4 character indent. That may be true, but that same person is going to have a difficult time editing the code. Anyway, I gave up the 80 char line length long ago, having little feeling for some dolt on a Weiss terminal that for some reason needs to edit my code. I feel rather the same about the spaces and tabs, given that most people seem to be using editors these days that are configurable to show tabs a four characters. Any evidence out there that this part of PEP8 is becoming more optional or even obsolete, as I've heard others say about the 80 char line length? Just need ammo for when the hammer of code unification comes down. Indentation: more important than what convention is chosen is that a convention is chosen. Relax and follow your collegue's example. As to the line length: how do you manage to exceed the 80-char limit? Deep nesting, long variable names, complex expressions? All of these often make it worthwhile refactoring the code even with a lot of horizonal space left blank on the monitor. Also: you can probably come up with five aspects that affect the quality of your company's code more than the above superficial points and that are hard to fix. So pick your fights and attack the most relevant issue. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 07/03/2014 10:46 AM, Tim Chase wrote: Any evidence out there that this part of PEP8 is becoming more optional or even obsolete, as I've heard others say about the 80 char line length? Just need ammo for when the hammer of code unification comes down. I'm not sure you'll get a whole lot of PEP8 is optional or obsolete, though some may protest the 80-char suggestion. While I prefer tabs for similar reasons you present (I can set them to display at whatever width is comfortable), I have Vim configured to expand tabs into spaces so that my code conforms to standards. If you're really picky about it, just create hooks in your VCS (you ARE using revision control, right?) that turn $STANDARD_NUMBER_OF_SPACES into a tabs at checkout, and then revert tabs back to that number of spaces pre-commit. For git, this SO post covers it: http://stackoverflow.com/questions/2316677/can-git-automatically-switch-between-spaces-and-tabs Very interesting. Yes, we're using Git. Thanks for the suggestion. Tobiah -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Hello, On Fri, 4 Jul 2014 03:38:27 +1000 Chris Angelico ros...@gmail.com wrote: On Fri, Jul 4, 2014 at 3:31 AM, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast rules. 2) Tabs let different people display the indents at different widths. That's exactly the problem with tabs - whatever you think your code looks like with tabs, other people will see quite different picture. Also, most people are not interested in doing mumbo-jumbo with tabs settings, and have them set to standard 8-char tabs. So, any python code which uses only tabs for indentation automatically violates 4-space convention (and mixing tabs and spaces is nowadays prohibited in Python). Summing up: if you care about other human beings, use spaces. If you don't care about other human beings, you may use tabs, but other human beings surely will take how you treat them into account ;-). -- Best regards, Paul mailto:pmis...@gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 2014-07-03, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. The sole thing you get with spaces as far as I can tell, is that someone loading the code into Notepad will still see a 4 character indent. Or any editor at all. That may be true, but that same person is going to have a difficult time editing the code. That's true with Notepad, but with dozens of other programming editors, code indented with spaces will read and edit prefectly. Not so for tab-indented code. Anyway, I gave up the 80 char line length long ago, having little feeling for some dolt Same to you. on a Weiss terminal that for some reason needs to edit my code. I feel rather the same about the spaces and tabs, given that most people seem to be using editors these days that are configurable to show tabs a four characters. Any evidence out there that this part of PEP8 is becoming more optional or even obsolete, as I've heard others say about the 80 char line length? Just need ammo for when the hammer of code unification comes down. Just do the right thing and configure your editor to indent with spaces. -- Grant Edwards grant.b.edwardsYow! Am I SHOPLIFTING? at gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Any evidence out there that this part of PEP8 is becoming more optional or even obsolete, as I've heard others say about the 80 char line length? Just need ammo for when the hammer of code unification comes down. I'm not sure you'll get a whole lot of PEP8 is optional or obsolete, though some may protest the 80-char suggestion. While I prefer tabs for similar reasons you present (I can set them to display at whatever width is comfortable), I have Vim configured to expand tabs into spaces so that my code conforms to standards. If you're really picky about it, just create hooks in your VCS (you ARE using revision control, right?) that turn $STANDARD_NUMBER_OF_SPACES into a tabs at checkout, and then revert tabs back to that number of spaces pre-commit. For git, this SO post covers it: http://stackoverflow.com/questions/2316677/can-git-automatically-switch-between-spaces-and-tabs -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 2014-07-03 19:02, Grant Edwards wrote: That may be true, but that same person is going to have a difficult time editing the code. That's true with Notepad, but with dozens of other programming editors, code indented with spaces will read and edit prefectly. Not so for tab-indented code. A broken editor isn't the world's best argument. If I used an editor that changed my line-endings, randomly altered arbitrary characters, or tried to compress multiple spaces into one, I'd complain that the editor was broken. If a file has tab characters and my editor doesn't let me properly deal with tab characters, then THE EDITOR IS BROKEN. That said, even though I'm -0 on use 4 spaces rather than tabs, I conform to the standard to reduce interop headache even if I'd rather use tabs. -tkc -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 07/03/2014 12:44 PM, Simon Ward wrote: On 3 July 2014 18:31:04 BST, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. This isn't worth arguing about. How point of view changes things. Anyway, I gave up the 80 char line length long ago, having little feeling for some dolt on a Weiss terminal that for some reason needs to edit my code. Putting the code factoring considerations aside, because others have already mentioned them and I'm sure others will, there are some other practical reasons for limiting line width: All that is fine, and makes great sense. I generally write short lines. I know the tricks for splitting otherwise long lines into multiple readable lines. I'm not advocating that we use semicolons and always go past 80 characters. I'm just saying that once in a while it makes sense to me to do it, and I don't lose sleep when it happens. I feel rather the same about the spaces and tabs, given that most people seem to be using editors these days that are configurable to show tabs a four characters. Conversely, those same editors can probably automatically indent and unindent a configurable amount of spaces. If you don't use such an editor, and you really can't tolerate the different style, you can use another tool to reindent your code. It works both ways. I'm using Vim, and it will handle the spaces and give a tab-like experience - not quite as good, but good enough to live with. Either of us could give in. The boss likes tabs, as I do. The coworker really only has PEP8 to point to. There is really nothing good about the space way, other than as I said, Notepad users will see four space indents. Most other users can configure the tabstop as they like *if* tabs are being used. The Notepad users will get by just fine. It could fall either way. I was just trying to nudge it toward mine. Tobiah -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 3 July 2014 18:31:04 BST, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. This isn't worth arguing about. Pick a convention, it's probably going to be a compromise, get used to it. PEP8 is as good a base as any, and is (mostly) directly supported by various syntax checking tools such as flake8 and pylama (which I think both use the pep8 tool underneath), and the modes of various editors. Any good editor will make indentation painless, whichever method you settle on. Anyway, I gave up the 80 char line length long ago, having little feeling for some dolt on a Weiss terminal that for some reason needs to edit my code. Putting the code factoring considerations aside, because others have already mentioned them and I'm sure others will, there are some other practical reasons for limiting line width: I often use multiple editors side-by-side or in split window mode. If I'm limited to one screen I'll probably also have documentation open on that screen. Having to side scroll, or have a single editor take up most of the width of the display forcing switching between windows, seems to me to be more harmful than good for productivity. There is plenty of research on the readability of prose, less so on code, but some of the considerations apply to code too. I'll pick out three of them. The first probably applies less to code (because code is generally line-based and the line widths vary; it's not just a big wall of text): people tend to find it harder to track from one line to the next with longer lines of text. The second has to do with focus: as the reader continues along a line of text their focus dwindles, it seems that starting a new line renews focus. Thirdly, it may seem unintuitive given that we appear to have more capacity for horizontal movement of the eyes, but excessively long lines can cause more work for them potentially inducing eyestrain. We focus near the centre. Our peripheral vision either side is less discerning of details and more on movement (such as an attacker). We must move our eyes to continue reading long lines, and possibly even move our heads. This is a problem for vertical movement too, and happens if lines are too short. (I have no idea how this affects readers of vertical scripts.) I feel rather the same about the spaces and tabs, given that most people seem to be using editors these days that are configurable to show tabs a four characters. Conversely, those same editors can probably automatically indent and unindent a configurable amount of spaces. If you don't use such an editor, and you really can't tolerate the different style, you can use another tool to reindent your code. Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 07/03/2014 12:40 PM, Tim Chase wrote: On 2014-07-03 19:02, Grant Edwards wrote: That may be true, but that same person is going to have a difficult time editing the code. That's true with Notepad, but with dozens of other programming editors, code indented with spaces will read and edit prefectly. Not so for tab-indented code. A broken editor isn't the world's best argument. If I used an editor that changed my line-endings, randomly altered arbitrary characters, or tried to compress multiple spaces into one, I'd complain that the editor was broken. If a file has tab characters and my editor doesn't let me properly deal with tab characters, then THE EDITOR IS BROKEN. That said, even though I'm -0 on use 4 spaces rather than tabs, I conform to the standard to reduce interop headache even if I'd rather use tabs. -tkc I think your suggestion of having GIT handle the transformations is the way we'll go. nothing to quibble or worry about. Well put spaces in the repository since it still seems to be the community's preference and I'll convert to tabs with GIT on the fly. Problem solved. Thanks, Tobiah -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
Anyway, I gave up the 80 char line length long ago, having little feeling for some dolt Same to you. Haha, the language was too strong. The code I'm talking about is only going to be seen by a small group of programmers. The current trio has all been here for over 20 years. I'd be more concerned if the code were ever to be made public. on a Weiss terminal that for some reason needs to edit my code. I feel rather the same about the spaces and tabs, given that most people seem to be using editors these days that are configurable to show tabs a four characters. Any evidence out there that this part of PEP8 is becoming more optional or even obsolete, as I've heard others say about the 80 char line length? Just need ammo for when the hammer of code unification comes down. Just do the right thing and configure your editor to indent with spaces. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On 7/3/2014 2:23 PM, Tobiah wrote: I think your suggestion of having GIT handle the transformations is the way we'll go. nothing to quibble or worry about. Well put spaces in the repository since it still seems to be the community's preference and I'll convert to tabs with GIT on the fly. Problem solved. Just watch out for mixed tabs and spaces in the same file -- a tab counts as eight spaces and can be used interchangeably in python2. Emile -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Thu, 03 Jul 2014 10:31:04 -0700, Tobiah wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. Point out to your boss, and your co-worker, that PEP 8 *explicitly* states that it is not compulsory except for the standard library, and that for third-party and private code, local conventions over-rule PEP 8. In other words, if your co-worker is the only one who uses spaces when everyone else uses tabs, **he is violating PEP 8**. The sole thing you get with spaces as far as I can tell, is that someone loading the code into Notepad will still see a 4 character indent. That may be true, but that same person is going to have a difficult time editing the code. Advantages of spaces: - It's a convention that many people follow. Disadvantages of tabs: - Many standard Unix/Linux/POSIX tools have a hard time dealing with tabs. I call such tools *broken*, and there is a vicious circle going on: programmers use the fact that these tools don't support tabs to justify the use of spaces, and the majority consensus that you should use spaces as justification for not fixing the tools. As I understand it, Unix coders tend to prefer spaces, and Windows users tend to be more comfortable with tabs. This isn't a hard-and-fast rule, you'll find plenty of exceptions, but it seems to me that Unix tools are unforgiving of tabs while Windows IDEs tend to default to tabs. I'm not a Windows person myself, any Windows guys like to comment? Anyway, I gave up the 80 char line length long ago, having little feeling for some dolt on a Weiss terminal that for some reason needs to edit my code. How do you feel about some dolt who aligns two or three editor windows side-by-side so they can compare code? :-) Being able to set code side-by-side, say in a horizontal diff, or two editors next to each other, is a much more important reason to support a 79+1 maximum line width than Weiss terminals. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Fri, Jul 4, 2014 at 11:02 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: As I understand it, Unix coders tend to prefer spaces, and Windows users tend to be more comfortable with tabs. This isn't a hard-and-fast rule, you'll find plenty of exceptions, but it seems to me that Unix tools are unforgiving of tabs while Windows IDEs tend to default to tabs. I'm not a Windows person myself, any Windows guys like to comment? I've worked both platforms extensively, and it's not really as clear-cut as that. Most Unix tools are perfectly happy with tabs, *as long as you let them mean eight spaces*; a lot, but not all, have an option to configure tab width, but you have to specify it to every program separately. On the flip side, tab configurability can be a huge feature. There've been times when I've looked at something with the tab width set to something insane like 7 or 9 (no, folks, I did not say 7 of 9) to highlight a display bug or other oddity. Not often, but it has its uses - and you can't do that if there are actual spaces involved. Anyone who's using a broken editor should fix it or switch editors. That's easy. And if you really love your editor, sometimes you can fix the issue outside it - maybe in a source control hook. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Thu, 03 Jul 2014 21:07:28 +0300, Paul Sokolovsky wrote: Hello, On Fri, 4 Jul 2014 03:38:27 +1000 Chris Angelico ros...@gmail.com wrote: On Fri, Jul 4, 2014 at 3:31 AM, Tobiah tshep...@rcsreg.com wrote: Coworker takes PEP8 as gospel and uses 4 spaces to indent. I prefer tabs. Boss want's us to unify. 1) PEP 8 is meant to be guidelines, *not* a set of hard-and-fast rules. 2) Tabs let different people display the indents at different widths. That's exactly the problem with tabs - whatever you think your code looks like with tabs, other people will see quite different picture. Why do you consider this a problem? The only rational reason I can think of is that you are concerned about line widths. If I write code with tabs set to two spaces, indent five times, and then write 50 characters of code, I'll see a total line width of 60 columns. Somebody who views tabs as four spaces will see a width of 70, and someone else who views them as eight spaces will see a width of 90 columns. So I can see that's somewhat of a problem, but not a huge one. Also, most people are not interested in doing mumbo-jumbo with tabs settings, and have them set to standard 8-char tabs. So, any python code which uses only tabs for indentation automatically violates 4-space convention Mumbo-jumbo? In any decent editor, it's a single setting. In kwrite I go Settings Configure Editor, click the Editing icon, and there's a Tab width field right there. Hardly mumbo-jumbo. In any case, the 4-space convention is just a convention. If you're willing to go against PEP 8 and use tabs, going against PEP 8 and using 8- column tab settings shouldn't worry you. (and mixing tabs and spaces is nowadays prohibited in Python). Yes, that's because the algorithm used by the parser to determine the indentation level may not give the same answer as a human reader, in the presence of mixed tabs and spaces. In any case, in the entire history of the space/tab argument, I'm not aware of a single person who recommended mixed space/tabs for indents. There are two standard solutions for the problem of indenting code, not three: use spaces, or use tabs, but not arbitrarily pick one or the other each time you indent. Summing up: if you care about other human beings, use spaces. If you don't care about other human beings, you may use tabs, but other human beings surely will take how you treat them into account ;-). Ha ha, that's funny, I would have said the opposite: if you care about keeping tools that expect spaces happy, use spaces, if you care about allowing people to configure the look of your code, or poor unfortunates who aren't using a programmer's editor, use tabs. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Fri, Jul 4, 2014 at 11:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Summing up: if you care about other human beings, use spaces. If you don't care about other human beings, you may use tabs, but other human beings surely will take how you treat them into account ;-). Ha ha, that's funny, I would have said the opposite: if you care about keeping tools that expect spaces happy, use spaces, if you care about allowing people to configure the look of your code, or poor unfortunates who aren't using a programmer's editor, use tabs. Right. And hey. If you're a sufficiently competent programmer, you CAN get away with not caring about other human beings: either because you're so utterly valuable that people accept you despite your rough edges... or because you just script away the differences :) Now, if your *boss* doesn't understand about these things, it's possible to lose your job over stupid stuff like style guides. Although to be fair, I'd been planning to quit for a long time, and the style guide was the last in a long line of problems, so when I kicked back and said basically No, your style guide is a bad idea, it ended up with us parting ways. But that's a separate point. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
In article mailman.11478.1404437416.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Fri, Jul 4, 2014 at 11:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Summing up: if you care about other human beings, use spaces. If you don't care about other human beings, you may use tabs, but other human beings surely will take how you treat them into account ;-). Ha ha, that's funny, I would have said the opposite: if you care about keeping tools that expect spaces happy, use spaces, if you care about allowing people to configure the look of your code, or poor unfortunates who aren't using a programmer's editor, use tabs. Right. And hey. If you're a sufficiently competent programmer, you CAN get away with not caring about other human beings: either because you're so utterly valuable that people accept you despite your rough edges... or because you just script away the differences :) Now, if your *boss* doesn't understand about these things, it's possible to lose your job over stupid stuff like style guides. Although to be fair, I'd been planning to quit for a long time, and the style guide was the last in a long line of problems, so when I kicked back and said basically No, your style guide is a bad idea, it ended up with us parting ways. But that's a separate point. ChrisA The way I figure it, there are two things which have sucked up more time, effort, and productivity than anything else. Buffer overrun bugs, and arguments about whitespace (and placement of braces in those sorts of languages). I'm not sure which order they go in. Solving buffer overruns is easy; you use bounds-checked containers, or languages which don't expose raw memory. Killing whitespace arguments seems to be a far more intractable problem. -- https://mail.python.org/mailman/listinfo/python-list
Re: PEP8 and 4 spaces
On Jul 3, 2014 10:31 AM, Tobiah tshep...@rcsreg.com wrote: Just need ammo for when the hammer of code unification comes down. One issue that I've encountered in the past (one of the reasons outside of pep8) that I switched to spaces is when working with libraries other than your own. If you want to stick print statements, breakpoints or make any other modifications to the code you're working with, chances are if you're using tabs in your editor, you're going to run into issues when making those changes. Most (of not all) libraries I've worked with use spaces. Pep8 suggests the use of spaces. New hires who have spent any amount of time in python are /likely/ most used to using spaces. For those reasons I much prefer spaces over tabs. -- https://mail.python.org/mailman/listinfo/python-list
