Re: A natural magnet for the craziest TKinter lovers out there

[Thomas Passin]

On 1/18/2023 11:46 PM, Thomas Passin wrote:

On 1/18/2023 8:56 PM, Michael Torrie wrote:

On 1/18/23 18:01, Dan Kolis wrote:
Hangs after maybe between 4 and 50 screen rewrites. sometimes CTRL C 
under Ubuntu starts it up again. Click go rewrites al the fonts the 
thing can find in a few windows Repeated.




Not sure what you mean by "screen rewrites."

I ran your test program here and it generates 25 windows on my machine,
and I can click "run" at least half a dozen times. I tried closing the
font windows before clicking run again, and also just leaving the
windows up and generating many more windows.  300 windows. No hangs here
at all. Fedora 35 with Mate Desktop on X11 with compositing enabled.


It could be using up some system resource.  tk could have some memory or 
resource leak, possibly specific to the OP's machine.  Try looking at 
system memory with the system monitor as the program goes through its 
paces.  Maybe you will notice something suspicious.




Also reduce the number of windows that get opened to a small number.  If 
there are no freezes, increase the number little by little.  This may 
give you some bounds on what's going on, or at least let your ultimate 
program work by keeping the resource use under control.


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

Re: Improvement to imports, what is a better way ?

[Cameron Simpson]

On 18Jan2023 16:10, Dan Kolis  wrote:

I have written a very sizable and elaborate program that uses tKinter for X11 
displays of genomics.
Yet maybe 1 of 6 times it freezes, so I decided to extract the minimum 
that works perfectly and add back big pieces. It does it both running 
.pyc and in VSCode.


The other thing you can do is put in a heap of print() calls in 
strategic places. See if you can get a handle on what its doing when it 
freezes. This might be iterative, zooming in on where this happens, if 
it's a specific thing.


I know this is vague. Once you find its stalling in a particular 
function (if it is) you may be able to run that function directly. Also, 
a print() at the top abd bottom/return of the stalling function. And so 
on.


If the GUI freezes, maybe you're running something time consuming inline 
in the event loop, such that it blocks reaching the "idle" point where 
the tk gui updates widgets and polls for user actions.


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

Re: A natural magnet for the craziest TKinter lovers out there

[Thomas Passin]

On 1/18/2023 8:56 PM, Michael Torrie wrote:

On 1/18/23 18:01, Dan Kolis wrote:

Hangs after maybe between 4 and 50 screen rewrites. sometimes CTRL C under 
Ubuntu starts it up again. Click go rewrites al the fonts the thing can find in 
a few windows Repeated.



Not sure what you mean by "screen rewrites."

I ran your test program here and it generates 25 windows on my machine,
and I can click "run" at least half a dozen times. I tried closing the
font windows before clicking run again, and also just leaving the
windows up and generating many more windows.  300 windows. No hangs here
at all. Fedora 35 with Mate Desktop on X11 with compositing enabled.


It could be using up some system resource.  tk could have some memory or 
resource leak, possibly specific to the OP's machine.  Try looking at 
system memory with the system monitor as the program goes through its 
paces.  Maybe you will notice something suspicious.


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

Re: A natural magnet for the craziest TKinter lovers out there

[Michael Torrie]

On 1/18/23 18:01, Dan Kolis wrote:
> Hangs after maybe between 4 and 50 screen rewrites. sometimes CTRL C under 
> Ubuntu starts it up again. Click go rewrites al the fonts the thing can find 
> in a few windows Repeated.
> 

Not sure what you mean by "screen rewrites."

I ran your test program here and it generates 25 windows on my machine,
and I can click "run" at least half a dozen times. I tried closing the
font windows before clicking run again, and also just leaving the
windows up and generating many more windows.  300 windows. No hangs here
at all. Fedora 35 with Mate Desktop on X11 with compositing enabled.

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

A natural magnet for the craziest TKinter lovers out there

[Dan Kolis]

Hangs after maybe between 4 and 50 screen rewrites. sometimes CTRL C under 
Ubuntu starts it up again. Click go rewrites al the fonts the thing can find in 
a few windows Repeated.

TKinter has a cult following. I don''t really expect others to fix my problems, 
but you know, es since its a cult thing to love TCL ( or something  ) Here 
is is.

 Same on two different computers in Python 3.6 and 3.8

Plus I suppose you get to see for sure all your finest fonts as rendered in a 
real TK thing, not that this changes the worlds so much.


Thanks for the advice so far...
Regards,
Dan Kolis

# Code version 18Jan2023 19:48 EST Dan Kolis
# Click 'go' on main page. when run over and over after a while it freezes


import tkinter as   tk
from tkinter import ttk
from tkinter import fontas  luFont


# Empty object maker ( M T ) ... get it say it !
class MT():
pass


# Module level variables
mod = MT()
mod.itsPlaces = MT()
mod.itsPlaces = []


# Apply XY Size to things like windows, variable place 31Jul22
def apply_Width_Height_Position( toThis, aWidth, aHeight, *argsPlace ):

# Width and height is expected

# Argument overflow is quite variable size is it its usual hint for me
aLen = len( argsPlace )

# Sometimes, just width and height are given ( not that + position )
wAndH = str( int( aWidth ) ) +'x' + str( int( aHeight ) )   
# Size has a funny text line interface
toThis.geometry( wAndH )
# Apply

# Sometimes position too
if aLen == 2:
eP = "+" + str( argsPlace[ 0 ] ) + "+" +  str( argsPlace[ 1 ] )
param4 = wAndH + eP 
# Combine size and position
toThis.geometry( param4 )   
# Apply

jj = 560


# Create local   toplevel   to whoever calls me 11Dec22 bc-endive
def make_Tk_Window( sReason, *attribKc ):

# Top level window maker and rememberer
# Kc = 'Kind code'

aCode = "na"
# Not available
if attribKc:
aCode = attribKc [ 0 ]  
# Better code then 'na'

# Make window
ansWin = tk.Toplevel()

# Keep track of this creation step
newEntry = {}
newEntry[ 'tkaddress' ] = ansWin
# Real TK window accessor
newEntry[ 'ideanamed' ] = sReason   
# Casual description
newEntry[ 'kindcode'  ] = aCode 
# So can be worked with together

