[issue44332] For Loop temporary variable scope should be local to For loop

[Mark Dickinson]

Change by Mark Dickinson :


--
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44323] install module fail on windows 10

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
title: insttall module faid on wondows 10 -> install module fail on windows 10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44332] For Loop temporary variable scope should be local to For loop

[Steven D'Aprano]

Steven D'Aprano  added the comment:

By the way, loop variables are not considered to be "temporary" in Python. They 
are no more temporary than any other local variable -- they *are* local 
variables with exactly the same scope and lifetime as all other local variables.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44332] For Loop temporary variable scope should be local to For loop

[Steven D'Aprano]

Steven D'Aprano  added the comment:

This is not a bug, it is intentional design and has been since Python 1.

You are incorrect about x consuming memory "always". If the value bound to x is 
in use elsewhere, deleting x will save no memory. If the value is not in use 
elsewhere, it will be garbage collected as soon as x goes out of scope, which 
will be at the end of the function.

Shifting to block-scope for for-loops has been discussed before, it is not a 
popular idea and I expect that most people will oppose it. You can search the 
Python-Ideas mailing list if you want to find out more. If you still feel 
strongly that this is an enhancement, as it is a major change in language 
behaviour it would require a PEP to be written.

https://www.python.org/dev/peps/pep-0001/

Even if the PEP was accepted, the earliest it could go into the language would 
be Python 3.11 or better, and that would likely require a special `__future__` 
import.

--
nosy: +steven.daprano
resolution:  -> not a bug
stage:  -> resolved

___
Python tracker 

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

[Terry J. Reedy]

Change by Terry J. Reedy :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44332] For Loop temporary variable scope should be local to For loop

[Debasis Satapathy]

New submission from Debasis Satapathy :

numbers = [1, 2, 3, 4, 5, 6, 7, 8]
for x in numbers:
print(x)
print(x)

In the above code, print(x) statement should give error. Because x scope should 
be local to for loop only.
99% cases, developers will not use the temporary variable x outside of the for 
loop.
So x will keep on consuming memory always. So it is a bad usage of memory.
Ideally x memory should be free once for loop execution is completed.

--
components: Library (Lib)
messages: 395246
nosy: deb_ctc
priority: normal
severity: normal
status: open
title: For Loop temporary variable scope should be local to For loop
type: behavior
versions: Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41391] Make test_unicodedata pass when running without network

[Chih-Hsuan Yen]

Chih-Hsuan Yen  added the comment:

Closing in favor of a simpler fix merged from issue43144. Thanks for the fix!

--
resolution:  -> duplicate
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

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

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset d5f8bd60e1203a41996b3ee370d6f09389070627 by Terry Jan Reedy in 
branch '3.9':
[3.9] bpo-44322: Document more SyntaxError details. (GH-26562)
https://github.com/python/cpython/commit/d5f8bd60e1203a41996b3ee370d6f09389070627


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44331] Generate static PyCodeObjects for faster startup

[Neil Schemenauer]

Change by Neil Schemenauer :


--
keywords: +patch
pull_requests: +25161
pull_request: https://github.com/python/cpython/pull/26571

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44331] Generate static PyCodeObjects for faster startup

[Neil Schemenauer]

New submission from Neil Schemenauer :

Note: This is a proof of concept and not ready for merging as is.


This is based on 'frozen_modules' from Jeethu Rao , via 
Larry Hastings.  Larry's git branch was:

g...@github.com:larryhastings/cpython.git
not_another_use_of_the_word_frozen

Usage:

- Compile Python as normal
- Run "make regen-freeze-startup" to re-generate Python/frozenmodules_code.c
- Compile Python a second time

Changes from Larry's branch:

- Move static C code generation tool to Tools/freeze2
- Move _serializer to Modules
- Rebase on Python 3.10.0b1
- determine startup modules by running sys.executable
- use importlib.util.find_spec() to get code objects
- fix ref-counting when setting __path__
- put static frozen modules in frozen_code_objects dict
- reduce set of "bad" modules as it seems only _collections_abc needs
  exclusion
