[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Vedran Čačić]

Vedran Čačić  added the comment:

> based on feedback it seems that almost everyone expects "exit" to exit

I don't, and I don't remember being asked.

Let me be clear: if exit were a Python keyword, then maybe I would expect that. 
Or at least, I could convince myself to expect that. But exit is _not_ a 
keyword, it is not even a builtin, and there is a _strong_ reason for that. One 
of Guido's many valuable insights about language design is that you shouldn't 
preclude other uses of names you find convenient for your builtins. See the 
last line of Zen of Python.

And yes, I _have_ used exit as a name for my objects (e.g. as a flag in Pygame, 
set exit = False at the beginning and exit = True somewhere in the loop when I 
find out that the game is over). Although I don't recall ever actually typing 
`exit` into Python REPL to inspect its value, I really think that scenario is 
plausible (for example, if a game exited prematurely, and I wanted to see 
whether exit was set to True prematurely, or there was some other reason), and 
it would _annoy me immensely_ if instead of showing me the status of the flag 
it would drop me out of Python.

In fact, you're proposing to use exit as a keyword, but lying about it to the 
users. If it were really so important, then it _should_ be a keyword, and at 
least I'd know that I can't use it for my variables anymore. (It's not the 
first time such a thing would happen. The same thing happened with `async` a 
few years ago.) But please don't introduce those "keywords just in a particular 
context", they are horrible from the perspective of usability.

--

___
Python tracker 

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

