Re: Who are the "spacists"?

[Wildman via Python-list]

On Sun, 26 Mar 2017 15:18:06 +0200, Mikhail V wrote:

> On 26 March 2017 at 06:16, Wildman via Python-list
>  wrote:
>> On Tue, 21 Mar 2017 15:15:14 +0100, Mikhail V wrote:
>>
>>> And on linux console, by default one does not even have good
>>> possibilities for text-mode pseudographics, it was more relevant
>>> in DOS where one had rich possibilities and programmable
>>> binary fonts.
>>>
>>> Mikhail
>>
>> Nonsense.
> 
> Why? IIRC I can do good pseudographics on linux only with extended
> unicode character sets, so yes it is possible, is that what you mean?

No.  The same ASCII character set that was available in DOS is
available in Linux without unicode.

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 26 March 2017 at 06:16, Wildman via Python-list
 wrote:
> On Tue, 21 Mar 2017 15:15:14 +0100, Mikhail V wrote:
>
>> And on linux console, by default one does not even have good
>> possibilities for text-mode pseudographics, it was more relevant
>> in DOS where one had rich possibilities and programmable
>> binary fonts.
>>
>> Mikhail
>
> Nonsense.

Why? IIRC I can do good pseudographics on linux only with extended
unicode character sets, so yes it is possible, is that what you mean?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Wildman via Python-list]

On Tue, 21 Mar 2017 15:15:14 +0100, Mikhail V wrote:

> And on linux console, by default one does not even have good
> possibilities for text-mode pseudographics, it was more relevant
> in DOS where one had rich possibilities and programmable
> binary fonts.
> 
> Mikhail

Nonsense.

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEOPLE! PLEASE! [ WAS: Re: Who are the "spacists"? ]

[Mikhail V]

On 26 March 2017 at 00:01, Michael Torrie  wrote:
> On 03/25/2017 01:40 PM, Gilmeh Serda wrote:
>>
 So Python supports both spaces and tabs for indentation.
>>
>> People!
>>
>> This is as far from normal conversation about Python as it gets!
>>
>> Keep this shit to yourselves, PLEASE!
>>
>> Using an editor worth the name, makes it a non issue (since it can
>> convert between one and the other, Eclipse/LiClipse comes to mind). Get
>> real, and think before you post/send!
>
> I agree, although this thread had pretty much died on its own before you
> posted to it. Our troll seems to have slunk off, having done his
> trolling.  Peace had returned it seemed.  Unless the mailing list mods
> finally banned the guy... either way I haven't seen any posts in a while.

Oh don't turn it into drama please, it was interesting discussion.
Sad is that many are more in sociology than technology.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEOPLE! PLEASE! [ WAS: Re: Who are the "spacists"? ]

[Michael Torrie]

On 03/25/2017 01:40 PM, Gilmeh Serda wrote:
> 
>>> So Python supports both spaces and tabs for indentation.
> 
> People!
> 
> This is as far from normal conversation about Python as it gets!
> 
> Keep this shit to yourselves, PLEASE!
> 
> Using an editor worth the name, makes it a non issue (since it can 
> convert between one and the other, Eclipse/LiClipse comes to mind). Get 
> real, and think before you post/send!

I agree, although this thread had pretty much died on its own before you
posted to it. Our troll seems to have slunk off, having done his
trolling.  Peace had returned it seemed.  Unless the mailing list mods
finally banned the guy... either way I haven't seen any posts in a while.

Also USENET has a long tradition of killfiles. And entire threads can be
muted on most clients, including e-mail clients. I recommend you and
everyone else use these tools.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PEOPLE! PLEASE! [ WAS: Re: Who are the "spacists"? ]

[Joel Goldstick]

On Sat, Mar 25, 2017 at 3:40 PM, Gilmeh Serda
 wrote:
>
>>> So Python supports both spaces and tabs for indentation.
>
> People!
>
> This is as far from normal conversation about Python as it gets!
>
> Keep this shit to yourselves, PLEASE!
>
> Using an editor worth the name, makes it a non issue (since it can
> convert between one and the other, Eclipse/LiClipse comes to mind). Get
> real, and think before you post/send!
>
> --
> Gilmeh
> --
> https://mail.python.org/mailman/listinfo/python-list

+1


-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Ian Kelly]

On Tue, Mar 21, 2017 at 7:28 PM, Ben Finney  wrote:
> Grant Edwards  writes:
>
>> Question: is it still successfull trolling if we all knew that was the
>> intent and are just playing along for the entertainment value?
>
> Yes, it creates more noise and drives away signal from people who don't
> want to be in a noisy environment. That is success for the troll.

+1. Arguing with trolls is like tic-tac-toe or global thermonuclear
war: the only way to win is not to play.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Ben Finney]

Grant Edwards  writes:

> Question: is it still successfull trolling if we all knew that was the
> intent and are just playing along for the entertainment value?

Yes, it creates more noise and drives away signal from people who don't
want to be in a noisy environment. That is success for the troll.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\  Brain, but isn't that why they invented tube socks?” —_Pinky |
_o__)   and The Brain_ |
Ben Finney

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 21 March 2017 at 16:42, Michael Torrie  wrote:
> On 03/21/2017 08:15 AM, Mikhail V wrote:
>> Didn't want to say this, but you know it was quite predictable from
>> the beginning that
>> the arguments will end up somewhere in "linux console is the center of the
>> universe, e-macs is mother of all apps and monospaced text is peak of
>> human evolution".
>
> Knowing that, the honest question is: if you knew where this would all
> end up (in a heated argument), why did post your provocation in the
> first place?

That was a metaphor, it was predictable that arguments
will touch some retro aspects, but it was quite unpredictable
that till now I did not see good arguments for spaces, and
I was interested of course to see some technical aspects.

So one of mentioned points for spaces which I can count as
more or less real argument, that many web forms keep
converting tabs to spaces, when I paste code into them
and when I copy back into the editor, I need again to
convert them. This is not a good argument against
tabs but this is at least a *real* issue. Unlike other,
(not so logical or yet not supported) arguments.

Does it sound reasonable?
Why I ask? Well obviously because I and probably
many people want to know why cannot one make
sort of styleguide based on pros and cons.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 21 March 2017 at 22:40, Chris Angelico  wrote:
> On Wed, Mar 22, 2017 at 8:27 AM, Mikhail V  wrote:
>> I'd just tell one thing since I am a bit tired: if you wish,
>> take an advice: avoid *any* monospaced fonts as plague if you are
>> reading a lot of information, this includes coding.
>> Avoid *any* sepia color schemes as plague.
>> Avoid *any* sans-serif font. Get the most close
>> to Garamond or Perpetua font.
>>
>> For cases, where you *absolutely must* use monospaced
>> font, stick to Courier font (it is called "Courier 10 pitch" on Linux, if
>> you don't have it in the system, try to find it, it must be
>> in some true type font package).
>> As for editing executables I don't know what *exactly*
>> are you trying to do, what processes are involved,
>> so I can't advice much.
>> And don't worry if a zero does not look like a pusy,
>> but looks like a big O, this is irrelevant in most cases.
>>
>> Now if you follow this, then probably in some time you
>> will say: thanks, good man Mikhail.
>
> Thanks, good troll Mikhail. You started a nice thread, but your advice
> is now crystal clear for what it is: duff.
>

Youre welcome, good troll Chris  :)
And in this thread (apart this comment) you were reasonable, I am pleased.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Wed, Mar 22, 2017 at 8:27 AM, Mikhail V  wrote:
> I'd just tell one thing since I am a bit tired: if you wish,
> take an advice: avoid *any* monospaced fonts as plague if you are
> reading a lot of information, this includes coding.
> Avoid *any* sepia color schemes as plague.
> Avoid *any* sans-serif font. Get the most close
> to Garamond or Perpetua font.
>
> For cases, where you *absolutely must* use monospaced
> font, stick to Courier font (it is called "Courier 10 pitch" on Linux, if
> you don't have it in the system, try to find it, it must be
> in some true type font package).
> As for editing executables I don't know what *exactly*
> are you trying to do, what processes are involved,
> so I can't advice much.
> And don't worry if a zero does not look like a pusy,
> but looks like a big O, this is irrelevant in most cases.
>
> Now if you follow this, then probably in some time you
> will say: thanks, good man Mikhail.

Thanks, good troll Mikhail. You started a nice thread, but your advice
is now crystal clear for what it is: duff.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 21 March 2017 at 17:41, Gene Heskett  wrote:
> On Tuesday 21 March 2017 11:04:58 Mikhail V wrote:
>
>> On 21 March 2017 at 15:49, Grant Edwards 
> wrote:
>> > On 2017-03-21, Mikhail V  wrote:
>> >
>> >> I don't know how to help, probably if there is an important
>> >> document which you want different people to read, just make plain
>> >> txt, or HTML table, Office document, PNG image, etc.  Or just use
>> >> spaces if it is for ASCII-art purposes.
>> >
>> > Well written code _is_ ASCII-art.
>>
>> Written code is ASCII-art only if you live in the Monospaced Kingdom,

>
> Whats wrong with Monospace (caps yours)? In case you've not heard the
> news, we (linux users, other platform unk, don't use them) have a font,
> called "hack" (announced several years ago) that is not only Monospaced
> but quite civilized to look at. I use it for editing any executable
> codes source language, and here in kmail too.
>

This was already discussed here what is wrong with monospaced,
but ok, since you question. Look, I know what is Hack font as
well a lot of other thing about fonts, since I work on fonts
and reading-related problems my whole life.
I'd just tell one thing since I am a bit tired: if you wish,
take an advice: avoid *any* monospaced fonts as plague if you are
reading a lot of information, this includes coding.
Avoid *any* sepia color schemes as plague.
Avoid *any* sans-serif font. Get the most close
to Garamond or Perpetua font.

For cases, where you *absolutely must* use monospaced
font, stick to Courier font (it is called "Courier 10 pitch" on Linux, if
you don't have it in the system, try to find it, it must be
in some true type font package).
As for editing executables I don't know what *exactly*
are you trying to do, what processes are involved,
so I can't advice much.
And don't worry if a zero does not look like a pusy,
but looks like a big O, this is irrelevant in most cases.

Now if you follow this, then probably in some time you
will say: thanks, good man Mikhail.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Gene Heskett]

On Tuesday 21 March 2017 11:04:58 Mikhail V wrote:

> On 21 March 2017 at 15:49, Grant Edwards  
wrote:
> > On 2017-03-21, Mikhail V  wrote:
> >> Didn't want to say this, but you know it was quite predictable from
> >> the beginning that the arguments will end up somewhere in "linux
> >> console is the center of the universe, e-macs is mother of all apps
> >> and monospaced text is peak of human evolution".
> >
> > Well, I'm glad you've finally admitted it. :)
> >
> >> I don't know how to help, probably if there is an important
> >> document which you want different people to read, just make plain
> >> txt, or HTML table, Office document, PNG image, etc.  Or just use
> >> spaces if it is for ASCII-art purposes.
> >
> > Well written code _is_ ASCII-art.
>
> Written code is ASCII-art only if you live in the Monospaced Kingdom,

Whats wrong with Monospace (caps yours)? In case you've not heard the 
news, we (linux users, other platform unk, don't use them) have a font, 
called "hack" (announced several years ago) that is not only Monospaced 
but quite civilized to look at. I use it for editing any executable 
codes source language, and here in kmail too.

> and even there, only if you draw ASCII-art in multi-line comment
> blocks. But its true, that it will have a notable place in a museum.
>
> Mikhail


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Grant Edwards]

On 2017-03-21, Jon Ribbens  wrote:
> On 2017-03-21, Michael Torrie  wrote:
>> On 03/21/2017 08:15 AM, Mikhail V wrote:
>>> Didn't want to say this, but you know it was quite predictable from
>>> the beginning that the arguments will end up somewhere in "linux
>>> console is the center of the universe, e-macs is mother of all apps
>>> and monospaced text is peak of human evolution".
>>
>> Knowing that, the honest question is: if you knew where this would all
>> end up (in a heated argument), why did post your provocation in the
>> first place?
>
> Seriously, could the trolling be any more obvious? Or successful?

Question: is it still successfull trolling if we all knew that was the
intent and are just playing along for the entertainment value?

-- 
Grant Edwards   grant.b.edwardsYow! Well, O.K.
  at   I'll compromise with my
  gmail.comprinciples because of
   EXISTENTIAL DESPAIR!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Jon Ribbens]

On 2017-03-21, Michael Torrie  wrote:
> On 03/21/2017 08:15 AM, Mikhail V wrote:
>> Didn't want to say this, but you know it was quite predictable from
>> the beginning that the arguments will end up somewhere in "linux
>> console is the center of the universe, e-macs is mother of all apps
>> and monospaced text is peak of human evolution".
>
> Knowing that, the honest question is: if you knew where this would all
> end up (in a heated argument), why did post your provocation in the
> first place?

Seriously, could the trolling be any more obvious? Or successful?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Rhodri James]

