Re: Tabs for indentation & Spaces for alignment in Python 3?
Michael Torrie : > So obviously your zigzaggy diffs are showing that the person who wrote > the code is *not* using tabs for indent and spaces for alignment. Source code lives easily for ten years or longer. It is touched by numerous people in different groups or even companies under different stylistic preferences. In fact, people rarely have the luxury or inclination to think in terms of style. > Since tabs and spaces are not visibly distinguished, it's not readily > apparent when one is properly using tabs and spaces together, Your "properly" is different from my "properly," I bet. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/06/2014 10:12 AM, Simon Ward wrote: > Not every programmer is as conscientious in the first of place, and > that's far easier to get wrong than just agreeing to stick to one > thing. This is why (often more rigid) style guides (or rather > policies) exist. Sure, but in the world of braces languages, reformatting crappy code is fairly trivial > Maybe we should sack such programmers regardless of their other > abilities instead of forcing all, including the conscientious, > programmers to adhere to strict style policies? While I like the > idea, I think that a slap on the wrist and a bit of > re-indentation/re-alignment is all that is necessary (although I have > worked with people who consider pure style changes to be a sin too). I suppose if an employee continually submits commits that violate the coding standard after being asked time and again to not do that, and is too lazy to run his code through GNU indent probably should be fired. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 6 December 2014 03:04:48 GMT+00:00, Michael Torrie wrote: >On 12/05/2014 07:31 PM, Ned Batchelder wrote: >> This is a perfect example! The code (with tabs as >--- and leading >> spaces as .) is: >> >> >---if (!list_empty(pending)) >> >--->---ret = list_first_entry(pending, struct async_entry, >> >--->--->--->---...domain_list)->cookie; >> >> Now, display it in your editor with tabs set to four spaces: >> >> >---if (!list_empty(pending)) >> >--->---ret = list_first_entry(pending, struct async_entry, >> >--->--->--->---...domain_list)->cookie; > >However, a conscientious programmer knows that tabs could be >arbitrarily >sized, so he would never do that. Instead he would do: > > >---if (!list_empty(pending)) > >--->---ret = list_first_entry(pending, struct async_entry, > >--->---...domain_list)->cookie; > >Which under the heretical tab size of 4: > >---if (!list_empty(pending)) > >--->---ret = list_first_entry(pending, struct async_entry, > >--->---...domain_list)->cookie; Not every programmer is as conscientious in the first of place, and that's far easier to get wrong than just agreeing to stick to one thing. This is why (often more rigid) style guides (or rather policies) exist. Maybe we should sack such programmers regardless of their other abilities instead of forcing all, including the conscientious, programmers to adhere to strict style policies? While I like the idea, I think that a slap on the wrist and a bit of re-indentation/re-alignment is all that is necessary (although I have worked with people who consider pure style changes to be a sin too). Simon -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/06/2014 09:57 AM, Marko Rauhamaa wrote: >> And one of the OP's points is that by using tabs for indent, and >> spaces for alignment, you can have the best of both worlds. > > I certainly doesn't sound that way. Why is that? > >> Programmers can set their tab size to anything they want, and it still >> looks good > > That's anything but true. I see zigzaggy diffs all the time. You're not reading what I'm writing, at least understanding it. The idea behind using tabs for indent and spaces for alignment are clear enough: >--->---blah (one, >--->---..two So obviously your zigzaggy diffs are showing that the person who wrote the code is *not* using tabs for indent and spaces for alignment. Must just be using tabs. Since tabs and spaces are not visibly distinguished, it's not readily apparent when one is properly using tabs and spaces together, and not apparent that your editor is doing it properly, so in Python most people recommend never mixing tabs and spaces, although you *can* do that in the way I've described if you really want to. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
Michael Torrie : > What dilemma? Do you mean you can avoid the drama of tabs by going all > spaces? Of course in Python this is the recommended course. > > But that's typically not what I, or most people, use in C or C++. "Most people"? Hm. I don't know most people. Anyway. Who cares about "most people"? > And one of the OP's points is that by using tabs for indent, and > spaces for alignment, you can have the best of both worlds. I certainly doesn't sound that way. > Programmers can set their tab size to anything they want, and it still > looks good That's anything but true. I see zigzaggy diffs all the time. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On Sun, Dec 7, 2014 at 3:41 AM, Michael Torrie wrote: > What dilemma? Do you mean you can avoid the drama of tabs by going all > spaces? Of course in Python this is the recommended course. Actually it's only one of several recommended courses, but otherwise yes. :) ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/06/2014 01:40 AM, Marko Rauhamaa wrote: > Michael Torrie : > >> In fact a decent editor that is auto-indenting code would, at least in >> C or C++ mode, do that automatically. > > A decent editor frees you from this dilemma entirely: > > (custom-set-variables > '(indent-tabs-mode nil)) What dilemma? Do you mean you can avoid the drama of tabs by going all spaces? Of course in Python this is the recommended course. But that's typically not what I, or most people, use in C or C++. And one of the OP's points is that by using tabs for indent, and spaces for alignment, you can have the best of both worlds. Programmers can set their tab size to anything they want, and it still looks good (except of Linux kernel source code, which only will ever look right at tabs equivalent to 8 spaces). He wanted to know if he could still do that in Python3, and the answer is "yes" although we recommend highly just sticking to pep8 4 space characters per indent and no tabs whatsoever. Of course any validly-formatted Python code (or C code) can be made to look right and work right by running autopep8[1] on it. Just like "indent" can make your C code fit whatever style guide you need. [1] https://pypi.python.org/pypi/autopep8/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
Michael Torrie : > In fact a decent editor that is auto-indenting code would, at least in > C or C++ mode, do that automatically. A decent editor frees you from this dilemma entirely: (custom-set-variables '(indent-tabs-mode nil)) HT belongs together with VT, SOH and ETB. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/05/2014 09:48 PM, Aahan Krish wrote: Hello Ned, I didn't notice that he was using tabs more than as needed for indentation. Guess I trusted the wrong guy. :P Anyway, it's one more thing to keep in mind. G! Several times now you have started a new thread to comment on an existing one. Please use the reply-list feature of your email program or newsgroup reader. New messages are for new threads. And while I'm at it, please use text messages. html messages are wrong here for a number of reasons, even though none of them have apparently affected your recent messages. -- DaveA -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/5/14 10:04 PM, Michael Torrie wrote: On 12/05/2014 07:31 PM, Ned Batchelder wrote: This is a perfect example! The code (with tabs as >--- and leading spaces as .) is: >---if (!list_empty(pending)) >--->---ret = list_first_entry(pending, struct async_entry, >--->--->--->---...domain_list)->cookie; Now, display it in your editor with tabs set to four spaces: >---if (!list_empty(pending)) >--->---ret = list_first_entry(pending, struct async_entry, >--->--->--->---...domain_list)->cookie; However, a conscientious programmer knows that tabs could be arbitrarily sized, so he would never do that. The Linux kernel style guide makes clear: tabs are not arbitrarily sized. In the Linux kernel, they are eight spaces. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/05/2014 07:31 PM, Ned Batchelder wrote: > This is a perfect example! The code (with tabs as >--- and leading > spaces as .) is: > > >---if (!list_empty(pending)) > >--->---ret = list_first_entry(pending, struct async_entry, > >--->--->--->---...domain_list)->cookie; > > Now, display it in your editor with tabs set to four spaces: > > >---if (!list_empty(pending)) > >--->---ret = list_first_entry(pending, struct async_entry, > >--->--->--->---...domain_list)->cookie; However, a conscientious programmer knows that tabs could be arbitrarily sized, so he would never do that. Instead he would do: >---if (!list_empty(pending)) >--->---ret = list_first_entry(pending, struct async_entry, >--->---...domain_list)->cookie; Which under the heretical tab size of 4: >---if (!list_empty(pending)) >--->---ret = list_first_entry(pending, struct async_entry, >--->---...domain_list)->cookie; In fact a decent editor that is auto-indenting code would, at least in C or C++ mode, do that automatically. Maybe I misread, but I would think this is what the OP had in mind. Of course maybe kernel programmers think differently. Ahh well. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
Hello Ned, I didn't notice that he was using tabs more than as needed for indentation. Guess I trusted the wrong guy. :P Anyway, it's one more thing to keep in mind. G! -- Aahan Krish -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/5/14 8:50 PM, Aahan Krish wrote: Hello Ned, I thought that the use of tabs and spaces in the manner I suggested is pretty common. Linux Kernel follows the same technique, for example: https://github.com/torvalds/linux/blob/master/kernel/async.c#L100 This is a perfect example! The code (with tabs as >--- and leading spaces as .) is: >---if (!list_empty(pending)) >--->---ret = list_first_entry(pending, struct async_entry, >--->--->--->---...domain_list)->cookie; Now, display it in your editor with tabs set to four spaces: >---if (!list_empty(pending)) >--->---ret = list_first_entry(pending, struct async_entry, >--->--->--->---...domain_list)->cookie; "domain_list" and "pending" no longer line up, even though the author worked so hard to make the code look nice. In fact, the Linux kernel specifically says that tabs must be eight spaces (https://www.kernel.org/doc/Documentation/CodingStyle): Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. So you've started by trying to use tabs so that people can choose the indentation width they like, and ended up with a strict rule that you cannot change the size of tabs. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
Hello Ned, I thought that the use of tabs and spaces in the manner I suggested is pretty common. Linux Kernel follows the same technique, for example: https://github.com/torvalds/linux/blob/master/kernel/async.c#L100 Of course, I understand the gist of what you are saying—if people don't understand this technique properly and start mixing up tabs and spaces interchangeably or wrongly the code'd get mangled pretty quickly. Thank you for the heads up! Best, Aahan -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 06Dec2014 09:29, Steven D'Aprano wrote: Cameron Simpson wrote: I have spent too much time reading files indented with TABs by people using a different tabwidth to my own, and thus looking aweful on my screen. The original author didn't choose to make it awful, but their tabs rendered in my tab scheme look awful. And doubtless vice versa. The root cause of this is that when we, as humans, indent with tabs, we do it to achieve a certain visual effect; as though a certain number of spaces were in play. How is this different from people who achieve a certain visual effect by indenting with actual spaces? I've seen people indent with 8 spaces. I've seen people indent with 2 spaces. I've even seen people indent with a single space per level. I haven't seen anyone indent with 17 spaces, but I suppose it's only a matter of time... I don't see how reading code indented with tabs configured for 8/4/2/1 spaces is *worse* than reading tab indented with 8/4/2/1 spaces. Because the author will have chosen a scheme not too insane. But when I pull up their indented-with-2-or-4-tab files in my tab==8 editor, it looks terrible. When I pull up their indented-with-spaces in whatever scheme, it looks as good or bad as their judgement, which even when tasteless is usually better than overwide tabs. I would rather not have to readjust my editor's tab spacing every time I load up a file from someone-who-is-not-me. If they use spaces, I don't have to. If they use tabs and do not indent like I do, I have to to keep things readable. Cheers, Cameron Simpson They shouldn't get any new nuclear weapons until they've used the ones they've got.- Murff -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On Fri, Dec 5, 2014 at 11:49 AM, Aahan Krish wrote: > > Hello Ian, > > So, wrt Q2, what you are saying is, the following would cause issues in Python 3? > > int f(int x, > ..int y) { > --->return g(x, > --->.y); > } > > Where: > > ---> for tabs (used for indentation) > for spaces (used for alignment) That example should be fine, I think (if it were actually Python and not C, that is). The second line is a continuation of the first line, so the preceding whitespace isn't indentation and doesn't matter. Likewise for the fourth line. So the only line with any actual indentation there is the third line. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
Cameron Simpson wrote: > I have spent too much time reading files indented > with TABs by people using a different tabwidth to my own, and thus looking > aweful on my screen. The original author didn't choose to make it awful, > but their tabs rendered in my tab scheme look awful. And doubtless vice > versa. The root cause of this is that when we, as humans, indent with > tabs, we do it to achieve a certain visual effect; as though a certain > number of spaces were in play. How is this different from people who achieve a certain visual effect by indenting with actual spaces? I've seen people indent with 8 spaces. I've seen people indent with 2 spaces. I've even seen people indent with a single space per level. I haven't seen anyone indent with 17 spaces, but I suppose it's only a matter of time... I don't see how reading code indented with tabs configured for 8/4/2/1 spaces is *worse* than reading tab indented with 8/4/2/1 spaces. -- Steven -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/5/14 1:49 PM, Aahan Krish wrote: Hello Ian, So, wrt Q2, what you are saying is, the following would cause issues in Python 3? int f(int x, ..int y) { --->return g(x, --->.y); } Where: ---> for tabs (used for indentation) for spaces (used for alignment) (Aside from the fact that that isn't Python syntax *at all*), Python 3 would be OK with that indentation. It wouldn't be OK with mixed tabs and spaces where the meaning depends on the indent width of a tab, but here it does not. I sincerely hope no one is seriously considering trying to maintain code using a mix of tabs and spaces like that. That's a nightmare. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 12/5/14 12:40 PM, Aahan Krish wrote: I have two general questions regarding Python that I couldn't find any good answers for. This is not the often-asked Tabs vs Spaces question, so kindly read it in whole. *Q1.* This is not to debate the decision, but I really wanted to know the reason why PEP 8 chose to go with spaces instead of tabs. I read that tabs were initially preferred over spaces (esp. Mr. Rossum)? What caused the decision that spaces are better? According to Core Python Programming (Book): ...because tabs vary in the number of spaces depending on your system, we recommend not using tabs if there is any hint of cross-platform development. Isn't that a feature of tabs? (i.e. allowing the user to configure the size of a tab stop in his editor, which has no affect whatsoever on the tab character itself or how it displays in another user's editor.) But you can't configure the width of tabs in all the places you look at code (printing, online repos, diff viewers, etc, etc). Others have mentioned the awkward nature of over-indented continuation lines. My feeling is that if you are working with others who feel strongly enough about differing indent widths that they need to use tabs so they can each have their own way, then you probably have bigger collaboration issues. Use four spaces, and be done with it. Agree with your team members on how your code will look, then innovate on the important things. -- Ned Batchelder, http://nedbatchelder.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On 05Dec2014 17:40, Aahan Krish wrote: *Q1.* This is not to debate the decision, but I really wanted to know the reason why PEP 8 chose to go with spaces instead of tabs. I read that tabs were initially preferred over spaces (esp. Mr. Rossum)? What caused the decision that spaces are better? Essentially because the space is always the same. According to Core Python Programming (Book): ...because tabs vary in the number of spaces depending on your system, we recommend not using tabs if there is any hint of cross-platform development. Isn't that a feature of tabs? (i.e. allowing the user to configure the size of a tab stop in his editor, which has no affect whatsoever on the tab character itself or how it displays in another user's editor.) Yes, but in practice it causes varying degrees of pain. Ideally, the various pieces of code have differing indents and that would be specified entirely with tabs. In practice, (1) people mix them and (2) people make other formatting decisions based on the rendering width of tabs in whatever editor they're using at the time, particularly with multiline strings such as docstrings. There are two common approaches to TABs: the purists who uses TABs entirely so that other users can align the code as they see fit, and the pragmatists who configure their editors to accept the TAB _keystroke_ and have it insert spaces according to their tab convention. I'm in the latter category; I have spent too much time reading files indented with TABs by people using a different tabwidth to my own, and thus looking aweful on my screen. The original author didn't choose to make it awful, but their tabs rendered in my tab scheme look awful. And doubtless vice versa. The root cause of this is that when we, as humans, indent with tabs, we do it to achieve a certain visual effect; as though a certain number of spaces were in play. So my editor is configured to accept the tab key for convenience of typing, but to insert spaces. Cheers, Cameron Simpson In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt.- Blair P. Houghton -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On Sat, Dec 6, 2014 at 4:40 AM, Aahan Krish wrote: > I have two general questions regarding Python that I couldn't find any good > answers for. This is not the often-asked Tabs vs Spaces question, so kindly > read it in whole. > > Q1. This is not to debate the decision, but I really wanted to know the > reason why PEP 8 chose to go with spaces instead of tabs. I read that tabs > were initially preferred over spaces (esp. Mr. Rossum)? What caused the > decision that spaces are better? The decisions in PEP 8 govern the Python standard library *only*. For any other project, you're free to say "We'll follow PEP 8 but using tabs for indentation" or "We'll follow PEP 8 but use three spaces for indentation". (Yes, you're free to be utterly insane.) Personally, I prefer and recommend tabs for indentation. That way, if there's any argument about how wide indents ought to be, the belligerents can simply reconfigure them. But ultimately, there's very little difference between "use tabs" and "use four spaces" and "use eight spaces" and "use two spaces" (though I'd put them in that order); the most important thing is to choose *something* and stick with it. Oh, and get yourself an editor that tells you when you've mucked them up. SciTE does; a little blue line fills the indent if it's wrong compared to the previous one. I work with a lot of students who use Sublime, have it set to show tabs as four spaces wide, and then have no idea why their code isn't working. Hmm. I guess "alias python='python -tt'" would be a good thing, here. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On Friday, December 5, 2014 9:47:10 AM UTC-8, Aahan Krish wrote: > I have two general questions regarding Python that I couldn't find any good > answers for. This is not the often-asked Tabs vs Spaces question, so kindly > read it in whole. > > Q1. This is not to debate the decision, but I really wanted to know the > reason why PEP 8 chose to go with spaces instead of tabs. I read that tabs > were initially preferred over spaces (esp. Mr. Rossum)? What caused the > decision that spaces are better? > > According to Core Python Programming (Book): > > ...because tabs vary in the number of spaces depending on your system, we > recommend not using tabs if there is any hint of cross-platform development. > > Isn't that a feature of tabs? (i.e. allowing the user to configure the size > of a tab stop in his editor, which has no affect whatsoever on the tab > character itself or how it displays in another user's editor.) > > Is it the difficulty to adhere to the Maximum Line Length (79) when using > tabs? or is it simply because most of the Python programmers were using > spaces (or were adamant on using them) at the time of the decision-making > process? > The problem comes when people use tabs for aligning code when a single statement spans multiple lines. For example let's say your tabs are 4 spaces, and you have this block of code: if someCondition: someVariable = someFunction(parameter1, parameter2, parameter3, parameter4, parameter5) If you align the third line (the one with parameter4 and parameter5) with more than 1 tab, then someone with their tab size set to something other than 4 spaces won't see the aligned code. Of course, the correct solution *IF YOU ARE USING TABS FOR INDENTATION* is to indent that third line with a SINGLE tab, then use a bunch of spaces to align the code. This way, even if someone else has their tab size set to 8 spaces, they still see aligned code. So using spaces instead of tabs is a way of preventing the code aligning issue. The downside, of course, is that it forces everyone to use the same number of spaces for indentation, which results in a different argument of how many spaces should be used, which of course is a different discussion entirely, another dead horse to beat. It of course is worth mentioning at this point that any editor that is worth using can be configured to insert spaces when you press the TAB key, and the number of spaces being configurable. So even if you're using spaces, you can still use the TAB key. Even the 'nano' editor for *nix can do this. I frequently see a lot of beginner programmers using the argument that hitting the space bar 4-8 times (Depending on agreed tab size) is wasteful as an argument for tabs. -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
Hello Ian, So, wrt Q2, what you are saying is, the following would cause issues in Python 3? int f(int x, ..int y) { --->return g(x, --->.y); } Where: ---> for tabs (used for indentation) for spaces (used for alignment) Best Aahan -- https://mail.python.org/mailman/listinfo/python-list
Re: Tabs for indentation & Spaces for alignment in Python 3?
On Fri, Dec 5, 2014 at 10:40 AM, Aahan Krish wrote: > Q2. PEP 8 also reads, "Python 3 disallows mixing the use of tabs and spaces for indentation." > > So, if I am using tabs for indentation and spaces for alignment, is it still considered "mixing the use of tabs and spaces" in Python 3? (Please see this example.) No, you can mix tabs and spaces as long as you do so consistently within a block, i.e. if one line is indented with then the next line in the same block had better start with that same exact sequence. The difference is that Python 2 when trying to compare indentation will treat a tab as equal to 8 spaces (or was it 4?) which can lead to situations where the relative indentation of two lines looks one way to the programmer but is lexed a different way by the interpreter. Python 3 resists the temptation to guess in this situation and simply raises an error. -- https://mail.python.org/mailman/listinfo/python-list