Re: Tkinter long-running window freezes

[MRAB]

On 2021-02-27 02:38, John O'Hagan wrote:

On Sat, 27 Feb 2021 01:06:06 +
MRAB  wrote:


On 2021-02-26 23:59, John O'Hagan wrote:
> On Fri, 26 Feb 2021 08:19:14 +0100
> Christian Gollwitzer  wrote:
>   
>> Am 26.02.21 um 06:15 schrieb John O'Hagan:  
> [...]  
>> > 
>> > I've followed your suggestions as per my last post, and can

>> > confirm the same freezing behaviour when running your code
>> > directly as a tclsh script on Debian Testing, Tcl 8.6.11.
>> 
>> You might report this as a bug to the Tcl bugtracker 
>> https://core.tcl-lang.org/tk/ticket
>> 
>> I guess the problem is with the steady creation of widgets. Tk was

>> not meant to be used like that. Tkinter creates new widget names
>> for each widget with random numbers, just like the Tcl code above
>> does, whereas in a usual Tcl/Tk program the names are given by the
>> programmer.  
> 
> Thanks, I will make the bug report. However, based  on your comments

> above, it looks similar to this one, closed as invalid 16 years ago:
> 
> https://core.tcl-lang.org/tk/tktview/1173484f
> 
> This was also related to memory "creep" caused by Tk's cache of

> names, which AIUI is a Tk design feature (but I don't know Tk!).
>   
>> Can you also check this program, which reuses the same widget path

>> name, albeit does the creation/destruction in cycles:
>> 
>> ==

>> package require Tk
>> 
>> proc randint {} {

>>  expr {int(rand()*1000)}
>> }
>> 
>> proc display {label} {

>>  destroy $label
>>  set label [label .l -text [randint]]
>>  pack $label
>>  after 100 [list display $label]
>> }
>> 
>> display [label .l]

>> 
>>   
> 
> I have tried this overnight and it is still running, not frozen and

> with no apparent increase in memory use. I guess that is likely the
> issue. I don't know Tcl/Tk - is there a way to emulate the above
> approach of re-using the widget name in tkinter?
>   
>> As mentioned by others, typically you wouldn't continuously

>> recreate new widgets, but either update the text of the widget
>> (label['text']="New text") or attaching a StringVar() )
>> 
>> or, if you must rearrange the widgets, you pack_forget() them and

>> then repack them.
>> 
>> 	Christian  
> 
> This is possible of course, but will require more than a repack. In

> my use case, each widget is an attribute of a Python object,
> intended control and display data about that object, and there is an
> indeterminate number of such objects at any given time. I had
> assumed I could just destroy the widget and let the object go out of
> scope to be garbage collected. I'll need to redesign this
> altogether if I can't rely on Tk to manage memory.
> 
> IMHO it's quite surprising if .destroy doesn't free all the

> resources used by a widget!
>   
I've look in Lib\tkinter\__init__.py and it appears that you can give

it a name, so:

from tkinter import *
from random import randint

root = Tk()

def display(label):
  label.destroy()
  label = Label(name='my_label', text=randint(0, 9))
  label.pack()
  root.after(1, display, label)

display(Label(name='my_label'))
mainloop()

When I do that I'm not seeing a memory rise.


I just did the exact same thing, also saw no memory rise, but the
window still froze after a couple of hours. Did your window freeze?
Maybe the memory rise and the freeze are unrelated after all.

Also, I was mistaken about Christian's second version of the Tcl code
above - there is no memory rise but the window also freezes after a
while. Suggests the problem is in Tcl/Tk.

I didn't run it for that long, only long enough to compare it with the 
previous version. (Both were started at the same time.)

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

Re: Tkinter long-running window freezes