- fix the is_frozen_package() and is_frozen() functions to find
  static frozen code

It's not passing all unit tests yet but I'm somewhat hopeful there are no deep 
problems.  Porting the changes from 3.6 to 3.8 and then to 3.10 was not too 
horrible.  There was a few changes to PyGC_Head, to the PyCodeObject structure 
and to the runtime initialization process.  That gives me some hope that it 
wouldn't be too burdensome to maintain this in the long-term.  Mostly it would 
be updating _serialize.c to keep up with PyCodeObject changes.

Based on benchmarking with 3.8, this gives a decent speedup for startup of a 
trival program, e.g. python -c "True".  I measure it as taking 76% of the time. 
 The savings are mostly in marshal.c but there is also some 
importlib/filesystem overhead that's removed.

--
messages: 395243
nosy: nascheme
priority: low
severity: normal
stage: patch review
status: open
title: Generate static PyCodeObjects for faster startup
type: performance

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37449] Move ensurepip off of pkgutil and to importlib.resources

[Jason R. Coombs]

Jason R. Coombs  added the comment:


New changeset afb2eed72b32a35b4726ff35f92e4fbf54926046 by wim glenn in branch 
'main':
bpo-37449: ensurepip uses importlib.resources.files() traversable APIs (#22659)
https://github.com/python/cpython/commit/afb2eed72b32a35b4726ff35f92e4fbf54926046


--
nosy: +jaraco

___
Python tracker 

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

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 2af690fdb26d0312de056b54ddb113d3c44dee8c by Miss Islington (bot) 
in branch '3.10':
bpo-44322: Document more SyntaxError details. (GH-26562)
https://github.com/python/cpython/commit/2af690fdb26d0312de056b54ddb113d3c44dee8c


--

___
Python tracker 

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

[Terry J. Reedy]

Change by Terry J. Reedy :


--
pull_requests: +25160
pull_request: https://github.com/python/cpython/pull/26570

___
Python tracker 

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

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +25159
pull_request: https://github.com/python/cpython/pull/26569

___
Python tracker 

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

[Terry J. Reedy]

Terry J. Reedy  added the comment:


New changeset 67dfa6f2a508c325715625fe442f2ce20270a8b3 by Terry Jan Reedy in 
branch 'main':
bpo-44322: Document more SyntaxError details. (GH-26562)
https://github.com/python/cpython/commit/67dfa6f2a508c325715625fe442f2ce20270a8b3


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44330] IDLE: Colorizer and output tests hang on macOS

[Terry J. Reedy]

Change by Terry J. Reedy :


--
title: IDLE: Colorizer test hangs on macOS -> IDLE: Colorizer and output tests 
hang on macOS

___
Python tracker 

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

[Terry J. Reedy]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44328] time.monotonic() should use a different clock source on Windows

[Ryan Hileman]

Ryan Hileman  added the comment:

I found these two references:
- 
https://stackoverflow.com/questions/35601880/windows-timing-drift-of-performancecounter-c
- https://bugs.python.org/issue10278#msg143209

Which suggest QueryPerformanceCounter() may be bad because it can drift. 
However, these posts are fairly old and the StackOverflow post also says the 
drift is small on newer hardware / Windows.

Microsoft's current stance is that QueryPerformanceCounter() is good: 
https://docs.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps

> Guidance for acquiring time stamps
> Windows has and will continue to invest in providing a reliable and efficient 
> performance counter. When you need time stamps with a resolution of 1 
> microsecond or better and you don't need the time stamps to be synchronized 
> to an external time reference, choose QueryPerformanceCounter

I looked into how a few other languages provide monotonic time on Windows:

Golang seems to read the interrupt time (presumably equivalent to 
QueryInterruptTime) directly by address. 
https://github.com/golang/go/blob/a3868028ac8470d1ab7782614707bb90925e7fe3/src/runtime/sys_windows_amd64.s#L499

