subject:"Re\: Python indentation \(3 spaces\)"


On 15/10/18 16:41, Marko Rauhamaa wrote:

Rhodri James :


On 15/10/18 12:28, Marko Rauhamaa wrote:

Try running

  emacs -q abc.c

and observe the indentation depth.


"""User Option: c-basic-offset

 This style variable holds the basic offset between indentation
levels. It's factory default is 4, but all the built-in styles set it
themselves, to some value between 2 (for gnu style) and 8 (for bsd,
linux, and python styles)."""


To realize why 2 is the factory default despite the above statement, we
observe that the factory setting of c-default-style specifies "gnu" for
C-like files other than Java and awk.


In other words, only for some  C styles.  As I said.

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

Re: Python indentation (3 spaces)

2018-10-15 Thread Marko Rauhamaa

Rhodri James :

> On 15/10/18 12:28, Marko Rauhamaa wrote:
>> Try running
>>
>>  emacs -q abc.c
>>
>> and observe the indentation depth.
>
> """User Option: c-basic-offset
>
> This style variable holds the basic offset between indentation
> levels. It's factory default is 4, but all the built-in styles set it
> themselves, to some value between 2 (for gnu style) and 8 (for bsd,
> linux, and python styles)."""

To realize why 2 is the factory default despite the above statement, we
observe that the factory setting of c-default-style specifies "gnu" for
C-like files other than Java and awk.


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

Re: Python indentation (3 spaces)


On 15/10/18 12:28, Marko Rauhamaa wrote:

Rhodri James :


On 15/10/18 05:45, Marko Rauhamaa wrote:

The two-space indentation is the out-of-the-box default for emacs.


Ahem.  It's the default for certain C styles.  It's not even the default
for C-mode itself, which is 4.


You must be running a different version of emacs than all the versions
I've every run.

Try running

 emacs -q abc.c

and observe the indentation depth.


https://www.gnu.org/software/emacs/manual/html_node/ccmode/Customizing-Indentation.html#Customizing-Indentation

"""User Option: c-basic-offset

This style variable holds the basic offset between indentation 
levels. It's factory default is 4, but all the built-in styles set it 
themselves, to some value between 2 (for gnu style) and 8 (for bsd, 
linux, and python styles)."""


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

Re: Python indentation (3 spaces)

2018-10-15 Thread Antoon Pardon

On 13-10-18 09:37, Peter J. Holzer wrote:
> On 2018-10-09 09:55:34 +0200, Antoon Pardon wrote:
>> On 08-10-18 19:43, Peter J. Holzer wrote:
>>> On 2018-10-08 10:36:21 +1100, Chris Angelico wrote:
 How wide my indents are on my screen shouldn't influence your screen
 or your choices.
>>> Theoretically I would agree with you: Just use a single tab per
>>> indentation level and let the user decide whether that's displayed as 2,
>>> 3, 4, or 8 spaces or 57 pixels or whatever. 
>>>
>>> In practice it doesn't work in my experience. There is always someone in
>>> a team who was "just testing that new editor" and replaced all tabs
>>> with spaces (or vice versa) or - worse - just some of them.
>> Isn't that caugth in the process of commiting to version control?
> Tabs are easy to catch. If a file contains a tab, reject it.
>
> Spaces aren't, because spaces are everywhere.

Spaces that replaced a tab by accident, are easy to catch too. They are all
those lines that show up when you do a diff with the previous version that
shouldn't show up.

-- 
Antoon.

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

Re: Python indentation (3 spaces)

2018-10-15 Thread Marko Rauhamaa

Rhodri James :

> On 15/10/18 05:45, Marko Rauhamaa wrote:
>> The two-space indentation is the out-of-the-box default for emacs.
>
> Ahem.  It's the default for certain C styles.  It's not even the default
> for C-mode itself, which is 4.

You must be running a different version of emacs than all the versions
I've every run.

Try running

emacs -q abc.c

and observe the indentation depth.

> Those of us who believe that tabs are evil set indent-tabs-mode nil
> anyway to stop the annoying behaviour.

Yes.


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

Re: Python indentation (3 spaces)


On 15/10/18 05:45, Marko Rauhamaa wrote:

Chris Angelico :

I'm saying I have never seen is this:

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:

However, it is trumped by an older
convention whereby the indentation levels go as follows:

0:
1: SPC SPC
2: SPC SPC SPC SPC
3: SPC SPC SPC SPC SPC SPC
4: TAB
5: TAB SPC SPC
6: TAB SPC SPC SPC SPC
7: TAB SPC SPC SPC SPC SPC SPC
8: TAB TAB


Specifically that two-space indents and tab-collapsing are a
*convention*. I have never seen this used anywhere, much less seen it
commonly enough to call it a convention.


The two-space indentation is the out-of-the-box default for emacs.


Ahem.  It's the default for certain C styles.  It's not even the default 
for C-mode itself, which is 4.  Those of us who believe that tabs are 
evil set indent-tabs-mode nil anyway to stop the annoying behaviour.


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

Re: Python indentation (3 spaces)


On 14/10/18 09:06, Peter J. Holzer wrote:

On 2018-10-14 00:45:49 +, Grant Edwards wrote:

On 2018-10-13, Peter J. Holzer  wrote:



For "just use tabs" to work, all of those tools would have to
magically recognize that they're looking at Python source and adjust
the tab size accordingly.  That isn't going to happen.


Well, no. The idea of "just use tabs" isn't have a different tab width
per language, but a different tab width per user.


You work in a different environment than I do.  for me, tab width
varies from one project to another (sometimes even in the same
language).  I don't get to pick just one tab width.


You probably don't because you use spaces, not tabs.

If everybody used tabs, why would anyone care about your tab width?
Unless they look over your shoulder while you are typing, they won't
even know how wide your tabs are.


If you used two-space tab stops and I used (the normal :-) eight, 
comfortable indentations for you would rapidly become uncomfortably 
large indentations for me.  I'd care about that.  I'd also care if you 
used spaces to make sub-tab stop adjustments to line up appropriate text 
(inside brackets, for example).


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

Re: Python indentation (3 spaces)

2018-10-15 Thread Marko Rauhamaa

Chris Angelico :

> On Mon, Oct 15, 2018 at 3:51 PM Marko Rauhamaa  wrote:
> I don't understand your point here. It prints a letter, then some
> spaces, then a tab, then another letter. On my terminal, that displays
> the tab by advancing to the next tab position. If I highlight to
> select, it's obvious that the spaces have not been collapsed or
> converted in any way; it is indeed printing that many spaces, then a
> tab. Universal default? Not very.

The point is that your tab stops are at every 8th column even if some
other tab stops were used in your editor.

Unless you configured your terminal (emulator) with the same tab stops
as your editor.

Then, you'll need to configure your printer, browser and other visual
tools that have the every-8th-column-tab-stop default.

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

Re: Python indentation (3 spaces)

On Mon, Oct 15, 2018 at 3:51 PM Marko Rauhamaa  wrote:
> The two-space indentation is the out-of-the-box default for emacs.
> However, the tab collapsing principle is a universal default. If you go
> against it, you will have to educate more tools than your editor. For
> example, try running this Python snippet (in REPL or as a program):
>
> for i in range(32):
> print("x{}\ty".format(" " * i))
>

I don't understand your point here. It prints a letter, then some
spaces, then a tab, then another letter. On my terminal, that displays
the tab by advancing to the next tab position. If I highlight to
select, it's obvious that the spaces have not been collapsed or
converted in any way; it is indeed printing that many spaces, then a
tab. Universal default? Not very.

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

Re: Python indentation (3 spaces)

2018-10-14 Thread Marko Rauhamaa

Chris Angelico :
> I'm saying I have never seen is this:
>
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
>> However, it is trumped by an older
>> convention whereby the indentation levels go as follows:
>>
>>0:
>>1: SPC SPC
>>2: SPC SPC SPC SPC
>>3: SPC SPC SPC SPC SPC SPC
>>4: TAB
>>5: TAB SPC SPC
>>6: TAB SPC SPC SPC SPC
>>7: TAB SPC SPC SPC SPC SPC SPC
>>8: TAB TAB
>
> Specifically that two-space indents and tab-collapsing are a
> *convention*. I have never seen this used anywhere, much less seen it
> commonly enough to call it a convention.

The two-space indentation is the out-of-the-box default for emacs.
However, the tab collapsing principle is a universal default. If you go
against it, you will have to educate more tools than your editor. For
example, try running this Python snippet (in REPL or as a program):

for i in range(32):
print("x{}\ty".format(" " * i))


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

Re: Python indentation (3 spaces)