[John O'Hagan]

On Sat, 27 Feb 2021 10:59:24 +1100
John O'Hagan  wrote:

> On Fri, 26 Feb 2021 08:19:14 +0100
> Christian Gollwitzer  wrote:
[...]
> 
> > Can you also check this program, which reuses the same widget path
> > name, albeit does the creation/destruction in cycles:
> > 
> > ==
> > package require Tk
> > 
> > proc randint {} {
> >  expr {int(rand()*1000)}
> > }
> > 
> > proc display {label} {
> >  destroy $label
> >  set label [label .l -text [randint]]
> >  pack $label
> >  after 100 [list display $label]
> > }
> > 
> > display [label .l]
> > 
> >   
> 
> I have tried this overnight and it is still running, not frozen and
> with no apparent increase in memory use. 

[...]

Correction! The window did freeze after all, and again on a second
attempt. No memory rise though, so those two issues seem to be
independent.

Thanks

--

John

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

Re: Tkinter long-running window freezes

[John O'Hagan]

On Sat, 27 Feb 2021 01:06:06 +
MRAB  wrote:

> On 2021-02-26 23:59, John O'Hagan wrote:
> > On Fri, 26 Feb 2021 08:19:14 +0100
> > Christian Gollwitzer  wrote:
> >   
> >> Am 26.02.21 um 06:15 schrieb John O'Hagan:  
> > [...]  
> >> > 
> >> > I've followed your suggestions as per my last post, and can
> >> > confirm the same freezing behaviour when running your code
> >> > directly as a tclsh script on Debian Testing, Tcl 8.6.11.
> >> 
> >> You might report this as a bug to the Tcl bugtracker 
> >> https://core.tcl-lang.org/tk/ticket
> >> 
> >> I guess the problem is with the steady creation of widgets. Tk was
> >> not meant to be used like that. Tkinter creates new widget names
> >> for each widget with random numbers, just like the Tcl code above
> >> does, whereas in a usual Tcl/Tk program the names are given by the
> >> programmer.  
> > 
> > Thanks, I will make the bug report. However, based  on your comments
> > above, it looks similar to this one, closed as invalid 16 years ago:
> > 
> > https://core.tcl-lang.org/tk/tktview/1173484f
> > 
> > This was also related to memory "creep" caused by Tk's cache of
> > names, which AIUI is a Tk design feature (but I don't know Tk!).
> >   
> >> Can you also check this program, which reuses the same widget path
> >> name, albeit does the creation/destruction in cycles:
> >> 
> >> ==
> >> package require Tk
> >> 
> >> proc randint {} {
> >>  expr {int(rand()*1000)}
> >> }
> >> 
> >> proc display {label} {
> >>  destroy $label
> >>  set label [label .l -text [randint]]
> >>  pack $label
> >>  after 100 [list display $label]
> >> }
> >> 
> >> display [label .l]
> >> 
> >>   
> > 
> > I have tried this overnight and it is still running, not frozen and
> > with no apparent increase in memory use. I guess that is likely the
> > issue. I don't know Tcl/Tk - is there a way to emulate the above
> > approach of re-using the widget name in tkinter?
> >   
> >> As mentioned by others, typically you wouldn't continuously
> >> recreate new widgets, but either update the text of the widget
> >> (label['text']="New text") or attaching a StringVar() )
> >> 
> >> or, if you must rearrange the widgets, you pack_forget() them and
> >> then repack them.
> >> 
> >>Christian  
> > 
> > This is possible of course, but will require more than a repack. In
> > my use case, each widget is an attribute of a Python object,
> > intended control and display data about that object, and there is an
> > indeterminate number of such objects at any given time. I had
> > assumed I could just destroy the widget and let the object go out of
> > scope to be garbage collected. I'll need to redesign this
> > altogether if I can't rely on Tk to manage memory.
> > 
> > IMHO it's quite surprising if .destroy doesn't free all the
> > resources used by a widget!
> >   
> I've look in Lib\tkinter\__init__.py and it appears that you can give
> it a name, so:
> 
> from tkinter import *
> from random import randint
> 
> root = Tk()
> 
> def display(label):
>   label.destroy()
>   label = Label(name='my_label', text=randint(0, 9))
>   label.pack()
>   root.after(1, display, label)
> 
> display(Label(name='my_label'))
> mainloop()
> 
> When I do that I'm not seeing a memory rise.

I just did the exact same thing, also saw no memory rise, but the
window still froze after a couple of hours. Did your window freeze?
Maybe the memory rise and the freeze are unrelated after all.

Also, I was mistaken about Christian's second version of the Tcl code
above - there is no memory rise but the window also freezes after a
while. Suggests the problem is in Tcl/Tk.

Thanks

--

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

Re: editor recommendations?

[Bob van der Poel]

On Fri, Feb 26, 2021 at 11:24 AM Grant Edwards 
wrote:

> On 2021-02-26, Rich Shepard  wrote:
>
> > Long ago someone wrote that Emacs is an operating system that includes
> the
> > kitchen sink. A friend of mine working for Sharp Electronics did all his
> > work in Emacs, including email and web browsing (back when a text-based
> > browser was sufficient.)
>
> Yep, I worked with somebody who did that. All his command-line shell
> interaction was done in emacs, as well as all his e-mail, Usenet,
> file-system browsing, etc. That was back before web browsing was "a
> thing", but I'm sure he found a way to do that inside emacs also.
>

Of course there is a mode for that:
https://www.emacswiki.org/emacs/CategoryWebBrowser


-- 

 Listen to my FREE CD at http://www.mellowood.ca/music/cedars 
Bob van der Poel ** Wynndel, British Columbia, CANADA **
EMAIL: b...@mellowood.ca
WWW:   http://www.mellowood.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: editor recommendations?

[Grant Edwards]

On 2021-02-26, Rich Shepard  wrote:

> Long ago someone wrote that Emacs is an operating system that includes the
> kitchen sink. A friend of mine working for Sharp Electronics did all his
> work in Emacs, including email and web browsing (back when a text-based
> browser was sufficient.)

Yep, I worked with somebody who did that. All his command-line shell
interaction was done in emacs, as well as all his e-mail, Usenet,
file-system browsing, etc. That was back before web browsing was "a
thing", but I'm sure he found a way to do that inside emacs also.

I pretty much only use emacs for editing text...

-- 
Grant Edwards   grant.b.edwardsYow! Hmmm ... a CRIPPLED
  at   ACCOUNTANT with a FALAFEL
  gmail.comsandwich is HIT by a
   TROLLEY-CAR ...

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

Re: Where is the problem?

[Cousin Stanley]

RD wrote:

> Python 3.4.3 on WinXP.
> 
> I create a Tk canvas and draw on it with create_text(),
> create_line(), and create_polygon with fill and stipple.
> 
> So far, so good, looks fine on the screen.
> 
> So I go to send it to a postsctript file:
> 
> bmap.postscript(file="tmp.ps", colormode='color')
> 
> It generates a file, no errors reported.
> 
> So I open up the file in a PS viewer (2, actually),
> and the saved file looks like someone left a
> watercolor out in the rain.
> 
> Artifacts everywhere, the lines are blurred, and the
> text is unreadable.
> 
> Googling was unhelpful; did I miss something?
> 
> TIA

  I have a couple of postscript saving examples
  that include the following geometry parameters
  which produce  .ps  files that render the same
  as the canvas drawings when viewed in ghostsript.
   
retval = canvas.postscript( 
   file   = "image/ps/xyzzy.ps , 
   height = 400 , 
   width  = 400 ,
   pagewidth  = 400 , 
   pageheight = 400 ,  
   colormode = "color" )

  Perhaps adding the geomerty parameters
  might help.


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: Tkinter long-running window freezes

[MRAB]

On 2021-02-26 23:59, John O'Hagan wrote:

On Fri, 26 Feb 2021 08:19:14 +0100
Christian Gollwitzer  wrote:


Am 26.02.21 um 06:15 schrieb John O'Hagan:

[...]
> 
> I've followed your suggestions as per my last post, and can confirm

> the same freezing behaviour when running your code directly as a
> tclsh script on Debian Testing, Tcl 8.6.11.  

You might report this as a bug to the Tcl bugtracker 
https://core.tcl-lang.org/tk/ticket


I guess the problem is with the steady creation of widgets. Tk was
not meant to be used like that. Tkinter creates new widget names for
each widget with random numbers, just like the Tcl code above does,
whereas in a usual Tcl/Tk program the names are given by the
programmer.


Thanks, I will make the bug report. However, based  on your comments
above, it looks similar to this one, closed as invalid 16 years ago:

https://core.tcl-lang.org/tk/tktview/1173484f

This was also related to memory "creep" caused by Tk's cache of names,
which AIUI is a Tk design feature (but I don't know Tk!).


Can you also check this program, which reuses the same widget path
name, albeit does the creation/destruction in cycles:

==
package require Tk

proc randint {} {
 expr {int(rand()*1000)}
}

proc display {label} {
 destroy $label
 set label [label .l -text [randint]]
 pack $label
 after 100 [list display $label]
}

display [label .l]




I have tried this overnight and it is still running, not frozen and with
no apparent increase in memory use. I guess that is likely the issue. I
don't know Tcl/Tk - is there a way to emulate the above approach of
re-using the widget name in tkinter?


As mentioned by others, typically you wouldn't continuously recreate
new widgets, but either update the text of the widget
(label['text']="New text") or attaching a StringVar() )

or, if you must rearrange the widgets, you pack_forget() them and
then repack them.

Christian


This is possible of course, but will require more than a repack. In my
use case, each widget is an attribute of a Python object, intended
control and display data about that object, and there is an
indeterminate number of such objects at any given time. I had
assumed I could just destroy the widget and let the object go out of
scope to be garbage collected. I'll need to redesign this altogether if
I can't rely on Tk to manage memory.

IMHO it's quite surprising if .destroy doesn't free all the resources
used by a widget!

I've look in Lib\tkinter\__init__.py and it appears that you can give it 
a name, so:


from tkinter import *
from random import randint

root = Tk()

def display(label):
 label.destroy()
 label = Label(name='my_label', text=randint(0, 9))
 label.pack()
 root.after(1, display, label)

display(Label(name='my_label'))
mainloop()

When I do that I'm not seeing a memory rise.
--
https://mail.python.org/mailman/listinfo/python-list

Re: editor recommendations?

[Marco Sulla]

I use Sublime free for simple tasks. I like the fact it's fast and it
saves to disk immediately. You don't have even to name the file. I use
it also for taking notes. Probably not as powerful as Vim and it's
proprietary.
For development, I use PyCharm, but it's an IDE.

I also used in past:
gedit: slow
atom: slow
notepad++: windows only
emacs: too much for my needs
scite: too minimalist
kate: not bad at all
visual studio: resource intensive
eclipse: slow (even if I continue to use it for non-Python coding)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tkinter long-running window freezes

[John O'Hagan]

On Fri, 26 Feb 2021 08:19:14 +0100
Christian Gollwitzer  wrote:

> Am 26.02.21 um 06:15 schrieb John O'Hagan:
[...]
> > 
> > I've followed your suggestions as per my last post, and can confirm
> > the same freezing behaviour when running your code directly as a
> > tclsh script on Debian Testing, Tcl 8.6.11.  
> 
> You might report this as a bug to the Tcl bugtracker 
> https://core.tcl-lang.org/tk/ticket
> 
> I guess the problem is with the steady creation of widgets. Tk was
> not meant to be used like that. Tkinter creates new widget names for
> each widget with random numbers, just like the Tcl code above does,
> whereas in a usual Tcl/Tk program the names are given by the
> programmer.

Thanks, I will make the bug report. However, based  on your comments
above, it looks similar to this one, closed as invalid 16 years ago:

https://core.tcl-lang.org/tk/tktview/1173484f

This was also related to memory "creep" caused by Tk's cache of names,
which AIUI is a Tk design feature (but I don't know Tk!).

> Can you also check this program, which reuses the same widget path
> name, albeit does the creation/destruction in cycles:
> 
> ==
> package require Tk
> 
> proc randint {} {
>  expr {int(rand()*1000)}
> }
> 
> proc display {label} {
>  destroy $label
>  set label [label .l -text [randint]]
>  pack $label
>  after 100 [list display $label]
> }
> 
> display [label .l]
> 
> 

I have tried this overnight and it is still running, not frozen and with
no apparent increase in memory use. I guess that is likely the issue. I
don't know Tcl/Tk - is there a way to emulate the above approach of
re-using the widget name in tkinter? 

> As mentioned by others, typically you wouldn't continuously recreate
> new widgets, but either update the text of the widget
> (label['text']="New text") or attaching a StringVar() )
> 
> or, if you must rearrange the widgets, you pack_forget() them and
> then repack them.
> 
>   Christian

This is possible of course, but will require more than a repack. In my
use case, each widget is an attribute of a Python object, intended
control and display data about that object, and there is an
indeterminate number of such objects at any given time. I had
assumed I could just destroy the widget and let the object go out of
scope to be garbage collected. I'll need to redesign this altogether if
I can't rely on Tk to manage memory.

IMHO it's quite surprising if .destroy doesn't free all the resources
used by a widget!

Thanks

-- 

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

Re: error of opening Python

[Mladen Gogala via Python-list]

On Fri, 26 Feb 2021 02:23:51 -0500, Terry Reedy wrote:


> Not on Windows.  Please don't spew misleading garbage that will only
> confuse the new user on a different operating system.
>

You are right, I apologize. I sort of like poking fun at the Winduhs 
users but this is not the right place.



-- 
Mladen Gogala
Database Consultant
https://dbwhisperer.wordpress.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Tkinter needed as a legacy version 2.7 imports the module...

[MRAB]

On 2021-02-26 22:23, Kevin M. Wilson via Python-list wrote:

Hey Community,    Is there a site where I might/can download a version of 
Tkinter for Python 2.7?


Tkinter as already included in Python 2.7.
--
https://mail.python.org/mailman/listinfo/python-list

Re: editor recommendations?

[inhahe]

My editor of choice is Komodo IDE, which used to be commercialware but is
free now. I'm pretty sure it has dark modes, but I haven't used them. I
just thought I'd mention it because it's a good, solid IDE but I never see
anybody mention it, e.g. in lists of Python editors and such..

On Fri, Feb 26, 2021 at 9:52 AM Ethan Furman  wrote:

> I'm looking for an editor to use for Python programming, as well as
> related incidentals such as markdown files, restructured text, etc.
>
> I'm currently using vim, and the primary reason I've stuck with it for so
> long is because I can get truly black screens with it.  By which I mean
> that I have a colorful window title bar, a light-grey menu bar, and then a
> light-grey frame around the text-editing window (aka the only window), and
> a nice, black-background editing area.
>
> When I have occasionally tried other editors, they either don't support a
> black background, or the black background is only for the text-editing
> portion which leaves large portions of screen real-estate with a bright
> background, which is hard on my eyes.
>
> So, what's the state-of-the-art with regards to editors supporting dark
> color themes?
>
> TIA.
>
> --
> ~Ethan~
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Tkinter needed as a legacy version 2.7 imports the module...

[Kevin M. Wilson via Python-list]

Hey Community,    Is there a site where I might/can download a version of 
Tkinter for Python 2.7?

Seriously, KMW
John 1:4  "In him was life; and the life was the light of men."
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: editor recommendations?

[Thomas Jollans]

On 26/02/2021 15:51, Ethan Furman wrote:
>
> So, what's the state-of-the-art with regards to editors supporting
> dark color themes?

You’re in luck, “Dark Mode” is very much en vogue these days. Most
modern programmer's editors (meaning editors that think of themselves as
modern) are either dark by default or at least come with a fully dark theme.

I mostly use Sublime Text [€€€] myself. Visual Studio Code is pretty
similar, but a fair bit more resource-intensive thanks to being built on
Electron. They're both dark-by-default, fairly configurable and have
communities obsessed with (usually dark) colour schemes. And they both
have loads of plugins which can slow your editor down and give you smart
completion and tooltips with docstrings if you like that sort of thing.
Atom is in the same general category as VS Code.

Spacemacs sounds like it could be fun. ¯\_(ツ)_/¯

- Thomas


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

Re: editor recommendations?

[Cameron Simpson]

On 26Feb2021 06:51, Ethan Furman  wrote:
>I'm looking for an editor to use for Python programming, as well as related 
>incidentals such as markdown files, restructured text, etc.
>
>I'm currently using vim, and the primary reason I've stuck with it for so long 
>is because I can get truly black screens with it.  By which I mean that I have 
>a colorful window title bar, a light-grey menu bar, and then a light-grey 
>frame around the text-editing window (aka the only window), and a nice, 
>black-background editing area.
>
>When I have occasionally tried other editors, they either don't support a 
>black background, or the black background is only for the text-editing portion 
>which leaves large portions of screen real-estate with a bright background, 
>which is hard on my eyes.
>
>So, what's the state-of-the-art with regards to editors supporting dark 
>color themes?

I'm afraid I use vim. My colour schemes come from (a) the terminal 
(often my screen is 100% terminals) and (b) the vim syntax highlighting.  
And I've got an easy-on-the-eyes colouring for the vim pane separator 
characters.

My fingers know vim. Some others' fingers know emacs.

So I mostly get my colours from my terminal setup, which means I have a 
consistent dark theme for most of my activities: editing, shells and 
email (mutt). And I have my terminal panes which don't have the keyboard 
focus slightly dim themselves.

Alas, this does not recommend another editor for you.

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

Re: python 2.6: Need some advise for installing modules on a legacy system

[Thomas Jollans]

On 24/02/2021 14:13, Antoon Pardon wrote:
> I need to do some development on this legacy system. It only runs
> python2.6 and there is little hope of installing an other version. How
> can I best proceed to install modules for working with mysql and ldap?
>

The answer very much depends on the operating system. If it's a Linux
system with a working package manager, chances are most common modules
were packaged by the distribution vendor, and your best bet is probably
to get the RPMs or deb packages from the corresponding package archive.
There usually is one.

Otherwise, as Dan suggested, find the source tar.gz (or zip, or
whatever) file for the last version that supported python 2.6 on the
corresponding project's website or on PyPI and install the packages (and
all their dependencies) using the setup.py scripts. If you're on
Windows, you'll probably need Visual Studio 2008 or at least the Visual
C++ compiler version 9.0 (see
)

That being said, I am curious: if you can install Python modules, why
can't you install a newer Python interpreter? Are you running Windows 2000?

Have fun I guess

Thomas


-- 
Dr. Thomas Jollans

✉ t...@tjol.eu

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

Re: editor recommendations?

[Mats Wichmann]

On 2/26/21 7:51 AM, Ethan Furman wrote:
I'm looking for an editor to use for Python programming, as well as 
related incidentals such as markdown files, restructured text, etc.


I'm currently using vim, and the primary reason I've stuck with it for 
so long is because I can get truly black screens with it.  By which I 
mean that I have a colorful window title bar, a light-grey menu bar, and 
then a light-grey frame around the text-editing window (aka the only 
window), and a nice, black-background editing area.


When I have occasionally tried other editors, they either don't support 
a black background, or the black background is only for the text-editing 
portion which leaves large portions of screen real-estate with a bright 
background, which is hard on my eyes.


So, what's the state-of-the-art with regards to editors supporting dark 
color themes?


Of course this is going to be opinionated.

The editors I've tried don't do dark themes well, every theme seems to 
get something wrong so you're trying to squint to read something in a 
color that doesn't stand out sufficiently, etc., while something else is 
too electric


I've stuck with vi/vim since it was written, but...

PyCharm (I know for sure, probably others have something like this 
concept) has some modes to make some of the stuff you're not actually 
using less... cruddy - it has a "distraction-free mode" and a "zen 
mode".  Just for fun those might be sort of what you're looking for?



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

Re: editor recommendations?

[MRAB]

On 2021-02-26 14:51, Ethan Furman wrote:

I'm looking for an editor to use for Python programming, as well as related 
incidentals such as markdown files, restructured text, etc.

I'm currently using vim, and the primary reason I've stuck with it for so long 
is because I can get truly black screens with it.  By which I mean that I have 
a colorful window title bar, a light-grey menu bar, and then a light-grey frame 
around the text-editing window (aka the only window), and a nice, 
black-background editing area.

When I have occasionally tried other editors, they either don't support a black 
background, or the black background is only for the text-editing portion which 
leaves large portions of screen real-estate with a bright background, which is 
hard on my eyes.

So, what's the state-of-the-art with regards to editors supporting dark color 
themes?


Have you looked at Visual Studio Code?
--
https://mail.python.org/mailman/listinfo/python-list

Re: editor recommendations?

[J. Pic]

On Fri, Feb 26, 2021 at 5:24 PM Rich Shepard 
wrote:

> Perhaps he didn't but he should know that by opening a shell within emacs
> he
> can run his python code there.
>

:term in vim

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

Re: editor recommendations?

[Dan Stromberg]

On Fri, Feb 26, 2021 at 6:51 AM Ethan Furman  wrote:

> I'm looking for an editor to use for Python programming, as well as
> related incidentals such as markdown files, restructured text, etc.
>
> I'm currently using vim, and the primary reason I've stuck with it for so
> long is because I can get truly black screens with it.  By which I mean
> that I have a colorful window title bar, a light-grey menu bar, and then a
> light-grey frame around the text-editing window (aka the only window), and
> a nice, black-background editing area.
>
> When I have occasionally tried other editors, they either don't support a
> black background, or the black background is only for the text-editing
> portion which leaves large portions of screen real-estate with a bright
> background, which is hard on my eyes.
>
> So, what's the state-of-the-art with regards to editors supporting dark
> color themes?
>
I like vim :)

