Re: python for irc client

[Daniel via Python-list]

inhahe  writes:

> On Thu, Jul 4, 2024 at 5:14 AM Daniel via Python-list <
> python-list@python.org> wrote:
>
>> Hi guys -
>>
>> I have historical experience developing sofwtare for my own use. It has
>> been
>> quite a while since doing so and the advent of new languages has brought me
>> here. Python has built quite a reputation. It would be fun to pick up a
>> new language while I'm at it.
>>
>> I've been a consumer of IRC since the nineties and have been running an
>> instance of quassel core on an old laptop for the last decade. Over the
>> years, my use of xwindows has dramatically decreased and I spend 90% of my
>> computer time with multiple panes of tmux while I do my usual daily fun.
>> One
>> thing missing is a good textmode irc client that will connect to quassel
>> core.
>>
>> I've seen efforts to make a plugin for weechat but, to date, I don't see
>> much
>> progress on that end.
>>
>> In your wisdom, would python be a good environment to accomplish this? I'd
>> likely use extended ascii and colors. The point would be to minimize the
>> memory footprint of the application.
>>
>> I don't use standard desktop computers anymore - I'm writing this on my
>> beloved pi400 using emacs.
>>
>> Thanks
>>
>> Daniel
>> --
>> https://mail.python.org/mailman/listinfo/python-list
>
>
> I think Python would be a great language to write an IRC client in, it's a
> rapid-development language, and also Python is particularly good for text
> manipulation and the IRC protocol is textual rather than binary. But, if
> your only purpose for using Python is to reduce the memory footprint, I'm
> not sure. I don't know specifically, but I'd guess Python has a higher
> memory footprint than, say, C, because it's a high-level language. For
> example, each variable has to be boxed, and also the interpreter has to be
> loaded..
>
> Regarding high ASCII, I don't know if that works in IRC, but either way,
> ASCII isn't really enough nowadays. You need to support Unicode;
> specifically, UTF-8.

Okay great. Since my original post, I settled on UTF8. I have to create
a list of requirements for v1.0 to limit scope creep and I can actually
get this done.

I may put it on github and solicit for assistance at some point.

Thanks for the response, both of them. I'll look at the other code and
see how I can fold it in. What I have to find out, still, is how the
core server manages the messages. I suspect the core does all the
sending and receiving and the client just sends the packets to core for
management. That's just a guess though.

I still have to review the liraries, this is a new idea hatched last
night so I have yet to investigate much.

My initial thought was C++ but this would be my first termianl-only
application in many years so I thought a different coding platform would
be effective.

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

python for irc client

[Daniel via Python-list]

Hi guys -

I have historical experience developing sofwtare for my own use. It has been
quite a while since doing so and the advent of new languages has brought me
here. Python has built quite a reputation. It would be fun to pick up a
new language while I'm at it.

I've been a consumer of IRC since the nineties and have been running an
instance of quassel core on an old laptop for the last decade. Over the
years, my use of xwindows has dramatically decreased and I spend 90% of my
computer time with multiple panes of tmux while I do my usual daily fun. One
thing missing is a good textmode irc client that will connect to quassel
core.

I've seen efforts to make a plugin for weechat but, to date, I don't see much
progress on that end.

In your wisdom, would python be a good environment to accomplish this? I'd
likely use extended ascii and colors. The point would be to minimize the
memory footprint of the application.

I don't use standard desktop computers anymore - I'm writing this on my
beloved pi400 using emacs.

Thanks

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

complaint

[Daniel Ifechukwude Dibie]

i tried to uninstall the python 3.11.3 program from my machine so that i
can re-install it is showing successful but it is ligerning on the program
and features
-- 
https://mail.python.org/mailman/listinfo/python-list

回复: UTF-8 and latin1

[Daniel Lee]

Thanks!

发件人: Stefan Ram
发送时间: 2022年8月19日 6:23
收件人: python-list@python.org
主题: Re: UTF-8 and latin1

Tobiah  writes:
>  When a person enters
>Montréal, Quebéc into a form field, what are they
>doing on the keyboard to make that happen?

  Depends on the OS and its configuration. Some devices might
  not even have a keyboard as hardware.

>As the
>string sits there in the text box, is it latin1, or utf-8
>or something else?

  This is an internal implementation detail of the browser.

>How does the browser know what
>sort of data it has in that text box?

  This is an internal implementation details of the browser.

  You usually do not need to know these internal information
  about the browser in order to use it.


--
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-listdata=05%7C01%7C%7C242e3a7de5ba4183621b08da81684702%7C84df9e7fe9f640afb435%7C1%7C0%7C637964582138805523%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=HSG21e6Aj5pyf7m8e290Rv7tsMMfCGZptEU32iMbo1I%3Dreserved=0

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

回复: Problem using cx_Freeze

[Daniel Lee]

Thank you!
发件人: subin
发送时间: 2022年8月19日 8:02
收件人: python-list@python.org
主题: Re: Problem using cx_Freeze

Hope you had a good time.

On Wed, Aug 17, 2022 at 10:19 PM Peter J. Holzer  wrote:

> On 2022-08-17 12:09:14 -0600, David at Booomer wrote:
> > Executable(
> >
>  "prjui.py","Maiui.py","about.py","dict.py","geometry.py","getEquation.py",
> >
>  "gtrail.py","main.py","matchingstring.py","producelatex.py","readfile.py",
> > "separete.py","speak.py",
> > )
> [...]
> > I am/was worried about the trailing ‘,' after ',"speak.py”,’ <- but
> > deleting it or moving it after the ] didn’t help.
>
> This has nothing to do with your problem but:
>
> Python allows a trailing comma in any comma-separated list of values. It
> will just be ignored.
>
> This is really common in modern programming languages (read: programming
> languages younger than 30 years or so), because it makes it much more
> convenient to extend/shorten/reorder a list. Otherwise you alway have to
> remember add or remove a comma in the right place. (Some people
> (especially SQL programmers for some reason) resorted to put the comma
> at the start of each line to get around this, which is really ugly.)
>
> hp
>
> --
>_  | Peter J. Holzer| Story must make more sense than reality.
> |_|_) ||
> | |   | h...@hjp.at |-- Charles Stross, "Creative writing
> __/   | 
> https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.hjp.at%2Fdata=05%7C01%7C%7Cf1c5395d5c384d4337a308da81760b87%7C84df9e7fe9f640afb435%7C1%7C0%7C637964641252805670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=%2F8KY%2FjYyHLyPx3VNEXGW0yBOwwoNSOgjbqt6Z46AKHQ%3Dreserved=0
>  |   challenge!"
> --
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-listdata=05%7C01%7C%7Cf1c5395d5c384d4337a308da81760b87%7C84df9e7fe9f640afb435%7C1%7C0%7C637964641252805670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=SQPv4cUay6nBpvjcx7m9FGSfhZXBrwyQ72IdwWCpyCE%3Dreserved=0
>
--
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-listdata=05%7C01%7C%7Cf1c5395d5c384d4337a308da81760b87%7C84df9e7fe9f640afb435%7C1%7C0%7C637964641252805670%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=SQPv4cUay6nBpvjcx7m9FGSfhZXBrwyQ72IdwWCpyCE%3Dreserved=0

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

回复: setup.py + cython == chicken and the egg problem

[Daniel Lee]

Thank you!

从 Windows 版邮件发送

发件人: Dan Stromberg
发送时间: 2022年8月19日 8:35
收件人: Python List
主题: Re: setup.py + cython == chicken and the egg problem

On Tue, Aug 16, 2022 at 2:03 PM Dan Stromberg  wrote:

> Hi folks.
>
> I'm attempting to package up a python package that uses Cython.
>
> Rather than build binaries for everything under the sun, I've been
> focusing on including the .pyx file and running cython on it at install
> time.  This requires a C compiler, but I'm OK with that.
>
> BTW, the pure python version works fine, and the cython version works too
> as long as you preinstall cython - but I don't want users to have to know
> that :)
>

For the actual chicken-and-egg problem, I'd needed to include my
pyproject.toml in my MANIFEST.in, like:
include pyx_treap.pyx pyx_treap.c pyproject.toml
--
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-listdata=05%7C01%7C%7C128ce386df164c9d8a3708da817ab65c%7C84df9e7fe9f640afb435%7C1%7C0%7C637964661300313663%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=FMteu3dpspfzD4WvRWjnEbeNSr9P0aXrrv467ueM86k%3Dreserved=0

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

回复: Problem using cx_Freeze > auto-py-to-exe

[Daniel Lee]

Thank you so much, I really appreciate it.

发件人: Chris Angelico
发送时间: 2022年8月19日 8:39
收件人: python-list@python.org
主题: Re: Problem using cx_Freeze > auto-py-to-exe

On Fri, 19 Aug 2022 at 10:07, Grant Edwards  wrote:
>
> On 2022-08-18, Chris Angelico  wrote:
> > On Fri, 19 Aug 2022 at 05:05, Grant Edwards  
> > wrote:
> >> On 2022-08-18, Chris Angelico  wrote:
> >>
> >> > It's one of the frustrations with JSON, since that format doesn't
> >> > allow the trailing comma :)
> >>
> >> Yep, that's a constant, low-level pain for all the C code I deal with
> >> which generates JSON. You'd think after 10+ years of maintaining code
> >> that outputs JSON, I wouldn't trip over that any longer...
> >
> > With some JSON files, I just cheat and define a shim at the end of arrays...
> >
> > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2FRosuav%2FMustardMine%2Fmaster%2Ftemplate.jsondata=05%7C01%7C%7Cc74e60f1d42f4904e66c08da817b37fa%7C84df9e7fe9f640afb435%7C1%7C0%7C637964663486534639%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=W5LULRCXXGHodvem7CdscC9KZDrU7ONXbCAlIuBZ8Xg%3Dreserved=0
>
> That's OK if it's strictly internal. Almost all of the JSON data I
> work with is part of published APIs ― many of which are defined by
> industry consortiums or corporate-wide "standards".
>