On Mon, Oct 15, 2018 at 2:51 PM Alan Bawden  wrote:
>
> Chris Angelico  writes:
> > On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> > > In my experience this is a very common way to assume that tabs will be
> > > interpreted.  Virtually every source-code file I have encountered since 
> > > the
> > > mid 1970s (for any programming language or operating system) has assumed
> > > either this convention or, slightly less often, its 4-column variant.
> > >
> > > It's surprising that you've never encountered it.
> >
> > I've seen the four-column variant, but never the two. Maybe I just
> > move in different circles. In any case, I wouldn't say that "two space
> > indents, collapsed to a tab after eight" is somehow a universal
> > convention any more than four-space with or without collapsing.
>
> I think we're talking past each other somehow here.  I described the common
> 8-column interpretation, and the less common 4-column interpretation.  I
> did not mention, nor do I ever remember encountering in the wild, the
> 2-column variation.  (I _have_ seen the 10-column variation used -- it was
> the standard on Multics.)
> [chomp details]

I believe we are in agreement here - that it is common for a tab to be
interpreted as equivalent to eight spaces, but also that this is
definitely not the definition of the character. The convention that
I'm saying I have never seen is this:

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB

Specifically that two-space indents and tab-collapsing are a
*convention*. I have never seen this used anywhere, much less seen it
commonly enough to call it a convention.

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

Re: Python indentation (3 spaces)

2018-10-14 Thread Alan Bawden

Chris Angelico  writes:
> On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> > In my experience this is a very common way to assume that tabs will be
> > interpreted.  Virtually every source-code file I have encountered since the
> > mid 1970s (for any programming language or operating system) has assumed
> > either this convention or, slightly less often, its 4-column variant.
> >
> > It's surprising that you've never encountered it.
> 
> I've seen the four-column variant, but never the two. Maybe I just
> move in different circles. In any case, I wouldn't say that "two space
> indents, collapsed to a tab after eight" is somehow a universal
> convention any more than four-space with or without collapsing.

I think we're talking past each other somehow here.  I described the common
8-column interpretation, and the less common 4-column interpretation.  I
did not mention, nor do I ever remember encountering in the wild, the
2-column variation.  (I _have_ seen the 10-column variation used -- it was
the standard on Multics.)

The ANSI standard for ASCII only describes the tab character as follows:

   7.21 HT (HORIZONTAL TABULATION). A format effector that causes the
   active position to advance to the next predetermined character position.

This says nothing about where those "predetermined character positions"
happen to be.  They could be set at columns 5, 17, 23, 99 and 100, or they
could be set every N columns for some N, or wherever you want, it's up to
you.  (Note that this is exactly the way mechanical typewriters used to
work: "tab stops" were originally physical sliders that you would position
manually, and then when you pressed the "tab" key, a spring would pull the
carriage holding the paper to the left until it would be physically
_stopped_ by the tab stop.)

Given that the ANSI standard is silent on where the tab stops should be set
for the HT character, we can only ask where they are set _in practice_,
based on looking at he contents of files and the behavior of various pieces
of software.  For example, in the Linux termios(3) manual page describes
one of the options you can set to control output to a terminal:

   TABDLY Horizontal tab delay mask.  Values are TAB0, TAB1, TAB2, TAB3 (or
  XTABS).  A value of TAB3, that is, XTABS, expands tabs to spaces
  (with tab stops every eight columns).

So if tabs are going to be converted to spaces on output, your only choice
is the every-8-columns interpretation.  (Interestingly, setting TABDLY to
TAB3 to convert tabs to spaces is part of POSIX, but the POSIX standard
does _not_ appear to specify the positions of the tab stops!)

The 8-column interpretation is also the default behavior in every text
editor I have ever used (except, as I noted above, on Multics!).

The 8-column interpretation also seems most common in source code files,
although 4-column files do show up occasionally.

So when you say:

   I've literally NEVER come across this as a convention.  Not a single
   file that I have ever worked with has used it.  Where is this convention
   from?

I feel that there _must_ be some misunderstanding here.  Maybe you
misinterpreted Marko's description of how 8-column tabs are used to achieve
2-columns-per-level indentation.  Or maybe I'm misunderstanding what you
mean by "convention".  Or maybe one of us just beamed in from parallel
universe...

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

Re: Python indentation (3 spaces)

On Mon, Oct 15, 2018 at 9:56 AM Alan Bawden  wrote:
> In my experience this is a very common way to assume that tabs will be
> interpreted.  Virtually every source-code file I have encountered since the
> mid 1970s (for any programming language or operating system) has assumed
> either this convention or, slightly less often, its 4-column variant.
>
> It's surprising that you've never encountered it.

I've seen the four-column variant, but never the two. Maybe I just
move in different circles. In any case, I wouldn't say that "two space
indents, collapsed to a tab after eight" is somehow a universal
convention any more than four-space with or without collapsing.

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

Re: Python indentation (3 spaces)

2018-10-14 Thread Alan Bawden

Chris Angelico  writes:
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> > Chris Angelico :
...
> > That *could* be the situation. However, it is trumped by an older
> > convention whereby the indentation levels go as follows:
> >
> >0:
> >1: SPC SPC
> >2: SPC SPC SPC SPC
> >3: SPC SPC SPC SPC SPC SPC
> >4: TAB
> >5: TAB SPC SPC
> >6: TAB SPC SPC SPC SPC
> >7: TAB SPC SPC SPC SPC SPC SPC
> >8: TAB TAB
> 
> I've literally NEVER come across this as a convention. Not a single
> file that I have ever worked with has used it. Where is this
> convention from?

I just picked a C source code file AT RANDOM from the FreeBSD source tree
on the machine I'm using to compose this message
(/usr/src/gnu/usr.bin/man/man/glob.c), and I find that, as I expected, it
uses exactly that convention.  And in that file, the comments don't line up
as the author clearly intended unless the tab stops are set every 8
columns.

In my experience this is a very common way to assume that tabs will be
interpreted.  Virtually every source-code file I have encountered since the
mid 1970s (for any programming language or operating system) has assumed
either this convention or, slightly less often, its 4-column variant.

It's surprising that you've never encountered it.

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

Re: Python indentation (3 spaces)

2018-10-14 Thread Cameron Simpson

On 15Oct2018 00:33, Peter J. Holzer  wrote:

On 2018-10-15 09:06:11 +1100, Chris Angelico wrote:

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> Chris Angelico :
> > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > One indentation level is represented by one tab. Two indentation
> > levels? Two tabs. It's about as perfect a representation as you could
> > hope for.
>
> That *could* be the situation. However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB

That's not using tabs for indentation, that's using tabs for compressing
spaces (somebody already mentioned that in this thread).

I've literally NEVER come across this as a convention. Not a single
file that I have ever worked with has used it. Where is this
convention from?

It's something vi does by default, and apparently emacs as well.
In the 1970's saving space by replacing sequences of 8 spaces
with tabs seemed lika a good idea.

There are workarounds in vi(m), but I'm not sure if you can get rid of
that behaviour completely. I'm sure it is possible in emacs.

I'm a "just use spaces" guy. I use the tab _key_ as a shortcut to do a 
bunch of spaces.

My vim setup has this:

 set expandtab

which turns them into spaces.

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

2018-10-14 Thread Peter J. Holzer

On 2018-10-15 09:06:11 +1100, Chris Angelico wrote:
> On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
> > Chris Angelico :
> > > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > > One indentation level is represented by one tab. Two indentation
> > > levels? Two tabs. It's about as perfect a representation as you could
> > > hope for.
> >
> > That *could* be the situation. However, it is trumped by an older
> > convention whereby the indentation levels go as follows:
> >
> >0:
> >1: SPC SPC
> >2: SPC SPC SPC SPC
> >3: SPC SPC SPC SPC SPC SPC
> >4: TAB
> >5: TAB SPC SPC
> >6: TAB SPC SPC SPC SPC
> >7: TAB SPC SPC SPC SPC SPC SPC
> >8: TAB TAB

That's not using tabs for indentation, that's using tabs for compressing
spaces (somebody already mentioned that in this thread).

> I've literally NEVER come across this as a convention. Not a single
> file that I have ever worked with has used it. Where is this
> convention from?

It's something vi does by default, and apparently emacs as well.
In the 1970's saving space by replacing sequences of 8 spaces
with tabs seemed lika a good idea.

There are workarounds in vi(m), but I'm not sure if you can get rid of
that behaviour completely. I'm sure it is possible in emacs.

> > Your scheme also is ad hoc in that it doesn't follow its logic to other
> > ASCII control characters. Why not use VT to separate methods? Why not
> > use US to separate operators from operands? Why not use RS to separate
> > the operands of optional arguments? Why not use GS to separate logical
> > blocks of code? After all, those schemes would allow people to
> > personalize the visual representation of more aspects of the source
> > code.
> 
> You're most welcome to use VT between methods.

I sometimes use FF so separate sections of code in longer files. Had to
stop that in Django projects because it messes up the stack traces.

> Not sure what you mean by US, RS, and GS,

Unit separator, record separator, group separator (and FS is file
separator). I think they were intended for a CSV-like file format, but I
have never seen them in use (outside of my own projects).

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

