Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #42852 > unrolled thread

I hate you all

Back to article view | Back to comp.lang.python

Contents

  I hate you all terminatorul@gmail.com - 2013-04-05 14:41 -0700
    Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-06 08:53 +1100
    Re: I hate you all John Gordon <gordon@panix.com> - 2013-04-05 21:55 +0000
      Re: I hate you all terminatorul@gmail.com - 2013-04-05 15:04 -0700
        Re: I hate you all Andrew Berg <bahamutzero8825@gmail.com> - 2013-04-05 17:28 -0500
        Re: I hate you all Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-05 16:42 -0600
          Re: I hate you all terminatorul@gmail.com - 2013-04-05 17:22 -0700
            Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-06 11:35 +1100
              Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 08:07 +0300
                Re: I hate you all Benjamin Kaplan <benjamin.kaplan@case.edu> - 2013-04-05 22:28 -0700
                Re: I hate you all Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-05 23:53 -0600
                  Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 09:56 +0300
                    Re: I hate you all Joshua Landau <joshua.landau.ws@gmail.com> - 2013-04-06 11:17 +0100
                      Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 17:22 +0300
                        Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-06 15:30 +0000
                        Re: I hate you all Roland Koebler <r.koebler@yahoo.de> - 2013-04-08 00:52 +0200
                Re: I hate you all Michael Torrie <torriem@gmail.com> - 2013-04-05 23:59 -0600
                  Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-06 06:19 +0000
                Re: I hate you all Michael Torrie <torriem@gmail.com> - 2013-04-05 23:49 -0600
            Re: I hate you all Andrew Berg <bahamutzero8825@gmail.com> - 2013-04-05 19:50 -0500
            Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-06 02:07 +0000
            Re: I hate you all Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-05 21:53 -0600
              Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 08:36 +0300
                Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-06 16:44 +1100
                Re: I hate you all Michael Torrie <torriem@gmail.com> - 2013-04-05 23:58 -0600
                  Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 10:07 +0300
                Re: I hate you all Ethan Furman <ethan@stoneleaf.us> - 2013-04-05 23:00 -0700
                  Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-06 15:37 +0000
                    Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 11:49 -0400
                Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-06 06:55 +0000
                Re: I hate you all Larry Hudson <orgnut@yahoo.com> - 2013-04-06 13:17 -0700
                  Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-07 14:37 +0300
              Re: I hate you all Nobody <nobody@nowhere.com> - 2013-04-06 14:52 +0100
                Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-07 01:20 +1100
                  Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-06 17:37 +0300
                  Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 11:01 -0400
                    Re: I hate you all Neil Cerutti <neilc@norwich.edu> - 2013-04-06 15:15 +0000
                      Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-06 15:41 +0000
                        Re: I hate you all rusi <rustompmody@gmail.com> - 2013-04-06 09:00 -0700
                      Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 11:59 -0400
                        Re: I hate you all Neil Cerutti <neilc@norwich.edu> - 2013-04-06 18:48 +0000
                    Re: I hate you all rusi <rustompmody@gmail.com> - 2013-04-06 08:31 -0700
                    Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-07 07:29 +1000
                    Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 01:38 +0000
                  Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-07 01:30 +0000
                    Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 22:15 -0400
                    Re: I hate you all Jason Friedman <jsf80238@gmail.com> - 2013-04-06 20:42 -0600
                    Re: I hate you all Nobody <nobody@nowhere.com> - 2013-04-08 19:43 +0100
                      Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-08 19:48 +0000
                        Re: I hate you all Walter Hurry <walterhurry@lavabit.com> - 2013-04-08 21:25 +0000
                          Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-08 21:29 +0000
                            Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-09 08:00 +1000
                              Re: I hate you all Walter Hurry <walterhurry@lavabit.com> - 2013-04-08 22:51 +0000
                                Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-09 08:57 +1000
                                Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-09 09:33 +0100
                                  Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-09 13:39 +0000
                                    Re: I hate you all Tim Chase <python.list@tim.thechases.com> - 2013-04-09 09:17 -0500
                                    Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-10 00:20 +1000
                                    Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-09 16:51 +0100
                                      Re: I hate you all Walter Hurry <walterhurry@lavabit.com> - 2013-04-09 21:09 +0000
                                        Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-09 23:09 +0100
                                          Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-09 23:21 +0000
                                            Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-10 09:28 +1000
                                              Re: I hate you all Walter Hurry <walterhurry@lavabit.com> - 2013-04-09 23:50 +0000
                                                Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-10 10:31 +1000
                                                  Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-10 02:00 +0000
                                                    Re: I hate you all Chris Angelico <rosuav@gmail.com> - 2013-04-10 12:14 +1000
                                            Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-10 00:39 +0100
                                            Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-10 00:41 +0100
                                      Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-09 21:43 +0000
                      Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-09 02:51 +0000
                        Re: I hate you all rusi <rustompmody@gmail.com> - 2013-04-08 21:06 -0700
                          Re: I hate you all rusi <rustompmody@gmail.com> - 2013-04-08 21:52 -0700
                          Re: I hate you all Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-09 05:19 +0000
            Re: I hate you all "Günther Dietrich" <gd.usenet@spamfence.net> - 2013-04-06 14:55 +0200
          Re: I hate you all terminatorul@gmail.com - 2013-04-05 17:22 -0700
        Re: I hate you all Isaac To <isaac.to@gmail.com> - 2013-04-06 06:35 +0800
        Re: I hate you all Ian Kelly <ian.g.kelly@gmail.com> - 2013-04-05 17:00 -0600
    Re: I hate you all Dylan Evans <dylan@dje.me> - 2013-04-06 14:28 +1000
      Re: I hate you all terminatorul@gmail.com - 2013-04-05 22:13 -0700
        Re: I hate you all Dylan Evans <dylan@dje.me> - 2013-04-07 13:00 +1000
          Re: I hate you all Timothy Madden <terminatorul@gmail.com> - 2013-04-07 14:44 +0300
            Re: I hate you all Ethan Furman <ethan@stoneleaf.us> - 2013-04-07 11:12 -0700
              Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-07 14:33 -0400
      Re: I hate you all terminatorul@gmail.com - 2013-04-05 22:13 -0700
    Re: I hate you all Grant Edwards <invalid@invalid.invalid> - 2013-04-06 15:27 +0000
      Re: I hate you all Roy Smith <roy@panix.com> - 2013-04-06 11:58 -0400
    Re: I hate you all Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-04-07 19:25 +0100

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#42877