mod.itsPlaces.append( newEntry )

return ansWin


# Idle time rewrite
def justRedisplayNow( wThings,  *argsR ):

# Redisplay a named tj thing
# Dont use this frivolously, if it's needed its here you have to study it

wThings.update()  


# Look at fonts possible 6Oct22
def showAllFonts():

# Show fonts possible

mod.lines_In_Window = 30; mod.window_Seq_Number = 1

# What we want to see
mod.seeFonts = list( luFont.families() )
mod.seeFonts.sort() 
# Alpha order is nice

# Fill windows as a look at me report
try:
populateW()
except:
tt = 456

rr = 245


# Show fonts regarding avoiding BAD ones that crash, etc size limits in buffers 
too 19Dec22
def populateW():

# Put in the fonts

aLen = len( mod.seeFonts )  
# Fun to know, debug really
last_considered_name = "gghfjhljfl" 
# Don't show doubles

# Loop through all fonts the system named
thisPassMakeWindow = True; a_Line_Count = 0; list_Number = 0
for item in mod.seeFonts:

# Multiple windows ( Python has funny ideas on this, ok like this )
if thisPassMakeWindow:
winTk_Now = winMakerFontsW(); thisPassMakeWindow = False; 
a_Line_Count = 0  # We gots one now

if a_Line_Count < mod.lines_In_Window:  
 # Will a window we made
list_Number += 1
# Counts
aN = str( list_Number ) + " "; name_In_lower = item.lower()

# Various reasons to not render this one
isOk = True
if name_In_lower == last_considered_name:
isOk = False
a_Bad_Thing = name_In_lower.find( 'emoji' ) > -1
if a_Bad_Thing:
isOk = False
a_Bad_Thing = item.find( 'Noto Sans Mono CJK' ) > -1
if a_Bad_Thing:
isOk = False

# Good good
if isOk:
label = "listlabel" + str( list_Number )

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

I have written a very sizable and elaborate program that uses tKinter for X11 
displays of genomics.

Yet maybe 1 of 6 times it freezes, so I decided to extract the minimum that 
works perfectly and add back big pieces. It does it both running .pyc and in 
VSCode.

so even the most minor of oddities is suspect. I cant really think of any 
better way to debug it. I see no evidence in WWW searches its a generic 
problem. So tracing the startup and watching it hop all around is about one of 
five lesser problem line items.

Regs
Dan

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

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

Thank you

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

Re: Improvement to imports, what is a better way ?

[Michael Torrie]

On 1/18/23 14:42, Dan Kolis wrote:
> 
>> I don't think you've described this. I don't know what you mean here. 
> 
> When I trace it in VSCode the imports seem like they endlessly suspend 
> scanning and go to other ones over and over. Like "Whats this doing ?"
> 

Nothing to worry about there. Python knows what it's doing! :)  Lots of
modules import other modules, so there will be a spanning tree of sorts.
 Each module will only actually be formally imported once.  The rest is
just setting up name spaces.  Yes it all adds to run time latency, but
it certainly won't lead to any leaks.

Definitely there's no need to import a module's dependencies; it will do
that itself.  Just import what your own module explicitly needs.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Greg Ewing]

On 19/01/23 10:40 am, Dan Kolis wrote:

I guess I don't full understand what bothers me about the repetition of the 
imports so much.


It's doubtful that every module uses every one of those imports.
It looks like someone had a standard block of imports that they
blindly pasted at the top of every file, to avoid having to think
about which ones were actually needed.

If you're looking for advice, I would suggest:

* Only import what you use in a particular file (this doesn't
have much effect on efficiency, but there's less clutter for
the reader.)

* Only use short names for modules that are *very* frequently
referenced. Use full unabbreviated names for everything else.

* Don't 'import foo as foo', just 'import foo'.

* Don't try to line the code up in columns, it doesn't really
help readability IMO.

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

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

> I don't think you've described this. I don't know what you mean here. 

When I trace it in VSCode the imports seem like they endlessly suspend scanning 
and go to other ones over and over. Like "Whats this doing ?"

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

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

Most of the time the newbie I visualize adding a function copies and pastes 
maybe a screen of python and changes it a little, maybe 5% of the lines have a 
xx. code so they rarely have to understand it,  thats not the part of the 
program there changing.

Also, I suffered long and hard for extreme uniformity in the names and so on, 
there utterly uniform, so there not so bad to consider, ( I hope ).

I guess I don't full understand what bothers me about the repetition of the 
imports so much. The tracing of it seems so bizarre, it just seems like its 
wrong.

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

Re: Improvement to imports, what is a better way ?

[Cameron Simpson]

On 18Jan2023 12:57, Dan Kolis  wrote:
I'm not sure what to do. Do either / both know if there is a way to 
make it parse each import list to bytecode in one shot ??


Python usually compiles files to bytecode and leaves those around as 
.pyc files to be used until the original source is modified. And anyway, 
an imported module is only loaded a ready once; imports are kept track 
of in the sys.modules dict, and just pulled directly from there when the 
same module is requests by another import.


The hop around read keeps making me worry it migth leave some memory 
leak or something.


I don't think you've described this. I don't know what you mean here.

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

Re: Improvement to imports, what is a better way ?

[Paul Bryan]

On Thu, 2023-01-19 at 09:47 +1300, dn via Python-list wrote:

> The longer an identifier, the more it 'pushes' code over to the right
> or 
> to expand over multiple screen-lines. Some thoughts on this are
> behind 
> PEP-008 philosophies, eg line-limit.

I sympathize with this issue. I've pushed the line limit to 96, which
in my case removed this pain point. My argument—though subjective—is
that we have wide screens now, and it's quite unlikely production code
will be accessed through a vintage VT-100 terminal or printed on a 80-
column dot-matrix printer. That said, even if you stick to PEP-8
proper, `black` does most of the formatting work, and it seems to do a
reasonable job despite longer module identifiers.

> In the body of the code, if every time an external identifier is used
> it 
> must be prefixed by a full 'path', the cognitive "burden" shifts from
> the aspect highlighted (above), to a reading-burden. Thus, (in
> extreme 
> cases) moving towards a 'wall of text' problem.