I have it all set up with plugins automatically at
https://stromberg.dnsalias.org/svn/vimrc/trunk/

Just cd'ing to that directory and typing "make" gives me vim with
syntastic, MRU, jedi, etcetera - on Debian based Linuxes and CentOS-like
Linuxes as well.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: editor recommendations?

[Rich Shepard]

On Fri, 26 Feb 2021, 2qdxy4rzwzuui...@potatochowder.com wrote:


That's what my emacs looks like, minus the light-grey frame (the window
manager's frame and border are enough for me). Emacs has themes now, but
my setup is very old; all I did was set the "base" text background and
foreground colors and set a flag that says "I have a dark background
rather than a light one."


Emacs: +1. I've been using it for more than two decades. It will provide
syntax coloring (on the black background) for Python as well as other
languages and file types.


Did you have a Python question?  ;-)


Perhaps he didn't but he should know that by opening a shell within emacs he
can run his python code there.

Long ago someone wrote that Emacs is an operating system that includes the
kitchen sink. A friend of mine working for Sharp Electronics did all his
work in Emacs, including email and web browsing (back when a text-based
browser was sufficient.)

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

Re: editor recommendations?

[2QdxY4RzWzUUiLuE]

On 2021-02-26 at 06:51:02 -0800,
Ethan Furman  wrote:

> [...] vim [...] truly black screens with it.  By which I mean that I
> have a colorful window title bar, a light-grey menu bar, and then a
> light-grey frame around the text-editing window (aka the only window),
> and a nice, black-background editing area.

That's what my emacs looks like, minus the light-grey frame (the window
manager's frame and border are enough for me).  Emacs has themes now,
but my setup is very old; all I did was set the "base" text background
and foreground colors and set a flag that says "I have a dark background
rather than a light one."

Did you have a Python question?  ;-)
-- 
https://mail.python.org/mailman/listinfo/python-list

editor recommendations?

[Ethan Furman]

I'm looking for an editor to use for Python programming, as well as related 
incidentals such as markdown files, restructured text, etc.

I'm currently using vim, and the primary reason I've stuck with it for so long 
is because I can get truly black screens with it.  By which I mean that I have 
a colorful window title bar, a light-grey menu bar, and then a light-grey frame 
around the text-editing window (aka the only window), and a nice, 
black-background editing area.

When I have occasionally tried other editors, they either don't support a black 
background, or the black background is only for the text-editing portion which 
leaves large portions of screen real-estate with a bright background, which is 
hard on my eyes.

So, what's the state-of-the-art with regards to editors supporting dark color 
themes?

TIA.

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

Re: name for a mutually inclusive relationship

