Re: I hate you all
On 08/04/2013 23:51, Walter Hurry wrote: On Tue, 09 Apr 2013 08:00:06 +1000, Chris Angelico wrote: On Tue, Apr 9, 2013 at 7:29 AM, Grant Edwards invalid@invalid.invalid wrote: On 2013-04-08, Walter Hurry walterhu...@lavabit.com wrote: The fact of Python enforcing it (or all tabs; a poor second choice) is *a good thing*, easy and natural IMHO. No need for end if or end loop or fi. One wonders whether OP is simply trolling. If he was trolling, he certainly deserves a prize. I don't think he was trolling. It was a classic-model rant: I upgraded my dependency to a newer version and all my stuff broke. Commonly provokes anger, largely because many such upgrades do NOT break stuff (eg if I were to switch from gcc 4.5 to gcc 4.7 right now, I doubt anything would break, and my code would be able to use the new iterator syntax in c++11 - pity 4.7 isn't packaged for Debian Squeeze). The OP upgraded across an openly-non-backward-compatible boundary, and got angry over one particular aspect of backward compat that wasn't there. But wouldn't it have been easier simply to do do a quick sed or whatever rather than to spend hours here arguing? Where's the fun in that? :) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-09, Mark Lawrence breamore...@yahoo.co.uk wrote: But wouldn't it have been easier simply to do do a quick sed or whatever rather than to spend hours here arguing? Where's the fun in that? :) What, you don't think sed is fun? -- Grant Edwards grant.b.edwardsYow! Did I say I was at a sardine? Or a bus??? gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-09 13:39, Grant Edwards wrote:
On 2013-04-09, Mark Lawrence breamore...@yahoo.co.uk wrote:
But wouldn't it have been easier simply to do do a quick sed or
whatever rather than to spend hours here arguing?
Where's the fun in that? :)
What, you don't think sed is fun?
--
Grant Edwards grant.b.edwardsYow! Did I say I
was at a sardine? Or a bus???
gmail.com
| sed -e '/What.*n.t/{s//Sure I/;s/?/!/};/^-- /{r .signature' -e'q}'
:-)
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Wed, Apr 10, 2013 at 12:17 AM, Tim Chase
python.l...@tim.thechases.com wrote:
| sed -e '/What.*n.t/{s//Sure I/;s/?/!/};/^-- /{r .signature' -e'q}'
A very apt response. Oh wait, I already have sed on this system, don't
need to fire up apt.
ChrisA
--
http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 09/04/2013 14:39, Grant Edwards wrote: On 2013-04-09, Mark Lawrence breamore...@yahoo.co.uk wrote: But wouldn't it have been easier simply to do do a quick sed or whatever rather than to spend hours here arguing? Where's the fun in that? :) What, you don't think sed is fun? Having never really used a *nix box in anger how would I know? A substantial portion of my career was spent on a combination of VMS, C with embedded SQL and Ingres. Please don't ask as I don't know the answer :) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Tue, 09 Apr 2013 16:51:26 +0100, Mark Lawrence wrote: On 09/04/2013 14:39, Grant Edwards wrote: On 2013-04-09, Mark Lawrence breamore...@yahoo.co.uk wrote: But wouldn't it have been easier simply to do do a quick sed or whatever rather than to spend hours here arguing? Where's the fun in that? :) What, you don't think sed is fun? Having never really used a *nix box in anger how would I know? A substantial portion of my career was spent on a combination of VMS, C with embedded SQL and Ingres. Please don't ask as I don't know the answer :) Anti-virus, anti-malware, defragmenters, registry cleaners, needing to reboot every time I install or update software? No grep, no awk, no sed? No thanks. But never mind; each to his own. I don't want to spark OS wars. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-09, Mark Lawrence breamore...@yahoo.co.uk wrote: On 09/04/2013 14:39, Grant Edwards wrote: On 2013-04-09, Mark Lawrence breamore...@yahoo.co.uk wrote: But wouldn't it have been easier simply to do do a quick sed or whatever rather than to spend hours here arguing? Where's the fun in that? :) What, you don't think sed is fun? Having never really used a *nix box in anger how would I know? A substantial portion of my career was spent on a combination of VMS, That's no excuse -- DECShell for VMS included sed! :) I spent many months months writing a set of shell-scripts and makefiles that used awk, sed, and their brethren to do automated testing and building of an 1100 page document that was written in LaTeX. It was all on a VMS system. Unfortunately, the massive process-creation overhead of VMS hit shell-scripts pretty hard -- a full VV run and document build took something like 7 hours. We usually only ran it overnight. C with embedded SQL and Ingres. Please don't ask as I don't know the answer :) -- Grant Edwards grant.b.edwardsYow! FROZEN ENTREES may at be flung by members of gmail.comopposing SWANSON SECTS ... -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 09/04/2013 22:09, Walter Hurry wrote: On Tue, 09 Apr 2013 16:51:26 +0100, Mark Lawrence wrote: Having never really used a *nix box in anger how would I know? A substantial portion of my career was spent on a combination of VMS, C with embedded SQL and Ingres. Please don't ask as I don't know the answer :) Anti-virus, anti-malware, defragmenters, registry cleaners, needing to reboot every time I install or update software? No grep, no awk, no sed? No thanks. But never mind; each to his own. I don't want to spark OS wars. I haven't the faintest idea what your response means so please explainn. -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Tue, 09 Apr 2013 23:09:19 +0100, Mark Lawrence wrote: On 09/04/2013 22:09, Walter Hurry wrote: On Tue, 09 Apr 2013 16:51:26 +0100, Mark Lawrence wrote: Having never really used a *nix box in anger how would I know? A substantial portion of my career was spent on a combination of VMS, C with embedded SQL and Ingres. Please don't ask as I don't know the answer :) Anti-virus, anti-malware, defragmenters, registry cleaners, needing to reboot every time I install or update software? No grep, no awk, no sed? No thanks. But never mind; each to his own. I don't want to spark OS wars. I haven't the faintest idea what your response means so please explainn. Walter is pointing out that as a Windows user, you probably have to deal with problems that Unix users are barely even aware of, like viruses, the registry, having to reboot after installing software, etc., and you are missing out on oodles of useful and powerful tools like grep. He finds your decision to use Windows curious, but respects your decision to use it and doesn't want to get into an unproductive war over which is the best OS. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Wed, Apr 10, 2013 at 9:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Walter is pointing out that as a Windows user... Walter is also assuming that Mark is a Windows user, which was never actually stated :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 10/04/2013 00:21, Steven D'Aprano wrote: On Tue, 09 Apr 2013 23:09:19 +0100, Mark Lawrence wrote: On 09/04/2013 22:09, Walter Hurry wrote: On Tue, 09 Apr 2013 16:51:26 +0100, Mark Lawrence wrote: Having never really used a *nix box in anger how would I know? A substantial portion of my career was spent on a combination of VMS, C with embedded SQL and Ingres. Please don't ask as I don't know the answer :) Anti-virus, anti-malware, defragmenters, registry cleaners, needing to reboot every time I install or update software? No grep, no awk, no sed? No thanks. But never mind; each to his own. I don't want to spark OS wars. I haven't the faintest idea what your response means so please explainn. Walter is pointing out that as a Windows user, you probably have to deal with problems that Unix users are barely even aware of, like viruses, the registry, having to reboot after installing software, etc., and you are missing out on oodles of useful and powerful tools like grep. He finds your decision to use Windows curious, but respects your decision to use it and doesn't want to get into an unproductive war over which is the best OS. How did VMS get translated into Windows? :) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 10/04/2013 00:28, Chris Angelico wrote: On Wed, Apr 10, 2013 at 9:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Walter is pointing out that as a Windows user... Walter is also assuming that Mark is a Windows user, which was never actually stated :) ChrisA Another unicode error with VMS being transposed to Windows? :) -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Wed, 10 Apr 2013 09:28:26 +1000, Chris Angelico wrote: On Wed, Apr 10, 2013 at 9:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Walter is pointing out that as a Windows user... Walter is also assuming that Mark is a Windows user, which was never actually stated :) From Mark's reply to me: User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Wed, Apr 10, 2013 at 9:50 AM, Walter Hurry walterhu...@lavabit.com wrote: On Wed, 10 Apr 2013 09:28:26 +1000, Chris Angelico wrote: On Wed, Apr 10, 2013 at 9:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Walter is pointing out that as a Windows user... Walter is also assuming that Mark is a Windows user, which was never actually stated :) From Mark's reply to me: User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 My headers say I use Windows, too, but I actually use Linux. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Wed, 10 Apr 2013 10:31:44 +1000, Chris Angelico wrote: On Wed, Apr 10, 2013 at 9:50 AM, Walter Hurry walterhu...@lavabit.com wrote: On Wed, 10 Apr 2013 09:28:26 +1000, Chris Angelico wrote: On Wed, Apr 10, 2013 at 9:21 AM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Walter is pointing out that as a Windows user... Walter is also assuming that Mark is a Windows user, which was never actually stated :) From Mark's reply to me: User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 My headers say I use Windows, too, but I actually use Linux. Actually, no they don't. They don't say anything about your OS, and there is no User-Agent string. Since Mark claims to have not seriously used Unix, that rules out Linux, FreeBSD, OpenBSD, and modern Apple Mac. It's just barely possible that he's still using VMS or Hurd, but really, by a process of elimination the most likely answer is that he's using Windows. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Wed, Apr 10, 2013 at 12:00 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Wed, 10 Apr 2013 10:31:44 +1000, Chris Angelico wrote: On Wed, Apr 10, 2013 at 9:50 AM, Walter Hurry walterhu...@lavabit.com wrote: From Mark's reply to me: User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 My headers say I use Windows, too, but I actually use Linux. Actually, no they don't. They don't say anything about your OS, and there is no User-Agent string. Since Mark claims to have not seriously used Unix, that rules out Linux, FreeBSD, OpenBSD, and modern Apple Mac. It's just barely possible that he's still using VMS or Hurd, but really, by a process of elimination the most likely answer is that he's using Windows. Heh, I didn't actually check. But if my user-agent _were_ being recorded anywhere, it would make it seem that I use Windows. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sun, 07 Apr 2013 01:30:45 +, Steven D'Aprano wrote: Am I the only one here who has used a typewriter? Tab stops were set manually, to a physical distance into the page, using a mechanical stop. This long predates the rule that tab stops are every 8 characters. And your point is? Typewriters don't have a tab character. The information regarding tab stops is conveyed out-of-band from the typist to the typewriter, and doesn't need to persist beyond the time taken to type the document. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-08, Nobody nob...@nowhere.com wrote: On Sun, 07 Apr 2013 01:30:45 +, Steven D'Aprano wrote: Am I the only one here who has used a typewriter? Tab stops were set manually, to a physical distance into the page, using a mechanical stop. This long predates the rule that tab stops are every 8 characters. And your point is? The point is that there is little historical precedent for assuming that tab stops are evenly and equally spaced across the page (let alone one particular fixed, even spacing) -- and people who mix spaces and tabs based on such false assumptions are responsible for their own bleeding foot. Typewriters don't have a tab character. The information regarding tab stops is conveyed out-of-band from the typist to the typewriter, and doesn't need to persist beyond the time taken to type the document. And the same is true when you don't mix tabs and spaces when indenting Python code. If you use tabs alone when indenting Python code it doesn't matter where the tabs are set -- they don't even have to be equally spaced -- the meaning of the source file is unambiguous. If you mix tabs and spaces, then you've got to provide out-of-band information regarding the position of the tab stops in order to make the source code unambiguous. Since there's no mechanism to provide that OOB tab stop info, mixed tabs and spaces isn't accepted. -- Grant Edwards grant.b.edwardsYow! I am covered with at pure vegetable oil and I am gmail.comwriting a best seller! -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-08, Walter Hurry walterhu...@lavabit.com wrote: Personally I have always used 4 spaces. I use it in SQL, shell scripts and Python. It makes code simple to read, and unambiguous. Same here -- mostly because that's what the emacs Python-mode does by default, and it seems to be commonly accepted right way. All things being equal, I'd pobably pick 2 or 3, but 4 is fine. The fact of Python enforcing it (or all tabs; a poor second choice) is *a good thing*, easy and natural IMHO. No need for end if or end loop or fi. One wonders whether OP is simply trolling. If he was trolling, he certainly deserves a prize. -- Grant Edwards grant.b.edwardsYow! Here we are in America at ... when do we collect gmail.comunemployment? -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Mon, 08 Apr 2013 19:48:58 +, Grant Edwards wrote: On 2013-04-08, Nobody nob...@nowhere.com wrote: On Sun, 07 Apr 2013 01:30:45 +, Steven D'Aprano wrote: Am I the only one here who has used a typewriter? Tab stops were set manually, to a physical distance into the page, using a mechanical stop. This long predates the rule that tab stops are every 8 characters. And your point is? The point is that there is little historical precedent for assuming that tab stops are evenly and equally spaced across the page (let alone one particular fixed, even spacing) -- and people who mix spaces and tabs based on such false assumptions are responsible for their own bleeding foot. Typewriters don't have a tab character. The information regarding tab stops is conveyed out-of-band from the typist to the typewriter, and doesn't need to persist beyond the time taken to type the document. And the same is true when you don't mix tabs and spaces when indenting Python code. If you use tabs alone when indenting Python code it doesn't matter where the tabs are set -- they don't even have to be equally spaced -- the meaning of the source file is unambiguous. If you mix tabs and spaces, then you've got to provide out-of-band information regarding the position of the tab stops in order to make the source code unambiguous. Since there's no mechanism to provide that OOB tab stop info, mixed tabs and spaces isn't accepted. Personally I have always used 4 spaces. I use it in SQL, shell scripts and Python. It makes code simple to read, and unambiguous. The fact of Python enforcing it (or all tabs; a poor second choice) is *a good thing*, easy and natural IMHO. No need for end if or end loop or fi. One wonders whether OP is simply trolling. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Tue, Apr 9, 2013 at 7:29 AM, Grant Edwards invalid@invalid.invalid wrote: On 2013-04-08, Walter Hurry walterhu...@lavabit.com wrote: The fact of Python enforcing it (or all tabs; a poor second choice) is *a good thing*, easy and natural IMHO. No need for end if or end loop or fi. One wonders whether OP is simply trolling. If he was trolling, he certainly deserves a prize. I don't think he was trolling. It was a classic-model rant: I upgraded my dependency to a newer version and all my stuff broke. Commonly provokes anger, largely because many such upgrades do NOT break stuff (eg if I were to switch from gcc 4.5 to gcc 4.7 right now, I doubt anything would break, and my code would be able to use the new iterator syntax in c++11 - pity 4.7 isn't packaged for Debian Squeeze). The OP upgraded across an openly-non-backward-compatible boundary, and got angry over one particular aspect of backward compat that wasn't there. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Tue, 09 Apr 2013 08:00:06 +1000, Chris Angelico wrote: On Tue, Apr 9, 2013 at 7:29 AM, Grant Edwards invalid@invalid.invalid wrote: On 2013-04-08, Walter Hurry walterhu...@lavabit.com wrote: The fact of Python enforcing it (or all tabs; a poor second choice) is *a good thing*, easy and natural IMHO. No need for end if or end loop or fi. One wonders whether OP is simply trolling. If he was trolling, he certainly deserves a prize. I don't think he was trolling. It was a classic-model rant: I upgraded my dependency to a newer version and all my stuff broke. Commonly provokes anger, largely because many such upgrades do NOT break stuff (eg if I were to switch from gcc 4.5 to gcc 4.7 right now, I doubt anything would break, and my code would be able to use the new iterator syntax in c++11 - pity 4.7 isn't packaged for Debian Squeeze). The OP upgraded across an openly-non-backward-compatible boundary, and got angry over one particular aspect of backward compat that wasn't there. But wouldn't it have been easier simply to do do a quick sed or whatever rather than to spend hours here arguing? -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Tue, Apr 9, 2013 at 8:51 AM, Walter Hurry walterhu...@lavabit.com wrote: On Tue, 09 Apr 2013 08:00:06 +1000, Chris Angelico wrote: On Tue, Apr 9, 2013 at 7:29 AM, Grant Edwards invalid@invalid.invalid wrote: On 2013-04-08, Walter Hurry walterhu...@lavabit.com wrote: The fact of Python enforcing it (or all tabs; a poor second choice) is *a good thing*, easy and natural IMHO. No need for end if or end loop or fi. One wonders whether OP is simply trolling. If he was trolling, he certainly deserves a prize. I don't think he was trolling. It was a classic-model rant: I upgraded my dependency to a newer version and all my stuff broke. Commonly provokes anger, largely because many such upgrades do NOT break stuff (eg if I were to switch from gcc 4.5 to gcc 4.7 right now, I doubt anything would break, and my code would be able to use the new iterator syntax in c++11 - pity 4.7 isn't packaged for Debian Squeeze). The OP upgraded across an openly-non-backward-compatible boundary, and got angry over one particular aspect of backward compat that wasn't there. But wouldn't it have been easier simply to do do a quick sed or whatever rather than to spend hours here arguing? Probably. I don't profess to understand the OP's brain *that* much! ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Mon, 08 Apr 2013 19:43:51 +0100, Nobody wrote: On Sun, 07 Apr 2013 01:30:45 +, Steven D'Aprano wrote: Am I the only one here who has used a typewriter? Tab stops were set manually, to a physical distance into the page, using a mechanical stop. This long predates the rule that tab stops are every 8 characters. And your point is? Typewriters don't have a tab character. The information regarding tab stops is conveyed out-of-band from the typist to the typewriter, and doesn't need to persist beyond the time taken to type the document. Both text editors and typewriters encode information about tab settings out of band. Editors encode that information in some combination of program configuration, command-line switches, environment variables, and embedded mode lines in the document itself. Typewriters encode that information in the typists' memory, or failing that, in the actual physical space left on the page. That's a difference that makes no difference. My point is that there were well-established semantics for what a tab should do, and the 8 character tab is not that. Pressing the tab key on a keyboard while entering text ought to instruct the editor to advance to a specified tab stop capable of being set anywhere on the page. Word processors use that model: the word processor stores the positions of the tab stops out of band, usually in the paragraph formatting or style sheet, but in principle they could keep the position of the tab stops global to the document or even global to the application. Good text editors also support this model. Some versions of Vim, for example, include a feature called variable tabstops. Emacs includes a variable called tab-stop-list which can set variable tab stops[1]. Even the Linux command less supports variable width tabs, with the -x option. In case you think this is only for Unix editors, the Windows Boxer Text Editor also supports variable tab stops. There may, or may not be, good reasons for an eight character default setting for tab stops. But eight characters is not, and never has been, the One True Way of setting tab stops. [1] Although what happens when you press the tab key in Emacs is so complicated that only three people in the world have ever understood it fully. The first is Richard Stallman, then second is dead, and the third has gone mad. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Apr 9, 7:51 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 08 Apr 2013 19:43:51 +0100, Nobody wrote: On Sun, 07 Apr 2013 01:30:45 +, Steven D'Aprano wrote: Am I the only one here who has used a typewriter? Tab stops were set manually, to a physical distance into the page, using a mechanical stop. This long predates the rule that tab stops are every 8 characters. And your point is? Typewriters don't have a tab character. The information regarding tab stops is conveyed out-of-band from the typist to the typewriter, and doesn't need to persist beyond the time taken to type the document. Both text editors and typewriters encode information about tab settings out of band. Editors encode that information in some combination of program configuration, command-line switches, environment variables, and embedded mode lines in the document itself. Typewriters encode that information in the typists' memory, or failing that, in the actual physical space left on the page. That's a difference that makes no difference. My point is that there were well-established semantics for what a tab should do, and the 8 character tab is not that. Pressing the tab key on a keyboard while entering text ought to instruct the editor to advance to a specified tab stop capable of being set anywhere on the page. Word processors use that model: the word processor stores the positions of the tab stops out of band, usually in the paragraph formatting or style sheet, but in principle they could keep the position of the tab stops global to the document or even global to the application. Dunno what you mean by 'out-of-band' If I set tabstops for a para to say 4-13-25-36 in a wordprocessor, save the file and look inside, I will find the tuple (4,13,25,36) in some encoded form. For a typewritten page, if the margin seems to be at 11th col, the reader cannot know from the page alone whether the typist 1. set the tab at 11 2. set the tab at 8 and pressed TAB followed by 3 SPC 3. Started with 2 and switched to 1 -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Apr 9, 9:06 am, rusi rustompm...@gmail.com wrote: Dunno what you mean by 'out-of-band' If I set tabstops for a para to say 4-13-25-36 in a wordprocessor, save the file and look inside, I will find the tuple (4,13,25,36) in some encoded form. To make this conform to current practices, I should use some length- unit not characters which I had in mind. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Mon, 08 Apr 2013 21:06:42 -0700, rusi wrote: On Apr 9, 7:51 am, Steven D'Aprano steve +comp.lang.pyt...@pearwood.info wrote: On Mon, 08 Apr 2013 19:43:51 +0100, Nobody wrote: On Sun, 07 Apr 2013 01:30:45 +, Steven D'Aprano wrote: Am I the only one here who has used a typewriter? Tab stops were set manually, to a physical distance into the page, using a mechanical stop. This long predates the rule that tab stops are every 8 characters. And your point is? Typewriters don't have a tab character. The information regarding tab stops is conveyed out-of-band from the typist to the typewriter, and doesn't need to persist beyond the time taken to type the document. Both text editors and typewriters encode information about tab settings out of band. Editors encode that information in some combination of program configuration, command-line switches, environment variables, and embedded mode lines in the document itself. Typewriters encode that information in the typists' memory, or failing that, in the actual physical space left on the page. That's a difference that makes no difference. My point is that there were well-established semantics for what a tab should do, and the 8 character tab is not that. Pressing the tab key on a keyboard while entering text ought to instruct the editor to advance to a specified tab stop capable of being set anywhere on the page. Word processors use that model: the word processor stores the positions of the tab stops out of band, usually in the paragraph formatting or style sheet, but in principle they could keep the position of the tab stops global to the document or even global to the application. Dunno what you mean by 'out-of-band' I mean that the information about the tab stops are not inherent to the tab itself. If I set tabstops for a para to say 4-13-25-36 in a wordprocessor, save the file and look inside, I will find the tuple (4,13,25,36) in some encoded form. There's nothing about the *tab character itself* that says jump to column 25. That information is metadata, stored external to the tab. That doesn't necessarily mean external to the file. A word-processing file carries a lot of metadata about the document. A plain text file is a better example. If I type up a document in (say) OpenOffice and use tabs to align a table, I might manually set the tabs to 4cm, 9cm, 18cm. When I hit tab, the cursor will jump to (say) 18cm, but if I save the document as plain text, that information is not stored anywhere in the document. It may be encoded in the OpenOffice config, e.g. in the Normal stylesheet. The same applies for documents created in a text editor, say Vim or Emacs. They may store the metadata about tab settings as mode lines in the document, or in an environment variable, or in a config file, or perhaps nowhere at all. Just like a typewriter. For a typewritten page, if the margin seems to be at 11th col, the reader cannot know from the page alone whether the typist 1. set the tab at 11 2. set the tab at 8 and pressed TAB followed by 3 SPC 3. Started with 2 and switched to 1 Very true. Manual typewriters are not identical to text editors. Typewriters can do both more *and* less than text editors. E.g. you can compose extra symbols by backspacing and overtyping, but you cannot usually distinguish between space-tab and space-space-tab. But from the perspective of duplicate what you see on the page, the difference between space-tab and space-space-tab does not matter. What matters is where you end up, not how you get there. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 23:17, Larry Hudson wrote: [...] What you want and what you think are irrelevant. The Python language (whatever version) is already defined. If you want to use it, you have to accept it and adapt to what it is. Live with it and move on. Complaining about it is a complete waste of time -- it's NOT going to change just because YOU don't like it. Adding an option for fixed size tabs will not change the language (and someone even suggested I patch my own copy, but this discussion is not about me, is about tabs). I guess a discussion like this thread is the price to be paid for relying solely on white space to delimit code blocks, like the python syntax does. And in actual practice, that has been shown to be a Good Thing. Yes, I agree, it is. It just could have been better. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 07.04.2013 06:00, Dylan Evans wrote: Then you see my point, unless you are being told what to use by a boss then there are plenty of other languages you can choose from. Python is rigid about it's format, that's just what it is and a lot of people like it but if it's not your thing then some other language will probably suit you better. However, if you are working for a company, or OSS project, you are probably going to have your style dictated whatever language you use [...] I am ok with the people that like python the way it is. But an option from python authors to make tabs work the way they used to would have been nice. Just my opinion, I do see other people here think otherwise... Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 04/07/2013 04:44 AM, Timothy Madden wrote: I am ok with the people that like python the way it is. Really? 'Cause I totally missed that from the subject line... -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 05/04/2013 22:41, terminato...@gmail.com wrote: snipped as loads of comments already made. Timothy Madden The BDFL's view from many moons ago www.python.org/doc/essays/ppt/regrets/PythonRegrets.ppt slide 3. -- If you're using GoogleCrap™ please read this http://wiki.python.org/moin/GoogleGroupsPython. Mark Lawrence -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
In article mailman.247.1365358341.3114.python-l...@python.org, Ethan Furman et...@stoneleaf.us wrote: On 04/07/2013 04:44 AM, Timothy Madden wrote: I am ok with the people that like python the way it is. Really? 'Cause I totally missed that from the subject line... -- ~Ethan~ Take this logically... 1) Ethan hates all clp readers 2) Ethan does not hate people who like python the way it is I therefore deduce that Ethan believes there are no clp readers who like python the way it is. This may be a mistaken belief, but at least there's no logical contradiction. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
Hi, Well all previous (python 2) code is meant to work for a tab size of 8. yes, but even in Python 2, mixing spaces and tabs is considered bad style and should be avoided. And code-checkers like pylint (which I can recommend to everyone) create a warning. You may call this categorically wrong, but it has been there a long while, is is still in use, and it sticks to the default. As I said, mixing tabs and spaces for indentation was *always* a bad idea, and is discouraged also in Python 2. Spaces-only can achieve compatibility between different people settings for formatted text like source code. But so does a common default for the tab size, But there's no such thing as default tab size. Configuring the tab-size is quite common among programmers. But why do you insist on using tabs at all? The best way -- in my opinion -- is to use the tab- and backspace-key for indentation, and let the editor convert it to spaces. (And use some tool to convert all tabs in the old code.) I don't see *any* advantage of mixed spaces and tabs, but quite some disadvantages/problems. What I would expect is some option in python to make tabs work the way they used to. I want a choice for me to preserve my settings, the same way you want to preserve yours. What I want should not be much to ask, since this is how python 2 used to do things. I admit such a '--fixed-tabs' option, that will make tab stops be 8 columns apart, and allow any number of spaces like in python 2, makes the code I write dependent on that option. There's no need to add this to Python 3, since you already have what you want. Simply use: expand yourscript.py | python3 regards Roland -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 04/05/2013 11:36 PM, Timothy Madden wrote: I guess a discussion like this thread is the price to be paid for relying solely on white space to delimit code blocks, like the python syntax does. I've always been taught that in Python using tabs, particularly in the way that you use them (which, by the way, is the default way vim uses them when in C++ mode) is fraught with difficulty. So years ago I dropped in c couple of lines in my vimrc file to use spaces instead of tabs and use the PEP standard of 4 spaces. Have never had any problem. As for your problems, perhaps instead of coming on the list with a poorly-thought-out subject line, and desire to simply argue, perhaps you could run your code through a reformatter that would translate your tabs into spaces using the tab stop that you desired. Open the file in vim, enter the following commands: set sw=4 set ts=8 set et set softtabstop=4 set ai :retab Then save the file. Now it's pep-formatted with spaces and no tabs. Problem solved. Yes it doesn't address your concerns, but it is the recommended solution for Python given the difficulties in mixing tabs and spaces and different people's definition of tabs. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 04/05/2013 11:53 PM, Ian Kelly wrote: The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), What makes that not good? There is no law anywhere that says tabs are 8 characters. That's just an arbitrary amount that looked appropriate to the people designing the first teletypes. Ahh but assuming tabs are the equivalent of 8 spaces can save 7 bytes per tab character in the source code! Think of the savings. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Fri, 05 Apr 2013 23:59:18 -0600, Michael Torrie wrote: On 04/05/2013 11:53 PM, Ian Kelly wrote: The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), What makes that not good? There is no law anywhere that says tabs are 8 characters. That's just an arbitrary amount that looked appropriate to the people designing the first teletypes. Ahh but assuming tabs are the equivalent of 8 spaces can save 7 bytes per tab character in the source code! Think of the savings. If we standardize on 1025 spaces per indent, and use tabs, we can save 1KiB per indent. Let's see now... looking at a typical piece of code in my code base, I make it that the average line of code is indented about 1.75 levels. (I use a lot of top-level functions, and few classes). With an average line length of 50 characters, plus indentation, we can reduce the size of a typical Python module by ninety-seven percent! Of course, what we save in disk space, we lose in monitor size, but I'm sure that the price of 300 inch monitors will soon become quite affordable. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 04/05/2013 11:28 PM, Benjamin Kaplan wrote: http://www.xkcd.com/1172/ How did I ever miss this before? That is truly awesome. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 04/05/2013 10:36 PM, Timothy Madden wrote: 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2 should be enough to make that debate unnecessary. Python 3 broke a lot of things. Pull on your big-boy underwear and deal with it. Thank you, Saying 'thank you' does not mitigate you acting like an ass. -- ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sat, 06 Apr 2013 08:36:23 +0300, Timothy Madden wrote: 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2 should be enough to make that debate unnecessary. Compatibility with Python 2 is not a requirement. Python 3 exists to fix a bunch of design flaws and mistakes in Python 2. Among the changes: - print and exec are now functions, not statements - the dangerous input function is gone - raw_input is renamed input - the distinction between int and long is gone - the second-string classic classes are gone - strings are Unicode, not bytes - division is done correctly - the error-prone syntax of the except statement is fixed - inconsistently named modules are fixed - the plethora of similar dict methods is cleaned up - map, filter, zip operate lazily rather than eagerly and of course - mixed spaces and tabs for indentation is gone You are right, to change the tab size means to change the meaning of the code, and that would be wrong. Can't argue with that. I can argue with that. Changing tab size does *not* change the meaning of code, provided you *only* use tabs for indentation. Using only tabs for indentation is fine. Whether you set your editor to display tabs as 2 columns, 4 columns, 8 columns, or a thousand columns will make not a whit of difference to the meaning of the code or the number of indent levels. This is the Killer Feature of tabs, and it is the primary reason why tabs rule and spaces suck for indentation. (Alas, too many broken tools that can't handle tabs mean that the less- good standard won.) Using only spaces for indentation is also fine. Not as good as tabs, because if I use spaces, you're stuck reading my code in whatever poorly- thought out indent I might choose. I've seen developers use *one* space. But using only spaces does work. What does not work in general, is mixing the two. Don't mix them for indents, and you'll be fine. What I want is an option to use the tabs as I have used them in the past, with the default size. You can continue to use tabs, so long as you don't mix them with spaces. Since ambiguity about the tab size appears to be the cause for new python 3 rules, I though of an option the make that size explicit. I still think users should somehow have a way to use a tab stop of their choice, but how this could be achieved properly is another problem. Unnecessary complexity to solve a non-problem. Just pick one, tabs or spaces, and consistently use it in any one block of code. You don't even have to be consistent over an entire file. I guess a discussion like this thread is the price to be paid for relying solely on white space to delimit code blocks, like the python syntax does. Mixing spaces and tabs for indentation is bad in brace languages too. http://mailman.linuxchix.org/pipermail/programming/2004-August/001433.html Maybe if we had smarter editors and smarter diffs and smarter tools in general, it wouldn't be a problem. But we don't, so it is. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 08:53, Ian Kelly wrote: On Fri, Apr 5, 2013 at 11:07 PM, Timothy Madden terminato...@gmail.com wrote: [...] So in other words, everybody must be forced to use 8-character tabs because you want to be able to mix tabs and spaces. People say I can use tabs all the way, just set them to the indent I want. Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them. But now I can not; python no longer lets me do that. Honestly, I really don't understand why you *want* to do that. If your indentation is 4 characters, then that would be the natural tab width to use. If you're not going to tie your indent to your tabs, then why even use tabs in the first place? The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), What makes that not good? There is no law anywhere that says tabs are 8 characters. That's just an arbitrary amount that looked appropriate to the people designing the first teletypes. I am aware that 7 bytes per tab character (or 14/28, in UTF-16, UTF-32!) will not justify the time spent debating. The reason I want to use tabs is that I think there is nothing wrong with them. The reason why everybody should use 8-character tabs is so that I and the rest of the world can use `grep` / `findstr` on their code, and still see lines of code properly aligned in the terminal. Or to be able to print fragments of code as plain text only, and get the proper alignment. But most importantly, the reason that tab size should be 8 is so that all of us people in this world can freely exchange formatted text like source code without having to first consider if will it look the same in their editor ? What tab size do they use ? In other words, the solution to different people's definition of tabs is not to drop them, but only to get a common default. Which is already there: 8 columns between every tab stop. What python 3 does is a different attitude, and that is: everyone likes their own indent. Although I personally find it annoying, I am aware that many people use an indent of 2 spaces, some use even 3. Moreover, many C programers still like 8 spaces per indent. So some development environments find it an advantage to use tabs only for indentation, and every programmer is then free to set the tab stop to their liking. Everyone will see the indent they like, with no changes in the byte stream for the file. Why I think this is wrong is a little difficult for me explain. First, I admit this approach toward tabs has some value and is tempting for me, too. But it assumes everything, everywhere can configure tab sizes. Consoles and printers usually do not. Next, even if they can, most people, including all non-technical personal, never bother to change settings. Then this also assumes I change settings to my liking on several computers I use (maybe I work for several clients each with their computers, most people have a work computer and a home computer, maybe also a laptop and a tablet/smart device). Last, this is also not helpful if two sometimes use the same computer from time to time, and do not want to switch users all the time. So this is not a very good approach, and I have the feeling that most python programmers and development environment prefer to use only spaces than to use variable tab sizes. So the right solution remains a proper default setting for the tab size, and then we no longer have to drop tabs from source code files. Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 08:58, Michael Torrie wrote: [...] As for your problems, perhaps instead of coming on the list with a poorly-thought-out subject line, and desire to simply argue, perhaps you could run your code through a reformatter [...] Hey, I was feeling frustrated ... ! It is how people feel when they no longer have a choice they used to have. But I hear programmers should get used to the feeling: using code that you did not write is bound to trigger that reaction every so often. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 6 April 2013 07:56, Timothy Madden terminato...@gmail.com wrote: On 06.04.2013 08:53, Ian Kelly wrote: On Fri, Apr 5, 2013 at 11:07 PM, Timothy Madden terminato...@gmail.com wrote: [...] So in other words, everybody must be forced to use 8-character tabs because you want to be able to mix tabs and spaces. People say I can use tabs all the way, just set them to the indent I want. Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them. But now I can not; python no longer lets me do that. Honestly, I really don't understand why you *want* to do that. If your indentation is 4 characters, then that would be the natural tab width to use. If you're not going to tie your indent to your tabs, then why even use tabs in the first place? The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), What makes that not good? There is no law anywhere that says tabs are 8 characters. That's just an arbitrary amount that looked appropriate to the people designing the first teletypes. I am aware that 7 bytes per tab character (or 14/28, in UTF-16, UTF-32!) will not justify the time spent debating. The reason I want to use tabs is that I think there is nothing wrong with them. So use them The reason why everybody should use 8-character tabs is so that I and the rest of the world can use `grep` / `findstr` on their code, and still see lines of code properly aligned in the terminal. Or to be able to print fragments of code as plain text only, and get the proper alignment. Oh thanks. I liked using my four character tabs, but I guess you *are* so important that I'm going to have to change everything I do just for you. It's obviously not good enough for you just to not mix tabs and spaces so that we can both enjoy ourselves because that would make *you*, the holiest of all, have to put some effort in. No, I totally understand and will now go and change everything after Python is changed to break hundreds of files of codes for you. But most importantly, the reason that tab size should be 8 is so that all of us people in this world can freely exchange formatted text like source code without having to first consider if will it look the same in their editor ? What tab size do they use ? Hrm. Hrm. Hmmm. H. No, you're right: spaces are totally not for this in any way and that no-one has ever made this point before and who the hell cares if you're reading code with a different indent size anyway it's not like it affects the actual code. Yours frustratedly, Joshua Landau But seriously, please at least look like you've read other people's posts. It doesn't matter what tabstop you use as long as you don't mix. If your code depends on tab size then it's categorically wrong. Other people's tab sizes are as valid. I use tabs because of the variation it lets me have - I can switch tab sizes on the fly - and it's faster on dumb editors. So let me do that. But let us assume we were going to standardise on TAB == 8 SPACES. It would *still* be bad to mix tabs and spaces. Hence you'd change Python in exactly 0 ways. So *what do you want from us*? -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
terminato...@gmail.com wrote: [...] The def line has four spaces. The for line then has a hard tab. This is ambiguous. If the hard tab is assumed to have a width of four spaces, then they are at the same indentation level. If it is assumed to have a width of eight spaces, then they are not. [...] The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. You know the Unix command 'expand'? If you used tabs representing eight columns consequently, use expand on your python scripts to convert tabs to spaces before running them. Best regards, Günther -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Fri, 05 Apr 2013 21:53:40 -0600, Ian Kelly wrote: 8 characters is common, but no more correct than any other, This is pure revisionism. 8-column tabs may never have been a significant /de jure/ standard (although they have been that in many specific domains), but they have been a significant /de facto/ standard for almost as long as computers have existed. Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. Creating software which, in the absence of both a good reason and an explicit mechanism for communicating the configured value, treats them as configurable is usually a consequence of a code now, think later mentality (although there may have be a few cases where it was a deliberate embrace, extend, extinguish tactic). -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sun, Apr 7, 2013 at 12:52 AM, Nobody nob...@nowhere.com wrote: Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. 3. Tab stops are measured in something other than characters. With variable-width fonts, it's illogical to set tab stops in characters. DeScribe Word Processor defined them in centimeters, way back in the early... well, I didn't meet it till the 90s, but I don't know how long it had been around before that. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 13:17, Joshua Landau wrote: [...] Yours frustratedly, Joshua Landau But seriously, please at least look like you've read other people's posts. It doesn't matter what tabstop you use as long as you don't mix. When the default tab size is 8, than tab size does matter. Because it is too much to use as indent size. If you still want to use tabs, you are now supposed to change tab size from the default. I believe using non-default tab size in a public environment like open-source code is bound to cause formatting problems for someone at some point. If your code depends on tab size then it's categorically wrong. Other people's tab sizes are as valid. I use tabs because of the variation it lets me have - I can switch tab sizes on the fly - and it's faster on dumb editors. So let me do that. But let us assume we were going to standardise on TAB == 8 SPACES. It would *still* be bad to mix tabs and spaces. Hence you'd change Python in exactly 0 ways. So *what do you want from us*? Well all previous (python 2) code is meant to work for a tab size of 8. You may call this categorically wrong, but it has been there a long while, is is still in use, and it sticks to the default. Spaces-only can achieve compatibility between different people settings for formatted text like source code. But so does a common default for the tab size, and with that we do not have to limit ourselves to spaces only. Now I understand python 3 people may already use tabs with a size of 4, as you said. Although I tried to show this is not good practice, (and that not many people do that, really, since most of them prefer to use all-spaces instead), still I do not expect the people to change their settings. What I would expect is some option in python to make tabs work the way they used to. I want a choice for me to preserve my settings, the same way you want to preserve yours. What I want should not be much to ask, since this is how python 2 used to do things. I admit such a '--fixed-tabs' option, that will make tab stops be 8 columns apart, and allow any number of spaces like in python 2, makes the code I write dependent on that option. But the option will run all code written for the new python 3 way, and brings back some compatibility, so it is not that bad. And some people might actually want it. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 17:20, Chris Angelico wrote: On Sun, Apr 7, 2013 at 12:52 AM, Nobody nob...@nowhere.com wrote: Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. 3. Tab stops are measured in something other than characters. With variable-width fonts, it's illogical to set tab stops in characters. DeScribe Word Processor defined them in centimeters, way back in the early... well, I didn't meet it till the 90s, but I don't know how long it had been around before that. Yes, but systems with variable-width fonts do not make the default for the tab size now. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
In article mailman.200.1365258042.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Sun, Apr 7, 2013 at 12:52 AM, Nobody nob...@nowhere.com wrote: Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. 3. Tab stops are measured in something other than characters. With variable-width fonts, it's illogical to set tab stops in characters. DeScribe Word Processor defined them in centimeters, way back in the early... well, I didn't meet it till the 90s, but I don't know how long it had been around before that. What makes sense for a word processor and what makes sense for a programming language are two very different things. Word processors are almost always working with blocks of running text, set in proportional fonts, often with multiple font sizes and styles. It is usually assumed that line breaks are ephemeral, i.e. as the text gets edited and reformatted, lines will re-flow. Program text is almost always(*) displayed in a fixed-width font. No font information is carried along with the program text at all; it is assumed the reader will pick a font and size of their own preference, with the only requirement being that it's monospaced. (*) There was a fad about 10 or 15 years ago to print code samples in books in proportional fonts. Prentice-Hall seemed to be particularly guilty of this. Fortunately, common sense prevailed and everybody has gone back to monotype. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-06, Roy Smith r...@panix.com wrote: (*) There was a fad about 10 or 15 years ago to print code samples in books in proportional fonts. Prentice-Hall seemed to be particularly guilty of this. Fortunately, common sense prevailed and everybody has gone back to monotype. Bjarne Stroustrup likes it, and I agree with him that code is even easier to read that way, especially in hard-copy. But most tools have not caught up with the idea. I'll switch as soon as vim supports it. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-05, terminato...@gmail.com terminato...@gmail.com wrote: [Mad that in 3.3 you can no longer use ambiguous mixtures of spaces and tabs within a single indent level.] My boss would refer to this as a failure to be bug-compatible with the previous version. Whether or not to maintain bug-compatibility when you bring out a new version is one of the eternal debates. No matter what you do, it's going to annoy somebody... -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-06, Timothy Madden terminato...@gmail.com wrote: When the default tab size is 8, than tab size does matter. There is no default size. The size of a tab isn't even constant across a line -- they're individually adjustable. The tabs default to wherever they were left by the last person who used the typewriter. All assumptions about the size or predictabilty of tabs are erroneous. -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Apr 6, 8:01 pm, Roy Smith r...@panix.com wrote: What makes sense for a word processor and what makes sense for a programming language are two very different things. Word processors are almost always working with blocks of running text, set in proportional fonts, often with multiple font sizes and styles. It is usually assumed that line breaks are ephemeral, i.e. as the text gets edited and reformatted, lines will re-flow. Program text is almost always(*) displayed in a fixed-width font. No font information is carried along with the program text at all; it is assumed the reader will pick a font and size of their own preference, with the only requirement being that it's monospaced. (*) There was a fad about 10 or 15 years ago to print code samples in books in proportional fonts. Prentice-Hall seemed to be particularly guilty of this. Fortunately, common sense prevailed and everybody has gone back to monotype. Hmm… One of my favourite books on programming is Intro to functional programming by Bird and Wadler (1st edition Prentice Hall). I always knew that part of why I liked the book was the beautifully typeset code. Now I know how this choice dates me!! [It was published in 1988; I used it to teach from '89 onwards] -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-06, Ethan Furman et...@stoneleaf.us wrote: On 04/05/2013 10:36 PM, Timothy Madden wrote: 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2 should be enough to make that debate unnecessary. Python 3 broke a lot of things. Pull on your big-boy underwear and deal with it. Python 3 requires that you wear _underwear_? That seems entirely arbitrary, and violates the god-given rights of telecommuters to write code wearing nothing but a bathrobe! Hell, for all I know, there may be people who go into the office without underwear. Though I think the lonely, unbathed, unshaven, robe-wearing telecommuter will be the poster-child for the worldwide campaign against the undwearist fascists trying to impose their sartorial dictates on Python users. Next, we need to pick a song... -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-06, Neil Cerutti ne...@norwich.edu wrote: On 2013-04-06, Roy Smith r...@panix.com wrote: (*) There was a fad about 10 or 15 years ago to print code samples in books in proportional fonts. Prentice-Hall seemed to be particularly guilty of this. Fortunately, common sense prevailed and everybody has gone back to monotype. Bjarne Stroustrup likes it, and I agree with him that code is even easier to read that way, especially in hard-copy. I'd have to disagree. There are too many times when things are easier to read/maintain by visually aligning columns: * struct/array initializers * constant definitions * parallel/identical operations on multiple different variables * vertical alignment of a parameter lists in multi-line function calls -- Grant -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
In article kjpffa$n35$4...@reader1.panix.com, Grant Edwards invalid@invalid.invalid wrote: On 2013-04-06, Ethan Furman et...@stoneleaf.us wrote: On 04/05/2013 10:36 PM, Timothy Madden wrote: 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2 should be enough to make that debate unnecessary. Python 3 broke a lot of things. Pull on your big-boy underwear and deal with it. Python 3 requires that you wear _underwear_? Only at PyCon. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
In article kjpet5$n35$2...@reader1.panix.com, Grant Edwards invalid@invalid.invalid wrote: On 2013-04-05, terminato...@gmail.com terminato...@gmail.com wrote: [Mad that in 3.3 you can no longer use ambiguous mixtures of spaces and tabs within a single indent level.] My boss would refer to this as a failure to be bug-compatible with the previous version. Whether or not to maintain bug-compatibility when you bring out a new version is one of the eternal debates. No matter what you do, it's going to annoy somebody... I remember the first VAX was got. We used some third-party serial card because it cost a small fraction of the official DEC version. We had all sorts of trouble with it. Eventually it turned out that the third-party card was operating correctly according to the DEC specs, but the driver had been written to work against genuine DEC hardware, which didn't follow their own published spec! I vaguely remember it had to do with how the DMA processor dealt with odd-sized block transfers. As I recall, there was a software patch to the driver which allowed it to work with the correctly implemented hardware, but I could be messing up most of the details. Great machine, that VAX. For only $100k, three or four people could play rogue at the same time! -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
In article asasgofj03...@mid.individual.net, Neil Cerutti ne...@norwich.edu wrote: Bjarne Stroustrup likes it This is supposed to impress me? Yeah, most of the books I recall that used this were C++ books. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Apr 6, 8:41 pm, Grant Edwards inva...@invalid.invalid wrote: On 2013-04-06, Neil Cerutti ne...@norwich.edu wrote: On 2013-04-06, Roy Smith r...@panix.com wrote: (*) There was a fad about 10 or 15 years ago to print code samples in books in proportional fonts. Prentice-Hall seemed to be particularly guilty of this. Fortunately, common sense prevailed and everybody has gone back to monotype. Bjarne Stroustrup likes it, and I agree with him that code is even easier to read that way, especially in hard-copy. I'd have to disagree. There are too many times when things are easier to read/maintain by visually aligning columns: * struct/array initializers * constant definitions * parallel/identical operations on multiple different variables * vertical alignment of a parameter lists in multi-line function calls -- Grant I believe that it is at least possible to wish for the best of all worlds. http://nickgravgaard.com/elastictabstops/ (browser needs java) Pragmatically I continue to use emacs with a fixed-width font. Not claiming I am too happy with this choice. That includes a whole lot of stuff, not just fonts -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013-04-06, Roy Smith r...@panix.com wrote: In article asasgofj03...@mid.individual.net, Neil Cerutti ne...@norwich.edu wrote: Bjarne Stroustrup likes it This is supposed to impress me? Hehe. No! But he's got enough clout to give the notion some traction. Yeah, most of the books I recall that used this were C++ books. Yes, that would be why I bet. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 04/05/2013 10:36 PM, Timothy Madden wrote: [snip...] 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2 should be enough to make that debate unnecessary. As everyone keeps telling you -- there is NO default tab size. Default implies there is an OFFICIAL definition, there is none. There is, however, convention -- which is merely a common suggestion, without any force implied. What I want is an option to use the tabs as I have used them in the past, with the default size. Since ambiguity about the tab size appears to be the cause for new python 3 rules, I though of an option the make that size explicit. I still think users should somehow have a way to use a tab stop of their choice, but how this could be achieved properly is another problem. What you want and what you think are irrelevant. The Python language (whatever version) is already defined. If you want to use it, you have to accept it and adapt to what it is. Live with it and move on. Complaining about it is a complete waste of time -- it's NOT going to change just because YOU don't like it. Frankly, with your continuing to rant about this subject is simply making yourself look like an obstinate fool. I've enjoyed following this thread because I find your attitude so ridiculously amusing.[1] I guess a discussion like this thread is the price to be paid for relying solely on white space to delimit code blocks, like the python syntax does. And in actual practice, that has been shown to be a Good Thing. Thank you, Timothy Madden -=- Larry -=- [1]. I just turned 76 and definitely tend to be a curmudgeon, so sorry if I sound too insulting, but it is the way I feel. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sun, Apr 7, 2013 at 2:01 AM, Roy Smith r...@panix.com wrote: In article mailman.200.1365258042.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Sun, Apr 7, 2013 at 12:52 AM, Nobody nob...@nowhere.com wrote: Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. 3. Tab stops are measured in something other than characters. With variable-width fonts, it's illogical to set tab stops in characters. DeScribe Word Processor defined them in centimeters, way back in the early... well, I didn't meet it till the 90s, but I don't know how long it had been around before that. What makes sense for a word processor and what makes sense for a programming language are two very different things. Yes. I was just completing the set, since the heading didn't specify *for programming languages*. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sun, 07 Apr 2013 01:20:32 +1100, Chris Angelico wrote: On Sun, Apr 7, 2013 at 12:52 AM, Nobody nob...@nowhere.com wrote: Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. 3. Tab stops are measured in something other than characters. With variable-width fonts, it's illogical to set tab stops in characters. DeScribe Word Processor defined them in centimeters, way back in the early... well, I didn't meet it till the 90s, but I don't know how long it had been around before that. Am I the only one here who has used a typewriter? Tab stops were set manually, to a physical distance into the page, using a mechanical stop. This long predates the rule that tab stops are every 8 characters. If your editor doesn't support setting tab stops to at least single pixel resolution, it's not supporting tabs, it's supporting something else that it merely calls tabs. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sat, 06 Apr 2013 11:01:04 -0400, Roy Smith wrote: In article mailman.200.1365258042.3114.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: On Sun, Apr 7, 2013 at 12:52 AM, Nobody nob...@nowhere.com wrote: Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. 3. Tab stops are measured in something other than characters. With variable-width fonts, it's illogical to set tab stops in characters. DeScribe Word Processor defined them in centimeters, way back in the early... well, I didn't meet it till the 90s, but I don't know how long it had been around before that. What makes sense for a word processor and what makes sense for a programming language are two very different things. Word processors are almost always working with blocks of running text, set in proportional fonts, often with multiple font sizes and styles. It is usually assumed that line breaks are ephemeral, i.e. as the text gets edited and reformatted, lines will re-flow. Word processors mostly use tabs for aligning text, e.g. in tables and lists. Exactly the same thing that tabs are used for in source code. Large blocks of running text are irrelevant, because tabs are rarely used inside large blocks of running text. Program text is almost always(*) displayed in a fixed-width font. No font information is carried along with the program text at all; it is assumed the reader will pick a font and size of their own preference, And tab settings. If you're going to complain that changing the tab settings will break the layout of the source code, so will changing the font and size. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
In article 5160cc44$0$29995$c3e8da3$54964...@news.astraweb.com, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: On Sun, 07 Apr 2013 01:20:32 +1100, Chris Angelico wrote: On Sun, Apr 7, 2013 at 12:52 AM, Nobody nob...@nowhere.com wrote: Historically, software and hardware which assigns a meaning to a tab character has come in two flavours: 1. Tab stops are every 8 columns; this cannot be changed. 2. Tab stops are configurable, defaulting to every 8 columns. 3. Tab stops are measured in something other than characters. With variable-width fonts, it's illogical to set tab stops in characters. DeScribe Word Processor defined them in centimeters, way back in the early... well, I didn't meet it till the 90s, but I don't know how long it had been around before that. Am I the only one here who has used a typewriter? Tab stops were set manually, to a physical distance into the page, using a mechanical stop. This long predates the rule that tab stops are every 8 characters. Yup. I learned on a good old manual, with mechanical Tab Set and Tab Clear function. Of course, on an 029, you set the tab stops by punching a drum card. If your editor doesn't support setting tab stops to at least single pixel resolution, it's not supporting tabs, it's supporting something else that it merely calls tabs. Yup. I use emacs. M-X edit tab stops does that. Like so much else about emacs, I haven't used that feature in years (gee, maybe decades), but it's nice to know it's there. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
Am I the only one here who has used a typewriter? I used one. And http://en.wikipedia.org/wiki/White-Out. And http://en.wikipedia.org/wiki/Correction_tape. My wife typed her dissertation on this: http://en.wikipedia.org/wiki/File:Hardwarewordprocessor.png. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
Then you see my point, unless you are being told what to use by a boss then
there are plenty of other languages you can choose from. Python is rigid
about it's format, that's just what it is and a lot of people like it but
if it's not your thing then some other language will probably suit you
better. However, if you are working for a company, or OSS project, you are
probably going to have your style dictated whatever language you use, for
example the 2 space indents (*shudder*) that google uses in c++
http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml?showone=Spaces_vs._Tabs#Spaces_vs._Tabs
(Interestingly
google use 4 space indents in python for compatibility with PEP-8
http://google-styleguide.googlecode.com/svn/trunk/pyguide.html?showone=Indentation#Indentation
)
You probably won't like everything in a project style but it's not about
being tyrannical, and it's not a bad thing to have restrictions at the
language level.
I work for a company with a load of lagacy c formatted as follows:
int many_many_globals;
int func(int iFoo,int iBar)
{
int var = 10;
if(iBar1)
{
var=iFoo+many_many_globals;
}
return var;
}
So i am pretty happy to adopt a language which defines a sane style.
This is a nice flame war you have stirred up.
On Sat, Apr 6, 2013 at 3:13 PM, terminato...@gmail.com wrote:
On Saturday, April 6, 2013 7:28:55 AM UTC+3, Dylan Evans wrote:
On Sat, Apr 6, 2013 at 7:41 AM, termin...@gmail.com wrote:
Hello
I just tried python 3.3 with some simple script meant for unit test.
How can python authors be so arrogant to impose their tabs and spaces
options on me ? It should be my choice if I want to use tabs or not !
Don't like it? Use ruby.
Actually next on my list is perl. I know ruby is sexy, but taming the wild
beast is what makes me feel like the real cowboy.
--
http://mail.python.org/mailman/listinfo/python-list
--
The UNIX system has a command, nice ... in order to be nice to the other
users. Nobody ever uses it. - Andrew S. Tanenbaum
--
http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sat, Apr 6, 2013 at 8:41 AM, terminato...@gmail.com wrote: Hello I just tried python 3.3 with some simple script meant for unit test. How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not ! It is. As long as you're consistent, you can use tabs or spaces without problems. You're also most welcome to continue using Python 3.2, or 2.1, or 0.1 (if you're Steven D'Aprano), which might have the semantics you want. And hey, if you dig into the source, I'm sure you could find how to make it configurable. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
In 64d4fb7c-6a75-4b5f-b5c8-06a4b2b5d...@googlegroups.com terminato...@gmail.com writes: How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not ! You are free to use tabs, but you must be consistent. You can't mix tabs and spaces for lines of code at the same indentation level. -- John Gordon A is for Amy, who fell down the stairs gor...@panix.com B is for Basil, assaulted by bears -- Edward Gorey, The Gashlycrumb Tinies -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Saturday, April 6, 2013 12:55:29 AM UTC+3, John Gordon wrote: In 64d4fb7c-6a75-4b5f-b5c8-06a4b2b5d...@googlegroups.com terminato...@gmail.com writes: How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not ! You are free to use tabs, but you must be consistent. You can't mix tabs and spaces for lines of code at the same indentation level. They say so, but python does not work that way. This is a simple script: from unittest import TestCase class SvnExternalCmdTests(TestCase) : def test_parse_svn_external(self) : for sample_external in sample_svn_externals : self.assertEqual(parse_svn_externals(sample_external[0][0], sample_external[0][1]), [ sample_external[1] ]) And at the `for` statement at line 5 I get: C:\Documents and Settings\Adrian\Projectspython sample-py3.py File sample-py3.py, line 5 for sample_external in sample_svn_externals : ^ TabError: inconsistent use of tabs and spaces in indentation Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ? You can try the script as it is, and see python 3.3 will not run it -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013.04.05 17:04, terminato...@gmail.com wrote: Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ? The first indent level is done with spaces on the second line (for def) and then with a tab on the third (and another tab to indent again). Remember that your for loop is inside the class definition. -- CPython 3.3.0 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Fri, Apr 5, 2013 at 4:04 PM, terminato...@gmail.com wrote: They say so, but python does not work that way. This is a simple script: from unittest import TestCase class SvnExternalCmdTests(TestCase) : def test_parse_svn_external(self) : for sample_external in sample_svn_externals : self.assertEqual(parse_svn_externals(sample_external[0][0], sample_external[0][1]), [ sample_external[1] ]) And at the `for` statement at line 5 I get: C:\Documents and Settings\Adrian\Projectspython sample-py3.py File sample-py3.py, line 5 for sample_external in sample_svn_externals : ^ TabError: inconsistent use of tabs and spaces in indentation Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ? The def line has four spaces. The for line then has a hard tab. This is ambiguous. If the hard tab is assumed to have a width of four spaces, then they are at the same indentation level. If it is assumed to have a width of eight spaces, then they are not. Python 2 resolved this ambiguity by assuming that a hard tab was simply equivalent to four or eight spaces (I don't remember which). The problem with assuming this is that the assumption made by Python does not necessarily match the tab width selected by the user, with the result that lines that *look* like they are at the same indentation level might actually be different (and vice-versa), leading to hard-to-find bugs. Python 3 instead resolves this ambiguity by not allowing it. In the code above, because the def line has four spaces, the indentation of the for line that is subordinate to it needs to also start with four spaces (and then you can continue the indentation with tabs or spaces as you prefer). Because the line after the for line is subordinate to it, it also then needs to begin with the same exact indentation used by the for line (in the sample provided, it currently does). My suggestion: choose to use either all tabs or all spaces within a file, and then you won't have this problem. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
You underestimated the arrogance of Python. Python 3 tab doesn't map to 4 spaces. It doesn't map to any number of spaces. Tabs and spaces are completely unrelated. If you have a function having the first indentation level with 4 (or any number of) spaces, the next line starting not with 4 spaces but instead with a tab always lead you to the TabError exception. If you like to play tricks, you can use 4 spaces plus a tab as the next indentation level. I'd rather not do this kind of things, and forget about use using tabs at all. You are out of luck if you want to play the tab-space tricks, but if you follow the lead, you'll soon find that code will be more reliable without tabs, especially if you cut-and-paste code of others. On Sat, Apr 6, 2013 at 6:04 AM, terminato...@gmail.com wrote: On Saturday, April 6, 2013 12:55:29 AM UTC+3, John Gordon wrote: In 64d4fb7c-6a75-4b5f-b5c8-06a4b2b5d...@googlegroups.com terminato...@gmail.com writes: How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not ! You are free to use tabs, but you must be consistent. You can't mix tabs and spaces for lines of code at the same indentation level. They say so, but python does not work that way. This is a simple script: from unittest import TestCase class SvnExternalCmdTests(TestCase) : def test_parse_svn_external(self) : for sample_external in sample_svn_externals : self.assertEqual(parse_svn_externals(sample_external[0][0], sample_external[0][1]), [ sample_external[1] ]) And at the `for` statement at line 5 I get: C:\Documents and Settings\Adrian\Projectspython sample-py3.py File sample-py3.py, line 5 for sample_external in sample_svn_externals : ^ TabError: inconsistent use of tabs and spaces in indentation Line 5 is the only line in the file that starts at col 9 (after a tab). Being the only line in the file with that indent level, how can it be inconsistent ? You can try the script as it is, and see python 3.3 will not run it -- http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Fri, Apr 5, 2013 at 4:42 PM, Ian Kelly ian.g.ke...@gmail.com wrote: Python 2 resolved this ambiguity by assuming that a hard tab was simply equivalent to four or eight spaces (I don't remember which). In fact, neither is correct. Per the docs: ...tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight... -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote: [...] The def line has four spaces. The for line then has a hard tab. This is ambiguous. If the hard tab is assumed to have a width of four spaces, then they are at the same indentation level. If it is assumed to have a width of eight spaces, then they are not. [...] The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sat, Apr 6, 2013 at 11:22 AM, terminato...@gmail.com wrote: On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote: [...] The def line has four spaces. The for line then has a hard tab. This is ambiguous. If the hard tab is assumed to have a width of four spaces, then they are at the same indentation level. If it is assumed to have a width of eight spaces, then they are not. [...] The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. If you're indenting four spaces per level, then indent four spaces per level. The code you posted would work perfectly if the indentation is four spaces, then eight spaces, then twelve spaces. The problem is that you have a stupid editor that's enforcing tabs instead of certain multiples of spaces - get one that'll keep them all as spaces and you won't have a problem. Or use actual tabs, and set the displayed tab width to whatever you feel like. That works, too. Neither option causes any problems with any sane tools. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 2013.04.05 19:22, terminato...@gmail.com wrote: And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. Python (at least Python 3) has no concept of tab size. A tab is one character, and how an editor or terminal or whatever chooses to display it has nothing to do with Python. If you want to convert tabs to a specific number of spaces or vice versa, there are multiple tools out there you can use. In fact, many editors have the functionality built in. Use all tabs or use all spaces. Any editor that isn't broken will let you do either without problems. -- CPython 3.3.0 | Windows NT 6.2.9200 / FreeBSD 9.1 -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Fri, 05 Apr 2013 17:22:19 -0700, terminatorul wrote: On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote: [...] The def line has four spaces. The for line then has a hard tab. This is ambiguous. If the hard tab is assumed to have a width of four spaces, then they are at the same indentation level. If it is assumed to have a width of eight spaces, then they are not. [...] The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. This is incorrect. Tab stops come from *typewriters*, where they are user- configurable to any position on the page without limit. There is no requirement for them to be 8 character columns apart, or even a fixed number of columns apart. Word processors like OpenOffice and Microsoft Word get the behaviour of tab stops right. Any editor which forces tabs to be exactly 8 columns apart gets them wrong. And now python forces me out of using any tab characters at all. That is simply not true, and you have been told repeatedly by numerous people that Python 3 supports tabs. You can use spaces for indentation, and you can use tabs for indentation. You can even mix spaces and tabs in the same file. What you cannot do is mix spaces and tabs in the same block. If you don't believe us, and you don't believe the documentation, then believe the actual behaviour of the Python 3 compiler. Test it for yourself. Run this code under Python 3: === cut === code = def spam(): print(indented with five spaces) def eggs(): \t\tprint(indented with two tabs) spam() eggs() exec(code) === cut === If it were my language, I would be even stricter about indentation than Python 3. I would require that each file use *only* tabs, or *only* spaces, and not allow both in the same file. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Fri, Apr 5, 2013 at 6:22 PM, terminato...@gmail.com wrote: The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. 8 characters is common, but no more correct than any other, as tab width has never been standardized. You talk of not wanting tab options imposed on you, but consider that treating tabs as 8-character stops imposes that setting on anybody who needs to work with your mixed-indentation code. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. And then changing that setting could change the meaning of the code, which would be a disaster for code that you want to distribute. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sat, Apr 6, 2013 at 7:41 AM, terminato...@gmail.com wrote: Hello I just tried python 3.3 with some simple script meant for unit test. How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not ! Don't like it? Use ruby. I know people have all goten into this frenzy of using either tabs, either spaces for indentation, but using a hard-tab of 8 spaces and a soft tab of 4 spaces has worked fine long before python 3 showed up. And if they decided to throw a TabError, they should have at least created an option to specify tab size, so I can work around that. I am aware that so many editors use a tab stop of 4 spaces instead of 8 (which by the way started as a cheap way to work around their initial lack of a soft tab stop option, and then was kept at 4 for compatibility). But the rest of us who always use a tab stop of 8 should not be forced to change preferences because python reached version 3. Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list -- The UNIX system has a command, nice ... in order to be nice to the other users. Nobody ever uses it. - Andrew S. Tanenbaum -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 03:35, Chris Angelico wrote: On Sat, Apr 6, 2013 at 11:22 AM, terminato...@gmail.com wrote: On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote: [...] The def line has four spaces. The for line then has a hard tab. This is ambiguous. If the hard tab is assumed to have a width of four spaces, then they are at the same indentation level. If it is assumed to have a width of eight spaces, then they are not. [...] The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. If you're indenting four spaces per level, then indent four spaces per level. The code you posted would work perfectly if the indentation is four spaces, then eight spaces, then twelve spaces. The problem is that you have a stupid editor that's enforcing tabs instead of certain multiples of spaces - get one that'll keep them all as spaces and you won't have a problem. My editor is not the problem, of course, this is about what I think is right. I think I should be given the option to use tabs as I always have, and at least to use them with the default tab size, as python 2 used to. Or use actual tabs, and set the displayed tab width to whatever you feel like. That works, too. Neither option causes any problems with any sane tools. Well this is the problem, the tab size is not whatever I like, tab stops are 8 character columns apart (default). Changing the tab size from this default is what makes the code incompatible, not the tabs themselves. So the solution is simple: do not change tab size from the default. People say I can use tabs all the way, just set them to the indent I want. Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them. But now I can not; python no longer lets me do that. Tab size should be 8, so now python 3 says: either indent at 8 with tabs, either drop tabs and indent with spaces (just the same as if tabs are not allowed). But that is so wrong. I can indent at 4 (or any value), and still use tabs, as long as the interpreter knows tab stops are 8 columns apart. There is no ambiguity and no way to change the meaning of the code. So as a comparison we have: - the good old rules - python has use the default tab stops of 8 columns - indent is independent of tab stops - the new rules - python is independent of the tab stops - indent is now tied to the tab stop, so users have to : - use non-default tab size (8 is too much), or - drop tabs altogether The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), or drop the tabs, which I could have used before python 3 just fine. Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Saturday, April 6, 2013 7:28:55 AM UTC+3, Dylan Evans wrote: On Sat, Apr 6, 2013 at 7:41 AM, termin...@gmail.com wrote: Hello I just tried python 3.3 with some simple script meant for unit test. How can python authors be so arrogant to impose their tabs and spaces options on me ? It should be my choice if I want to use tabs or not ! Don't like it? Use ruby. Actually next on my list is perl. I know ruby is sexy, but taming the wild beast is what makes me feel like the real cowboy. -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Fri, Apr 5, 2013 at 10:07 PM, Timothy Madden terminato...@gmail.com wrote: On 06.04.2013 03:35, Chris Angelico wrote: On Sat, Apr 6, 2013 at 11:22 AM, terminato...@gmail.com wrote: On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote: [...] The def line has four spaces. The for line then has a hard tab. This is ambiguous. If the hard tab is assumed to have a width of four spaces, then they are at the same indentation level. If it is assumed to have a width of eight spaces, then they are not. [...] The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. If you're indenting four spaces per level, then indent four spaces per level. The code you posted would work perfectly if the indentation is four spaces, then eight spaces, then twelve spaces. The problem is that you have a stupid editor that's enforcing tabs instead of certain multiples of spaces - get one that'll keep them all as spaces and you won't have a problem. My editor is not the problem, of course, this is about what I think is right. I think I should be given the option to use tabs as I always have, and at least to use them with the default tab size, as python 2 used to. Or use actual tabs, and set the displayed tab width to whatever you feel like. That works, too. Neither option causes any problems with any sane tools. Well this is the problem, the tab size is not whatever I like, tab stops are 8 character columns apart (default). Changing the tab size from this default is what makes the code incompatible, not the tabs themselves. So the solution is simple: do not change tab size from the default. People say I can use tabs all the way, just set them to the indent I want. Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them. But now I can not; python no longer lets me do that. Tab size should be 8, so now python 3 says: either indent at 8 with tabs, either drop tabs and indent with spaces (just the same as if tabs are not allowed). But that is so wrong. I can indent at 4 (or any value), and still use tabs, as long as the interpreter knows tab stops are 8 columns apart. There is no ambiguity and no way to change the meaning of the code. So as a comparison we have: - the good old rules - python has use the default tab stops of 8 columns - indent is independent of tab stops - the new rules - python is independent of the tab stops - indent is now tied to the tab stop, so users have to : - use non-default tab size (8 is too much), or - drop tabs altogether The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), or drop the tabs, which I could have used before python 3 just fine. Thank you, Timothy Madden http://www.xkcd.com/1172/ -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On 06.04.2013 06:53, Ian Kelly wrote: On Fri, Apr 5, 2013 at 6:22 PM, terminato...@gmail.com wrote: The correct tab stop positions have always been at 8 character columns apart. The ambiguity was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators. 8 characters is common, but no more correct than any other, as tab width has never been standardized. You talk of not wanting tab options imposed on you, but consider that treating tabs as 8-character stops imposes that setting on anybody who needs to work with your mixed-indentation code. And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now. And then changing that setting could change the meaning of the code, which would be a disaster for code that you want to distribute. 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2 should be enough to make that debate unnecessary. You are right, to change the tab size means to change the meaning of the code, and that would be wrong. Can't argue with that. What I want is an option to use the tabs as I have used them in the past, with the default size. Since ambiguity about the tab size appears to be the cause for new python 3 rules, I though of an option the make that size explicit. I still think users should somehow have a way to use a tab stop of their choice, but how this could be achieved properly is another problem. I guess a discussion like this thread is the price to be paid for relying solely on white space to delimit code blocks, like the python syntax does. Thank you, Timothy Madden -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Sat, Apr 6, 2013 at 4:36 PM, Timothy Madden terminato...@gmail.com wrote: I guess a discussion like this thread is the price to be paid for relying solely on white space to delimit code blocks, like the python syntax does. Absolutely. Bring on Python 5000, where all such stupidities are abolished and we can argue about really important matters, like whether chr(7) should be allowed in identifiers. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: I hate you all
On Fri, Apr 5, 2013 at 11:07 PM, Timothy Madden terminato...@gmail.com wrote: Changing the tab size from this default is what makes the code incompatible, not the tabs themselves. So the solution is simple: do not change tab size from the default. So in other words, everybody must be forced to use 8-character tabs because you want to be able to mix tabs and spaces. People say I can use tabs all the way, just set them to the indent I want. Well, I always had my indent independent of the tab size. Which is the way it should be, after all, since one can indent with or without tabs, so indent should not be tied to them. But now I can not; python no longer lets me do that. Honestly, I really don't understand why you *want* to do that. If your indentation is 4 characters, then that would be the natural tab width to use. If you're not going to tie your indent to your tabs, then why even use tabs in the first place? The new rules may look flexible at first sight, but the net effect they have is they push me to use non-default tab size (which is not good), What makes that not good? There is no law anywhere that says tabs are 8 characters. That's just an arbitrary amount that looked appropriate to the people designing the first teletypes. -- http://mail.python.org/mailman/listinfo/python-list