I tend to agree this can be a problem in some cases, but I think those
can be made manageable. For brevity's sake, I import often-used data
types directly into the module's name space. It's far more rare that I
try to abbreviate a module name; common ones like importing pandas as
pd is a good counterexample.

> In using TDD, code is constructed module-by-module (not necessarily
> a 
> Python Module). So, when it comes time to call
> avMedia.fetch_the_file() 
> [sic] there is little thinking about the "avMedia" bit. The emphasis
> is 
> on the function-name, and it's parameters. 'I need that file so that
> I 
> can ...'.

I'm not entirely sure what you mean by not a Python module. Even in
test modules, I would only import what's required. If it turns out
`fetch_the_file` is called dozens of times or more, I would have no
qualm about importing it directly into the test module's namespace so
that it doesn't need to be prefixed at all.

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

Re: Improvement to imports, what is a better way ?

[Weatherby,Gerard]

In the body of the code, if every time an external identifier is used it
must be prefixed by a full 'path', the cognitive "burden" shifts from
the aspect highlighted (above), to a reading-burden.

As the fictional Jack McCoy ( https://en.wikipedia.org/wiki/Jack_McCoy) would 
say --

Objection: Assumes facts not in evidence!

If I read A.py:

import …
# many lines of code
x = obscure_module.widget(4)

I know immediately where the function widget is.

If I read B.py
from obscure_module import widget
# many lines of code
x = widget(4)

Now I have to find out where the heck “widget” came from

And C.py

from obscure_module import widget as gadget
# many lines of code
x = gadget(4)

which is actually easier and harder to read.  Personally, I’m much happier with 
A.py than B.py or C.py.







From: Python-list  on 
behalf of dn via Python-list 
Date: Wednesday, January 18, 2023 at 3:49 PM
To: python-list@python.org 
Subject: Re: Improvement to imports, what is a better way ?
*** Attention: This is an external email. Use caution responding, opening 
attachments or clicking on links. ***

On 19/01/2023 08.56, Mats Wichmann wrote:
> On 1/18/23 12:29, Paul Bryan wrote:
...

>>> import os asos
>>> import sys as   sys
>>> import importlib as importlib
>
> A general comment: there are some very common "import ... as" idioms
> (for example, it seems like *everyone* does "import pandas as pd") and
> those are okay to follow, but in general I would stay away from trying
> to give everything short-names.  Each module imported with a name other
> than their own is a memory burden for the reader (maybe even for you!).
>
>>> import aboutTime as tt  # Time dates timestamps and the
>>> like
>>> import avMedia as   av  # Audio and maybe video 'someday'
>>> well definitely lots of TTS text to speech
>>> import basicSwitchboard as  sc  # First switchboard lurking.
>>> Kickoff to sequence viewers
>
> Any decent editor these days will autocomplete for you, so there's
> really not much if any typing burden in using the full names.

Have vacillated on aspects of this topic, over the years. Currently I'm
in favor of abbreviations and not only the commonly-accepted/-used ones,
eg np for numpy.
(but am keen to learn from your wisdom)

I've argued the auto-complete cf typing point. So, that not at-issue.

The longer an identifier, the more it 'pushes' code over to the right or
to expand over multiple screen-lines. Some thoughts on this are behind
PEP-008 philosophies, eg line-limit.

In the body of the code, if every time an external identifier is used it
must be prefixed by a full 'path', the cognitive "burden" shifts from
the aspect highlighted (above), to a reading-burden. Thus, (in extreme
cases) moving towards a 'wall of text' problem.

The primary interest is to remove "burden" aka complexity.

In using TDD, code is constructed module-by-module (not necessarily a
Python Module). So, when it comes time to call avMedia.fetch_the_file()
[sic] there is little thinking about the "avMedia" bit. The emphasis is
on the function-name, and it's parameters. 'I need that file so that I
can ...'.

Using the IDE-as-a-tool argument (similar to above): if I miss-out,
mistype, use the wrong abbreviation, or otherwise fail to identify where
fetch_the_file() is located, the IDE will immediately tell me.
(dn you're wrong - again!)

Accordingly, the abbreviation/full-module-name is almost taken-on-trust.
(you're going to prove/test the linkage, either way, right?)


Personal Biases:
- TDD
- when starting to write the program[me]-code one of the first steps is
to marshal resources, which includes the question: which functions will
be called and thus which Python-modules should be imported? Thus,
listing all imports 'at the top' is a separable task.
- an early language learned (back-when) was COBOL, which has a formal
structure and separation between elements/phases of a program[me]'s
construction and execution. Some such thinking no doubt lingers...

--
Regards,
=dn
--
https://urldefense.com/v3/__https://mail.python.org/mailman/listinfo/python-list__;!!Cn_UX_p3!nUeLMY3g5EV0oaXoGfknoeDOLU9qMoIxHOe7jhHbHfN1v7-wj17OJCgqL_IyHpAr0EN8gyzj5ZEQZB9_A-rB3A_Q5g$
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Dan Kolis]

dn and Mats, thanks for your advice.

I'm not sure what to do. Do either / both know if there is a way to make it 
parse each import list to bytecode in one shot ?? The hop around read keeps 
making me worry it migth leave some memory leak or something.

I dont know. 

Thanks though, both your dialog's are very helpful.

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

Re: Improvement to imports, what is a better way ?

[dn via Python-list]

On 19/01/2023 08.56, Mats Wichmann wrote:

On 1/18/23 12:29, Paul Bryan wrote:

...


import os as    os
import sys as   sys
import importlib as importlib


A general comment: there are some very common "import ... as" idioms 
(for example, it seems like *everyone* does "import pandas as pd") and 
those are okay to follow, but in general I would stay away from trying 
to give everything short-names.  Each module imported with a name other 
than their own is a memory burden for the reader (maybe even for you!).



import aboutTime as tt  # Time dates timestamps and the
like
import avMedia as   av  # Audio and maybe video 'someday'
well definitely lots of TTS text to speech
import basicSwitchboard as  sc  # First switchboard lurking.
Kickoff to sequence viewers


Any decent editor these days will autocomplete for you, so there's 
really not much if any typing burden in using the full names.


Have vacillated on aspects of this topic, over the years. Currently I'm 
in favor of abbreviations and not only the commonly-accepted/-used ones, 
eg np for numpy.

(but am keen to learn from your wisdom)

I've argued the auto-complete cf typing point. So, that not at-issue.

The longer an identifier, the more it 'pushes' code over to the right or 
to expand over multiple screen-lines. Some thoughts on this are behind 
PEP-008 philosophies, eg line-limit.


In the body of the code, if every time an external identifier is used it 
must be prefixed by a full 'path', the cognitive "burden" shifts from 
the aspect highlighted (above), to a reading-burden. Thus, (in extreme 
cases) moving towards a 'wall of text' problem.


The primary interest is to remove "burden" aka complexity.

In using TDD, code is constructed module-by-module (not necessarily a 
Python Module). So, when it comes time to call avMedia.fetch_the_file() 
[sic] there is little thinking about the "avMedia" bit. The emphasis is 
on the function-name, and it's parameters. 'I need that file so that I 
can ...'.


Using the IDE-as-a-tool argument (similar to above): if I miss-out, 
mistype, use the wrong abbreviation, or otherwise fail to identify where 
fetch_the_file() is located, the IDE will immediately tell me.

(dn you're wrong - again!)

Accordingly, the abbreviation/full-module-name is almost taken-on-trust. 
(you're going to prove/test the linkage, either way, right?)



Personal Biases:
- TDD
- when starting to write the program[me]-code one of the first steps is 
to marshal resources, which includes the question: which functions will 
be called and thus which Python-modules should be imported? Thus, 
listing all imports 'at the top' is a separable task.
- an early language learned (back-when) was COBOL, which has a formal 
structure and separation between elements/phases of a program[me]'s 
construction and execution. Some such thinking no doubt lingers...


--
Regards,
=dn
--
https://mail.python.org/mailman/listinfo/python-list

Re: IDLE "Codepage" Switching?

[Eryk Sun]

On 1/17/23, Stephen Tucker  wrote:
>
> 1. Can anybody explain the behaviour in IDLE (Python version 2.7.10)
> reported below? (It seems that the way it renders a given sequence of bytes
> depends on the sequence.)

In 2.x, IDLE tries to decode a byte string via unicode() before
writing to the Tk text widget. However, if the locale encoding (e.g.
the process ANSI code page) fails to decode one or more characters,
IDLE lets Tk figure out how to decode the byte string.

Python 2.7 has an older version of Tk that has peculiar behavior on
Windows when bytes in the range 0x80-0xBF are written to a text box.
Bytes in this range get translated to native wide characters (16-bit
characters) in the halfwidth/fullwidth Unicode block, i.e. translated
to Unicode U+FF80 - U+FFBF.

If IDLE decodes using code page 1252, then the ordinals 0x81, 0x8d,
0x8f, 0x90 and 0x9d can't be decoded. IDLE thus passes the undecoded
byte string to Tk. The example you provided that demonstrates the
behavior contains ordinal 0x9d (157).

I get similar behavior for the other undefined ordinal values in code
page 1252. For example, using IDLE 2.7.18 on Windows:

>>> print '\x81\xa1'
ﾁﾡ
>>> print 'a\xa1'
a¡

In the first case, ordinal 0x81 causes decoding to fail in IDLE, so
the byte string is passed as is to Tk, which maps it to
'\uff81\uffa1'. In the second case, OTOH, "\xa1" is decoded by IDLE as
"¡".

> 2. Does the IDLE in Python 3.x behave the same way?

No, in 3.x only Unicode str() objects are written to the Tk text
widget. Moreover, the text widget doesn't have the same behavior in
newer versions. It ignores bytes in the control-block range 0x80-0x9F,
and it decodes bytes in the range 0xA0-0xBF normally.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Improvement to imports, what is a better way ?

[Mats Wichmann]

On 1/18/23 12:29, Paul Bryan wrote:

I would suggest allowing each module to define its own imports, don't
import what a module doesn't consume, keep them simple, avoid devising
a common namespace for each, and let tools like isort/black work out
how to order/express them in source files.


Indeed.  And various checkers will report on unused imports.

These add no value... why import something "as" and give it its own name?


import os as    os
import sys as   sys
import importlib as importlib


A general comment: there are some very common "import ... as" idioms 
(for example, it seems like *everyone* does "import pandas as pd") and 
those are okay to follow, but in general I would stay away from trying 
to give everything short-names.  Each module imported with a name other 
than their own is a memory burden for the reader (maybe even for you!).



import aboutTime as tt  # Time dates timestamps and the
like
import avMedia as   av  # Audio and maybe video 'someday'
well definitely lots of TTS text to speech
import basicSwitchboard as  sc  # First switchboard lurking.
Kickoff to sequence viewers


Any decent editor these days will autocomplete for you, so there's 
really not much if any typing burden in using the full names.


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

Re: Improvement to imports, what is a better way ?

[Paul Bryan]

I would suggest allowing each module to define its own imports, don't
import what a module doesn't consume, keep them simple, avoid devising
a common namespace for each, and let tools like isort/black work out
how to order/express them in source files.

On Wed, 2023-01-18 at 10:43 -0800, Dan Kolis wrote:
> This program has lots of files and each is well segregated for a
> concept.
> 
> the top of each as a heap of imports, all identical. Well the very
> top has some one of's
> 
> import os as    os
> import sys as   sys
> import importlib as importlib
> import datetime as  dt
> from   tokenize import  maybe
> import signal
> 
> from   tkinter import filedialog as fd
> from   tkinter.messagebox import    showinfo
> import tkinter as   tk  
> from   tkinter import   ttk
> from   tkinter import   font
>  
> from   PIL import Image as  pl
> from   PIL import ImageTk   as  ii
> 
> # Imports part of this program 
> import aboutTime as tt  # Time dates timestamps and the
> like
> import avMedia as   av  # Audio and maybe video 'someday'
> well definitely lots of TTS text to speech
> import basicSwitchboard as  sc  # First switchboard lurking.
> Kickoff to sequence viewers
> import bestNotifications as bn  # Alerts, modals and
> notifications of many kinds including TK windows
> import bitBlitting as   bb  # Help - # A setup window with
> basic facts written into files and the workspace
> import configSetting as cs  # A setup window with basic facts
> written into files and the workspace
> import devPeeks as  dp  # Developments peek assets code
> for adding features and debugging
> import fileIo as    io  # File reads, writes even some of
> the the pickle and unpickling
> import forFun as    ff  # Staging area for uncertian
> features, also some dynamic code inclusion
> import fractionScreens as   fs  # Common window pieces for TK
> windows in sequence viewers
> import genomeDb as  gd  # IO to from databases external
> files gbk and others sure
> import globalIdeas as   gi  # Common code for stuff used
> everywhere and definition of share DOT OBJECTS
> import insertableEditors as ie  # Text editor(s) and support for
> that, some language issues managed too
> import modalSimple as   mo  # Modal windows icp seq ssues,
> not used much currently
> import osDependant as   od  # Operating system dependant
> calls and adaptions
> import pickle as    pk  # Packaging to and from file
> system for objects especially DOT OBJECTS
> import screenBuilder1 as    sb  # Screen maker for TKinter and
> TKinter ++ windows
> import selectViewer as  sv  # Window for picking which
> sequence viewers are enabled
> import sequencesMaintain as sm  # Touching up temporal version
> issues of DOT OBJECTS
> import sequencesOverview as so  # Working with sequences as macro
> facts, lists, see turn off etc
> import serverHttp1 as   sh1 # Servers for HTTP - User Support
> import serverHttp2 as   sh2 # Servers for HTTP - Protein
> viewing
> import specialFour as   sf  # Classes and stuff for viewer
> four, a very complex viewer
> import stagingNow as    sn  # More stabler new ideas getting
> tried out and moved in
> import taskingFunction as   tf  # Tasker for real timeish event
> processor calls. Has two versions both work
> import toastMaker as    tm  # Notifications
> import transFormations as   xf  # Sequence transFormations from
> mother natures ideas like DNA and RNA
> import unlovedMenus as  um  # Pretty rarely used ond
> fashioned menus. A while interface is in here that works
> import wayOffline as    wo  # Code not discarded but just
> studies, etc
> import windowsX as  wx  # Windows Life ! X11 esp TK not
> MS Windoze ...
> 
> So the file for instance fileIo.py has a duplicate of this.
> 
> I want to be able to call any code by using the two char prefix form
> anywhere. ex: io.get_Sequence(  'abc.fa' )
> 
> this seems weirdly disorderly. when it starts it sort of iterates
> down into objects, backs up etc.
> 
> What's the right way to do this ?
> 
> Thank you
> Dan

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

Improvement to imports, what is a better way ?

[Dan Kolis]

This program has lots of files and each is well segregated for a concept.

the top of each as a heap of imports, all identical. Well the very top has some 
one of's

import os asos
import sys as   sys
import importlib as importlib
import datetime as  dt
from   tokenize import  maybe
import signal

from   tkinter import filedialog as fd
from   tkinter.messagebox importshowinfo
import tkinter as   tk  
from   tkinter import   ttk
from   tkinter import   font
 
from   PIL import Image as  pl
from   PIL import ImageTk   as  ii

# Imports part of this program 
import aboutTime as tt  # Time dates timestamps and the like
import avMedia as   av  # Audio and maybe video 'someday' well 
definitely lots of TTS text to speech
import basicSwitchboard as  sc  # First switchboard lurking. Kickoff to 
sequence viewers
import bestNotifications as bn  # Alerts, modals and notifications of many 
kinds including TK windows
import bitBlitting as   bb  # Help - # A setup window with basic facts 
written into files and the workspace
import configSetting as cs  # A setup window with basic facts written 
into files and the workspace
import devPeeks as  dp  # Developments peek assets code for adding 
features and debugging
import fileIo asio  # File reads, writes even some of the the 
pickle and unpickling
import forFun asff  # Staging area for uncertian features, also 
some dynamic code inclusion
import fractionScreens as   fs  # Common window pieces for TK windows in 
sequence viewers
import genomeDb as  gd  # IO to from databases external files gbk 
and others sure
import globalIdeas as   gi  # Common code for stuff used everywhere and 
definition of share DOT OBJECTS
import insertableEditors as ie  # Text editor(s) and support for that, some 
language issues managed too
import modalSimple as   mo  # Modal windows icp seq ssues, not used 
much currently
import osDependant as   od  # Operating system dependant calls and 
adaptions
import pickle aspk  # Packaging to and from file system for 
objects especially DOT OBJECTS
import screenBuilder1 assb  # Screen maker for TKinter and TKinter ++ 
windows
import selectViewer as  sv  # Window for picking which sequence viewers 
are enabled
import sequencesMaintain as sm  # Touching up temporal version issues of 
DOT OBJECTS
import sequencesOverview as so  # Working with sequences as macro facts, 
lists, see turn off etc
import serverHttp1 as   sh1 # Servers for HTTP - User Support
import serverHttp2 as   sh2 # Servers for HTTP - Protein viewing
import specialFour as   sf  # Classes and stuff for viewer four, a very 
complex viewer
import stagingNow assn  # More stabler new ideas getting tried out 
and moved in
import taskingFunction as   tf  # Tasker for real timeish event processor 
calls. Has two versions both work
import toastMaker astm  # Notifications
import transFormations as   xf  # Sequence transFormations from mother 
natures ideas like DNA and RNA
import unlovedMenus as  um  # Pretty rarely used ond fashioned menus. A 
while interface is in here that works
import wayOffline aswo  # Code not discarded but just studies, etc
import windowsX as  wx  # Windows Life ! X11 esp TK not MS Windoze 
...

So the file for instance fileIo.py has a duplicate of this.

I want to be able to call any code by using the two char prefix form anywhere. 
ex: io.get_Sequence(  'abc.fa' )

this seems weirdly disorderly. when it starts it sort of iterates down into 
objects, backs up etc.

What's the right way to do this ?

Thank you
Dan
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDLE "Codepage" Switching?

[Peter J. Holzer]

On 2023-01-18 11:05:24 -0500, Thomas Passin wrote:
> On 1/18/2023 5:43 AM, Stephen Tucker wrote:
> > Thanks for these responses.
> > 
> > I was encouraged to read that I'm not the only one to find this all
> > confusing.
> > 
> > I have investigated a little further.
> > 
> > 1. I produced the following IDLE log:
> > 
> > > > > mylongstr = ""
> > > > > for thisCP in range (1, 256):
> > mylongstr += chr (thisCP) + " " + str (ord (chr (thisCP))) + ", "
> > 
> > 
> > > > > print mylongstr
> > 1, 2, 3, 4, 5, 6, 7, 8, 9,
> >   10, 11, 12,
> >   13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
> > 31,   32, ! 33, " 34, # 35, $ 36, % 37, & 38, ' 39, ( 40, ) 41, * 42, + 43,
> > , 44, - 45, . 46, / 47, 0 48, 1 49, 2 50, 3 51, 4 52, 5 53, 6 54, 7 55, 8
> > 56, 9 57, : 58, ; 59, < 60, = 61, > 62, ? 63, @ 64, A 65, B 66, C 67, D 68,
> > E 69, F 70, G 71, H 72, I 73, J 74, K 75, L 76, M 77, N 78, O 79, P 80, Q
> > 81, R 82, S 83, T 84, U 85, V 86, W 87, X 88, Y 89, Z 90, [ 91, \ 92, ] 93,
> > ^ 94, _ 95, ` 96, a 97, b 98, c 99, d 100, e 101, f 102, g 103, h 104, i
> > 105, j 106, k 107, l 108, m 109, n 110, o 111, p 112, q 113, r 114, s 115,
> > t 116, u 117, v 118, w 119, x 120, y 121, z 122, { 123, | 124, } 125, ~
> > 126, 127, ﾀ 128, ﾁ 129, ﾂ 130, ﾃ 131, ﾄ 132, ﾅ 133, ﾆ 134, ﾇ 135, ﾈ 136, ﾉ
> > 137, ﾊ 138, ﾋ 139, ﾌ 140, ﾍ 141, ﾎ 142, ﾏ 143, ﾐ 144, ﾑ 145, ﾒ 146, ﾓ 147,
> > ﾔ 148, ﾕ 149, ﾖ 150, ﾗ 151, ﾘ 152, ﾙ 153, ﾚ 154, ﾛ 155, ﾜ 156, ﾝ 157, ﾞ
> > 158, ﾟ 159, ﾠ 160, ﾡ 161, ﾢ 162, ﾣ 163, ﾤ 164, ﾥ 165, ﾦ 166, ﾧ 167, ﾨ 168,
> > ﾩ 169, ﾪ 170, ﾫ 171, ﾬ 172, ﾭ 173, ﾮ 174, ﾯ 175, ﾰ 176, ﾱ 177, ﾲ 178, ﾳ
> > 179, ﾴ 180, ﾵ 181, ﾶ 182, ﾷ 183, ﾸ 184, ﾹ 185, ﾺ 186, ﾻ 187, ﾼ 188, ﾽ 189,
> > ﾾ 190, ﾿ 191, À 192, Á 193, Â 194, Ã 195, Ä 196, Å 197, Æ 198, Ç 199, È
> > 200, É 201, Ê 202, Ë 203, Ì 204, Í 205, Î 206, Ï 207, Ð 208, Ñ 209, Ò 210,
> > Ó 211, Ô 212, Õ 213, Ö 214, × 215, Ø 216, Ù 217, Ú 218, Û 219, Ü 220, Ý
> > 221, Þ 222, ß 223, à 224, á 225, â 226, ã 227, ä 228, å 229, æ 230, ç 231,
> > è 232, é 233, ê 234, ë 235, ì 236, í 237, î 238, ï 239, ð 240, ñ 241, ò
> > 242, ó 243, ô 244, õ 245, ö 246, ÷ 247, ø 248, ù 249, ú 250, û 251, ü 252,
> > ý 253, þ 254, ÿ 255,
> > > > > 
> > 
> > 2. I copied and pasted the IDLE log into a text file and ran a program on
> > it that told me about every byte in the log.
> > 
> > 3. I discovered the following:
> > 
> > Bytes 001 to 127 (01 to 7F hex) inclusive were printed as-is;

Which might mean that they are also UTF-8-encoded (there is no
difference between UTF-8-encoding and ASCII-encoding for these
characters).


> > Bytes 128 to 191 (80 to BF) inclusive were output as UTF-8-encoded
> > characters whose codepoints were FF00 hex more than the byte values (hence
> > the strange glyphs);
> > 
> > Bytes 192 to 255 (C0 to FF) inclusive were output as UTF-8-encoded
> > characters - without any offset being added to their codepoints in the
> > meantime!
> > 
> > I thought you might just be interested in this - there does seem to be some
> > method in IDLE's mind, at least.
> 
> This has nothing to do with IDLE.  The UTF-8 encoding of those code points
> uses two bytes instead of one.  See

That's not the peculiar thing. The peculiar thing is that characters
U+0080 to U+00BF are recoded to U+FF80 to U+FFBF (but U+00C0 to U+00FF
are printed normally).

I have no idea what's happening here. I can only urge Stephen to use
Python 3.x instead of Python 2.7. Python2 has been deprecated for years
has has reached its official end of life 3 years ago. There really
shouldn't be any reason to use Python 2.7 any more except
reverse-engineering old applications in order to port them to Python 3.

In particular, the type "str" is very different in Python2 and Python3.
In Python2 it is a sequence of bytes (similar to the Python3 type
"bytes") and in Python3 it is a sequence of (Unicode) characters
(similar to the Python2 type "unicode").

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


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

Re: IDLE "Codepage" Switching?

[Thomas Passin]

On 1/18/2023 5:43 AM, Stephen Tucker wrote:

Thanks for these responses.

I was encouraged to read that I'm not the only one to find this all
confusing.

I have investigated a little further.

1. I produced the following IDLE log:


mylongstr = ""
for thisCP in range (1, 256):

mylongstr += chr (thisCP) + " " + str (ord (chr (thisCP))) + ", "



print mylongstr

1, 2, 3, 4, 5, 6, 7, 8, 9,
  10, 11, 12,
  13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
31,   32, ! 33, " 34, # 35, $ 36, % 37, & 38, ' 39, ( 40, ) 41, * 42, + 43,
, 44, - 45, . 46, / 47, 0 48, 1 49, 2 50, 3 51, 4 52, 5 53, 6 54, 7 55, 8
56, 9 57, : 58, ; 59, < 60, = 61, > 62, ? 63, @ 64, A 65, B 66, C 67, D 68,
E 69, F 70, G 71, H 72, I 73, J 74, K 75, L 76, M 77, N 78, O 79, P 80, Q
81, R 82, S 83, T 84, U 85, V 86, W 87, X 88, Y 89, Z 90, [ 91, \ 92, ] 93,
^ 94, _ 95, ` 96, a 97, b 98, c 99, d 100, e 101, f 102, g 103, h 104, i
105, j 106, k 107, l 108, m 109, n 110, o 111, p 112, q 113, r 114, s 115,
t 116, u 117, v 118, w 119, x 120, y 121, z 122, { 123, | 124, } 125, ~
126, 127, ﾀ 128, ﾁ 129, ﾂ 130, ﾃ 131, ﾄ 132, ﾅ 133, ﾆ 134, ﾇ 135, ﾈ 136, ﾉ
137, ﾊ 138, ﾋ 139, ﾌ 140, ﾍ 141, ﾎ 142, ﾏ 143, ﾐ 144, ﾑ 145, ﾒ 146, ﾓ 147,
ﾔ 148, ﾕ 149, ﾖ 150, ﾗ 151, ﾘ 152, ﾙ 153, ﾚ 154, ﾛ 155, ﾜ 156, ﾝ 157, ﾞ
158, ﾟ 159, ﾠ 160, ﾡ 161, ﾢ 162, ﾣ 163, ﾤ 164, ﾥ 165, ﾦ 166, ﾧ 167, ﾨ 168,
ﾩ 169, ﾪ 170, ﾫ 171, ﾬ 172, ﾭ 173, ﾮ 174, ﾯ 175, ﾰ 176, ﾱ 177, ﾲ 178, ﾳ
179, ﾴ 180, ﾵ 181, ﾶ 182, ﾷ 183, ﾸ 184, ﾹ 185, ﾺ 186, ﾻ 187, ﾼ 188, ﾽ 189,
ﾾ 190, ﾿ 191, À 192, Á 193, Â 194, Ã 195, Ä 196, Å 197, Æ 198, Ç 199, È
200, É 201, Ê 202, Ë 203, Ì 204, Í 205, Î 206, Ï 207, Ð 208, Ñ 209, Ò 210,
Ó 211, Ô 212, Õ 213, Ö 214, × 215, Ø 216, Ù 217, Ú 218, Û 219, Ü 220, Ý
221, Þ 222, ß 223, à 224, á 225, â 226, ã 227, ä 228, å 229, æ 230, ç 231,
è 232, é 233, ê 234, ë 235, ì 236, í 237, î 238, ï 239, ð 240, ñ 241, ò
242, ó 243, ô 244, õ 245, ö 246, ÷ 247, ø 248, ù 249, ú 250, û 251, ü 252,
ý 253, þ 254, ÿ 255,




2. I copied and pasted the IDLE log into a text file and ran a program on
it that told me about every byte in the log.

3. I discovered the following:

Bytes 001 to 127 (01 to 7F hex) inclusive were printed as-is;

Bytes 128 to 191 (80 to BF) inclusive were output as UTF-8-encoded
characters whose codepoints were FF00 hex more than the byte values (hence
the strange glyphs);

Bytes 192 to 255 (C0 to FF) inclusive were output as UTF-8-encoded
characters - without any offset being added to their codepoints in the
meantime!

I thought you might just be interested in this - there does seem to be some
method in IDLE's mind, at least.


This has nothing to do with IDLE.  The UTF-8 encoding of those code 
points uses two bytes instead of one.  See


https://stackoverflow.com/questions/8732025/why-degree-symbol-differs-from-utf-8-from-unicode#:~:text=UTF-8%20encodes%20the%20value%200xB0%20as%20two%20consecutive,on%20endianness%20(I%20suppose%20other%20orderings%20are%20possible).coding-in-vs-code-on-ubuntu-leading-to-unicode-error/62652695#62652695





Stephen Tucker.








On Wed, Jan 18, 2023 at 9:41 AM Peter J. Holzer  wrote:


On 2023-01-17 22:58:53 -0500, Thomas Passin wrote:

On 1/17/2023 8:46 PM, rbowman wrote:

On Tue, 17 Jan 2023 12:47:29 +, Stephen Tucker wrote:

2. Does the IDLE in Python 3.x behave the same way?


fwiw

Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
Type "help", "copyright", "credits" or "license()" for more

information.

str = ""
for c in range(140, 169):
  str += chr(c) + " "

print(str)
Œ   Ž ‘ ’ “ ” • – — ˜ ™ š › œ   ž Ÿ   ¡ ¢ £ ¤ ¥
¦ § ¨


I don't know how this will appear since Pan is showing the icon for a
character not in its set.  However, even with more undefined characters
the printable one do not change. I get the same output running Python3
from the terminal so it's not an IDLE thing.


I'm not sure what explanation is being asked for here.  Let's take

Python3,

so we can be sure that the strings are in unicode.  The font being used

by

the console isn't mentioned, but there's no reason it should have glyphs

for

any random unicode character.


Also note that the characters between 128 (U+0080) and 159 (U+009F)
inclusive aren't printable characters. They are control characters.

 hp

--
_  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"
--
https://mail.python.org/mailman/listinfo/python-list



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

Re: IDLE "Codepage" Switching?

[Stephen Tucker]

Thanks for these responses.

I was encouraged to read that I'm not the only one to find this all
confusing.

I have investigated a little further.

1. I produced the following IDLE log:

>>> mylongstr = ""
>>> for thisCP in range (1, 256):
mylongstr += chr (thisCP) + " " + str (ord (chr (thisCP))) + ", "


>>> print mylongstr
1, 2, 3, 4, 5, 6, 7, 8, 9,
 10, 11, 12,
 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30,
31,   32, ! 33, " 34, # 35, $ 36, % 37, & 38, ' 39, ( 40, ) 41, * 42, + 43,
, 44, - 45, . 46, / 47, 0 48, 1 49, 2 50, 3 51, 4 52, 5 53, 6 54, 7 55, 8
56, 9 57, : 58, ; 59, < 60, = 61, > 62, ? 63, @ 64, A 65, B 66, C 67, D 68,
E 69, F 70, G 71, H 72, I 73, J 74, K 75, L 76, M 77, N 78, O 79, P 80, Q
81, R 82, S 83, T 84, U 85, V 86, W 87, X 88, Y 89, Z 90, [ 91, \ 92, ] 93,
^ 94, _ 95, ` 96, a 97, b 98, c 99, d 100, e 101, f 102, g 103, h 104, i
105, j 106, k 107, l 108, m 109, n 110, o 111, p 112, q 113, r 114, s 115,
t 116, u 117, v 118, w 119, x 120, y 121, z 122, { 123, | 124, } 125, ~
126, 127, ﾀ 128, ﾁ 129, ﾂ 130, ﾃ 131, ﾄ 132, ﾅ 133, ﾆ 134, ﾇ 135, ﾈ 136, ﾉ
137, ﾊ 138, ﾋ 139, ﾌ 140, ﾍ 141, ﾎ 142, ﾏ 143, ﾐ 144, ﾑ 145, ﾒ 146, ﾓ 147,
ﾔ 148, ﾕ 149, ﾖ 150, ﾗ 151, ﾘ 152, ﾙ 153, ﾚ 154, ﾛ 155, ﾜ 156, ﾝ 157, ﾞ
158, ﾟ 159, ﾠ 160, ﾡ 161, ﾢ 162, ﾣ 163, ﾤ 164, ﾥ 165, ﾦ 166, ﾧ 167, ﾨ 168,
ﾩ 169, ﾪ 170, ﾫ 171, ﾬ 172, ﾭ 173, ﾮ 174, ﾯ 175, ﾰ 176, ﾱ 177, ﾲ 178, ﾳ
179, ﾴ 180, ﾵ 181, ﾶ 182, ﾷ 183, ﾸ 184, ﾹ 185, ﾺ 186, ﾻ 187, ﾼ 188, ﾽ 189,
ﾾ 190, ﾿ 191, À 192, Á 193, Â 194, Ã 195, Ä 196, Å 197, Æ 198, Ç 199, È
200, É 201, Ê 202, Ë 203, Ì 204, Í 205, Î 206, Ï 207, Ð 208, Ñ 209, Ò 210,
Ó 211, Ô 212, Õ 213, Ö 214, × 215, Ø 216, Ù 217, Ú 218, Û 219, Ü 220, Ý
221, Þ 222, ß 223, à 224, á 225, â 226, ã 227, ä 228, å 229, æ 230, ç 231,
è 232, é 233, ê 234, ë 235, ì 236, í 237, î 238, ï 239, ð 240, ñ 241, ò
242, ó 243, ô 244, õ 245, ö 246, ÷ 247, ø 248, ù 249, ú 250, û 251, ü 252,
ý 253, þ 254, ÿ 255,
>>>

2. I copied and pasted the IDLE log into a text file and ran a program on
it that told me about every byte in the log.

3. I discovered the following:

Bytes 001 to 127 (01 to 7F hex) inclusive were printed as-is;

Bytes 128 to 191 (80 to BF) inclusive were output as UTF-8-encoded
characters whose codepoints were FF00 hex more than the byte values (hence
the strange glyphs);

Bytes 192 to 255 (C0 to FF) inclusive were output as UTF-8-encoded
characters - without any offset being added to their codepoints in the
meantime!

I thought you might just be interested in this - there does seem to be some
method in IDLE's mind, at least.

Stephen Tucker.








On Wed, Jan 18, 2023 at 9:41 AM Peter J. Holzer  wrote:

> On 2023-01-17 22:58:53 -0500, Thomas Passin wrote:
> > On 1/17/2023 8:46 PM, rbowman wrote:
> > > On Tue, 17 Jan 2023 12:47:29 +, Stephen Tucker wrote:
> > > > 2. Does the IDLE in Python 3.x behave the same way?
> > >
> > > fwiw
> > >
> > > Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
> > > Type "help", "copyright", "credits" or "license()" for more
> information.
> > > str = ""
> > > for c in range(140, 169):
> > >  str += chr(c) + " "
> > >
> > > print(str)
> > > Œ   Ž ‘ ’ “ ” • – — ˜ ™ š › œ   ž Ÿ   ¡ ¢ £ ¤ ¥
> > > ¦ § ¨
> > >
> > >
> > > I don't know how this will appear since Pan is showing the icon for a
> > > character not in its set.  However, even with more undefined characters
> > > the printable one do not change. I get the same output running Python3
> > > from the terminal so it's not an IDLE thing.
> >
> > I'm not sure what explanation is being asked for here.  Let's take
> Python3,
> > so we can be sure that the strings are in unicode.  The font being used
> by
> > the console isn't mentioned, but there's no reason it should have glyphs
> for
> > any random unicode character.
>
> Also note that the characters between 128 (U+0080) and 159 (U+009F)
> inclusive aren't printable characters. They are control characters.
>
> hp
>
> --
>_  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | http://www.hjp.at/ |   challenge!"
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: IDLE "Codepage" Switching?

[Peter J. Holzer]

On 2023-01-17 22:58:53 -0500, Thomas Passin wrote:
> On 1/17/2023 8:46 PM, rbowman wrote:
> > On Tue, 17 Jan 2023 12:47:29 +, Stephen Tucker wrote:
> > > 2. Does the IDLE in Python 3.x behave the same way?
> > 
> > fwiw
> > 
> > Python 3.10.6 (main, Nov 14 2022, 16:10:14) [GCC 11.3.0] on linux
> > Type "help", "copyright", "credits" or "license()" for more information.
> > str = ""
> > for c in range(140, 169):
> >  str += chr(c) + " "
> > 
> > print(str)
> > Œ  Ž   ‘ ’ “ ” • – — ˜ ™ š › œ  ž Ÿ   ¡ ¢ £ ¤ ¥
> > ¦ § ¨
> > 
> > 
> > I don't know how this will appear since Pan is showing the icon for a
> > character not in its set.  However, even with more undefined characters
> > the printable one do not change. I get the same output running Python3
> > from the terminal so it's not an IDLE thing.
> 
> I'm not sure what explanation is being asked for here.  Let's take Python3,
> so we can be sure that the strings are in unicode.  The font being used by
> the console isn't mentioned, but there's no reason it should have glyphs for
> any random unicode character.

Also note that the characters between 128 (U+0080) and 159 (U+009F)
inclusive aren't printable characters. They are control characters.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


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