[Alan Gauld via Python-list]

On 26/02/2021 04:30, Ethan Furman wrote:

>> Do you have a specific problem you're trying to solve?
> 
> No, I just came across the concept in my browsing and 
> was wondering if there was a name for it.  

If we stick with boolean values (like radio buttons
and checkboxes) then I think the name is "equality"

A  BResult
--
0  0  1
0  1  0
1  0  0
1  1  1

So you determine "success" by whether all
inputs are equal. (Or as somebody else
said "not xor")

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


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

Re: error of opening Python

[Terry Reedy]

On 2/26/2021 12:55 AM, Mladen Gogala via Python-list wrote:

On Thu, 25 Feb 2021 17:22:35 +, Botao Liu wrote:


Dear Python team,

This is my first time using Python, I tried to launch Python and it
showed "Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC
v.1928 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or
"license" for more information." I don't know what this meant and how to
fix this. Could you please help me? Thank you very much.

Kind regards,

Botao Liu


Try with this first: https://python.swaroopch.com/
It gives you the details of what that means and what to do next. Also,
your Python interpreter is broken 


No.

it says:



It should say something like this:
Python 3.9.2 (tags/v3.9.2:1a79785, Feb 19 2021, 13:44:55) [MSC

v.1928 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or
"license"


That is exactly what it does say, which is correct.


-- [mgogala@umajor ~]$ python3
Python 3.9.1 (default, Jan 20 2021, 00:00:00)
[GCC 10.2.1 20201125 (Red Hat 10.2.1-9)] on linux
Type "help", "copyright", "credits" or "license" for more information.




The problem string is "win32".


No.  'win32' is a historical artifact.

 You should be able to open a terminal

Window and execute "uname -r".


Not on Windows.  Please don't spew misleading garbage that will only 
confuse the new user on a different operating system.



--
Terry Jan Reedy

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

Re: name for a mutually inclusive relationship

[Antoon Pardon]

Op 24/02/21 om 17:12 schreef Ethan Furman:
I'm looking for a name for a group of options that, when one is 
specified, all of them must be specified.



It seems you are looking at an equivalence.
--
https://mail.python.org/mailman/listinfo/python-list