On Mon, Oct 15, 2018 at 8:56 AM Marko Rauhamaa  wrote:
>
> Chris Angelico :
>
> > Tabs for indentation have semantic meaning. Top-level has zero tabs.
> > One indentation level is represented by one tab. Two indentation
> > levels? Two tabs. It's about as perfect a representation as you could
> > hope for. If you like your indentation levels to be as wide as four
> > spaces, you can have that. I could have them at eight, and it wouldn't
> > make a difference. And if someone messes up their code by using tabs
> > to align all their comments, reject that code at code review time.
> > This ain't rocket science.
>
> That *could* be the situation. However, it is trumped by an older
> convention whereby the indentation levels go as follows:
>
>0:
>1: SPC SPC
>2: SPC SPC SPC SPC
>3: SPC SPC SPC SPC SPC SPC
>4: TAB
>5: TAB SPC SPC
>6: TAB SPC SPC SPC SPC
>7: TAB SPC SPC SPC SPC SPC SPC
>8: TAB TAB

I've literally NEVER come across this as a convention. Not a single
file that I have ever worked with has used it. Where is this
convention from?

> Your scheme also is ad hoc in that it doesn't follow its logic to other
> ASCII control characters. Why not use VT to separate methods? Why not
> use US to separate operators from operands? Why not use RS to separate
> the operands of optional arguments? Why not use GS to separate logical
> blocks of code? After all, those schemes would allow people to
> personalize the visual representation of more aspects of the source
> code.

You're most welcome to use VT between methods. Not sure what you mean
by US, RS, and GS, but if they count as whitespace, you are absolutely
welcome to use them. I don't see why you have to use ALL of them if
you use any, but hey, if you want to, nobody's stopping you. What's
the issue here?

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

Re: Python indentation (3 spaces)

2018-10-14 Thread Marko Rauhamaa

Chris Angelico :

> Tabs for indentation have semantic meaning. Top-level has zero tabs.
> One indentation level is represented by one tab. Two indentation
> levels? Two tabs. It's about as perfect a representation as you could
> hope for. If you like your indentation levels to be as wide as four
> spaces, you can have that. I could have them at eight, and it wouldn't
> make a difference. And if someone messes up their code by using tabs
> to align all their comments, reject that code at code review time.
> This ain't rocket science.

That *could* be the situation. However, it is trumped by an older
convention whereby the indentation levels go as follows:

   0:
   1: SPC SPC
   2: SPC SPC SPC SPC
   3: SPC SPC SPC SPC SPC SPC
   4: TAB
   5: TAB SPC SPC
   6: TAB SPC SPC SPC SPC
   7: TAB SPC SPC SPC SPC SPC SPC
   8: TAB TAB

That's how emacs indents source code files out of the box, BTW.

Moreover:

   SPC TAB = TAB
   SPC SPC SPC SPC SPC SPC SPC SPC = TAB

etc.

This older convention is honored by Python2 as well.

This older convention has been honored by many operating systems (at
least UNIX, CP/M and MS-DOS).

If I had to choose between your scheme and the older scheme, I'd choose
the older one.

Instead, I have chosen to banish HT as an unnecessary distraction.

Your scheme also is ad hoc in that it doesn't follow its logic to other
ASCII control characters. Why not use VT to separate methods? Why not
use US to separate operators from operands? Why not use RS to separate
the operands of optional arguments? Why not use GS to separate logical
blocks of code? After all, those schemes would allow people to
personalize the visual representation of more aspects of the source
code.


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

Re: Python indentation (3 spaces)

On Mon, Oct 15, 2018 at 1:35 AM Grant Edwards  wrote:
>
> On 2018-10-14, Christian Gollwitzer  wrote:
> > Am 14.10.18 um 02:45 schrieb Grant Edwards:
> >> On 2018-10-13, Peter J. Holzer  wrote:
> >>>
>  For "just use tabs" to work, all of those tools would have to
>  magically recognize that they're looking at Python source and adjust
>  the tab size accordingly.  That isn't going to happen.
> >>>
> >>> Well, no. The idea of "just use tabs" isn't have a different tab width
> >>> per language, but a different tab width per user.
> >>
> >> You work in a different environment than I do.  for me, tab width
> >> varies from one project to another (sometimes even in the same
> >> language).  I don't get to pick just one tab width.
> >
> > But if you use only tabs for indentation, the tab width setting simply
> > does not matter.
>
> > There is a disadvantage only if you try to align something which is NOT
> > an indentation level, e.g. when there are big string constants or list
> > constants etc.
>
> Exactly.  In my experience, people who use tabs for indentation always
> end up using them for other things as well: aligning comments or columns
> in data tables, etc.
>

Well, I don't, and I DO use tabs for indentation. So how about we
restrict this discussion to indentation, and not worry about other
things people might also use tabs for?

Tabs for indentation have semantic meaning. Top-level has zero tabs.
One indentation level is represented by one tab. Two indentation
levels? Two tabs. It's about as perfect a representation as you could
hope for. If you like your indentation levels to be as wide as four
spaces, you can have that. I could have them at eight, and it wouldn't
make a difference. And if someone messes up their code by using tabs
to align all their comments, reject that code at code review time.
This ain't rocket science.

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

Re: Python indentation (3 spaces)

2018-10-14 Thread Grant Edwards

On 2018-10-14, Christian Gollwitzer  wrote:
> Am 14.10.18 um 02:45 schrieb Grant Edwards:
>> On 2018-10-13, Peter J. Holzer  wrote:
>>>
 For "just use tabs" to work, all of those tools would have to
 magically recognize that they're looking at Python source and adjust
 the tab size accordingly.  That isn't going to happen.
>>>
>>> Well, no. The idea of "just use tabs" isn't have a different tab width
>>> per language, but a different tab width per user.
>> 
>> You work in a different environment than I do.  for me, tab width
>> varies from one project to another (sometimes even in the same
>> language).  I don't get to pick just one tab width.
>
> But if you use only tabs for indentation, the tab width setting simply 
> does not matter.

> There is a disadvantage only if you try to align something which is NOT 
> an indentation level, e.g. when there are big string constants or list 
> constants etc.

Exactly.  In my experience, people who use tabs for indentation always
end up using them for other things as well: aligning comments or columns
in data tables, etc.

-- 
Grant

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

Re: Python indentation (3 spaces)

2018-10-14 Thread Peter J. Holzer

On 2018-10-14 00:45:49 +, Grant Edwards wrote:
> On 2018-10-13, Peter J. Holzer  wrote:
> >
> >> For "just use tabs" to work, all of those tools would have to
> >> magically recognize that they're looking at Python source and adjust
> >> the tab size accordingly.  That isn't going to happen.
> >
> > Well, no. The idea of "just use tabs" isn't have a different tab width
> > per language, but a different tab width per user.
> 
> You work in a different environment than I do.  for me, tab width
> varies from one project to another (sometimes even in the same
> language).  I don't get to pick just one tab width.

You probably don't because you use spaces, not tabs.

If everybody used tabs, why would anyone care about your tab width?
Unless they look over your shoulder while you are typing, they won't
even know how wide your tabs are.

(That said, I personally prefer shorter indentation for marked up text
(like HTML or LaTeX) than for programming languages. But I could live
with the same indentation if necessary (and of course it isn't
necessary: Any decent editor has to be able detect the file type anyway
for syntax highlighting so it can adjust the display of tabs, too.))

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

2018-10-14 Thread Christian Gollwitzer


Am 14.10.18 um 02:45 schrieb Grant Edwards:

On 2018-10-13, Peter J. Holzer  wrote:



For "just use tabs" to work, all of those tools would have to
magically recognize that they're looking at Python source and adjust
the tab size accordingly.  That isn't going to happen.


Well, no. The idea of "just use tabs" isn't have a different tab width
per language, but a different tab width per user.


You work in a different environment than I do.  for me, tab width
varies from one project to another (sometimes even in the same
language).  I don't get to pick just one tab width.


But if you use only tabs for indentation, the tab width setting simply 
does not matter. I'm in favour of using only tabs.


There is a disadvantage only if you try to align something which is NOT 
an indentation level, e.g. when there are big string constants or list 
constants etc.


Christian


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

Re: Python indentation (3 spaces)

2018-10-13 Thread Grant Edwards

On 2018-10-13, Peter J. Holzer  wrote:
>
>> For "just use tabs" to work, all of those tools would have to
>> magically recognize that they're looking at Python source and adjust
>> the tab size accordingly.  That isn't going to happen.
>
> Well, no. The idea of "just use tabs" isn't have a different tab width
> per language, but a different tab width per user.

You work in a different environment than I do.  for me, tab width
varies from one project to another (sometimes even in the same
language).  I don't get to pick just one tab width.

-- 
Grant


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

Re: Python indentation (3 spaces)

2018-10-13 Thread Peter J. Holzer