On Fri, 05 Apr 2013 17:22:19 -0700, terminatorul wrote:

> On Saturday, April 6, 2013 1:42:15 AM UTC+3, Ian wrote: [...]
>> The "def" line has four spaces.  The "for" line then has a hard tab.
>> This is ambiguous.  If the hard tab is assumed to have a width of four
>> spaces, then they are at the same indentation level.  If it is assumed
>> to have a width of eight spaces, then they are not.
> [...]
> 
> The correct tab stop positions have always been at 8 character columns
> apart. The "ambiguity" was introduced by editors that do not follow the
> default value set in hardware like printers or used by consoles and
> terminal emulators.

This is incorrect. Tab stops come from *typewriters*, where they are user-
configurable to any position on the page without limit. There is no 
requirement for them to be 8 character columns apart, or even a fixed 
number of columns apart. Word processors like OpenOffice and Microsoft 
Word get the behaviour of tab stops right. Any editor which forces tabs 
to be exactly 8 columns apart gets them wrong.


> And now python forces me out of using any tab characters at all.

That is simply not true, and you have been told repeatedly by numerous 
people that Python 3 supports tabs. You can use spaces for indentation, 
and you can use tabs for indentation. You can even mix spaces and tabs in 
the same file. What you cannot do is mix spaces and tabs in the same 
block. If you don't believe us, and you don't believe the documentation, 
then believe the actual behaviour of the Python 3 compiler. Test it for 
yourself. Run this code under Python 3:


=== cut ===

code = """
def spam():
     print("indented with five spaces")

def eggs():
\t\tprint("indented with two tabs")


spam()
eggs()
"""

exec(code)

=== cut ===


If it were my language, I would be even stricter about indentation than 
Python 3. I would require that each file use *only* tabs, or *only* 
spaces, and not allow both in the same file.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#42883

On Fri, Apr 5, 2013 at 6:22 PM,  <terminatorul@gmail.com> wrote:
> The correct tab stop positions have always been at 8 character columns apart.
> The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.

8 characters is common, but no more "correct" than any other, as tab
width has never been standardized.  You talk of not wanting tab
options imposed on you, but consider that treating tabs as 8-character
stops imposes that setting on anybody who needs to work with your
mixed-indentation code.

> And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.

And then changing that setting could change the meaning of the code,
which would be a disaster for code that you want to distribute.

