[issue44330] IDLE: Colorizer and output tests hang on macOS
Change by Terry J. Reedy : -- title: IDLE: Colorizer test hangs on macOS -> IDLE: Colorizer and output tests hang on macOS ___ Python tracker <https://bugs.python.org/issue44330> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44330] IDLE: Colorizer test hangs on macOS
New submission from Terry J. Reedy : Ned, have you seen or heard anything about tkinter/tk8.6.11 freezing on macOS? It is happening in many places. On my MacBook, python3.9 -m test -ugui -v test_idle runs OK in about 10 seconds. With installed python3.10.0b2, it runs test_colorizer ColorCongigTest, ColorDelagatorInstantionTest, and ColorDelagatorTest.test_LoadTagDefs. It hangs on test_case_soft_keyword, which is new in 3.10 for the new match statement soft keywords. With added skips, it hangs on test_def_statement test_incremental_editing test_match_soft_keyword test_recolorize_main test_removecolors and then test_colorizer passes. At this point, I thought the problem was the fancy new test methods and helpers. But running test_idle again, test_outwin.OutputWindowTest.test_goto_file_line (line 105) hangs displaying a blank window. The test writes something at 115 which did not appear. However, debug prints indicate that it is the 2nd write, about 121, that does not return. The write method just inserts into the text widget. Nothing apparently fancy. The failure is deterministic (over 10 times). In 3.9.5, the same test and all of test_idle ran OK 3 times. Adding .update() and .update_idletasks() before the write did nothing. Making this test method fail before the write, let the test continue until it hung in test_write. The problem seems to be in the test environment. Tests of match, case, and _ in Shell looked corrected. Grepping idlelib for 'tkinter' returned 222 hits and multiple gotos for different files and lines within a file worked normally. -- messages: 395239 nosy: ned.deily, taleinat, terry.reedy priority: normal severity: normal status: open title: IDLE: Colorizer test hangs on macOS versions: Python 3.10, Python 3.11 ___ Python tracker <https://bugs.python.org/issue44330> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44325] IDLE: Fix shell comment anomalies
Terry J. Reedy added the comment:
I added debug prints to _maybe_compile and confirmed
1) trailing whitespace (' ' and '\t' at least) is removed before this function
is called. I presume in IDLE rather than code.II, but cannot find where. It
is not with .rstrip. (Note: doing so after '\' is a bug in that it lets buggy
input such as 'a\ \n + 2' run instead of raising.)
2. code is otherwise delivered intact and blanks lines become 'pass'. Thus any
difference noted above is not due to compile().
The report was based on Windows with 3.9.5, 3.10.0b2, and fresh main. I
repeated the Shell experiments on a Mac Airbook, and a slower machine, with
3.10.b1. There was never a spurious ... -- once the proper >>> was printed.
However, I sometimes saw ... appear very briefly, only to be overwritten with
>>>. (I saw this once, *very briefly*, on Windows with main, on the first
comment I tried.) I also saw ... appear and disappear when there was a
SyntaxError or print output. I suspect that Sidebar always adds ..., only to
be deleted or overwritten when it is a mistake.
I then tried 3.9.5 on the Mac and saw a spurious blank line with ' # a' once,
on the first try, but not again in several attempts. There seems to be a
'warmup' effect.
My conclusion so far: sidebar might be a culprit, but because of the 3.9
behavior, I think it more likely a victim of pyshell prematurely marking the
new line as a possible continuation line. As long as there was not
continuation prompt, this might seem innocuous. But it might also be a factor
in other spurious blank lines. In particular,
>>> if 1: # Hit return on indented line.
... print(2)
...
... < undeleted 4 space indent
2
>>> if 1: # Delete indent first. Get proper behavior.
... print(2)
...
2
>>>
I am stopping here. Tal, what do you think with your better knowledge of
pyshell internals?
--
___
Python tracker
<https://bugs.python.org/issue44325>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44325] IDLE: Fix shell comment anomalies
New submission from Terry J. Reedy :
Spinoff from #38673, about standard REPL, msg356271 (me) and msg356348 (Guido).
In the following interactions, no blank lines were entered.
3.9 behavior
>>> #a
>>> # a
>>> #a
>>> # a
>>>
Mystery 1: why the blank continuation line?
I previously wrote
"ast.dump(ast.parse(' # a\n', '', 'single')) gives the same result,
'Module(body=[], type_ignores=[])', as without [space after #]".
Today, 3.8.10, 3.9.5, 3.10, and 3.11 say "unexpected EOF while parsing".
3.10 behavior
>>> #a
...
>>> # a
>>> #a
>>> # a
...
>>>
Mystery 2: why the new continuation line after '#a'?
3.11 behavior
>>> #a
>>> # a
>>> #a
>>> #a
>>> # a
...
>>>
Mystery 3: why does the 3.10 regression for '#a' disappear?
Perhaps IDLE should handle initial blank lines itself, but I will investigate
what codeop._maybe_compile is getting and doing in the different cases first.
--
messages: 395214
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: test needed
status: open
title: IDLE: Fix shell comment anomalies
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44325>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43610] Ctrl C makes interpreter exit
Terry J. Reedy added the comment: I verified that sndhdr.what(0) calls "with open(0, rb)" so that Eryk's comment applies. (On Windows, handle 0 is invalid, so the call errors immediately instead of hanging.) -- nosy: +terry.reedy resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44322] Document SyntaxError args and interpretation for f-string fields
Change by Terry J. Reedy : -- keywords: +patch pull_requests: +25151 pull_request: https://github.com/python/cpython/pull/26562 ___ Python tracker <https://bugs.python.org/issue44322> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44322] Document SyntaxError args and interpretation for f-string fields
New submission from Terry J. Reedy :
Document that SyntaxError args[1] is a tuple of the other attributes and how
the meaning of the attributes is adjusted when the syntax error is in an
f-string field replacement expression. Also add compile() to the list of
builtins that can raise SyntaxError.
PR to follow immediately. I wrote most of the text so that it works for 3.9
and 3.10+, with the new end info. In the example, the main part of the message
changed from "invalid syntax" to "invalid syntax. Perhaps you forgot a comma?".
I hid that with '...' but each could be given in the respective versions.
args[1] changes from "('', 1, 4, '(a b)\n')" to "('', 1, 2, '(a b)\n', 1, 5)"
and that will have to be changed in a 3.9 backport.
Spinoff from #43705. I will create a separate issue for using this information
in IDLE.
--
assignee: docs@python
components: Documentation
messages: 395208
nosy: ammar2, docs@python, pablogsal, terry.reedy
priority: normal
severity: normal
stage: patch review
status: open
title: Document SyntaxError args and interpretation for f-string fields
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44322>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44265] Create an MSI Package
Change by Terry J. Reedy : -- versions: -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue44265> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44310] lru_cache memory leak
Change by Terry J. Reedy : -- versions: -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue44310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44309] Add support for yescrypt in crypt.
Change by Terry J. Reedy : -- nosy: +jafo ___ Python tracker <https://bugs.python.org/issue44309> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44307] date.today() is half as fast as datetime.now().date()
Change by Terry J. Reedy : -- title: date.today() is 2x slower than datetime.now().date() -> date.today() is half as fast as datetime.now().date() ___ Python tracker <https://bugs.python.org/issue44307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44304] segmentation fault appeared in python 3.10.0b2
Terry J. Reedy added the comment: Coredevs are likely to assume that the problem is in greenlets, especially if it has any C code (I don't know). I suggest you first try to find the commit between releases that resulted in the problem. If it is not deterministicly reproducible, you likely need to do a manual binary search. (This is as much as I know.) If you get an OS 'traceback' longer than a dozen line or so, please attach it as a file rather than pasting in a message. -- nosy: +terry.reedy type: -> crash ___ Python tracker <https://bugs.python.org/issue44304> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44301] Is there a way to provide destructor for module written using C API?
Change by Terry J. Reedy : -- versions: -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue44301> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44276] Replace if-elif-else structure with match-case (PEP634)
Terry J. Reedy added the comment: To me, Raymond's flattening is a plausible replacement, especially ater a future speedup. However, I would re-order the patterns to None, False, True, str(), int(), ..., _. These independent conditions, other than _ (or else in the if chain), can be ordered for best reading and comprehension speed, and I think the above is an improvement. Ordering for execution speed would instead start with the most frequently true conditions. An advantage of match over 'if' is that patterns are apparently easier to re-order or otherwise automatically optimize. I agree that replacement should only be done when there is significant improvement in reading and/or execution speed. To avoid backport issues, they should best be preceded by a check for bug reports and especially PRs that will or do affect the same area of code. The proposal for a general, +- global replacement has been and will be rejected. I think that this issue should therefore be closed, fairly soon, as such. -- nosy: +terry.reedy ___ Python tracker <https://bugs.python.org/issue44276> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44275] Is there a mojibake problem rendering interactive help in the REPL on Windows?
Terry J. Reedy added the comment: Jesse or Andre, please test interactive help in IDLE as pydoc then knows that it is *not* talking to Windows console. It then does not use more.com but prints the entire text at once. It should send it 'as is' and should ignore the console language and encoding settings. Use a Start menu icon or > pyw -m idlelib 'py' works too. It blocks, but displays the occasional tk/tkinter/IDLE error message as sys.__stderr__, etc, are the console stream instead of None. Long output such as the 240 lines for COMPARISON is, by default, 'squeezed' to a little box. Double click to expand or right click to move it to a separate window. If there is still a problem with garbage in the text, we should try to fix it. PS: one can select more than one Component, but Documentation usually refers to the content, not the means of displaying it. -- nosy: +terry.reedy ___ Python tracker <https://bugs.python.org/issue44275> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44266] AttributeError: module 'sys' has no attribute 'original_stdout'
Terry J. Reedy added the comment: If you intend to import the stdlib sys and succeed, the original stdout is called '__stdout__'. See https://docs.python.org/3/library/sys.html#sys.__stdin__, including the note that it may be None on Windows. Also peruse that doc to see what attributes sys *does* have. When you have questions about using python, please post first to python-list or other question-answering forums. -- nosy: +terry.reedy resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31552] IDLE: Convert browswers to use ttk.Treeview
Terry J. Reedy added the comment: Concrete reason 3. Treewidget does not work on high-res monitors. The #37041 quick Treeview test worked for Andre Roberge -- nosy: +aroberge versions: +Python 3.11 -Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue31552> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44282] IDLE: ColorDelegatorTest test_incremental_editing failures
Change by Terry J. Reedy : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44282] IDLE: ColorDelegatorTest test_incremental_editing failures
Terry J. Reedy added the comment: The other thing I thought is parameterizing the decorator to pass in a delay only for this test, but that require another layer of wrapping, which I cannot do right now. So I think we should just add skiptest for now. In fact, we only need to run it when editing colordelagator. -- ___ Python tracker <https://bugs.python.org/issue44282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44282] IDLE: ColorDelegatorTest test_incremental_editing failures
Terry J. Reedy added the comment: The confusion is my fault: PR-26404 is where I first saw this failure, for the previously added tests, not where the test was added. I unlinked the erroneous message. Running 12 duplicate tests in parallel on Windows on a 6 core (12 CPU) machine with f:\dev\3x>python -m test -j12 -ugui -m test_incremental_editing test_idle test_idle test_idle test_idle test_idle test_idle test_idle test_idle test_idle test_idle test_idle test_idle resulted in nearly all failing. Half or less failed with -j6, usually one with -j3, none without -j. Are the processess failing because of interaction with each other? Or from be switched with other processes? Back with -j12: increasing the after delay in run_in_tk_mainloop from 1 to 5 cut the failures down to 0-4 in 12. Increasing further to 8 resulting in no failures. Note that human keystrokes are at least, say, 50 milliseconds (1/20 second) apart. I am reluctant to add a delay that is mostly not needed, so i tried the uploaded 'adaptive' code to only add a long delay if needed. Uploaded. But when a tested failed once, it failed again even with the delay, and contrary to the results above. -- Added file: https://bugs.python.org/file50084/tkinter_testing_utils.py ___ Python tracker <https://bugs.python.org/issue44282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44282] IDLE: ColorDelegatorTest test_incremental_editing failures
Change by Terry J. Reedy : -- Removed message: https://bugs.python.org/msg394871 ___ Python tracker <https://bugs.python.org/issue44282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41611] IDLE: problems with completions on Mac
Change by Terry J. Reedy : -- pull_requests: -25083 ___ Python tracker <https://bugs.python.org/issue41611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43654] IDLE: Fix tab completion after settings and some keys
Terry J. Reedy added the comment:
Currently, the keys that define certain pseudoevents and invoke the associated
event handlers are fixed: tab, '.', and within strings, '/' and '\' for
completions, '(' and ')' for calltip open and close, and ')', ']', and '}' for
opener matching. Note that quote matching is indicated by coloring completed
strings.
PR-26421 proposes to augment this list with tab for smart indent, backspace for
smart backspace, and newline for completing a line and maybe smart indenting.
In other words, remove the following 3 lines
'<>': [''],
'<>': ['', ''],
'<>': [''],
from config-keys.def and the Settings Keys tab and add them as fixed binding to
EditorWindow.__init__ just above the existing fixed pseudoevent -- keys
bindings.
Only fixing smart-indent and tab (or unfixing name-completion and tab) is
needed to keep name completion working after re-doing setting. So why all
three? 1. These three pairs go together; I don't see anything else that should
be fixed. 2. By the standard used to fix some pairs already, these three
should be also. I think it an accident of IDLE's history that they aren't*.
3. It might be that changing either of the other two binding could disable
something, or might in the future. In other words, I consider having this
bindings be mutable to be a bit buggy, with this issue being evidence.
* Multiple coders, coding convenience, shift of focus from 'consenting adults
to 'beginners'?
The unknown is whether anyone has changed these pseudoevent bindings and if so,
how much do we care?
Guido, do you have any comment on this proposal from a change policy
perspective?
--
nosy: +gvanrossum
title: IDLE: Applying settings disables tab completion -> IDLE: Fix tab
completion after settings and some keys
___
Python tracker
<https://bugs.python.org/issue43654>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44282] IDLE: ColorDelegatorTest test_incremental_editing failures
New submission from Terry J. Reedy :
idlelib.idle_test.test_colordelagator.ColorDelegatorTest.test_incremental_editing
has failed on at least on the following machines.
Pip32 CI Pipelines Win32
Gen3x https://buildbot.python.org/all/#/builders/464 x86 Gentoo Installed
with X 3.x
GenPR https://buildbot.python.org/all/#/builders/465 x86 Gentoo Installed
with X PR
Failures seen. Since tests are sequential without subtesting, failure means
successors are not tested.
line keyword start wantgot
569 ('BUILTIN', '1.0'), ('1.0', '1.3') () Gen3x, x3; GenPR
573 ('BUILTIN', '1.0'), ('1.0', '1.3') () Gen3x, x5
586 ('BUILTIN', '1.0'), ('1.0', '1.3') () GenPR
597 ('KEYWORD', '1.0'), () ('1.0', '1.1') Pip32, x2
As far as I can tell, looking at Windows buildbots, the 1 failure on Win32 has
not been repeated. If there have been any on CI machines, I have not been
informed.
A few years ago, I believe Gentoo was the only *nix buildbot running tkinter
and IDLE tests. It has a problem with a builtin at the beginning of the line
about 10-20% of test runs. This are the majority of its failures in the last
week. Perhaps there is a timing issue we can fix.
--
assignee: terry.reedy
components: IDLE, Tests
messages: 394870
nosy: taleinat, terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: ColorDelegatorTest test_incremental_editing failures
type: behavior
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue44282>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44282] IDLE: ColorDelegatorTest test_incremental_editing failures
Terry J. Reedy added the comment: Followup to PR-26404, which added the tests. -- ___ Python tracker <https://bugs.python.org/issue44282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Terry J. Reedy added the comment: New changeset 9bcb76c24f6d3f01e596a439c1521f9099e3fe80 by Miss Islington (bot) in branch '3.9': bpo-44254: On Mac, remove disfunctional colors from turtledemo buttons (GH-26448) https://github.com/python/cpython/commit/9bcb76c24f6d3f01e596a439c1521f9099e3fe80 -- ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Terry J. Reedy added the comment: New changeset addd32986f703e692463828ac0014023a901010f by Miss Islington (bot) in branch '3.10': bpo-44254: On Mac, remove disfunctional colors from turtledemo buttons (GH-26448) https://github.com/python/cpython/commit/addd32986f703e692463828ac0014023a901010f -- ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Terry J. Reedy added the comment: New changeset af5a324843de395cecc562cb0c757b3768f2077f by Terry Jan Reedy in branch 'main': bpo-44254: On Mac, remove disfunctional colors from turtledemo buttons (GH-26448) https://github.com/python/cpython/commit/af5a324843de395cecc562cb0c757b3768f2077f -- ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Terry J. Reedy added the comment: I picked a bluish green that works on both white and black on Windows. Test is you can and wish. -- ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Terry J. Reedy added the comment: Of course, I cannot set the background on my Mac, so I will test on Windows and let you verify on dark theme mac -- ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Terry J. Reedy added the comment: I presume you tested pr_26448. If default colors do not work, that is on tcl/tk. I suspect 8.6.11 is not prepared for dark theme. The underlying bug is ignoring the tk/user setting and deferring to the system for background only. In the meanwhile, I will try to set the forground to something at least readable on either background. Is the dark theme background black as opposed to dark something? -- nosy: +taleinat stage: patch review -> needs patch ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Change by Terry J. Reedy : -- keywords: +patch pull_requests: +25042 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/26448 ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Terry J. Reedy added the comment:
Ned, could you check the darwin osascript in turtledemo.__main__, lines 138-149
is current (both needed and correct)?
subprocess.run(
[
'osascript',
'-e', 'tell application "System Events"',
'-e', 'set frontmost of the first process whose '
'unix id is {} to true'.format(os.getpid()),
'-e', 'end tell',
],
stderr=subprocess.DEVNULL,
stdout=subprocess.DEVNULL,)
The one line could be an fstring now.
--
___
Python tracker
<https://bugs.python.org/issue44254>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
Terry J. Reedy added the comment: I am going to disable color config on darwin (and hope it gets into b2). The default should always work. -- ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30495] IDLE: modernize textview module
Change by Terry J. Reedy : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue30495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44259] lib2to3 does not accept "exec" as name
Terry J. Reedy added the comment: 'exec' was a keyword in 2.x, but that should not matter in 3.9. What OS? Did you get an actual crash (core dump on *nix), or a python exception and traceback (not a crash)? If the latter, copy and paste it. -- nosy: +terry.reedy ___ Python tracker <https://bugs.python.org/issue44259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44249] Readme typo fix
Change by Terry J. Reedy : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: enhancement -> behavior versions: +Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44249] Readme typo fix
Terry J. Reedy added the comment: New changeset 7261b29fa90d22f6cb5f3c94a3dbbf7978c6f448 by Miss Islington (bot) in branch '3.10': bpo-44249: Fix 3 README.rst typos (GH-26385) https://github.com/python/cpython/commit/7261b29fa90d22f6cb5f3c94a3dbbf7978c6f448 -- ___ Python tracker <https://bugs.python.org/issue44249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44249] Readme typo fix
Terry J. Reedy added the comment: New changeset 8f8f2ea832949fd9cd76c7a7924f346b316fb610 by Miss Islington (bot) in branch '3.9': bpo-44249: Fix 3 README.rst typos (GH-26385) https://github.com/python/cpython/commit/8f8f2ea832949fd9cd76c7a7924f346b316fb610 -- ___ Python tracker <https://bugs.python.org/issue44249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44249] Readme typo fix
New submission from Terry J. Reedy : New changeset acac6c71ff370413374c6aca1df808c426e8a30c by Ayush Parikh in branch 'main': bpo-44249: Fix 3 README.rst typos (GH-26385) https://github.com/python/cpython/commit/acac6c71ff370413374c6aca1df808c426e8a30c -- nosy: +terry.reedy ___ Python tracker <https://bugs.python.org/issue44249> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44215] help() module listing displays import warnings from deprecated package modules
Change by Terry J. Reedy : -- versions: -Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue44215> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44225] stop() on a stopped loop inhibits the next run_forever
Change by Terry J. Reedy : -- versions: -Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44225> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44211] Duplicate '.bmp' key in mimetypes.py, maps to both 'image/bmp' and 'image/x-ms-bmp'
Terry J. Reedy added the comment: David and Steve merged the seemingly conflicting PRs. -- nosy: +r.david.murray, steve.dower, terry.reedy versions: +Python 3.11 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue44211> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43654] IDLE: Applying settings disables tab completion
Terry J. Reedy added the comment: Tal, I think you had the right solution the first time. To me, tab is (should be) a fixed key, and the event added just once, like the other fixed keys. I am quite surprised that it isn't. Please revise or make a new patch to remove it from both configkeys.def and config.py. Even if I agreed with unfixing other keys, only <> would need rebinding, not an arbitrary subset of the fixed keys. We mostly did away with treating some features differently; what remains was mostly an expedient to get a too-big patch merged. I meant and still mean to finish the job. -- ___ Python tracker <https://bugs.python.org/issue43654> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44243] tkinter button colors on Mac
Change by Terry J. Reedy : -- resolution: -> third party stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23937] IDLE: revise window size, placement startup options
Terry J. Reedy added the comment: When I changed the title, I intended to broaden the issue beyond 'start maximized'. Even for that, there are two possibilities. 1. Configure option (default as now). 2. Save 'current' position, which helps non-maximizers also. So I am inclined to the latter with some definition of current. If we add multiple panes, maximized will make more sense. There is a subtle issue easy to not notice. Scrolling is slightly different when the window height an integral number of lines, as it now is on startup, or pixels, as after resizing with zoom or mouse grab. I believe 'lines' is enough better that I have considered snapping to 'lines' after changes. Not now though. The Settings dialog height is currently determined by the General tab. It is already too high for some notebooks: on my macbook, I can barely click OK (with 'OK' not visible) *after* putting the app bar on the side rather than bottom. We need to squeeze existing items rather than add another. -- ___ Python tracker <https://bugs.python.org/issue23937> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31790] double free or corruption (while using smem)
Terry J. Reedy added the comment: pydev core has not touched 2.7 in a year. Anyone else maintaining 2.7 has had a chance to grab 2.7 issues. So all 2.7 issues should be closed unless obviously relevant to current issues (and even then have 2.7 removed). I agree that the later does not apply here. -- resolution: -> wont fix stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue31790> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44243] tkinter button colors on Mac
Terry J. Reedy added the comment: #44254 is a followup to change turtledemo unpressed button colors to something on white. -- ___ Python tracker <https://bugs.python.org/issue44243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44254] Change turtledemo button colors
New submission from Terry J. Reedy : [Following up on #44243.] tk/tkinter-based turtledemo buttons are currently white on something. On Mac, configured foreground button colors are honored (while the button is unpressed), while background colors are ignored. Given that the unpressed default is black on white, the configured result of white on something is white on white. I don't like the current colors anyway, so I think we should change to something on white. I am thinking of green, red, and blue for Start, Stop, and Clear. -- components: Library (Lib) messages: 394597 nosy: terry.reedy priority: normal severity: normal stage: needs patch status: open title: Change turtledemo button colors type: behavior versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44254> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44243] tkinter button colors on Mac
Terry J. Reedy added the comment: "The configure and cget subcommands can still manipulate the values, but do not cause any variation to the look of the widget." is wrong. Setting the foreground color *does* change the unpressed foreground color, so that 'white' becomes 'white on white'. I consider not being more explicit about which options are or or not fixed, or at least not warning about foreground, to be a doc buglet. What a trap for someone trying to make a cross-platform dark theme. But their docs are theirs. And our docs are ours. We can't change external tk or ttk docs, but how about adding the following to the our ttk doc, just above 'Combobox'? Button On macOS, the pressed colors are fixed as white on blue. The background is otherwise fixed as white. So an attempt at white on dark results in white on white. -- stage: -> needs patch type: -> behavior ___ Python tracker <https://bugs.python.org/issue44243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41611] IDLE: problems with completions on Mac
Terry J. Reedy added the comment: The completion freeze fix is easily backported to non-Windows installations. 1. Run IDLE 2. File => Open Module, enter 'idlelib.autocomplete_w', OK. 3. Goto line 247 (3.9) or 250 (3.10) with "acw.update". 4. Add # in from of above to disable it. 5. Save and close IDLE, then restart. For me, with 3.10.0b1, this restores full functions, with boxes appearing as appropriate. With 3.9.5, no freeze by also no box. 2 or 3 tabs brings up first match. 'pr' = print, 'int.' = int.as_integer_ratio. As far as I know, the file is the same in both versions. Both versions are the same in Shell and Editor, so it is not the improved 3.10 shell. -- ___ Python tracker <https://bugs.python.org/issue41611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41611] IDLE: problems with completions on Mac
Terry J. Reedy added the comment: With 3.10.0b1 on Mac I am getting attribute completion freezes. I had to turn them off. I am tempted to disable completions until there is a Mac IDLE developer to dig into issues like this. -- nosy: +taleinat ___ Python tracker <https://bugs.python.org/issue41611> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44243] tkinter button colors on Mac
Change by Terry J. Reedy : -- nosy: +serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue44243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44243] tkinter button colors on Mac
New submission from Terry J. Reedy :
Mac Mohave, 3.9 with 8.6.8 and 3.10 with 8.6.11
import tkinter as tk
r = tk.Tk()
b = tk.Button(r, text='START', fg='white', bg='red') # Or '#f00'.
b.pack()
r.mainloop()
On Windows, white on red button, as expected. On Mac, all white until one
presses and holds mouse, and then blue background. Default black on white
works OK.
This may be new since several years ago, when 2 of us worked on turtle demo,
which has 3 such buttons. They all now misbehave (reported by Raymond). If
someone tested on Mac, it must have worked then.
I retried with the b= line replaced with
s = ttk.Style()
s.configure('Td.TButton', foreground='white', background='red')
b = ttk.Button(r, text='START', style='Td.TButton')
with the same result. (Mark, did I get this right?)
--
components: Tkinter, macOS
messages: 394506
nosy: markroseman, ned.deily, rhettinger, ronaldoussoren, taleinat, terry.reedy
priority: normal
severity: normal
status: open
title: tkinter button colors on Mac
versions: Python 3.10, Python 3.11, Python 3.9
___
Python tracker
<https://bugs.python.org/issue44243>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37903] IDLE Shell sidebar.
Terry J. Reedy added the comment: I will link to an IDLE shell followup issue later. Discussions about other IDLE issues should be on pre-existing issues (use the tracker search with Components: IDLE), new issues, or without an issue, on the idle-dev list. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42109] Use hypothesis for testing the standard library, falling back to stubs
Terry J. Reedy added the comment:
In order to understand what Paul is concretely proposing, I read and partly
reviewed his PR. I thought about maintainability.
Part A adds test.support.hypothesis_helper, similar in purpose to other
specialized xyz_helper modules. Hypothesis_helper imports either hypothesis
itself or a replacement 'as hypothesis'. The replacement is currently called
'_hypothesis_stub', but its name is irrelevant as it is normally not seen by
the user.
Part B adds a second zoneinfo test module, one that uses hypothesis. Besides
further testing zoneinfo, it serves to test hypothesis_helper and partly
justify its addition. It starts with 'from hypothesis_helper import
hypothesis. The new test module has tests such as
@hypothesis.given(
dt=hypothesis.strategies.one_of(
hypothesis.strategies.datetimes(), hypothesis.strategies.times()
)
)
@hypothesis.example(dt=datetime.datetime.min)
@hypothesis.example(dt=datetime.datetime.max)
@hypothesis.example(dt=datetime.datetime(1970, 1, 1))
@hypothesis.example(dt=datetime.datetime(2039, 1, 1))
@hypothesis.example(dt=datetime.time(0))
@hypothesis.example(dt=datetime.time(12, 0))
@hypothesis.example(dt=datetime.time(23, 59, 59, 99))
def test_utc(self, dt):
zi = self.klass("UTC")
dt_zi = dt.replace(tzinfo=zi)
self.assertEqual(dt_zi.utcoffset(), ZERO)
self.assertEqual(dt_zi.dst(), ZERO)
self.assertEqual(dt_zi.tzname(), "UTC")
@given always (Paul?) runs the examples as subtests. When the replacement is
imported, no randomized examples are added.
If some year an example were to fail, could a hypothesis-ignorant
zoneinfo-knowing person deal with the failure? I believe so, knowing that the
above is equivalent to a test with "for dt in dt_list:\n with
self.subTest(...):\n"
Why not require such a rewriting? Some reasons against: Rewriting by hand can
lead to errors. test_utc would have to be split into test_utc_ran(dom) and
test_utc_pre(set). Code would have to be duplicated unless factored into a
third function. For and with together add two indents, which sometimes
squeezes assert onto more lines. I believe that when hypothesis is present,
there are advantages to including preset examples with given-generated examples.
Paul would like the PR to be a 'camel's nose' in the CPython tent. This cuts
both ways. I think this PR should be judged on its own merits. Opening
possibilities can be a merit as long as not seen as pre-approval. Our CI
testing and buildbots are already configured to blame and annoy the wrong
people for random failures. I don't want more unless failure notices are sent
to someone responsible for the failing code.
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue42109>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44217] Tkinter/IDLE: literal astral char discombobulates text editing
Terry J. Reedy added the comment:
This is fundamentally a tk text widget issue. Prior to fall 2019, attempts to
insert an astral (non-BMP) chars in tkinter widgets raised a unicode decode
exception. Then Serhiy fixed tkinter so that such chars could be displayed,
either as the actual chars or as a replacement box for unavailable chars.
There were 2 remaining problems:
1. The presence of the literal astral char in an editable widget, especially a
Text widget, make editing past the char weird. It can be demonstrated with,
for instance, the following.
import tkinter as tk
r = tk.Tk()
t.insert = tk.Text(r); t.pack()
t.insert('insert', "ab'ab'ab)\n"
We decided that beings able to output such chars to the view-only part of shell
more than made up for confusion such as Shreyan experienced.
Re-experimenting now, it appears that the behavior is worse in IDLE. In
particular, backspace delete does not work (nothing happens). IDLE intercepts
in order to invoke its smart backspace routine. I will try to find
out why nothing happens. Whatever the result, the behavior should be better
documented.
The 8.7a3 was released Nov 2019, so I have no idea how soon 8.7 will arrive.
Maybe the devs found enough bugs to work on, especially on Mac. And then
8.6.11 was needed to have tcl/tk work on the new Apple hardware and OS version.
2. On some Linux systems with some fonts with some XWindows, attempts to
display some colored chars (such as particular emoji), in color, causes an
XWindows error ('too complex'). This is a Linux-Xwindows-font bug.
--
nosy: +taleinat
title: [IDLE] Weird behaviour in IDLE when printing non-BMP unicode characters
-> Tkinter/IDLE: literal astral char discombobulates text editing
___
Python tracker
<https://bugs.python.org/issue44217>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44190] Dictionary assignment shorthand
Change by Terry J. Reedy : -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44190> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43927] Remove IOError references from the tutorial
Change by Terry J. Reedy : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue43927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44038] In documentation Section 8.6, the definition of parameter_list need correcting
Terry J. Reedy added the comment: After mentally reparsing and translating to English, I think you are right. -- ___ Python tracker <https://bugs.python.org/issue44038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43927] Remove IOError references from the tutorial
Terry J. Reedy added the comment: IOError is a back-compatibility synonym for OSError. I will eliminate the last use from all 3 versions. The change to the previous example was done by 2 people who did not backport to 3.9 and I will not bother with that. Future versions are already fixed. -- stage: patch review -> versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue43927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43927] Remove IOError references from the tutorial
Change by Terry J. Reedy : -- keywords: +patch nosy: +terry.reedy nosy_count: 2.0 -> 3.0 pull_requests: +24893 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26289 ___ Python tracker <https://bugs.python.org/issue43927> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44038] In documentation Section 8.6, the definition of parameter_list need correcting
Terry J. Reedy added the comment: I *think* that another bracket pair is needed, changing "," "/" to ["," "/"] -- nosy: +pablogsal, terry.reedy versions: +Python 3.11 -Python 3.9 ___ Python tracker <https://bugs.python.org/issue44038> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44069] pathlib.Path.glob's generator is not a real generator
Terry J. Reedy added the comment: I agree that from the outside is seems slightly bizarre to make an internal list to implement a function documented as returning an iterator. However, list(scandir) was added by Serhiy in #26032 with the comment that it made globbing 1.5-4 times faster. This is, of course, if one runs the iterator to completion, as is the normal use. For your presented use case, I suggest something like the following: next(f for f in scandir(path) if os.path.splitext(f)[1] == '.txt') -- nosy: +terry.reedy versions: -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44069> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44163] IDLE ValueError in HyperParser
Terry J. Reedy added the comment: For now, I want to just improve the error message and then close. -- ___ Python tracker <https://bugs.python.org/issue44163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44163] IDLE ValueError in HyperParser
Terry J. Reedy added the comment: So, consider both possibilities where relevant. In the future, I will assume that you are running standard, up-to-date, Mac build unless you say otherwise. I presume you start IDLE from terminal and check it before shutting down. I have wondered whether it might be worthwhile to try to catch the occasional messages even when running from an icon. Seems it might be. This conditional exception was part of the 2005 merge of the separate IDLE branch. So there is no history to say whether 'just-in-case' or known trigger. -- ___ Python tracker <https://bugs.python.org/issue44163> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44163] IDLE ValueError in HyperParser
Terry J. Reedy added the comment:
Thank you for the report. Which 3.9.? hyperparser has not changed in a year,
but some of the calltip logic has.
This occurred when you typed a '(' and IDLE tried to open a calltip but failed,
and you did not notice its absence. Easy when not looking for it to help
complete the call, especially when others are around. Do you have any idea if
more likely to have been in editor or shell, or did you use a mix of both?
The preceding lines are
indexinrawtext = (len(self.rawtext) -
len(self.text.get(index, self.stopatindex)))
if indexinrawtext < 0:
The resolution of this issue might be augment the error message to print the
window type, the index as line.col as well as 'insert', the two lengths, and at
least part of the text.
We should perhaps look at other callback error messages that IDLE raises.
--
nosy: +taleinat
___
Python tracker
<https://bugs.python.org/issue44163>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40452] Tkinter/IDLE: preserve clipboard on closure
Terry J. Reedy added the comment: Tcl_Finalize can be called more than once, says the tcl doc. It also says it, or T_FThread should be called when unloading. If the tcl implementation on some system does not match the doc, then there is a bug that should be reported. If the registration is done by tkinter, rather than IDLE, then all tkinter apps benefit. -- versions: +Python 3.8 -Python 3.11 ___ Python tracker <https://bugs.python.org/issue40452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40452] Tkinter/IDLE: preserve clipboard on closure
Terry J. Reedy added the comment: As Tal notes on the PR, the _tkinter patch is the minimum needed to fix the problem for IDLE, not the undetermined patch to tkinter that should be done to properly expose the fix to all tkinter users. If the tcl function were exposed with a presumably temporary private name, '_finalize_tcl', rather than a public name, 'finalize_tcl', then I presume we should be able to backport without question. -- ___ Python tracker <https://bugs.python.org/issue40452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40452] Tkinter/IDLE: preserve clipboard on closure
Terry J. Reedy added the comment:
Can we backport? The change to _tkinter, not directly exposed in tkinter,
could be considered an enhancement, but is necessary to fix what I consider a
real bug in tkinter, and hence in IDLE.
Pablo, would you allow the _tkinter change in .0b2?
If we cannot backport the _tkinter change, can the tcl function be accessed
through root.tk.call('')? I am guessing that 'exit' exits the process from
tcl, which is probably not what we want.
https://www.tcl.tk/man/tcl8.6/TclLib/Exit.htm
suggests that when tcl is loaded as an extention, Tcl_Finalize should be called
instead of Tcl_Exit to *not* exit the process.
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue40452>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40452] Tkinter/IDLE: preserve clipboard on closure
Terry J. Reedy added the comment: Tal: cancel comment above. I was confused because FinalizeThread is exposed as just finalize. On Windows, PR fixes issue whether Shell or editor is closed last. -- ___ Python tracker <https://bugs.python.org/issue40452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40452] Tkinter/IDLE: preserve clipboard on closure
Terry J. Reedy added the comment: Serhiy: what do you know of tcl finalization? Tal: why does your patch only expose the option that you said crashes ubuntu. Spacekiwigames: if you have a cpython fork and local repository, you could try the patch on your linux mint. -- nosy: +Spacekiwigames, serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue40452> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24964] Add tunnel CONNECT response headers to httplib / http.client
Terry J. Reedy added the comment: Alexey, to repeat what I said to Thomas above: please sign a contributor agreement for your patches to be considered. https://www.python.org/psf/contrib/ https://www.python.org/psf/contrib/contrib-form/ -- ___ Python tracker <https://bugs.python.org/issue24964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24964] Add tunnel CONNECT response headers to httplib / http.client
Change by Terry J. Reedy : -- versions: +Python 3.11 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue24964> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13498] os.makedirs exist_ok documentation is incorrect, as is some of the behavior
Terry J. Reedy added the comment: This issue was really two issues: fix doc of existing behavior; change behavior (which would be an enhancement). The first has been done; the second not. I think this should be closed and if anyone still proposes the second, open a new enhancement issue for 3.11, referencing this one, that clearly lays out the proposed change and rationale, given the 3.10 status quo. (I have no opinion about the proposed change.) Once someone submits a patch, we are free to change it before or after applying it. But before, we give the author first crack and wait a week or so for an answer. Hynek, do you still propose the change in your second patch? If so, do you want to update it and make a PR? -- ___ Python tracker <https://bugs.python.org/issue13498> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44072] Doc: power operator (`**`) present for numbers.Complex, not added in numbers.Integral
Terry J. Reedy added the comment: Thanks for the report and clean patch. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44107] HTTPServer can't close http client completely
Terry J. Reedy added the comment: 3.8 only gets security fixes. Please verify issue on a current release. -- nosy: +terry.reedy ___ Python tracker <https://bugs.python.org/issue44107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44081] ast.unparse: dont use redundant space separator for lambdas with no parameters
Terry J. Reedy added the comment:
Agreed. unparse is already correct if there is a parameter.
>>> ast.unparse(ast.parse("lambda x: 'hey!'"))
"lambda x: 'hey!'"
--
nosy: +terry.reedy
___
Python tracker
<https://bugs.python.org/issue44081>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40358] pathlib's relative_to should behave like os.path.relpath
Terry J. Reedy added the comment: On #44078 (closed as duplicate), Mark Hammond made a similar request. -- nosy: +terry.reedy versions: +Python 3.11 -Python 3.10 ___ Python tracker <https://bugs.python.org/issue40358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44078] Output relative path when using PurePath.relative_to
Change by Terry J. Reedy : -- resolution: -> duplicate stage: -> resolved status: open -> closed superseder: -> pathlib's relative_to should behave like os.path.relpath ___ Python tracker <https://bugs.python.org/issue44078> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44072] Doc: power operator (`**`) present for numbers.Complex, not added in numbers.Integral
Terry J. Reedy added the comment: Yes, complex ** complex works fine, and "TypeError: pow() 3rd argument not allowed unless all arguments are integers". -- nosy: +terry.reedy ___ Python tracker <https://bugs.python.org/issue44072> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42109] Use hypothesis for testing the standard library, falling back to stubs
Terry J. Reedy added the comment: This issue confuses two different testing issues. First is selection of test data before the test versus generation while testing (usually 'randomly') Second is how the function is tested. All tests test some property of the inputs and function, but it is useful to distinguish between testing that a function produces a specific expected output versus testing something more abstract or defined in terms of the inputs. Example 1: 2 + 3 = 5 (a + b = (known) c) versus 2 + 3 = 3 + 2 (a + b = b + a) and (2 + 3) + 4 = 2 + (3 + 4). Example 2: sorted([3,5,1,4]) = [1,3,4,5] versus is_sorted(sorted([random list]). The latter are what hypothesis people mean by 'property tests'. Such property tests can be done with either fixed or random pairs in unittest module tests. The test that a module compiles is a weak property test, but better than nothing. A test that that all lines of code runs at least once without an unexpected exception a stronger property test. I consider it roughly on a par with min(s) <= mean(s) <= max(s). The connection between randomized input testing, such as with hypothesis, and property tests is that with random inputs, one cannot test f(input) against an 'expected' value unless one has an alternate means of producing the expected value. It is often easier to test a parameterized equation or other properties. The problem with random input tests in not that they are 'flakey', but that they are useless unless someone is going to pay attention to failures and try to find the cause. This touches on the difference between regression testing and bug-finding tests. CPython CI is the former, and marred at that by buggy randomly failing tests. My conclusion: bug testing would likely be a good idea, but should be done separate from the CI test suite. Such testing should only be done for modules with an active maintainer who would welcome failure reports. -- ___ Python tracker <https://bugs.python.org/issue42109> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31753] Unnecessary closure in ast.literal_eval
Change by Terry J. Reedy : -- resolution: -> rejected ___ Python tracker <https://bugs.python.org/issue31753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13657] IDLE doesn't recognize resetting sys.ps1.
Terry J. Reedy added the comment: Starting with 3.10.0b1, Shell is being reworked in ways that make this issue, as formulated, out of date. Solving the indent problems means that prompt must be removed from the first line of interactive input. #37892. The initial solution is to put >>> and ... prompts in a sidebar. #37903. The rules out customization. A planned alternate solution is to put the prompt on a line by itself above interactive input. A followup issue could be customizing the isolated prompt by a setting in the options dialog. -- resolution: -> out of date stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue13657> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39228] traceback.FrameSummary does not handle exceptions from `repr()`
Change by Terry J. Reedy : -- nosy: -terry.reedy versions: +Python 3.11 -Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39228> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37903] IDLE Shell sidebar.
Terry J. Reedy added the comment:
Yes, lets discuss actual problems and various possible solutions.
Raymond's example is incomplete as it omits multiline statements, which is
where the real problems lie and the reason a fix was sorely needed. This has
been more or less agreed on since at least 2005.
Old:
--
>>> if a:
print('okay:'
else:
if a is None:
print('none:')
else:
print('else:')
else:
--
Possible confusion between input and output is a pre-existing issue. For the
default themes, Shell User Output has the same background color as Code or
Normal Text. The foreground is blue. The lack of contrast is worse on the
dark theme. I think using the same background was a mistake, but so far
changing the default has been considered off limits. The pre-existing fix for
distinguishing output is to customize colors for Shell User Output, as I have
done. I have also given Shell User Exceptions more contrast. One can make both
as different as one wants.
In 2014, #7676, Raymond said that the indent mess was a "major PITA" and the
impossibility of copy-pasting correctly indented code into an editor "has been
a continual source of frustration for students in my Python courses as well.
I'm looking forward to it being fixed."
At the time, I had no more idea how to fix this than Kurt Kaiser did in the
2000s. But I eventually realized that the problem is entirely due to the first
line of multiline statements being indented relative to following code lines,
unlike the REPL. The fix (and the only acceptible fix) was and is to stop
doing that.
The day before the beta1 release*, Tal and I merged a beta-quality release that
we said would need improvement before production release.
--
>>> if a:
... print('okay:'
... else:
... if a is None:
... print('none:')
... else:
... print('else:')
...
else:
--
I am sure that a graphics designer would consider this improved. Unindented
code now lines up, and the indents are that same as in any decent python-aware
editor. In any case, the above is identical to the REPL except that in the
REPL, the output starts at the left, under the prompts.
If one selects the above lines, easily done by clicking and dragging on the
sidebar, just as with line numbers, right clicks, and selects 'Copy with
prompts' on the context menu, one gets the above *with* output 'else' to the
left. IDLE is now as useful for interactive snippets as the REPL. This is
mentioned in the IDLE What's New and News items.
I can imagine a possible alternative fix that would put output under the
prompts in Shell, not just in the clipboard copy. It would involve a fixed
input prompt above the code entry area and side prompts in the history area.
This would be a variation on the two-text solution that I discussed on #37892.
As for copying code to paste into an editor: As I believe was mentioned above,
we had 'Copy only code' on the context menus, but removed it because it also
copied user input in response to user code prompts, which is currently tagged
the same as code entered in response to the Shell's prompts. Fixing this will
be a high priority issue. When it is, we will list both new option on the
Shell menu.
I will soon open another issue for the sidebar colors. I consider the current
colors to be placeholders. We set that aside to get the sidebar otherwise
ready. Some might prefer a background matching the general shell background so
that there is no vertical separation.
* Not by choice. We were delayed 6 months because Azure Pipelines, on Ubuntu
and Windows, changes the test environment by grabbing sys.stdout. Shell
receives input on sys.stdout. So when test code sent text to shell via
sys.stdout, it went to Pipelines instead of Shell, breaking the tests. We
should have ignored those failures, but didn't. Once we realized the problem,
less that 2 weeks before the beta, we had the test steal sys.stdout back for
each test and moved forward.
--
___
Python tracker
<https://bugs.python.org/issue37903>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44028] Request for locals().update() to work, it is
Terry J. Reedy added the comment: When quoting, please include the source, preferably a direct link. In Python 1 and 2, there were two function local namespace *implementations* -- array index by number or dictionary indexed by name. The implementation, and hence the lookup mode, was fixed at compile time. In Python 3, the one *implementation*, and its lookup mode, are fixed. The slower implementation was dropped because it was not thought worth the bother. When you invoke the save function while playing a game, I am imagine that the save function does not have access to and does not same the locals of whatever function was executing at the time you hit the save key. Rather a game and player states are serialized, and likely not in one line of code. -- nosy: +terry.reedy ___ Python tracker <https://bugs.python.org/issue44028> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE: print "Did you mean?" for AttributeError and NameError
Change by Terry J. Reedy : -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue44026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE: print "Did you mean?" for AttributeError and NameError
Terry J. Reedy added the comment:
Merged to 3.11.0a0 first, bot forget to post it.
Dennis, thank you for the analysis and then the suggestion as to how to access
the not directly accessible. It would likely have been awhile before I
stumbled from 'cannot' to 'can with workaround'. Feel free to add ideas on
other IDLE issues.
Thanks EP for making the fix work even with chained exceptions *and* for
providing tests. I redid half the lines, but core test logic was correct and
remains. In .0b1+ repository (and future .0b2 release) IDLE:
>>> try: abc
... except NameError: f"{complex.reel(1+1j)} errors occurred!"
...
Traceback (most recent call last):
File "", line 1, in
try: abc
NameError: name 'abc' is not defined. Did you mean: 'abs'?
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "", line 2, in
except NameError: f"{complex.reel(1+1j)} errors occurred!"
AttributeError: type object 'complex' has no attribute 'reel'. Did you mean:
'real'?
And thank you Pablo for making exception messages more helpful.
--
stage: patch review ->
___
Python tracker
<https://bugs.python.org/issue44026>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE: print "Did you mean?" for AttributeError and NameError
Terry J. Reedy added the comment: New changeset 5a5237c6d08ed97458b0903d6836624168df0b51 by Miss Islington (bot) in branch '3.10': bpo-44026: Idle - display interpreter's 'did you mean' hints (GH-25912) https://github.com/python/cpython/commit/5a5237c6d08ed97458b0903d6836624168df0b51 -- ___ Python tracker <https://bugs.python.org/issue44026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE: print "Did you mean?" for AttributeError and NameError
Change by Terry J. Reedy : -- pull_requests: +24631 pull_request: https://github.com/python/cpython/pull/25975 ___ Python tracker <https://bugs.python.org/issue44026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37892] IDLE Shell: isolate user code input
Terry J. Reedy added the comment: PR 25678 merged on top of the sidebar patch results in using space indents with the sidebar. An additional patch is needed to have the mode with '>>>' on a line by itself instead of having a sidebar. The shell prompt_last_line attribute is now obsolete (it is always '') and should be removed after uses, such as "if self.prompt_last_line" headers and the following code, are removed. -- ___ Python tracker <https://bugs.python.org/issue37892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE: print "Did you mean?" for AttributeError and NameError
Terry J. Reedy added the comment: This is only backported to 3.10 and not 3.9 because the fix recommendations were only added in 3.10. If the code difference became a problem, this could be backported because the roundabout method for name and attribute errors would work in 3.9. -- stage: patch review -> ___ Python tracker <https://bugs.python.org/issue44026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37903] IDLE Shell sidebar.
Terry J. Reedy added the comment: As described above in msg392163, the other fix is to put the prompt on a line by itself. I hoped to get a switch between fixes into b1 but ran out of time and energy. I intend to have in in the next, along with other improvements. -- ___ Python tracker <https://bugs.python.org/issue37903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25094] [EASY][Windows] test_tools fails on Windows when passing
Change by Terry J. Reedy : -- pull_requests: -24577 ___ Python tracker <https://bugs.python.org/issue25094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE: print "Did you mean?" for AttributeError and NameError
Terry J. Reedy added the comment: Pablo, unless you are suggesting rewriting IDLE's custom exception handing in C, I don't see how making it a single function would be an improvement. As long as it is Python code, the problem is accessing the message supplement. After reading your comment, I agree that injecting Python code into the C exception handling is a bad idea. It also, I see now, not needed run.print_exception first calls traceback.extract_tb (line 238). The doc says " It is useful for alternate formatting of stack traces", which IDLE does. print_exception next calls the undocumented traceback.print_list, which is format_list + print*. Finally, print_exception calls traceback.format_exception_only (line 2440), which returns a list of lines that is immediately printed. So all IDLE needs is for format_exception_only to include the extra lines, either by default or by option. But it just calls TracebackException.format_exception)only, which call a private Python-coded function, which can only add the lines if accessible from Python-code. Dennis cleverly pointed out that such access is available, even if awkwardly, by capturing the standard excepthook outout and keeping only the missing part. (test.support.captured_stderr just wraps io.StringIO as a context manager. IDLE can borrow and edits its code.) Dennis, would you like to prepare a PR that follows the format_exception_only call with something like if isinstance(typ, (AttributeError, NameError)): lines.extend(extract_extra_message()) and a definition of the new function? (and a new test)? Or perhaps better, replace format_exception_only with a function that gets all lines at once. Pablo, do any other exception types have such omitted help info? Do you have plans for any more? -- title: IDLE doesn't offer "Did you mean?" for AttributeError and NameError -> IDLE: print "Did you mean?" for AttributeError and NameError ___ Python tracker <https://bugs.python.org/issue44026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE doesn't offer "Did you mean?" for AttributeError and NameError
Terry J. Reedy added the comment: I realized after posting that looking for close matching is a performance issue and does not need to be done unless the exception is going to be displayed. But it is a shame to keep such great work away from many users. What would you think of either 1. add sys.tracebackhook, to be called by the traceback display functions if not None. Then idlelib.run.print_exception would not have to duplicate the sometimes changing logic for chaining or otherwise joining multiple tracebacks into one mega-traceback. Instead, from what Dennis said above, it could set the hook and call the built-in exceptionhook. 2. add a new optional parameter to exceptionhook and the traceback display function. This would have the same advantage as above. -- ___ Python tracker <https://bugs.python.org/issue44026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44025] Match doc: Clarify '_' as a soft keyword
Terry J. Reedy added the comment: bedevere-bot malfunctioned. Lukasz merged PR 25873 into main, and I verified the change on the main branch. But the PR is listed above as closed, not merged, and commit 3b200b2aa648fcc8a2673871807c1463afe00195 is not listed. -- nosy: +Mariatta, lukasz.langa ___ Python tracker <https://bugs.python.org/issue44025> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37605] CI should not depend on gmane response
Terry J. Reedy added the comment:
nntp.rst, line 23, has already been updated to "s = NNTP('news.gmane.io'). But
that also occasionally fails to respond. I have not seen any test failures
recently, so maybe something else has changes. Should this be closed pending
current failures?
--
versions: +Python 3.11 -Python 2.7, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue37605>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44026] IDLE doesn't offer "Did you mean?" for AttributeError and NameError
Terry J. Reedy added the comment: (Shreyan, the fake filenames are not relevant.) By default, sys.excepthook is sys.__excepthook is . So by default IDLE runcode calls print_exception, which call cleanup_traceback for each traceback printed. This function makes two important changes to the traceback. First, it removes traceback lines that are not present when running in the C-coded REPL, because IDLE does some functions with Python code. The result is that IDLE tracebacks nearly always equal REPL tracebacks. Second, for Shell code, IDLE add cached code lines. Compare >>> a = b Traceback (most recent call last): File "", line 1, in NameError: name 'b' is not defined to >>> a = b Traceback (most recent call last): File "", line 1, in a = b NameError: name 'b' is not defined >>> We are not going to stop using print_exception. Note that it is normal for IDEs to modify tracebacks. The 'is' is false when user change excepthook. The false branch was recently added to run user excepthooks. Pablo, I checked an AttributeError instance and the missing phrase is not present. Why is it hidden from Python code. Why not add the rest of the message to the message? Or at least add it to the tuple or an attribute. Or add a .get_suggestion method to exception objects, like .with_traceback. -- ___ Python tracker <https://bugs.python.org/issue44026> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