On 2018-10-09 09:55:34 +0200, Antoon Pardon wrote:
> On 08-10-18 19:43, Peter J. Holzer wrote:
> > On 2018-10-08 10:36:21 +1100, Chris Angelico wrote:
> >> How wide my indents are on my screen shouldn't influence your screen
> >> or your choices.
> > Theoretically I would agree with you: Just use a single tab per
> > indentation level and let the user decide whether that's displayed as 2,
> > 3, 4, or 8 spaces or 57 pixels or whatever. 
> >
> > In practice it doesn't work in my experience. There is always someone in
> > a team who was "just testing that new editor" and replaced all tabs
> > with spaces (or vice versa) or - worse - just some of them.
> 
> Isn't that caugth in the process of commiting to version control?

Tabs are easy to catch. If a file contains a tab, reject it.

Spaces aren't, because spaces are everywhere. So you would have to check
whether a particular run of spaces should really be a tab, which is a
much harder problem. At the very least you will have to parse enough of
the language to find multi-line strings and indented blocks.

So it's easier to mandate "no tabs" than "only tabs for indentation".
Especially if you are dealing with more than one language. (I think
Python would be relatively easy. Perl is somewhere between hard and
impossible, but there is a library which can handle most
non-pathological code, C is somewhere between, etc. But the point is
that you would need a different checking tool for every language.)

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

2018-10-13 Thread Peter J. Holzer

On 2018-10-08 20:13:38 +, Grant Edwards wrote:
> On 2018-10-08, Peter J. Holzer  wrote:
> > Theoretically I would agree with you: Just use a single tab per
> > indentation level and let the user decide whether that's displayed
> > as 2, 3, 4, or 8 spaces or 57 pixels or whatever.
> >
> > In practice it doesn't work in my experience.
> 
> Nor in mine.  On problem is that under Unix is that there isn't just
> one place where you would need to configure the tab width.  There are
> dozens of text-processing tools that get used on all sorts of text,
> including program sources in a variety of languages.
> 
> For "just use tabs" to work, all of those tools would have to
> magically recognize that they're looking at Python source and adjust
> the tab size accordingly.  That isn't going to happen.

Well, no. The idea of "just use tabs" isn't have a different tab width
per language, but a different tab width per user. So I - being a fan of
fixed-width fonts - would set the tab width to 5 spaces (just to pick a
somewhat unusual number), and Python, Perl, C, TypeScript, HTML, CSS,
etc. code containing tabs would be displayed and printed with that tab
width. You set your tab width to half an inch. And all your text files
are displayed and printed with that tab width. Gene uses 3 spaces, etc.

There aren't that many tools which would have to be configured. For me
that would be vim (the text editor), the tty driver and/or the terminal
emulator (not sure what the right place is), less (the pager), and paps
(for printing). Maybe a few others, but the vast majority of tools
doesn't care about the tab width. For them a tab is just a single byte.

The problem is in my experience that a "use only tabs" policy is hard to
enforce. People will type spaces when they should use tabs (and use tabs
when they should use spaces), their software will autoconvert between
spaces and tabs (with a different number of spaces per tab for each
user), etc. The result is an awful mess. "Use only spaces" is much
easier to enforce: Just reject any file (except binaries and makefiles)
with a 0x09 byte at commit time.

(Now that I think of it, "use tabs" might work better in Python than in
other languages because in Python indentation has syntactic meaning. If
your editor replaces some tabs with spaces or vice versa, your program
won't compile any more and you will (hopefully) fix it before committing
it.)

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

2018-10-09 Thread Antoon Pardon

On 08-10-18 19:43, Peter J. Holzer wrote:
> On 2018-10-08 10:36:21 +1100, Chris Angelico wrote:
>> TBH, I think that tab width should be up to the display, just like the
>> font. You're allowed to view code in any font that makes sense for
>> you, and you should be able to view code with any indentation that
>> makes sense for you. If someone submits code and says "it looks
>> tidiest in Times New Roman 12/10pt", I'm sure you'd recommend making
>> sure it doesn't matter [1]; if someone submits code and says "you have
>> to set your tabs equal to 5 spaces or it looks ugly", you'd say the
>> same, right?
>>
>> How wide my indents are on my screen shouldn't influence your screen
>> or your choices.
> Theoretically I would agree with you: Just use a single tab per
> indentation level and let the user decide whether that's displayed as 2,
> 3, 4, or 8 spaces or 57 pixels or whatever. 
>
> In practice it doesn't work in my experience. There is always someone in
> a team who was "just testing that new editor" and replaced all tabs
> with spaces (or vice versa) or - worse - just some of them.

Isn't that caugth in the process of commiting to version control?

-- 
Antoon Pardon.

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Chris Angelico

On Tue, Oct 9, 2018 at 9:06 AM Marko Rauhamaa  wrote:
>
> Thomas Jollans :
>
> > On 08/10/2018 08:31, Marko Rauhamaa wrote:
> >> Where I work (and at home), the only control character that is allowed
> >> in source code is LF.
> >
> > No tolerance for form feeds?
>
> None whatsoever.
>
> CR is ok but only if immediately followed by BEL. That way typing source
> code gives out the air of an old typewriter.
>
> Highlighting keywords with ANSI escape sequences can also be rather
> cute.
>

Bah, you're missing out on so much fun by banning control characters.
Inserting a "cursor up one line" character in the middle of a quoted
string makes typing source code ever so much more exciting! Especially
if you carefully engineer it so it gently changes a few variable
names...

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Marko Rauhamaa

Thomas Jollans :

> On 08/10/2018 08:31, Marko Rauhamaa wrote:
>> Where I work (and at home), the only control character that is allowed
>> in source code is LF.
>
> No tolerance for form feeds?

None whatsoever.

CR is ok but only if immediately followed by BEL. That way typing source
code gives out the air of an old typewriter.

Highlighting keywords with ANSI escape sequences can also be rather
cute.

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Thomas Jollans


On 08/10/2018 08:31, Marko Rauhamaa wrote:

Chris Angelico :

How wide my indents are on my screen shouldn't influence your screen
or your choices.


Where I work (and at home), the only control character that is allowed
in source code is LF.



No tolerance for form feeds?

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Grant Edwards

On 2018-10-08, Peter J. Holzer  wrote:

> Theoretically I would agree with you: Just use a single tab per
> indentation level and let the user decide whether that's displayed
> as 2, 3, 4, or 8 spaces or 57 pixels or whatever.
>
> In practice it doesn't work in my experience.

Nor in mine.  On problem is that under Unix is that there isn't just
one place where you would need to configure the tab width.  There are
dozens of text-processing tools that get used on all sorts of text,
including program sources in a variety of languages.

For "just use tabs" to work, all of those tools would have to
magically recognize that they're looking at Python source and adjust
the tab size accordingly.  That isn't going to happen.

> There is always someone in a team who was "just testing that new
> editor" and replaced all tabs with spaces (or vice versa) or - worse
> - just some of them. It is safer to disallow tabs completely and
> mandate a certain number of spaces per indentation level.

Indeed. That's the only thing that actually works.

-- 
Grant Edwards   grant.b.edwardsYow! Being a BALD HERO
  at   is almost as FESTIVE as a
  gmail.comTATTOOED KNOCKWURST.

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Marko Rauhamaa

Chris Angelico :
> How wide my indents are on my screen shouldn't influence your screen
> or your choices.

Where I work (and at home), the only control character that is allowed
in source code is LF.


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

Re: Python indentation (3 spaces)

2018-10-08 Thread Chris Angelico

On Tue, Oct 9, 2018 at 4:44 AM Peter J. Holzer  wrote:
>
> On 2018-10-08 10:36:21 +1100, Chris Angelico wrote:
> > TBH, I think that tab width should be up to the display, just like the
> > font. You're allowed to view code in any font that makes sense for
> > you, and you should be able to view code with any indentation that
> > makes sense for you. If someone submits code and says "it looks
> > tidiest in Times New Roman 12/10pt", I'm sure you'd recommend making
> > sure it doesn't matter [1]; if someone submits code and says "you have
> > to set your tabs equal to 5 spaces or it looks ugly", you'd say the
> > same, right?
> >
> > How wide my indents are on my screen shouldn't influence your screen
> > or your choices.
>
> Theoretically I would agree with you: Just use a single tab per
> indentation level and let the user decide whether that's displayed as 2,
> 3, 4, or 8 spaces or 57 pixels or whatever.
>
> In practice it doesn't work in my experience. There is always someone in
> a team who was "just testing that new editor" and replaced all tabs
> with spaces (or vice versa) or - worse - just some of them. It is safer
> to disallow tabs completely and mandate a certain number of spaces per
> indentation level.
>

Ahh yes, it hurts to stick your neck out and have someone hack at it... :|

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Peter J. Holzer

On 2018-10-08 10:36:21 +1100, Chris Angelico wrote:
> TBH, I think that tab width should be up to the display, just like the
> font. You're allowed to view code in any font that makes sense for
> you, and you should be able to view code with any indentation that
> makes sense for you. If someone submits code and says "it looks
> tidiest in Times New Roman 12/10pt", I'm sure you'd recommend making
> sure it doesn't matter [1]; if someone submits code and says "you have
> to set your tabs equal to 5 spaces or it looks ugly", you'd say the
> same, right?
> 
> How wide my indents are on my screen shouldn't influence your screen
> or your choices.