[toc] | [prev] | [next] | [standalone]

#42888

On 06.04.2013 06:53, Ian Kelly wrote:
> On Fri, Apr 5, 2013 at 6:22 PM,  <terminatorul@gmail.com> wrote:
>> The correct tab stop positions have always been at 8 character columns apart.
>> The "ambiguity" was introduced by editors that do not follow the default value set in hardware like printers or used by consoles and terminal emulators.
>
> 8 characters is common, but no more "correct" than any other, as tab
> width has never been standardized.  You talk of not wanting tab
> options imposed on you, but consider that treating tabs as 8-character
> stops imposes that setting on anybody who needs to work with your
> mixed-indentation code.
>
>> And now python forces me out of using any tab characters at all. I believe I should still have a choice, python should at lest give an option to set tab size, if the default of 8 is ambiguous now.
>
> And then changing that setting could change the meaning of the code,
> which would be a disaster for code that you want to distribute.
>

8-character tab stops should be the default. Debating that is I believe 
another topic, and compatibility with python2 should be enough to make 
that debate unnecessary.

You are right, to change the tab size means to change the meaning of the 
code, and that would be wrong. Can't argue with that.

What I want is an option to use the tabs as I have used them in the 
past, with the default size. Since "ambiguity" about the tab size 
appears to be the cause for new python 3 rules, I though of an option 
the make that size explicit. I still think users should somehow have a 
way to use a tab stop of their choice, but how this could be achieved 
properly is another problem.

I guess a discussion like this thread is the price to be paid for 
relying solely on white space to delimit code blocks, like the python 
syntax does.

Thank you,
Timothy Madden

[toc] | [prev] | [next] | [standalone]

#42889

On Sat, Apr 6, 2013 at 4:36 PM, Timothy Madden <terminatorul@gmail.com> wrote:
> I guess a discussion like this thread is the price to be paid for relying
> solely on white space to delimit code blocks, like the python syntax does.

Absolutely. Bring on Python 5000, where all such stupidities are
abolished and we can argue about really important matters, like
whether chr(7) should be allowed in identifiers.

ChrisA

[toc] | [prev] | [next] | [standalone]

#42892

On 04/05/2013 11:36 PM, Timothy Madden wrote:
> I guess a discussion like this thread is the price to be paid for 
> relying solely on white space to delimit code blocks, like the python 
> syntax does.

I've always been taught that in Python using tabs, particularly in the
way that you use them (which, by the way, is the default way vim uses
them when in C++ mode) is fraught with difficulty.  So years ago I
dropped in c couple of lines in my vimrc file to use spaces instead of
tabs and use the PEP standard of 4 spaces.  Have never had any problem.

As for your problems, perhaps instead of coming on the list with a
poorly-thought-out subject line, and desire to simply argue, perhaps you
could run your code through a reformatter that would translate your tabs
into spaces using the tab stop that you desired.  Open the file in vim,
enter the following commands:

set sw=4
set ts=8
set et
set softtabstop=4
set ai
:retab

Then save the file.  Now it's pep-formatted with spaces and no tabs.
Problem solved.  Yes it doesn't address your concerns, but it is the
recommended solution for Python given the difficulties in mixing tabs
and spaces and different people's definition of tabs.

[toc] | [prev] | [next] | [standalone]

#42900

On 06.04.2013 08:58, Michael Torrie wrote:
[...]
> As for your problems, perhaps instead of coming on the list with a
> poorly-thought-out subject line, and desire to simply argue, perhaps you
> could run your code through a reformatter [...]

Hey, I was feeling frustrated ... ! It is how people feel when they no 
longer have a choice they used to have.

But I hear programmers should get used to the feeling: using code that 
you did not write is bound to trigger that reaction every so often.

Timothy Madden

[toc] | [prev] | [next] | [standalone]

#42897

On 04/05/2013 10:36 PM, Timothy Madden wrote:
>
> 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2
> should be enough to make that debate unnecessary.

Python 3 broke a lot of things.  Pull on your big-boy underwear and deal with it.


> Thank you,

Saying 'thank you' does not mitigate you acting like an ass.


--
~Ethan~

[toc] | [prev] | [next] | [standalone]

#42924

On 2013-04-06, Ethan Furman <ethan@stoneleaf.us> wrote:
> On 04/05/2013 10:36 PM, Timothy Madden wrote:
>>
>> 8-character tab stops should be the default. Debating that is I believe another topic, and compatibility with python2
>> should be enough to make that debate unnecessary.
>
> Python 3 broke a lot of things.  Pull on your big-boy underwear and
> deal with it.

