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

[Glyph Lefkowitz]

Glyph Lefkowitz  added the comment:

Adding versions after confirming the bug is the same on 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

[issue44599] Changing logging format for one handler changes it for all

[Vinay Sajip]

Vinay Sajip  added the comment:

> It looks like an unexpected behavior to me when reading the doc.

Perhaps you missed this?

https://docs.python.org/3/library/logging.html?highlight=exc_text#logging.Formatter.format

"Note that the formatted exception information is cached in attribute exc_text. 
This is useful because the exception information can be pickled and sent across 
the wire, but you should be careful if you have more than one Formatter 
subclass which customizes the formatting of exception information. In this 
case, you will have to clear the cached value after a formatter has done its 
formatting, so that the next formatter to handle the event doesn’t use the 
cached value but recalculates it afresh."

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

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

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

1. Different handling of None:

>>> isinstance(None, int | type(None))
True
>>> issubclass(type(None), int | type(None))
True
>>> isinstance(None, int | None)
True
>>> issubclass(type(None), int | None)
False

2. Different handling of virtual subclasses:

>>> import collections.abc
>>> isinstance({}, int | collections.abc.Mapping)
True
>>> issubclass(dict, int | collections.abc.Mapping)
False

I do not know what behavior is correct.

--
components: Interpreter Core
messages: 397281
nosy: gvanrossum, serhiy.storchaka
priority: normal
severity: normal
status: open
title: Discrepancy between isinstance() and issubclass() for union types
type: behavior
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

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

[Andrei Kulakov]

Andrei Kulakov  added the comment:

(Also if they are able to help, please report back here and update this issue, 
that will be much appreciated!)

--

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

Robert: thanks for the response..

I looked a bit more into it and I'm starting to think it's a PyWin issue, not 
pyclbr.

It seems to me that PyWin is calling pyclbr readmodule_ex with 
module='__main__', and pyclbr is supposed to find it on the filesystem. The 
problem is, '__main__' is the special name for current script or interactive 
session. It doesn't give pyclbr any info on where the script might be, if it 
exists (maybe it's pywin's interactive window?).

So, unless someone more familiar with pyclbr steps in and gives us a bit more 
insight, I think the best course may be to report this to PyWin. They might 
also know more about pyclbr, perhaps they've run into similar issues with it 
before!

--

___
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

[Glyph Lefkowitz]

New submission from Glyph Lefkowitz :

Consider the following example that attempts to make a series of types sortable 
by their class name:




from functools import total_ordering

@total_ordering
class SortableMeta(type):
def __new__(cls, name, bases, ns):
return super().__new__(cls, name, bases, ns)

def __lt__(self, other):
if not isinstance(other, SortableMeta):
pass
return self.__name__ < other.__name__

def __eq__(self, other):
if not isinstance(other, SortableMeta):
pass
return self.__name__ == other.__name__

class B(metaclass=SortableMeta):
pass

class A(metaclass=SortableMeta):
pass


print(A < B)
print(A > B)


This should just print "True", "False", but instead the second comparison 
raises this exception:

Traceback (most recent call last):
  File "total_ordering_metaclass.py", line 27, in 
print(A > B)
  File "lib/python3.9/functools.py", line 91, in _gt_from_lt
op_result = self.__lt__(other)
TypeError: expected 1 argument, got 0


The problem here is that functools considers .__special__ to be equivalent to 
operator.special.  I'm pretty sure this should be invoking "self < other" 
rather than self.__lt__(other).

--
components: Library (Lib)
messages: 397278
nosy: glyph
priority: normal
severity: normal
stage: needs patch
status: open
title: functools.total_ordering doesn't work with metaclasses
type: behavior
versions: Python 3.7, 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

[issue41972] bytes.find consistently hangs in a particular scenario

[Dennis Sweeney]

Dennis Sweeney  added the comment:

In "Fast String Searching" (1991), A. Hume and D. Sunday emphasize that most of 
the runtime of string-search algorithms occurs in a code path that skips over 
immediately-disqualified alignments. As such, that paper recommends extracting 
a hot "Horspool" code path and keeping it small. For that reason, I'm posting a 
PR which boils down that fast path to the following:

while (skip > 0 && window_last < haystack_end) {
window_last += skip;
skip = table[(*window_last) & 63];
}

This uses two memory accesses, whereas the last implementation used three (the 
extra to get window[cut]). This requires the skip table to change slightly, 
since it is indexed by the last character in the current haystack window rather 
than one character later ("fast" versus "sd1" in the paper). The paper also 
recommends unrolling this loop 3x, but my benchmarks found no benefit to 
unrolling.

The PR also refactors some of the main fastsearch code into separate functions, 
and computes and then uses a similar gap/skip integer used already in the 
default implementation (Hume and Sunday call this "md2"). It retains a 
linear-time constant space worst-case with the Two-Way algorithm.

There are a bunch of benchmarks here, both on Zipf-distributed random strings 
and on a few c/rst/python/binary files in the cpython repo. They compare the 
current main branch to the PR:

https://gist.github.com/sweeneyde/fc20ed5e72dc6b0f3b41c0abaf4ec3be

Summary of those results:

On the Zipf strings:
* 83 cases slower (at most 1.59x slower)
* 654 cases faster (up to 4.49x faster)
* Geometric mean: 1.10x faster

On the "Real world" source files:
* 76 cases slower (at most 2.41x slower)
* 420 cases faster (up to 18.12x faster)
* Geometric mean: 1.33x faster

--

___
Python tracker 

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

[issue41972] bytes.find consistently hangs in a particular scenario

[Dennis Sweeney]

Change by Dennis Sweeney :


--
pull_requests: +25639
pull_request: https://github.com/python/cpython/pull/27091

___
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, this behaviour lives here:

https://github.com/python/cpython/blob/e14d5ae5447ae28fc4828a9cee8e9007f9c30700/Lib/_sitebuiltins.py#L13-L26

--

___
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, Stargirl for opening this issue and for the thorough description and 
proposals. I am sympathetic with the idea and the general proposal and 
(unsurprisingly) I agree with (1).

For (2) there are some challenges here to consider. The most important one is 
that the mechanism to show those messages is really the repr() of the exit() 
built-in the one showing the message:

>>> x = exit
>>> repr(x)
'Use exit() or Ctrl-D (i.e. EOF) to exit'

There is no other mechanism in the interpreter that triggers anything when the 
user inputs that. The most straightforward way is to raise SystemExit from the 
repr() of the built-in but that has some obvious problems. As printing anything 
where the exit function lives will also raise SystemExit (for instance printing 
the builtins module or objects in the GC). 

For these reasons I propose to go with (1) with the slight modification of 
"exit" to "exit()".

--
nosy: +pablogsal

___
Python tracker 

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

[issue44604] [Enhancement] Asyncio task decorator to provide functionality similar to dask's delayed interface

[Aritn Sarraf]

New submission from Aritn Sarraf :

For those not familiar, the dask delayed interface allows a user to define a 
DAG through a functional invocation interface. Dask docs here: 
https://docs.dask.org/en/latest/delayed.html
Another example of this kind of interface is airflow's new TaskFlow api: 
https://airflow.apache.org/docs/apache-airflow/stable/concepts/taskflow.html

The proposed solution would look something like this. Essentially all we're 
doing is defining a decorator that will allow you to pass in coroutines to 
another coroutine, and will resolve the dependent coroutines before passing the 
results to your dependent coroutine.

# Note0: can be removed, see Note2 below
async def task_wrapper(val):
return val