On 21/03/17 15:04, Mikhail V wrote:

On 21 March 2017 at 15:49, Grant Edwards  wrote:

On 2017-03-21, Mikhail V  wrote:


Didn't want to say this, but you know it was quite predictable from
the beginning that the arguments will end up somewhere in "linux
console is the center of the universe, e-macs is mother of all apps
and monospaced text is peak of human evolution".


Well, I'm glad you've finally admitted it. :)


I don't know how to help, probably if there is an important document
which you want different people to read, just make plain txt, or
HTML table, Office document, PNG image, etc.  Or just use spaces if
it is for ASCII-art purposes.


Well written code _is_ ASCII-art.


Written code is ASCII-art only if you live in the Monospaced Kingdom,
and even there, only if you draw ASCII-art in multi-line comment blocks.
But its true, that it will have a notable place in a museum.


You misunderstand; well-written code has a pleasing shape all of its 
own, never mind any deliberate attempts at diagramming.  You may be 
correct that it is only true in the Monospaced Kingdom; if so, that's a 
major plus point for fixed-width fonts.


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Michael Torrie]

On 03/21/2017 08:15 AM, Mikhail V wrote:
> Didn't want to say this, but you know it was quite predictable from
> the beginning that
> the arguments will end up somewhere in "linux console is the center of the
> universe, e-macs is mother of all apps and monospaced text is peak of
> human evolution".

Knowing that, the honest question is: if you knew where this would all
end up (in a heated argument), why did post your provocation in the
first place?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Wed, Mar 22, 2017 at 1:38 AM, Marko Rauhamaa  wrote:
> State of the art. Thankfully, the editor of the RFC chose not to use
> tabs.

Exactly. Because tabs are the wrong character to use for this kind of
thing. So you see, this is not any fault of tabs - what you're
pointing out is that misusing them causes problems. What a surprise.
But using them appropriately has yet been shown to cause any problems.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 21 March 2017 at 15:49, Grant Edwards  wrote:
> On 2017-03-21, Mikhail V  wrote:
>
>> Didn't want to say this, but you know it was quite predictable from
>> the beginning that the arguments will end up somewhere in "linux
>> console is the center of the universe, e-macs is mother of all apps
>> and monospaced text is peak of human evolution".
>
> Well, I'm glad you've finally admitted it. :)
>
>> I don't know how to help, probably if there is an important document
>> which you want different people to read, just make plain txt, or
>> HTML table, Office document, PNG image, etc.  Or just use spaces if
>> it is for ASCII-art purposes.
>
> Well written code _is_ ASCII-art.

Written code is ASCII-art only if you live in the Monospaced Kingdom,
and even there, only if you draw ASCII-art in multi-line comment blocks.
But its true, that it will have a notable place in a museum.

Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Mikhail V :

> On 21 March 2017 at 14:42, Marko Rauhamaa  wrote:
>> - Draw this box starting from the top left corner and circling
>>   clockwise:
>>
>> +--+
>> |  |
>> |  |
>> +--+
>>
>
> Didn't want to say this, but you know it was quite predictable from
> the beginning that the arguments will end up somewhere in "linux
> console is the center of the universe, e-macs is mother of all apps
> and monospaced text is peak of human evolution".
>
> I don't know how to help, probably if there is an important document
> which you want different people to read, just make plain txt, or HTML
> table, Office document, PNG image, etc. Or just use spaces if it is
> for ASCII-art purposes.
>
> And on linux console, by default one does not even have good
> possibilities for text-mode pseudographics, it was more relevant in
> DOS where one had rich possibilities and programmable binary fonts.

Here's what I have studied today (HTTP/2):

 +---+
 | Length (24)   |
 +---+---+---+
 |   Type (8)|   Flags (8)   |
 +-+-+---+---+
 |R| Stream Identifier (31)  |
 +=+=+
 |   Frame Payload (0...)  ...
 +---+


   [...]


++
send PP || recv PP
   ,|  idle  |.
  / || \
 v  ++  v
  +--+  |   +--+
  |  |  | send H /  |  |
   ,--| reserved |  | recv H| reserved |--.
   |  | (local)  |  |   | (remote) |  |
   |  +--+  v   +--+  |
   |  | ++ |  |
   |  | recv ES || send ES |  |
   |   send H | ,---|  open  |---. | recv H   |
   |  |/||\|  |
   |  v   v ++ v   v  |
   |  +--+  |   +--+  |
   |  |   half   |  |   |   half   |  |
   |  |  closed  |  | send R /  |  closed  |  |
   |  | (remote) |  | recv R| (local)  |  |
   |  +--+  |   +--+  |
   |   || |   |
   |   | send ES /  |   recv ES / |   |
   |   | send R /   vsend R / |   |
   |   | recv R ++   recv R   |   |
   | send R /  `--->||<---'  send R / |
   | recv R | closed |   recv R   |
   `--->||<--'
++

   http://httpwg.org/specs/rfc7540.html>

State of the art. Thankfully, the editor of the RFC chose not to use
tabs.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Jussi Piitulainen]

Grant Edwards writes:

> Well written code _is_ ASCII-art.

:)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Grant Edwards]

On 2017-03-21, Mikhail V  wrote:

> Didn't want to say this, but you know it was quite predictable from
> the beginning that the arguments will end up somewhere in "linux
> console is the center of the universe, e-macs is mother of all apps
> and monospaced text is peak of human evolution".

Well, I'm glad you've finally admitted it. :)

> I don't know how to help, probably if there is an important document
> which you want different people to read, just make plain txt, or
> HTML table, Office document, PNG image, etc.  Or just use spaces if
> it is for ASCII-art purposes.

Well written code _is_ ASCII-art.

-- 
Grant Edwards   grant.b.edwardsYow! Do I have a lifestyle
  at   yet?
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Grant Edwards]

On 2017-03-21, Wildman via Python-list  wrote:

> I would love to hear also.  I've been using Linux for about
> 10 years and I have never had anything "break" because of a
> tab.  Sounds like a case of Chicken Little to me.

The main problem is that when you display/print a program that uses
tabs on something that expands them to every 8-columns, you often end
up with much of the code so far to the right you can't see much of it.

Another problem is that people will use tabs to do things like line up
comments to the right of code.  That only works if the program
displaying/printing the code has tab widths that match the authors.

-- 
Grant Edwards   grant.b.edwardsYow! I'm having a MID-WEEK
  at   CRISIS!
  gmail.com

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 21 March 2017 at 14:42, Marko Rauhamaa  wrote:
> Wildman :
>
>> On Tue, 21 Mar 2017 06:01:26 +1100, Chris Angelico wrote:
>>> Can you ask your workmates to elaborate? I'd love to hear.
>>
>> I would love to hear also. I've been using Linux for about 10 years
>> and I have never had anything "break" because of a tab. Sounds like a
>> case of Chicken Little to me.
>
> Example:
>
> - Start emacs with the default settings.
>
> - Edit buffer "abc": C-x C-b abc
>
> - Start drawing: M-x picture-mode
>
> - Draw this box starting from the top left corner and circling
>   clockwise:
>
> +--+
> |  |
> |  |
> +--+
>

Didn't want to say this, but you know it was quite predictable from
the beginning that
the arguments will end up somewhere in "linux console is the center of the
universe, e-macs is mother of all apps and monospaced text is peak of
human evolution".

I don't know how to help, probably if there is an important document
which you want different people to read, just make plain
txt, or HTML table, Office document, PNG image, etc.
Or just use spaces if it is for ASCII-art purposes.

And on linux console, by default one does not even have good
possibilities for text-mode pseudographics, it was more relevant
in DOS where one had rich possibilities and programmable
binary fonts.

Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Wildman :

> On Tue, 21 Mar 2017 06:01:26 +1100, Chris Angelico wrote:
>> Can you ask your workmates to elaborate? I'd love to hear.
>
> I would love to hear also. I've been using Linux for about 10 years
> and I have never had anything "break" because of a tab. Sounds like a
> case of Chicken Little to me.

Example:

- Start emacs with the default settings.

- Edit buffer "abc": C-x C-b abc

- Start drawing: M-x picture-mode

- Draw this box starting from the top left corner and circling
  clockwise:

+--+
|  |
|  |
+--+

- Move the cursor to the beginning of the first line of the box.
  Try to move the box to the left by three columns:

  C-SPC C-n C-n C-n C-f C-f C-f C-x r k

  What you get is:

 +--+
|  |
|  |
+--+

  because only the first line was indented with spaces. Emacs uses
  when opening the other lines.

If you disable tabs (or untabify), you get the intended result:

 +--+
 |  |
 |  |
 +--+

This is only an example. Analogous annoyances crop up in all kinds of
editing.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Wildman via Python-list]

On Tue, 21 Mar 2017 06:01:26 +1100, Chris Angelico wrote:

> On Tue, Mar 21, 2017 at 4:39 AM, Steve D'Aprano
>  wrote:
>> And yet I'm forever being told by my Linux sys admin work mates "don't use
>> tabs, because they break everything". For another example, see JMZ's essay
>> (its already been linked to twice in this thread, look it up).
>>
>> We've had a similar attitude right here from Marko, who insists that
>> anything except 8-column tabs is the Devil's Work. (Or something like
>> that -- to be perfectly honest, I'm not really sure I understand *what*
>> Marko's objection is.)
>>
>> So okay, if tabs work fine with Unix tools, why do so many Unix people avoid
>> tabs as if they were radioactive plague?
> 
> Can you ask your workmates to elaborate? I'd love to hear.
> 
> ChrisA

I would love to hear also.  I've been using Linux for about
10 years and I have never had anything "break" because of a
tab.  Sounds like a case of Chicken Little to me.

-- 
 GNU/Linux user #557453
The cow died so I don't need your bull!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 20 March 2017 at 16:19, BartC  wrote:
> On 20/03/2017 14:32, Chris Angelico wrote:
>>
>> On Tue, Mar 21, 2017 at 1:24 AM, BartC  wrote:
>>>
>>> But it would be better IMO if tabs were used, with some scheme for
>>> suggesting the tab width (or set of tab stops) that is recommended (eg. a
>>> comment at the top).
>>
>>
>> If you absolutely have to, then sure, put a directive in some
>> machine-readable way at the top or bottom of the file. It's like the
>> coding cookie that Python follows - some editors also respect it. But
>> I would prefer to just use tabs *without* suggesting a width, because
>> each one represents *one indent*. Not a number of spaces. One
>> indentation level.
>
>
> For leading tabs at the start of a new statement that wouldn't be a problem.
> Changing the tab width shown just spreads out statements more, or less,
> horizontally.
>
> It works - there is no jarring misalignment - because each tab corresponds
> to the same N spaces, whatever N happens to be.
>
> But tabs are also used after statements, before comments for example, or to
> line up elements in tables. Then it doesn't work, because tabs may represent
> 1 to N spaces:
>
> Using N=4, with 1 tab before each number:
>
> (one,   1), #comment 1
> (two,   2), #comment 2
> (three, 3), #comment 3
> ...

Well, the definition of tabwidth in file could help only in theory,
As already said, one cannot define a tab as N charaters,
since character size is not a constant.
Don't assume that one uses monospaced
editor. For screen, generally, the units are pixels.
(warning: thinking too much about it can be brain-damaging)

Reasonable solution is just to be patient and wait
before IDEs can render tables inside a document depending
on the context. This would mean exactly 1 tab as separator.
Before that I'd say just don't worry much if
your layout will look not so nice, and not be so fanatic
with inserting multi-column content into the source code.

Tab-separated tables is actually what I use on a daily
basis, e.g copy-pasting from Excell to TXT file back
and forth, and my scripts parse tables usually as tab-separated
txt file.

And I'd say again, don't spam multiple spaces anywhere, it will be harder
to pluck them out for the collegues (and probably for the
document creator in the future).
My rule of thumb: if I see multiple spaces in any document,
something is probably wrong (except ASCII art:))).

So if one'd ask, this would be roughly my styleguide.


Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Gregory Ewing]

Steve D'Aprano wrote:

But wait... before there was COBOL, there were *typewriters*. Its been many
years since I've had my hands on a manual typewriter, but if I remember
correctly the standard default tab setting was 1 inch.


I haven't used many manual typewriters, but on the ones I have
used, there were no "standard" tab stops -- you configured them
yourself, wherever you wanted.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 8:19 AM, alister  wrote:
> On Tue, 21 Mar 2017 06:04:12 +1100, Chris Angelico wrote:
>
>> On Tue, Mar 21, 2017 at 5:57 AM, alister 
>> wrote:
>>> I have just tested this with geany & it works a charm,
>>>
>>> personally I prefer tabs for setting my indent levels, it feels more
>>> logical & breaks nothing if the font or tab size is changed but votes
>>> have been counted & the jury has returned a verdict
>>>
>>> Spaces are the preferred option, but you are still able to make your
>>> own choice.
>>
>> I'm so glad the world isn't a democracy. "The votes have been counted"
>> means nothing. :)
>>
>> ChrisA
>
> you know as well as Id that I meant this discussion was had many years
> ago & the decision was made.
>
> to be honest I don't know whether it was by a consensus of the community
> or simply Guido tossing a coin. either way does not matter it is not
> something that is going to change now.
>
> fortunately both tabs & spaces are still supported so individual
> programmes can still make their own decisions, the only time it makes any
> difference is when working on a collaboration with other programmers when
> style guides have to be agreed.