Rust uses QueryPerformanceCounter: 
https://github.com/rust-lang/rust/blob/38ec87c1885c62ed8c66320ad24c7e535535e4bd/library/std/src/time.rs#L91

V8 uses QueryPerformanceCounter after checking for old CPUs: 
https://github.com/v8/v8/blob/dc712da548c7fb433caed56af9a021d964952728/src/base/platform/time.cc#L672

Ruby uses QueryPerformanceCounter: 
https://github.com/ruby/ruby/blob/44cff500a0ad565952e84935bc98523c36a91b06/win32/win32.c#L4712

C# implements QueryPerformanceCounter on other platforms using CLOCK_MONOTONIC, 
indicating that they should be roughly equivalent: 
https://github.com/dotnet/runtime/blob/01b7e73cd378145264a7cb7a09365b41ed42b240/src/coreclr/pal/src/misc/time.cpp#L175

Swift originally used QueryPerformanceCounter, but switched to 
QueryUnbiasedInterruptTime() because they didn't want to count time the system 
spent asleep: 
https://github.com/apple/swift-corelibs-libdispatch/commit/766d64719cfdd07f97841092bec596669261a16f

--

Note that none of these languages use GetTickCount64(). Swift is an interesting 
counter point, and I noticed QueryUnbiasedInterruptTime() is available on 
Windows 8 while QueryInterruptTime() is new as of Windows 10. The "Unbiased" 
just refers to whether it advances during sleep.

I'm not actually sure whether time.monotonic() in Python counts time spent 
asleep, or whether that's desirable. Some kinds of timers using monotonic time 
should definitely freeze during sleep so they don't cause a flurry of activity 
on wake, but others definitely need to roughly track wall clock time, even 
during sleep.

Perhaps the long term answer would be to introduce separate "asleep" and 
"awake" monotonic clocks in Python, and possibly deprecate perf_counter() if 
it's redundant after this (as I think it's aliased to monotonic() on 
non-Windows platforms anyway).

--
title: time.monotonic() should use QueryPerformanceCounter() on Windows -> 
time.monotonic() should use a different clock source on Windows

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

[Ryan Hileman]

Ryan Hileman  added the comment:

Ok, I filed a PR for this. I used pytime's interface to avoid duplicating the 
QueryPerformanceFrequency() code.

I found a StackOverflow answer that says QueryPerformance functions will only 
fail if you pass in an unaligned pointer: https://stackoverflow.com/a/27258700

Per that, I used Py_FatalError to catch this case, as there is probably 
something wrong with the compiler at that point, and the other recovery options 
would be likely to result in incorrect program behavior (e.g. dead lock).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

[Ryan Hileman]

Change by Ryan Hileman :


--
keywords: +patch
pull_requests: +25157
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26568

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44324] add a "expected expression" syntax error

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>  I saw that unclosed parentheses' special error are checked in the same 
> place. 

Just to clarify: unclosed parentheses is a tokenizer error, not a parser error 
and this is handled by checking the tokenize status when it has already failed. 
The reason is done after the failed parser is because our tokenizer is made 
lazy and to check for unclosed pantheses you need to fully parse everything, 
and this needs a driver. There is no semantic analysis here, just checking the 
lexer status: that's why is handled separately

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44324] add a "expected expression" syntax error

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>> Well, I was thinking we could just do a simple check in 
>> _PyPegen_check_tokenizer_errors or _PyPegen_run_parser functions. If the 
>> last three tokens in the Parser object's tokens array are NAME, 
>> EQUAL/MINEQUAL/etc and NEWLINE, we raise the special error. Is this the 
>> right way to do it? I saw that unclosed parentheses' special error are 
>> checked in the same place. 