def task(afunc):  # open to other names for the decorator since it might be 
a bit ambiguous
async def inner(*args):  # Note1: real solution would be expanded to 
args/kwargs
# Note2: `task_wrapper` kind of unneccesary, we can just 
conditionally not gather in those cases
args = [arg if inspect.isawaitable(arg) else task_wrapper(arg) for 
arg in args]
args = await asyncio.gather(*args)
return await afunc(*args)
return inner


The advantage this gives us in asyncio is that we can easily build processing 
pipelines where each piece is completely independent and does not know anything 
about any other piece of the pipeline. Obviously this is already possible 
currently, but this simple wrapper will provide a very clean way to connect it 
all together.

Take the following example, where we want to fetch data for various ids and 
post process/upload them.

@task
async def fetch(x):
# Note3: timings here defined to demo obvious expected async behavior 
in completion order of print statements
sleep_time = {'a1': 1, 'a2': 2, 'b1': 4, 'b2': 0.5, 'c1': 6, 'c2': 
3.5}[x]
await asyncio.sleep(sleep_time)
ret_val = f'f({x})'
print(f'Done {ret_val}')
return ret_val

async def process(x1, x2):
await asyncio.sleep(1)
ret_val = f'p({x1}, {x2})'
print(f'Done {ret_val}')
return ret_val

Notice we didn't decorate `process`, this is to allow us to demonstrate how you 
can still use the interface on functions that you can't or don't want to 
decorate. Now to define/execute our pipeline we can simply do this. :


async def main():
fa1 = fetch('a1')
fa2 = fetch('a2')
fb1 = fetch('b1')
fb2 = fetch('b2')
fc1 = fetch('c1')
fc2 = fetch('c2')
pa = task(process)(fa1, fa2)
pb = task(process)(fb1, fb2)
pc = task(process)(fc1, fc2)
return await asyncio.gather(pa, pb, pc)
 
loop = asyncio.new_event_loop()
loop.run_until_complete(main())

This will be a very simple non-breaking inclusion to the library, that will 
allow users to build clean/straightforward asynchronous processing 
pipelines/DAGs.

--
components: asyncio
messages: 397274
nosy: asarraf, asvetlov, yselivanov
priority: normal
severity: normal
status: open
title: [Enhancement] Asyncio task decorator to provide functionality similar to 
dask's delayed interface
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

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

[Stargirl Flowers]

New submission from Stargirl Flowers :

Presently, when using REPL if a user types simply "exit", they are greeted with 
a message instructing them to do it "correctly":

>>> exit
Use exit() or Ctrl-Z plus Return to exit

It comes across as a little surprising that (1) the program knows what I meant 
and (2) the program told me it wouldn't do it unless I request it in a very 
specific way. This isn't very user-friendly behavior.

Further surprising is the inconsistent behavior of the other built-ins 
described on interpreter start-up. "copyright" and "credits" work fine without 
being invoked as a function, whereas "help" and "license" rebuff the user. 

I know there are compelling technical reasons for the current behavior, 
however, this behavior is a bit off-putting for newcomers. Knowing the 
technical reasons behind this behavior made me *more* frustrated than less 
frustrated.

Python is a lovely language and I think we should do what we can to be 
friendlier to users. I propose a few changes to fix this specific issue:

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

(2) Make the interactive interpreter exit when the user types simply "exit" or 
"quit.

To address some possible edge cases an objections:

- if (2) proves too controversial, we should at least do (1) with the slight 
modification of "exit" to "exit()".
- if there is a concern about accidentally exiting the interpreter, there are 
several strategies we can use. First, we can only activate this behavior if, 
and only if, Python is being used as an interactive interpreter. From what I 
can tell, main() is already distinguishing this case. Second, if absolutely 
necessary we could ask the user to confirm that they want to exit. For example:

>>> exit
Are you sure you want to exit Python? (yes/no): 

For what it's worth, I am willing to do this work, however, I might need a 
little guidance to find the right bits.

--
components: Demos and Tools
messages: 397273
nosy: theacodes
priority: normal
severity: normal
status: open
title: REPL: exit when the user types exit instead of asking them to explicitly 
type exit()