See, that's the thing. PEP 7 and PEP 8 govern the source code for the
Python language itself, and there is no requirement to follow their
recommendations in other projects. If you choose to adopt PEP 8 as the
basis of your style guide, you should still make your own decisions on
the points where the specific recommendations are less important than
internal consistency - and tabs vs spaces is definitely one of them.
The decision has NOT been made for the entire Python community.

And even the decision governing the standard library was not on the
basis of a vote. It was the basis of a considered decision by the
person responsible. Like I said, the world - and Python - is not a
democracy. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[alister]

On Tue, 21 Mar 2017 06:04:12 +1100, Chris Angelico wrote:

> On Tue, Mar 21, 2017 at 5:57 AM, alister 
> wrote:
>> I have just tested this with geany & it works a charm,
>>
>> personally I prefer tabs for setting my indent levels, it feels more
>> logical & breaks nothing if the font or tab size is changed but votes
>> have been counted & the jury has returned a verdict
>>
>> Spaces are the preferred option, but you are still able to make your
>> own choice.
> 
> I'm so glad the world isn't a democracy. "The votes have been counted"
> means nothing. :)
> 
> ChrisA

you know as well as Id that I meant this discussion was had many years 
ago & the decision was made.

to be honest I don't know whether it was by a consensus of the community 
or simply Guido tossing a coin. either way does not matter it is not 
something that is going to change now.

fortunately both tabs & spaces are still supported so individual 
programmes can still make their own decisions, the only time it makes any 
difference is when working on a collaboration with other programmers when 
style guides have to be agreed.

if I was to say only a Nazi world try to enforce one or the other at this 
stage in the languages evolution can we call Godwin's on this un-
Productive debate ;-)



-- 
Remembering is for those who have forgotten.
-- Chinese proverb
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 5:57 AM, alister  wrote:
> I have just tested this with geany & it works a charm,
>
> personally I prefer tabs for setting my indent levels, it feels more
> logical & breaks nothing if the font or tab size is changed but votes
> have been counted & the jury has returned a verdict
>
> Spaces are the preferred option, but you are still able to make your own
> choice.

I'm so glad the world isn't a democracy. "The votes have been counted"
means nothing. :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Steve D'Aprano :

> On Tue, 21 Mar 2017 12:30 am, Marko Rauhamaa wrote:
>
>> Unicode was 25 years late to the game
>
> I don't understand that comment. Are you suggesting that the oldest
> convention wins? The Unix 8-column convention is older than Unicode, so it
> wins?

The 8-column convention is older, alive and well on Unix so it wins on
Unix.

> Well... in that case, there are tab conventions that pre-date Unix, e.g.
> those used by COBOL.

COBOL is not highly relevant in the Unix world.

> But wait... before there was COBOL, there were *typewriters*.

Typewriters and teletypes are indeed behind the original intended
(pre-Unix) semantics of things like BS, HT, CR and LF. However, they
acquired modified meanings in Unix. For example, CR on input is
converted to an LF, and LF on output is converted to a CRLF.

> So there you go. Unix was 50+ years late to the game.

Unix is normative for Unix.

I seem to recall, though, that the same 8-column interpretation was
there with CP/M and MS-DOS. The practice must be older:

   In practice, settable tab stops were rather quickly replaced with
   fixed tab stops, de facto standardized at every multiple of 8
   characters horizontally, and every 6 lines vertically (typically one
   inch vertically). A printing program could easily send the necessary
   spaces or line feeds to move to any position wanted on a form, and
   this was far more reliable than the modal and non-standard methods of
   setting tab stops. Tab characters simply became a form of data
   compression.

   https://en.wikipedia.org/wiki/Tab_key>


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 4:39 AM, Steve D'Aprano
 wrote:
> And yet I'm forever being told by my Linux sys admin work mates "don't use
> tabs, because they break everything". For another example, see JMZ's essay
> (its already been linked to twice in this thread, look it up).
>
> We've had a similar attitude right here from Marko, who insists that
> anything except 8-column tabs is the Devil's Work. (Or something like
> that -- to be perfectly honest, I'm not really sure I understand *what*
> Marko's objection is.)
>
> So okay, if tabs work fine with Unix tools, why do so many Unix people avoid
> tabs as if they were radioactive plague?

Can you ask your workmates to elaborate? I'd love to hear.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[alister]

On Sun, 19 Mar 2017 23:01:22 +, Erik wrote:

> On 19/03/17 22:29, Jon Ribbens wrote:
>> On 2017-03-19, breamore...@gmail.com  wrote:
>>> On Sunday, March 19, 2017 at 9:54:52 PM UTC, Larry Hudson wrote:
 A trivial point (and irrelevant)...  The thing I find annoying about
 an editor set to expand tabs to spaces is that it takes one keypress
 to indent but four (or whatever) to unindent.
>>>
>>> No, just about every editor that I've ever used has SHIFT-TAB set to
>>> undo whatever TAB does.
>>
>> Not to mention plenty of editors (e.g. vim) will unindent when you
>> press backspace.
> 
> I don't think that's strictly true. If you have just indented with a tab
> character, then backspace will delete that tab character. But, if you
> indent with either 4 spaces or use the Tab key with "expandtab" enabled,
> then it will just delete the right-most space character.
> 
> The closest I've come to an "unindent" in vim so far is Ctrl-D, which
> backs up one "shift width's" worth.
> 
> 
> For sanity, in 'vim', I always use (for my own Python code, at least):
> 
> :set sw=4 ts=4 expandtabs
> 
> That way, all tab keypresses insert 4 spaces instead of a tab and the
> shift operations ('<' and '>') will do the same. This also means the
> "back up one shift-width" command (Ctrl-D) is the same as a "dedent".
> 
> 
> If you also use the autoindent setting (:set ai), then writing code is
> as easy as pressing enter and Tab to start a new suite, enter only to
> continue a suite, and enter and Ctrl-D to drop back to the outer suite.
> 
> E.

I have just tested this with geany & it works a charm,

personally I prefer tabs for setting my indent levels, it feels more 
logical & breaks nothing if the font or tab size is changed but votes 
have been counted & the jury has returned a verdict

Spaces are the preferred option, but you are still able to make your own 
choice.




-- 
It's a very *__UN*lucky week in which to be took dead.
-- Churchy La Femme
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Joel Goldstick]

On Mon, Mar 20, 2017 at 1:39 PM, Steve D'Aprano
 wrote:
> On Tue, 21 Mar 2017 02:40 am, Tobiah wrote:
>
>>> I wonder whether the tabs versus spaces divide is closely aligned to the
>>> Windows versus Unix/Linux divide?
>>>
>>> It seems to me that Unix users are typically going to be using Unix tools
>>> which often assume spaces are used for indentation, and consequently cope
>>> badly with tabs.
>>
>> I can't think of any classic Unix tool that behaves in a way that would
>> support this point of view.
>
> And yet I'm forever being told by my Linux sys admin work mates "don't use
> tabs, because they break everything". For another example, see JMZ's essay
> (its already been linked to twice in this thread, look it up).
>
> We've had a similar attitude right here from Marko, who insists that
> anything except 8-column tabs is the Devil's Work. (Or something like
> that -- to be perfectly honest, I'm not really sure I understand *what*
> Marko's objection is.)
>
> So okay, if tabs work fine with Unix tools, why do so many Unix people avoid
> tabs as if they were radioactive plague?
>
>
>
>
> --
> Steve
> “Cheer up,” they said, “things could be worse.” So I cheered up, and sure
> enough, things got worse.
>
> --
> https://mail.python.org/mailman/listinfo/python-list

I was the first to post that this topic would go nowhere.  77 posts
later, for some reason the word 'spaceist' bothers me.  Why do people
debate spaces versus tabs?  I don't think it has to do with spaces or
tabs, but something more sociological or psychological.

-- 
Joel Goldstick
http://joelgoldstick.com/blog
http://cc-baseballstats.info/stats/birthdays
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Steve D'Aprano]

On Tue, 21 Mar 2017 02:40 am, Tobiah wrote:

>> I wonder whether the tabs versus spaces divide is closely aligned to the
>> Windows versus Unix/Linux divide?
>> 
>> It seems to me that Unix users are typically going to be using Unix tools
>> which often assume spaces are used for indentation, and consequently cope
>> badly with tabs.
> 
> I can't think of any classic Unix tool that behaves in a way that would
> support this point of view.

And yet I'm forever being told by my Linux sys admin work mates "don't use
tabs, because they break everything". For another example, see JMZ's essay
(its already been linked to twice in this thread, look it up).

We've had a similar attitude right here from Marko, who insists that
anything except 8-column tabs is the Devil's Work. (Or something like
that -- to be perfectly honest, I'm not really sure I understand *what*
Marko's objection is.)

So okay, if tabs work fine with Unix tools, why do so many Unix people avoid
tabs as if they were radioactive plague?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[jladasky]

On Sunday, March 19, 2017 at 1:11:45 PM UTC-7, Mikhail V wrote:

> Trying to line up things after a non-whitespace character, e.g. like this?
> 
> myList = [
> ["a", "b", "c"],
> ["mess up your alignment", "b", "c"],
> ["a", "b", "c"]
> ]
> 
> Well there is no easy solution possible, especially if you want it
> to look exactly the same on all computers and editors.
> Before something like elastic tabstops will be a standard,
> it will continue to confuse people.
> Spaces are still one of the worst solutions, although it will
> give same results on monospaced editors. 

This is a good example of exactly WHY I continue to write code using monospaced 
fonts, and spaces for indentation.  The results are unambiguous.  If I want 
vertical alignment between specific characters in different rows, I can have 
it.  I am not only interested in the indentation of the first character in a 
line of code.  Yes, sometimes I have to adjust the spacing manually, but I can 
live with that.

Now, my word-processing documents make full use of styles, and in that context 
I've transcended tabs completely.  For casual documents I might find myself 
falling back into the email-like habit of pushing "Enter" twice between 
paragraphs.  But when it's time to get serious, I define an appropriate 
paragraph style.

I have read about elastic tabstops.  If they become a standard and address my 
needs (it looks like they should), I will be happy to switch.

If you want to make your head spin, investigate how to represent polyphonic 
musical notation in a data structure that ensures it will be drawn accurately 
on staff paper, as well as played correctly by a synthesizer.  Code is child's 
play by comparison.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Random832]

On Sun, Mar 19, 2017, at 18:48, Mikhail V wrote:
> Sadly, many people believe that a code editor
> should be monospaced, but generally that does not
> have any sense.

It's also a bit self-reinforcing because there aren't many good coding
fonts that are proportional. And in fact there are issues for coding
usability in proportional fonts that aren't even present for monospaced
fonts. Confusables like lI1| O0 are only the beginning of the story. If
, and ' are only one pixel wide each, it's hard to tell which order they
are in. And in many proportional fonts it is difficult or impossible to
distinguish '' from ". Other issues also exist, such as """ having more
space between the ticks of a single character than between characters,
looking more like '""'. @ and % and sometimes # are too wide and too
short. Minus is too narrow, too thick, and too low owing to its design
as a hyphen (U+2212 is usually nicer, but not used in programming
languages). < and > are wide and low, which works great as relational
operators but makes them visually unpleasant as brackets - and >=
doesn't look nice either. {} are often too tall, too narrow, and a
little bit too curly.

So people try coding in the proportional fonts available on their
systems and rightly note how ugly it is.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Tobiah]

> I wonder whether the tabs versus spaces divide is closely aligned to the
> Windows versus Unix/Linux divide?
> 
> It seems to me that Unix users are typically going to be using Unix tools
> which often assume spaces are used for indentation, and consequently cope
> badly with tabs. 

I can't think of any classic Unix tool that behaves in a way that would support 
this
point of view.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 2:19 AM, BartC  wrote:
> But tabs are also used after statements, before comments for example, or to
> line up elements in tables. Then it doesn't work, because tabs may represent
> 1 to N spaces:
>
> Using N=4, with 1 tab before each number:
>
> (one,   1), #comment 1
> (two,   2), #comment 2
> (three, 3), #comment 3
>
> Displayed using N=3:
>
>(one, 1), #comment 1
>(two, 2), #comment 2
>(three,  3), #comment 3
>
> Displayed using N=6:
>
>(one, 1),   #comment 1
>(two, 2),   #comment 2
>(three, 3),   #comment 3
>
> Even tabs at the start of a line are sometimes using to line things up with
> a previous line; here with N=4, and 5 tabs before B and C:
>
>  longfunctionname (  A,  #comment 1
>  B,  #comment 2
>  C)  #comment 3
>
> With N=2:
>
> longfunctionname (  A,  #comment 1
>   B,  #comment 2
>   C)  #comment 3
>
> With N=8:
>
> longfunctionname (  A,  #comment 1
> B,  #comment 2
> C)  #comment 3