That's an export/import format that I defined, so I mandated (a) that
there's an empty-string key as a signature (on import, it can be
anywhere, but on export, it's that final shim), and (b) all arrays are
allowed to have an empty string at the end, which is ignored on
import. Saves so much trouble.

That particular export format is actually designed as a git-managed
config file as well, which is why the line breaks are done the way
they are (anything on a single line is intended to be added/removed as
a single unit), which is why I definitely don't want the "add a comma
to the previous line" deltas.

"Strictly internal" is a subset of "protocols/standards that you are
in control of". :)

ChrisA
--
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.python.org%2Fmailman%2Flistinfo%2Fpython-listdata=05%7C01%7C%7Cc74e60f1d42f4904e66c08da817b37fa%7C84df9e7fe9f640afb435%7C1%7C0%7C637964663486554552%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7Csdata=5nlih9a9slRg%2FWdtsS4IbskQKIKUTfj%2BqefVsWa0C4Q%3Dreserved=0

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

Tkinter not working

[Daniel Lee]

Hello, I my code with tkinter was working before, and now, it has many errors 
in it. I’m not sure what has happened. The results after running are below:

"D:\Python Projects\tes\venv\Scripts\python.exe" "D:/Python 
Projects/tes/main.py"
Traceback (most recent call last):
  File "D:\Python Projects\tes\main.py", line 1, in 
import tkinter as tk
  File 
"C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\__init__.py",
 line 3, in 
import tkinter.messagebox
  File 
"C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\messagebox.py",
 line 25, in 
from tkinter.commondialog import Dialog
  File 
"C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\commondialog.py",
 line 13, in 
from tkinter import Frame, _get_temp_root, _destroy_temp_root
ImportError: cannot import name 'Frame' from partially initialized module 
'tkinter' (most likely due to a circular import) 
(C:\Users\Daniel.LAPTOP-6U1MQ9CR\AppData\Local\Programs\Python\Python310\lib\tkinter\__init__.py)

Process finished with exit code 1
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue47237] Inheritance from Protocol with property in dataclass makes them non-instantiatable

[Daniel Draper]

New submission from Daniel Draper :

Hi,

According to 
https://peps.python.org/pep-0544/#explicitly-declaring-implementation it should 
be possible to explicitly inherit from Protocols. This however breaks the 
dataclass constructor when using the @property decorator in the protocol, see 
this example:

```python
from typing import Protocol
from dataclasses import dataclass

class SomeProtocol(Protocol):
@property
def some_value(self) -> str: ...

@dataclass
class SomeDataclasss(SomeProtocol):
some_value: str

if __name__ == '__main__':
a = SomeDataclasss(some_value="value") # this crashes with AttributeError: 
can't set attribute 'some_value'
```

The pattern of @property in the protocol is one taken from the mypy docs (see 
https://mypy.readthedocs.io/en/stable/protocols.html#recursive-protocols for 
example). 

When removing the explicit inheritiance mypy also correctly typechecks the 
dataclass implementation when doing something like, only the explicit 
inheritance seems to fail in python

```python
a: SomeProtocol = SomeDataclass()
```

--
components: Library (Lib)
messages: 416846
nosy: Germandrummer92
priority: normal
severity: normal
status: open
title: Inheritance from Protocol with property in dataclass makes them 
non-instantiatable
type: behavior
versions: Python 3.10

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

[issue40172] ZipInfo corrupts file names in some old zip archives

[Daniel Hillier]

Daniel Hillier  added the comment:

Related to issue https://bugs.python.org/issue28080 which has a patch that 
covers a bit of this issue

--

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

[issue46958] json dump/dumps prints each array element on a new line (bad for readability)

[Daniel]

Change by Daniel :


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

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

[issue46958] json dump/dumps prints each array element on a new line (bad for readability)

[Daniel]

Change by Daniel :


--
components: Library (Lib)
nosy: Entirity
priority: normal
severity: normal
status: open
title: json dump/dumps prints each array element on a new line (bad for 
readability)
type: enhancement
versions: Python 3.11

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

[issue46440] ArgumentParser.parse_args exits on missing required argument with exit_on_error=False

[Daniel Schulte]

New submission from Daniel Schulte :

When calling ArgumentParser.parse_args(list_of_things_to_parse) sys.exit gets 
called even though the parser was constructed with exit_on_error=False. It 
doesn't matter if the parser has any subparsers added or not.

The docs say
> Normally, when you pass an invalid argument list to the parse_args() 
> method of an ArgumentParser, it will exit with error info.

> If the user would like to catch errors manually, the feature can be 
> enabled by setting exit_on_error to False:
> [example code follows]

The docs make me believe what I'm trying to do should work.
I've attached a minimal working example to show what happens (with and without 
subparsers).

--
components: Library (Lib)
files: bug.py
messages: 410984
nosy: trilader
priority: normal
severity: normal
status: open
title: ArgumentParser.parse_args exits on missing required argument with 
exit_on_error=False
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50567/bug.py

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

[issue32912] Raise non-silent warning for invalid escape sequences

[Daniel Carpenter]

Daniel Carpenter  added the comment:

I'm not sure if this is an issue or by design, but this DeprecationWarning 
behaves differently to other DeprecationWarnings.

A normal DeprecationWarning triggered by code in __main__ is printed by default:

$ python -c 'import warnings; warnings.warn("test", DeprecationWarning)'
:1: DeprecationWarning: test

But this one is silent:

$ python -c '"\,"'
[no output]

To see this DeprecationWarning at all, I need to type:

$ python -Wdefault -c '"\,"'
:1: DeprecationWarning: invalid escape sequence '\,'

But that enables this DeprecationWarning for all modules, not just __main__ .

I've tested this with Python 3.9 on debian bullseye and the 3.10 docker image.

--
nosy: +dansebcar

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

[issue22833] The decode_header() function decodes raw part to bytes or str, depending on encoded part

[Daniel Lenski]

Change by Daniel Lenski :


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

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

[issue46236] PyFunction_GetAnnotations returning Tuple vs Dict

[Daniel McCarney]

New submission from Daniel McCarney :

Hi there,

This is my first Python bug, hope I haven't missed anything important.

I noticed that the PyFunction_GetAnnotations function from the C API is 
returning a PyTuple when I link Python 3.10 where historically it returned a 
PyDict.

The documentation for PyFunction_GetAnnotations for 3.10 (here[0]) says its 
return can be:
> a mutable dictionary or NULL

I'm not sure if:
* This is user error and I should adapt to this case in my dependent code when 
using Python 3.10+.
* This is a documentation error, and it should say "a mutable dictionary, set, 
or NULL"
* This is a regression in the C API that should be fixed.

I've made a small reproduction program (here[1]) that can be used to quickly 
demonstrate the difference in return type between the two Python versions for 
the same C program and .py inputs.

I also noticed that issue42202 (here[2]) landed an optimization in 3.10.x that 
changed the internal representation of annotations to a set - could that 
possibly be related? I'm not 100% sure!

Thanks!

[0]: https://docs.python.org/3/c-api/function.html#c.PyFunction_GetAnnotations
[1]: https://github.com/cpu/pyfunction_getannotations_test
[2]: https://bugs.python.org/issue42202

--
components: C API
messages: 409555
nosy: cpu
priority: normal
severity: normal
status: open
title: PyFunction_GetAnnotations returning Tuple vs Dict
versions: Python 3.10

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

[issue22833] The decode_header() function decodes raw part to bytes or str, depending on encoded part

[Daniel Lenski]

Daniel Lenski  added the comment:

Due to this bug, any user of this function in Python 3.0+ *already* has to be 
able to handle all of the following outputs in order to use it reliably:

   decode_header(...) -> [(str, None)]
or decode_header(...) -> [(bytes, str)]
or decode_header(...) -> [(bytes, (str|None)), (bytes, (str|None)), ...]

== Fix str/bytes inconsistency ==

We could eliminate the inconsistency, and make the function only ever return 
bytes instead of str, with the following changes to 
https://github.com/python/cpython/blob/3.10/Lib/email/header.py.

```
diff --git a/Lib/email/header.py.orig b/Lib/email/header.py
index 4ab0032..41e91f2 100644
--- a/Lib/email/header.py
+++ b/Lib/email/header.py
@@ -61,7 +61,7 @@ _max_append = email.quoprimime._max_append
 def decode_header(header):
 """Decode a message header value without converting charset.
 
-Returns a list of (string, charset) pairs containing each of the decoded
+Returns a list of (bytes, charset) pairs containing each of the decoded
 parts of the header.  Charset is None for non-encoded parts of the header,
 otherwise a lower-case string containing the name of the character set
 specified in the encoded string.
@@ -78,7 +78,7 @@ def decode_header(header):
 for string, charset in header._chunks]
 # If no encoding, just return the header with no charset.
 if not ecre.search(header):
-return [(header, None)]
+return [header.encode(), None)]
 # First step is to parse all the encoded parts into triplets of the form
 # (encoded_string, encoding, charset).  For unencoded strings, the last
 # two parts will be None.
```

With these changes, decode_header() would return one of the following:

   decode_header(...) -> [(bytes, None)]
or decode_header(...) -> [(bytes, str)]
or decode_header(...) -> [(bytes, (str|None)), (bytes, (str|None)), ...]


== Ensure that charset is always str, never None ==

A couple more small changes:

```
@@ -92,7 +92,7 @@ def decode_header(header):
 unencoded = unencoded.lstrip()
 first = False
 if unencoded:
-words.append((unencoded, None, None))
+words.append((unencoded, None, 'ascii'))
 if parts:
 charset = parts.pop(0).lower()
 encoding = parts.pop(0).lower()
@@ -133,7 +133,8 @@ def decode_header(header):
 # Now convert all words to bytes and collapse consecutive runs of
 # similarly encoded words.
 collapsed = []
-last_word = last_charset = None
+last_word = None
+last_charset = 'ascii'
 for word, charset in decoded_words:
 if isinstance(word, str):
 word = bytes(word, 'raw-unicode-escape')
```

With these changes, decode_header() would return only:

   decode_header(...) -> List[(bytes, str)]

--

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

[issue22833] The decode_header() function decodes raw part to bytes or str, depending on encoded part

[Daniel Lenski]

Daniel Lenski  added the comment:

I recently ran into this bug as well.

For those looking for a reliable workaround, here's an implementation of a 
'decode_header_to_string' function which should Just Work™ in all possible 
cases:

#!/usr/bin/python3
import email.header

# Workaround for https://bugs.python.org/issue22833
def decode_header_to_string(header):
'''Decodes an email message header (possibly RFC2047-encoded)
into a string, while working around 
https://bugs.python.org/issue22833'''

return ''.join(
alleged_string if isinstance(alleged_string, str) else 
alleged_string.decode(
alleged_charset or 'ascii')
for alleged_string, alleged_charset in 
email.header.decode_header(header))


for header in ('=?utf-8?B?ZsOzbw==',
   '=?ascii?Q?hello?==?utf-8?B?ZsOzbw==?=',
   'bar=?ascii?Q?hello?==?utf-8?B?ZsOzbw==?=',
   'plain string',):
print("Header value: %r" % header)
print("email.header.decode_header(...) -> %r" % 
email.header.decode_header(header))
print("decode_header_to_string(...)-> %r" % 
decode_header_to_string(header))
print("---")

Outputs:

Header value: '=?utf-8?B?ZsOzbw=='
email.header.decode_header(...) -> [('=?utf-8?B?ZsOzbw==', None)]
decode_header_to_string(...)-> '=?utf-8?B?ZsOzbw=='
---
Header value: '=?ascii?Q?hello?==?utf-8?B?ZsOzbw==?='
email.header.decode_header(...) -> [(b'hello', 'ascii'), (b'f\xc3\xb3o', 
'utf-8')]
decode_header_to_string(...)-> 'hellofóo'
---
Header value: 'bar=?ascii?Q?hello?==?utf-8?B?ZsOzbw==?='
email.header.decode_header(...) -> [(b'bar', None), (b'hello', 'ascii'), 
(b'f\xc3\xb3o', 'utf-8')]
decode_header_to_string(...)-> 'barhellofóo'
---
Header value: 'plain string'
email.header.decode_header(...) -> [('plain string', None)]
decode_header_to_string(...)-> 'plain string'
---
Header value: 'foo=?blah?Q??='
email.header.decode_header(...) -> [(b'foo', None), (b'', 'blah')]
decode_header_to_string(...)-> 'foo'
---

--
nosy: +dlenski

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

[issue25044] bring BTPROTO_SCO inline with other Bluetooth protocols

[Daniel Diniz]

Change by Daniel Diniz :


--
versions: +Python 3.11 -Python 3.4, Python 3.5, Python 3.6

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

[issue7687] Bluetooth support untested

[Daniel Diniz]

Change by Daniel Diniz :


--
versions: +Python 3.10, Python 3.11

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

[issue14844] netrc does not handle accentuated characters

[Daniel Diniz]

Daniel Diniz  added the comment:

Now that a PR has landed in #28806 to improve shlex, we need to check whether 
this issue can/needs to move forward.

--
nosy: +ajaksu2, asvetlov
type:  -> behavior
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.2

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

[issue1438480] shutil.move raises OSError when copystat fails

[Daniel Diniz]

Change by Daniel Diniz :


--
keywords:  -easy
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 3.3

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

[issue978604] wait_variable hangs at exit

[Daniel Diniz]

Daniel Diniz  added the comment:

Confirmed on Python 3.11.0a3+, assuming older versions also affected. This 
issue has different versions of tests to confirm it, but I think not in a test 
suite-friendly format yet.

There's also a patch and detailed analysis by gpolo indicating that it might 
need editing _tkinter.c to handle fallout from his proposed Python-side patch.

--
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.2, Python 
3.3

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

[issue46169] Same-moment datetimes with different ZoneInfo timezones are not considered ==

[Daniel Diniz]

Change by Daniel Diniz :


--
nosy: +belopolsky

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

[issue46169] Same-moment datetimes with different ZoneInfo timezones are not considered ==

[Daniel Diniz]

Daniel Diniz  added the comment:

Confirmed for 3.11 in Windows. 

The C datetime code can be trivially fixed so your equality test returns True, 
but there are two Python tests that depend on current behavior so it might not 
be so easy. They were added with current code in issue 24773, to implement PEP 
495 -- Local Time Disambiguation.

Also, using a timezone implementation from the test suite makes the equality 
work, so maybe the bug depends on zoneinfo.

If you change datetimemodule.c line 5761 from "diff = 1;" to "diff = 0;", two 
tests fail and your code works.

See attached file for the tests that fail and using the timezone implementation 
mentioned above.

--
nosy: +ajaksu2
Added file: https://bugs.python.org/file50517/dt_equality.py

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

[issue504219] locale.resetlocale is broken

[Daniel Diniz]

Change by Daniel Diniz :


--
nosy: +ajaksu2
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.3, Python 
3.4

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

[issue46168] Incorrect format specified for the "style" key in the configuration file format formatter example

[Daniel Diniz]

Daniel Diniz  added the comment:

This example was added in issue 43047. It only seems to affect 3.10+ docs. Ian, 
is this something you'd like to tackle?

--
keywords: +easy
nosy: +ajaksu2, iwienand
stage:  -> needs patch
versions: +Python 3.10, Python 3.11 -Python 3.8

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

[issue44413] Improvement mktime error reporting

[Daniel McDonald]

Daniel McDonald  added the comment:

Sounds good, thank you, Terry

--
type: enhancement -> behavior

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

[issue44413] OverflowError: mktime argument out of range after 2019

[Daniel McDonald]

Daniel McDonald  added the comment:

A definitive assessment was obtained by Aurelien with Debian:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001774

In brief, the OverflowError is expected and correct. 

Two factors contribute to the difference in observed behavior. First, the 
production of the -1 from mktime which Python uses to raise OverflowError 
depends on whether timezone is or is not set (e.g. "Etc/UTC"). This was 
confirmed on the Github Actions 20.04 ubuntu instance independent of Python 
directly with the mktime() function from C. Second, mktime returning -1 to 
indicate overflow is dependent on glibc >= 2.29, and versions prior "do not 
report any error if the date is not representable." This second factor is 
supported by testing the lack of the -1 (and subsequent OverflowError) on 
Github Actions ubuntu 18.04, which uses an older version of glibc.

The full thread with Debian is here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001774

With regards to CPython, a possible change to consider would be to test if 
tm_isdst < 0 prior to the mktime call, and if that evaluates true to provide an 
error indicating use requires a timezone being set. I think that change would 
make Python's behavior consistent with glibc >= 2.29, and smooth over a 
potential platform dependency, while also providing an informative error 
message. However, I have limited knowledge of how timezones are implemented and 
am unsure if more than "Etc/UTC" would result in tm_isdst being < 0. 

If that change makes sense, I'd be happy to submit a pull request to that 
effect. However, I recognize there may be considerations not accounted for here 
particularly as this is a central module, so I'll hold off issuing a pull 
request until hearing back from on this matter.

--

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

[issue46138] Strange behavior with lists

[Daniel Frey]

New submission from Daniel Frey :

Hi

I found a strange behavior with lists. When I want to save the list {3,1,8}, it 
saves the 8 at the first entry. Only when I add the integers 7 and 9, the 8 is 
placed correctly. (See the attached picture)

Can anyone help me understand what is going on here?

Thanks in advance!

--
files: python_strange_behavior.png
messages: 408960
nosy: daniel.frey
priority: normal
severity: normal
status: open
title: Strange behavior with lists
type: behavior
versions: Python 3.10
Added file: https://bugs.python.org/file50505/python_strange_behavior.png

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

[issue23224] bz2/lzma: Compressor/Decompressor objects are only initialized in __init__

[Daniel Diniz]

Change by Daniel Diniz :


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

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

[issue46127] Missing HTML span element in exceptions.html

[Daniel Diniz]

Daniel Diniz  added the comment:

That happens because EncodingWarning isn't highlighted as an Exception by 
Pygments[0]. The doc page gets its exceptions diagram by:
".. literalinclude:: ../../Lib/test/exception_hierarchy.txt"
and all other entries are recognized by Pygments, so we get the "ne" class for 
them.

A PR for Pygments adding EncodingWarning could be interesting, but I'm not sure 
the doc build process would pick it up and fix the 3.10 docs issue.

For 3.11, the diagram drawing was changed so no highlighting happens anymore, 
which fixes the issue for us in the long run.

[0] 
https://github.com/pygments/pygments/blob/8630e033313647d9579e314f3e8e2882f4558933/pygments/lexers/python.py#L225

--
nosy: +ajaksu2

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

[issue41033] readline.c: endless loop on SIGWINCH when loaded twice

[daniel hahler]

Change by daniel hahler :


--
versions: +Python 3.11

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

[issue41033] readline.c: endless loop on SIGWINCH when loaded twice

[daniel hahler]

daniel hahler  added the comment:

Yes, the example also does not segfault for me either (also with Python 3.8.12 
I have now as `python3.8`), so this was likely only happening in the more 
complex setup, and/or maybe with some specific version of readline back then.

--
title: readline.c: SEGFAULT on SIGWINCH when loaded twice -> readline.c: 
endless loop on SIGWINCH when loaded twice

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

[issue678264] test_resource fails when file size is limited

[Daniel Diniz]

Change by Daniel Diniz :


--
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.4, Python 
3.5

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

[issue9917] resource max value represented as signed when should be unsigned

[Daniel Diniz]

Change by Daniel Diniz :


--
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.4, Python 
3.5

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

[issue1062277] Pickle breakage with reduction of recursive structures

[Daniel Diniz]

Change by Daniel Diniz :


--
versions: +Python 3.11 -Python 3.5

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

[issue45959] Teach pprint about dict views

[Daniel Diniz]

Daniel Diniz  added the comment:

I have tried to add this. The PR adds:
- PrettyPrinter._pprint_dict_view to handle dict_keys and dict_values (sorted 
with _safe_key).
= PrettyPrinter._pprint_dict_items_view to handle dict_items (sorted using 
_safe_tuple).
- Tests.

Would a NEWS entry or other form of documentation be necessary?

--

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

[issue45959] Teach pprint about dict views

[Daniel Diniz]

Change by Daniel Diniz :


--
keywords: +patch
nosy: +ajaksu2
nosy_count: 4.0 -> 5.0
pull_requests: +28355
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/30135

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

[issue44413] OverflowError: mktime argument out of range after 2019

[Daniel McDonald]

Daniel McDonald  added the comment:

For reference, the bug reports with Debian and Ubuntu are at the following URLs:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1001774
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1954963

--

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

[issue44413] OverflowError: mktime argument out of range after 2019

[Daniel McDonald]

Daniel McDonald  added the comment:

Thank you, Christian, I apologize for missing your reply. That is great advice, 
and I will do so.

--

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

[issue44413] OverflowError: mktime argument out of range after 2019

[Daniel McDonald]

Daniel McDonald  added the comment:

The use of tm_isdst=1 appears to trigger the overflow, and occurs when varying 
other aspects of the timetuple.  

Python's mktime wrapper can throw OverflowError in two places. The thrown error 
is the second location, following the call to glibc's mktime occurring in this 
specific if block:

https://github.com/python/cpython/blob/f62420c3d3f5d87f2b57e54b2a98682bc835f7b6/Modules/timemodule.c#L1038-L1046

Modification of Modules/timemodule.c as to printf tm struct members confirms 
that when tm_isdst=1, the result from mktime() is -1, and the tm_wday member is 
set to -1, the combination of which triggers the conditional. 

mktime within the Github Action ubuntu-latest (20.04) environment is sourced 
from glibc 2.31 as confirmed by ldd and nm on the compiled Python binary.

As a proof of concept, C program was written that calls mktime independent of 
CPython (can be compiled with "gcc bug.c -o bug"). The code below succeeds on 
both OSX 11.6.1 and Centos 7.9:

#include 
#include 

void do_test() {
  struct tm tm_works = { .tm_year=117,
 .tm_mon=4,
 .tm_mday=26,
 .tm_hour=15,
 .tm_min=30,
 .tm_sec=16,
 .tm_wday=4,
 .tm_yday=145,
 .tm_isdst=-1 };
  
  struct tm tm_fails = { .tm_year=117,
 .tm_mon=4,
 .tm_mday=26,
 .tm_hour=15,
 .tm_min=30,
 .tm_sec=16,
 .tm_wday=4,
 .tm_yday=145,
 .tm_isdst=1 };

  time_t works = mktime(_works);
  time_t fails = mktime(_fails);

  if(works == -1) {
  printf("Unexpected failure\n");
  } else {
  if(works == fails) {
  printf("Test passed\n");
  } else {
  printf("Test failed: works=%d; fails=%d\n", (int)works, (int)fails);
  }
  }
}

int main(int argc, char **argv) {
do_test();
}

When compiled and run within in the Github Actions ubuntu-latest (20.04) 
environment, the erroneous behavior occurs:

https://github.com/wasade/cpython/runs/4541212472?check_suite_focus=true#step:17:57

The use of tm_isdst=1 is valid according to multiple sources, a few examples 
are linked below. The sources are consistent, and indicate a positive value 
means Daylight Savings Time is in effect. 

https://www.gnu.org/software/libc/manual/html_node/Broken_002ddown-Time.html
https://www.cplusplus.com/reference/ctime/tm/

At this time, I believe this remains unexpected behavior, however the source 
appears upstream of CPython as mktime is part of glibc. Unless suggested 
otherwise, I'll open an issue with on the glibc tracker.

--

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

[issue44413] OverflowError: mktime argument out of range after 2019

[Daniel McDonald]

Daniel McDonald  added the comment:

Thank you, Terry. I'm currently exploring modifications to the test Andrei made 
within a fork of CPython using Github Actions (ubuntu-latest). These 
modifications include debug prints in the CPython mktime call, and some 
parameter exploration. I expect to have a summary of the observations this 
afternoon.

--

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

[issue44413] OverflowError: mktime argument out of range after 2019

[Daniel McDonald]

Daniel McDonald  added the comment:

I'd like to politely request this issue be reopened. 

We recently observed a similar, if not the same, OverflowError during 
continuous integration using Github Actions on ubuntu-latest (20.04). We can 
produce the error using pure Python without pytz.

We have been unable to replicate the error using Github Actions on 
macos-latest, Centos 7.9, Ubuntu 18.04 or OSX 11.6.1.

Specifically, the following code, which I believe is pure python, will trigger 
the overflow. We've observed this using Python 3.7 and 3.9. 

import time
print(time.mktime((2017,5,26,15,30,16,4,146,1)))

Exact error output from CI can be found at the link below: 

https://github.com/biocore/microsetta-private-api/runs/4536611219?check_suite_focus=true#step:4:117

On a passing system, we receive "1495837816.0" as output. On a failing system, 
we observe "OverflowError: mktime argument out of range". 

More detail can be found on our issue with pytz and stub42 who helped guide a 
more definitive example of the bug showing it could be pure Python. That issue 
can be found here:

https://github.com/stub42/pytz/issues/66

Last, I apologize in advance if any detail is missing here or if this is not 
formatted as well as it should be. This is my first bug report with Python and 
am unfamiliar with the norms. Please let me know if further information may be 
helpful.

--
nosy: +wasade
versions: +Python 3.7, Python 3.9

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

[issue766910] fix one or two bugs in trace.py

[Daniel Diniz]

Change by Daniel Diniz :


--
nosy: +ajaksu2
versions: +Python 3.10, Python 3.11, Python 3.9 -Python 2.7, Python 3.7

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

[issue1182143] making builtin exceptions more informative

[Daniel Diniz]

Change by Daniel Diniz :


--
nosy: +iritkatriel

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

[issue4733] Add a "decode to declared encoding" version of urlopen to urllib

[Daniel Diniz]

Daniel Diniz  added the comment:

As Victor notes, this is a controversial issue. And I'll add that the need for 
this feature seems not to have been brought up up in over a decade. So I'm 
closing this.

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

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

[issue46036] Single-phase initialized modules gets initialized multiple times in 3.10.0

[Daniel]

New submission from Daniel :