___
Python tracker 

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

[issue44599] Changing logging format for one handler changes it for all

[Karthikeyan Singaravelan]

Change by Karthikeyan Singaravelan :


--
nosy: +vinay.sajip

___
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

[Andrei Kulakov]

Andrei Kulakov  added the comment:

Christof: I've left one comment on the PR.

Generally your reasoning (on why unexpected deep cmp is not ideal), makes sense 
to me.

However, this is a backwards incompatible change that will probably affect a 
large number of a lot of scripts that quietly run in the background and might 
silently break (i.e. just by affecting different sets of files, with no 
reported errors or warnings) with this change.

Can you find other instances where people complained about this behavior e.g. 
here on BPO or SO?

What do you think about making this change while preserving backwards 
compatibility e.g. via a new arg?

--
nosy: +andrei.avk

___
Python tracker 

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

[issue44594] AsyncExitStack.enter_async_context() is mishandling exception __context__

[John Belmonte]

John Belmonte  added the comment:

demonstrating the difference for async case:

import contextlib
import trio

async def background():
assert False

async def main1():
async with trio.open_nursery() as nursery:
nursery.start_soon(background)
await trio.sleep_forever()

async def main2():
async with contextlib.AsyncExitStack() as stack:
nursery = await stack.enter_async_context(trio.open_nursery())
nursery.start_soon(background)
await trio.sleep_forever()

try:
trio.run(main1)
except BaseException as e:
print('main1, context:', e.__context__)

try:
trio.run(main2)
except BaseException as e:
print('main2, context:', e.__context__)



main1, context: None
main2, context: Cancelled

--

___
Python tracker 

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

[issue44564] DeprecationWarning in test_enum over formatting

[Brandon Schabell]

Change by Brandon Schabell :


--
keywords: +patch
nosy: +brandonschabell
nosy_count: 2.0 -> 3.0
pull_requests: +25638
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27090

___
Python tracker 

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

[issue44594] AsyncExitStack.enter_async_context() is mishandling exception __context__

[John Belmonte]

Change by John Belmonte :


--
keywords: +patch
nosy: +jbelmonte
nosy_count: 3.0 -> 4.0
pull_requests: +25637
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27089

___
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

[Rajesh]

Rajesh  added the comment:

Recently Microsoft also removed support to install Visual Studio 2015 
installation using installer, so users who need visual studio 2015 must 
download and then install.

This will cause issues to Python packages that depend on distutils which again 
depends on visual studio 2015

--

___
Python tracker 

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

[issue44159] mimetypes - "strict" on Windows

[Brandon Schabell]

Change by Brandon Schabell :


--
keywords: +patch
nosy: +brandonschabell
nosy_count: 5.0 -> 6.0
pull_requests: +25636
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27088

___
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

[Rajesh]

New submission from Rajesh :

get_build_version method in msvc9compiler.py file in distutils folder is 
returning MSVC version as "14.2" for Python 3.9.

14.2 is the build version for Visual Studio 2015, but Visual studio 2015 wont 
work on Windows 10 as per the below link 

https://visualstudio.microsoft.com/vs/support/vs2015/visual-studio-2015-system-requirements/

So, Python 3.9 wont work on Windows 10?

I am trying to install wxPython 4.0.7 using "pip install wxPython==4.0.7" but 
facing error to find the visual studio in Windows 10 using Python 3

--
messages: 397269
nosy: kalyan
priority: normal
severity: normal
status: open
title: Issue with get_build_version in msvc9compiler.py in distutils
type: behavior

___
Python tracker 

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

[issue44601] argparse: potential bugs on add_subparser due to allow_abbrev cannot deal with short options

[Xiang Zhong]

New submission from Xiang Zhong :

Additional argument like "allow_abbrev_short" should be added to avoid those 
potential bugs due to abbreviations on short options cannot be handled by 
"allow_abbrev".