My points here are the same as for the other examples:

1) Preferably, don't do it at all.
2) If you absolutely have to do it, then by definition you're counting
character slots, so use spaces, not tabs.

Note that PEP 8 specifically forbids one of these kinds of usages:

"""
More than one space around an assignment (or other) operator to align
it with another.

Yes:

x = 1
y = 2
long_variable = 3

No:

x = 1
y = 2
long_variable = 3
"""

The reasoning behind this also applies to most of the other forms:
you're fiddling with formatting in ways that have to be forever
fiddled with as you make edits.

Here's a suggestion: Use a single tab after a statement and before the
hash. Exactly one tab. Then configure your editor to right-align that.
If someone else's editor doesn't right-align, no big deal, and you'll
get some measure of alignment anyway (eg if tabs are every eight
spaces, it rounds the alignment off to the next eight-mark); it won't
hurt anything, as those of us who don't care about the alignment won't
be bothered anyway.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[BartC]

On 20/03/2017 14:32, Chris Angelico wrote:

On Tue, Mar 21, 2017 at 1:24 AM, BartC  wrote:

But it would be better IMO if tabs were used, with some scheme for
suggesting the tab width (or set of tab stops) that is recommended (eg. a
comment at the top).


If you absolutely have to, then sure, put a directive in some
machine-readable way at the top or bottom of the file. It's like the
coding cookie that Python follows - some editors also respect it. But
I would prefer to just use tabs *without* suggesting a width, because
each one represents *one indent*. Not a number of spaces. One
indentation level.


For leading tabs at the start of a new statement that wouldn't be a 
problem. Changing the tab width shown just spreads out statements more, 
or less, horizontally.


It works - there is no jarring misalignment - because each tab 
corresponds to the same N spaces, whatever N happens to be.


But tabs are also used after statements, before comments for example, or 
to line up elements in tables. Then it doesn't work, because tabs may 
represent 1 to N spaces:


Using N=4, with 1 tab before each number:

(one,   1), #comment 1
(two,   2), #comment 2
(three, 3), #comment 3

Displayed using N=3:

   (one, 1), #comment 1
   (two, 2), #comment 2
   (three,  3), #comment 3

Displayed using N=6:

   (one, 1),   #comment 1
   (two, 2),   #comment 2
   (three, 3),   #comment 3

Even tabs at the start of a line are sometimes using to line things up 
with a previous line; here with N=4, and 5 tabs before B and C:


 longfunctionname (  A,  #comment 1
 B,  #comment 2
 C)  #comment 3

With N=2:

longfunctionname (  A,  #comment 1
  B,  #comment 2
  C)  #comment 3

With N=8:

longfunctionname (  A,  #comment 1
B,  #comment 2
C)  #comment 3


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 1:24 AM, BartC  wrote:
> But it would be better IMO if tabs were used, with some scheme for
> suggesting the tab width (or set of tab stops) that is recommended (eg. a
> comment at the top).

If you absolutely have to, then sure, put a directive in some
machine-readable way at the top or bottom of the file. It's like the
coding cookie that Python follows - some editors also respect it. But
I would prefer to just use tabs *without* suggesting a width, because
each one represents *one indent*. Not a number of spaces. One
indentation level.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[BartC]

On 20/03/2017 08:15, Chris Angelico wrote:

On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa  wrote:



The tools I mentioned honor the traditional tab stop columns:

1, 9, 17, 25, 33, 41, 49, 57, 65, 73



That means that you were depending, in your source file, on something
that isn't actually part of the character's definition. You're
depending on "horizontal tab" meaning those exact tab stops. If you
want those semantics, you should use spaces


There are effectively two versions of the text: the slightly higher 
level, or 'marked up' version containing these special controls, and the 
'rendered' version you see displayed on the screen.


You're suggesting doing away with the controls, working only with the 
rendered snapshot version. Which means instead of pressing Backspace 
once to delete a tab, you might need to press it 8 times, or 1 to 8 
times if not at the start.


This is little different to inserting hard newlines at the end of each 
visible line of a paragraph, to ensure that it is shown how you want it 
and isn't 'reflowed' depending on the width of someone's display.


Which work great - until you have to edit the text with those newlines 
present, which can be a lot of work.


So really you want to keep and work with the original version, not the 
rendered one.


In the case of tabs, it might be possible to take the rendered text (I 
call it 'flat' text because the tabs have been flattened out) and 
reconstruct the tabs, but there are some problems (are those 8 spaces 
one tab, or two or four, or were they just 8 spaces?).


It might be a little easier if the text represented, say, Python source 
code.


But it would be better IMO if tabs were used, with some scheme for 
suggesting the tab width (or set of tab stops) that is recommended (eg. 
a comment at the top).


--
bartc
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Steve D'Aprano]

On Tue, 21 Mar 2017 12:30 am, Marko Rauhamaa wrote:

> Unicode was 25 years late to the game

I don't understand that comment. Are you suggesting that the oldest
convention wins? The Unix 8-column convention is older than Unicode, so it
wins?

Well... in that case, there are tab conventions that pre-date Unix, e.g.
those used by COBOL. The tabs command offers them as pre-defined standards.
From the man page:

   -c 1,8,12,16,20,55
  COBOL, normal format.

But wait... before there was COBOL, there were *typewriters*. Its been many
years since I've had my hands on a manual typewriter, but if I remember
correctly the standard default tab setting was 1 inch.

So there you go. Unix was 50+ years late to the game.




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Tue, Mar 21, 2017 at 12:30 AM, Marko Rauhamaa  wrote:
>> And in the Unicode specifications,
>
> Unicode was 25 years late to the game, but please point me to the
> paragraph anyway.

3.3, D3 Character semantics: The semantics of a character are
determined by its identity, normative properties, and behavior.

That's the best I can find for you. The best statement that says "hey
you idiot, a character's name indicates the intended semantics of that
character". If U+0009's name were "SHORTER ENCODED FORM FOR SEQUENCE
OF SPACES", then I might be prepared to believe you. But it isn't.
It's "CHARACTER TABULATION". Does the specification really need to say
"don't be a fool"?

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Mar 20, 2017 at 8:56 PM, Marko Rauhamaa  wrote:
>> I bet some terminal emulators support ANSI escape sequences to set
>> the tab stops to arbitrary columns, but nobody uses that
>> type-writer-era mechanism.
>
> Probably not. Most people would use the tabs(1) command instead.

>From "man tabs":

   Use "-8" to set tabs to the standard interval.

I'd argue most people never touch the standard interval.

>>> The different kinds of whitespace have different semantic meanings,
>>
>> Only in your head (and Makefiles).
>
> And in the Unicode specifications,

Unicode was 25 years late to the game, but please point me to the
paragraph anyway.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 8:56 PM, Marko Rauhamaa  wrote:
> All terminal emulators, editors, text utils etc honor the
> convention out of the box. No wonder then that C source code files have
> consecutive lines indented randomly:
>
>HT
>SPC HT
>SPC SPC SPC SPC HT
>
> etc. The tools show no visible difference between those variants, so you
> can't blame the developers for being inconsistent.

Actually you can, for the same reason that you expect programmers to
use ASCII Latin to write language keywords, not other symbols that
happen to look identical.

>> If you want those semantics, you should use spaces -
>
> That is precisely what we have done: HT is banished (except in
> Makefiles, but we have banished Makefiles as well...).
>
>> or better still, *change your needs* and don't align things like that.
>> In far too many fonts, this simply won't work.
>
> You must use fixed-width fonts even in the absense of HT's.
> [chomp examples]

Yes, there are good reasons for using monospaced fonts for certain
types of documents. But if those documents have been created
correctly, they won't be mixing tabs and spaces to achieve that
alignment - they'll be using spaces exclusively.

>>> The presence of a HT code point in a plain text file is not a
>>> semantic marker for indentation. It is a silly, traditional
>>> compression scheme for whitespace.
>>
>> Only if you truly expect and assume that. Can you show me a standards
>> document that says "the meaning of this byte/character value is this
>> sequence of this other byte/character"?
>
> I already mentioned three examples: lpr, cat on a terminal and Firefox.
> Ultimately, it's the terminals that dictate the de-facto standard.

Do they actually document that its meaning is strictly as you
describe? On all of my terminals, a tab is *NOT* the same thing as X
spaces - for example, highlighting with the mouse will grab the entire
tab as a single character, and will copy it to the clipboard as a
character. Also, check out 'man tabs'. It's trivially easy to tell the
terminal to use a different set of tab stops, and catting a file will
look different. Notice that I didn't say "reconfigure cat". It's not
cat that does this - it's only the terminal, and I suspect that every
modern terminal on every POSIX system supports it (since the 'tabs'
command is itself part of POSIX). What 'lpr' does with tabs I don't
know, because paper is an archaic data transmission format that I use
only when absolutely necessary (such as when sending information off
to the gummint). Firefox... what's the betting that it can be
configured too, maybe with CSS?

> I bet some terminal emulators support ANSI escape sequences to set the
> tab stops to arbitrary columns, but nobody uses that type-writer-era
> mechanism.

Probably not. Most people would use the tabs(1) command instead.

>>> If you ever had to review C source code pull requests where tabs and
>>> spaces alternate randomly...
>>
>> Yes, and if you've ever had to review source code pull requests where
>> the letters "q" and "e" were used interchangeably, you'd also be
>> appalled.
>
> Huh? I'm talking about a real issue. I'm surprised you haven't run into
> it.

Maybe I have, and just rejected the PR out of hand. It certainly isn't
something that I am forced to wrestle with. Every PR that I have
accepted has been internally consistent (either all tabs or all
spaces).

>> The different kinds of whitespace have different semantic meanings,
>
> Only in your head (and Makefiles).

And in the Unicode specifications, and in a lot of other people's
heads. But you're welcome to reject all that too.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa  wrote:
>> The tools I mentioned honor the traditional tab stop columns:
>>
>> 1, 9, 17, 25, 33, 41, 49, 57, 65, 73
>
> (Point of clarity: "whitespace" is a general term that covers U+0020
> SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, U+2008
> PUNCTUATION SPACE, and others. You're talking about mixing *spaces*
> and tabs.)
>
> That means that you were depending, in your source file, on something
> that isn't actually part of the character's definition.

Those tab stops are a 40-year-old de-facto UNIX standard.

> You're depending on "horizontal tab" meaning those exact tab stops.

Not me. All terminal emulators, editors, text utils etc honor the
convention out of the box. No wonder then that C source code files have
consecutive lines indented randomly:

   HT
   SPC HT
   SPC SPC SPC SPC HT

etc. The tools show no visible difference between those variants, so you
can't blame the developers for being inconsistent.

> If you want those semantics, you should use spaces -

That is precisely what we have done: HT is banished (except in
Makefiles, but we have banished Makefiles as well...).

> or better still, *change your needs* and don't align things like that.
> In far too many fonts, this simply won't work.

You must use fixed-width fonts even in the absense of HT's. Try RFC 793,
for example:

   TCP Header Format

0   1   2   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Source Port  |   Destination Port|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Sequence Number|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Acknowledgment Number  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Data |   |U|A|P|R|S|F|   |
   | Offset| Reserved  |R|C|S|S|Y|I|Window |
   |   |   |G|K|H|T|N|N|   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Checksum| Urgent Pointer|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Options|Padding|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | data  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Those kinds of ASCII graphics diagrams are commonplace in source code
comments.

> (It was only from context that I figured out that that's what you were
> even aiming for. It didn't work in my email.)

When participating in technical discussions, I strongly recommend using
a fixed-width font. For example:

   =  =  ===
 A  BA and B
   =  =  ===
   False  False  False
   True   False  False
   False  True   False
   True   True   True
   =  =  ===

   https://www.python.org/dev/peps/pep-0012/>

>> The presence of a HT code point in a plain text file is not a
>> semantic marker for indentation. It is a silly, traditional
>> compression scheme for whitespace.
>
> Only if you truly expect and assume that. Can you show me a standards
> document that says "the meaning of this byte/character value is this
> sequence of this other byte/character"?

I already mentioned three examples: lpr, cat on a terminal and Firefox.
Ultimately, it's the terminals that dictate the de-facto standard.

I bet some terminal emulators support ANSI escape sequences to set the
tab stops to arbitrary columns, but nobody uses that type-writer-era
mechanism.

>> If you ever had to review C source code pull requests where tabs and
>> spaces alternate randomly...
>
> Yes, and if you've ever had to review source code pull requests where
> the letters "q" and "e" were used interchangeably, you'd also be
> appalled.

Huh? I'm talking about a real issue. I'm surprised you haven't run into
it.

> The different kinds of whitespace have different semantic meanings,

Only in your head (and Makefiles).


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 6:37 PM, Marko Rauhamaa  wrote:
>> I don't use paper, but I tried cat and Firefox. In each case, the tab
>> characters showed precisely as they should: as indentation. Was it the
>> exact same amount of indentation that showed when I originally wrote
>> the text in my editor? Was it displayed in the same font as my text
>> editor uses? Was the window the same size as that of my text editor?
>> Was the text colour the same everywhere? And do any of these questions
>> even matter?
>
> Those questions do matter when you mix whitespace and tabs, as well as
> in cases like these:
>
> call_some_function(1,
>2,
>3)
>
> The tools I mentioned honor the traditional tab stop columns:
>
> 1, 9, 17, 25, 33, 41, 49, 57, 65, 73

(Point of clarity: "whitespace" is a general term that covers U+0020
SPACE, U+0009 CHARACTER TABULATION, U+000A LINE FEED, U+2008
PUNCTUATION SPACE, and others. You're talking about mixing *spaces*
and tabs.)

That means that you were depending, in your source file, on something
that isn't actually part of the character's definition. You're
depending on "horizontal tab" meaning those exact tab stops. If you
want those semantics, you should use spaces - or better still, *change
your needs* and don't align things like that. In far too many fonts,
this simply won't work. (It was only from context that I figured out
that that's what you were even aiming for. It didn't work in my
email.)