[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs

[Christof Hanke]

Christof Hanke  added the comment:

Andrei,
cmp is the deep-compare part of filecmp. I thought we were taking about the 
shallow one.

Thus,
- shallow like rsync "quick": size + mtime.
- deep like cmp

--

___
Python tracker 

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

[issue44617] Undesired Behavior on `match` using Singleton object

[Pablo Aguilar]

New submission from Pablo Aguilar :

Hey, I'm not sure if this is really a bug but I'd like to show to prevent some 
undesired behavior!

I'm working in the `match` support for returns 
(https://github.com/dry-python/returns) library when I saw a behavior similar 
to the described in `Constant Value Patterns` section on PEP-622 
(https://www.python.org/dev/peps/pep-0622/#constant-value-patterns).

A very small and reproducible example:
```python
from typing import Any, ClassVar, Optional


class Maybe:
empty: ClassVar['Maybe']
_instance: Optional['Maybe'] = None

def __new__(cls, *args: Any, **kwargs: Any) -> 'Maybe':
if cls._instance is None:
cls._instance = object.__new__(cls)
return cls._instance


Maybe.empty = Maybe()


if __name__ == '__main__':
my_maybe = Maybe()
match my_maybe:
case Maybe.empty:
print('FIRST CASE')
case _:
print('DEFAULT CASE')
```

The output here is `FIRST CASE`, but if I delete `__new__` method the output is 
`DEFAULT CASE`.

Is that the correct behavior?

Python version: 3.10.0a7

--
components: Interpreter Core
messages: 397380
nosy: thepabloaguilar
priority: normal
severity: normal
status: open
title: Undesired Behavior on `match` using Singleton object
type: behavior
versions: Python 3.10

___
Python tracker 

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

[issue44608] Memory use increase in function _tkinter._flatten

[Ned Deily]

Change by Ned Deily :


--
components: +Tkinter

___
Python tracker 

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

[issue44602] Issue with get_build_version in msvc9compiler.py in distutils

[Ned Deily]

Change by Ned Deily :


--
components: +Distutils, Windows
nosy: +dstufft, eric.araujo, paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Taylor Alexander]

Taylor Alexander  added the comment:

Am I correct in thinking that the proposed change only affects the use case 
where a user types exit in to the REPL and hits return? And that any other case 
is unaffected?

I can only imagine that the majority of users who type exit in to the 
interpreter are expecting the REPL to exit.

Stargirl do I recall you mentioning (perhaps on twitter) that there are threads 
online of users expressing frustration with this feature? It would be helpful 
to see what users have said about it.

I would push back against the idea that this is about laziness. It sounds like 
this is about reducing user confusion.

--

___
Python tracker 

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

[issue44616] Incorrect tracing for "except" with variable

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Pablo, this is triggered by my bug report here: 
https://github.com/nedbat/coveragepy/issues/1187

I tested this again today with the 3.10 git head and still got the coverage 
misses.  Happy to try any other combinations.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Stargirl Flowers]

Stargirl Flowers  added the comment:

@steven.daprano I appreciate your perspective but you laid out a lot of strong 
opinions as if they're incontrovertible truths.

The motivation here isn't laziness- I created this bug because I saw actual 
people across various skill levels that are bugged by this behavior. I don't 
think that I can accept your declaration that changing this behavior would be 
user hostile in the face of multiple pieces of user feedback that says the 
existing behavior is hostile and changing it would be an improvement.

It's not about saving two characters. It's about doing what the user actual 
means and expects- based on feedback it seems that almost everyone expects 
"exit" to exit. Your point about being able to inspect objects falls a bit flat 
when the current behavior is:

>>> exit
Use exit() or Ctrl-D (i.e. EOF) to exit

If I weren't an experienced Python developer, I would have no idea that "exit" 
is actually an object and its __repr__ is what's showing there. To those who 
haven't ascended to language experts, this just seems like the program chiding 
us - like responding to "can I have some water" with "*may* you have some 
water". I didn't type "exit" to view the exit object, I typed it to leave the 
interpreter. If I *do* want to inspect it, well, there's dir() and help(), 
which are far, far more useful than the __repr__.

--

___
Python tracker 

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

[issue44616] Incorrect tracing for "except" with variable

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I assume this is due to some artificial bytecode for cleaning the variable in 
the exception

--

___
Python tracker 

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

[issue44616] Incorrect tracing for "except" with variable

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Marking as release blocker for the first release candidate.

Ned, I assume this comes from some recent bug report in coverage, but it would 
be great if you could ask your users to test the latest beta and report any 
issue before we release the first candidate. That way we can be more sure that 
we won't find any future surprise

Thanks in advance

--
nosy: +pablogsal
priority: normal -> release blocker

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Thanks Steven for your input and your comments and for expressing your 
concerns. I will hold the PR then until there is consensus on how to proceed 
and all concerns are addressed (eventually closing it if there isn't consensus).

I'm any case, I think we should at least proceed with the uncontroversial part 
of the proposal:

> (1) Include "exit" in the interpreter startup message, making it: Type 
> "help()", "copyright", "credits" or "license" for more information, or type 
> "exit()" to quit Python.

This is, including exit in the message and using the form exit() and help() 
instead of exit and help.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Steven D'Aprano]

Steven D'Aprano  added the comment:

> Other than that, only arguments based on the purity of the language, 
> but I think having this working is far more important.

Having this "working" is not important at all. This is precisely the 
sort of user-hostile anti-feature that we should avoid, not compromise 
the execution model just to save typing two characters.

I mean, seriously, we're talking about typing *two characters*. If 
people care so much about minimizing the amount of typing when they exit 
the REPL, they can use Ctrl-D or just close the terminal window.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Steven D'Aprano]

Steven D'Aprano  added the comment:

Please don't do this.

On Mon, Jul 12, 2021 at 02:19:58PM +, Pablo Galindo Salgado wrote:

> >>> exit
> bye!

This is a user-hostile and unfriendly UI for Python. The Python REPL is 
not a shell like bash etc, it should be safe to evaluate any builtin 
object at the interactive interpreter to view its repr without 
side-effects.

Especially not major side-effects such as exiting the interpreter with 
its total loss of program state.

The only motivation of this change is pure laziness to avoid typing 
parentheses when you want to call an object. I know that the creator of 
Perl famously says that laziness and hubris are virtues for programmers, 
but I disagree. Pandering to laziness in language design is not a 
virtue.

This does not add any new and improved functionality, or make the 
language better, or more friendly for beginners exploring things at the 
REPL. It is a useability regression, making it more hostile and 
unfriendly for people expecting to be able to view objects by entering 
them at the REPL without catastrophic side-effects, and the only benefit 
is to save two characters.

Having said that Pablo, I don't dislike your hack to make the exit repr 
pretend to be a confirmation message anywhere near as much. I don't 
think it is necessary, I think it looks even stranger when displaying 
the builtin namespace dict, but at least it is not a useability 
regression.

--

___
Python tracker 

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

[issue44611] CPython uses deprecated randomness API

[Dan Stromberg]

Dan Stromberg  added the comment:

Yes, cng-portal.

On Mon, Jul 12, 2021 at 3:24 PM Thomas Grainger 
wrote:

>
> Thomas Grainger  added the comment:
>
> https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal ?
>
> --
> nosy: +graingert
>
> ___
> Python tracker 
> 
> ___
>

-- 

Dan Stromberg | Senior Software Engineer

Mobile +1.949.342.6502



** This email is confidential and is intended for the recipient(s)
addressed herein **

--

___
Python tracker 

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

[issue44613] Make importlib.metadata non-provisional in Python 3.10

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:

Jason, I think the question you raise re: accelerated deprecation, is probably 
a RM or SC question.  I'll nosy in Pablo and see if he has a strong opinion.

--
nosy: +pablogsal

___
Python tracker 

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

[issue44613] Make importlib.metadata non-provisional in Python 3.10

[Barry A. Warsaw]

Change by Barry A. Warsaw :


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

[issue44613] Make importlib.metadata non-provisional in Python 3.10

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:


New changeset 7223ce3b3f50ec8a825e317437ea0359b6ad6856 by Miss Islington (bot) 
in branch '3.10':
bpo-44613: Make importlib.metadata non-provisional (GH-27101) (#27106)
https://github.com/python/cpython/commit/7223ce3b3f50ec8a825e317437ea0359b6ad6856


--

___
Python tracker 

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

[issue43950] Include column offsets for bytecode instructions

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 9c3eaf88dc5d5bed80cc45936de06b7b3162bc6d by Ammar Askar in branch 
'main':
bpo-43950: Add documentation for PEP-657 (GH-27047)
https://github.com/python/cpython/commit/9c3eaf88dc5d5bed80cc45936de06b7b3162bc6d


--

___
Python tracker 

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

[issue44613] Make importlib.metadata non-provisional in Python 3.10

[Barry A. Warsaw]

Barry A. Warsaw  added the comment:


New changeset f6954cdfc50060a54318fb2aea4d80408381243a by Barry Warsaw in 
branch 'main':
bpo-44613: Make importlib.metadata non-provisional (#27101)
https://github.com/python/cpython/commit/f6954cdfc50060a54318fb2aea4d80408381243a


--

___
Python tracker 

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

[issue44613] Make importlib.metadata non-provisional in Python 3.10

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +25651
pull_request: https://github.com/python/cpython/pull/27106

___
Python tracker 

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

[issue44616] Incorrect tracing for "except" with variable

[Barry A. Warsaw]

Change by Barry A. Warsaw :


--
nosy: +barry

___
Python tracker 

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

[issue34451] docs: tutorial/introduction doesn't mention toggle of prompts

[Thomas]

Change by Thomas :


--
keywords: +patch
nosy: +thmsdnnr
nosy_count: 6.0 -> 7.0
pull_requests: +25650
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27105

___
Python tracker 

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

[issue44616] Incorrect tracing for "except" with variable

[Ned Batchelder]

Ned Batchelder  added the comment:

Based on https://github.com/nedbat/coveragepy/issues/1187, btw

--

___
Python tracker 

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

[issue44616] Incorrect tracing for "except" with variable

[Ned Batchelder]

New submission from Ned Batchelder :

This construct isn't traced properly:

except ExceptionName as var:
if something:
raise

Here's a reproducer:

-- 8< -
import linecache, sys

def trace(frame, event, arg):
# The weird globals here is to avoid a NameError on shutdown...
if frame.f_code.co_filename == globals().get("__file__"):
lineno = frame.f_lineno
print("{} {}: {}".format(event[:4], lineno, linecache.getline(__file__, 
lineno).rstrip()))
return trace

def f(x):
try:
1/0
except ZeroDivisionError as error:
if x:
raise
return 12

print(sys.version)
sys.settrace(trace)

for x in [0, 1]:
try:
print(f(x))
except:
print("oops")
---

When run with 3.10.0b4, it produces this output:

  3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
  call 10: def f(x):
  line 11: try:
  line 12: 1/0
  exce 12: 1/0
  line 13: except ZeroDivisionError as error:
  line 14: if x:
* line 15: raise
  line 16: return 12
  retu 16: return 12
  12
  call 10: def f(x):
  line 11: try:
  line 12: 1/0
  exce 12: 1/0
  line 13: except ZeroDivisionError as error:
  line 14: if x:
  line 15: raise
  retu 15: raise
  oops

The starred line claims that raise is being run, but it is not run at that 
point.

The variable on the except clause is important.  If you change that line to 
"except ZeroDivisionError:", then the output is correct:

  3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
  call 10: def f(x):
  line 11: try:
  line 12: 1/0
  exce 12: 1/0
  line 13: except ZeroDivisionError:
  line 14: if x:
  line 16: return 12
  retu 16: return 12
  12
  call 10: def f(x):
  line 11: try:
  line 12: 1/0
  exce 12: 1/0
  line 13: except ZeroDivisionError:
  line 14: if x:
  line 15: raise
  retu 15: raise
  oops

--
components: Interpreter Core
keywords: 3.10regression
messages: 397365
nosy: Mark.Shannon, nedbat
priority: normal
severity: normal
status: open
title: Incorrect tracing for "except" with variable
type: behavior
versions: Python 3.10

___
Python tracker 

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

[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs

[Andrei Kulakov]

Andrei Kulakov  added the comment:

But rsync is a quite more specific tool. For example, unix cmp command does not 
guess based on any part of `stat` sig. That's a much closer command in scope to 
'filecmp'.

--

___
Python tracker 

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

[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs

[Christof Hanke]

Christof Hanke  added the comment:

Hi Andrei,

I would follow rsync. 
>From the man page:
"""
[...]
 -c, --checksum
  This changes the way rsync checks if the files have been changed 
and are in need of a transfer.   Without  this  option,  rsync
  uses  a  "quick  check" that (by default) checks if each file’s 
size and time of last modification match between the sender and
  receiver. 
[...]
"""

so, yes you can have false positives with a shallow comparison of size + mtime 
only. But that's usually ok for e.g. incremental backups. 


Wow, the bug is that old...

--

___
Python tracker 

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

[issue44611] CPython uses deprecated randomness API

[Thomas Grainger]

Thomas Grainger  added the comment:

https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal ?

--
nosy: +graingert

___
Python tracker 

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

[issue44611] CPython uses deprecated randomness API

[Tim Peters]

Tim Peters  added the comment:

Dan, the Microsoft URL in your message gives a 404 for me. Did you perhaps mean 
to end it with "cng-portal" (instead of "cng-por")?

--
nosy: +tim.peters

___
Python tracker 

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

[issue44615] Multiprocessing Pool example and comments incomplete/wrong?

[Florian Streibelt]

New submission from Florian Streibelt :

The docs at the url

https://docs.python.org/3/library/multiprocessing.html#module-multiprocessing.pool

state in a red warning box:

"Warning

multiprocessing.pool objects have internal resources that need to be properly 
managed (like any other resource) by using the pool as a context manager or by 
calling close() and terminate() manually. Failure to do this can lead to the 
process hanging on finalization."


however, when using the context manager, as it is also shown in the examples, 
the context manager will call terminate() instead of close() and join() on the 
pool, possible leading to deadlocks if I understand the documentation correct.

It seems the only safe way of using a Pool as Context Manager is to manually 
call pool.close() and pool.join() prior to leaving it, which, to be honest, 
does not make sense to me.


see pool.py:

def __exit__(self, exc_type, exc_val, exc_tb):
self.terminate()

--
assignee: docs@python
components: Documentation
messages: 397360
nosy: docs@python, mutax
priority: normal
severity: normal
status: open
title: Multiprocessing Pool example and comments incomplete/wrong?
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

[issue44613] Make importlib.metadata non-provisional in Python 3.10

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Thanks Barry for filing this. I was planning to do it but happy for you to beat 
me to it.

I had one question I'd been meaning to ask - with this change, can the code 
paths that were deprecated in 3.10 be removed in 3.11 (SelectableGroups and 
cast to dict of sequence of EntryPoint objects)? I was planning a slightly 
accelerated removal of the compatibility support because:

(a) The backport presented the deprecation for older Pythons already and so 
users will likely have migrated off the deprecated behaviors prior to the 
release of 3.10.
(b) It will be substantially harder to maintain the backport while the backport 
drops that support.
(c) In extreme cases, the backport is available to provide backward 
compatibility even for Python 3.11.

Let me know if you would rather I pose this question elsewhere or elaborate on 
the proposition. It doesn't affect the PR or move out of provisional.

--

___
Python tracker 

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

[issue44614] Broken Pipe in Server of Manager in multiprocessing when finalizing, sometimes

[Florian Streibelt]

New submission from Florian Streibelt :

It seems that the shutdown() method of the Server in in managers.py is already 
sending the result of its execution directly into the connection, and then the 
handle_request() method is trying to send ('#RETURN', None) yet again after 
returning from the call to shutdown() which sometimes yields a Broken Pipe 
Exception.

with the following line in handle_request():
result = func(c, *args, **kwds)
a call to shutown() is made, and in shutdown() I see:
c.send(('#RETURN', None))

and back in handle_request():
msg = ('#RETURN', result)
…
c.send(msg)

attached you find a minimal example that shows this behaviour sometimes, if 
logging is set to not more than DEBUG. I am guessing that the Broken Pipe 
depends on a race with the other side being closed.

Although the race condition does not look like having an impact, it is highly 
confusing when debugging. 


log:
  INFO   MainProcess util.py:54  sending shutdown message 
to manager
 DEBUGBaseManager-12 util.py:50  manager received shutdown 
message
  INFOBaseManager-12 util.py:54  Failure to send message: 
('#RETURN', None)
  INFOBaseManager-12 util.py:54  process shutting down
  INFOBaseManager-12 util.py:54   ... request was (None, 
'shutdown', (), {})
 DEBUGBaseManager-12 util.py:50  running all "atexit" 
finalizers with priority >= 0
  INFOBaseManager-12 util.py:54   ... exception was 
BrokenPipeError(32, 'Broken pipe')
 DEBUGBaseManager-12 util.py:50  running the remaining 
"atexit" finalizers
  INFOBaseManager-12 util.py:54  process exiting with 
exitcode 0

--
components: Library (Lib)
files: race2.py
messages: 397358
nosy: mutax
priority: normal
severity: normal
status: open
title: Broken Pipe in Server of Manager in multiprocessing when finalizing, 
sometimes
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50145/race2.py

___
Python tracker 

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

[issue38825] shutil.disk_usage - Lacking documentation

[Norman Lorrain]

Norman Lorrain  added the comment:

Something like this:

   .. impl-detail::
  Where applicable (e.g. Unix) *path* must point to somewhere on a
**mounted** filesystem partition.

On Sun, 11 Jul 2021 at 16:18, Tyler Crompton  wrote:

>
> Tyler Crompton  added the comment:
>
> Not even the kernel knows how much space is available on a nonmounted
> partition. It doesn't know much beyond the fact that it exists and where it
> exists. There exist tools that can analyze nonmounted partitions, but these
> will vary by filesystem and operating system. If someone wants to implement
> solutions for the most common filesystem-OS combinations, then that might
> be helpful.
>
> But considering that no one has done that or even asked for it yet, I'm
> not sure that doing so is worth the effort. So I agree that documenting it
> is the best approach. It should be documented such that the limitations are
> mentioned, not necessarily how it's implemented. If explaining which system
> calls are used helps explain the limitations, then so be it. Additionally,
> as far as I'm concerned, there's no reason to restrict other Python
> implementations from implementing functionality for nonmounted disks. So
> the limitations should be described as being CPython-specific, akin to what
> is done for `readline.set_auto_history`.
>
> --
> nosy: +tylercrompton
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Also see this 16 years old issue: https://bugs.python.org/issue1234674

--

___
Python tracker 

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

[issue44606] Discrepancy between isinstance() and issubclass() for union types

[Guido van Rossum]

Guido van Rossum  added the comment:

Ken Jin, should we treat type(None) as a subclass of int|None?

--
nosy: +kj

___
Python tracker 

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

[issue44593] _randbelow_with_getrandbits may request an unnecessary random bit

[Mark Dickinson]

Change by Mark Dickinson :


--
resolution:  -> duplicate
superseder:  -> _randbelow_with_getrandbits function inefficient with powers of 
two

___
Python tracker 

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

[issue10716] Modernize pydoc to use better HTML and separate CSS

[Éric Araujo]

Éric Araujo  added the comment:

On second thought, this issue is not purely programming, but also has a UI 
component.  Better HTML and separated CSS would be good, but before that I 
think we’d need someone with design chops to mock up a better page layout and 
style (better than big coloured rectangles!), then I think have a discussion on 
python-dev (not to discuss all details in committee, but to validate the 
overall change).

--

___
Python tracker 

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

[issue10716] Modernize pydoc to use better HTML and separate CSS

[Éric Araujo]

Éric Araujo  added the comment:

Someone would need to take the patch, apply it to current main branch, fix 
issues and open a PR.

--
versions: +Python 3.11 -Python 3.8

___
Python tracker 

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

[issue43950] Include column offsets for bytecode instructions

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset 1890dd235f618d60c938f6904d2e1a8a56f99c1c by Batuhan Taskaya in 
branch 'main':
bpo-43950: Specialize tracebacks for subscripts/binary ops (GH-27037)
https://github.com/python/cpython/commit/1890dd235f618d60c938f6904d2e1a8a56f99c1c


--

___
Python tracker 

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

[issue44612] inspect module points that could be using f-String

[Eric V. Smith]

Eric V. Smith  added the comment:

Yes, thank you Leonardo!

There are probably places in the stdlib where changing to f-strings would be a 
performance improvement. Of course finding those places is the challenge!

--
nosy: +eric.smith

___
Python tracker 

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

[issue44605] functools.total_ordering doesn't work with metaclasses

[Dennis Sweeney]

Dennis Sweeney  added the comment:

The one twist is that if type(b) is a strict subtype of type(a), then "a < b" 
first calls type(b).__gt__(b, a), then falls back to type(a).__lt__(a, b). 
Example:

>>> class Int(int):
... def __gt__(self, other):
... print("Here!")
... return int(self) > int(other)
... 
... 
>>> 5 < Int(6)
Here!
True

see 
https://github.com/python/cpython/blob/da2e673c53974641a0e13941950e7976bbda64d5/Objects/object.c#L683

So I think replacing "a.__lt__(b)" with "a < b" would be an unnecessary change 
in behavior, since "a < b" still has to decide which method to use.

I think instead "a.__lt__(b)" could be replaced with "type(a).__lt__(a, b)"

--
nosy: +Dennis Sweeney

___
Python tracker 

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

[issue44612] inspect module points that could be using f-String

[Leonardo Freua]

Leonardo Freua  added the comment:

Thanks, Ammar. I'll look.

--

___
Python tracker 

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

[issue44612] inspect module points that could be using f-String

[Ammar Askar]

Ammar Askar  added the comment:

Thanks for trying to help Leonardo! You might consider looking for easy issues 
on the bug tracker or reviewing open pull requests to help. Definitely take a 
look at the dev guide :) https://cpython-devguide.readthedocs.io/fixingissues/

--
resolution:  -> rejected
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

[issue44612] inspect module points that could be using f-String

[Leonardo Freua]

Leonardo Freua  added the comment:

Understood. Anyway, it was good to try to help at this point.

--

___
Python tracker 

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

[issue44600] match/case statements trace incorrectly in 3.10.0b4

[Ammar Askar]

Ammar Askar  added the comment:

Brandt, maybe this regression test from a previous tracing bug might be useful 
for the test writing: 
https://github.com/python/cpython/pull/22026/files#diff-8b73bfc55514d8add8904c5f4d1d24b7b644ebfccba8d846085303577aa94dd6

--
nosy: +ammar2

___
Python tracker 

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

[issue44612] inspect module points that could be using f-String

[Ammar Askar]

Ammar Askar  added the comment:

As per https://bugs.python.org/issue36249 and https://bugs.python.org/issue38351

We don't generally do large-scale changes that are mostly formatting based. We 
would prefer that these sort of improvements happen when someone happens to be 
touching that code anyway unless there is a demonstrable improvement from them.

--
nosy: +ammar2

___
Python tracker 

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

[issue44613] Make importlib.metadata non-provisional in Python 3.10

[Barry A. Warsaw]

Change by Barry A. Warsaw :


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

___
Python tracker 

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

[issue44612] inspect module points that could be using f-String

[Leonardo Freua]

Change by Leonardo Freua :


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

___
Python tracker 

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

[issue44613] Make importlib.metadata non-provisional in Python 3.10

[Barry A. Warsaw]

New submission from Barry A. Warsaw :

As discussed with Jason, importlib.metadata will be made non-provisional in 
3.10.  I have a PR in the works for this.

--
assignee: barry
components: Documentation
messages: 397344
nosy: barry, jaraco
priority: normal
severity: normal
status: open
title: Make importlib.metadata non-provisional in Python 3.10
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

[issue44612] inspect module points that could be using f-String

[Leonardo Freua]

New submission from Leonardo Freua :

There are some points in inspect module (I counted 48 since version 3.7) that 
could be using f-String formatting instead of format().

Changing these points will improve code readability, it will also decrease the 
complexity at these points and not to mention the fact that f-String formatting 
has better performance.

Obs.: Many other points could receive this improvement in other modules. This 
would provide the improvements I mentioned earlier, especially in older 
snippets of code.

--
components: Library (Lib)
messages: 397343
nosy: Leonardofreua
priority: normal
severity: normal
status: open
title: inspect module points that could be using f-String
type: enhancement
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

[issue44610] Format issue with strftime and %Y

[Bartosz Kaznowski]

Change by Bartosz Kaznowski :


--
versions: +Python 3.10, Python 3.6, Python 3.7, Python 3.8

___
Python tracker 

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

[issue44610] Format issue with strftime and %Y

[Bartosz Kaznowski]

Change by Bartosz Kaznowski :


--
versions: +Python 3.9 -Python 3.7

___
Python tracker 

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

[issue44559] Enum: revert to 3.9

[Ethan Furman]

Change by Ethan Furman :


--
pull_requests: +25647
pull_request: https://github.com/python/cpython/pull/27099

___
Python tracker 

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

[issue43299] pyclbr.readmodule_ex traversing "import __main__": dies with ValueError: __main__.__spec__ is None / is not set

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Upon further pondering, I'm not sure PyWin is doing the right thing here. I 
believe it's best to first file it with PyWin and find out what it is trying to 
do and why.

Pyclbr behavior sort of makes sense to me -- pyclbr goal is to parse and browse 
the source of a module, but the __main__ module is either the current script, 
in which case it can be imported under another name (and then it would have the 
__spec__), or it's an interactive session, which you probably don't need to 
browse (maybe?).

--

___
Python tracker 

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

[issue44607] Teleport method for turtle class

[Muffinlicious]

Muffinlicious  added the comment:

Turtle is  the most accessible and well-known drawing module for kids to use so 
teleporting makes more sense in the context of drawing random shapes or small 
pictures around the screen. I've seen the penup/goto/pendown combo so often 
that I figure it at least warrants a suggestion. Also my crappy function was 
mostly just meant as an outline, haha.

--

___
Python tracker 

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

[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Christof and Alexander, as you both said your preference is to have some way of 
enforcing "only shallow" compare, I want to clarify -- it seems if you do that, 
you will get the answer of True if the files are most likely the same (sig is 
equal), but if the sig is not equal, I'm not sure what answer you expect or 
why. The sig may be different because of mtime, and then the files may be 
different or the same, it's anyone's guess.

I wonder if both of you expect the same behavior, and if so, for the same use 
case or not?

--
nosy: +andrei.avk

___
Python tracker 

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

[issue44611] CPython uses deprecated randomness API

[Dan Stromberg]

New submission from Dan Stromberg :

CPython 3.9 uses CryptGenRandom(), which has been deprecated by Microsoft.

I'm told the randomness produced by CryptGenRandom() is fine, but Microsoft has 
introduced a newer API for getting randomness.

For these reasons, Python/bootstrap_hash.c should be updated to use 
https://docs.microsoft.com/en-us/windows/win32/seccng/cng-por , but it is not 
urgent, and is not needed in older versions of CPython.

Also the documentation that references CryptGenRandom() should be updated, EG: 
https://docs.python.org/3/library/os.html#os.urandom

--
components: Windows
messages: 397339
nosy: paul.moore, steve.dower, strombrg, tim.golden, zach.ware
priority: normal
severity: normal
status: open
title: CPython uses deprecated randomness API
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

[issue44571] itertools: takedowhile()

[pavel-lexyr]

pavel-lexyr  added the comment:

Thank you - that answers the questions. The use case where we would want to 
know if the last element is transitional or not completely slipped my mind for 
some reason.

--

___
Python tracker 

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

[issue44571] itertools: takedowhile()

[Tim Peters]

Tim Peters  added the comment:

That said, if you really do want those semantics, it's easy to build on top of 
Raymond's API:

def takewhile_plus_one_more_if_any(pred, iterable):
from itertools import islice, chain
before, after = before_and_after(pred, iterable)
return chain(before, islice(after, 1))

--

___
Python tracker 

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

[issue44428] _ProactorBasePipeTransport.abort() after _ProactorBasePipeTransport.close() does not cancel writes

[Thomas Grainger]

Change by Thomas Grainger :


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue44571] itertools: takedowhile()

[Tim Peters]

Tim Peters  added the comment:

If you don't use the 'after` iterator, then of course you'll never see the 
values (if any) it would have yielded.

How could it possibly be otherwise? By design and construction, the `before` 
iterator ends before yielding the first (if any) transitional element.

As Raymond said at the start, the `takedowhile()` proposal appears much harder 
to use correctly, since there's no reasonably sane way to know that the last 
value it yields _is_ the transitional element (or, perhaps, that there was no 
transitional element, and the underlying iterable was just exhausted without 
finding one).

If the proposal were instead for `takewhile_plus_one_more_if_any()`, then at 
least the ugly name would warn about the surprising intended behavior ;-)

--

___
Python tracker 

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

[issue42194] Docs for argparse.BooleanOptionalAction missing "New in version 3.9"

[Łukasz Langa]

Change by Łukasz Langa :


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

[issue42194] Docs for argparse.BooleanOptionalAction missing "New in version 3.9"

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset c786988b19d7b6808d4c940f7206b95e49e06b71 by Miss Islington (bot) 
in branch '3.9':
bpo-42194: Add "New in version: 3.9" to argparse.BooleanOptionalAction 
(GH-23026) (#27098)
https://github.com/python/cpython/commit/c786988b19d7b6808d4c940f7206b95e49e06b71


--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

Since Paul is +1 if another core dev (or devs) are +1 as well with the approach 
in PR27096 I would feel confident to proceed with this. Alternatively, we could 
discuss this more generally in python-dev if someone feels that we should have 
a more open discussion about the tradeoffs.

--

___
Python tracker 

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

[issue43048] Printing RecursionError results in RecursionError

[Łukasz Langa]

Change by Łukasz Langa :


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

[issue43048] Printing RecursionError results in RecursionError

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 489c27358376e772a61753c3f67daa836ca1eab7 by Vladimir Feinberg in 
branch '3.9':
[3.9] bpo-43048: RecursionError traceback RecursionError bugfix for cpy3.9 
(GH-24460) (#24460)
https://github.com/python/cpython/commit/489c27358376e772a61753c3f67daa836ca1eab7


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue42194] Docs for argparse.BooleanOptionalAction missing "New in version 3.9"

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 721d4796be60e6a0a11dee8318794f78928648c1 by Miss Islington (bot) 
in branch '3.10':
bpo-42194: Add "New in version: 3.9" to argparse.BooleanOptionalAction 
(GH-23026) (#27097)
https://github.com/python/cpython/commit/721d4796be60e6a0a11dee8318794f78928648c1


--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> Are there any downsides to doing it this way? It seems tightly scoped and 
> with minimal overhead.

We also need to support quit(), if we go this route.

It makes parsing in the REPL a bit slower because it needs to check for this at 
every command and is a bit "floating" in the middle of the parser and the 
compiler (but that's a consequence that we don't have any defined layer for 
this). We also need to check that this also works with piping input.

Other than that, only arguments based on the purity of the language, but I 
think having this working is far more important.

--

___
Python tracker 

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

[issue43299] pyclbr.readmodule_ex traversing "import __main__": dies with ValueError: __main__.__spec__ is None / is not set

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Actually, I was mistaken about this, `readmodule_ex` can get the __main__ from 
sys.modules.. I will look more into this later today.

--

___
Python tracker 

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

[issue44610] Format issue with strftime and %Y

[Bartosz Kaznowski]

New submission from Bartosz Kaznowski :

When you convert a date pre the year 1000 to a string with `%Y` as the 
formatter and then back to a date again then it fails. This is because `%Y` 
expects it to be formatted with leading zeroes. For example, the year 1/01/01 
(/mm/dd) should be 0001/01/01 when formatting using %Y/%m/%d. However, %Y 
returns 1.
You can see this in action here:

from datetime import date, datetime
format = "%Y-%m-%d"
formatted = date.min.strftime("%Y-%m-%d")
datetime.strptime(formatted, format).date()

`ValueError: time data '1-01-01' does not match format '%Y-%m-%d'` is raised on 
the forth line.

--
components: Library (Lib)
messages: 397329
nosy: bkaznowski
priority: normal
severity: normal
status: open
title: Format issue with strftime and %Y
type: behavior
versions: Python 3.7

___
Python tracker 

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

[issue26329] os.path.normpath("//") returns //

[Łukasz Langa]

Change by Łukasz Langa :


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

[issue26329] os.path.normpath("//") returns //

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 47abf240365ddd54a91c6ac167900d4bf6806c4f by Miss Islington (bot) 
in branch '3.9':
bpo-26329: update os.path.normpath documentation (GH-20138) (#27095)
https://github.com/python/cpython/commit/47abf240365ddd54a91c6ac167900d4bf6806c4f


--

___
Python tracker 

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

[issue42194] Docs for argparse.BooleanOptionalAction missing "New in version 3.9"

[miss-islington]

Change by miss-islington :


--
pull_requests: +25646
pull_request: https://github.com/python/cpython/pull/27098

___
Python tracker 

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

[issue42194] Docs for argparse.BooleanOptionalAction missing "New in version 3.9"

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset da2e673c53974641a0e13941950e7976bbda64d5 by David Sanders in 
branch 'main':
bpo-42194: Add "New in version: 3.9" to argparse.BooleanOptionalAction 
(GH-23026)
https://github.com/python/cpython/commit/da2e673c53974641a0e13941950e7976bbda64d5


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue42194] Docs for argparse.BooleanOptionalAction missing "New in version 3.9"

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 9.0 -> 10.0
pull_requests: +25645
pull_request: https://github.com/python/cpython/pull/27097

___
Python tracker 

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

[issue43207] InspectLoader.is_package is not an abstract method

[Łukasz Langa]

Change by Łukasz Langa :


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

[issue38820] Make Python compatible with OpenSSL 3.0.0

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset c92b391dcefe9a7b3e6290bc2e2356eedfcf4bc3 by Christian Heimes in 
branch '3.9':
[3.9] bpo-38820: Test with OpenSSL 3.0.0-alpha16 (GH-25942) (#25944)
https://github.com/python/cpython/commit/c92b391dcefe9a7b3e6290bc2e2356eedfcf4bc3


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue43207] InspectLoader.is_package is not an abstract method

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 779983ed7f86610be4a7201deeffdcb8608977e0 by Miss Islington (bot) 
in branch '3.9':
bpo-43207: InspectLoader.is_package is not an abstract method (GH-24517) 
(#26322)
https://github.com/python/cpython/commit/779983ed7f86610be4a7201deeffdcb8608977e0


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue43298] Windows build cannot detect missing Windows SDK

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset e7009f4f9a6a55036ef628a07bedc8dab1aa851e by Miss Islington (bot) 
in branch '3.9':
bpo-43298: Improved error message when building without the Windows SDK 
installed (GH-26800) (#26803)
https://github.com/python/cpython/commit/e7009f4f9a6a55036ef628a07bedc8dab1aa851e


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue44472] ltrace functionality doesn't work if there is an exception set

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 6fb4248cd9502f50dd089fdcf548d735dcfd981e by Miss Islington (bot) 
in branch '3.9':
bpo-44472: Fix ltrace functionality when exceptions are raised (GH-26822) 
(#26831)
https://github.com/python/cpython/commit/6fb4248cd9502f50dd089fdcf548d735dcfd981e


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue44022] urllib http client possible infinite loop on a 100 Continue response

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 0389426fa4af4dfc8b1d7f3f291932d928392d8b by Miss Islington (bot) 
in branch '3.8':
bpo-44022: Improve the regression test. (GH-26503) (#26506)
https://github.com/python/cpython/commit/0389426fa4af4dfc8b1d7f3f291932d928392d8b


--

___
Python tracker 

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

[issue26329] os.path.normpath("//") returns //

[Łukasz Langa]

Łukasz Langa  added the comment:


New changeset 443db64f496d3988d20cfda2c3c2ceb6702df36f by Miss Islington (bot) 
in branch '3.10':
bpo-26329: update os.path.normpath documentation (GH-20138) (GH-27094)
https://github.com/python/cpython/commit/443db64f496d3988d20cfda2c3c2ceb6702df36f


--
nosy: +lukasz.langa

___
Python tracker 

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

[issue44609] Buffer support in the stable ABI

[Tarun Johar]

New submission from Tarun Johar :

PEP 384 and PEP 652 define a stable ABI to be used with Python 3.2 and later.  
On Windows, symbols for the stable ABI are exported from the python3.dll shared 
library.

The following functions are present in Python 3.9 but have been removed from 
Python 3.10b3:

PyObject_AsCharBuffer()
PyObject_AsReadBuffer()
PyObject_AsWriteBuffer()
PyObject_CheckReadBuffer()

The justification for the removal of these functions was discussed in this 
issue:

https://bugs.python.org/issue41103

Without these functions, an extension cannot utilize the stable ABI to access 
the buffer memory of data structures.  The buffer protocol is suggested as an 
alternative, but the buffer functions PyObject_GetBuffer() and 
PyBuffer_Release() are not present in the stable ABI.

While these two functions may be added to the stable ABI, removal of the four 
functions above makes Python 3.10 incompatible with previous versions.  It is 
requested that the four functions be reinstated and maintained as described in 
PEP 652.

--
components: Build
messages: 397319
nosy: tarun.johar
priority: normal
severity: normal
status: open
title: Buffer support in the stable ABI
type: behavior
versions: Python 3.10

___
Python tracker 

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

[issue42958] filecmp.cmp(shallow=True) isn't actually shallow when only mtime differs

[Christof Hanke]

Christof Hanke  added the comment:

Hi,

this is also discussed in https://bugs.python.org/issue41354.

Ciao,
  Christof

--
nosy: +chanke

___
Python tracker 

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

[issue41354] filecmp.cmp documentation does not match actual code

[Christof Hanke]

Christof Hanke  added the comment:

Andrei,

See https://bugs.python.org/issue42958

Someone else stumbled over this topic.

Maybe you can merge these two requests?

Otherwise, I'm fine with a new arg.

Christof

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Paul Ganssle]

Paul Ganssle  added the comment:

I'm +1 for Pablo's approach. That's approximately what I meant by "special-case 
it in the REPL layer" anyway.

Are there any downsides to doing it this way? It seems tightly scoped and with 
minimal overhead.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Stargirl Flowers]

Stargirl Flowers  added the comment:

Fair point about semantic behavior and complexity, but hopefully we can come up 
with a solution that's easier for users.

I do like the PR suggested.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> I do want to be cautious of saying that we can't do it because of the way the 
> REPL is currently implemented- which appears to be an implementation driven 
> by convenience more than necessity.

Apologies if I have not been clear on this. Is not that we can't do it, is just 
the balance between complexity and the benefits of the change.

> I also find pushing against special-case behavior in the REPL strange. The 
> REPL already has special-case behavior: printing the header, the 
> __interactivehook__ that configures readline, heck, the `>>>` are unique the 
> REPL and plainly copy-pasting a REPL session into a file won't work.

But that is just printing, not semantic behaviour. What we are discussing here 
is to give a different semantic behaviour to exit NAME only in interactive 
mode. This is fundamentally different that just printing or make the parser 
show ">>>" every time it asks for a new line, as those are not changing the 
*meaning* of Python code.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Stargirl Flowers]

Stargirl Flowers  added the comment:

I do want to be cautious of saying that we can't do it because of the way the 
REPL is currently implemented- which appears to be an implementation driven by 
convenience more than necessity.

I also find pushing against special-case behavior in the REPL strange. The REPL 
already has special-case behavior: printing the header, the __interactivehook__ 
that configures readline, heck, the `>>>` are unique the REPL and plainly 
copy-pasting a REPL session into a file won't work.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

One thing we *could* do which is not super invasive, is to match a single AST 
node of type NAME at the end of Python run. This seems to work but is a bit 
inelegant:

>>> print(exit)
Use exit() or Ctrl-D (i.e. EOF) to exit
>>> [exit]
[Use exit() or Ctrl-D (i.e. EOF) to exit]
>>> exit
bye!

I have opened a draft with this in PR27096

--
stage: patch review -> 

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


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

___
Python tracker 

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

[issue44571] itertools: takedowhile()

[pavel-lexyr]

pavel-lexyr  added the comment:

There is a core part of the `takedowhile` proposal's use case that I am having 
trouble envisioning via the alternative `before_and_after` proposal. If the 
`after` part of the iterator the user does not engage with, the transitional 
elements will be stuck indefinitely. What would a correct usage be, in case one 
wants the following two conditions to hold true:

1. the amount of elements after the first falsifying one is minimal, i.e. 0
2. all the yielded elements are processed no matter what?

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> would be in the REPL layer by special-casing `exit`

Unfortunately, there is no REPL *layer* as my previous comments mentioned.

There is a few details that change for interactive mode but fundamentally the 
pipeline is the same as reading from a file, except that the file is stdin and 
it has some special logic in the parser to do that in a lazy way and fail fast. 
But there is no semantic information that separates REPL for non-REPL.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Paul Ganssle]

Paul Ganssle  added the comment:

If we want to confine the behavior to just the repl, we could possibly have the 
repl set an environment variable or something of that nature for interactive 
sessions, so that `__repr__` of `exit` can tell the difference between being 
invoked in a REPL and not — though I suppose it could cause some pretty 
frustrating and confusing behavior if some library function is doing something 
like this behind the scenes:

```
def get_all_reprs():
return {
  v: repr(obj) for v, obj in globals()
]
```

You could invoke some function and suddenly your shell quits for no apparent 
reason. And if it only happens when triggered in a REPL, you'd be doubly 
confused because you can't reproduce it with a script.

I do think the "type exit() to exit" is a papercut. The ideal way to fix it 
would be in the REPL layer by special-casing `exit`, but I realize that that 
may introduce unnecessary complexity that isn't worth it for this one thing.

> Second, if absolutely necessary we could ask the user to confirm that they 
> want to exit.

A thought occurs: we could simply re-word the message to make it seem like 
we're asking for confirmation:

```
>>> exit
Do you really want to exit? Press Ctrl+Z to confirm, or type exit() to exit 
without confirmation.
```

Then it won't seem as much like we know what you meant to do but aren't doing 
it, despite the fact that the behavior is exactly the same .

--
nosy: +p-ganssle

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

For reference, IPython has an entire interception + filtering mechanism to auto 
call certain functions:

https://github.com/ipython/ipython/blob/0e4d6390b2174fb1b352a082b72ad387ae696e87/IPython/core/prefilter.py#L414-L425

where exit is one instance of this:

https://github.com/ipython/ipython/blob/81b87f20aa8836b42fbb2b1dee7b662d8d5d46c6/IPython/core/autocall.py#L51-L57

As you can see, this requires an entirely different execution abstraction and a 
new layer in the middle that filters/intercepts the user input **after** it has 
been transformed into some intermediate representation.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

IPython and other reprs are an entire abstraction layer on top of Python, which 
allows them to do a lot of extra things like implement new commands and alters 
a lot of behaviours, but the CPython REPL is just the interpreter evaluating 
commands, and this is very coupled with the regular machinery, at to the point 
that is the tokenizer the one consuming input (lazily!) from standard input.

Unless I am missing anything, the only way to do the desired behaviour is to 
re-architect part of how interactive mode works or to directly make exit a 
keyword, which is backwards incompatible. 

I may be missing simpler ways of course, but in general, my opinion is that 
anything that involves modifying the compiler pipeline to somehow special case 
this is too much cost for the advantage.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

> However, I disagree that "exit" should not be a special case. 

But a special case of *what*? How would you implement this in a 
backwards-compatible way?

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Stargirl Flowers]

Stargirl Flowers  added the comment:

Also, if a PEP is recommended, I will be happy to author it.

--

___
Python tracker 

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

[issue44603] REPL: exit when the user types exit instead of asking them to explicitly type exit()

[Stargirl Flowers]

Stargirl Flowers  added the comment:

I don't think we should completely write off the possibility of doing this just 
because the *current* implementation is counter-intuitive. As I expressed in 
the original post, the explanation of this behavior is rather unsatisfying to 
newcomers.

Also @steven.daprano, please do not confuse one recommendation for 
implementation for the concept.

I agree that printing the Quitter object should not exit the interpreter. 
However, I disagree that "exit" should not be a special case. Specifically, 
when using the interactive interpreter the behavior (regardless of 
implementation strategy) would ideally be:

>>> exit
(interpreter exit)
>>> exit()
(interpreter exit)
>>> print(exit)
Call "exit()" to quit Python. When using the interactive interpreter you can 
simply type "exit".

This behavior closely matches IPython's behavior, and even a cursory search 
reveals not only individual users running into this and being frustrated, but 
even threads where this behavior has reached "meme status": 
https://twitter.com/0xabad1dea/status/1414204661360472065?s=19

--

___
Python tracker 

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

[issue26329] os.path.normpath("//") returns //

[miss-islington]

Change by miss-islington :


--
pull_requests: +25643
pull_request: https://github.com/python/cpython/pull/27095

___
Python tracker 

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

[issue26329] os.path.normpath("//") returns //

[Joannah Nanjekye]

Joannah Nanjekye  added the comment:


New changeset 66c5853406bbcccecf35372795078c0641a5f385 by Furkan Onder in 
branch 'main':
bpo-26329: update os.path.normpath documentation (GH-20138)
https://github.com/python/cpython/commit/66c5853406bbcccecf35372795078c0641a5f385


--

___
Python tracker 

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