To reproduce and be well explanation, please check on my attached testing file.

The following is the excerpt:

1) contents in link:
   https://docs.python.org/3/library/argparse.html#prefix-matching
   should be updated to long options (two dashes)

2) bugs may happen due to `allow_abbrev' cannot handle short options
   when recycling top-level arguments by using `add_subparsers'

--
components: Library (Lib)
files: myargparse.py
messages: 397268
nosy: zhongxiang117
priority: normal
severity: normal
status: open
title: argparse: potential bugs on add_subparser due to allow_abbrev cannot 
deal with short options
type: behavior
versions: Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50143/myargparse.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

[Tyler Crompton]

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

[Brandt Bucher]

Brandt Bucher  added the comment:

Thanks, I'll take a closer look at this soon (most likely this coming week).

Out of curiosity, do we have a standard way of writing regression tests for 
correct line numbers like this? Of the top of my head, it seems like we could 
either statically compare the dis output (fragile) or actually execute some 
code with a trace function enabled and check the line hits (tricky).

Neither really seems ideal, so I'm wondering if there's be a better way?

--
assignee:  -> brandtbucher
type:  -> behavior

___
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

[Zac Gross]

Zac Gross  added the comment:

Hey all, I'd like to note my interest in this issue getting addressed. I have a 
use case where I'd like to generate documentation for a module and using 
non-core modules to do that requires some approval that I would like to avoid. 

I understand there are other more important issues but this issue has had a 
patch waiting for review for ten years. Can we move this forward somehow?

--
nosy: +brickman1444

___
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

[Mark Shannon]

Change by Mark Shannon :


--
nosy: +brandtbucher

___
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

[Ned Batchelder]

New submission from Ned Batchelder :

Some simple match/case statements show incorrect tracing.  Below is the code to 
run, as well as the output.  Output lines with initial stars are incorrect: 
they incorrectly indicate that case bodies are executing when they are not. 
Sorry for the bulk here, I wanted to give you all the cases I had.

-- 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 match_with_default():
for command in ["huh", "go home", "go n"]:
print(command)
match command.split():
case ["go", direction] if direction in "nesw":
match = f"go: {direction}"
case ["go", _]:
match = "no go"
case _:
match = "default"
print(match)

def match_with_wildcard():
for command in ["huh", "go home", "go n"]:
print(command)
match command.split():
case ["go", direction] if direction in "nesw":
match = f"go: {direction}"
case ["go", _]:
match = "no go"
case x:
match = f"default: {x}"
print(match)

def match_without_wildcard():
match = None
for command in ["huh", "go home", "go n"]:
print(command)
match command.split():
case ["go", direction] if direction in "nesw":
match = f"go: {direction}"
case ["go", _]:
match = "no go"
print(match)

print(sys.version)
sys.settrace(trace)
match_with_default()
match_with_wildcard()
match_without_wildcard()
-- 8< -
Output:

  3.10.0b4 (default, Jul 11 2021, 13:51:53) [Clang 12.0.0 (clang-1200.0.32.29)]
  call 10: def match_with_default():
  line 11: for command in ["huh", "go home", "go n"]:
  line 12: print(command)
  huh
  line 13: match command.split():
  line 14: case ["go", direction] if direction in "nesw":
  line 15: match = f"go: {direction}"
  line 16: case ["go", _]:
* line 17: match = "no go"
  line 19: match = "default"
  line 20: print(match)
  default
  line 11: for command in ["huh", "go home", "go n"]:
  line 12: print(command)
  go home
  line 13: match command.split():
  line 14: case ["go", direction] if direction in "nesw":
  line 16: case ["go", _]:
  line 17: match = "no go"
  line 20: print(match)
  no go
  line 11: for command in ["huh", "go home", "go n"]:
  line 12: print(command)
  go n
  line 13: match command.split():
  line 14: case ["go", direction] if direction in "nesw":
  line 15: match = f"go: {direction}"
  line 20: print(match)
  go: n
  line 11: for command in ["huh", "go home", "go n"]:
  retu 11: for command in ["huh", "go home", "go n"]:
  call 22: def match_with_wildcard():
  line 23: for command in ["huh", "go home", "go n"]:
  line 24: print(command)
  huh
  line 25: match command.split():
  line 26: case ["go", direction] if direction in "nesw":