>> Semantically, indentation is indentation.
>
> The presence of a HT code point in a plain text file is not a semantic
> marker for indentation. It is a silly, traditional compression scheme
> for whitespace.

Only if you truly expect and assume that. Can you show me a standards
document that says "the meaning of this byte/character value is this
sequence of this other byte/character"?

>> I prefer to use tabs in my code precisely *because* they are not
>> defined in a concrete way.
>
> If you ever had to review C source code pull requests where tabs and
> spaces alternate randomly...

Yes, and if you've ever had to review source code pull requests where
the letters "q" and "e" were used interchangeably, you'd also be
appalled. The different kinds of whitespace have different semantic
meanings, and while I'm sympathetic to the desire to stick to ASCII
where possible (resulting in a pair of newlines often being used to
represent a paragraph, where semantically U+2029 PARAGRAPH SEPARATOR
would be more appropriate), I believe that the meanings of different
characters should be respected. You wouldn't separate words in a
sentence with form-feeds; nor should you mix tabulation and space
characters to create indentation.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Chris Angelico :

> On Mon, Mar 20, 2017 at 6:01 PM, Marko Rauhamaa  wrote:
>> Pretty much. Try printing out your program with lpr, or sending it to
>> the terminal with cat, or opening it with with Firefox.
>
> I don't use paper, but I tried cat and Firefox. In each case, the tab
> characters showed precisely as they should: as indentation. Was it the
> exact same amount of indentation that showed when I originally wrote
> the text in my editor? Was it displayed in the same font as my text
> editor uses? Was the window the same size as that of my text editor?
> Was the text colour the same everywhere? And do any of these questions
> even matter?

Those questions do matter when you mix whitespace and tabs, as well as
in cases like these:

call_some_function(1,
   2,
   3)

The tools I mentioned honor the traditional tab stop columns:

1, 9, 17, 25, 33, 41, 49, 57, 65, 73

> Semantically, indentation is indentation.

The presence of a HT code point in a plain text file is not a semantic
marker for indentation. It is a silly, traditional compression scheme
for whitespace.

> I prefer to use tabs in my code precisely *because* they are not
> defined in a concrete way.

If you ever had to review C source code pull requests where tabs and
spaces alternate randomly...


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 6:01 PM, Marko Rauhamaa  wrote:
> Steve D'Aprano :
>
>> On Mon, 20 Mar 2017 09:50 am, Marko Rauhamaa wrote:
>>
>>> the 8-column interpretation is the only defensible use for
>>> tabs.
>>
>>
>> Oh, that's a law of physics is it?
>
> Pretty much. Try printing out your program with lpr, or sending it to
> the terminal with cat, or opening it with with Firefox.

I don't use paper, but I tried cat and Firefox. In each case, the tab
characters showed precisely as they should: as indentation. Was it the
exact same amount of indentation that showed when I originally wrote
the text in my editor? Was it displayed in the same font as my text
editor uses? Was the window the same size as that of my text editor?
Was the text colour the same everywhere? And do any of these questions
even matter?

Semantically, indentation is indentation. Obviously there are
ridiculous extremes (a tab character probably shouldn't indent by just
one pixel, nor should it normally indent by the entire width of a
line), but even those should be under the control of the viewer, not
the author. I prefer to use tabs in my code precisely *because* they
are not defined in a concrete way. The only thing I demand of the
display is that a sequence of N tabs be narrower than a sequence of
N+1 tabs.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Steve D'Aprano :

> On Mon, 20 Mar 2017 09:50 am, Marko Rauhamaa wrote:
>
>> the 8-column interpretation is the only defensible use for
>> tabs.
>
>
> Oh, that's a law of physics is it?

Pretty much. Try printing out your program with lpr, or sending it to
the terminal with cat, or opening it with with Firefox.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Erik]

On 19/03/17 23:23, Jon Ribbens wrote:

On 2017-03-19, Erik  wrote:

On 19/03/17 22:29, Jon Ribbens wrote:

Not to mention plenty of editors (e.g. vim) will unindent when you
press backspace.


I don't think that's strictly true. If you have just indented with a tab
character, then backspace will delete that tab character. But, if you
indent with either 4 spaces or use the Tab key with "expandtab" enabled,
then it will just delete the right-most space character.


The option you want is "smarttab", then it will behave as I describe.


You're quite right (as was I because you didn't mention it wasn't 
out-of-the-box functionality ;)).


I may well add that setting to my .vimrc, but FWIW, the Ctrl-D thing 
harks back to the original "vi" which I grew up on, so although I may 
add that setting, my muscle memory will probably still have me pressing 
Ctrl-D forever ;)



(Or install the "vim-sensible" settings, which I highly recommend.)


I have no interest in making my settings "sensible", thank you very much :D

Thanks though - it's always nice to learn another way to hone things 
just as one likes them ...


E.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 11:42 AM, Steve D'Aprano
 wrote:
> Or perhaps "just that one guy": here is JMZ, who says it is "impossible" to
> do anything with a text file unless you know what a TAB character
> represents:
>
> I just care that two people editing the same file use the same
> interpretations, and that it's possible to look at a file and
> know what interpretation of the TAB character was used, because
> otherwise it's just impossible to read.
>
> https://www.jwz.org/doc/tabs-vs-spaces.html
>
>
> Jamie Zawinski is a clever man, but I've read that document probably a dozen
> times over the years, and I still don't understand it. If I indent
> something using tab characters:
>
> indent 1
> indent 2
> indent 1 again
>
> why does JMZ need to know how many columns *I* choose to use to display
> this?

It's the same problem that you get when you put byte value 97 into a
file and it's impossible to know whether you meant for it to be
displayed in Courier or Times Roman. When you care about that level of
detail, *you're doing it wrong*. Text files are not intended to convey
exact pixel arrangements - they're for carrying linguistic
information.

In a text file, horizontal tab means "move horizontally". It doesn't
mean "move eight times the width of one standard character" (which is
less standard than a standard drink), and it doesn't mean "move 30mm",
and it certainly doesn't mean "move into debate mode against people
who use spaces".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Steve D'Aprano]

On Mon, 20 Mar 2017 06:00 am, Chris Angelico wrote:

> On Mon, Mar 20, 2017 at 4:29 AM, Steve D'Aprano
>  wrote:
>> I wonder whether the tabs versus spaces divide is closely aligned to the
>> Windows versus Unix/Linux divide?
>>
>> It seems to me that Unix users are typically going to be using Unix tools
>> which often assume spaces are used for indentation, and consequently cope
>> badly with tabs. I maintain that makes them "broken" tools, but broken or
>> not, that's the status quo and Unix users will simply deal with it by
>> using spaces for indents.
> 
> Nope. I'm on Linux and I love my tabs. They play fine with grep, diff,
> etc. None of my tools has a problem with them.

Hence my comment:

"I'm not even sure that it is true that tabs will break the Unix toolset.
But Unix users mostly believe it is true."

Perhaps I should have specified, *many* Unix users believe. Or "some" Unix
users. Or "the guys I work with".

Or perhaps "just that one guy": here is JMZ, who says it is "impossible" to
do anything with a text file unless you know what a TAB character
represents:

I just care that two people editing the same file use the same
interpretations, and that it's possible to look at a file and 
know what interpretation of the TAB character was used, because
otherwise it's just impossible to read. 

https://www.jwz.org/doc/tabs-vs-spaces.html


Jamie Zawinski is a clever man, but I've read that document probably a dozen
times over the years, and I still don't understand it. If I indent
something using tab characters:

indent 1
indent 2
indent 1 again

why does JMZ need to know how many columns *I* choose to use to display
this? I could use 4 columns per tab, or 64, and not only is the source text
identical but the interpretation in terms of *indent levels* is the same.
And that's the only interpretation that really matters: whether something
is indented once, or twice, not the physical number of columns that takes
up on *my* screen.

JMZ's "solution" is to ban TAB characters from source files. I don't
understand why he thinks that solves *anything*. If anything, it makes it
worse: for example, in the above quoted paragraph, I deliberately indented
the quote by *two* indents, not one, but using a spaces. How can JMZ
distinguish between "one 8-column indent" and "two 4-column indent" when
spaces are used instead of tabs? I don't think you can. I think he is
working on the unstated assumption that indentation will never increase by
more than one level. If so, then he can easily read:

indented text
more indented text

as a single 8-column indent. And he'll usually be right, until he keeps
reading and find:

still more indented text
outdented by half a level text?


I find myself using spaces because it is the path of least resistance, and
the tools I use make it tolerable. But for the life of me I still cannot
understand the *logical argument* against tabs.





-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 10:55 AM, Steve D'Aprano
 wrote:
> Oh, that's a law of physics is it? "8 columns per tab" is one of the
> fundamental mathematical or physical constants baked into the nature of
> reality, like
>
> π ≈ 3.14159...
> e ≈ 2.71828...
> Feigenbaum constant δ ≈ 4.66920...
> gravitational constant G ≈ 6.673e-11 N m**2 kg**-2
> fine structure constant α ≈ 7.297351e-3
>
> etc. And here I was, in my ignorance, thinking that it was a mere
> convention, something that could trivially be made a config option for
> those tools which actually needed it:
>
>   --tabwidth=4
>
> But I guess that's just as silly as redefining π as 3 exactly.

Yes. Actually, all of those constants are themselves defined in terms
of the width of a tab; if you change a tab to be seven spaces, e would
become 2.3785. That's just how the world works.

Actually, when I first met tabs, they were defined in centimeters.
Aside from the fact that they really should have been defined in
millimeters, I fully support that broad concept. (And they weren't
defined as "every 2.5 cm" necessarily; the default was for them to
repeat, but if you wanted, you could have them at 2.5, then 5.0, then
6.0, then 9.0, etc, etc, etc.)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Steve D'Aprano]

On Mon, 20 Mar 2017 09:50 am, Marko Rauhamaa wrote:

> the 8-column interpretation is the only defensible use for
> tabs.


Oh, that's a law of physics is it? "8 columns per tab" is one of the
fundamental mathematical or physical constants baked into the nature of
reality, like

π ≈ 3.14159...
e ≈ 2.71828...
Feigenbaum constant δ ≈ 4.66920...
gravitational constant G ≈ 6.673e-11 N m**2 kg**-2
fine structure constant α ≈ 7.297351e-3

etc. And here I was, in my ignorance, thinking that it was a mere
convention, something that could trivially be made a config option for
those tools which actually needed it:

  --tabwidth=4

But I guess that's just as silly as redefining π as 3 exactly.



-- 
Steve
299792.458 km/s — not just a good idea, it’s the law!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Jon Ribbens]

On 2017-03-19, Erik  wrote:
> On 19/03/17 22:29, Jon Ribbens wrote:
>> Not to mention plenty of editors (e.g. vim) will unindent when you
>> press backspace.
>
> I don't think that's strictly true. If you have just indented with a tab 
> character, then backspace will delete that tab character. But, if you 
> indent with either 4 spaces or use the Tab key with "expandtab" enabled, 
> then it will just delete the right-most space character.