Python 3 requires that you wear _underwear_?

That seems entirely arbitrary, and violates the god-given rights of
telecommuters to write code wearing nothing but a bathrobe!

Hell, for all I know, there may be people who go into the office
without underwear. Though I think the lonely, unbathed, unshaven,
robe-wearing telecommuter will be the poster-child for the worldwide
campaign against the undwearist fascists trying to impose their
sartorial dictates on Python users.  Next, we need to pick a song...

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#42927

In article <kjpffa$n35$4@reader1.panix.com>,
 Grant Edwards <invalid@invalid.invalid> wrote:

> On 2013-04-06, Ethan Furman <ethan@stoneleaf.us> wrote:
> > On 04/05/2013 10:36 PM, Timothy Madden wrote:
> >>
> >> 8-character tab stops should be the default. Debating that is I believe 
> >> another topic, and compatibility with python2
> >> should be enough to make that debate unnecessary.
> >
> > Python 3 broke a lot of things.  Pull on your big-boy underwear and
> > deal with it.
> 
> Python 3 requires that you wear _underwear_?

Only at PyCon.

[toc] | [prev] | [next] | [standalone]

#42898

On Sat, 06 Apr 2013 08:36:23 +0300, Timothy Madden wrote:

> 8-character tab stops should be the default. Debating that is I believe
> another topic, and compatibility with python2 should be enough to make
> that debate unnecessary.

Compatibility with Python 2 is not a requirement. Python 3 exists to fix 
a bunch of design flaws and mistakes in Python 2. Among the changes:

- print and exec are now functions, not statements
- the dangerous input function is gone
- raw_input is renamed input
- the distinction between int and long is gone
- the second-string "classic classes" are gone
- strings are Unicode, not bytes
- division is done correctly
- the error-prone syntax of the "except" statement is fixed
- inconsistently named modules are fixed
- the plethora of similar dict methods is cleaned up
- map, filter, zip operate lazily rather than eagerly

and of course

- mixed spaces and tabs for indentation is gone


> You are right, to change the tab size means to change the meaning of the
> code, and that would be wrong. Can't argue with that.

I can argue with that. Changing tab size does *not* change the meaning of 
code, provided you *only* use tabs for indentation.

Using only tabs for indentation is fine. Whether you set your editor to 
display tabs as 2 columns, 4 columns, 8 columns, or a thousand columns 
will make not a whit of difference to the meaning of the code or the 
number of indent levels. This is the Killer Feature of tabs, and it is 
the primary reason why tabs rule and spaces suck for indentation.

(Alas, too many broken tools that can't handle tabs mean that the less-
good standard won.)

Using only spaces for indentation is also fine. Not as good as tabs, 
because if I use spaces, you're stuck reading my code in whatever poorly-
thought out indent I might choose. I've seen developers use *one* space. 
But using only spaces does work.

What does not work in general, is mixing the two. Don't mix them for 
indents, and you'll be fine.


> What I want is an option to use the tabs as I have used them in the
> past, with the default size.

You can continue to use tabs, so long as you don't mix them with spaces.


> Since "ambiguity" about the tab size
> appears to be the cause for new python 3 rules, I though of an option
> the make that size explicit. I still think users should somehow have a
> way to use a tab stop of their choice, but how this could be achieved
> properly is another problem.

Unnecessary complexity to solve a non-problem. Just pick one, tabs or 
spaces, and consistently use it in any one block of code. You don't even 
have to be consistent over an entire file.


> I guess a discussion like this thread is the price to be paid for
> relying solely on white space to delimit code blocks, like the python
> syntax does.

Mixing spaces and tabs for indentation is bad in brace languages too.

http://mailman.linuxchix.org/pipermail/programming/2004-August/001433.html


Maybe if we had smarter editors and smarter diffs and smarter tools in 
general, it wouldn't be a problem. But we don't, so it is.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#42940

On 04/05/2013 10:36 PM, Timothy Madden wrote:

[snip...]

> 8-character tab stops should be the default. Debating that is I believe another topic, and
> compatibility with python2 should be enough to make that debate unnecessary.
>
As everyone keeps telling you -- there is NO default tab size.  Default implies there is an 
OFFICIAL definition, there is none.  There is, however, convention -- which is merely a common 
suggestion, without any force implied.