* line 27: match = f"go: {direction}"
  line 28: case ["go", _]:
* line 29: match = "no go"
  line 30: case x:
  line 31: match = f"default: {x}"
  line 32: print(match)
  default: ['huh']
  line 23: for command in ["huh", "go home", "go n"]:
  line 24: print(command)
  go home
  line 25: match command.split():
  line 26: case ["go", direction] if direction in "nesw":
  line 28: case ["go", _]:
  line 29: match = "no go"
  line 32: print(match)
  no go
  line 23: for command in ["huh", "go home", "go n"]:
  line 24: print(command)
  go n
  line 25: match command.split():
  line 26: case ["go", direction] if direction in "nesw":
  line 27: match = f"go: {direction}"
  line 32: print(match)
  go: n
  line 23: for command in ["huh", "go home", "go n"]:
  retu 23: for command in ["huh", "go home", "go n"]:
  call 34: def match_without_wildcard():
  line 35: match = None
  line 36: for command in ["huh", "go home", "go n"]:
  line 37: print(command)
  huh
  line 38: match command.split():
  line 39: case ["go", direction] if direction in "nesw":
* line 40: match = f"go: {direction}"
  line 41: case ["go", _]:
* line 42: match = "no go"
  line 43: print(match)
  None
  line 36: 

[issue8595] Explain the default timeout in http-client-related libraries

[Andrei Kulakov]

Andrei Kulakov  added the comment:

I've put up the doc update PR:
https://github.com/python/cpython/pull/27087

I did not add a module level default timeouts to these modules because it seems 
to me most of the issue is users being unaware of the current global default, 
which is fixed by docs update; then it's easy to set the timeout when calling 
respective functions.

--

___
Python tracker 

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

[issue8595] Explain the default timeout in http-client-related libraries

[Andrei Kulakov]

Change by Andrei Kulakov :


--
keywords: +patch
nosy: +andrei.avk
nosy_count: 6.0 -> 7.0
pull_requests: +25635
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/27087

___
Python tracker 

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

[issue29753] [Linux] ctypes packs bitfields Incorrectly

[Filipe Laíns]

Filipe Laíns  added the comment:

Sorry for not posting a link here, see 
https://github.com/python/cpython/pull/19850#issuecomment-869410686.

The issue is not legacy behavior, it's that the fix messed up the functionality 
and that was not caught by tests. I don't have much time to look into why that 
happened right now, but I will when I get a chance. Sorry!

--

___
Python tracker 

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

[issue29753] [Linux] ctypes packs bitfields Incorrectly

[Sam Price]

Sam Price  added the comment:

I’ve been looking forward to this fix.  The old implementation did  not
match what my LLVM compiler generated.

On Sun, Jul 11, 2021 at 2:52 PM Charles Machalow 
wrote:

>
> Charles Machalow  added the comment:
>
> Maybe we need to add a __packing__ option to specify how packing should
> work and default to legacy behavior. Then allow users to specify if they
> want similar behavior cross-os.
>
> Otherwise changing this does change packing for existing users and can lead
> to breakages.
>
> What exactly was the hit regression here?
>
> On Sun, Jul 11, 2021, 10:47 AM miss-islington 
> wrote:
>
> >
> > miss-islington  added the
> > comment:
> >
> >
> > New changeset 42da46ed522157b057d73e6b623615ef6427999e by Miss Islington
> > (bot) in branch '3.10':
> > bpo-29753: revert 0d7ad9f (GH-19850) (GH-27085)
> >
> >
> https://github.com/python/cpython/commit/42da46ed522157b057d73e6b623615ef6427999e
> >
> >
> > --
> >
> > ___
> > Python tracker 
> > 
> > ___
> >
>
> --
>
> ___
> Python tracker 
> 
> ___
>
-- 
Thank you,