I find that quite inelegant and error prone. A PEG parser is not assured to 
finish when you think it will finish as it can backtrack and expand to parse 
left recursive rules. Incorrect syntax must be handled by the parser itself 
using the parser process, not after the fact. Once the parser has finished, the 
semantic information is gone and you are left with unstructured tokens.


> Yea, I realized that the "expected an expression" error can be used in 
> multiple places. Could be added one by one?

Not sure what you mean here, but this should be added in a single place related 
to the assignment rule, otherwise is going to be quite difficult to maintain.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44324] add a "expected expression" syntax error

[Arjun]

Arjun  added the comment:

> This one will be very tricky to do correctly because the '=' is very 
> context-sensitive and the parser can be confused when backtracking, so this 
> *may* be quite delicate/complex

Well, I was thinking we could just do a simple check in 
_PyPegen_check_tokenizer_errors or _PyPegen_run_parser functions. If the last 
three tokens in the Parser object's tokens array are NAME, EQUAL/MINEQUAL/etc 
and NEWLINE, we raise the special error. Is this the right way to do it? I saw 
that unclosed parentheses' special error are checked in the same place. 

> I suspect this is going to be a pain for malformed expressions on the right

Yea, I realized that the "expected an expression" error can be used in multiple 
places. Could be added one by one?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44329] [sqlite3] refactor pysqlite_statement_create

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> Yes, we need to allocate/track every time. I just propose to do so as late as 
> possible, in order to avoid allocating a PyObject before we know if it is 
> possible to actually create the statement.

That describes much better the intent :)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44329] [sqlite3] refactor pysqlite_statement_create

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

Ah, I see I formulated myself a bit unclear:
Yes, we need to allocate/track every time. I just propose to do so as late as 
possible, in order to avoid allocating a PyObject before we know if it is 
possible to actually create the statement.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44329] [sqlite3] refactor pysqlite_statement_create

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

... to expand: so currently, if statement creation fails, we must deallocate 
the PyObject.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44329] [sqlite3] refactor pysqlite_statement_create

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

> I am not sure what you mean, in the happy path you still need to GC track and 
> allocate.

Currently, we allocate the object, then try to create the statement using the 
SQLite API. If we create the statement first, we can do the sanity check on the 
return value and just return NULL; then we can allocate the Py object and 
initialise the members.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44329] [sqlite3] refactor pysqlite_statement_create

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

>  will avoid unneeded allocations/GC tracking,

I am not sure what you mean, in the happy path you still need to GC track and 
allocate.

--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44087] [sqlite3] consider adding Py_TPFLAGS_DISALLOW_INSTANTIATION to sqlite3.Statement

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
keywords: +patch
pull_requests: +25156
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26567

___
Python tracker 

___
___
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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44324] add a "expected expression" syntax error

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I suspect this is going to be a pain for malformed expressions on the right. 
For instance:

>>> a = {x: for x in {}}
  File "", line 1
a = {x: for x in {}}
^^^
SyntaxError: expected an expression

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44324] add a "expected expression" syntax error

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

This one will be very tricky to do correctly because the '=' is very 
context-sensitive and the parser can be confused when backtracking, so this 
*may* be quite delicate/complex. 

I need to play a bit with this to know how feasible this would be.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44326] [sqlite3] remove unused members from pysqlite_Statement

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44327] [sqlite3] remove unused members from pysqlite_Connection

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44329] [sqlite3] refactor pysqlite_statement_create

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
keywords: +patch
pull_requests: +25155
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26566

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44329] [sqlite3] refactor pysqlite_statement_create

[Erlend E. Aasland]

New submission from Erlend E. Aasland :

Currently, pysqlite_statement_create() approx. looks like this:

1. some sanity checks (type, sql lenght, etc.)
2. allocate (PyObject_GC_New)
3. initialise members
4. determine if statement is a DML statement
5. create the statement (sqlite3_prepare_v2)
6. PyObject_GC_Track
7. check statement return value
8. more sanity checking
9. done!