The documentation 
(https://docs.python.org/3/c-api/init.html#c.Py_NewInterpreter) states:


For modules using single-phase initialization, e.g. PyModule_Create(), the 
first time a particular extension is imported, it is initialized normally, and 
a (shallow) copy of its module’s dictionary is squirreled away. When the same 
extension is imported by another (sub-)interpreter, a new module is initialized 
and filled with the contents of this copy; the extension’s init function is not 
called. Objects in the module’s dictionary thus end up shared across 
(sub-)interpreters, which might cause unwanted behavior (see Bugs and caveats 
below).


This does however seem to have changed (sometime between 3.6.9 and 3.10.0). 
Consider the following code:


#include 

/*
 * Create a module "my_spam" that uses single-phase initialization
 */
static PyModuleDef EmbModule = {
  PyModuleDef_HEAD_INIT, "my_spam", NULL, -1,
  NULL,
  NULL, NULL, NULL, NULL
};

/*
 * According to the docs this function is only called once when dealing with
 * subinterpreters, the next time a shallow copy of the initial state is
 * returned. This does however not seem to be the case in Python 3.10.0..
 */
static PyObject* PyInit_emb(void) {
  PyObject *module = PyModule_Create();
  PyModule_AddObject(module, "test", PyDict_New());

  printf("Init my_spam module %p\n", module);
  return module;
}

/*
 * Main program
 */

int main(int argc, char *argv[]) {
  PyImport_AppendInittab("my_spam", _emb);
  Py_Initialize();

  // Save the main state
  PyThreadState *mainstate = PyThreadState_Get();

  // Create two new interpreters
  PyThreadState *inter1 = Py_NewInterpreter();
  PyThreadState *inter2 = Py_NewInterpreter();

  // Import the my_spam module into the first subinterpreter
  // and change the global variable of it
  PyThreadState_Swap(inter1);
  PyRun_SimpleString("import sys; print(sys.version_info)");
  PyRun_SimpleString("import my_spam; print('my_spam.test: ', my_spam.test)");
  PyRun_SimpleString("my_spam.test[1]=1; print('my_spam.test: ', 
my_spam.test)");

  // Import the my_spam module into the second subinterpreter
  // and change the global variable of it
  PyThreadState_Swap(inter2);
  PyRun_SimpleString("import sys; print(sys.version_info)");
  PyRun_SimpleString("import my_spam; print('my_spam.test: ', my_spam.test)");
  PyRun_SimpleString("my_spam.test[2]=2; print('my_spam.test: ', 
my_spam.test)");

  // Close the subinterpreters
  Py_EndInterpreter(inter2);
  PyThreadState_Swap(inter1);
  Py_EndInterpreter(inter1);

  // Swap back to the main state and finalize python
  PyThreadState_Swap(mainstate);
  if (Py_FinalizeEx() < 0) {
  exit(120);
  }

  return 0;
}



Compiled with python 3.6.9 this does act according to the documentation:


$ gcc test_subinterpreters.c 
-I/home/daniel/.pyenv/versions/3.6.9/include/python3.6m 
-L/home/daniel/.pyenv/versions/3.6.9/lib -lpython3.6m && 
LD_LIBRARY_PATH=/home/daniel/.pyenv/versions/3.6.9/lib ./a.out
sys.version_info(major=3, minor=6, micro=9, releaselevel='final', serial=0)
Init my_spam module 0x7ff7a63d1ef8
my_spam.test:  {}
my_spam.test:  {1: 1}
sys.version_info(major=3, minor=6, micro=9, releaselevel='final', serial=0)
my_spam.test:  {1: 1}
my_spam.test:  {1: 1, 2: 2}


But compiled with 3.10.0 the module is reinitialized and thus objects in the 
module are not shared between the subinterpreters:


$ gcc test_subinterpreters.c 
-I/home/daniel/.pyenv/versions/3.10.0/include/python3.10 
-L/home/daniel/.pyenv/versions/3.10.0/lib -lpython3.10 && 
LD_LIBRARY_PATH=/home/daniel/.pyenv/versions/3.10.0/lib ./a.out
sys.version_info(major=3, minor=10, micro=0, releaselevel='final', serial=0)
Init my_spam module 0x7f338a9a9530
my_spam.test:  {}
my_spam.test:  {1: 1}
sys.version_info(major=3, minor=10, micro=0, releaselevel='final', serial=0)
Init my_spam module 0x7f338a9a96c0
my_spam.test:  {}
my_spam.test:  {2: 2}


To me the new behavior seems nicer, but at the very least the documentation 
should be updated. It also seems like if this could break integrations, albeit 
it is an unlikely "feature" to rely on.

--
components: C API
messages: 408209
nosy: daniel-falk
priority: normal
severity: normal
status: open
title: Single-phase initialized modules gets initialized multiple times in 
3.10.0
type: behavior
versions: Python 3.10

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

[issue45981] Get raw file name in bytes from ZipFile

[Daniel Hillier]

Daniel Hillier  added the comment:

Handling different character sets is not completely supported yet. There are a 
couple of open issues relating to this: https://bugs.python.org/issue40407 
(reading file names), https://bugs.python.org/issue41928 (support for reading 
and writing filenames using the unicode filename extra field) and 
https://bugs.python.org/issue40172 (issues with reading and then writing a 
filename from and back into a zip where the initial filename isn't encoded in 
cp437).

Most modern zip programs that deal with characters outside ascii or cp437 
either set the utf-8 flag or write both an ascii or cp437 compatible filename 
(to the original filename field in the zip header) and the actual filename with 
all non-ascii characters in the unicode filename extra field. I think adding 
support for the unicode field to Python would probably cover the majority files 
generated by modern zip programs.

For complete support, including older zip programs that don't support the utf-8 
flag or unicode filename extra field, we may need to provide another parameter 
in Python's ZipFile's read and write functions to be able to override the 
charset used for the filename stored directly in the zip file header.

I've added my thoughts on how to approach this in 
https://bugs.python.org/issue40172 but haven't had time to implement these 
myself.

--
nosy: +dhillier

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

[issue45973] Not possible to clear PyImport_Inittab after PyImport_AppendInittab

[Daniel]

New submission from Daniel :

Hello,

When embedding Python into a C application and not using Py_RunMain it is not 
possible to remove a module added to PyImport_Inittab even if the interpreter 
is finalized and a new is created.

One reason for not using Py_RunMain is to use python as a subprocessor to my 
primary C application by initializing an interpreter, run some python code, 
then go back to execute some C code and again execute some python code in the 
same interpreter. After a while I might want to finalize the interpreter and 
create a new one without the module added to inittab, still being in the same 
process.

See example:

#include 


/*
 * Create a python interpreter, run a command and delete the interpreter
 */
void run_in_new_interpreter(char *cmd) {
Py_Initialize();

PyRun_SimpleString(cmd);

if (Py_FinalizeEx() < 0) {
exit(120);
}
}

/*
 * Create a module "my_spam" but do not append it to inittab
 */
static PyModuleDef EmbModule = {
  PyModuleDef_HEAD_INIT, "my_spam", NULL, -1,
  NULL,
  NULL, NULL, NULL, NULL
};

static PyObject* PyInit_emb(void) {
return PyModule_Create();
}

/*
 * Main program
 */
char *LIST_MODULES_CMD="try:\n import my_spam; print('SPAM!');\nexcept:\n 
print('no mod my_spam')";

int main(int argc, char *argv[]) {
// Run with no "my_spam" module
run_in_new_interpreter(LIST_MODULES_CMD);

// Run with "my_spam" module
PyImport_AppendInittab("my_spam", _emb);
run_in_new_interpreter(LIST_MODULES_CMD);

// How to run without my_spam? The module is still in the PyImport_Inittab
// despite the Py_FinalizeEx() call. This list is not reset until
// _PyImport_Fini2() is called, but that is never exposed in anyi public 
header,
// only in Include/internal/pycore_pylifecycle.h
run_in_new_interpreter(LIST_MODULES_CMD);
return 0;
}



The output of the program is:

>>> gcc test_embed.c `pkg-config --cflags --libs python-3.6` && ./a.out
no mod my_spam
SPAM!
SPAM!

--
components: C API
messages: 407590
nosy: daniel-falk
priority: normal
severity: normal
status: open
title: Not possible to clear PyImport_Inittab after PyImport_AppendInittab
type: behavior

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

doubt About import machine

[Daniel Eduardo Almeida Correa]

Hello, I'm trying to use the machine library in python 3.10 version, but I
can't import it with the pip install machine, could you tell me a way to
solve it  or a python version compatible with the library? Thank you a lot
for your answer.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45737] assertLogs to optionally not disable existing handlers

[Daniel]

Change by Daniel <3dan...@hotmail.com>:


--
type:  -> enhancement

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

[issue45737] assertLogs to optionally not disable existing handlers

[Daniel]

Change by Daniel <3dan...@hotmail.com>:


--
components: +Library (Lib)
versions: +Python 3.11

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

[issue45737] assertLogs to optionally not disable existing handlers

[Daniel]

New submission from Daniel <3dan...@hotmail.com>:

At the moment, assertLogs removes the handlers attached to the logger.
In general this is good, because it reduces message spamming in the test logs.
However, if the code being tested is relying on a handler to do something, then 
the test fails because the handler is being removed.
This leads to the situation that the same exact test must be run twice:
- first time within the context manager, to assert that specific messages were 
logged (using `with self.assertLogs()`)
- second time, without the assertLogs to ensure the code that uses a handler 
does the right thing

The proposal is to have `self.assertLogs()` accept a key word argument such as 
`keep_handlers=False`, which can be set to True, whenever the handlers should 
be preserved.
It would probably be also useful to add a note in the documentation that makes 
users aware that the existing handlers will be removed.

--
messages: 405858
nosy: dandiez
priority: normal
severity: normal
status: open
title: assertLogs to optionally not disable existing handlers
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9

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

[issue30238] 2to3 doesn't detect or fix Exception indexing

[Daniel Lenski]

Daniel Lenski  added the comment:

Why was this closed?

As I wrote in a previous comment, this situation can be automatically 
identified and addressed via static analysis in the vastly-predominant case, 
where the Exception object is assigned via an `exception ... as exc:` clause.

--

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

[issue45249] Update doctect SyntaxErrors for location range

[daniel hahler]

Change by daniel hahler :


--
versions: +Python 3.10

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

[issue45249] Update doctect SyntaxErrors for location range

[daniel hahler]

daniel hahler  added the comment:

I've noticed a regression/change with the code change for this issue.

When not catching the exception from `compile("invalid(", "", "single")` 
it has a caret below the opening parenthesis:

```
Traceback (most recent call last):
  File "…/t-syntaxerror-chained.py", line 2, in 
compile("invalid(", "", "single")
  File "", line 1
invalid(
   ^
SyntaxError: '(' was never closed
```

When using `traceback.print_exc` however this is missing:
```
Traceback (most recent call last):
  File "…/t-syntaxerror-chained.py", line 2, in 
compile("invalid(", "", "single")
  File "", line 1
invalid(

SyntaxError: '(' was never closed
```

The file used for testing:
```
try:
compile("invalid(", "", "single")
except Exception:
# raise
__import__("traceback").print_exc()
```

(this change was noticed between 3.10.0rc2 and the final release with pdbpp's 
test suite)

I've not investigated further (yet), and also feel free to ask for creating a 
new issue, but I've figured it would be good to notify you here first (where 
the code was changed).

--
nosy: +blueyed

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

[issue45347] datetime subject to rounding?

[Daniel Fortunov]

Change by Daniel Fortunov :


--
nosy: +dfortunov

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

[issue39359] zipfile: add missing "pwd: expected bytes, got str" exception message

[Daniel Hillier]

Daniel Hillier  added the comment:

I agree it is bad form but I would accidentally do it when I couldn't remember 
the proper API and took a stab in the dark without looking up the docs. I 
unfortunately used it in an example in the docs for pyzipper and started 
getting a few bug reports even after fixing my docs.

--

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

