Python indentation (correct behaviour) (was: Python indentation (3 spaces))

2018-10-08 Thread Ben Finney
Cameron Simpson  writes:

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

For Vim: https://github.com/nathanaelkane/vim-indent-guides>.
For Emacs: https://github.com/antonj/Highlight-Indentation-for-Emacs>

The latter is used by default in Elpy, an excellent Python development
suite https://elpy.readthedocs.io/>.

-- 
 \   “When a well-packaged web of lies has been sold to the masses |
  `\over generations, the truth will seem utterly preposterous and |
_o__)its speaker a raving lunatic.” —Dresden James |
Ben Finney

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

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
[email protected]://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 (correct behaviour) (was: Python indentation (3 spaces))

2018-10-08 Thread Cameron Simpson

On 08Oct2018 18:06, Ben Finney  wrote:

Cameron Simpson  writes:

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.


For Vim: https://github.com/nathanaelkane/vim-indent-guides>.
For Emacs: https://github.com/antonj/Highlight-Indentation-for-Emacs>

The latter is used by default in Elpy, an excellent Python development
suite https://elpy.readthedocs.io/>.


Thank you!

- Cameron
--
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, [email protected] 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: kivy [quick report]

2018-10-08 Thread m
W dniu 05.10.2018 o 18:43, Stefan Ram pisze:
>   BTW: For Android, there is a "Bulldozer" (or some such) that
>   can create an APK. I wonder what the best way to package one's
>   kivy program to distribute it to Windows users?

I use wine + pyinstaller.

regards

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


Re: Python indentation (correct behaviour) (was: Python indentation (3 spaces))

2018-10-08 Thread Peter J. Holzer
On 2018-10-08 18:06:51 +1100, Ben Finney wrote:
> Cameron Simpson  writes:
> > 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.
> 
> For Vim: https://github.com/nathanaelkane/vim-indent-guides>.

Nice.

hp

-- 
   _  | Peter J. Holzer| we build much bigger, better disasters now
|_|_) || because we have much more sophisticated
| |   | [email protected] | 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 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
| |   | [email protected] | 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 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 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: Observations on the List - "Be More Kind"

2018-10-08 Thread Rhodri James

On 05/10/18 11:22, Bruce Coram wrote:
The level of vitriol and personal attacks on the moderators was 
profoundly disappointing, but not totally out of character for those who 
made the attacks.  There is no doubt that these people know software and 
Python and this certainly earns my respect,  but perhaps they need to 
retain a sense of perspective.  There are 7 billion people in the 
world.  There are plenty more people at least as good as you and many 
better, but they don't have the compelling urge to demonstrate their 
genius.  They get on with their work in a quiet professional manner.


Speaking as one of the people who have been vocally unimpressed with the 
moderators of late, I'd personally appreciate something a little more 
specific than "not totally out of character".  Because actually it *is* 
out of character for me to be confrontational.


I appreciate that the moderators are volunteers, but they have official 
power on this list.  Being volunteers doesn't mean that they can't get 
it wrong, or that we shouldn't call them on it when they do.  They have 
got things wrong, and I have called them on it.  The response has 
been... I'm trying not to say "patronising" because I'm fairly sure it 
wasn't meant that way, but "I'm sorry you feel that way" made me feel 
patronised.  It certainly didn't (and doesn't) make me feel that my 
outright anger at their actions has been considered with any degree of 
seriousness.  Unsurprisingly that doesn't lead to me taking them 
seriously any more.  The formal language only makes me take them less 
seriously.


I don't know what else to say to you.  With one or maybe two exceptions, 
I haven't seen anything that is even close to qualifying as vitriol. 
Much of what has been said could be cast as personal attacks, but that 
is true of almost any confrontation, especially where abuse of power is 
or may be involved.  (Oh, and posting a thumbnail character 
assassination of someone who isn't allowed to post in their defense is 
hardly blameless behaviour, by the way.)  Flatly, I do not see what you 
see.  I'm open to persuasion, but I'll say up front I don't expect you 
to succeed.


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


Encounter issues to install Python

2018-10-08 Thread Olivier Oussou via Python-list
Hi!I downloaded and installed python 3.6.4 (32-bit) on my computer but I have 
problems and can not access the python interface.
I need your technical assistance to solve this matter. 

Best regard!

Olivier OUSSOUMedical entomologist, Benin
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: Observations on the List - "Be More Kind"

2018-10-08 Thread Ethan Furman

On 10/08/2018 07:43 AM, Rhodri James wrote:

I appreciate that the moderators are volunteers, but they have official 
power on this list.  Being volunteers doesn't mean that they can't get 
it wrong, or that we shouldn't call them on it when they do.


I completely agree.


They have got things wrong,


I completely disagree.


and I have called them on it.


Yes, you and a few others -- and nobody has actually talked (emailed) us 
directly, but rather talked *about* us on the list [1].


The response has 
been... I'm trying not to say "patronising" because I'm fairly sure it 
wasn't meant that way, but "I'm sorry you feel that way" made me feel 
patronised.


You're right, I didn't mean it that way, and I apologize.

To briefly explain our decisions of late:

Suspending D'Aprano:
---
His public post to me was shared with several people, including 
moderators of others lists, and it was unanimously agreed that his post 
was completely unacceptable and a two month suspension was appropriate. 
I restarted that suspension because, according to his own words, "I am 
ignoring the ban in this instance"; had he emailed me privately I would 
have correctly posted the notice to the list; had he not said that and 
just posted I would have fixed the filter and left the suspension alone 
(he posts from comp.lang.python).


Suspending Mark Lawrence:

He has a history of posting attacks.  I sent him a private warning, he 
responded a couple days later with another attack.


Suspending BartC:

Many, if not most, of his posts' primary relation to Python was how his 
personal language was better.  The resulting threads seemed to be 
largely unfriendly, unproductive, and unnecessary.


Banning Rick Johnson:

Hopefully no explanation needed [2].

Shutting down threads:
-
There is a problem with threads getting heated and people not exercising 
self-control and posting inappropriately.  That makes the list 
unwelcoming.  As soon as we feel that that is happening we are going to 
shut down the thread.  Personal attacks and name-calling are not 
appropriate and will not be tolerated.  The goal is not to shut down 
debate -- as long as the debate stays civil it will get no moderation 
action.  If a thread is shut down and you feel there is more to be 
(civilly) said -- wait a couple days so everyone can cool off, and then 
start a new thread.


Hopefully you now agree with our decisions, or at least support us in 
them.  If you don't, I actually am sorry -- I would much rather have 
your support (and everyone's).  Either way, we are not changing our 
minds about them.


--
~Ethan~
Python List Moderator



[1] Please correct me if I'm wrong.

[2] If one is needed: his posts can contain profanity, personal attacks, 
condescension, and completely inappropriate language.

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


How to use Python's built-in Logging with Asyncio (Permission Error)

2018-10-08 Thread liamhanninen
>From the logging docs I found out there was another avenue (comp.lang.python) 
>to ask questions about it. I already posted to stackoverflow but if anyone 
>could help out here or via stackoverflow I would greatly appreciate it. Here 
>is the link to my question:

https://stackoverflow.com/questions/52708756/how-to-use-pythons-built-in-logging-with-asyncio-permission-error
-- 
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 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: How to use Python's built-in Logging with Asyncio (Permission Error)

2018-10-08 Thread Ian Kelly
I'm spit-balling here, but I suspect the problem is that
TimedRotatingFileHandler was probably not designed to have multiple
instances of it in different processes all trying to rotate the same
file. Yet that's the situation you have since each subprocess in your
process pool creates its own handler instance.

I've not used it myself, but I believe that this is effectively the
problem that QueueHandler and QueueListener were created to solve:
https://docs.python.org/3.7/library/logging.handlers.html#queuehandler

The parent process should create a queue and a QueueListener to
service that queue, using the TimedRotatingFileHandler. Each
subprocess should log to the queue using QueueHandler instead. This
way the actual log file is only handled by one process.
On Mon, Oct 8, 2018 at 1:54 PM  wrote:
>
> From the logging docs I found out there was another avenue (comp.lang.python) 
> to ask questions about it. I already posted to stackoverflow but if anyone 
> could help out here or via stackoverflow I would greatly appreciate it. Here 
> is the link to my question:
>
> https://stackoverflow.com/questions/52708756/how-to-use-pythons-built-in-logging-with-asyncio-permission-error
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
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 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


My python code has suddenly started to give me error. Please see code below**

2018-10-08 Thread upadhyay . kamayani


## Calculating the Lower Limits(LLi) and Upper Limit(ULi) for each Band, where 
i is 1,2,.10
LL1=0
print(LL1)

print(P2)
print(D2)

if(P2>25):
UL1=D1
print(UL1)

elif(UL1==D2):
print(UL1)

LL2=UL1

if(P3>25):
UL2=D2
print(UL2)

elif(UL2==D3):
print(UL2)

LL3=UL2

if(P4>25):
UL3=D3
print(UL3)

elif(UL3==D4):
print(UL3)
 

LL4=UL3

if(P5>25):
UL4=D4
print(UL4)

elif(UL4==D5):
print(UL4)

LL5=UL4

if(P6>25):
UL5=D5
print(UL5)

elif(UL5==D6):
print(UL5)

LL6=UL5

if(P7>25):
UL6=D6
print(UL6)

elif(UL6==D7):
print(UL6)

LL7=UL6

if(P8>25):
UL7=D7
print(UL7)

elif(UL7==D8):
print(UL7)

LL8=UL7

if(P9>25):
UL8=D8
print(UL8)

elif(UL8==D9):
print(UL8)

LL9=UL8

if(P10>25):
UL9=D9
print(UL9)

elif(UL9==D10):
print(UL9)

LL10=UL9
UL10=("& Above")

print(UL10)



**
n1=int(UL1)
count=0
while (n1>0):
count=count+1
n1=n1//10

print(count)

B11=LL1
If((count)/2)==0:
B12=int((UL1)/(10**(count-2)))
B12
elif(B12=int((UL1)/(10**(count-1:
B12
B1=(B11,"-",B12,"M")
B1
-- 
https://mail.python.org/mailman/listinfo/python-list


Re: My python code has suddenly started to give me error. Please see code below**

2018-10-08 Thread Gary Herron
So, tell us the error and we'll see what we can do.  Give us something 
to work with:   Cut and past the full error message, trace back, 
whatever you can.


Also tell us what version of Python, what system you are running on, how 
you run this code, ...




On 10/08/2018 10:17 PM, [email protected] wrote:

## Calculating the Lower Limits(LLi) and Upper Limit(ULi) for each Band, where 
i is 1,2,.10
LL1=0
print(LL1)

print(P2)
print(D2)

if(P2>25):
 UL1=D1
 print(UL1)

elif(UL1==D2):
 print(UL1)
 
LL2=UL1
 
if(P3>25):

 UL2=D2
 print(UL2)

elif(UL2==D3):
 print(UL2)
 
LL3=UL2


if(P4>25):
 UL3=D3
 print(UL3)

elif(UL3==D4):
 print(UL3)
  


LL4=UL3

if(P5>25):
 UL4=D4
 print(UL4)

elif(UL4==D5):
 print(UL4)
 
LL5=UL4


if(P6>25):
 UL5=D5
 print(UL5)

elif(UL5==D6):
 print(UL5)
 
LL6=UL5


if(P7>25):
 UL6=D6
 print(UL6)

elif(UL6==D7):
 print(UL6)
 
LL7=UL6


if(P8>25):
 UL7=D7
 print(UL7)

elif(UL7==D8):
 print(UL7)
 
LL8=UL7


if(P9>25):
 UL8=D8
 print(UL8)

elif(UL8==D9):
 print(UL8)
 
LL9=UL8


if(P10>25):
 UL9=D9
 print(UL9)

elif(UL9==D10):
 print(UL9)
 
LL10=UL9

UL10=("& Above")

print(UL10)



**
n1=int(UL1)
count=0
while (n1>0):
 count=count+1
 n1=n1//10
 
print(count)


B11=LL1
If((count)/2)==0:
B12=int((UL1)/(10**(count-2)))
B12
 elif(B12=int((UL1)/(10**(count-1:
B12
B1=(B11,"-",B12,"M")
B1


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

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