Suggesting to refactor as this:
1. all sanity checks => early exit on failure
2. create the statement and validate return value
3. determine if statement is a DML statement => no need to do this if statement 
creation failed
4. allocate
5. initialise members
5. return


This will avoid unneeded allocations/GC tracking, it will avoid unneeded 
statement creation, and it will be more readable/maintainable.

--
assignee: erlendaasland
components: Extension Modules
messages: 395224
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] refactor pysqlite_statement_create
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44326] [sqlite3] remove unused members from pysqlite_Statement

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 0d12f245523178eb62e22f5da5a276bfc7004ac4 by Erlend Egeberg 
Aasland in branch 'main':
bpo-44326: Remove unused members from pysqlite_Statement (GH-26564)
https://github.com/python/cpython/commit/0d12f245523178eb62e22f5da5a276bfc7004ac4


--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44327] [sqlite3] remove unused members from pysqlite_Connection

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 505624e917a2d3d845304f8d34fccd41f06d4720 by Erlend Egeberg 
Aasland in branch 'main':
bpo-44327: Remove unused members from pysqlite_Connection (GH-26565)
https://github.com/python/cpython/commit/505624e917a2d3d845304f8d34fccd41f06d4720


--
nosy: +pablogsal

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44328] time.monotonic() should use QueryPerformanceCounter() on Windows

[Ryan Hileman]

New submission from Ryan Hileman :

Related to https://bugs.python.org/issue41299#msg395220

Presumably `time.monotonic()` on Windows historically used GetTickCount64() 
because QueryPerformanceCounter() could fail. However, that hasn't been the 
case since Windows XP: 
https://docs.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter

> On systems that run Windows XP or later, the function will always succeed and 
> will thus never return zero

I've run into issues with this when porting python-based applications to 
Windows. On other platforms, time.monotonic() was a decent precision so I used 
it. When I ported to Windows, I had to replace all of my time.monotonic() calls 
with time.perf_counter(). I would pretty much never knowingly call 
time.monotonic() if I knew ahead of time it could be quantized to 16ms.

My opinion is that the GetTickCount64() monotonic time code in CPython should 
be removed entirely and only the QueryPerformanceCounter() path should be used.

I also think some of the failure checks could be removed from 
QueryPerformanceCounter() / QueryPerformanceFrequency(), as they're documented 
to never fail in modern Windows and CPython has been dropping support for older 
versions of Windows, but that's less of a firm opinion.

--
components: Library (Lib), Windows
messages: 395221
nosy: lunixbochs2, paul.moore, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: time.monotonic() should use QueryPerformanceCounter() on Windows
type: performance
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

[Ryan Hileman]

Change by Ryan Hileman :


--
versions: +Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue41299] Python3 threading.Event().wait time is twice as large as Python27

[Ryan Hileman]

Ryan Hileman  added the comment:

I just ran into this. GetTickCount64() is a bad choice even without improving 
the Windows timer resolution, as every mutex wait will have 16ms of jitter. 
Here are some lock.acquire(timeout=0.001) times measured with 
time.perf_counter():

elapsed=21.215ms
elapsed=30.960ms
elapsed=21.686ms
elapsed=30.998ms
elapsed=30.794ms

Here's the same lock.acquire(timeout=0.001) with CPython patched to use 
QueryPerformanceCounter() instead of GetTickCount64(). Notice this is less 
overhead than even the original post's Python 2.x times.

elapsed=9.554ms
elapsed=14.516ms
elapsed=13.985ms
elapsed=13.434ms
elapsed=13.724ms

Here's the QueryPerformanceCounter() test in a timeBeginPeriod(1) block:

elapsed=1.135ms
elapsed=1.204ms
elapsed=1.189ms
elapsed=1.052ms
elapsed=1.052ms

I'd like to submit a PR to fix the underlying issue by switching to 
QueryPerformanceCounter() in EnterNonRecursiveMutex().