The option you want is "smarttab", then it will behave as I describe.
(Or install the "vim-sensible" settings, which I highly recommend.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Larry Hudson :
> A trivial point (and irrelevant)... The thing I find annoying about an
> editor set to expand tabs to spaces is that it takes one keypress to
> indent but four (or whatever) to unindent.

In emacs' Python mode, if I have entered:


env.SharedLibrary('custom', [ 'a.c',
▯


and press Tab, the cursor moves to the right position:


env.SharedLibrary('custom', [ 'a.c',
  ▯


Now, pressing Backspace once (or Tab once more), I get:


env.SharedLibrary('custom', [ 'a.c',
▯


After a second Backspace (or a third Tab):


env.SharedLibrary('custom', [ 'a.c',
▯


and so on, 4 columns at a time.

I have told emacs not to use HT characters.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Erik]

On 19/03/17 22:29, Jon Ribbens wrote:

On 2017-03-19, breamore...@gmail.com  wrote:

On Sunday, March 19, 2017 at 9:54:52 PM UTC, Larry Hudson wrote:

A trivial point (and irrelevant)...  The thing I find annoying
about an editor set to expand tabs to spaces is that it takes one
keypress to indent but four (or whatever) to unindent.


No, just about every editor that I've ever used has SHIFT-TAB set to
undo whatever TAB does.


Not to mention plenty of editors (e.g. vim) will unindent when you
press backspace.


I don't think that's strictly true. If you have just indented with a tab 
character, then backspace will delete that tab character. But, if you 
indent with either 4 spaces or use the Tab key with "expandtab" enabled, 
then it will just delete the right-most space character.


The closest I've come to an "unindent" in vim so far is Ctrl-D, which 
backs up one "shift width's" worth.



For sanity, in 'vim', I always use (for my own Python code, at least):

:set sw=4 ts=4 expandtabs

That way, all tab keypresses insert 4 spaces instead of a tab and the 
shift operations ('<' and '>') will do the same. This also means the 
"back up one shift-width" command (Ctrl-D) is the same as a "dedent".



If you also use the autoindent setting (:set ai), then writing code is 
as easy as pressing enter and Tab to start a new suite, enter only to 
continue a suite, and enter and Ctrl-D to drop back to the outer suite.


E.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 9:48 AM, Mikhail V  wrote:
> [regarding monospaced text]
> Or, for example collision detection, which is part
> of mouse text selection algorithm is much simpler, etc.
> These are IMO main reasons why it still often used.

I work extensively with MUDs, where traditionally ASCII text is
monospaced. It's normal to create alignment with spaces, and for tabs
to represent eight-space positions (so "abc\td" will take up nine
slots of width). But in the world of Unicode, it's not that simple.
Some text runs right-to-left, some characters have different widths
assigned, some have no width at all. My program has to cope with all
of these, including when you use the mouse to select text.

Monospacing is not about making it easier for the program; it's about
keeping things the way the human expects. I do not ever want my MUDs
or my shells to run with classic "proportionally-spaced" fonts, but I
do want them to be able to cope with RTL text etc. And they can.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Gregory Ewing :

> Steve D'Aprano wrote:
>> Unix tools which often assume spaces are used for indentation, and
>> consequently cope badly with tabs. I maintain that makes them
>> "broken" tools,
>
> They're not broken in the context of Unix, where there is a
> long-standing convention of assuming tab stops every 8 columns. From
> that point of view, tabs are not formatting instructions, but are just
> a way of compressing consecutive spaces. If tabs are used according to
> that convention, Unix tools cope with them just fine.

Correct, the 8-column interpretation is the only defensible use for
tabs. However, since that use is completely redundant, better not use
them at all.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 19 March 2017 at 22:54, Gregory Ewing  wrote:
> Mikhail V wrote:
>>
>> Monospaced text rendering is an artifact,
>> which exist on a very short time period in history.
>> At best, one should just imagine it should not exist, and is
>> just a temporary inconvinience. Actually it lasts already much
>> longer than I would expect.
>
>
> The fact that it *has* lasted so long might be telling us
> something. It has some advantages when machine processing
> text such as source code, where the semantic content is much
> more important than making it look pretty.
>
> --
> Greg


If we speak about information reading, e.g. text or Python code,
then I don't know of any helpful feature, except that characters
are vertically aligned. And the feature is helpful only in this
sense that I can align table columns with integer amount of spaces.
The readability is however very poor and cannot
be remedied with any tricks. Also if one *needs*
monospaced for some reason, then one can always
render units at equal distances, e.g. to compare
two encrypted strings visually, but those
are rare specific tasks.

Obviously there are some technical advantages, e.g.
the algorithms for tiled rendering
are much simpler and respectively hardware
can be much simpler / more performant.
(E.g. tabloid in airport)

Or, for example collision detection, which is part
of mouse text selection algorithm is much simpler, etc.
These are IMO main reasons why it still often used.

Sadly, many people believe that a code editor
should be monospaced, but generally that does not
have any sense.

Mikhail
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Jon Ribbens]

On 2017-03-19, breamore...@gmail.com  wrote:
> On Sunday, March 19, 2017 at 9:54:52 PM UTC, Larry Hudson wrote:
>> A trivial point (and irrelevant)...  The thing I find annoying
>> about an editor set to expand tabs to spaces is that it takes one
>> keypress to indent but four (or whatever) to unindent.
>
> No, just about every editor that I've ever used has SHIFT-TAB set to
> undo whatever TAB does.

Not to mention plenty of editors (e.g. vim) will unindent when you
press backspace.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Larry Hudson via Python-list]

On 03/18/2017 05:01 PM, Nathan Ernst wrote:
[...]

Personally, I dislike any editor that, by default, changes my input to
something else. If I hit tab, I want a tab to be inserted, by default. If I
want something else, I'll change the configuration.

A trivial point (and irrelevant)...  The thing I find annoying about an editor set to expand 
tabs to spaces is that it takes one keypress to indent but four (or whatever) to unindent.


--
 -=- Larry -=-
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Gregory Ewing]

Mikhail V wrote:

Monospaced text rendering is an artifact,
which exist on a very short time period in history.
At best, one should just imagine it should not exist, and is
just a temporary inconvinience. Actually it lasts already much
longer than I would expect.


The fact that it *has* lasted so long might be telling us
something. It has some advantages when machine processing
text such as source code, where the semantic content is much
more important than making it look pretty.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Gregory Ewing]

Steve D'Aprano wrote:

Unix tools
which often assume spaces are used for indentation, and consequently cope
badly with tabs. I maintain that makes them "broken" tools,


They're not broken in the context of Unix, where there is a
long-standing convention of assuming tab stops every 8 columns.
From that point of view, tabs are not formatting instructions,
but are just a way of compressing consecutive spaces.
If tabs are used according to that convention, Unix tools
cope with them just fine.


I'm not even sure that it is true that tabs will break the Unix toolset. But
Unix users mostly *believe* it is true.


Tabs used according to non-Unix conventions will break Unix
tools. But that doesn't mean the tools themselves are broken,
any more than the fact that putting diesel fuel in a petrol
car damages it means that petrol engines are broken.

Python is in the awkward position of being expected to run
on either petrol or diesel. It copes by requiring a
particularly refined form of fuel, i.e. not mixing tabs
and spaces.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 18 March 2017 at 22:50, Nathan Ernst  wrote:
> My issue with using spaces instead of tabs, is that, as mentioned earlier in
> the thread, everyone has their own preferences on indentation. I've worked
> on teams where different developers used 2, 3 & 4 spaces as indentation.
> Obviously, if you're using spaces, several of the members will be unhappy.
>
> Tabs have the benefit that most editors used by developers allow the
> adjustment of the width of a tab. If you use tabs, everyone can be happy
> with the visual presentation of their code.
>
> My rule of thumb: tabs for indentation, spaces for alignment (i.e. trying to
> line up anything after a non-whitespace character on a single line).
>
> Regards,
> Nathan
>

Trying to line up things after a non-whitespace character, e.g. like this?

myList = [
["a", "b", "c"],
["mess up your alignment", "b", "c"],
["a", "b", "c"]
]

Well there is no easy solution possible, especially if you want it
to look exactly the same on all computers and editors.
Before something like elastic tabstops will be a standard,
it will continue to confuse people.
Spaces are still one of the worst solutions, although it will
give same results on monospaced editors. Changing
a long string in above example means again ASCII art exercises,
and it is not funny.
I'd just leave it as is or use tabs, despite they
can look different on other editor.

Most importang thing, one should just stop thinking
'monospaced'. Monospaced text rendering is an artifact,
which exist on a very short time period in history.
At best, one should just imagine it should not exist, and is
just a temporary inconvinience. Actually it lasts already much
longer than I would expect.

So for column alignment technically correct IMO are single tabs
which are rendered depending on the context, i.e. this is
like elastic tabstobs work, IIUC.
On the other hand one should not edit spreadsheets
in a text editor. If one does a lot of work on tables,
then use appropriate softwre, e.g. Excell.

Mikhail

ine up anything after a non-whitespace character
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Mon, Mar 20, 2017 at 4:29 AM, Steve D'Aprano
 wrote:
> I wonder whether the tabs versus spaces divide is closely aligned to the
> Windows versus Unix/Linux divide?
>
> It seems to me that Unix users are typically going to be using Unix tools
> which often assume spaces are used for indentation, and consequently cope
> badly with tabs. I maintain that makes them "broken" tools, but broken or
> not, that's the status quo and Unix users will simply deal with it by using
> spaces for indents.

Nope. I'm on Linux and I love my tabs. They play fine with grep, diff,
etc. None of my tools has a problem with them.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Alain Ketterlin]

Jon Ribbens  writes:

> On 2017-03-18, Grant Edwards  wrote:
>> On 2017-03-18, Mikhail V  wrote:
>>> How would one come to the idea to use spaces for indentation at all?
>>
>> Because tabs are a major security vulnerability and should be outlawed
>> in all source code.
>
> You forgot to mention that tabs are carcinogenic, can be addictive,
> and hate our freedoms. If we use them, the terrorists win. Tabs can
> settle during transit, and may contain traces of nuts. Tabs should
> not be folded, spindled or mutilated. Tabs are vicious if wounded.
> Remember, kids: Just Say No to the Invisible Menace.

And US government officials call them "alternative spaces".
Enough said.

-- Alain.

P/S: just in case: https://www.jwz.org/doc/tabs-vs-spaces.html
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Steve D'Aprano]

On Mon, 20 Mar 2017 01:27 am, Grant Edwards wrote:

> On 2017-03-18, Nathan Ernst  wrote:
> 
>> As I said earlier, where tabs are superior in that most code focused
>> editors (at least those worth using) allow you to adjust the width of the
>> tab.
> 
> What about all other other text tools that _aren't_ 'code focused
> editors'?  (e.g. grep, less, cat, awk, sed, a2ps, asciidoc, etc.)

I wonder whether the tabs versus spaces divide is closely aligned to the
Windows versus Unix/Linux divide?

It seems to me that Unix users are typically going to be using Unix tools
which often assume spaces are used for indentation, and consequently cope
badly with tabs. I maintain that makes them "broken" tools, but broken or
not, that's the status quo and Unix users will simply deal with it by using
spaces for indents.

On the other hand, the typical Windows developer probably has little or no
access to grep, less, sed, etc, and consequently doesn't fear using tabs in
source code. Since nothing is going to touch it apart from either Notepad
or the IDE, there's no problem with using tabs.

Back when dinosaurs ruled the earth, and I had a Macintosh (classic OS, not
OS X) it was normal to use tabs for indents. Likewise when I had a Windows
machine. It was only when I moved to Linux that I had "tabs are bad,
m'kay?" beaten into me, with the main justification being "tabs will break
your tools".

I'm not even sure that it is true that tabs will break the Unix toolset. But
Unix users mostly *believe* it is true.



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tabs are a security vulnerabilty [was Re: Who are the "spacists"?]

[Mikhail V]

On 19 March 2017 at 01:32, Steve D'Aprano  wrote:
> On Sun, 19 Mar 2017 03:30 am, Grant Edwards wrote:
>
>> tabs are a major security vulnerability and should be outlawed
>> in all source code.
>
>
> I've heard many arguments both in favour of and against tabs, but I've never
> heard them described as a security vulnerability before. Let alone a major
> one.
>
> Got a citation or some more information?

Double that, I've googled and did not find anything.
Also it is not clear, since vulnerability can be only
for a particular executable that does something
with a file, not the file itslef.
I've heard some arguments aginst tabs also, but
it turned out that most of them are even not real.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 19 March 2017 at 02:05, Marko Rauhamaa  wrote:
> Chris Angelico :
>
>> On Sun, Mar 19, 2017 at 11:39 AM, Steve D'Aprano
>>  wrote:
>>> Is it also ridiculous to use several newlines to space paragraphs
>>> vertically?
>>
>> At least with paragraphs, we don't have eternal debates between people
>> who think they should have four newlines, three newlines, or oh
>> wait, there is debate between two and one
>
> Some people like fluffy source code:
>
> def f():
>
> "doc"
>
> # Code follows
>
> x = calculate_some()
>
> return x + 1
>

BTW, this was a good option, if one worked in
such text modes where lines are so close to
each other, that it was too hard to read anything.
So it would be not 'fluffy' but actually normal
spacing. Thankfully modern tools allow
configuring the line spacing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Grant Edwards]

On 2017-03-18, Nathan Ernst  wrote:

> As I said earlier, where tabs are superior in that most code focused
> editors (at least those worth using) allow you to adjust the width of the
> tab.

What about all other other text tools that _aren't_ 'code focused
editors'?  (e.g. grep, less, cat, awk, sed, a2ps, asciidoc, etc.)

> I'm not aware of a single editor that allows you to adjust the
> indentation of multiple spaces, let alone in the face of sources with mixed
> space indentations in the same codebase.

So the only thing that ever touches your code is that one editor?

-- 
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Grant Edwards]

On 2017-03-18, Chris Angelico  wrote:
> On Sun, Mar 19, 2017 at 8:50 AM, Nathan Ernst  wrote:
>> My rule of thumb: tabs for indentation, spaces for alignment (i.e. trying
>> to line up anything after a non-whitespace character on a single line).
>
> My rule of thumb: tabs for indentation, and don't align stuff after
> non-whitespace :)