Theoretically I would agree with you: Just use a single tab per
indentation level and let the user decide whether that's displayed as 2,
3, 4, or 8 spaces or 57 pixels or whatever. 

In practice it doesn't work in my experience. There is always someone in
a team who was "just testing that new editor" and replaced all tabs
with spaces (or vice versa) or - worse - just some of them. It is safer
to disallow tabs completely and mandate a certain number of spaces per
indentation level.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | h...@hjp.at | management tools.
__/   | http://www.hjp.at/ | -- Ross Anderson 

signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

2018-10-08 Thread Rhodri James

On 05/10/18 21:48, ts9...@gmail.com wrote:

I am new to Python programming but have significant SQL and C experience. My simple question
is,"Why not standardize Python indentations to 3 spaces instead of 4 in order to avoid
potential programming errors associated with using "TAB" instead of 4 spaces?"

Thank you for the suggestion, Thomas. Unfortunately I think it's a
perfect example of something that was being discussed elsewhere, the
well-intentioned name change that actually makes things worse in the
long run.

I think the most likely outcome of switching to 3 space indentation,
which we could do right now with no need to change a single thing, is
that it would all seem to work perfectly well for a while. It wouldn't
take long for people to get irritated with actually typing three spaces
though, and to reprogram their Tab keys to three space tab stops. Once
that happens, it's only a matter of time before the people who believe
that Tabs should give you actual Tab characters do the same, and lo and
behold you are back where you started but with 3-space tab stops as well
as 4-space tab stops.

Why do I think that's what would happen? Because that's how we got
4-space tab stops in the first place. The original de facto standard
was for 8-space tab stops (see
https://en.wikipedia.org/wiki/Tab_key#Tab_characters for some
background). 8 characters on a 132-character line printer isn't that
much. 8 characters on an 80 column monitor is quite a long way, on the
other hand. People started using four spaces as a more reasonable size,
used the Tab key for convenience and eventually ended up with the unholy
mess we know and love today.

Fortunately 2-space tabbing never attracted the attention of the
tab-character purists, or we'd be in an even worse situation :-)

I've watched this sort of thing happen in too many different arenas over
the years, most obviously with my father's job. He worked with disabled
people, and changing terms used to refer to them never once got rid of
the associated prejudices. This doesn't seem to be an easy thing to
hear particularly when it's associated with something emotive like the
master/slave debate, but changing terms buys you at best a couple of
months free of previous associations. Then the old associations catch
up, and usually bring some new friends with them.

Changing indent sizes is falling into the same trap as changing
terminology, I'm afraid. It's an obvious, well-intentioned thought, but
it won't actually change anything for the better. Thank you for
bringing it up, though.

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Thomas Jollans


On 08/10/2018 03:13, Gene Heskett wrote:

On Sunday 07 October 2018 19:20:57 Dennis Lee Bieber wrote:


On Sun, 7 Oct 2018 14:19:15 -0400, Gene Heskett 

declaimed the following:

But that automatically assumes one is running in a windows
environment. I don't allow it on the premises if I own the machine.
Are there good, alternatives that run on linux?


Visual Studio Code /does/ run on Linux. Without having to install
WINE or similar.



--
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/


I just read the License TOC, and deleted the deb. I have very little use
for spyware.



You can use the open source version though. According to 
https://github.com/Microsoft/vscode/issues/60#issuecomment-161792005 
it's essentially identical but without the spyware (though you can check 
that yourself, because you know, it's open source)

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

Re: Python indentation (3 spaces)

2018-10-08 Thread Ben Finney

Terry Reedy  writes:

> You assumption that a tab means '4 spaces' is wrong.  A tab means
> 'jump to the next tab stop'.  On 10 char/inch US typewriters, tab
> stops were initially set to every 5 spaces or 1/2 inch.  In terminals
> and code editors, virtual tab stops were often set to every 8 spaces,
> and python still interprets tabs that way.
>
> This means that editing Python code in an editor that *displays* tabs
> (as opposed to converting them to spaces) with other than
> every-8-space tab stops is arguably a bad idea if the file has or
> might have non-tab space indents.

The distinctions Terry is drawing attention to are important. Often the
confusion in these discussions comes from people conflating the three
separate issues that jwz described in this classic essay
https://www.jwz.org/doc/tabs-vs-spaces.html>.