QueryInterruptTime() is a bad candidate because it's only supported on Windows 
10, and CPython still supports Windows 8. Improvements based on 
QueryPerformanceCounter() can be backported to at least 3.8 (3.8 dropped 
Windows XP support, which was the last Windows version where 
QueryPerformanceCounter() could fail).

I checked and the only other use of GetTickCount64() seems to be in 
time.monotonic(). Honestly I would vote to change time.monotonic() to 
QueryPerformanceCounter() as well, as QueryPerformanceCounter() can no longer 
fail on any Windows newer than XP (which is no longer supported by Python), but 
that's probably a topic for a new BPO.

--
nosy: +lunixbochs2
versions:  -Python 3.10, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44327] [sqlite3] remove unused members from pysqlite_Connection

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
keywords: +patch
pull_requests: +25154
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26565

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44327] [sqlite3] remove unused members from pysqlite_Connection

[Erlend E. Aasland]

New submission from Erlend E. Aasland :

The timeout and timeout_started members of pysqlite_Connection are never used. 
Suggesting to remove them.

--
assignee: erlendaasland
components: Extension Modules
messages: 395219
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] remove unused members from pysqlite_Connection
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44326] [sqlite3] remove unused members from pysqlite_Statement

[Erlend E. Aasland]

Erlend E. Aasland  added the comment:

The "sql" member is also unused. Removing this will make the tp_clear method 
redundant, as there are no PyObjects to clear anymore.

--
title: [sqlite3] remove unused db member from pysqlite_Statement -> [sqlite3] 
remove unused members from pysqlite_Statement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44326] [sqlite3] remove unused db member from pysqlite_Statement

[Erlend E. Aasland]

New submission from Erlend E. Aasland :

The db member of pysqlite_Statement is only "used" in the statement create 
method. Suggesting to remove this. A couple of lines less of code, a couple of 
bytes less per statement object.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44326] [sqlite3] remove unused db member from pysqlite_Statement

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
Removed message: https://bugs.python.org/msg395216

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44326] [sqlite3] remove unused db member from pysqlite_Statement

[Erlend E. Aasland]

Change by Erlend E. Aasland :


--
keywords: +patch
pull_requests: +25153
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26564

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44326] [sqlite3] remove unused db member from pysqlite_Statement

[Erlend E. Aasland]

New submission from Erlend E. Aasland :

The db member of pysqlite_Statement is only "used" in the __init__ method. 
Suggesting to remove this. A couple of lines less of code, a couple of bytes 
less per statement object.

--
assignee: erlendaasland
components: Extension Modules
messages: 395216
nosy: erlendaasland
priority: low
severity: normal
status: open
title: [sqlite3] remove unused db member from pysqlite_Statement
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44324] add a "expected expression" syntax error

[Arjun]

Arjun  added the comment:

I forgot to add, I would be willing to make the necessary changes, if accepted

--

___
Python tracker 

___
___
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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44324] add a "expected expression" syntax error

[Arjun]

New submission from Arjun :

Recently, CPython got a new syntax error, "SyntaxError: expression expected 
after dictionary key and ':'". I propose to add a "expected expression" in 
general for consistency. I would like to have it changed for all the "equals" 
(e.g. PLUSEQUAL, MINEQUAL, etc). 


>>> x =
  File "", line 1
x =
^
SyntaxError: invalid syntax

Would be enhanced by:

>>> x +=
  File "", line 1
x =
 ^
SyntaxError: expected expression

--
components: Parser
messages: 395213
nosy: CCLDArjun, lys.nikolaou, pablogsal
priority: normal
severity: normal
status: open
title: add a "expected expression" syntax error
type: enhancement
versions: Python 3.11

___
Python tracker 

___
___
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]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44227] help(bisect.bisect_left)

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset b5cedd098043dc58ecf9c2f33774cd7646506a92 by Miss Islington (bot) 
in branch '3.10':
bpo-44227: Update bisect docstrings (GH-26548) (GH-26563)
https://github.com/python/cpython/commit/b5cedd098043dc58ecf9c2f33774cd7646506a92


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44323] insttall module faid on wondows 10