Aligning columns in tables of data make it far easier to read/edit.

-- 
Grant



-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Pavol Lisy]

On 3/19/17, Pavol Lisy  wrote:
> On 3/18/17, Nathan Ernst  wrote:

> PS. I am "spacist" :P but I feel this a little more aggressive than is
> necessary too:
>
>> Feel free to start your own discussion forum for your new programming
>> language that forbids spaces for indentation. That language will never
>> be Python, so please don't ask us to discuss it here.
>
> I think there could be enough time to deprecate now and forbid tabs
> (or spaces) as indentation in python4.
>
> That doesn't mean I propose that! I only think that this transition
> could be technically possible so discussion is not necessary useless.

Sorry here I forgot to mention that citation above is from Ben
Finney's mail and not from Nathan's!

Anyway. I just made a simple and primitive analyze:

re.findall('^ '...) and re.findall('^\t'...) for more than 100k
py-files discoverable by find / -name "*.py" on my (ubuntu 16.04)
computer.

Anybody could see that it incorrectly finds lines in multiline strings
(and has maybe much more flaws) but it could be probably still
interesting.

there are:
127 837 files where at least one line starts with space
   2 273 files where at least one line starts with tab
   1 192 files where are lines which starts with space and lines which
starts with tab

and there are:
35 144 893 lines which starts with space
   428 160 lines which starts with tab

PL.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Sun, Mar 19, 2017 at 4:53 PM, Pavol Lisy  wrote:
> Everyone has their own preferences how to display tabs (2, 3, 4 spaces?).

Exactly, and they're welcome to them.

> How could alignment look in case of mixed tabs and spaces? Everybody
> will be happy?

Don't do that. Ever. In any language.

> In case of spaces there is not discrepancy. pep8 and similar linters
> could work fine without incompatible configurations.

I don't like the pep8 tool; its name implies far more authority than
it actually has. But if you look at the rules Python 3 applies, or
Python 2 with "-tt", you should easily be able to comply.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Pavol Lisy]

On 3/18/17, Nathan Ernst  wrote:
> My issue with using spaces instead of tabs, is that, as mentioned earlier
> in the thread, everyone has their own preferences on indentation. I've
> worked on teams where different developers used 2, 3 & 4 spaces as
> indentation. Obviously, if you're using spaces, several of the members will
> be unhappy.
>
> Tabs have the benefit that most editors used by developers allow the
> adjustment of the width of a tab. If you use tabs, everyone can be happy
> with the visual presentation of their code.
>
> My rule of thumb: tabs for indentation, spaces for alignment (i.e. trying
> to line up anything after a non-whitespace character on a single line).
>
> Regards,
> Nathan

Everyone has their own preferences how to display tabs (2, 3, 4 spaces?).

How could alignment look in case of mixed tabs and spaces? Everybody
will be happy?

In case of spaces there is not discrepancy. pep8 and similar linters
could work fine without incompatible configurations.

PL.

PS. I am "spacist" :P but I feel this a little more aggressive than is
necessary too:

> Feel free to start your own discussion forum for your new programming
> language that forbids spaces for indentation. That language will never
> be Python, so please don't ask us to discuss it here.

I think there could be enough time to deprecate now and forbid tabs
(or spaces) as indentation in python4.

That doesn't mean I propose that! I only think that this transition
could be technically possible so discussion is not necessary useless.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

> On 19 March 2017 at 01:39, Steve D'Aprano  wrote:
>> On Sun, 19 Mar 2017 08:24 am, Mikhail V wrote:
>>
>> I've noticed a tendency that more and more users
>> choose tabs.

>Have you really? I've noticed the opposite.

Not *really*, but on stackoverflow more and more
answers recommending tabs are upvoted. Few years ago
IIRC I noticed merely upvoted PEP citations.
Of my friends, I know those who use Sublime editor
on Macs, use tabs, probably spaces cause issues there, IDK.
Younger people today have more
and more previous experience with digital documents
and already familiar with the concept of tabulation.
Also after one tries to move the cursor around line
beginnings and try to delete or add indentation,
with spaces it is not so easy.
On the other hand I've noticed that spacists are
for some reason quite active in the web and at times even
agressive, writing that tabs are 'cancer' and so on.

>> Indeed if you think about it, using several spaces for
>> one level of indentation is ridiculous

>Is it?

Yes it is. In the times of DOS it felt totally ok
to indent e.g. 2 spaces, but those were text mode apps
on small resolution screens. Now one wants more than 2
spaces for sure, and for Python specifically, the intuitive
wish is to use one tab for one indentation level, since
one already knows that indentation is important and
despite spaces work, those are not control characters.
The point is that spaces are not supposed for indentation
regardless if it is code or MS Word document, at least
in the modern world.

This reminds me of Lexicon:
https://en.wikipedia.org/wiki/Lexicon_(program)
It is a DOS text-mode word processor, to make full line justify
it inserts additional spaces between words.
All those space alignments is more about ASCII art.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Chris Angelico :

> On Sun, Mar 19, 2017 at 11:39 AM, Steve D'Aprano
>  wrote:
>> Is it also ridiculous to use several newlines to space paragraphs
>> vertically?
>
> At least with paragraphs, we don't have eternal debates between people
> who think they should have four newlines, three newlines, or oh
> wait, there is debate between two and one

Some people like fluffy source code:

def f():

"doc"

# Code follows

x = calculate_some()

return x + 1

Me, I like it compact:

def f():
"doc"
# Code follows
x = calculate_some()
return x + 1

Not to worry! Just use VT characters to indicate vertical space and
configure your editor to display it with your favorite number of empty
pixels.

Thankfully, the use of VT characters in source code has experienced a
200% increase in recent years.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Sun, Mar 19, 2017 at 11:39 AM, Steve D'Aprano
 wrote:
>> Indeed if you think about it, using several spaces for
>> one level of indentation is ridiculous
>
> Is it?
>
> Is it also ridiculous to use several newlines to space paragraphs
> vertically?

At least with paragraphs, we don't have eternal debates between people
who think they should have four newlines, three newlines, or oh
wait, there is debate between two and one

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Nathan Ernst :

> emacs, like Vim is very configurable. I'm sure there's an appropriate
> setting.
>
> Because 1 editor does it one way, doesn't mean the rest of the
> numerous editors should follow suit.

Correct. There's no universal standard so we have to declare a local one.

I have defined:

(custom-set-variables
 '(indent-tabs-mode nil))

meaning: don't indent using ASCII HT characters.

> Personally, I dislike any editor that, by default, changes my input to
> something else. If I hit tab, I want a tab to be inserted, by default.
> If I want something else, I'll change the configuration.

Well, I have yet to find an editor that gives no interpretation to the
keys. For example, typing the "Esc" key in vi's insert mode will not
place an ESC character in the file. And even vi puts an LF in your file
if you should press the "Enter" key.

Of course, you are free to like or dislike any editor you want.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Steve D'Aprano]

On Sun, 19 Mar 2017 08:24 am, Mikhail V wrote:

> There can be some problems, say in one class a teacher says: never
> use tabs, in other class a teacher says: don't use spaces.
> Who is right?

Neither is right, both are wrong, and the students have just learned a
valuable lesson: authority figures can be mistaken, they can be ignorant,
and they can spread superstition.


> This is not a major problem, but technically seen using tabs
> is more logical way, but de-facto spaces are recommended.

Yes, I agree 100% with that.


> I've noticed a tendency that more and more users
> choose tabs. 

Have you really? I've noticed the opposite.


> Indeed if you think about it, using several spaces for 
> one level of indentation is ridiculous 

Is it?

Is it also ridiculous to use several newlines to space paragraphs
vertically?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Tabs are a security vulnerabilty [was Re: Who are the "spacists"?]

[Steve D'Aprano]

On Sun, 19 Mar 2017 03:30 am, Grant Edwards wrote:

> tabs are a major security vulnerability and should be outlawed
> in all source code.


I've heard many arguments both in favour of and against tabs, but I've never
heard them described as a security vulnerability before. Let alone a major
one.

Got a citation or some more information?



-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Nathan Ernst]

emacs, like Vim is very configurable. I'm sure there's an appropriate
setting.

Because 1 editor does it one way, doesn't mean the rest of the numerous
editors should follow suit.

Personally, I dislike any editor that, by default, changes my input to
something else. If I hit tab, I want a tab to be inserted, by default. If I
want something else, I'll change the configuration.

On Sat, Mar 18, 2017 at 6:38 PM, Marko Rauhamaa  wrote:

> Nathan Ernst :
>
> > Tabs rectify this issue as you can configure them to appear how you
> > like to see your code without affecting or impacting any other
> > contributors to a code base.
> >
> > Personally, I used to be a 4-spacer. Now, I prefer 2 spaces. Guess
> > what? When I changed my preference, zero lines of source were changed,
> > no commits were necessary, and I was happy.
>
> Your scheme is thrown into disarray by the default emacs setup, which
> defines C source code indendation levels as follows:
>
>Level 1: SPC SPC
>Level 2: SPC SPC SPC SPC
>Level 3: SPC SPC SPC SPC SPC SPC
>Level 4: HT
>Level 5: HT SPC SPC
>
> etc.
>
> (You see, in emacs pressing the Tab key is a command to indent the
> current line by the "appropriate amount;" it doesn't cause an HT to be
> inserted.)
>
> Point is, something's going to have to give, no matter what you do. You
> are going to have to issue a binding executive order that is not an
> automatic default for everybody.
>
> Where I work, the executive order is: no HT's in files, and use 4-space
> indentation.
>
>
> Marko
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Nathan Ernst :

> Tabs rectify this issue as you can configure them to appear how you
> like to see your code without affecting or impacting any other
> contributors to a code base.
>
> Personally, I used to be a 4-spacer. Now, I prefer 2 spaces. Guess
> what? When I changed my preference, zero lines of source were changed,
> no commits were necessary, and I was happy.

Your scheme is thrown into disarray by the default emacs setup, which
defines C source code indendation levels as follows:

   Level 1: SPC SPC
   Level 2: SPC SPC SPC SPC
   Level 3: SPC SPC SPC SPC SPC SPC
   Level 4: HT
   Level 5: HT SPC SPC

etc.

(You see, in emacs pressing the Tab key is a command to indent the
current line by the "appropriate amount;" it doesn't cause an HT to be
inserted.)

Point is, something's going to have to give, no matter what you do. You
are going to have to issue a binding executive order that is not an
automatic default for everybody.

Where I work, the executive order is: no HT's in files, and use 4-space
indentation.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Marko Rauhamaa]

Chris Angelico :
> My rule of thumb: tabs for indentation, and don't align stuff after
> non-whitespace :)

I always use the "Tab" key to indent, but I don't allow the file to
contain any ASCII HT characters. The only control character in my files
is the LF. The only exception would be plain text files that I paginate
using the FF before sending them to the printer.


Marko
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Nathan Ernst]

On Sat, Mar 18, 2017 at 4:44 PM, ROGER GRAYDON CHRISTMAN 
wrote:

> Just a couple minor notes from my experience:
>
> 1)
> Some of the course management software I use doesn't like me typing tab
> characters.
> When I want to post sample code into a course page using this software,
> tabs
> are either
> ignored or does something really broken (like post an incomplete file).
> So, I
> must necessarily
> type spaces when posting that code -- and of course, downloading that
> sample
> from the page
> has spaces in it instead of tabs.
>
> Point in favor of using spaces.
>

Then your course management software is broken, and should be fixed. This
is not a valid argument against tabs, although it may make it more
convenient to use spaces for you.


> 2)
> Tabs are one byte; spaces are one byte; so unless all of your indents are
> only
> one space at a time,
> a source file with tabs takes less memory than a source file with tabs.
> It's not a significant difference.
>
> Very minor point in favor of using tabs.
>
> I'm still a spacer myself.
>
>
> --
> https://mail.python.org/mailman/listinfo/python-list


The size of tab vs space is a novel argument, but generally specious. Yes,
it may matter in certain circumstances, but it's not generally valid (and I
say this with a tab preferrence).