Sam Price
(707) 742-3726

--

___
Python tracker 

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

[issue29753] [Linux] ctypes packs bitfields Incorrectly

[Charles Machalow]

Charles Machalow  added the comment:

Maybe we need to add a __packing__ option to specify how packing should
work and default to legacy behavior. Then allow users to specify if they
want similar behavior cross-os.

Otherwise changing this does change packing for existing users and can lead
to breakages.

What exactly was the hit regression here?

On Sun, Jul 11, 2021, 10:47 AM miss-islington 
wrote:

>
> miss-islington  added the
> comment:
>
>
> New changeset 42da46ed522157b057d73e6b623615ef6427999e by Miss Islington
> (bot) in branch '3.10':
> bpo-29753: revert 0d7ad9f (GH-19850) (GH-27085)
>
> https://github.com/python/cpython/commit/42da46ed522157b057d73e6b623615ef6427999e
>
>
> --
>
> ___
> Python tracker 
> 
> ___
>

--

___
Python tracker 

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

[issue29753] [Linux] ctypes packs bitfields Incorrectly

[miss-islington]

miss-islington  added the comment:


New changeset 42da46ed522157b057d73e6b623615ef6427999e by Miss Islington (bot) 
in branch '3.10':
bpo-29753: revert 0d7ad9f (GH-19850) (GH-27085)
https://github.com/python/cpython/commit/42da46ed522157b057d73e6b623615ef6427999e


--

___
Python tracker 

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

[issue44599] Changing logging format for one handler changes it for all

[Amanieu]

New submission from Amanieu :

I want to stream a logger to several streams. Changing the standard format 
works, but changing the formatException function changes it for all!

As I am not entirely sure if it is a feature and I am misunderstanding 
something, I have posted on SO on this topic: 
https://stackoverflow.com/questions/68244691/changing-logging-format-for-one-handler-changes-it-for-all

It looks like an unexpected behavior to me when reading the doc.

--
components: Library (Lib)
messages: 397258
nosy: hyamanieu
priority: normal
severity: normal
status: open
title: Changing logging format for one handler changes it for all
type: behavior
versions: Python 3.7, 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

[issue29753] [Linux] ctypes packs bitfields Incorrectly

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:


New changeset e14d5ae5447ae28fc4828a9cee8e9007f9c30700 by Filipe Laíns in 
branch 'main':
bpo-29753: revert 0d7ad9f (GH-19850) (GH-27085)
https://github.com/python/cpython/commit/e14d5ae5447ae28fc4828a9cee8e9007f9c30700


--
nosy: +pablogsal

___
Python tracker 

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

[issue29753] [Linux] ctypes packs bitfields Incorrectly

[miss-islington]

Change by miss-islington :


--
pull_requests: +25634
stage: resolved -> patch review
pull_request: https://github.com/python/cpython/pull/27086

___
Python tracker 

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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[Christian Heimes]

Christian Heimes  added the comment:

Python 3.9.5 and OpenSSL 1.1.1f are both outdated. Can you reproduce the 
problem with 3.9.6 and 1.1.1k?

Can you tel us more about your system (distribution, CPU arch, compiler) and 
provide a C stacktrace with debug symbols?

--
nosy:  -Guido.van.Rossum

___
Python tracker 

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

[issue29753] [Linux] ctypes packs bitfields Incorrectly

[Filipe Laíns]

Filipe Laíns  added the comment:

Unfortunately, the fix has some unforeseen side-effects, so we'll have to 
revert it :/

--
resolution: fixed -> 
status: closed -> open
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

[issue44598] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