[Battant]

New submission from Battant :

Hello

Configuration :
windows 10
python install p: python3.9 from microsoft store

step to reproduce :
on windows, install visual studio and buid tools
clone cpython repository main branch

https://github.com/python/cpython

compile python with command

pCbuil/bauld.bat

run command : 
.\PCbuild\amd64\py.exe .\setup.py install
Actuel result :
cpython\setup.py", line 131, in set_compiler_flags
sysconfig.get_config_vars()[compiler_flags] = flags + ' ' + py_flags_nodist
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
Detail :
cpython\setup.py", line : 128
compile flag  : CFLAGS py_flags_nodist = None
compiler_flags  : CFLAGS
sysconfig  : PY_CFLAGS_NODIST
Question :
why compile flag  : CFLAGS py_flags_nodist = None )

Coud you help me to fix this issuus ?


Best regards

Battant

--
components: Extension Modules
messages: 395210
nosy: Battant
priority: normal
severity: normal
status: open
title: insttall module faid on wondows 10
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44227] help(bisect.bisect_left)

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 3.0 -> 4.0
pull_requests: +25152
pull_request: https://github.com/python/cpython/pull/26563

___
Python tracker 

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

[Terry J. Reedy]

Change by Terry J. Reedy :


--
keywords: +patch
pull_requests: +25151
pull_request: https://github.com/python/cpython/pull/26562

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44297] Frame with -1 line number

[Dominic Davis-Foster]

Dominic Davis-Foster  added the comment:

Is this a re-regression of https://bugs.python.org/issue43933?

--
nosy: +domdfcoding

___
Python tracker 

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

[Terry J. Reedy]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue40468] IDLE: configdialog tab rearrange

[Tal Einat]

Change by Tal Einat :


--
keywords: +patch
pull_requests: +25149
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26561

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37768] IDLE: Show help(object) output in a text viewer

[Tal Einat]

Change by Tal Einat :


--
pull_requests: +25150
pull_request: https://github.com/python/cpython/pull/26561

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Jason R. Coombs]

Jason R. Coombs  added the comment:

The line where the failure occurs is the point where it's checking that the 
warning was issued. The fact that a StopIteration is raised indicates that no 
warnings were caught. I can think of a couple of scenarios where that could 
happen:

- That warning is somehow disabled.
- The `Distribution` object returned by `distribution('distinfo-pkg')` is 
somehow an older implementation (perhaps an older importlib_metadata is 
present).

Given that the DeprecationWarnings aren't missed on other tests, the latter 
seems to be a more likely candidate.

I notice that the regular tests are passing. It's only in the 'appx' 
environment where the test fails. I'm not familiar with appx, but it seems 
likely that something from the appx environment creation is a factor in the 
divergent behavior.

Steve, can you advise on how appx environments are created and how one could 
replicate a test failure that only occurs in that environment?

--
nosy: +steve.dower

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39573] [C API] Make PyObject an opaque structure in the limited C API

[William Pickard]

William Pickard  added the comment:

MSVC by default disables method inlining (/Ob0) when '/Od' is specified on the 
command line while the optimization options specify '/Ob2'.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39573] [C API] Make PyObject an opaque structure in the limited C API

[Ken Jin]

Ken Jin  added the comment:

@victor, git bisect tells me the change 
f3fa63ec75fdbb4a08a10957a5c631bf0c4a5970 caused 
test_exceptions.ExceptionTests.test_recursion_in_except_handler to stack 
overflow only on windows debug builds. 3 windows buildbots using python debug 
mode is affected. Python compiled with release mode is *not* affected and 
passes the test. Here's an example error on one of the buildbots:

https://buildbot.python.org/all/#/builders/596/builds/354/steps/4/logs/stdio

I can also reproduce this locally. I tracked this issue down after a recursion 
in AST also caused a stack overflow, see my message here:
https://bugs.python.org/msg395172