> What I want is an option to use the tabs as I have used them in the past, with the default size.
> Since "ambiguity" about the tab size appears to be the cause for new python 3 rules, I though of
> an option the make that size explicit. I still think users should somehow have a way to use a
> tab stop of their choice, but how this could be achieved properly is another problem.
>
What you want and what you think are irrelevant.  The Python language (whatever version) is 
already defined.  If you want to use it, you have to accept it and adapt to what it is.  Live 
with it and move on.  Complaining about it is a complete waste of time -- it's NOT going to 
change just because YOU don't like it.

Frankly, with your continuing to rant about this subject is simply making yourself look like an 
obstinate fool.  I've enjoyed following this thread because I find your attitude so ridiculously 
amusing.[1]

> I guess a discussion like this thread is the price to be paid for relying solely on white space
> to delimit code blocks, like the python syntax does.
>
And in actual practice, that has been shown to be a Good Thing.

> Thank you,
> Timothy Madden

      -=- Larry -=-

[1].  I just turned 76 and definitely tend to be a curmudgeon, so sorry if I sound too 
insulting, but it is the way I feel.

[toc] | [prev] | [next] | [standalone]

#42994

On 06.04.2013 23:17, Larry Hudson wrote:
[...]
> What you want and what you think are irrelevant.  The Python language
> (whatever version) is already defined.  If you want to use it, you have
> to accept it and adapt to what it is.  Live with it and move on.
> Complaining about it is a complete waste of time -- it's NOT going to
> change just because YOU don't like it.

Adding an option for fixed size tabs will not change the language
(and someone even suggested I patch my own copy, but this discussion is 
not about me, is about tabs).

>> I guess a discussion like this thread is the price to be paid for
>> relying solely on white space
>> to delimit code blocks, like the python syntax does.
>>
> And in actual practice, that has been shown to be a Good Thing.

Yes, I agree, it is. It just could have been better.

Timothy Madden

[toc] | [prev] | [next] | [standalone]

#42911

On Fri, 05 Apr 2013 21:53:40 -0600, Ian Kelly wrote:

> 8 characters is common, but no more "correct" than any other,

This is pure revisionism. 8-column tabs may never have been a significant
/de jure/ standard (although they have been that in many specific
domains), but they have been a significant /de facto/ standard for almost
as long as computers have existed.

Historically, software and hardware which assigns a meaning to a tab
character has come in two flavours:

1. Tab stops are every 8 columns; this cannot be changed.
2. Tab stops are configurable, defaulting to every 8 columns.

Creating software which, in the absence of both a good reason and an
explicit mechanism for communicating the configured value, treats them as
configurable is usually a consequence of a "code now, think later"
mentality (although there may have be a few cases where it was a
deliberate "embrace, extend, extinguish" tactic).

[toc] | [prev] | [next] | [standalone]

#42912

On Sun, Apr 7, 2013 at 12:52 AM, Nobody <nobody@nowhere.com> wrote:
> Historically, software and hardware which assigns a meaning to a tab
> character has come in two flavours:
>
> 1. Tab stops are every 8 columns; this cannot be changed.
> 2. Tab stops are configurable, defaulting to every 8 columns.

3. Tab stops are measured in something other than characters.

With variable-width fonts, it's illogical to set tab stops in
characters. DeScribe Word Processor defined them in centimeters, way
back in the early... well, I didn't meet it till the 90s, but I don't
know how long it had been around before that.

ChrisA

[toc] | [prev] | [next] | [standalone]

#42914

On 06.04.2013 17:20, Chris Angelico wrote:
> On Sun, Apr 7, 2013 at 12:52 AM, Nobody <nobody@nowhere.com> wrote:
>> Historically, software and hardware which assigns a meaning to a tab
>> character has come in two flavours:
>>
>> 1. Tab stops are every 8 columns; this cannot be changed.
>> 2. Tab stops are configurable, defaulting to every 8 columns.
>
> 3. Tab stops are measured in something other than characters.
>
> With variable-width fonts, it's illogical to set tab stops in
> characters. DeScribe Word Processor defined them in centimeters, way
> back in the early... well, I didn't meet it till the 90s, but I don't
> know how long it had been around before that.

Yes, but systems with variable-width fonts do not make the default for 
the tab size now.

[toc] | [prev] | [next] | [standalone]

#42917