As I said earlier, where tabs are superior in that most code focused
editors (at least those worth using) allow you to adjust the width of the
tab. I'm not aware of a single editor that allows you to adjust the
indentation of multiple spaces, let alone in the face of sources with mixed
space indentations in the same codebase. Again, I've seen 2, 3 and 4 spaced
identations. Really f***ing annoying to see that in a single codebase. It's
even worse when you get files edited by two different people with different
styles and their white space changes happen to work because the entire
block is within their preferred style. (yes, I've seen 3-spaced indents
mixed with 2-spaced idents and 4-spaced indents all within a single file!)
Tabs rectify this issue as you can configure them to appear how you like to
see your code without affecting or impacting any other contributors to a
code base.

Personally, I used to be a 4-spacer. Now, I prefer 2 spaces. Guess what?
When I changed my preference, zero lines of source were changed, no commits
were necessary, and I was happy.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 18 March 2017 at 21:19, Bob Gailer  wrote:
> On Mar 17, 2017 9:23 PM, "Mikhail V"  wrote:
>>
>> So Python supports both spaces and tabs for indentation.
>>
>> I just wonder, why not forbid spaces in the beginning of lines?
>> How would one come to the idea to use spaces for indentation at all?
>
> One problem for me with tabs: there is no standard visual representation (1
> tab = ? Spaces)

Hi Bob,
The rendering of each character, including tab character is up to the
renderer, i.e. editor or IDE. This means, if the editor supports
customisations, then you can define the width of the tabs.
With more advanced rendering, editor can 'know' if it is
a preceding (indent) tab or some other indentation, e.g.
multiline list definition (e.g. 'elastic tabs', but that is more
about future). In VIM I set the tab width = 4 spaces
and VIM is a monospaced-only editor.

>>
>> Space is not even a control/format character, but a word separator.
>
> Huh? The character sets I'm familiar with don't have "word separators".
> Space is just another no -control character.

Yes that is what I mean. So it is quite logical to use a tab, i.e. different
character than space for this specific case, 1 char for 1 level.

>
>> And when editors will be proportional font based
>
> Editors allow your choice of font. Some are proportional, some monospaced. I
> fail to see any benefit from making a proportional-only font based editor.

Well, if there will be a decent IDE/editor with realistic font
rendering and good tabs mangement, I will not ever
want to switch back to a monospaced font.
So put another way, there will be no need to use
a monospaced font.
And if one uses spaces to indent e.g. multiline list with proportional
font, then it is not possible to achieve exact alignment.
Anyway, why use space? space is space, a character for
specific usage.
Also if I increase the font size I don;t necesserily want to increase
the tab width.

I treat monospaced editors more as an anachronism,
I mean of course only the 'visual' component.
So VIM, despite its monospaced nature, is for me high
above all products I've tested so far, if speak about input, editing.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[ROGER GRAYDON CHRISTMAN]

Just a couple minor notes from my experience:

1) 
Some of the course management software I use doesn't like me typing tab
characters.
When I want to post sample code into a course page using this software, tabs
are either
ignored or does something really broken (like post an incomplete file).  So, I
must necessarily
type spaces when posting that code -- and of course, downloading that sample
from the page
has spaces in it instead of tabs.

Point in favor of using spaces.

2)
Tabs are one byte; spaces are one byte; so unless all of your indents are only
one space at a time,
a source file with tabs takes less memory than a source file with tabs.
It's not a significant difference.

Very minor point in favor of using tabs.

I'm still a spacer myself. 


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Sun, Mar 19, 2017 at 8:59 AM, Nathan Ernst  wrote:
> I don't generally align stuff, either, but if you're going to, use spaces.

The most interesting coder in the world.

https://imgflip.com/i/1lo0wl

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Nathan Ernst]

I don't generally align stuff, either, but if you're going to, use spaces.

On Sat, Mar 18, 2017 at 4:55 PM, Chris Angelico  wrote:

> On Sun, Mar 19, 2017 at 8:50 AM, Nathan Ernst 
> wrote:
> > My rule of thumb: tabs for indentation, spaces for alignment (i.e. trying
> > to line up anything after a non-whitespace character on a single line).
>
> My rule of thumb: tabs for indentation, and don't align stuff after
> non-whitespace :)
>
> ChrisA
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Chris Angelico]

On Sun, Mar 19, 2017 at 8:50 AM, Nathan Ernst  wrote:
> My rule of thumb: tabs for indentation, spaces for alignment (i.e. trying
> to line up anything after a non-whitespace character on a single line).

My rule of thumb: tabs for indentation, and don't align stuff after
non-whitespace :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Nathan Ernst]

My issue with using spaces instead of tabs, is that, as mentioned earlier
in the thread, everyone has their own preferences on indentation. I've
worked on teams where different developers used 2, 3 & 4 spaces as
indentation. Obviously, if you're using spaces, several of the members will
be unhappy.

Tabs have the benefit that most editors used by developers allow the
adjustment of the width of a tab. If you use tabs, everyone can be happy
with the visual presentation of their code.

My rule of thumb: tabs for indentation, spaces for alignment (i.e. trying
to line up anything after a non-whitespace character on a single line).

Regards,
Nathan

On Sat, Mar 18, 2017 at 4:24 PM, Mikhail V  wrote:

> On 18 March 2017 at 16:54, Lutz Horn  wrote:
> > Am 18.03.17 um 16:18 schrieb Mikhail V:
> >> On 18 March 2017 at 05:02, Ben Finney 
> >> wrote:
> >>> Mikhail V  writes:
> >>>
>  I think it would be a salvation to forbid spaces for indentation,
>  did such attemps take place?
> >>>
> >>> Feel free to start your own discussion forum for your new
> >>> programming language that forbids spaces for indentation. That
> >>> language will never be Python, so please don't ask us to discuss it
> >>> here.
> >
> >> So you are the opinion it would be more productive to invent a new
> >> language instead of just cleaning up spaces?
> >
> > Productive in solving what problem exactly? Why do you think a cleaning
> > of spaces is necessary?
>
> Ehm, why is it necessary? I won't mix them and I use tabs, so if I become a
> source with spaces and edit it, I must replace them, then if a spacist
> becomes
> tabulated code he replaces tabs with spaces again. Not a big
> deal, but seems strange.
>
> >
> >> I think it still helps to realize that in the future this will become
> >> more noticable problem than it seems now
> >
> > Why? What could be the problem? I fail to see how the Python policy of
> > preferring spaces over tabs while allowing both if used consistent is
> > causing any problem.
>
> There can be some problems, say in one class a teacher says: never
> use tabs, in other class a teacher says: don't use spaces.
> Who is right?
> This is not a major problem, but technically seen using tabs
> is more logical way, but de-facto spaces are recommended.
> I've noticed a tendency that more and more users
> choose tabs. Indeed if you think about it, using several spaces for
> one level of indentation is ridiculous and it is not only my opinion.
> So tabs are quite natural choice, but with spaces being a 'recommended'
> style, there are two 'camps' within one language.
> New users will be always frustrated, and ask why is it bad to use tabs.
> But can all teachers explain exactly the difference? So it starts as a
> problem of choice.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Mikhail V]

On 18 March 2017 at 16:54, Lutz Horn  wrote:
> Am 18.03.17 um 16:18 schrieb Mikhail V:
>> On 18 March 2017 at 05:02, Ben Finney 
>> wrote:
>>> Mikhail V  writes:
>>>
 I think it would be a salvation to forbid spaces for indentation,
 did such attemps take place?
>>>
>>> Feel free to start your own discussion forum for your new
>>> programming language that forbids spaces for indentation. That
>>> language will never be Python, so please don't ask us to discuss it
>>> here.
>
>> So you are the opinion it would be more productive to invent a new
>> language instead of just cleaning up spaces?
>
> Productive in solving what problem exactly? Why do you think a cleaning
> of spaces is necessary?

Ehm, why is it necessary? I won't mix them and I use tabs, so if I become a
source with spaces and edit it, I must replace them, then if a spacist becomes
tabulated code he replaces tabs with spaces again. Not a big
deal, but seems strange.

>
>> I think it still helps to realize that in the future this will become
>> more noticable problem than it seems now
>
> Why? What could be the problem? I fail to see how the Python policy of
> preferring spaces over tabs while allowing both if used consistent is
> causing any problem.

There can be some problems, say in one class a teacher says: never
use tabs, in other class a teacher says: don't use spaces.
Who is right?
This is not a major problem, but technically seen using tabs
is more logical way, but de-facto spaces are recommended.
I've noticed a tendency that more and more users
choose tabs. Indeed if you think about it, using several spaces for
one level of indentation is ridiculous and it is not only my opinion.
So tabs are quite natural choice, but with spaces being a 'recommended'
style, there are two 'camps' within one language.
New users will be always frustrated, and ask why is it bad to use tabs.
But can all teachers explain exactly the difference? So it starts as a
problem of choice.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Bob Gailer]

On Mar 17, 2017 9:23 PM, "Mikhail V"  wrote:
>
> So Python supports both spaces and tabs for indentation.
>
> I just wonder, why not forbid spaces in the beginning of lines?
> How would one come to the idea to use spaces for indentation at all?

One problem for me with tabs: there is no standard visual representation (1
tab = ? Spaces)
>
> Space is not even a control/format character, but a word separator.

Huh? The character sets I'm familiar with don't have "word separators".
Space is just another no -control character.

> And when editors will be proportional font based

Editors allow your choice of font. Some are proportional, some monospaced.
I fail to see any benefit from making a proportional-only font based
editor.

, indenting with
> spaces will not make *any* sense so they are just annoyance.

Only in the eye of the beholder.

> Neither makes it sense in general case of text editing.
> I think it would be a salvation to forbid spaces for indentation,
> did such attemps take place?
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Grant Edwards]

On 2017-03-18, Jon Ribbens  wrote:
> On 2017-03-18, Grant Edwards  wrote:
>> On 2017-03-18, Mikhail V  wrote:
>>> How would one come to the idea to use spaces for indentation at all?
>>
>> Because tabs are a major security vulnerability and should be outlawed
>> in all source code.
>
> You forgot to mention that tabs are carcinogenic, can be addictive,
> and hate our freedoms.

And they contribute to global warming.

> If we use them, the terrorists win. Tabs can settle during transit,
> and may contain traces of nuts. Tabs should not be folded, spindled
> or mutilated. Tabs are vicious if wounded.  Remember, kids: Just Say
> No to the Invisible Menace.

And remember, kids...

   Do Not Taunt Tabs.

-- 
Grant Edwards   grant.b.edwardsYow! I want EARS!  I want
  at   two ROUND BLACK EARS
  gmail.comto make me feel warm
   'n secure!!

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Gary Herron]

On 03/18/2017 06:46 AM, Mikhail V wrote:

On 18 March 2017 at 03:09, Joel Goldstick  wrote:

On Fri, Mar 17, 2017 at 8:52 PM, Mikhail V  wrote:

So Python supports both spaces and tabs for indentation.

I just wonder, why not forbid spaces in the beginning of lines?
How would one come to the idea to use spaces for indentation at all?

Space is not even a control/format character, but a word separator.
And when editors will be proportional font based, indenting with
spaces will not make *any* sense so they are just annoyance.
Neither makes it sense in general case of text editing.
I think it would be a salvation to forbid spaces for indentation,
did such attemps take place?

This is not a useful conversation.  It has been had over and over in
the past.  Some people like tabs, some like spaces.  In python you can
use either, but you must stick to one or the other


Not to judge, but usually such opinions come from determined
spasists. And "stick to one or the other" is exactly what would make
life easier, but in literal sense of global preference.

On 18 March 2017 at 05:02, Ben Finney  wrote:

Mikhail V  writes:


I just wonder, why not forbid spaces in the beginning of lines?

Because that would make countless lines of existing Python code illegal.

Yes, yes. And it is of course so hard to clean up spaces in existing code.


As a mater of fact, and despite the snark, that is true.  A quick count 
finds 46,209 .py files on my computer, spread across the OS, installed 
packages, and my own work.  I would strongly resist anything that needs 
that much re-installation and personal attention.



--
Dr. Gary Herron
Professor of Computer Science
DigiPen Institute of Technology
(425) 895-4418

--
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Jon Ribbens]

On 2017-03-18, Grant Edwards  wrote:
> On 2017-03-18, Mikhail V  wrote:
>> How would one come to the idea to use spaces for indentation at all?
>
> Because tabs are a major security vulnerability and should be outlawed
> in all source code.

You forgot to mention that tabs are carcinogenic, can be addictive,
and hate our freedoms. If we use them, the terrorists win. Tabs can
settle during transit, and may contain traces of nuts. Tabs should
not be folded, spindled or mutilated. Tabs are vicious if wounded.
Remember, kids: Just Say No to the Invisible Menace.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Who are the "spacists"?

[Grant Edwards]

On 2017-03-18, Mikhail V  wrote:

> So Python supports both spaces and tabs for indentation.

Indeed.

> I just wonder, why not forbid spaces in the beginning of lines?

Because spaces are pure, clean, and secure.

> How would one come to the idea to use spaces for indentation at all?

Because tabs are a major security vulnerability and should be outlawed
in all source code.

-- 
Grant

-- 
https://mail.python.org/mailman/listinfo/python-list