TLDR: Windows builds seems to set stack size to 2MB, on *nix it's probably 
higher (usually 8MB). I suspect the static inline functions are not being 
inlined in windows debug builds, so every function call adds to the stack. In 
that message I proposed to increase the stack size on windows but there are 
some concerns (see msg395177). What do you think?

--
nosy: +kj

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue39573] [C API] Make PyObject an opaque structure in the limited C API

[Batuhan Taskaya]

Change by Batuhan Taskaya :


--
nosy: +BTaskaya
nosy_count: 10.0 -> 11.0
pull_requests: +25148
pull_request: https://github.com/python/cpython/pull/26550

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44321] os.EX_OK for Windows

[Samuel Marks]

Samuel Marks  added the comment:

`EXIT_SUCCESS` is defined in `stdlib.h`, as per 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/exit-success-exit-failure
 (following the standard 
https://pubs.opengroup.org/onlinepubs/009695399/basedefs/stdlib.h.html)

There are also 
https://docs.microsoft.com/en-us/cpp/c-runtime-library/errno-constants which 
has many equivalents to the `` (in ``).

Kinda related: https://bugs.python.org/issue24053

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44317] Suggestion for better syntax errors in tokenizer errors

[wyz23x2]

Change by wyz23x2 :


--
type: behavior -> enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44321] os.EX_OK for Windows

[Samuel Marks]

Change by Samuel Marks :


--
keywords: +patch
pull_requests: +25147
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/26559

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44321] os.EX_OK for Windows

[Samuel Marks]

New submission from Samuel Marks :

Since Python 2.3 alpha 2 [19-Feb-2003] `EX_OK` has existed… but only for Unix. 
This adds support for Windows.

--
components: Windows
messages: 395203
nosy: paul.moore, samuelmarks, steve.dower, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: os.EX_OK for Windows
type: enhancement

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44246] 3.10 beta 1: breaking change in importlib.metadata entry points

[Ken Jin]

Ken Jin  added the comment:

The new test `test_entry_points_by_index` (added in 
c34ed08d975fb7daa7b329f7c631647782290393 ) seems to fail on some windows 
buildbots: 

https://dev.azure.com/Python/cpython/_build/results?buildId=81807&view=logs&j=c8a71634-e5ec-54a0-3958-760f4148b765&t=599737bc-ad72-560d-1530-0f89b05729e4

A copy of the error output for everyone's convenience:
==
ERROR: test_entry_points_by_index 
(test.test_importlib.test_metadata_api.APITests)
Prior versions of Distribution.entry_points would return a
--
Traceback (most recent call last):
  File 
"D:\a\1\b\layout-appx-amd64\lib\test\test_importlib\test_metadata_api.py", line 
145, in test_entry_points_by_index
expected = next(iter(caught))
StopIteration

--

BTW, the same buildbot is currently failing on main with a different error 
which masks that error above. I'll do more digging if no one takes this up by 
next week. Currently I'm not able to reproduce that locally on my windows 
machine. Thanks all!

--
nosy: +kj

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44227] help(bisect.bisect_left)

[PeterChu]

Change by PeterChu :


--
nosy: +PeterChu
nosy_count: 2.0 -> 3.0
pull_requests: +25146
pull_request: https://github.com/python/cpython/pull/26548

___
Python tracker 

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

[Tal Einat]

Tal Einat  added the comment:

> The unknown is whether anyone has changed these pseudoevent bindings and if 
> so, how much do we care?

Let's ask on idle-dev.

> Guido, do you have any comment on this proposal from a change policy 
> perspective?

I'm not an ex-BDFL, but I can't think of a reason this shouldn't be backported 
as per our usual policy regarding IDLE.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44186] TimedRotatingFileHandler overwrite log

[Raymond Hettinger]

Change by Raymond Hettinger :


--
assignee:  -> vinay.sajip
nosy: +vinay.sajip

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com