-- 
 \  “I find the whole business of religion profoundly interesting. |
  `\ But it does mystify me that otherwise intelligent people take |
_o__)it seriously.” —Douglas Adams |
Ben Finney

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

Re: Python indentation (3 spaces)

On Sunday 07 October 2018 19:20:57 Dennis Lee Bieber wrote:

> On Sun, 7 Oct 2018 14:19:15 -0400, Gene Heskett 
>
> declaimed the following:
> >But that automatically assumes one is running in a windows
> > environment. I don't allow it on the premises if I own the machine.
> > Are there good, alternatives that run on linux?
>
>   Visual Studio Code /does/ run on Linux. Without having to install
> WINE or similar.
>
>
>
> --
>   Wulfraed Dennis Lee Bieber AF6VN
>   wlfr...@ix.netcom.comHTTP://wlfraed.home.netcom.com/

I just read the License TOC, and deleted the deb. I have very little use 
for spyware.

-- 
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: Python indentation (3 spaces)

On Sunday 07 October 2018 18:47:45 Chris Angelico wrote:

> On Mon, Oct 8, 2018 at 9:46 AM Gene Heskett  
wrote:
> > On Sunday 07 October 2018 18:29:21 Chris Angelico wrote:
> > > On Mon, Oct 8, 2018 at 9:26 AM Gene Heskett 
> >
> > wrote:
> > > > On Sunday 07 October 2018 17:36:34 Chris Angelico wrote:
> > > > > On Mon, Oct 8, 2018 at 8:27 AM Gene Heskett
> > > > > 
> > > >
> > > > wrote:
> > > > [...]>
> > > >
> > > > > Okay, but I'm trying to understand why you're referencing this
> > > > > in this thread about indentation. That would imply that you at
> > > > > least have reason to suspect that the problem is indentation.
> > > > >
> > > > > ChrisA
> > > >
> > > > Grasping at straws ChrisA.  And anything that will reach out and
> > > > slap me around when it see's a syntax problem might accidentally
> > > > teach me something about this snake.
> > >
> > > Ah. Fair enough, then. Basically, you want the Python equivalent
> > > of "gcc -Wall -Wpedantic".
> >
> > Is there such a critter?
>
> Not really; there's -Wall, of course, but it's not nearly as
> comprehensive as gcc's pedantic mode. Sorry.
>
> ChrisA

Oh,  fudge. Probably beyond my fading abilities anyway.

-- 
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: Python indentation (3 spaces)

2018-10-07 Thread Cameron Simpson

On 08Oct2018 09:47, Chris Angelico  wrote:

On Mon, Oct 8, 2018 at 9:46 AM Gene Heskett  wrote:

On Sunday 07 October 2018 18:29:21 Chris Angelico wrote:
> Ah. Fair enough, then. Basically, you want the Python equivalent of
> "gcc -Wall -Wpedantic".
>
Is there such a critter?

Not really; there's -Wall, of course, but it's not nearly as
comprehensive as gcc's pedantic mode. Sorry.

But there's any number of lint tools. My current "lint" script runs pyflakes 
and pep8 and pylint.

What I do wish was that I had a vim mode that highlighted an indent column so I 
can line up indented code with its controlling top line. (A vim mode because I 
use vim, not as a recommendation.)

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)

On Mon, Oct 8, 2018 at 10:31 AM Terry Reedy  wrote:
>
> On 10/7/2018 2:35 PM, Ryan Johnson wrote:
>
> > The logic is that all the text editors that are designed to work with 
> > Python code will KNOW to replace tab input with 3 characters, while still 
> > parsing the \t tab character as 4 characters;
>
> What do you mean by 'parsing a tab character as 4 characters'?  If the
> editor *converts* the tab to k spaces in its buffer, then k must be the
> same number as when the user types a tab, and there is no tab left to
> worry about.  If the editor put the tab into its buffer (and saves it
> with tabs), then what users on particular display devices depends on
> what the device does with tabs.
>
> Theoretically, all tabs might seem like a good idea, but since 0 spaces,
> 1/2 inch, and 8 spaces are possible display results, in addition to a
> users custom setting, this does not work except in a circumscribed
> environment.  That leaves space indents and no tabs except in strings
> where needed.
>

TBH, I think that tab width should be up to the display, just like the
font. You're allowed to view code in any font that makes sense for
you, and you should be able to view code with any indentation that
makes sense for you. If someone submits code and says "it looks
tidiest in Times New Roman 12/10pt", I'm sure you'd recommend making
sure it doesn't matter [1]; if someone submits code and says "you have
to set your tabs equal to 5 spaces or it looks ugly", you'd say the
same, right?

How wide my indents are on my screen shouldn't influence your screen
or your choices.

ChrisA

[1] eg the last of the Pet Peeves
https://www.python.org/dev/peps/pep-0008/#whitespace-in-expressions-and-statements
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Python indentation (3 spaces)


On 10/7/2018 2:35 PM, Ryan Johnson wrote:


The logic is that all the text editors that are designed to work with Python 
code will KNOW to replace tab input with 3 characters, while still parsing the 
\t tab character as 4 characters;


What do you mean by 'parsing a tab character as 4 characters'?  If the 
editor *converts* the tab to k spaces in its buffer, then k must be the 
same number as when the user types a tab, and there is no tab left to 
worry about.  If the editor put the tab into its buffer (and saves it 
with tabs), then what users on particular display devices depends on 
what the device does with tabs.


Theoretically, all tabs might seem like a good idea, but since 0 spaces, 
1/2 inch, and 8 spaces are possible display results, in addition to a 
users custom setting, this does not work except in a circumscribed 
environment.  That leaves space indents and no tabs except in strings 
where needed.


--
Terry Jan Reedy

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

Re: Re: Python indentation (3 spaces)

2018-10-07 Thread Peter via Python-list

It's also useful to be aware of the standard tabnanny module for 
"Detection of ambiguous indentation".


Very useful for highlighting problems with tabs and spaces.

Peter


On 8/10/2018 2:32 AM, Terry Reedy wrote:

On 10/5/2018 11:30 PM, Ryan Johnson wrote:

The point that OP is trying to make is that a fixed standard that is
distinguishable from the even-spacing Tab-length convention in code and
text editors will establish a level of trust between the end 
developer and
upstream developers or co-developers who may not have the same 
development

environment.


And my counter point is that a) we will not change the standard and b) 
we deliver an editor that by default enforces the standard, and c) to 
be fair, many other editors will do the same.



For example, the first Python library I ever tried to use was


What library?  From where?

poorly maintained and had spaces on one line with tabs on the next, 
and the
author mixed naming conventions and syntax from Python 2 and 3 in his 
code.

That type of experience doesn’t exactly instill trust in the coding
language’s standards, when a noob tries to use a library they found and
ends up having to debug weird errors with weirder error messages on the
first project they do.


I don't follow the logic.  If someone violates a law, does that make 
the law bad?  And if people follow a law, does that make it good?


People obviously should not distribute buggy messes, at least not 
without warning.  Were you using the library with an unsupported 
version?  Or inform the author or distributor?


Flexibility is great until the learning curve comes into play. That 
said,
there is an easy fix for tab misuse: in Visual Studio Code, you can 
replace

all Tabs with Spaces by highlighting the entire code block, hitting Tab
once and Shift-Tab after.


IDLE does that also.




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

Re: Python indentation (3 spaces)

On Mon, Oct 8, 2018 at 9:46 AM Gene Heskett  wrote:
>
> On Sunday 07 October 2018 18:29:21 Chris Angelico wrote:
>
> > On Mon, Oct 8, 2018 at 9:26 AM Gene Heskett 
> wrote:
> > > On Sunday 07 October 2018 17:36:34 Chris Angelico wrote:
> > > > On Mon, Oct 8, 2018 at 8:27 AM Gene Heskett 
> > >
> > > wrote:
> > > [...]>
> > >
> > > > Okay, but I'm trying to understand why you're referencing this in
> > > > this thread about indentation. That would imply that you at least
> > > > have reason to suspect that the problem is indentation.
> > > >
> > > > ChrisA
> > >
> > > Grasping at straws ChrisA.  And anything that will reach out and
> > > slap me around when it see's a syntax problem might accidentally
> > > teach me something about this snake.
> >
> > Ah. Fair enough, then. Basically, you want the Python equivalent of
> > "gcc -Wall -Wpedantic".
> >
> Is there such a critter?

Not really; there's -Wall, of course, but it's not nearly as
comprehensive as gcc's pedantic mode. Sorry.

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

Re: Python indentation (3 spaces)

On Sunday 07 October 2018 18:29:21 Chris Angelico wrote:

> On Mon, Oct 8, 2018 at 9:26 AM Gene Heskett  
wrote:
> > On Sunday 07 October 2018 17:36:34 Chris Angelico wrote:
> > > On Mon, Oct 8, 2018 at 8:27 AM Gene Heskett 
> >
> > wrote:
> > [...]>
> >
> > > Okay, but I'm trying to understand why you're referencing this in
> > > this thread about indentation. That would imply that you at least
> > > have reason to suspect that the problem is indentation.
> > >
> > > ChrisA
> >
> > Grasping at straws ChrisA.  And anything that will reach out and
> > slap me around when it see's a syntax problem might accidentally
> > teach me something about this snake.
>
> Ah. Fair enough, then. Basically, you want the Python equivalent of
> "gcc -Wall -Wpedantic".
>
Is there such a critter?

> ChrisA



-- 
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: Python indentation (3 spaces)

On Mon, Oct 8, 2018 at 9:26 AM Gene Heskett  wrote:
>
> On Sunday 07 October 2018 17:36:34 Chris Angelico wrote:
>
> > On Mon, Oct 8, 2018 at 8:27 AM Gene Heskett 
> wrote:
> [...]>
> > Okay, but I'm trying to understand why you're referencing this in this
> > thread about indentation. That would imply that you at least have
> > reason to suspect that the problem is indentation.
> >
> > ChrisA
>
> Grasping at straws ChrisA.  And anything that will reach out and slap me
> around when it see's a syntax problem might accidentally teach me
> something about this snake.
>

Ah. Fair enough, then. Basically, you want the Python equivalent of
"gcc -Wall -Wpedantic".

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

Re: Python indentation (3 spaces)

On Sunday 07 October 2018 17:36:34 Chris Angelico wrote:

> On Mon, Oct 8, 2018 at 8:27 AM Gene Heskett  
wrote:
[...]>
> Okay, but I'm trying to understand why you're referencing this in this
> thread about indentation. That would imply that you at least have
> reason to suspect that the problem is indentation.
>
> ChrisA

Grasping at straws ChrisA.  And anything that will reach out and slap me 
around when it see's a syntax problem might accidentally teach me 
something about this snake.

-- 
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: Python indentation (3 spaces)

2018-10-07 Thread Bev in TX


> On Oct 7, 2018, at 4:30 PM, Gene Heskett  wrote:
> 
>> Free for Linux, Macs and Windows ...
>> https://code.visualstudio.com/Download 
>> 
>> > >
>> 
>> Bev in TX
> 
> Thank you for the url. Downloaded, but not installed on the target 
> machine yet.
Don’t forget to read the license agreement — the link is at the bottom of that 
webpage. 
Bev in TX




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

Re: Python indentation (3 spaces)

On Mon, Oct 8, 2018 at 8:27 AM Gene Heskett  wrote:
>
> On Sunday 07 October 2018 14:30:04 Chris Angelico wrote:
>
> > On Mon, Oct 8, 2018 at 5:20 AM Gene Heskett 
> wrote:
> > > This poster is 200% correct. Somewhere, someplace, there should be
> > > easily found rule that dictates where one can use a tab, and where
> > > spaces only are allowed.
> >
> > Ask the people who maintain makefiles whether that's a good thing or
> > not. HINT: Many will say no.
> >
> > > > > That
> > > > > said, there is an easy fix for tab misuse: in Visual Studio
> > > > > Code, you can replace all Tabs with Spaces by highlighting the
> > > > > entire code block, hitting Tab once and Shift-Tab after.
> > >
> > > But that automatically assumes one is running in a windows
> > > environment. I don't allow it on the premises if I own the machine.
> > > Are there good, alternatives that run on linux?
> >
> > VSCode runs on Linux. Also, there are easy ways to do the same sort of
> > thing in many editors that I've used.
> >
> > > > IDLE does that also.
> > >
> > > And idle for python-2.7 runs on linux.
> >
> > (Not sure why you specifically say 2.7, as IDLE for any version of
> > Python runs on Linux, far as I know.)
> >
> 3.5+ has not, and never will arrive on wheezy. We've a stretch based lcnc
> installer now, but I've got stretch on 2 machines now, and I'm not
> impressed. Making networking actually work makes work a 4 letter word.

Wheezy is no longer supported by Debian. It's not even oldstable any
more. But if you still have old releases sitting around, you have two
good options:

1) Use IDLE from CPython 3.2 by installing package idle3
2) Compile CPython 3.5+ from source

But if you have issues with networking on Stretch, just uninstall
Network Manager and try again. I've been using Stretch since before it
was stable, and have not a whit of trouble. All my family use either
Debian or Ubuntu (including the not-so-technically-literate ones), and
those on Debian are mostly on Stretch. That includes laptops that
connect to various different wifi networks, the routers/gateways that
drive the networks themselves, everyone's desktop computers... the
works.

Also, that *still* has nothing to do with the matter at hand. There's
no problems running some version of IDLE on any release of Debian that
I've ever used.

> > I don't understand what any of this has to do with anything. Do you
> > suspect that your code is fraught with indentation bugs?
>
> Not sure where the problem is Chris, but A: its not my code, and B: a
> potentially very useful machine vision utility to a cnc machinist
> actually works like the teats on a boar hog. Useless if it cannot be
> actually used on a daily basis. I've tried to make it work with pyvcp,
> and with gladevcp. Essentially the same errors (none reported) and
> behavior on both gui interfaces. With 3 different cameras. That, in 3
> versions of it, is the main reason I've been mostly lurking on this list
> for several years.

Okay, but I'm trying to understand why you're referencing this in this
thread about indentation. That would imply that you at least have
reason to suspect that the problem is indentation.

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

Re: Python indentation (3 spaces)

On Sunday 07 October 2018 14:30:07 Bev in TX wrote:

> > On Oct 7, 2018, at 1:19 PM, Gene Heskett  
wrote:
> >>> That
> >>> said, there is an easy fix for tab misuse: in Visual Studio Code,
> >>> you can replace all Tabs with Spaces by highlighting the entire
> >>> code block, hitting Tab once and Shift-Tab after.
> >
> > But that automatically assumes one is running in a windows
> > environment. I don't allow it on the premises if I own the machine.
> > Are there good, alternatives that run on linux?
>
> Free for Linux, Macs and Windows ...
> https://code.visualstudio.com/Download
> 
>
> Bev in TX

Thank you for the url. Downloaded, but not installed on the target 
machine yet.

-- 
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: Python indentation (3 spaces)

On Sunday 07 October 2018 14:30:04 Chris Angelico wrote:

> On Mon, Oct 8, 2018 at 5:20 AM Gene Heskett  
wrote:
> > This poster is 200% correct. Somewhere, someplace, there should be
> > easily found rule that dictates where one can use a tab, and where
> > spaces only are allowed.
>
> Ask the people who maintain makefiles whether that's a good thing or
> not. HINT: Many will say no.
>
> > > > That
> > > > said, there is an easy fix for tab misuse: in Visual Studio
> > > > Code, you can replace all Tabs with Spaces by highlighting the
> > > > entire code block, hitting Tab once and Shift-Tab after.
> >
> > But that automatically assumes one is running in a windows
> > environment. I don't allow it on the premises if I own the machine.
> > Are there good, alternatives that run on linux?
>
> VSCode runs on Linux. Also, there are easy ways to do the same sort of
> thing in many editors that I've used.
>
> > > IDLE does that also.
> >
> > And idle for python-2.7 runs on linux.
>
> (Not sure why you specifically say 2.7, as IDLE for any version of
> Python runs on Linux, far as I know.)
>
3.5+ has not, and never will arrive on wheezy. We've a stretch based lcnc 
installer now, but I've got stretch on 2 machines now, and I'm not 
impressed. Making networking actually work makes work a 4 letter word.

> > We have a mostly python app called
> > camview that runs on and with LinuxCNC. Giving us the ability to
> > mark a feature on a workpiece, and create a set of co-ordinates that
> > autoaligns the workpiece and a about to be carved code. But with a
> > 640x480 camera, the view dies if the display window its given is
> > equal to or larger, at which point it dies/goes away, whatever, and
> > the only way to restore it to operational status is to reboot the
> > machine.
> >
> > I've installed idle on that particular machine, and will see if it
> > will call my attention to bad coding. I'll be most appreciative if
> > it can find something that will make this code Just Work(TM).  Thank
> > you for mentioning it, Terry.
>
> I don't understand what any of this has to do with anything. Do you
> suspect that your code is fraught with indentation bugs?

Not sure where the problem is Chris, but A: its not my code, and B: a 
potentially very useful machine vision utility to a cnc machinist 
actually works like the teats on a boar hog. Useless if it cannot be 
actually used on a daily basis. I've tried to make it work with pyvcp, 
and with gladevcp. Essentially the same errors (none reported) and 
behavior on both gui interfaces. With 3 different cameras. That, in 3 
versions of it, is the main reason I've been mostly lurking on this list 
for several years.

> If so, pretty 
> much ANY Python-aware editor will help you, as will Python 3.x, as
> will Python2 with the "-tt" option.
>
> ChrisA

Thanks ChrisA.

-- 
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: Python indentation (3 spaces)

On Mon, Oct 8, 2018 at 5:39 AM Ryan Johnson  wrote:
>
> > What library? From where?
>
> It was a GitHub repository for a zebra scanner (barcode scanner) module (and 
> sorry for calling it a library; I don’t recall if it was a library or module).
>
> The logic is that all the text editors that are designed to work with Python 
> code will KNOW to replace tab input with 3 characters, while still parsing 
> the \t tab character as 4 characters; while the editors that aren’t made for 
> python input are generally older or non-coding text editors that maintain the 
> older Tab convention that looks like 4 spaces, so it is visually 
> distinguishable, when loading code that a person made on one of these 
> non-python-aware text editors.
>
> The difference we want to see is that Python-aware creates 3 spaces from the 
> keyboard, while still displaying 4 spaces on parsing \t . If this becomes a 
> coding convention for Python, it’ll be enforced by editors that are intended 
> to be used with Python (i.e. the ones that currently replace `Tab` keyboard 
> input with 4 characters).
>

So why not just have them display differently from each other? Or
have an editor that notices when a line disagrees with the one above
it, and highlights that as an error?

> It’s slick. And annoying, because every OCD person in the room is going to 
> choke when they see 3 characters for a tab.

Ahh, yes. The "annoy everyone until they do what you want" technique.
Remind me why the language should mandate that editors annoy their
users?

> > If someone violates a law, does that make the law bad? And if people follow 
> > a law, does that make it good?
>
> No, the question you should ask is “if the current law causes an unintended 
> ambiguity or side-effect, could there be a more clear law that makes the 
> ambiguity go away?” Clearly the current law wasn’t up to the task of 
> delineating 1: bad code from a bad editor opened in a good editor, and 2: 
> good code from a good editor opened in a good editor or bad editor.
>

Only if you're using bad code from a bad editor in a different bad
editor. Lots of good editors will correctly differentiate.

> If I was less than accurate in my explanation, I apologize, but the concept 
> itself is solid, except for the annoyance of being an odd number of spaces.
>

Your explanation is fine. Your concept is internally consistent. I
strongly disagree with it. :)

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

RE: Python indentation (3 spaces)

2018-10-07 Thread Ryan Johnson

> What library? From where?

It was a GitHub repository for a zebra scanner (barcode scanner) module (and 
sorry for calling it a library; I don’t recall if it was a library or module).

The logic is that all the text editors that are designed to work with Python 
code will KNOW to replace tab input with 3 characters, while still parsing the 
\t tab character as 4 characters; while the editors that aren’t made for python 
input are generally older or non-coding text editors that maintain the older 
Tab convention that looks like 4 spaces, so it is visually distinguishable, 
when loading code that a person made on one of these non-python-aware text 
editors.

The difference we want to see is that Python-aware creates 3 spaces from the 
keyboard, while still displaying 4 spaces on parsing \t . If this becomes a 
coding convention for Python, it’ll be enforced by editors that are intended to 
be used with Python (i.e. the ones that currently replace `Tab` keyboard input 
with 4 characters).

It’s slick. And annoying, because every OCD person in the room is going to 
choke when they see 3 characters for a tab.

> If someone violates a law, does that make the law bad? And if people follow a 
> law, does that make it good?

No, the question you should ask is “if the current law causes an unintended 
ambiguity or side-effect, could there be a more clear law that makes the 
ambiguity go away?” Clearly the current law wasn’t up to the task of 
delineating 1: bad code from a bad editor opened in a good editor, and 2: good 
code from a good editor opened in a good editor or bad editor.

The distinction can be made known to the good programmer by having the good 
editors follow a convention that makes the difference evident, while a bad 
editor continues to show no distinction between good and bad code. Remember, 
the primary rule is that a good editor will obviously not permit a bad coder to 
type bad spacing, but a bad editor will.

This convention change would allow a person using a good editor to know that 
the code was made in a non-python-oriented editor immediately, instead of 
blowing up their debug console with Syntax errors.

If I was less than accurate in my explanation, I apologize, but the concept 
itself is solid, except for the annoyance of being an odd number of spaces.

Sent from Mail for Windows 10

From: Terry Reedy
Sent: Sunday, October 7, 2018 10:35 AM
To: python-list@python.org
Subject: Re: Python indentation (3 spaces)

On 10/5/2018 11:30 PM, Ryan Johnson wrote:
> The point that OP is trying to make is that a fixed standard that is
> distinguishable from the even-spacing Tab-length convention in code and
> text editors will establish a level of trust between the end developer and
> upstream developers or co-developers who may not have the same development
> environment.

And my counter point is that a) we will not change the standard and b) 
we deliver an editor that by default enforces the standard, and c) to be 
fair, many other editors will do the same.

> For example, the first Python library I ever tried to use was

What library?  From where?

> poorly maintained and had spaces on one line with tabs on the next, and the
> author mixed naming conventions and syntax from Python 2 and 3 in his code.
> That type of experience doesn’t exactly instill trust in the coding
> language’s standards, when a noob tries to use a library they found and
> ends up having to debug weird errors with weirder error messages on the
> first project they do.

I don't follow the logic.  If someone violates a law, does that make the 
law bad?  And if people follow a law, does that make it good?

People obviously should not distribute buggy messes, at least not 
without warning.  Were you using the library with an unsupported 
version?  Or inform the author or distributor?

> Flexibility is great until the learning curve comes into play. That said,
> there is an easy fix for tab misuse: in Visual Studio Code, you can replace
> all Tabs with Spaces by highlighting the entire code block, hitting Tab
> once and Shift-Tab after.

IDLE does that also.

-- 
Terry Jan Reedy

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

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

Re: Python indentation (3 spaces)

On Mon, Oct 8, 2018 at 5:20 AM Gene Heskett  wrote:
> This poster is 200% correct. Somewhere, someplace, there should be easily
> found rule that dictates where one can use a tab, and where spaces only
> are allowed.

Ask the people who maintain makefiles whether that's a good thing or
not. HINT: Many will say no.

> > > That
> > > said, there is an easy fix for tab misuse: in Visual Studio Code,
> > > you can replace all Tabs with Spaces by highlighting the entire code
> > > block, hitting Tab once and Shift-Tab after.
>
> But that automatically assumes one is running in a windows environment. I
> don't allow it on the premises if I own the machine. Are there good,
> alternatives that run on linux?

VSCode runs on Linux. Also, there are easy ways to do the same sort of
thing in many editors that I've used.

> > IDLE does that also.
> >
> And idle for python-2.7 runs on linux.

(Not sure why you specifically say 2.7, as IDLE for any version of
Python runs on Linux, far as I know.)

> We have a mostly python app called
> camview that runs on and with LinuxCNC. Giving us the ability to mark a
> feature on a workpiece, and create a set of co-ordinates that autoaligns
> the workpiece and a about to be carved code. But with a 640x480 camera,
> the view dies if the display window its given is equal to or larger, at
> which point it dies/goes away, whatever, and the only way to restore it
> to operational status is to reboot the machine.
>
> I've installed idle on that particular machine, and will see if it will
> call my attention to bad coding. I'll be most appreciative if it can
> find something that will make this code Just Work(TM).  Thank you for
> mentioning it, Terry.

I don't understand what any of this has to do with anything. Do you
suspect that your code is fraught with indentation bugs? If so, pretty
much ANY Python-aware editor will help you, as will Python 3.x, as
will Python2 with the "-tt" option.

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

Re: Python indentation (3 spaces)

2018-10-07 Thread Bev in TX



> On Oct 7, 2018, at 1:19 PM, Gene Heskett  wrote:
> 
>>> 
>>> That 
>>> said, there is an easy fix for tab misuse: in Visual Studio Code,
>>> you can replace all Tabs with Spaces by highlighting the entire code
>>> block, hitting Tab once and Shift-Tab after.
> 
> But that automatically assumes one is running in a windows environment. I 
> don't allow it on the premises if I own the machine. Are there good, 
> alternatives that run on linux?
> 

Free for Linux, Macs and Windows ...
https://code.visualstudio.com/Download 

Bev in TX




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

Re: Python indentation (3 spaces)

On Sunday 07 October 2018 11:32:21 Terry Reedy wrote:

> On 10/5/2018 11:30 PM, Ryan Johnson wrote:
> > The point that OP is trying to make is that a fixed standard that is
> > distinguishable from the even-spacing Tab-length convention in code
> > and text editors will establish a level of trust between the end
> > developer and upstream developers or co-developers who may not have
> > the same development environment.
>
> And my counter point is that a) we will not change the standard and b)
> we deliver an editor that by default enforces the standard, and c) to
> be fair, many other editors will do the same.
>
> > For example, the first Python library I ever tried to use was
>
> What library?  From where?
>
Don't recall, or care.

> > poorly maintained and had spaces on one line with tabs on the next,
> > and the author mixed naming conventions and syntax from Python 2 and
> > 3 in his code. That type of experience doesn’t exactly instill trust
> > in the coding language’s standards, when a noob tries to use a
> > library they found and ends up having to debug weird errors with
> > weirder error messages on the first project they do.

This poster is 200% correct. Somewhere, someplace, there should be easily 
found rule that dictates where one can use a tab, and where spaces only 
are allowed.

> I don't follow the logic.  If someone violates a law, does that make
> the law bad?  And if people follow a law, does that make it good?

No, and I'll give you the USA's present state of "democracy" as a prime 
example.
>
> People obviously should not distribute buggy messes, at least not
> without warning.  Were you using the library with an unsupported
> version?  Or inform the author or distributor?
>
> > Flexibility is great until the learning curve comes into play.

Understatement of the month, Terry.

> > That 
> > said, there is an easy fix for tab misuse: in Visual Studio Code,
> > you can replace all Tabs with Spaces by highlighting the entire code
> > block, hitting Tab once and Shift-Tab after.

But that automatically assumes one is running in a windows environment. I 
don't allow it on the premises if I own the machine. Are there good, 
alternatives that run on linux?
>
> IDLE does that also.
>
And idle for python-2.7 runs on linux. We have a mostly python app called 
camview that runs on and with LinuxCNC. Giving us the ability to mark a 
feature on a workpiece, and create a set of co-ordinates that autoaligns 
the workpiece and a about to be carved code. But with a 640x480 camera, 
the view dies if the display window its given is equal to or larger, at 
which point it dies/goes away, whatever, and the only way to restore it 
to operational status is to reboot the machine.

I've installed idle on that particular machine, and will see if it will 
call my attention to bad coding. I'll be most appreciative if it can 
find something that will make this code Just Work(TM).  Thank you for 
mentioning it, Terry.

> --
> Terry Jan Reedy



-- 
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: Python indentation (3 spaces)

On 10/5/2018 4:48 PM, ts9...@gmail.com wrote:

You assumption that a tab means '4 spaces' is wrong. A tab means 'jump
to the next tab stop'. On 10 char/inch US typewriters, tab stops were
initially set to every 5 spaces or 1/2 inch. In terminals and code
editors, virtual tab stops were often set to every 8 spaces, and python
still interprets tabs that way.

This means that editing Python code in an editor that *displays* tabs
(as opposed to converting them to spaces) with other than every-8-space
tab stops is arguably a bad idea if the file has or might have non-tab
space indents.

By making the standard indent 4 spaces, Python already partly did what
you want. The following code is a SyntaxError in both 2.7 and 3.x.

if 1:
a = 1 # 4 space indent
b = 2 # 1 tab indent, which may or may not display as 8 spaces

In 3.x, the following raises
TabError: inconsistent use of tabs and spaces in indentation

if 1:
if 2: # 4 space indent
b = 2 1 tab indent

In 2.x, this runs, but if you run it from IDLE, you get a message
suggesting that you change the tab to spaces and telling you how to do
so. This is because IDLE runs your code through the tabnanny script,
which has the check later incorporated in compile in 3.x. One can also
just check one's code without running it.

In other words, it is easy to expose indent issues without changing the
4 space standard.

Terry Jan Reedy

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

Re: Python indentation (3 spaces)


On 10/5/2018 11:30 PM, Ryan Johnson wrote:

The point that OP is trying to make is that a fixed standard that is
distinguishable from the even-spacing Tab-length convention in code and
text editors will establish a level of trust between the end developer and
upstream developers or co-developers who may not have the same development
environment.


And my counter point is that a) we will not change the standard and b) 
we deliver an editor that by default enforces the standard, and c) to be 
fair, many other editors will do the same.



For example, the first Python library I ever tried to use was


What library?  From where?


poorly maintained and had spaces on one line with tabs on the next, and the
author mixed naming conventions and syntax from Python 2 and 3 in his code.
That type of experience doesn’t exactly instill trust in the coding
language’s standards, when a noob tries to use a library they found and
ends up having to debug weird errors with weirder error messages on the
first project they do.


I don't follow the logic.  If someone violates a law, does that make the 
law bad?  And if people follow a law, does that make it good?


People obviously should not distribute buggy messes, at least not 
without warning.  Were you using the library with an unsupported 
version?  Or inform the author or distributor?



Flexibility is great until the learning curve comes into play. That said,
there is an easy fix for tab misuse: in Visual Studio Code, you can replace
all Tabs with Spaces by highlighting the entire code block, hitting Tab
once and Shift-Tab after.


IDLE does that also.

--
Terry Jan Reedy


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

Re: Python indentation (3 spaces)