date:20181007


On 10/6/2018 3:47 PM, C W Rose via Python-list wrote:

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. For example, the first Python library I ever tried to use was
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.


The view of the Python Gods (TM) is that significant whitespace make
Python much easier to use, particularly for the inexperienced.


This seems completely irrelevant to Ryan's comment, which was about 
mixing whitespace, not eliminating it.



If you disagree, then use another language.


Given the absence of any complaint about using whitespace, this seems 
rude.  Did you actually read what Ryan wrote?



(Leibnitz had some snappy phrases on the subject of Theodicy, which
explain the matter clearly.)


How it this a response to the Python style question?

--
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)

On 10/5/2018 4:48 PM, 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?"
Thoughts?

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 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)

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 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 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: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)

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 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 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)

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 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)

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 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: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: 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 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: 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)

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 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)