[issue39359] zipfile: add missing "pwd: expected bytes, got str" exception message

[Daniel Hillier]

Daniel Hillier  added the comment:

Thanks Łukasz!

--

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

[issue45164] int.to_bytes()

[daniel capelle]

daniel capelle  added the comment:

An ASCII representation is shown instead of the hexadecimal value, if there is 
any. 
I was not aware this is an intended behaviour.

--

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

[issue45164] int.to_bytes()

[daniel capelle]

daniel capelle  added the comment:

for example check:
(6500).to_bytes(2, 'big')
result is:
b'\x19d'
but was expected to be:
b'\x19\x64'
since 
ord('d') is 100 = 0x64 there seems to be hex and char representation mixed up.

--

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

[issue45164] int.to_bytes()

[daniel capelle]

New submission from daniel capelle :

for example check:
(6500).to_bytes(2, 'big')
result is:
b'\x19d'
but was expected to be:
b'\x1964'
since 
ord('d') is 100 = 0x64 there seems to be hex and char representation mixed up.

--
messages: 401571
nosy: hypnoticum
priority: normal
severity: normal
status: open
title: int.to_bytes()
type: behavior
versions: Python 3.9

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

[issue36550] Avoid creating AttributeError exceptions in the debugger

[daniel hahler]

daniel hahler  added the comment:

Given code like the following the try/except handling of Pdb (via `Cmd.onecmd`, 
see https://github.com/python/cpython/pull/4666) will mess with 
`sys.exc_info()`, which could be avoided:

```
try:
raise ValueError()
except Exception as exc:
e = exc
__import__('pdb').set_trace()
```

```
% ./python t_issue36550.py
--Return--
> …/t_issue36550.py(5)()->None
-> __import__('pdb').set_trace()
(Pdb) import sys; sys.exc_info()
(, AttributeError("'Pdb' object has no attribute 
'do_import'"), )
```

The initial / better motivation was described in the original issue: with 
pdb++/pdbpp I want to display tracebacks/errors with errors that might occur 
via Pdb's prompt, where this then showed up as interfering with it.

(Sorry for not responding on https://github.com/python/cpython/pull/4666 
earlier, but I think it is only part of this issue, and therefore it should not 
get closed, and also creating a new one instead does not sound useful to me, so 
please consider to re-open it instead.)

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

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

[issue44963] anext_awaitable is not a collections.abc.Generator

[Daniel Pope]

New submission from Daniel Pope :

The anext_awaitable object returned by anext(..., default) does not support 
.send()/.throw(). It only supports __next__().

So we can pass messages from the suspending coroutine to the event loop but not 
from the event loop to the suspending coroutine.

trio and curio rely on both directions working. (I don't know about asyncio.)

For example, this trio code fails:

import trio

async def produce():
   for v in range(3):
   await trio.sleep(1)
   yield v

async def consume():
   p = produce()
   while True:
print(await anext(p, 'finished'))

trio.run(consume)

raising AttributeError: 'anext_awaitable' object has no attribute 'send'.

I realise that any awaitable that wants to await another awaitable must return 
not an iterator from __await__() but something that implements the full PEP-342 
generator protocol. Should PEP-492 section on __await__()[1] say something 
about that?

[1] https://www.python.org/dev/peps/pep-0492/#await-expression

--
components: Library (Lib)
messages: 399982
nosy: lordmauve
priority: normal
severity: normal
status: open
title: anext_awaitable is not a collections.abc.Generator
type: behavior
versions: Python 3.10, Python 3.11

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

[issue44555] Dictionary operations are LINEAR for any dictionary (for a particular code).

[Daniel Fleischman]

Daniel Fleischman  added the comment:

Hey Raymond,

> "Changing the dict implementation to a linked list would make your case
perform better but would make most users worse off."

Is there any standard benchmark? I would like to implement my idea, as I
think that it is very unlikely that "most users would be made worse off" by
a measurable amount if I implement what I have in mind. If there aren't
standard benchmarks, I can always make artificial ones (insert a lot of
entries, remove them, access, iterate, etc).

Thank you,
Daniel

--

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

[issue44555] Dictionary operations are LINEAR for any dictionary (for a particular code).

[Daniel Fleischman]

Daniel Fleischman  added the comment:

Thank you for your reply. I didn't know that this was the expected behavior 
(found it at https://wiki.python.org/moin/TimeComplexity):

"For these operations, the worst case n is the maximum size the container ever 
achieved, rather than just the current size. For example, if N objects are 
added to a dictionary, then N-1 are deleted, the dictionary will still be sized 
for N objects (at least) until another insertion is made."

Thank you for pointing out! 

I still disagree with this design since it's not how a person using a hash map 
expects it to behave. That said, this link clearly shows that it's *not* a bug, 
and that we just have different opinions on what is the best trade-off between 
space, code complexity, and speed, especially on something as ubiquitous as a 
dictionary.

Just one final attempt to gain support for my idea before I close the issue. 
When I proposed a linked list I didn't mean an "intro to programming" linked 
list, with pointers and a new malloc for every node. I meant simply adding two 
fields to PyDictKeyEntry with the indices of the next and previous valid 
entries. There would be a tiny memory overhead, and we would get a data 
structure that behaves how one would reasonably expect it to (compare with hash 
table found in the standard libraries of other languages. It's usually 
unexpected for an operation in a data structure to take time proportional to 
its historical value).

I will close this issue in two days if there are no further replies. Thank you 
for the discussion!

--

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

[issue44555] Dictionary operations are LINEAR for any dictionary (for a particular code).

[Daniel Fleischman]

Daniel Fleischman  added the comment:

Thank you again, Dennis.

I would disagree with your conclusion for mainly 3 reasons:

1. The linked list proposal would increase the memory usage by 2 Py_ssize_t per 
entry, plus another 2 for the whole dictionary. I don't think this is an 
overwhelming amount of extra memory for Python, but of course it's open for 
discussion. Insertions and removals would become marginally slower (I'll try to 
measure it), membership wouldn't suffer, and iteration would become O(1) per 
element iterated on. 

2. I think that this case is covered by "Dynamic Mappings" in the document 
you've linked to.

3. This is not about the ordering in ducts being first or second nature. Please 
read the example in bad_dict_example.py to see a bad case where hearing over a 
dict of size 1 can take milliseconds.

I want to reiterate (pun not intended) that this is not a use case for me, but 
it surprised me that dictionaries display this behavior. It's not hard to 
imagine a real use case where it just happens that someone deletes elements 
from a dictionary in insertion order. Or that someone deletes all keys but the 
last inserted (in any order), resulting in a dictionary that takes way too long 
to iterate on. 


Thank you for the discussion. :)

--

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

[issue44555] Dictionary operations are LINEAR for any dictionary (for a particular code).

[Daniel Fleischman]

Daniel Fleischman  added the comment:

I think the idea of augmenting the struts to maintain a linked list of elements 
together with periodically shrinking on removal would solve both time and space 
issues, right? 

Space will be always linear, and operations would still be constant amortized 
time (of course the worst case of removing will be linear because of the 
shrinking, but I guess this behavior is expected).

I wrote a worse example in bad_dict_example.py submitted to this issue.  This 
example would be fixed simply by the shrinking, but as is it's a pretty 
unexpected bug, as a simple sum(d.values()) can take milliseconds on a 
dictionary with only one entry (both key and value are int).

--

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

[issue44555] Dictionary operations are LINEAR for any dictionary (for a particular code).

[Daniel Fleischman]

Daniel Fleischman  added the comment:

Please find attached a more complete example of the issue I am reporting.

tl;dr: I can make `sum(d.values())` run in O(maximum_size_in_d's_history) 
instead of O(len(d)), even when len(d) == 1.

The linked list approach would work in terms of making it faster, but we would 
still be using too much space.

--
Added file: https://bugs.python.org/file50138/bad_dict_example.py

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

[issue44555] Dictionary operations are LINEAR for any dictionary (for a particular code).

[Daniel Fleischman]

Daniel Fleischman  added the comment:

Thank you for your message!

I'm not particularly looking for an implementation, I was just surprised by
this behavior.

It can get even worse. Consider this example:

```
d = large_dict()
# remove all but one element of d, runs in quadratic time as explained above
while len(d) > 1:
del d[next(iter(d))]

# now iterating over d takes O(d), even when d has only one item:

# the following prints one key, but takes O(N)
for key in d:
print(key)
```

I think this example is better, since a person would expect iterating over
a singleton dictionary would be really fast, but it can be made as slow as
one wants. A "print_keys()" function would reasonably be expected to take
O(size of dictionary), but it doesn't.

Am I right to think that this is a performance bug?

On Fri, Jul 2, 2021, 8:10 PM Dennis Sweeney  wrote:

>
> Dennis Sweeney  added the comment:
>
> For what it's worth, using collections.OrderedDict gives constant-time
> behavior you're looking for.
>
> --
> nosy: +Dennis Sweeney
>
> ___
> Python tracker 
> <https://bugs.python.org/issue44555>
> ___
>

--

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

[issue44555] Dictionary operations are LINEAR for any dictionary (for a particular code).

[Daniel Fleischman]

Daniel Fleischman  added the comment:

The linked list solution is not as easy to implement as I expected, because of 
insertions. :(

--

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

[issue44555] Dictionary operations are LINEAR for any dictionary (for a particular code).

[Daniel Fleischman]

New submission from Daniel Fleischman :

The following code takes quadratic time on the size of the dictionary passed, 
regardless of the dictionary (explanation below):

```
def slow_dictionary(d):
while len(d) > 0:
# Remove first element
key = next(iter(d))
del d[key]
```

The problem is that when an element is deleted a NULL/NULL placeholder is set 
in its place 
(https://github.com/python/cpython/blob/818628c2da99ba0376313971816d472c65c9a9fc/Objects/dictobject.c#L1534)
 and when we try to find the first element with `next(iter(d))` the code needs 
to skip over all the NULL elements until it finds the first non-NULL element 
(https://github.com/python/cpython/blob/818628c2da99ba0376313971816d472c65c9a9fc/Objects/dictobject.c#L1713).

I'm not sure of what is the best way to fix it, but note that simply adding a 
field to the struct with the position of the first non-NULL element is not 
enough, since a code that always deletes the SECOND element of the dictionary 
would still have linear operations.

An easy (but memory-wasteful) fix would be to augment the struct PyDictKeyEntry 
with the indices of the next/previous non empty elements, and augment 
_dictkeysobject with the index of the first and last non empty elements (in 
other words, maintain an underlying linked list of the non empty entries). With 
this we can always iterate in O(1) per entry.

(I tested it only on version 3.9.2, but I would be surprised if it doesn't 
happen in other versions as well).

--
components: Interpreter Core
messages: 396880
nosy: danielfleischman
priority: normal
severity: normal
status: open
title: Dictionary operations are LINEAR for any dictionary (for a particular 
code).
type: performance
versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

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

[issue30238] 2to3 doesn't detect or fix Exception indexing

[Daniel Lenski]

Daniel Lenski  added the comment:

> There is no way to know through static analysis that the subscript is on an 
> object of type exception. I think this should be closed as won't fix.

In almost all cases, the variable in question will receive its value via 
`except ... as e:`.

   try:
   ...
   except (Exception1, Exception2, ...) as e:
   e[0]

Seems to me that it should be possible for 2to3 to handle this large subset of 
applicable cases via static analysis.

--
status: pending -> open

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

[issue44410] Exception in AsyncMock side_effect cases incorrect refcount

[Daniel Andersson]

New submission from Daniel Andersson :

Dear maintainers,

I discovered an unexpected behavior when the `side_effect` of an `AsyncMock` 
includes an exception. The test case below fails but I expected it to pass:

```
import sys
import unittest
from unittest.mock import AsyncMock


class A:
async def foobar(self):
while True:
try:
return await self.mock()
except Exception:
continue


class TestA(unittest.IsolatedAsyncioTestCase):
async def test_refcount(self):
a = A()
a.mock = AsyncMock(side_effect=[Exception(), None])
refc = sys.getrefcount(a)
await a.foobar()
self.assertEqual(refc, sys.getrefcount(a))


if __name__ == "__main__":
unittest.main()
```

If `side_effect=[Exception(), None]` is changed to `side_effect=[None, None]` 
the test case pass.

I discovered this in a bigger codebase while debugging why a weakref.finalize 
did not trigger as expected.

--
components: asyncio
messages: 395752
nosy: asvetlov, penlect, yselivanov
priority: normal
severity: normal
status: open
title: Exception in AsyncMock side_effect cases incorrect refcount
type: behavior
versions: Python 3.9

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

[issue44238] Unable to install Python 3.9.5 - Windows Server

[Ricardo Daniel Fuentes]

Ricardo Daniel Fuentes  added the comment:

Hi Steve,

I am attaching the latest log files I see on temp.

This is the first version of python I have installed on this server, we do
install and uninstall SW on this machine all the time. As we run the
operations and need to update sw there often.

Thanks,

Regards,
Ricardo

On Tue, Jun 1, 2021 at 10:19 PM Steve Dower  wrote:

>
> Steve Dower  added the comment:
>
> Unfortunately, I've got no idea whether it's failing to uninstall the MSI
> or if it's specific to removing the PATH environment variable. If you've
> still got the rest (no more than 2-3 I'd expect) of the uninstall log files
> in your %TEMP% directory that may show something.
>
> Have you successfully installed/uninstalled other versions of Python
> before on this machine/OS?
>
> --
>
> ___
> Python tracker 
> <https://bugs.python.org/issue44238>
> ___
>

--
Added file: https://bugs.python.org/file50082/archive (1).zip

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

[issue40172] ZipInfo corrupts file names in some old zip archives

[Daniel Hillier]

Daniel Hillier  added the comment:

Looking into this more and it appears that while Appendix D of 
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT says "If general 
purpose bit 11 is unset, the file name and comment SHOULD conform to the 
original ZIP character encoding" where the original encoding is IBM 437 
(cp437), this is not always followed. This isn't too surprising as cp437 
doesn't have every character for every language! In particular, some archive 
programs on windows will use the user's locale code page.

https://superuser.com/questions/1321371/proper-encoding-for-file-names-in-zip-archives-created-in-windows-and-unpacked-i

A UTF filename can be stored in the extra field 0x7075 in addition to a 
filename encoded in an arbitrary code page stored in the header's filename 
section. There is a open issue to add handling these fields (for reading) to 
zipfile: https://bugs.python.org/issue41928 and that issue may be related to 
this one https://bugs.python.org/issue40407

For this issue, with regards to encoding, I prefer the current situation where 
general purpose bit 11 for UTF is preferentially used because it doesn't change 
the behaviour compared to previous Python versions and it reduces file size as 
the filename isn't repeated in the extra field.

For compatibility with other archive programs that don't support the general 
purpose bit 11, I suggest we add an additional mechanism to allow the code page 
for the path name (and comment) to be set and use the 0x7075 extra field to 
store the UTF name in those cases where the filename can't be encoded in ascii 
(and 0x6075 to store the utf comment where it can't be encoded in ascii)

--

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

[issue44238] Unable to install Python 3.9.5 - Windows Server

[Ricardo Daniel Fuentes]

Change by Ricardo Daniel Fuentes :


--
type:  -> behavior

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

[issue44238] Unable to install Python 3.9.5 - Windows Server

[Ricardo Daniel Fuentes]

New submission from Ricardo Daniel Fuentes :

Hi,

I am Admin of a Windows Server 2012 R2, I have installed successfully Python 
3.9.5 (64-bit) however I cannot uninstall it, I get the error: "0x80070659 - 
The installation is forbidden by system policy. Contact your system 
administrator"

I don't have any software system policies defined on this server so this could 
be a Python bug.

attached the log.

Regards,
Ricardo

--
components: Installation
files: Python 3.9.5 (64-bit)_20210526084254.txt
messages: 394421
nosy: RFuentes
priority: normal
severity: normal
status: open
title: Unable to install Python 3.9.5 - Windows Server
versions: Python 3.9
Added file: https://bugs.python.org/file50064/Python 3.9.5 
(64-bit)_20210526084254.txt

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

[issue40172] ZipInfo corrupts file names in some old zip archives

[Daniel Hillier]

Daniel Hillier  added the comment:

zipfile decodes filenames using cp437 or unicode and encodes using ascii or 
unicode. It seems like zipfile has a preference for writing filenames in 
unicode rather than cp437. Is zipfile's preference for writing filenames in 
unicode rather than cp437 intentional?

Is the bug you're seeing related to using zipfile to open and rewrite old zips 
and not being able to open the rewritten files in an old program that doesn't 
support the unicode flag?

We could address this two ways:
- Change ZipInfo._encodeFilenameFlags() to always encode to cp437 if possible
- Add a flag to write filenames in cp437 or unicode, otherwise the current 
situation of ascii or unicode

I guess the choice will depend on if preferring unicode rather than cp437 is 
intentional and if writing filenames in cp437 will break anything (it shouldn't 
break anything according to Appendix D of 
https://pkware.cachefly.net/webdocs/casestudies/APPNOTE.TXT)

Here's a test for your current patch (I'd probably put it alongside 
OtherTests.test_read_after_write_unicode_filenames as this test was adapted 
from that one)

class OtherTests(unittest.TestCase):
...

def test_read_after_write_cp437_filenames(self):
fname = 'test_cp437_é'
with zipfile.ZipFile(TESTFN2, 'w') as zipfp:
zipfp.writestr(fname, b'sample')

with zipfile.ZipFile(TESTFN2) as zipfp:
zinfo = zipfp.infolist()[0]
# Ensure general purpose bit 11 (Language encoding flag
# (EFS)) is unset to indicate the filename is not unicode
self.assertFalse(zinfo.flag_bits & 0x800)
self.assertEqual(zipfp.read(fname), b'sample')

--
nosy: +dhillier

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

[issue14965] super() and property inheritance behavior

[Daniel Urban]

Daniel Urban  added the comment:

@habnabit I believe I've already signed some contributor form some years ago. 
If there is a new one, I can sign that one too.

--

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

[issue44129] zipfile: Add descriptive global variables for general purpose bit flags

[Daniel Hillier]

Change by Daniel Hillier :


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

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

[issue44129] zipfile: Add descriptive global variables for general purpose bit flags

[Daniel Hillier]

New submission from Daniel Hillier :

In the zipfile module, masking of bit flags is done against hex numbers eg. if 
flags & 0x800...

To increase readability I suggest we replace these with global variables named 
for the purpose of the flag. From the example above:

if flags & 0x800
becomes:
if flags & _MASK_UTF_FILENAME

--
components: Library (Lib)
messages: 393622
nosy: dhillier, serhiy.storchaka
priority: normal
severity: normal
status: open
title: zipfile: Add descriptive global variables for general purpose bit flags
versions: Python 3.10, Python 3.11

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

[issue44128] zipfile: Deduplicate ZipExtFile code for init and resetting when seeking

[Daniel Hillier]

Change by Daniel Hillier :


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

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

[issue44128] zipfile: Deduplicate ZipExtFile code for init and resetting when seeking

[Daniel Hillier]

New submission from Daniel Hillier :

Integrating a refactor suggested in https://bugs.python.org/issue38334

The logic for preparing a ZipExtFile for reading (setting CRC state, read 
positions, etc) is currently in two locations: first initialisation and when 
seeking back to the start of a file.

This change moves the logic into the method `ZipExtFile.init_read()`

--
components: Library (Lib)
messages: 393619
nosy: dhillier, serhiy.storchaka
priority: normal
severity: normal
status: open
title: zipfile: Deduplicate ZipExtFile code for init and resetting when seeking
type: enhancement
versions: Python 3.10, Python 3.11

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Daniel Watkins]

Daniel Watkins  added the comment:

(Accidentally dropped Ned from nosy list; apologies!)

--
nosy: +ned.deily

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

[issue43882] [security] urllib.parse should sanitize urls containing ASCII newline and tabs.

[Daniel Watkins]

Daniel Watkins  added the comment:

Hey folks,

Thanks for all the work on this: I really appreciate the efforts to keep Python 
as secure as possible!

This change _is_ causing us problems in the cloud-init codebase, which 
thankfully have been caught by our testing in Ubuntu's development release.  
This is in a fairly deep part of the codebase, so apologies in advance for the 
detailed description.

TL;DR: cloud-init constructs mirror URLs and then sanitises them by replacing 
invalid characters with hyphens.  With the fix for this bug, urlsplit silently 
removes (some of) those characters before we can replace them, modifying the 
output of our sanitisation code, and therefore meaning cloud-init will, albeit 
in fairly specific corner cases, configure different mirrors if run with a 
Python including this fix vs. one that precedes it.

cloud-init constructs mirror URLs based on applying cloud metadata to 
user-configured (or default) templates.  As we're responsible for constructing 
these URLs, we also sanitise them before configuring the package manager to use 
them: specifically, we urlsplit to get the hostname, IDNA-encode (to handle 
non-ASCII input), replace any invalid URL characters with a "-", and then strip 
"-" off each part of the hostname (to handle leading/trailing invalid 
characters), then recombine the URL.  The most common case for this is a cloud 
which specifies values for the variables used in the template with an 
underscore: http://my_openstack_region.cloud.archive.ubuntu.com/ubuntu causes 
Apache mirrors with the default "HTTPProtocolOptions Strict" configuration to 
reject all requests to them (as that's an invalid hostname).  In contrast, 
http://my-openstack-region.cloud.archive.ubuntu.com/ubuntu *is* accepted, so is 
preferable.  (This is important because *.cloud.archive.ubuntu.com exists so 
that l
 ocal cloud admins can DNS "hijack" subdomains of it to point at internal 
servers: even though the Ubuntu mirrors don't reject underscored domains (any 
longer), this is a landmine waiting for any admins running their own mirrors.)  
For more background, see the bug where we figured this all out: 
https://bugs.launchpad.net/cloud-init/+bug/1868232

So, more concretely: if we consider a post-templated URL of 
http://my\topenstack\tregion.mirror.internal/ubuntu, cloud-init changes from 
rewriting that to my-openstack-region.mirror.internal (on < 3.9.5) to 
myopenstackregion.mirror.internal (on 3.9.5+): if, in this notional deployment, 
an apt mirror is running at (exactly) my-openstack-region.mirror.internal, then 
new instance deployments will start failing: they won't be able to install 
packages.  This is the sort of breakage that we aim to avoid in cloud-init 
(because you just _know_ that everyone who deployed this cloud left 
NotionalCorp years ago, so fixing the configuration to remove these 
obviously-incorrect tabs is not necessarily trivial).

Given the current state of the fix here, it's not clear to me how we could 
(cleanly) achieve our desired behaviour.  We could perform replacement of these 
characters before invoking `urlsplit` but that would then substitute these 
characters outside of only the hostname: this is also a change in behaviour.  
We could substitute those characters with magic strings, perform the split, and 
then replace them in the non-hostname parts with the original character and in 
the hostname with hyphens: we've obviously left "cleanly" behind at this point. 
 Another option would be to monkeypatch _UNSAFE_URL_BYTES_TO_REMOVE to an empty 
list: again, not a solution I'd want to have to support across Python versions!

One solution that presents itself to me: add a `strip_insecure_characters: bool 
= True` parameter.  We, in cloud-init, would pass this in as `False`, knowing 
that we're going to handle those ourselves.  Of course, this does leave the 
door open for API users to keep the current insecure behaviour: if library code 
(either public or project-internal) were to default to `False`, then the 
situation is no better than today.

For our use case, at least, I think a more restricted solution would work: 
`url_replacement_char: str = ""`.  We'd call `urlsplit(..., 
url_replacement_char="-")` and the rest of our code would work as it does 
today: from its POV, there were never these invalid chars in the first place.


Thanks once again for the work (and apologies for the wall of text)!


Dan

--
nosy: +odd_bloke -ned.deily

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

[issue43798] Add position metadata to alias AST type

[daniel hahler]

Change by daniel hahler :


--
versions:  -Python 3.9

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

[issue43798] Add position metadata to alias AST type

[daniel hahler]

daniel hahler  added the comment:

@Pablo: the problem (referenced in the pytest issue) is that `ast.alias` has 
new required arguments now (see also the adjusted test in
https://github.com/python/cpython/commit/75a06f067bd0a2687312e5f8e78f9075be76ad3a#diff-3f516b60719dd445d33225e4f316b36e85c9c51a843a0147349d11a005c55937R1060-R1061).
  That's expected/wanted though (assuming that it should not have "defaults" 
for B/C), and there's a patch for the issue at 
https://github.com/pytest-dev/pytest/pull/8540.

--
nosy: +blueyed

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

Re: Ann: New Python curses book

[Daniel Nelson]

On Tue, Mar 30, 2021 at 12:12:19PM +0100, Alan Gauld via Python-list wrote:
> I've just published, in Kindle and paperback formats,
> my book on "Programming curses with Python".
> 
> https://www.amazon.co.uk/dp/B091B85B77/
> 
> (It should be available in most other Amazon stores too)

This looks handy, I'd love to buy a copy but I don't do business with
Amazon if I can avoid it.  Any chance this will be available from other
locations?


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

[issue43677] Descriptor.rst - Reference to Py_MethodType is not up to date

[Daniel Torres]

Change by Daniel Torres :


--
title: Descriptor Documentation - Reference to Py_MethodType is not up to date 
-> Descriptor.rst - Reference to Py_MethodType is not up to date

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

[issue43677] Descriptor Documentation - Reference to Py_MethodType is not up to date

[Daniel Torres]

Change by Daniel Torres :


--
title: Documentation -> Descriptor Documentation - Reference to Py_MethodType 
is not up to date

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

[issue43677] Documentation

[Daniel Torres]

New submission from Daniel Torres :

https://github.com/python/cpython/blob/master/Doc/howto/descriptor.rst

Section 'Functions and methods' 

The provided example contains comment 'Emulate Py_MethodType in 
Objects/classobject.c'

But Py_MethodType is nowhere to be found under 'Objects/classobject.c'

--
assignee: docs@python
components: Documentation
messages: 389878
nosy: danielcft, docs@python
priority: normal
severity: normal
status: open
title: Documentation
type: enhancement
versions: Python 3.10

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

[issue42128] Structural Pattern Matching (PEP 634)

[Daniel Moisset]

Change by Daniel Moisset :


--
pull_requests: +23450
pull_request: https://github.com/python/cpython/pull/24664

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

[issue43335] _ctypes/callbacks.c cannot be compiled by gcc 4.4.7 (RHEL6)

[DANIEL VILLENEUVE]

DANIEL VILLENEUVE  added the comment:

I'll let you do so if it's ok for you, since I'm not equipped with Python dev 
tools.

Regards

--

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

[issue42128] Structural Pattern Matching (PEP 634)

[Daniel Moisset]

Daniel Moisset  added the comment:

Thanks @xtreak, I'll make some changes in these sections too. 

The docs are coming along well, there's still some refinement to do in the 
compound statements section (it's there, but looks to big), I'll submit a draft 
PR during the weekend so interested people can review

--

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

[issue43335] _ctypes/callbacks.c cannot be compiled by gcc 4.4.7 (RHEL6)

[DANIEL VILLENEUVE]

New submission from DANIEL VILLENEUVE :

gcc 4.4.7 does not accept #pragma's inside functions.
I made the following patch, inspired by code found in other Python source files.

diff -r U/Python-3.9.2/Modules/_ctypes/callbacks.c 
V/Python-3.9.2/Modules/_ctypes/callbacks.c
433c433
< #if defined(__GNUC__)
---
> #if defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 4) && 
> (__GNUC_MINOR__ > 5)))
442c442
< #if defined(__GNUC__)
---
> #if defined(__GNUC__) && ((__GNUC__ > 4) || ((__GNUC__ == 4) && 
> (__GNUC_MINOR__ > 5)))

Regards

--
components: ctypes
messages: 387755
nosy: dvilleneuve
priority: normal
severity: normal
status: open
title: _ctypes/callbacks.c cannot be compiled by gcc 4.4.7 (RHEL6)
type: compile error
versions: Python 3.9

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

[issue42128] Structural Pattern Matching (PEP 634)

[Daniel Moisset]

Daniel Moisset  added the comment:

Note: I will NOT write something for "What's New in 3.10" seeing that's in 
progress

--

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

[issue42128] Structural Pattern Matching (PEP 634)

[Daniel Moisset]

Daniel Moisset  added the comment:

Fyi, I'm looking into the documentation. I think I can have something basic for 
the middle of this week, so it should be ok for March 1st.

--

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

[issue43253] asyncio open_connection fails when a socket is explicitly closed

[Daniel Engel]

Daniel Engel  added the comment:

It reproduced on a windows machine

--

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