New submission from tongxiaoge :

I have reproduced this problem in the latest versions of Python 3.8.11 and 
3.9.6. Python 3.8.5 does not have this problem, other versions are not tested. 
The failure log is as follows：
[  613s] 0:02:27 load avg: 4.66 Re-running failed tests in verbose mode
[  613s] 0:02:27 load avg: 4.66 Re-running test_ssl in verbose mode
[  613s] test_ssl: testing with 'OpenSSL 1.1.1f  31 Mar 2020' (1, 1, 1, 6, 15)
[  613s]   under 'Linux-5.4.6-x86_64-with-glibc2.2.5'
[  613s]   HAS_SNI = True
[  613s]   OP_ALL = 0x8054
[  613s]   OP_NO_TLSv1_1 = 0x1000
[  613s] test__create_stdlib_context (test.test_ssl.ContextTests) ... ok
[  613s] test_cert_store_stats (test.test_ssl.ContextTests) ... ok
[  613s] test_check_hostname (test.test_ssl.ContextTests) ... ok
[  613s] test_ciphers (test.test_ssl.ContextTests) ... ok
[  613s] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: 
Segmentation fault
[  613s] 
[  613s] Current thread 0x7ff433b90740 (most recent call first):
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/ssl.py", line 
483 in __new__
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/test_ssl.py", line 1126 in 
test_constructor
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 650 in 
_callTestMethod
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 693 in 
run
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/case.py", line 753 in 
__call__
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 122 in 
run
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 84 in 
__call__
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 122 in 
run
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/suite.py", line 84 in 
__call__
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/unittest/runner.py", line 176 in 
run
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/support/__init__.py", line 
2030 in _run_suite
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/support/__init__.py", line 
2152 in run_unittest
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/test_ssl.py", line 4848 in 
test_main
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", 
line 234 in _runtest_inner2
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", 
line 270 in _runtest_inner
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", 
line 153 in _runtest
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/runtest.py", 
line 193 in runtest
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 
318 in rerun_failed_tests
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 
694 in _main
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 
637 in main
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/libregrtest/main.py", line 
715 in main
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/regrtest.py", line 46 in 
_main
[  613s]   File 
"/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/test/regrtest.py", line 50 in 

[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/runpy.py", line 
87 in _run_code
[  613s]   File "/home/abuild/rpmbuild/BUILD/Python-3.8.11/Lib/runpy.py", line 
194 in _run_module_as_main
[  613s] /var/tmp/rpm-tmp.lFeeM8: line 50: 15891 Segmentation fault  
WITHIN_PYTHON_RPM_BUILD= LD_LIBRARY_PATH=$(pwd)/build/debug 
$(pwd)/build/debug/python -m test.regrtest -wW --slowest -j0 -x test_distutils 
-x test_bdist_rpm -x test_gdb -x test_socket -x test_asyncio
[  613s] error: Bad exit status from /var/tmp/rpm-tmp.lFeeM8 (%check)

What is the reason for this? and is there a plan to fix it?

--
assignee: christian.heimes
components: SSL, Tests
messages: 397254
nosy: Guido.van.Rossum, christian.heimes, sxt1001, vstinner
priority: normal
severity: normal
status: open
title: test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: 
Segmentation fault
type: crash
versions: 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

[issue43838] There is a way to access an underlying mapping in MappingProxyType

[Brandt Bucher]

Change by Brandt Bucher :


--
nosy: +brandtbucher

___
Python tracker 

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

[issue29753] [Linux] ctypes packs bitfields Incorrectly

[Filipe Laíns]

Change by Filipe Laíns :


--
pull_requests: +25633
pull_request: https://github.com/python/cpython/pull/27085

___
Python tracker 

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

[issue44568] test_constructor (test.test_ssl.ContextTests) ... Fatal Python error: Segmentation fault

[tongxiaoge]

Change by tongxiaoge :


--
resolution:  -> out of date
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