Re: Tabs -vs- Spaces: Tabs should have won.
* 2011-07-18T10:54:40+10:00 * Steven D'Aprano wrote: Back in 2007, a n00b calling himself TheFlyingDutchman who I am *reasonably* sure was Rick decided to fork Python: http://mail.python.org/pipermail/python-list/2007-September/1127123.html I don't know if they are the same person but quite recently TheFlyingDutchman tried to understand symbols, variables' scope, bindings as well as function and variable namespaces in Common Lisp. It resulted in a long thread, some of it was quite interesting. http://groups.google.com/group/comp.lang.lisp/browse_frm/thread/36000a1f37ebb052/5683597dd587fa87 -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Steven D'Aprano wrote: Why 78? Because it's one less than 79, as mandated by PEP 8, and two less than 80, the hoary old standard. There's another possible reason for the number 78, although hopefully it doesn't still apply today. There's an application I work with that stores free text in database records of 78 chars each. I suspect it's because early versions go back to the MS-DOS era, when it was common to make windows out of box-drawing characters. 80 columns minus two border chars equals 78! -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sunday, July 17, 2011 08:24:12 PM Dotan Cohen did opine: On Sun, Jul 17, 2011 at 17:29, gene heskett ghesk...@wdtv.com wrote: I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. Hey there Gene! Are you not on every mailing list on the internet old man?!? Nope, I miss quite a few in fact. Old? I might be looking at 77 yo in a couple months, and a few things don't work anymore because I'm too sweet (type 2 diabetic), but I can occasionally claim to be a JOAT in a serious tone of voice. Hell Dotan, I even know how vacuum tubes work, including some of the exotic ones, like klystrons. I had to wait till they had invented transistors before I could use my first one, 10 years after I had decided I wanted to be an electronics whiz in about '39 cuz my uncle kept himself in beer money fixing radios. I have also come to the conclusion that the perfect woman, the perfect physics theory, and the perfect programming font are all illusions that men will stride their entire lives in search for but will never find. ROTFLMAO! And right you are. It took me several decades (and 3 women I'll explain someday) to reach that conclusion. Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The person who makes no mistakes does not usually make anything. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On 07/17/2011 08:01 PM, Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Bah, when I started programming on the Apple ][+, we had no lower-case and a 40-column limit on the TV display. But you try and tell the young people today that... and they won't believe ya'. -tkc (expecting somebody to come back with a bit more retro-computing Four Yorkshiremen bit...spinning 360k 5.25 floppy drives? We should be so lucky. I had to hand jump 2000-amp bits with only my tongue, for a CPU architecture invented by Navajo code-talkers...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Bah, when I started programming on the Apple ][+, we had no lower-case and a 40-column limit on the TV display. Keyboards??? That was a luxery! We had mechanical switches that one had to physically push and pull to enter commands. And a 40 column display??? Unheard of! We were happy with several miniature flashlight bulbs! But you try and tell the young people today that... and they won't believe ya'. Fond memories! Malcolm Ref: http://totallytrygve.com/computer.php?item=188picture=0 http://www.logikus.info/english.htm http://oldcomputermuseum.com/logix_kosmos.html http://www.classiccmp.org/pipermail/cctech/2007-October/086682.html http://www.computerhistory.org/collections/accession/102621921 http://www.classiccmp.org/dunfield/ (scanned manual) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Tim Chase python.l...@tim.thechases.com wrote: On 07/17/2011 08:01 PM, Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Bah, when I started programming on the Apple ][+, we had no lower-case and a 40-column limit on the TV display. But you try and tell the young people today that... and they won't believe ya'. Acorn System One: 9 character 7 segment led display and 25 key keypad, 1Kb RAM, 512 bytes ROM. -- Duncan Booth http://kupuguy.blogspot.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Tim Chase wrote: On 07/17/2011 08:01 PM, Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Bah, when I started programming on the Apple ][+, we had no lower-case and a 40-column limit on the TV display. But you try and tell the young people today that... and they won't believe ya'. 40 columns? Luxury! My first computer was a Hewlett Packard 28S handheld programmable calculator, with 22 columns[1] and 32 entire kilobytes of memory! (I don't include my previous programmable calculator, a Casio, or was it a Canon, as the programming language included wasn't Turing Complete.) [1] I think it was 22 columns -- that's what my HP 48GX has, and I'm sure the 28S screen was no larger. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Monday, July 18, 2011 09:32:19 AM Tim Chase did opine: On 07/17/2011 08:01 PM, Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Bah, when I started programming on the Apple ][+, we had no lower-case and a 40-column limit on the TV display. But you try and tell the young people today that... and they won't believe ya'. -tkc (expecting somebody to come back with a bit more retro-computing Four Yorkshiremen bit...spinning 360k 5.25 floppy drives? We should be so lucky. I had to hand jump 2000-amp bits with only my tongue, for a CPU architecture invented by Navajo code-talkers...) No, but my first computer was an RCA Cosmac Super Elf, with a 6 digit led display. I added another 4k of static ram ($400 for the s100 board kit, and about $100 for the S-100 4 slot backplane, and about $125 for a cash register style cabinet that I hid the rest of the hardware, including a 6 volt gell cell for backup battery in) This had an RCA 1802 CPU which had a very interesting architecture. Writing, in machine code entered through its monitor, a program that drove the rest of the hardware and connected to the remote controls of the U- Matic tape machines of the day, including the display hardware I built from scratch with mostly TTL parts, it was replacing the most labor intensive step in preparing a commercial for use with an Automatic station break machine by applying a new frame accurate academy leader and the tones to control it directly to the finished commercial tape. That automated a very timing critical step, and removed a dub cycle from commercial production at KRCR in 1979, and was still in use in 1994 the last time I checked. How many of our code projects can make that claim? I still have a paper copy of the code in a bag on the top shelf. Interesting sidelight here. In 1980, Microtime brought a much more primative device to do that to the NAB show, which I stopped and looked at, and when I could control my laughing, said I had already done that, functionally far better than this attempt. Since they are as lawyer top loaded as Apple, I guess they assumed I had also copyrighted and patented it, so it was gone the next day they wouldn't even admit they had had it the day before. In 1987 I made a better version of the EDISK that Grass Valley sold as an accessory for the 300 series video production switchers, for $20,000. Theirs had a 2 digit display for file names ran at 1200 baud. Mine had a whopping 32 column display and english filenames and ran at 4800 baud, running on a TRS-80 Color Computer, I had $245 in the hardware. It was still in use when I retired in 2002, but when that forced a replacement of the 300 because of custom parts availability, the new CE gave me back the old machine. I still have it, and several more of them. The 6809 was not the crippled, drain bamaged processor the 6502 was. OS-9, the color computers multiuser/multitasking OS, has now grown to also execute on the hitachi 6309 cpu chip, and is about 2x faster now than then, and we now call it Nitros9. That is essentially todays linux, running on an 8 bit bus, and was my teacher, causing me to only have one legal winderz install in the house ever as it was on the laptop (XP) I bought quite a few years back now. Long since history, that machine has had linux on it for about 6 years now. FWIW, I met one of the code talkers when I was the CE at KIVA-TV in the late 70's. That was another example of how we have screwed the First Americans' and I had better not get started. Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Beneath this stone lies Murphy, They buried him today, He lived the life of Riley, While Riley was away. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Thorsten Kampe thors...@thorstenkampe.de writes: The perfect programming font is just the one that looks so good that you would also use it for writing email. Dejavu Sans Mono is pretty good. Consolas looks also looks good but it is Windows only. How is Consolas Windows only? Not that I'd put it in my Windows-free systems, but I don't see why you couldn't? Everything uses TrueType fonts now. I use a font called Dina on this laptop in Emacs. Not pretty but very readable, has a slashed zero and the wide characters are clearly separated, so something like www looks like three ws, not a block of triangle wave. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Anssi Saari (Mon, 18 Jul 2011 19:28:49 +0300) Thorsten Kampe thors...@thorstenkampe.de writes: The perfect programming font is just the one that looks so good that you would also use it for writing email. Dejavu Sans Mono is pretty good. Consolas looks also looks good but it is Windows only. How is Consolas Windows only? Not that I'd put it in my Windows-free systems, but I don't see why you couldn't? Consolas ships with all versions of Windows Vista and Windows 7, including Home Basic. If you’re using Visual Studio 2005, you can download Consolas from Microsoft. If not, you still may be able to use the font, though your mileage may vary. I was able to install it on a Windows XP SP1 machine that doesn’t have any version of Visual Studio. This PC does have the Microsoft .NET Framework SDK which creates various “Microsoft Visual Studio” folders under “Program Files”. These may cause the Consolas installer to think I do have VS 2005. I got no error messages, and the font was instantly available in all applications. Another way to get Consolas is to download and install the free PowerPoint Viewer 2007 from Microsoft. This works on any computer with Windows 2000 SP4 or Windows XP SP1 or later. In addition to the PowerPoint Viewer 2007 itself, the installer will install the following fonts: Calibri, Cambria, Candara, Consolas, Constantia and Corbel. Only the Consolas font is monospaced. All these fonts ship with Windows Vista and Windows 7. http://www.editpadpro.com/fonts.html -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On 18/07/2011 14:52, Duncan Booth wrote: Tim Chasepython.l...@tim.thechases.com wrote: On 07/17/2011 08:01 PM, Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Bah, when I started programming on the Apple ][+, we had no lower-case and a 40-column limit on the TV display. But you try and tell the young people today that... and they won't believe ya'. Acorn System One: 9 character 7 segment led display and 25 key keypad, 1Kb RAM, 512 bytes ROM. 1KB RAM? Wow! Science of Cambridge Mk14, with extra RAM and I/O chip, total of 640 bytes (some reserved for monitor program). Main RAM at 0xF00..0xFFF, extra RAM at 0xB00..0xBFF, I/O RAM somewhere else... -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Gregory Ewing wrote: Anders J. Munch wrote: Cameron Simpson wrote: Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. Just like in the old days:) Most editors can be configured to do that. True. Where they fall down, in my experience, is that having inserted those spaces, if you want to delete them you typically have to backspace over them one at a time. Now that's a BAD source code editor! Try one running on the Eclipse platform, like PyDev (single plugin or in Aptana, also as Eclipse plugin). But, even vim(1) has auto-indent *and* `', so … I don't enjoy that experience, which is why I have BBEdit Lite set up to use tab-only indentation. If I'm feeling conscientious, I convert to spaces before sharing the code with others. But tabs work better for me given the tools I use and the way I like to work. YMMV, of course. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Anssi Saari wrote: Thorsten Kampe thors...@thorstenkampe.de writes: The perfect programming font is just the one that looks so good that you would also use it for writing email. Dejavu Sans Mono is pretty good. Consolas looks also looks good but it is Windows only. How is Consolas Windows only? Not that I'd put it in my Windows-free systems, but I don't see why you couldn't? Consolas is _not_ free software, hence Inconsolata which is. Windows-only is too strong a classification for Consolas, though. Everything uses TrueType fonts now. Rather OpenType, but that is beside the point. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On 01/-10/-28163 02:59 PM, Steven D'Aprano wrote: Tim Chase wrote: On 07/17/2011 08:01 PM, Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Bah, when I started programming on the Apple ][+, we had no lower-case and a 40-column limit on the TV display. But you try and tell the young people today that... and they won't believe ya'. 40 columns? Luxury! My first computer was a Hewlett Packard 28S handheld programmable calculator, with 22 columns[1] and 32 entire kilobytes of memory! (I don't include my previous programmable calculator, a Casio, or was it a Canon, as the programming language included wasn't Turing Complete.) [1] I think it was 22 columns -- that's what my HP 48GX has, and I'm sure the 28S screen was no larger. My first programmable calculator had 1.5k of RAM, display was 13 digits wide, and it took an optional 2k of PROM via a plugin socket on top. I wrote a commercially sold navigation program for that calculator. The program was used on ships in 1974 and later. Later I squeezed the code a bit and made room for a dead reckoning program and great circle calculator. I didn't write a cross assembler for it till after this project was finished. That assembler ran on a machine with 64 column display. DaveA -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Thomas 'PointedEars' Lahn wrote: I am getting the idea here that you mean the right thing, but that you explain it wrong. Feel free to write the much longer essay that explains it all unambiguously, I'm not going to. regards, Anders -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Mon, Jul 18, 2011 at 02:55, Andrew Berg I think the reason the idea isn't dead is because of the emergence of new devices with small displays (tablets/smartphones/etc.) and their increasing popularity. When writing code that is meant to be run on desktops or servers, the 80-column limit is mostly irrelevant, but Python running on these small devices, especially with Python code being interpreted rather than compiled, it's convenient to edit code on those platforms, where there is a significant column limit. Let me see if I understand: because there exists a possibility that someone might want (not need) to edit code on a telephone to make a quick edit to code being interpreted on that machine, _all_ Python code should limit itself to a line width that may or may not wrap on a telephone screen? Is that the argument in favor of an 80-character line width? -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.18 01:51 PM, Dotan Cohen wrote: Let me see if I understand: because there exists a possibility that someone might want (not need) to edit code on a telephone to make a quick edit to code being interpreted on that machine, _all_ Python code should limit itself to a line width that may or may not wrap on a telephone screen? Is that the argument in favor of an 80-character line width? I doubt that's /the/ argument. I speculated that it's one of the reasons that a column limit still has relevance. I did not say that I thought the argument had merit; I make no judgment either way. Also, I'm sure more than quick edits are done on these phones. Depending on the focus of the project, it may be best to do most, if not all testing on that device. Personally, I think that 80 is pretty arbitrary now, and not the best limit. I'm more comfortable with 120-130 myself. In any case, Python won't complain about how many characters are on a line, and that's the way it should be. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOJIQ9AAoJEPiOA0Bgp4/LhgUH/iFWmSZXw9Rw0SyHpRZ4gPvb WahJhf3j0bAnWnJWueAMgzgTMzuZv/6V6x8Yka/KewjBk5/coIsCNHgL+LR8rrat YbN3FTQneuTlwtkj+2wQV+pQEQM6i2eVs50TEji98NW1jqtwW3UxhT/x4efaUHtc 9iHZRZTqmNMlXJWfRgfD6mC0bHGGAUTadyetGHicdZYy+AIo8Di7tObd5SwuQxIM 8U7aRkupiOpRaUj3YXXsIuWeio+SirpnJiVdWadBbgsdBSjI8jJl2MqXq52BieA6 5avnDGA+6575+1GNTaLXHNyFpgNkTUXCb5cOf3TP6zk0q9EtNxYY9dxQ8QJmdU8= =sKG0 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Tue, Jul 19, 2011 at 5:06 AM, Andrew Berg bahamutzero8...@gmail.com wrote: Personally, I think that 80 is pretty arbitrary now, and not the best limit. I'm more comfortable with 120-130 myself. In any case, Python won't complain about how many characters are on a line, and that's the way it should be. It's a question of policy, which is in the purview of the maintainer of the codebase. But since Python itself has a lot of Python code, the policy applied to its standard library is going to be looked at by everyone as having special status. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
In article Xns9F2695C6AAA73duncanbooth@127.0.0.1, Duncan Booth duncan.booth@invalid.invalid wrote: Tim Chase python.l...@tim.thechases.com wrote: On 07/17/2011 08:01 PM, Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Bah, when I started programming on the Apple ][+, we had no lower-case and a 40-column limit on the TV display. But you try and tell the young people today that... and they won't believe ya'. Acorn System One: 9 character 7 segment led display and 25 key keypad, 1Kb RAM, 512 bytes ROM. HP-9810. http://www.hpmuseum.org/98xx/9810n3qs.jpg. BTW, if anybody has one of these in working condition that they want to get rid of, let me know. I'd love to play with one again. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Andrew Berg bahamutzero8...@gmail.com wrote: I'm not saying it's wise Why not? It just makes it more difficult to follow the pattern when you add new code. If you have an editor mnaging that for you, then you might as well have the editor go all tabs or all spaces to avoid trouble. Vi and friends with ts=8 and sw=4 will use 4 spaces, then tab, then tab plus 4 spaces, then two tabs, etc. That's recognizable, but I still convert such a file to all spaces when I find one. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2011.07.16 06:06 PM, Tim Roberts wrote:
That's not true. Python allows tabs and spaces to be used in the
same source file, and even in the same source line.
You're right. TabError is only raised if the initial indentation is
inconsistent.
Not legal:
def spam():
tabprint('Wonderful spam!\n')
4 spacesprint('Bloody Vikings!')
Legal:
def eggs():
tabprint(
tabtab'Blech!\n',some spaces to align'Whaddya mean, blech?\n',
tabtab'I don\'t like spam!\n',spaces to align'...'
tabtab)
I'm not saying it's wise
Why not?
- --
CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
PGP/GPG Public Key ID: 0xF88E034060A78FCB
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAwAGBQJOIo9DAAoJEPiOA0Bgp4/LOk4IALdGAOb3RXyunzWiDBn3vNpr
fIR7NdtFmNc1QtvxGm3RVV+wxUjVjeCv5bXuAr/RvYDWm+MRCCr+VbexV52sFAbm
2G1g4rWQnRPGXvDMTq1bjJKcYFnJga/LHBqnM0mWTAms6o4d+Pj5ZJ5uK5CsFcx+
oL7y3YuVrtw/hYRNqTaxhMMy3erayGt4h3sEDIaekNbaNwNFy/7M6+tFzPBNHupT
EZAjkVewIDEgRqd+hCZfuanuS4mX6P2pup1dgAUiMAjEXRJO4xQ1JmmuCVXiccE/
HyiPtiIsTorDGGtzkaSpBwc1RVeZEeluO+VeVt9pIGCupKnDcVty+1R1C1kmS2U=
=QXtI
-END PGP SIGNATURE-
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sat, Jul 16, 2011 at 9:09 PM, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. With pure spaces, the text is laid out reliably for us both. And so I have my editor set to that behaviour. I have reluctantly come to do the same thing. There is a plethora of broken tools out there that don't handle tabs well, and consequently even though tabs for indentation are objectively better, I use spaces because it is less worse than the alternative. This. I used to think that tabs were better, for pretty much the reasons Rick outlined, but I've had enough problems with editors munging my tabs that I eventually found it simpler in practice to just go with the flow and use spaces. Of course, there is also another major problem with tabs that I have not seen pointed out yet, which is that it's not possible to strictly adhere to 80-column lines with tabs. I can write my code to 80 columns using 4-space tabs, but if somebody later tries to edit the file using 8-space tabs, their lines will be too long. Rick's answer to this might be to just mandate that everybody uses 4-space tabs, but then this would pretty much defeat the purpose of using tabs in the first place. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT)) 3) Tabs create freedom in the form of user controlled indention. Indention width should be a choice of the reader NOT the author. We should never code in indention width; but that is EXACTLY what we are doing with spaces! No, the reader should be able to choose the indention width without ANY formatting required or without any collateral damage to the source code. Tabs offer freedom, spaces offer oppression. Why are you so obsessed with indentation length? Indentation length is just /one/ of the formatting choices that the author makes for the reader - and probably the /least/ significant one. There is for instance maximum line length, the number of empty lines, the author's method of alignment, spaces between the equals sign and so on. These are all much more dominant in the source code and none of this is left for the reader's disposition. Compare for instance variable= 11 anothervariable = 22 def whatever (prettylong = 1, alsoprettylong = 22, anotherone = 33): pass to variable=11 anothervariable=22 def whatever (prettylong=1, alsoprettylong=22, anotherone=33): pass Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 1:29 AM, Andrew Berg bahamutzero8...@gmail.com wrote:
You're right. TabError is only raised if the initial indentation is
inconsistent.
Not legal:
def spam():
tabprint('Wonderful spam!\n')
4 spacesprint('Bloody Vikings!')
Legal:
def eggs():
tabprint(
tabtab'Blech!\n',some spaces to align'Whaddya mean, blech?\n',
tabtab'I don\'t like spam!\n',spaces to align'...'
tabtab)
Even this is legal:
def eggs()
tabif spam:
tabspacesprint(Spam and eggs)
tabelse:
tabtabprint(Just eggs)
It's only when you're inconsistent about the added indent of a single
block that Python will complain.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 02:32 AM, Ian Kelly wrote: Of course, there is also another major problem with tabs that I have not seen pointed out yet, which is that it's not possible to strictly adhere to 80-column lines with tabs. I can write my code to 80 columns using 4-space tabs, but if somebody later tries to edit the file using 8-space tabs, their lines will be too long. Setting an editor to read a tab as 8 spaces is just plain silly if your display is limited to 80 characters/line. Inserting 8 spaces as one indent is also a bit silly, but if you're going to do it, it's your responsibility to make sure the line is still less than 80 characters. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIpSlAAoJEPiOA0Bgp4/L7JwH/3zysmIUDPyy6f4X7oKAFye0 YcjgC5vM5gHQ4HGemGrIGBuurYffcC1XL3Cf7V5y4Rf6F+XwueLN1C4YEl8r1dtw r+E6pVsFM4e5keLoWb4s+IeBu0HV6GqHyXkEmj8kV8QG9dZJbWML42+AwGauXdO/ IUne0zp1ojHbAY5lDVJnRako3hMyXuxJjpERZXXh/Qe+z9GyaQ4/AHrVFsYyWS3A ZE9L7y/Yv/Bba9DjYLs1sgFDGVF996yQFAnhPw52cmlahh3/1vbpV+CPQhIeVVH8 PqObrFw9cdAMoo/kVoPRmcNBU+Xf9tlTDUS5w6bn7WjrYdnd28VesZ03uaapWx8= =tWjf -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Andrew Berg (Sat, 16 Jul 2011 19:29:30 -0500) Of everything I've read on tabs vs. spaces, this is what makes the most sense to me: http://www.iovene.com/61/ Interesting one, especially the - from the coder's point of view - artificial distinction between indentation and alignment. What is the difference between indentation and alignment? Well, indentation works with tabs, alignment not. The author's conclusion simply just use what ever you want for indenting, but use spaces for aligning leaves only two choices for Python programmers: use spaces for indenting or don't align. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sat, Jul 16, 2011 at 19:51, rantingrick rantingr...@gmail.com wrote: -- Evidence: Tabs ARE superior! -- I am also a recent spaces-to-tabs convert. One of the reasons is that I've discovered that programing in a non-fixed width font is a real pleasure, but the spaces are too narrow. Tabs alleviate that. I'm still looking for the perfect programming font. Suggestions welcomed. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 03:15 AM, Dotan Cohen wrote: programing in a non-fixed width font is a real pleasure If you're masochistic, maybe. Do you find fixed-width fonts ugly? I really would like to know why anyone would use a non-fixed-width font for programming. I'm still looking for the perfect programming font. Suggestions welcomed. I use Courier New. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIp7iAAoJEPiOA0Bgp4/LWzcH/0iHzlOF47JOnIJfPjbhhTu5 KbrkE3mkQEwDtdNT4FUQb/aklHqvlmd4DWgxg25eXZ8PWAfQBPjnfKWHDSvWz7+2 rt6MNXLfh/6wzAAAT2nJNl5QabeANYBEbSE3EvgnMe5LfVWR/vVl2upmTfxAaoWJ gH1Vp6TstAZluh8kcmii8dyrHXiubh9K84YS+FdRzLX3lz5mtGe+c20DWeeMiMxU NlIzfWQVzZa4avU+1GdWFXwgKJP5chf7lyrg1UKFmSeQUeR4MeOx1PP8spkQy51i fl4+VCCHOxL3Z5KVrM/aO0wTNwjYy+QddkGr+Hdk/QDNoqJwwYi8e2Nao/06HUY= =3pB7 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 02:56 AM, Thorsten Kampe wrote: What is the difference between indentation and alignment? Well, indentation works with tabs, alignment not. The use of spaces for indentation is as much of a hack as the use of tabs for alignment is. Not everyone agrees on how many spaces an indent should be (whether an indent is a tab or a space-tab), which is a good reason to use tabs. In fact, spaces have absolutely /no/ advantage over tabs when it comes to pure indentation. It may be possible to configure an editor to compensate using space-tabs (and perhaps even detect the length of indents, changing the number of spaces to conform to what the reader thinks is the right number of spaces per indent), but this is all to make a pretty delicate environment just to be even with tabs. On the flip side, tabs can't maintain alignment because again, not everyone agrees on how big a tab should be. This is a good reason to use spaces. Using tabs for indentation and spaces for alignment solves the problem. I really can't think of any problems this would cause that aren't superficial. The author's conclusion simply just use what ever you want for indenting, but use spaces for aligning leaves only two choices for Python programmers: use spaces for indenting or don't align. It's possible to indent with tabs and align with spaces in Python; see my earlier post. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIp8PAAoJEPiOA0Bgp4/LpjYIAIa+Qpw+1Uhsdv8R3NkH4yat h7axOgwpq2SqbU9KsJpmJbC737C2JWj3GrCzkSfExjlrG2Wv5qB7U5hgFbJVeTU/ 1paBZtXP0BZgXLEeZwlIKJDT3HF28sj7GCMFoP6KhX0v7oe7BsaRyriIBAQWX4Hh p8NrMfr16tkGQXFmTPyu5UHdiCX35/9ywR1hw96h4H1J6sht1Q6N47Xx4EI4DN/X eU5wY7qrJPjinYD7N3uQGpRhHKjTIAWRSPxFtN6voP9Y+6KGPH+e2eDFV06h8Hi1 /tPQtbfWROdN1c10TL57FDBqW+Q32gMB3z60/XMPWhB5Mz0a/dFLou5bdDhvtvc= =w8GN -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Andrew Berg (Sun, 17 Jul 2011 03:36:31 -0500) Not everyone agrees on how many spaces an indent should be (whether an indent is a tab or a space-tab), which is a good reason to use tabs. Not everyone who doesn't agree on indent size actually cares enough about indent size - especially in someone else's code. I'd say it's probably rather the majority making this whole debate artificial. I like my indent four spaces. If you like eight, wonderful, I don't care, it's your code. If I want to use your code in my own, I completely have to reformat your code anyway. And if we work on a project together, we have to agree on formatting anyway, the indent size being the least important one. This whole debate is artificial. Using tabs for indentation and spaces for alignment solves the problem. I really can't think of any problems this would cause that aren't superficial. Sorry, you didn't understand my point. My point is: the distinction between indentation and alignment is superficial. Indentation /is/ exactly the same as alignment. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 04:33 AM, Thorsten Kampe wrote: Not everyone who doesn't agree on indent size actually cares enough about indent size - especially in someone else's code. I'd say it's probably rather the majority making this whole debate artificial. It's more of a debate on what's good practice when sharing with others (especially when many developers work together and there are no strict guidelines enforced, which is not uncommon with large open-source projects). Obviously, one can completely disregard all guidelines for writing readable and maintainable code, and no one will care if no one sees it. And if we work on a project together, we have to agree on formatting anyway, the indent size being the least important one. How is indent size unimportant with regard to formatting? Or are you talking about design as part of formatting? This whole debate is artificial. Only if no one cares about your code. Sometimes that's more or less the case, and sometimes it isn't. It's also worth mentioning that some people have an almost religious fervor when it comes to spaces and tabs. That can make the issue much more relevant than other things that are more important. Many editors can work around either style (at least in some sense), so in many circumstances, it is indeed artificial, but there are other circumstances where it matters a lot (often more than it should). Sorry, you didn't understand my point. My point is: the distinction between indentation and alignment is superficial. Indentation /is/ exactly the same as alignment. I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIrMtAAoJEPiOA0Bgp4/LlHIH/j42a2rms3GDPzAkl8iLZvCq okJULVeqxAeW4gKFDnPHaagyqqj+d+jbeuEArPU0i3PPEaajCFk/0h53D6tP3lpf Gt8Iyg5cPjmnUchIuwdI1evSISIJoKU44m2x6W3joDzy+fqHfy14K8wdVV69oTKk YzUb/5mU2/xyW0ULpOMCQwTSBsbE+bQxPEoULNPoUHR0bglPqgrDkHlFkD6iOVRt IpL4exPXM8OxKknir7omN7mHNXD2InJqV2QE6nHwirywMxVrWtuIpM4YQ2RhRdES zfjelskyvp2KOG+VwLxaYmHHbonzRyMJY51w4kw2C7y4nAYzjiN5z4rgLrPyo2w= =FKP/ -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500) And if we work on a project together, we have to agree on formatting anyway, the indent size being the least important one. How is indent size unimportant with regard to formatting? Take some code or yours and format it with three and with six spaces. Then you will see how unimportant it is: it looks virtually the same. Or as I've written in another posting: There is for instance maximum line length, the number of empty lines, the author's method of alignment, spaces between the equals sign and so on. These are all much more dominant in the source code and none of this is left for the reader's disposition. Compare for instance variable= 11 anothervariable = 22 def whatever (prettylong = 1, alsoprettylong = 22, anotherone = 33): pass to variable=11 anothervariable=22 def whatever (prettylong=1, alsoprettylong=22, anotherone=33): pass This whole debate is artificial. Only if no one cares about your code. Only if you don't care about indent length - which I again state, most people (probably) don't. It's also worth mentioning that some people have an almost religious fervor when it comes to spaces and tabs. I know. These are people like rantingrick who start artificial threads like this with artificial problems like tabs versus spaces to liberate the common coder. Sorry, you didn't understand my point. My point is: the distinction between indentation and alignment is superficial. Indentation /is/ exactly the same as alignment. I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. Or your example: setup( name = 'Elucidation', version = '0.0.1-WIP', py_modules = ['elucidation'], author = 'Andrew Berg', author_email = 'baha...@digital-signal.net', url = '', platforms= 'Windows', description = 'Provides a class for storing information on multimedia files that are to be converted or remuxed and methods to convert and remux using popular tools.' ) The keywords are aligned by indenting. In the left of an assignment case it makes a difference for the Python compiler, in the alignment case it doesn't. In both cases, it makes a difference to the human who indents/aligns to group similar things and blocks. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 11:35, Andrew Berg bahamutzero8...@gmail.com wrote: programing in a non-fixed width font is a real pleasure If you're masochistic, maybe. Do you find fixed-width fonts ugly? I don't find that fixed-width fonts are ugly, but variable-width fonts sure are more of a pleasure. And with code-colouring in any good IDE, there is no real need to have the dot or other tiny characters jump out and announce their presence. So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? I really would like to know why anyone would use a non-fixed-width font for programming. Aesthetics. I'm still looking for the perfect programming font. Suggestions welcomed. I use Courier New. Have you looked at the Droid fixed-width fonts? Very nice, and easy to distinguish 0 from o or O. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 4:11 pm, Dotan Cohen dotanco...@gmail.com wrote: On Sun, Jul 17, 2011 at 11:35, Andrew Berg bahamutzero8...@gmail.com wrote: programing in a non-fixed width font is a real pleasure If you're masochistic, maybe. Do you find fixed-width fonts ugly? I don't find that fixed-width fonts are ugly, but variable-width fonts sure are more of a pleasure. And with code-colouring in any good IDE, there is no real need to have the dot or other tiny characters jump out and announce their presence. So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? I really would like to know why anyone would use a non-fixed-width font for programming. Aesthetics. Its more (or less depending...) than just aesthetics. Its about optimization. On a fixed width font an 'i' is as wide as an 'm' as a '.' This means that a fwf is either a unreasonably small or the lines are too long. [Note: I use only fwf because all the tools I know/use/tried are broken for vwf] -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300) So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? Alignment doesn't line up. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Steven D'Aprano wrote: I can't fathom why 8 position tabs were *ever* the default, let alone why they are still the default. That's because they were not invented as a means for programmers to vary indentation. Originally, tabs were a navigation device: When you press the tab key, you skip ahead to the next tab column. The notion that whitespace characters are inserted into the text would have been very alien to someone using text processing software anno 1970. Same thing with space and enter; on typewriters the space bar doesn't type anything onto the paper, it moves to the next column, and that thinking carried over to computers. The reason the tab stop is a full 8 positions: for faster navigation. If it were 3 positions, it would take forever to skip from the start of line to column 60. You'd appreciate that, if you were e.g. writing a fiduciary report with some text to the left and two number columns to the right, back in the day before spreadsheets and word processor tables. Skip a column or two too far? Adjust by backspacing (another navigation key). As for why 8 is still the default - well, what else should it be? 2, 3, 4, 5? I for one am thankful that we have so far been spared the flamewar armegeddon of all the world's programmers trying to agree on that. Cameron Simpson wrote: Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. Just like in the old days:) regards, Anders -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Thorsten Kampe wrote: * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500) I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. You might want to check your English dictionary. Indenting is commonly understood in typography as To begin (a line or lines) at a greater or less distance from the margin¹. In particular, in computer programming it usually means that there is, at most, whitespace on the left of the text.² In that sense, the above is _not_ indentation (or indenting), as neither variable nor variable = consist only of whitespace. It is only aligning.³ HTH ___ ¹ http://en.wiktionary.org/wiki/indenting ² http://en.wikipedia.org/wiki/Indent_style ³ http://en.wiktionary.org/wiki/aligning -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Dotan Cohen wrote: On Sat, Jul 16, 2011 at 19:51, rantingrick rantingr...@gmail.com wrote: -- Evidence: Tabs ARE superior! -- I am also a recent spaces-to-tabs convert. One of the reasons is that I've discovered that programing in a non-fixed width font is a real pleasure, but the spaces are too narrow. Tabs alleviate that. Not using a fixed-width font avoids this problem and others in the first place. I'm still looking for the perfect programming font. Suggestions welcomed. I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are designed for programming and are near perfect in that regard. However, I have decided for Deja Vu Sans Mono for reading and writing Usenet articles because it supports more Unicode characters and can be sized appropriately for running text. But, all of them are fixed-width fonts. I do not understand how you can consider using a non-fixed-width font in programming a real pleasure as many them show a lot of ambiguities in source code. Take for example the lowercase l (el) vs. the capital I (ai) vs. the | (pipe) character, or the 0 (zero) vs. the capital O (oh) character in Arial. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Ian Kelly wrote: but if somebody later tries to edit the file using 8-space tabs I came across this and I like to put a note on top of the script to remember to modify it accordingly. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sunday, July 17, 2011 10:28:16 AM Dotan Cohen did opine: On Sat, Jul 16, 2011 at 19:51, rantingrick rantingr...@gmail.com wrote: -- Evidence: Tabs ARE superior! -- I am also a recent spaces-to-tabs convert. One of the reasons is that I've discovered that programing in a non-fixed width font is a real pleasure, but the spaces are too narrow. Tabs alleviate that. I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Men will always be men -- no matter where they are. -- Harry Mudd, Mudd's Women, stardate 1329.8 -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200) Thorsten Kampe wrote: * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500) I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. You might want to check your English dictionary. Indenting is commonly understood in typography as To begin (a line or lines) at a greater or less distance from the margin¹. In particular, in computer programming it usually means that there is, at most, whitespace on the left of the text.² In that sense, the above is _not_ indentation (or indenting), as neither variable nor variable = consist only of whitespace. It is only aligning.³ *doublesigh* that is actually the point I was trying to make. From a programmer's point of view the distinction is artificial because he does essentially the same: press the tab key or the indent button to move the stuff right from the cursor to the right so it gets aligned with the stuff above. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* gene heskett (Sun, 17 Jul 2011 10:29:03 -0400) On Sunday, July 17, 2011 10:28:16 AM Dotan Cohen did opine: I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. The perfect programming font is just the one that looks so good that you would also use it for writing email. Dejavu Sans Mono is pretty good. Consolas looks also looks good but it is Windows only. Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 2:32 am, Ian Kelly ian.g.ke...@gmail.com wrote: This. I used to think that tabs were better, for pretty much the reasons Rick outlined, but I've had enough problems with editors munging my tabs that I eventually found it simpler in practice to just go with the flow and use spaces. Solution: STOP USING BROKEN TOOLS!!! Of course, there is also another major problem with tabs that I have not seen pointed out yet, which is that it's not possible to strictly adhere to 80-column lines with tabs. Of course it is. The litmus test will be four-space-tab-view. If the code overflows in this view type then the code will fail the 80 char maximum limit. This argument is ridiculous anyhow. It is up to you how to view the source. If you view it in 80 width tabs don't start complaining later when one indention goes off the page. Would you view the source with 50 point font? Jeez. I can write my code to 80 columns using 4-space tabs, but if somebody later tries to edit the file using 8-space tabs, their lines will be too long. THEIR LINES is the key words. A tab control is a tab control is a (you guessed it!) a tab control. No matter how small or large your tab settings are the source only reflects one tab control char per press of the tab key. Heck, people are already (unwisely) using 8-space- spaces and i don't hear you making the same argument. Rick's answer to this might be to just mandate that everybody uses 4-space tabs, but then this would pretty much defeat the purpose of using tabs in the first place. We already mandate four space spaces so what is the difference? I'll tell you, the difference is Freedom and Unity living in perfect harmony. Yes, we mandate that all code must meet the 80 line limit in four- space-tab-view, and if it doesn't, it's not allowed in the stdlib. Plain and simple. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Excerpts from Thorsten Kampe's message of Sun Jul 17 11:10:57 -0400 2011: The perfect programming font is just the one that looks so good that you would also use it for writing email. Dejavu Sans Mono is pretty good. Consolas looks also looks good but it is Windows only. I use inconsolata, but I hate the look of it un-bold at small sizes, so I keep it bold all the time. I've started using DejaVu very recently because of that, it looks better on screen at small sizes (pixelsize=9 in my ~/.Xdefaults, as opposed to the 12 and bold with inconsolata). Inconsolata looks great on paper, though. DejaVu Sans Mono isn't the prettiest thing but it certainly gets the job done. -- Corey Richardson Those who deny freedom to others, deserve it not for themselves -- Abraham Lincoln signature.asc Description: PGP signature -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 2:35 am, Thorsten Kampe thors...@thorstenkampe.de wrote:
* rantingrick (Sat, 16 Jul 2011 09:51:02 -0700 (PDT))
3) Tabs create freedom in the form of user controlled indention.
Indention width should be a choice of the reader NOT the author. We
should never code in indention width; but that is EXACTLY what we
are doing with spaces! No, the reader should be able to choose the
indention width without ANY formatting required or without any
collateral damage to the source code. Tabs offer freedom, spaces offer
oppression.
Why are you so obsessed with indentation length? Indentation length is
just /one/ of the formatting choices that the author makes for the
reader - and probably the /least/ significant one.
I am not OBSESSED with it, i am just PERTURBED that we are not using
tabs; since tabs offer freedom to view the source at ANY indentation
level you choose REGARDLESS of what the author thought was
appropriate. It is a wise choice to only allow tabs in a language that
has FORCED indention. This is one way we can actually promote freedom
whist maintaining unity.
There is for instance maximum line length,
I like to keep lines at 80. Sometimes i go over if the code is not
something you would need to read often. If the code was to go into the
stdlib i would make sure it was 110% style guide compliant.
the number of empty lines,
I hate vertical white-space. I follow Python style guide suggestions,
and then some! I hate when people insert spaces into code blocks and
function/method bodies. If you feel a space must be inserted then that
is a good clue you should be using a comment there instead. Vertical
breaks should only happen before and after classes, methods,
functions, groups of GLOBALS, groups of import statements. Think of
func/method bodies as paragraphs and classes as sections of a book.
Two vertical spaces between classes and one vertical space between
func/methods.
the author's method of alignment, spaces between the equals sign and so
on.
I believe non-compliant spacing in args should throw an syntax error.
I hate this:
func( arg1 = 1, arg2 = 3 )
It should be...
func(arg1=1, arg2=3)
Much easier to read when formatted into logical groups.
These are all much more dominant in the source code and none of
this is left for the reader's disposition.
It should be MANDATED. And these @holes who refuse to format their
code in a community standard will suffer the plague of syntax errors.
Who do these people think they are? Do they believe the rules do not
apply to them? I'll tell you who they are, they are F'ING format
criminals.
Compare for instance
variable = 11
anothervariable = 22
def whatever (prettylong = 1,
alsoprettylong = 22,
anotherone = 33):
pass
to
variable=11
anothervariable=22
def whatever (prettylong=1, alsoprettylong=22, anotherone=33):
pass
Both examples show non-compliance to the Python style guide.Except for
this...
--
FUNCTIONS/METHODS
--
def whatever(
prettylong=1,
alsoprettylong=22,
anotherone=33):
OR
def whatever(prettylong=1, alsoprettylong=22,
anotherone=33):
I think the second is more readable for block openers. Note the
closing bracket and colon on last line!
--
CONTAINER TYPES
--
d = {
1:1,
2:2,
3:3,
4:4,
}
Note closing bracket on newline; and all alone! For hand stitching
containers you should put the closer on a newline that matches the
opener's indention level.
--
VARIABLES
--
variable = 11
anothervariable = 22
Stop trying to be an individual in a community. When you write code
for just you then write it any way you like. Go ahead and use that
Joker font and 10 space indention. Go ahead an use foolish spacing and
whatever. However when you are writing code in public or for the
stdlib you should always be Style Guide compliant.
You guys should feel lucky i am not the BDFL, because i would cast
plagues of exceptions on your lazy butts!
--
http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 5:42 am, Thorsten Kampe thors...@thorstenkampe.de wrote: When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. Or your example: setup( name = 'Elucidation', version = '0.0.1-WIP', py_modules = ['elucidation'], author = 'Andrew Berg', author_email = 'baha...@digital-signal.net', url = '', platforms = 'Windows', description = 'Provides a class for storing information on multimedia files that are to be converted or remuxed and methods to convert and remux using popular tools.' Why do you feel the need to layout your code in a GUI-listview manner. Next you'll want column titles and column sorting... Jeez! This is what you should have done... DESC = Provides a class for storing information on multimedia files that are to be converted or remuxed and methods to convert and remux using popular tools. setup( name='Elucidation', version='0.0.1-WIP', py_modules=['elucidation'], author='Andrew Berg', author_email='baha...@digital-signal.net', url='', platforms='Windows', description=DESC, ) -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Mon, Jul 18, 2011 at 2:29 AM, rantingrick rantingr...@gmail.com wrote: You guys should feel lucky i am not the BDFL, because i would cast plagues of exceptions on your lazy butts! BDFL = Benevolent Dictator For Life. Note that first word. ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 4:49 am, Anders J. Munch 2...@jmunch.dk wrote: Originally, tabs were a navigation device: When you press the tab key, you skip ahead to the next tab column. The notion that whitespace characters are inserted into the text would have been very alien to someone using text processing software anno 1970. Same thing with space and enter; on typewriters the space bar doesn't type anything onto the paper, it moves to the next column, and that thinking carried over to computers. And how much longer are we going to live in the past? Who cares about backward compatible tabs. Mandate the four space tab now! Mandate that Python takes four space and four space only! We shall lead the charge for universal tab unity in all programming languages. How long are you going to accept this multiplicity? It's ridiculous. The reason the tab stop is a full 8 positions: for faster navigation. If it were 3 positions, it would take forever to skip from the start of line to column 60. You'd appreciate that, if you were e.g. writing a fiduciary report with some text to the left and two number columns to the right, back in the day before spreadsheets and word processor tables. Just in case you were not aware this the year 2011. Spreadsheets have been around for a LONG time. Stop living the past. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Mon, Jul 18, 2011 at 2:53 AM, rantingrick rantingr...@gmail.com wrote: [a whole lot of guff] Rick, you need to: 1) Grab the Python source code 2) Make your own version of Python that works the way you want it 3) Call it something different 4) Start your own mailing list. Put your money - or, in this case, development time - where your big ranting mouth is. Prove that your ideas are worth something by acting on them. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 12:11 pm, Chris Angelico ros...@gmail.com wrote: On Mon, Jul 18, 2011 at 2:53 AM, rantingrick rantingr...@gmail.com wrote: [a whole lot of guff] Rick, you need to: 1) Grab the Python source code 2) Make your own version of Python that works the way you want it 3) Call it something different 4) Start your own mailing list. It's funny you mention this because i am creating a specification for a Python 4000 fork that removes all ambiguities and multiplicity from the language. Very soon i will be posting the spec for review within this group. Maybe some of you will come to your senses and start implementing these important features in CPython. If not, i am not going to waste my time forever trying to convince idiots that the world is in fact round. Python as it stands now will be defunct unless we make some serious changes starting with formatting. We cannot continue to create code bases that are so haphazardly written just for the sake of personal freedom. Since people will not self-police we must create a mandate that forces compliance to a style guide. Years have passed since the first program was written. It is high time to set the standards for formatting. Such a system of rigorous formatting rules requires much less interpreter logic. Python will be leaner and meaner. There won't be any more arguing about how to format code. There will only be one way; the correct way! Choose to follow it or die of exceptions; your choice. I am looking to the future and leaving the past where it belongs. After i get a format style nailed down i will start culling the other language specific multiplicities. Then it will be time to look outside of Python and see what is the future of high level programming languages. You can choose to join me or choose to rot of old age in the self- induced hell of antiquity. The past is bickering over selfish personal freedoms, the future of is unity. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Mon, Jul 18, 2011 at 3:57 AM, rantingrick rantingr...@gmail.com wrote: It's funny you mention this because i am creating a specification for a Python 4000 fork that removes all ambiguities and multiplicity from the language. Very soon i will be posting the spec for review within this group. Maybe some of you will come to your senses and start implementing these important features in CPython. If not, i am not going to waste my time forever trying to convince idiots that the world is in fact round. Oh, I totally agree. And mailman is open source software so you can even host the new Python-4000 mailing list yourself! Gather unto thyself thy followers, and begin anew the creation of the world. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
4) Tabs remove the need for complicated indention/detention tools. On 07/17/2011 10:15 AM, rantingrick wrote: On Jul 17, 2:32 am, Ian Kellyian.g.ke...@gmail.com wrote: This. I used to think that tabs were better, for pretty much the reasons Rick outlined, but I've had enough problems with editors munging my tabs that I eventually found it simpler in practice to just go with the flow and use spaces. Solution: STOP USING BROKEN TOOLS!!! Unbroken tools that do anything worthwhile are usually complicated tools. Just pointing that out in case you missed the irony... -tkc -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* rantingrick (Sun, 17 Jul 2011 10:57:10 -0700 (PDT)) Choose to follow it or die of exceptions; your choice. One of the best things I've read for a long time :-). The past is bickering over selfish personal freedoms, the future of is unity. And a tab is *exactly* four spaces. Not three. Not five. Not eight. For you, for me, and for the rest of the world. Amen! Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 9:15 AM, rantingrick rantingr...@gmail.com wrote: I can write my code to 80 columns using 4-space tabs, but if somebody later tries to edit the file using 8-space tabs, their lines will be too long. THEIR LINES is the key words. A tab control is a tab control is a (you guessed it!) a tab control. No matter how small or large your tab settings are the source only reflects one tab control char per press of the tab key. Heck, people are already (unwisely) using 8-space- spaces and i don't hear you making the same argument. Because the problem does not apply. If I use 4 spaces, and somebody else opens my file who uses 8, the code will still be limited to 80 columns. They will just have to see my ugly 4-space indentation instead of their preferred 8-space indentation. You know what? They can cope. Rick's answer to this might be to just mandate that everybody uses 4-space tabs, but then this would pretty much defeat the purpose of using tabs in the first place. We already mandate four space spaces so what is the difference? I'll tell you, the difference is Freedom and Unity living in perfect harmony. Let me get this straight. You want us to use tabs so that individuals can set their tab width to however many spaces they want, but then you want everybody to set their tab widths to 4 spaces. You're contradicting yourself here. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 10:29 AM, rantingrick rantingr...@gmail.com wrote: I hate vertical white-space. I follow Python style guide suggestions, and then some! I hate when people insert spaces into code blocks and function/method bodies. If you feel a space must be inserted then that is a good clue you should be using a comment there instead. Vertical breaks should only happen before and after classes, methods, functions, groups of GLOBALS, groups of import statements. Think of func/method bodies as paragraphs and classes as sections of a book. Two vertical spaces between classes and one vertical space between func/methods. You know, there is such a thing as a vertical tab. If we're going to take your suggestion of mandating tabs (for greater freedom!), should we not follow it to its logical conclusion and mandate the usage of vertical tabs instead of multiple newlines? Then everybody could choose for themselves how many lines they want a vertical tab to represent It should be MANDATED. And these @holes who refuse to format their code in a community standard will suffer the plague of syntax errors. Who do these people think they are? Do they believe the rules do not apply to them? I'll tell you who they are, they are F'ING format criminals. I think I get it now. Your idea of freedom is that anybody can do whatever they want as long as it's not illegal, and the ruling party just makes anything it doesn't like illegal. In other words, a monarchy. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Thorsten Kampe wrote: * Thomas 'PointedEars' Lahn (Sun, 17 Jul 2011 14:35:15 +0200) Thorsten Kampe wrote: * Andrew Berg (Sun, 17 Jul 2011 05:02:22 -0500) I still don't understand. Whitespace to the left of an assignment to signify an indent and whitespace around operators to align values (in a multi-line assignment) are not the same. When I'm (consistently, of course) indenting code, I'm aligning it. When I'm aligning code, I do this by indenting it, see for instance... firstvariable = 11 variable = 111 firstvariable = 22 variable = 222 The second = and the 222 is indented. You might want to check your English dictionary. Indenting is commonly understood in typography as To begin (a line or lines) at a greater or less distance from the margin¹. In particular, in computer programming it usually means that there is, at most, whitespace on the left of the text.² In that sense, the above is _not_ indentation (or indenting), as neither variable nor variable = consist only of whitespace. It is only aligning.³ *doublesigh* that is actually the point I was trying to make. Well, you said you would align code *by indenting*, which is either nonsense following the not-so-uncommon definition of indenting that I presented, or you chose a particularly bad example to make your point (as it does not feature indentation at all). From a programmer's point of view the distinction is artificial because he does essentially the same: press the tab key But he should not, unless he uses the Tab key to insert spaces, because the *display width* of the Tab *character* is variable. *That* is the point! or the indent button to move the stuff right from the cursor to the right so it gets aligned with the stuff above. Indent button? -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 14:51, Thorsten Kampe thors...@thorstenkampe.de wrote: * Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300) So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? Alignment doesn't line up. They do with tabs. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 1:20 pm, Thorsten Kampe thors...@thorstenkampe.de wrote: The past is bickering over selfish personal freedoms, the future of is unity. And a tab is *exactly* four spaces. Not three. Not five. Not eight. For you, for me, and for the rest of the world. Amen! Not *exactly*. A tab is just a control char in a string that meant to convey a user defined space. When a text editor see's a tab in a string it uses the current user defined tab width and creates the proper space (or moves the proper distance) in the display. The tab control char carries no information as to how WIDE a tab must be, no, the editor makes that choice (based on user input or default). However a tab can be EQUAL to four spaces, or eight spaces , or even eight-eight spaces if the user wants it to. The same is true for font. A string contains chars and the display font is a decision for the editor to make (based on user input or default). We cannot always offer unity and freedom in a programming language. But there are some exceptions; one of which being tabs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 15:53, Thomas 'PointedEars' Lahn pointede...@web.de wrote: I am also a recent spaces-to-tabs convert. One of the reasons is that I've discovered that programing in a non-fixed width font is a real pleasure, but the spaces are too narrow. Tabs alleviate that. Not using a fixed-width font avoids this problem and others in the first place. I'm still looking for the perfect programming font. Suggestions welcomed. I can recommend Consolas (Windows) or Inconsolata (elsewhere), which are designed for programming and are near perfect in that regard. However, I have decided for Deja Vu Sans Mono for reading and writing Usenet articles because it supports more Unicode characters and can be sized appropriately for running text. I have used those three in the past. Terrific fonts each of them, especially Inconsolata if I remember correctly. But, all of them are fixed-width fonts. I do not understand how you can consider using a non-fixed-width font in programming a real pleasure as many them show a lot of ambiguities in source code. Take for example the lowercase l (el) vs. the capital I (ai) vs. the | (pipe) character, or the 0 (zero) vs. the capital O (oh) character in Arial. The ambiguity has never been an issue for me. In the unlikely event that an l (el) is in the place of a pipe, the code won't compile and I'll get an error on the line in question. Though that has never actually happened: the IDE is double-checking way before the code gets to the compiler. Zero vs. O (oh), I've never had this issue either and even if one key was hit in place of the other (they are close by) then either the IDE or compiler would catch it, or it would result in a minor bug in a text string. It simply isn't an issue. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 17:29, gene heskett ghesk...@wdtv.com wrote: I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. Hey there Gene! Are you not on every mailing list on the internet old man?!? I have also come to the conclusion that the perfect woman, the perfect physics theory, and the perfect programming font are all illusions that men will stride their entire lives in search for but will never find. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
* Dotan Cohen (Sun, 17 Jul 2011 22:20:15 +0300) On Sun, Jul 17, 2011 at 14:51, Thorsten Kampe thors...@thorstenkampe.de wrote: * Dotan Cohen (Sun, 17 Jul 2011 14:11:40 +0300) So long as the indentation lines up (which it does, with tabs or spaces) then I do not see any problem with variable-width. What are the counter-arguments? Alignment doesn't line up. They do with tabs. Indentation alignment will (because you're using only spaces). Otherwise it doesn't align (it can't), simply because of the variable-width. For instance (in a variable-width font): if a == b: var123= 22 varxyz456 = 333 ^ aligned not aligned Thorsten -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 20:57, rantingrick rantingr...@gmail.com wrote: Such a system of rigorous formatting rules requires much less interpreter logic. Python will be leaner and meaner. There won't be any more arguing about how to format code. There will only be one way; the correct way! Choose to follow it or die of exceptions; your choice. Do you know that Python 4000 is the only language in the world whose vocabulary gets smaller every year?' -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 21:20, Thorsten Kampe thors...@thorstenkampe.de wrote: The past is bickering over selfish personal freedoms, the future of is unity. And a tab is *exactly* four spaces. Not three. Not five. Not eight. For you, for me, and for the rest of the world. Amen! Four is the number thou shalt indent, and the number of the indenting shall be four. Six thou shalt not indent, neither indent thou two, excepting that thou then proceed to four. Eight is right out. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
I'm still looking for the perfect programming font. Suggestions welcomed. When you find it Dotan, let me know, I've been looking since the later '70's. For me, it's Terminus* (from sourceforge). Br. Waldek [*] As long as you don't need anything but iso8859-1. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Anders J. Munch wrote: Steven D'Aprano wrote: I can't fathom why 8 position tabs were *ever* the default, let alone why they are still the default. That's because they were not invented as a means for programmers to vary indentation. Originally, tabs were a navigation device: When you press the tab key, you skip ahead to the next tab column. No, when you pressed the Tab key on a typewriter (BTDT), you advanced to the next tab _stop_. This made it easier to write tables (tab from tabulate) on a typewriter (the alternative was time-consuming and error- prone use of the space and backspace keys). With the evolution of the (personal) computer, its use in offices and at home, and peripheral devices like the dot matrix printer, typewriters fell out of common use, but the terms associated with them were incorporated into information technology language (cf. TTY, originally teletypewriter, e. g.). The reason the tab stop is a full 8 positions: for faster navigation. No, the reason is that table columns should be as far enough away from each other to be distinguishable. If it were 3 positions, it would take forever to skip from the start of line to column 60. You'd appreciate that, if you were e.g. writing a fiduciary report with some text to the left and two number columns to the right, back in the day before spreadsheets and word processor tables. Skip a column or two too far? I am getting the idea here that you mean the right thing, but that you explain it wrong. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 1:22 pm, Tim Chase python.l...@tim.thechases.com wrote: Solution: STOP USING BROKEN TOOLS!!! Unbroken tools that do anything worthwhile are usually complicated tools. Just pointing that out in case you missed the irony... You make a good point, albeit a very well know point. It's the same kind of point Newton made when he wrote the laws of physics. Everyone since cavemen knew that a falling apple would continue to fall until the ground stopped it from falling. They just did not have the eloquent phrasing of Newton to express the idea in words. You've made the exact same well know expression as Newton. However we do need to explore this subject of broken tools vs unbroken tools a bit more. First let's start by understanding the difference between broken and unbroken editors in the arena of tab width. Tabs Explained: But what IS tab width exactly? Is it a simple unit of measurement like four inches or 22 millimeters, or etc? Well it can be, but for the most part it is something more. Especially in the arena of source code editors! In any plain text editor (i am not speaking of rich text editors or a plain text editor in rich-text mode) where you have only one global font choice at any given time a tab width should be the sum of N glyphs multiplied by the current glyph width. Here is some python code: | glyphW = 10.0 # in milimeters | def set_tab_width(nSpaces): | return glyphW * nSpaces | set_tab_width(1) |10.0 | set_tab_width(10) |100.0 We as humans use numbers of spaces to define a tab width but numbers of spaces is only an abstraction so we don't have to deal with absolute measurements. Fixed Width Fonts: If you are using a fixed-width-font you want the editor to use relative spacing (relative to a glyph width) when defining tab width in spaces. Non Fixed Width Fonts: On the other hand if you use non-fixed-width-font you want the editor to use absolute measurements (since glyphs can be different widths) when defining tab width. Conclusion If your editor does not support as minimum the fixed width version, it is broken. There is NOTHING complicated about creating tab width based on the sum of N glyphs. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Dotan Cohen wrote: On Sun, Jul 17, 2011 at 15:53, Thomas 'PointedEars' Lahn […] I do not understand how you can consider using a non-fixed-width font in programming a real pleasure as many them show a lot of ambiguities in source code. Take for example the lowercase l (el) vs. the capital I (ai) vs. the | (pipe) character, or the 0 (zero) vs. the capital O (oh) character in Arial. The ambiguity has never been an issue for me. In the unlikely event that an l (el) is in the place of a pipe, the code won't compile and I'll get an error on the line in question. Though that has never actually happened: the IDE is double-checking way before the code gets to the compiler. Zero vs. O (oh), I've never had this issue either and even if one key was hit in place of the other (they are close by) then either the IDE or compiler would catch it, or it would result in a minor bug in a text string. It simply isn't an issue. Apparently it is *has not been* an issue for *you* *yet*. There are languages (like Python) that are compiled just-in-time. Besides, neither an IDE nor a compiler can (always) recognize that foo[b0r] is not foo[bOr] (which really is not a far-fetched example as the O and zero keys are adjacent to each other on in keyboard layouts). You do not want such an ambiguity to bite you later. -- PointedEars Bitte keine Kopien per E-Mail. / Please do not Cc: me. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 1:48 pm, Ian Kelly ian.g.ke...@gmail.com wrote: Let me get this straight. You want us to use tabs so that individuals can set their tab width to however many spaces they want, but then you want everybody to set their tab widths to 4 spaces. You're contradicting yourself here. In my mind people are free to use whatever width they like. A tab is a tab is a tab. However for judging line widths we must pick one size tab (since 8 space tabs will create longer lines than four space tabs. This four space mandate is ONLY for determining line width. Let me repeat. ONLY FOR DETERMINING LINE WIDTH. How else could we decide what is truly 80 chars and what is not? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 1:54 pm, Ian Kelly ian.g.ke...@gmail.com wrote: On Sun, Jul 17, 2011 at 10:29 AM, rantingrick rantingr...@gmail.com wrote: I hate vertical white-space. I follow Python style guide suggestions, and then some! I hate when people insert spaces into code blocks and function/method bodies. If you feel a space must be inserted then that is a good clue you should be using a comment there instead. Vertical breaks should only happen before and after classes, methods, functions, groups of GLOBALS, groups of import statements. Think of func/method bodies as paragraphs and classes as sections of a book. Two vertical spaces between classes and one vertical space between func/methods. You know, there is such a thing as a vertical tab. If we're going to take your suggestion of mandating tabs (for greater freedom!), should we not follow it to its logical conclusion and mandate the usage of vertical tabs instead of multiple newlines? Then everybody could choose for themselves how many lines they want a vertical tab to represent On the face of it one might think vertical tabs are a good idea however newlines work just fine. There is no reason for expanding vertical whitespace to create readble code. If you can offer a good reason i'm listening. Also be sure to post links where others have requested the same. Besides, horizontal tabs are tied closely to distinguishing code blocks. Vertical tabs do not have such a benefit. Instead of vertical tabs we need strict rules on vertical code formatting. I intend to draft AND implement such rules very shortly. It should be MANDATED. And these @holes who refuse to format their code in a community standard will suffer the plague of syntax errors. Who do these people think they are? Do they believe the rules do not apply to them? I'll tell you who they are, they are F'ING format criminals. I think I get it now. Your idea of freedom is that anybody can do whatever they want as long as it's not illegal, In a programming language yes. You're trying to draw correlations between morality and law. In the arena of programming there is no such thing as morality, only the law. and the ruling party just makes anything it doesn't like illegal. In other words, a monarchy. What do you think we have now, a democracy? Does Benevolent?-Dictator- For-Life ring a bell? I can tell you one thing for sure. In MY version of Python everyone will have a voice. That does not mean that EVERYONE will make the final decision but EVERYONE's voice will be equally important. I can also tell you this. I will not hide under the coat tails of my dev team , NO, i will mingle with the people on my comp.lang.rickpy list. Mats (Ruby's creator) will answer questions on comp.lang.ruby so why does Guido refuse to acknowledge us here on comp.lang.python? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Jul 17, 2:34 pm, Thorsten Kampe thors...@thorstenkampe.de wrote: Indentation alignment will (because you're using only spaces). Otherwise it doesn't align (it can't), simply because of the variable-width. For instance (in a variable-width font): if a == b: var123 = 22 varxyz456 = 333 ^ aligned not aligned Thorsten Tabs will align properly in variable width font if the editor is NOT broken. When displaying a variable width font the editor should switch from using the sum of N glyphs to a user defined total width in absolute measurements (like millimeters). Alternatively if the editor had to guess it could just use the widest glyph of the current set. People, please stop using broken tools. If you stop using them people won't keep producing them. Just imagine how great the world would be if we could convince windows users! -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 22:53, Thomas 'PointedEars' Lahn pointede...@web.de wrote: It simply isn't an issue. Apparently it is *has not been* an issue for *you* *yet*. There are languages (like Python) that are compiled just-in-time. Besides, neither an IDE nor a compiler can (always) recognize that foo[b0r] is not foo[bOr] (which really is not a far-fetched example as the O and zero keys are adjacent to each other on in keyboard layouts). You do not want such an ambiguity to bite you later. I do agree that in a weakly-typed language such as python one might conceivably try to use an undeclared variable and the IDE and compiler won't catch that. However 0 vs. O would more likely be 0 vs. o as one would really have to mess up bad to not only press the wrong key but also hit shift at the same time. 0 and o are no harder to distinguish in a VWF than in a FWF. For that matter, why is it assumed that fixed-width fonts by nature better distinguish 0 from O, or any other ambiguous characters? My current system (Kubuntu 11.04, default VWF font in Firefox whatever it may be) distinguished 0 from O just fine. Also I/1 and l/1 are easy to distinguish, but I agree that I/l are not. -- Dotan Cohen http://gibberish.co.il http://what-is-what.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 1:54 PM, rantingrick rantingr...@gmail.com wrote: On Jul 17, 1:48 pm, Ian Kelly ian.g.ke...@gmail.com wrote: Let me get this straight. You want us to use tabs so that individuals can set their tab width to however many spaces they want, but then you want everybody to set their tab widths to 4 spaces. You're contradicting yourself here. In my mind people are free to use whatever width they like. A tab is a tab is a tab. However for judging line widths we must pick one size tab (since 8 space tabs will create longer lines than four space tabs. This four space mandate is ONLY for determining line width. Let me repeat. ONLY FOR DETERMINING LINE WIDTH. How else could we decide what is truly 80 chars and what is not? You're so focused on declaring code as compliant or not that you're missing the whole point of having the line width mandate in the first place. It exists so that people using 80-column editors can open up code without having line-wrapping problems. You can arbitrarily declare that line width is to be measured using 4-space tabs, and you can stamp code as being correctly formatted by that metric all you want, but it doesn't change the fact that if somebody with 8-space tabs opens up a file and has to deal with line-wrapping problems, the system has failed them. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Anders J. Munch wrote: Cameron Simpson wrote: Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. Just like in the old days:) Most editors can be configured to do that. Where they fall down, in my experience, is that having inserted those spaces, if you want to delete them you typically have to backspace over them one at a time. I don't enjoy that experience, which is why I have BBEdit Lite set up to use tab-only indentation. If I'm feeling conscientious, I convert to spaces before sharing the code with others. But tabs work better for me given the tools I use and the way I like to work. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On 17Jul2011 09:53, rantingrick rantingr...@gmail.com wrote: | On Jul 17, 4:49 am, Anders J. Munch 2...@jmunch.dk wrote: | Originally, tabs were a navigation device: When you press the tab key, you skip | ahead to the next tab column. The notion that whitespace characters are | inserted into the text would have been very alien to someone using text | processing software anno 1970. Same thing with space and enter; on typewriters | the space bar doesn't type anything onto the paper, it moves to the next | column, and that thinking carried over to computers. | | And how much longer are we going to live in the past? Who cares about | backward compatible tabs. Anders was explaining, not supporting-for-the-future. | Mandate the four space tab now! Mandate that | Python takes four space and four space only! We shall lead the charge | for universal tab unity in all programming languages. You really don't know what you're talking about, do you? If Python mandates this (hahaha!) the Perl crowd will immediately move to a more advanced standard, likely 5 space indents (nicely decimalisable) while indenting by two tabs (to flexibly leave room for more intermediate logic to be inserted later with less diff noise, which they will find hard to distinguish from program code). | The reason the tab stop is a full 8 positions: for faster navigation. If it | were 3 positions, it would take forever to skip from the start of line to column | 60. You'd appreciate that, if you were e.g. writing a fiduciary report with | some text to the left and two number columns to the right, back in the day | before spreadsheets and word processor tables. | | Just in case you were not aware this the year 2011. Spreadsheets have | been around for a LONG time. Stop living the past. The past was better. Always was and will be increasingly so in the future. Stop fighting the tide! -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Pardon my driving, I'm trying to reload. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 2:12 PM, rantingrick rantingr...@gmail.com wrote: On the face of it one might think vertical tabs are a good idea however newlines work just fine. There is no reason for expanding vertical whitespace to create readble code. If you can offer a good reason i'm listening. Also be sure to post links where others have requested the same. Okay: 1) Vertical tabs create freedom in the form of user controlled vertical spacing. Vertical spacing height should be a choice of the reader NOT the author. We should never code in vertical spacing height; but that is EXACTLY what we are doing with newlines! No, the reader should be able to choose the vertical spacing height without ANY formatting required or without any collateral damage to the source code. Vertical tabs offer freedom, newlines offer oppression. 2) Vertical tabs remove the need for complicated newline-formatting tools. With vertical tabs only you no longer need those fancy tools to add the correct number of newlines between classes or methods.. THAT IS EXACTLY WHY VERTICAL TABS WHERE INVENTED! Why are we not using this technology? Why are we continuing to promote newlines when vertical tabs are obviously more superior? And as to why we should remove newlines: 3) Using only one vertical space token removes any chance of user error. Unlike many syntactical errors, vertical space is invisible in a text/ source editor. Sure there are tools that can make vertical space visible, however why do we constantly create asinine rules that force us to use complicated tools when we could have choose vertical tabs and none of this would have been a problem? 4) Vertical tabs maintain unity in the source code base. When we replace newlines only with vertical tabs only we maintain a code base that promotes unity and not conformity. There shall not be any inconsistent vertical spacing errors due to mixing vertical tabs and newlines. Also we can avoid adding multiplicity to the compiler. The compiler will not have to consider BOTH vertical tabs AND newlines as valid vertical spacing tokens, only vertical tabs. The logic would be much simpler. Besides, horizontal tabs are tied closely to distinguishing code blocks. Vertical tabs do not have such a benefit. Instead of vertical tabs we need strict rules on vertical code formatting. I intend to draft AND implement such rules very shortly. Vertical spacing helps to visually separate classes from other classes, and methods from other methods. I think I get it now. Your idea of freedom is that anybody can do whatever they want as long as it's not illegal, In a programming language yes. You're trying to draw correlations between morality and law. In the arena of programming there is no such thing as morality, only the law. You have been drawing the same correlation from your very first post where you stated, Tabs offer freedom, spaces offer oppression. and the ruling party just makes anything it doesn't like illegal. In other words, a monarchy. What do you think we have now, a democracy? Does Benevolent?-Dictator- For-Life ring a bell? I don't see Guido going around making ridiculous pronouncements about what forms of indentation are acceptable (beyond the standards that are set and expected for the standard library, that is). He could have made the language space-only from the very beginning. He didn't; that should tell you something. He also could have insisted that the parser only accept source written in the ISO-8859-1 encoding for unity and freedom, but he didn't. Or he could have stated absolute imports only from the very beginning, and yet even in Python 3 where the old-style relative imports have been removed, relative imports are still available to be used. I can tell you one thing for sure. In MY version of Python everyone will have a voice. That does not mean that EVERYONE will make the final decision but EVERYONE's voice will be equally important. Thanks, but I won't be needing a voice, because your version of Python will clearly be too limiting from the ground up for me to have any interest in using it in the first place. I can also tell you this. I will not hide under the coat tails of my dev team , NO, i will mingle with the people on my comp.lang.rickpy list. Mats (Ruby's creator) will answer questions on comp.lang.ruby so why does Guido refuse to acknowledge us here on comp.lang.python? Probably for the same reason that (I presume) he doesn't spend all day answering Python questions on stackoverflow or responding to comments about Python on slashdot: he can get more done in his actual job by unsubscribing. If you want to have input on Python, all you have to do is subscribe to python-dev. Of course, it *is* a moderated list, so if you make as much of a nuisance of yourself over there as you do here, they might kick you out. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 03:12 PM, rantingrick wrote: I can tell you one thing for sure. In MY version of Python everyone will have a voice. That does not mean that EVERYONE will make the final decision but EVERYONE's voice will be equally important. That reminds me of Full Metal Jacket. Here you are all equally worthless. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI22xAAoJEPiOA0Bgp4/LIwsIANrgRO1m4f2w4M6HQ0I2Ysjl SqSCQ4r4p7ZG4O6t/ms6r3uVQXh7FrV1atkWLkUprwd+DfPTl2Lpp5xF7RB2lJ4/ pvcIWQ47kC2F4BgbcW2UN8E1vu6K1G+q/s81HzXsTfdnFqYBrhli+Hd3XvgFH9Zr nt8dKJuX1lVowYeg22iZyUiMaubpZl35Xyw4xFTPJ7eW8ynHriYG3JfJtUVjDYz0 Hs4oXrdcllugOwYcGUN4tddJ1uls/Xat16HUtxOIYIJUQr1kZVa/l0kmsoi1AT1/ SBCnLzyiuBLA8fHcvE675+/834FZi9sgAPOM4HY/dx3YDa8musSjbPtfSUFAQKQ= =NEuJ -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 11:46 AM, rantingrick wrote: Why do you feel the need to layout your code in a GUI-listview manner. Next you'll want column titles and column sorting... Jeez! This is what you should have done... I was testing my psychic abilities. I had the feeling that such a layout would irritate you, so I had to try it. Before, I thought this psychic stuff was all hokey, but now... - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI25rAAoJEPiOA0Bgp4/L5lwIAIxwvAz7QBEOaQ9Hn/Er7esE t4A76iJMOzVajFD61Wf8HkCyBrkQPk2i7koUqByUbQMRjAD3ukBorH+RNlfYwdJQ w2HGjxCG36fA9yYZe5N+ySX1UlxH4pbZJLDxJMvo4brF8XVVOknsQyIW3rPM2ma9 CtdP4pWRpuE+4mz+wu4uxZW0xFarFV64TbcsXs1aZZAUSSJ4HUEbSuk/gw4IGBc5 HrOCBKt9hlgB7oh6KyITikFHCWV63iDzqfkVxP7Cr7ON3KaMPcfEVe2JowZv8NeV cZmr4pbxWQ+ya0i8ukGjizrUa+Jdjp0p3I1OsVlZ0NCLyp4v5zDVS6R+97zjVc4= =lBEF -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 06:29 PM, Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I think the reason the idea isn't dead is because of the emergence of new devices with small displays (tablets/smartphones/etc.) and their increasing popularity. When writing code that is meant to be run on desktops or servers, the 80-column limit is mostly irrelevant, but Python running on these small devices, especially with Python code being interpreted rather than compiled, it's convenient to edit code on those platforms, where there is a significant column limit. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI3aPAAoJEPiOA0Bgp4/LRMQH/irglKlq7+Nk67dvGuQt39ZH nHqEE4HG5J7y/JfW+3g4UbhISHFwsJO0yvvcUN8cfLQ9O4KxzR65PS6Jqs8KEWS+ 04hAZl0AbEKHZv3nOxWhxvAF5saJnq0xWHAtE9tFwS31I7Oh65rCBZD4g9BFiCql YeTAklPB64Ik6F+7kcLDx3xDn6CPb/03Nj2assGatSUEY5p0OqzZ9nPnBxifLDFC piOkZOgPW39s/zEzr+0LiD3ayFmtPoYldBFR0c7qkzyN6aS+Fur4kqbxlGl4jbI/ Xkms/5yrie/jAf4HgcaMHX2l4Or/dY7jyb6cK+How+yNa76xh6CZdxIZ68oR6Fs= =K9SY -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
In article mailman.1196.1310946970.1164.python-l...@python.org, Andrew Berg bahamutzero8...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 06:29 PM, Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I think the reason the idea isn't dead is because of the emergence of new devices with small displays (tablets/smartphones/etc.) and their increasing popularity. When writing code that is meant to be run on desktops or servers, the 80-column limit is mostly irrelevant, but Python running on these small devices, especially with Python code being interpreted rather than compiled, it's convenient to edit code on those platforms, where there is a significant column limit. Can you give me a more specific example? I assume there's nobody (at least nobody sane) editing Python source code on iPhones. I'll admit I'm not that familiar with the plethora of tablets and handheld devices out there. Are there really devices which impose exactly an 80-column width? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 07:28 PM, Roy Smith wrote: Can you give me a more specific example? I assume there's nobody (at least nobody sane) editing Python source code on iPhones. I haven't done it myself, but there are plenty of Python projects out there made for mobile devices, and I would imagine the convenience of editing on the platform itself to test things immediately outweighs the inconvenience of a small display and tiny keyboard. Are there really devices which impose exactly an 80-column width? Font size can be changed, so it's not a matter of a fixed number of characters, but rather how many characters can fit on such a small display at a reasonable size. My guess is that 80 is pretty arbitrary nowadays, but it's much easier to stick with 80 than debate over it, especially when display sizes vary so greatly among these devices. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI4LnAAoJEPiOA0Bgp4/L9s4H/1hZUtzSUEK3ZCs/+5SQk4dE W7Au9Gv4rpNK6zmIRTmWkBeqUZdJHVXftQslnkvVr+pUMjz395YZbT3a2rAiaMje IYq2HqKk8kZAeVo1sQLlKAl5PcCP8yJKGW1UJBLcLarXC33e/3pB1M7MY3QIVEta S68IsBR5RJdtNIOJcmNtYEglPe1CSXt0LeEGYoseBhz9UyUDnnJlelu6WRAatKxR jB8sbaWN4wLdT1iFkNFePSA1hJQSGmot0D5UaYTTG5HuG4JNlSeTZ23ctFLph/XG 96vndHBjxkDEdzCBkxSRaM5i5W/vSa/t25c5uDvXibldrxBWqm2QYJTeMhJ9JsY= =6RXz -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 I should also mention that this mostly speculation on my part, and that I would love to hear from someone who develops for these devices. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI4NvAAoJEPiOA0Bgp4/LI8UH/3s+YyOsRGfHmcfX17glGUPT bMAHq7vkmyWp5/zdcTWiRSxySrmTdcBJlquQOzUXhzGjRJlDoRQJrVypNr5zEO/r FQkqwSnd0MmAg7wQX5I8xnM+muqeqOMvSqPs6HzBUiUqgwNoMlDn1v0Cc0h72mxx Nf5r67/0Sptg7sR15aZnLtDodfql6qDxbIbDBdsp6SVnL6XE3l2NfFnB8DcOXRXk 2ooiV5/HlV0S2lr5TiKshyWuumQCnOPg6+ZDc//vev4L3aeM6EAXtYTWTWJEERl+ 6PMP6u1SmA7P43jjzunxTiyXRkLLp7lJDaoWVzb3o+FDLOwNhgVEUH28TiXuNgQ= =0HaP -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Chris Angelico wrote: On Mon, Jul 18, 2011 at 2:53 AM, rantingrick rantingr...@gmail.com wrote: [a whole lot of guff] Rick, you need to: 1) Grab the Python source code 2) Make your own version of Python that works the way you want it 3) Call it something different 4) Start your own mailing list. Put your money - or, in this case, development time - where your big ranting mouth is. Prove that your ideas are worth something by acting on them. Ha ha, oh that's hilarious!!! Back in 2007, a n00b calling himself TheFlyingDutchman who I am *reasonably* sure was Rick decided to fork Python: http://mail.python.org/pipermail/python-list/2007-September/1127123.html Then in 2010, Rick promised that if the Python developers didn't bow to his demands, he would folk Python, and the silent majority who agreed with him but were too terrified to say so publicly would drop CPython in a flash and follow him. Thread starts here: read and weep. http://www.gossamer-threads.com/lists/python/python/835227?do=post_view_threaded#835227 How's that fork going Rick? Written a single line of code yet? -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Andrew Berg wrote: I should also mention that this mostly speculation on my part, and that I would love to hear from someone who develops for these devices. There's a mailing list for Python scripting on Android -- List-Subscribe: http://groups.google.com/group/python-for- android/subscribe?hl=en_US, mailto:python-for- android+subscr...@googlegroups.com . Tends to be pretty detail-oriented. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Andrew Berg wrote: I should also mention that this mostly speculation on my part, and that I would love to hear from someone who develops for these devices. There's a mailing list for Python scripting on Android -- List-Subscribe: http://groups.google.com/group/python-for- android/subscribe?hl=en_US, mailto:python-for- android+subscr...@googlegroups.com . Tends to be pretty detail-oriented. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Steven D'Aprano wrote: Roy Smith wrote: We don't have that problem any more. It truly boggles my mind that we're still churning out people with 80 column minds. I'm willing to entertain arguments about readability of long lines, but the idea that there's something magic about 80 columns is hogwash. I agree! Which is why I set my line width to 78 columns. Sorry, that looks like a troll, but isn't. I seriously do set my editor to a soft limit of 78 characters. That is, I can exceed it if I want, but almost never do. Why 78? Because it's one less than 79, as mandated by PEP 8, and two less than 80, the hoary old standard. The reasons given in PEP 8 for 79 make sense to me, and I don't like reading really long lines of code. With one exception, if your line of code needs more than 79 plus or minus 1 characters, chances are it is doing too much. The exception is, you have an indented block of code, perhaps three or four indents deep (surely you never allow anything to get beyond five or six indents?), and you want to raise an exception: raise SomeExceptionType(and here's a rather long error message blah blah blah) If I only go a character or two over, I might be tempted to just go over. But normally I split the line, as above, and use implicit line concatenation. http://www.python.org/dev/peps/pep-0008/ -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.17 07:54 PM, Steven D'Aprano wrote: Then in 2010, Rick promised that if the Python developers didn't bow to his demands, he would folk Python, and the silent majority who agreed with him but were too terrified to say so publicly would drop CPython in a flash and follow him. Thread starts here: read and weep. http://www.gossamer-threads.com/lists/python/python/835227?do=post_view_threaded#835227 How's that fork going Rick? Written a single line of code yet? I skimmed through the first post a bit and it's hilarious. TL;DR for now, but I'll read the whole thread later. I'm still surprised how much entertainment I get from a programming language newsgroup. - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOI4vQAAoJEPiOA0Bgp4/LiN4IAMFXmBUxLOr1lYRIVY7kSwWj Ln+pTvOR6S0og6S1v1fljTeFy8NWsbeLHjF48TahJf5VlEqiuCd7zUQ8r0gDn6ut +ibDz+rtJJAE2XOG5myBylwcuG31TuaoXcSsNMCTnIMi6ZsoOWeBmkD0rvG66eFM tPaceBdv7qe/0oNcy/DalEZ8gE2NSfrm6u4g5RQge8E4o4IwCWwMdSOkKRjkJdix mbCfcCytQtc+X7IFwuUcFMAtFq9f8rzp8Jl45/wCBlxBPvZbLfqJvit9J8hgF81v KgSeyV9BLKgzRamBOZQdG2/mUwJV8aQwxdSJrtRwZ0YWpQaOPnTZlQsRyAzf4nw= =9zSp -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Steven D'Aprano steve+comp.lang.pyt...@pearwood.info writes: The exception is, you have an indented block of code, perhaps three or four indents deep (surely you never allow anything to get beyond five or six indents?), and you want to raise an exception: raise SomeExceptionType(and here's a rather long error message blah blah blah) Give yourself plenty more room, stay within PEP 8, *and* make the alignment robust in the face of changes:: raise SomeExceptionType( and here's a rather long error message blah blah blah) -- \ “I have one rule to live by: Don't make it worse.” —Hazel | `\ Woodcock | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sat, Jul 16, 2011 at 9:51 AM, rantingrick rantingr...@gmail.com wrote: -- Summary -- As we all know python allows us to use either tabs or spaces but NEVER both in the same source file. And as we also know the python style guide says we should use four spaces and refrain from using tabs at all costs. Up until now i have blindly followed this pronouncement form our leader. I greatly prefer tabs over spaces for two reasons: 1) As you said, tabs make indentation the choice of the reader, not the writer 2) Many make (the build tool) programs only do tabs, so I don't end up flipping back and forth between tabs and spaces when moving from Python to make and back (often in the same vi session) But despite the inflexibility of spaces, they are simpler; there are some reasonably strong computer folk who don't get tabs. I suspect that's why spaces won. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.16 11:51 AM, rantingrick wrote: -- Evidence: Tabs ARE superior! -- That may be the case (for indentation, NOT alignment), but you're still a damn troll. ;) - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIhfBAAoJEPiOA0Bgp4/LQpIH/0AlLR09VPedCQMoeyRfoRxd Xbimrp+am1RiW3ysln1s+vKVyh9J38ATpe0AZmYtc44s1q6pg8mUYrgdc77IVtrc L/gPE/zw+R1aMcZDsAaZRU/UL0DrbrUKWAPJbPgA8Z5yXlBqR6a9/zYz8Uu96NlG Ma9abDC77fPtj9YuiGdqpRfJoF5ed4ZnWbYXukcT6L6VjJXA/Yt0ofb84iHl3To2 h8nSVhxfc2DOzUZBrnPQlxs7rSzo2lW3JhVhS25gnke2l9/aM1TF9vUet8qmaKtN 2neGYUGWqy9j7f9/w0IP/Wp7bO0aK/a7AxrNCCMevSUSptcvHB93Ngbl3qZNAC8= =OfNc -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
rantingrick rantingr...@gmail.com wrote: As we all know python allows us to use either tabs or spaces but NEVER both in the same source file. That's not true. Python allows tabs and spaces to be used in the same source file, and even in the same source line. I'm not saying it's wise, but it certainly allowed. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On 16Jul2011 09:51, rantingrick rantingr...@gmail.com trolled: | Evidence: Tabs ARE superior! | -- | I have begun to believe that tabs are far more superior to spaces Please Rick: you need at least three things to use the term more superior. With only two, you just have superior. It grates. Personally, I prefer spaces to tabs, at least fgor my Python code and generally anyway. Why? Well to some extent because I share files with another who uses 4 position tabs. Editing these is a real nightmare if one uses 8 position tabs (as I do, the common editor/terminal default these days). For pure indentation you may get sane (if wider that liked) results, bit any multicolumn stuff is badly broken by the mismatch. Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. With pure spaces, the text is laid out reliably for us both. And so I have my editor set to that behaviour. [...] | 3) Tabs create freedom in the form of user controlled indention. Only for leading indentation, not following indentation. Consider docstrings and other stuff with embedded fixed witdh layout. | Indention width should be a choice of the reader NOT the author. Sure, perhaps. | 4) Tabs remove the need for complicated indention/detention tools. | With tabs only you no longer need those fancy tools to indent or de- | dent after a tab or backspace key-press. THAT IS EXACTLY WHY TABS | WHERE INVENTED! Why are we not using this technology? Why are we | continuing to promote spaces when tabs are obviously more superior? Again with the more superior:-( Tabs were devised to lay out multiple columns reliably on physical media, to produce tabular output. But your proposal really only works for leading indents in a fixed with system, not multiple indents on the same line (see my 4 versus 8 example above). | -- | Conclusion: There IS freedom in unity! | -- | When you can create a mandate that brings both UNITY and FREEDOM to | your community you know you made the correct choice! Tabs are both | unity and freedom at the same time because tabs UNIFY the code base | whist giving FREEDOM to view source in any indentation with WITHOUT | extra formatting required. | | Source code must follow rules. And source code authors must follow | these rule. Anyone who claims that syntactical rules in a programming | language are evil because these rules somehow quell freedom is just | a complete nut job. Programming languages MUST have rules or | ambiguities will run a muck and bring the entire system crashing down. Amuck is one word you know... Anyway, plenty of systems have abiguities, many very deliberate. It is _good_ design in many cases to deliberately leave various things unspecified - it allows flexibility in implementation. Provided enough is specified to meet the use case one should often stop at that point. | Some would argue that allowing both tabs and spaces is freedom, | however this line of reasoning is flawed. Allowing a programmer to | format his code in way he pleases is bad, bad, bad. As a member of a | community we must all format our code in the same manner. This leads me to think you're just trolling. In a particular grouping of shared code I will adhere to the agreed upon style guides (almost always). But forcing _your_ style guide on all Python users? You can just f- off. | Would it be wise for folks to choose which side of the road to drive | on? Sure. But so much of the world chose the _wrong_ side. I drive on the left, as do all right thinking people. | Would it be wise for folks to choose which red lights to stop at (or | not stop at)? They do already. | Would it be wise to allow people to kill other people in the name of | freedom? I thought they did this, too. | If we continue along this flawed line of reasoning then one could | extrapolate just about any excuse for any action under the guise of | personal freedom. These people are selfish by nature and they don't | care about their own responsibilities to a greater community. They | exist only to please themselves. We (as a community) should not care | what they think until they decide to stop being selfish. | | We should never create languages that cater to the selfish. Our rules | must take in consideration the good of the many, and NEVER the good | of the few. We should ALWAYS give our community freedoms; but only | the freedoms that foster unity! Tabs meet both criteria and as such | should be Pythons only token for indention formatting. It must be nice to always be right. In fact, I know it is, being so myself. You haven't yet reached that happy state. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Will you come quietly, or shall I use earplugs? -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sat, Jul 16, 2011 at 4:52 PM, Cameron Simpson c...@zip.com.au wrote: Well to some extent because I share files with another who uses 4 position tabs. Editing these is a real nightmare if one uses 8 position tabs (as I do, the common editor/terminal default these days). 8's been the default in pretty much everything for as long as I can remember. For pure indentation you may get sane (if wider that liked) results, bit any multicolumn stuff is badly broken by the mismatch. That's why you use tabs before your commands, spaces after your commands - if you insist on putting comments on the same line as a command. It's also why it's better to put comments on lines by themselves, rather than tacking them onto the end of something else. -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.16 06:52 PM, Cameron Simpson wrote: Only for leading indentation, not following indentation. Consider docstrings and other stuff with embedded fixed witdh layout. I try to avoid aligning things unless not doing it really hurts readability for that reason. For example, in most of my source files, I use tabs to indent. Since Python won't allow a mix of tabs and spaces (for whitespace) on one line, I don't try to align things: else: self.x264_cmd = [ self.x264_exe, self.avs_file, '--fps', self.fpsr, '--sar', self.sar, '--crf', self.crf, '--level', self.level, '--keyint', self.ki, '--min-keyint', self.minki, '--ref', self.ref, '--weightp', self.weightp, '--bframes', self.bframes, '--b-adapt', self.badapt, '--me', self.me, '--merange', self.merange, '--direct', self.direct, '--trellis', self.trellis, '--subme', self.subme, '--deblock', self.deblock, '--output', self.video_output ] But it's still very readable. However, when alignment really matters, such as in a module's setup.py, spaces are the way to go: from distutils.core import setup setup( name = 'Elucidation', version = '0.0.1-WIP', py_modules = ['elucidation'], author = 'Andrew Berg', author_email = 'baha...@digital-signal.net', url = '', platforms= 'Windows', description = 'Provides a class for storing information on multimedia files that are to be converted or remuxed and methods to convert and remux using popular tools.' ) Of everything I've read on tabs vs. spaces, this is what makes the most sense to me: http://www.iovene.com/61/ - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIizqAAoJEPiOA0Bgp4/Lz3MH/2intDlRrMNNtfnyJF384/yS +dDptVATyTfFYlEGYhVAc1DZHWC2574ZPlB+rPQd8EnDuawGgFtq0h+5m2oMrWTV dG+53im/TD3t9vU8ElsQ4gdINV99bw2jASJA2zrFwUS7QWAadqHWfZji1JgJkp+k BupqXbBWaKZn9tREDbWNeTp3byHD0WFs6ZZp5ZxRxYCMNl4I4YMWgkSQuRmQJRy+ 3FuFokUz9uyCQk/pHD9JSQqiB2mkXBLZbXU0V71rTBqGIWe+u0n+DggWAAYNAK5R U+neKJAfwHfwNcgCI0r56gNl1fWc5cOXzT7HcPW4cErvgsBXOOGicPoxZTZZ05I= =6w/9 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 9:52 AM, Cameron Simpson c...@zip.com.au wrote: | Programming languages MUST have rules or | ambiguities will run a muck and bring the entire system crashing down. Amuck is one word you know... Yes, but maybe he's wanting to run a MUCK. It's quite possible; I run a MUD. Now, I'm not sure how ambiguities alone could run the MUCK without human intervention, but as we know, Rick has the solution to everything - it always involves other people doing work. | We should never create languages that cater to the selfish. Our rules | must take in consideration the good of the many, and NEVER the good | of the few. We should ALWAYS give our community freedoms; but only | the freedoms that foster unity! Tabs meet both criteria and as such | should be Pythons only token for indention formatting. It must be nice to always be right. In fact, I know it is, being so myself. You haven't yet reached that happy state. I was born here. It's a good place to be. (Wait, were we talking about Australia or Right?) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On 16Jul2011 19:29, Andrew Berg bahamutzero8...@gmail.com wrote: | Of everything I've read on tabs vs. spaces, this is what makes the most | sense to me: | http://www.iovene.com/61/ Makes sense to me. Thanks for the URL. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Every particle continues in its state of rest or uniform motion in a straight line except insofar as it doesn't. - Sir Arther Eddington -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Andrew Berg wrote: I try to avoid aligning things unless not doing it really hurts readability for that reason. For example, in most of my source files, I use tabs to indent. Since Python won't allow a mix of tabs and spaces (for whitespace) on one line, I don't try to align things: else: self.x264_cmd = [ self.x264_exe, self.avs_file, '--fps', self.fpsr, '--sar', self.sar, [snip rest of code] However, when alignment really matters, such as in a module's setup.py, spaces are the way to go: from distutils.core import setup setup( name = 'Elucidation', version = '0.0.1-WIP', [snip] Hilariously, in my newsreader, the first example (allegedly unaligned) was lined up as straight as an arrow, while the allegedly aligned second example was completely jagged and all over the place :) The perils of proportional fonts. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
Cameron Simpson wrote: On 16Jul2011 09:51, rantingrick rantingr...@gmail.com trolled: | Evidence: Tabs ARE superior! | -- | I have begun to believe that tabs are far more superior to spaces Please Rick: you need at least three things to use the term more superior. With only two, you just have superior. It grates. Really? If you just say superior, how do you know if it's more superior or less superior? *wink* Personally, I prefer spaces to tabs, at least fgor my Python code and generally anyway. Why? Well to some extent because I share files with another who uses 4 position tabs. Editing these is a real nightmare if one uses 8 position tabs (as I do, the common editor/terminal default these days). I can't fathom why 8 position tabs were *ever* the default, let alone why they are still the default. For pure indentation you may get sane (if wider that liked) results, bit any multicolumn stuff is badly broken by the mismatch. Personally, I like to use the tab _key_ as an input device, but to have my editor write real spaces to the file in consequence. With pure spaces, the text is laid out reliably for us both. And so I have my editor set to that behaviour. I have reluctantly come to do the same thing. There is a plethora of broken tools out there that don't handle tabs well, and consequently even though tabs for indentation are objectively better, I use spaces because it is less worse than the alternative. Victory of worse-is-better. [...] | Some would argue that allowing both tabs and spaces is freedom, | however this line of reasoning is flawed. Allowing a programmer to | format his code in way he pleases is bad, bad, bad. As a member of a | community we must all format our code in the same manner. This leads me to think you're just trolling. Slow learner, huh? :) I'm not sure which is worse... that Rick is trolling, and we still give him the attention he craves, or that he honestly believes this crap. I suspect the later. I get the impression that he genuinely has so little self-awareness that he doesn't notice that for all his talk about FREEDOM, he's constantly trying to deny it to others by forcing them to do what he wants them to do. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On 2011.07.16 10:07 PM, Steven D'Aprano wrote: Hilariously, in my newsreader, the first example (allegedly unaligned) was lined up as straight as an arrow, It has consistent indentation, but the self.whatever references aren't aligned. The perils of proportional fonts. Indeed. I have my MUA set up to always send plain text, so I don't think there's a way I can suggest a font to the recipient (like my favorite fixed-width font, Courier New). - -- CPython 3.2.1 | Windows NT 6.1.7601.17592 | Thunderbird 5.0 PGP/GPG Public Key ID: 0xF88E034060A78FCB -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAwAGBQJOIlToAAoJEPiOA0Bgp4/Lb1MH/R/0RCHYSNpP2cbYG10oPEVI JTx+u2vnRDJzjlJ2B85mKz3BV/cIO67rV+3tX3C4J272bS5SfmET3QUzprSTLerb WIAKWL3zJF+VNSPuPI2HMnHepOV61Cjlom0GGf/dOTY/zaQCGdqx3gVy0RljUsV+ xj/ywxsHbV3vbT34b1EtNaSIz+EnzZknd0mTBApNClv9Y+VF5g8pQmPyQ6mJTXuu 8uVS5yxXyH4h5sYpONFzMdPSQdZHFUggmEfUZ3xkJ2OWwJBDtrUrIQIgs2qopIxG Cx8sM1hg9mkcILN95e9qVkohXAzHl4R6tXSVC+vYj0k4TMM6sj5CowzgorbfpgA= =YvS2 -END PGP SIGNATURE- -- http://mail.python.org/mailman/listinfo/python-list
Re: Tabs -vs- Spaces: Tabs should have won.
On Sun, Jul 17, 2011 at 08:39, Steven D'Aprano steve+comp.lang.pyt...@pearwood.info wrote: I have reluctantly come to do the same thing. There is a plethora of broken tools out there that don't handle tabs well, and consequently even though tabs for indentation are objectively better, I use spaces because it is less worse than the alternative. Victory of worse-is-better. Here too. I prefer the 8-space tabs for the simplicity of the input method. (even while deleting 1 keystroke will do) [...] | Some would argue that allowing both tabs and spaces is freedom, | however this line of reasoning is flawed. Allowing a programmer to | format his code in way he pleases is bad, bad, bad. As a member of a | community we must all format our code in the same manner. This leads me to think you're just trolling. Slow learner, huh? :) I'm not sure which is worse... that Rick is trolling, and we still give him the attention he craves, or that he honestly believes this crap. I suspect the later. I get the impression that he genuinely has so little self-awareness that he doesn't notice that for all his talk about FREEDOM, he's constantly trying to deny it to others by forcing them to do what he wants them to do. (denying others freedom) Ha that he is. But given, i sometimes do go into these phases (complete and utter lack of self-awareness) i am not complaining... Despite all of that, i do believe it will be for the greater good, if all of us *decide* to use 8-space tabs. -- http://mail.python.org/mailman/listinfo/python-list