In article <mailman.200.1365258042.3114.python-list@python.org>,
 Chris Angelico <rosuav@gmail.com> wrote:

> On Sun, Apr 7, 2013 at 12:52 AM, Nobody <nobody@nowhere.com> wrote:
> > Historically, software and hardware which assigns a meaning to a tab
> > character has come in two flavours:
> >
> > 1. Tab stops are every 8 columns; this cannot be changed.
> > 2. Tab stops are configurable, defaulting to every 8 columns.
> 
> 3. Tab stops are measured in something other than characters.
> 
> With variable-width fonts, it's illogical to set tab stops in
> characters. DeScribe Word Processor defined them in centimeters, way
> back in the early... well, I didn't meet it till the 90s, but I don't
> know how long it had been around before that.

What makes sense for a word processor and what makes sense for a 
programming language are two very different things.

Word processors are almost always working with blocks of running text, 
set in proportional fonts, often with multiple font sizes and styles.  
It is usually assumed that line breaks are ephemeral, i.e. as the text 
gets edited and reformatted, lines will re-flow.

Program text is almost always(*) displayed in a fixed-width font.  No 
font information is carried along with the program text at all; it is 
assumed the reader will pick a font and size of their own preference, 
with the only requirement being that it's monospaced.

(*) There was a fad about 10 or 15 years ago to print code samples in 
books in proportional fonts.  Prentice-Hall seemed to be particularly 
guilty of this.  Fortunately, common sense prevailed and everybody has 
gone back to monotype.

[toc] | [prev] | [next] | [standalone]

#42919

On 2013-04-06, Roy Smith <roy@panix.com> wrote:
> (*) There was a fad about 10 or 15 years ago to print code
> samples in books in proportional fonts.  Prentice-Hall seemed
> to be particularly guilty of this.  Fortunately, common sense
> prevailed and everybody has gone back to monotype.

Bjarne Stroustrup likes it, and I agree with him that code is
even easier to read that way, especially in hard-copy.

But most tools have not caught up with the idea. I'll switch as
soon as vim supports it.

-- 
Neil Cerutti

[toc] | [prev] | [next] | [standalone]

#42925

On 2013-04-06, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2013-04-06, Roy Smith <roy@panix.com> wrote:
>> (*) There was a fad about 10 or 15 years ago to print code
>> samples in books in proportional fonts.  Prentice-Hall seemed
>> to be particularly guilty of this.  Fortunately, common sense
>> prevailed and everybody has gone back to monotype.
>
> Bjarne Stroustrup likes it, and I agree with him that code is
> even easier to read that way, especially in hard-copy.

I'd have to disagree.  There are too many times when things are easier
to read/maintain by visually aligning columns:

 * struct/array initializers

 * constant definitions

 * parallel/identical operations on multiple different variables

 * vertical alignment of a parameter lists in multi-line function calls

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#42930

On Apr 6, 8:41 pm, Grant Edwards <inva...@invalid.invalid> wrote:
> On 2013-04-06, Neil Cerutti <ne...@norwich.edu> wrote:
>
> > On 2013-04-06, Roy Smith <r...@panix.com> wrote:
> >> (*) There was a fad about 10 or 15 years ago to print code
> >> samples in books in proportional fonts.  Prentice-Hall seemed
> >> to be particularly guilty of this.  Fortunately, common sense
> >> prevailed and everybody has gone back to monotype.
>
> > Bjarne Stroustrup likes it, and I agree with him that code is
> > even easier to read that way, especially in hard-copy.
>
> I'd have to disagree.  There are too many times when things are easier
> to read/maintain by visually aligning columns:
>
>  * struct/array initializers
>
>  * constant definitions
>
>  * parallel/identical operations on multiple different variables
>
>  * vertical alignment of a parameter lists in multi-line function calls
>
> --
> Grant

I believe that it is at least possible to wish for the best of all
worlds.
http://nickgravgaard.com/elastictabstops/ (browser needs java)

Pragmatically I continue to use emacs with a fixed-width font.
Not claiming I am too happy with this choice. That includes a whole
lot of stuff, not just fonts

[toc] | [prev] | [next] | [standalone]

#42929

In article <asasgoFj03gU1@mid.individual.net>,
 Neil Cerutti <neilc@norwich.edu> wrote:
 
> Bjarne Stroustrup likes it

This is supposed to impress me?

Yeah, most of the books I recall that used this were C++ books.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web