Mailman 3 - Python-ideas

Protocols Subclassing Normal Classes
by Jordan Macdonald April 24, 2023

April 24, 2023

We have a large codebase which uses threads. Many - but not all - of these threads implement a method named 'stop()' which sets a flag, triggers an event, closes a connection, or what-have-you in order to command the thread in question to terminate. I was writing a thread manager, intended to automatically terminate threads in an organized way at shutdown. It could accept any thread which implemented a 'stop()' method, so how could I type-hint it correctly? 'Aha!' said I, 'This is what those … [View More]newfangled Protocol things are for! I shall use one of them!' (We only recently updated from 3.7 to 3.11, so quite a lot of features are still 'newfangled' to me.) However, I then encountered an issue: I could define a Protocol that specified the 'stop()' method easily enough, but if I annotated the manager as taking that, it would accept *any* class which implemented a method named 'stop()', which was not correct; the manager should only accept *threads* which implement such a method. I couldn't add 'threading.Thread' as a parent of the protocol; protocols aren't allowed to inherit from normal classes. And there's no syntax for marking an argument as needing to be *both* a given type and a given protocol. My proposal is this: Currently, a Protocol is forbidden from inheriting from a normal class, on the basis that it would break transitivity of subtyping. Instead, allow Protocols to inherit normal classes, with the rule that a class is only considered to implement that protocol if it also inherits the same normal classes. E.g.: ```python import typing as _tp class Base: ... class MyProtocol(Base, _tp.Protocol): def proto_method(self, string: str) -> bool: raise NotImplementedError() class Foo: def proto_method(self, string: str) -> bool: ... class Bar(Base): def proto_method(self, string: str) -> str: ... class Baz(Base): def proto_method(self, string: str) -> bool: ... class Zap(MyProtocol): def proto_method(self, string: str) -> bool: ... def my_func(proto: MyProtocol): ... my_func(Foo()) # Invalid; `Foo` does not inherit `Base` and therefore does not implement `MyProtocol` despite having the necessary method my_func(Bar()) # Invalid; `Bar` does not implement the method with the correct signature for `MyProtocol` my_func(Baz()) # Valid; `baz` inherits `Base` explicitly my_func(Zap()) # Valid; `Zap` inherits `Base` indirectly, via inheriting `MyProtocol` explicitly ``` -- So many books, so little time... - Anon. You haven't *lived* 'Till you've heard the floor ring To the whoop and the call Of 'Balance and swing!' [View Less]

4 3

new PEP: implementation independent native code invocation and data exchange ABI standard (not sure if accurate)
by Evan Greenup April 24, 2023

April 24, 2023

Dear All Python is a "glue" language, its dynamic nature has programming advantage and performance disadvantage. The best way to use Python is write Python code for high-level stuff and use native programming language like C, Rust, Zig, V for low level stuff. Currently, there is library like PyO3 and so on. However there is a lot of limitation in those library. - The "FFI" library is implementation specific. For example, PyO3, it highly depend on specific version of CPython. If you use a … [View More]different version of CPython, there is some work for you to do. If you don't use CPython, for example use another Python Implementation, This framework may not work. - The project structure is rigid. When using something like PyO3. you must make your project structure following certain pattern, then finally produce a complete wheel package. The majority Python programmer does not write a whole Python project for a installable package and pack it up then install it. They are edit Python source file iteratively and run it locally. - It is really ridiculous when you want to stick some item on the wall. You need to totally redesign this item and manufacture a new item to fit the glue you are going to use. As a glue language, Python should be designed to glue other native programming language as a feature of Python programming language itself not the tricks of certain variant of implementation. It would be nice to add the feature in Python Standards (no matter what implementation is used) to satisfy the following capabilities: - The interface is universal across all variant and version of Python implementation (There might be protocol version update and may not backward-compatible, but it is not bounded with Python implementation). The overall effect is in some extent like JSON, but it is not a structured string, It is a lively data structure with in-memory representation, they are unified no matter what Python variant is used and what low level native language is used. - This mechanism is transparent to users, there is modules in standard library to support it. If user want, they can design a toy native programming language, and use Python to write a compiler for it. Then write a module with custom language then compile and import it. This mechanism provide user with maximum flexibility. - almost zero-cost abstraction. Even if it not depend on CPython tricks. But the central idea of this mechanism is still the dynamic linking feature provided by operating system. The detailed format will be slightly different. It doesn't introduce new stuff in nature. It doesn't spawn new process, nor launch a VM, and nor I/O operations is involved. It just make some basic data representation conversion and invoke the method in dynamic library. This is just a raw idea. If it is valuable, it can take a discussion and make further steps. Thanks [View Less]

5 4

XDG Directory Support for PDB
by Gustaf Waldemarson April 21, 2023

April 21, 2023

Hello, I don't really use the Python debugger all that much, but recently I used it quite a bit for a small side-project. That said, it kept annoying me that there were no history associated with the prompt, so I added a few lines to the `pdbrc` config file to store that for me. However, it seems like this file must either exist in the user home directory, or the current working directory, neither of which were very convenient for me. Additionally, I strongly dislike polluting my home … [View More]directory with dotfiles, thus I did a bit of researching to see if this could be fixed. Thus, below is a small patch to PDB that adds support for **also** reading from configuration files in some XDG directories (currently ${XDG_CONFIG_HOME}/python/pdbrc). So I guess the question is, would anyone else find this useful enough to the point were I should write a PEP for it? As far as I can tell, Python haven't been using the XDG directories, so I suppose the naming of the subdirectory is really subject to a larger discussion. From d4ea8fbba3ba6c7538ccecad2a32e6b3b2059e5d Mon Sep 17 00:00:00 2001 From: Gustaf Waldemarson <gustaf.waldemarson(a)gmail.com> Date: Thu, 13 Apr 2023 11:39:00 +0200 Subject: [PATCH] Allow users to store PDB configuration in XDG directories. --- Lib/pdb.py | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/Lib/pdb.py b/Lib/pdb.py index a3553b345a..3f4ffd7719 100755 --- a/Lib/pdb.py +++ b/Lib/pdb.py @@ -231,19 +231,19 @@ def __init__(self, completekey='tab', stdin=None, stdout=None, skip=None, self.allow_kbdint = False self.nosigint = nosigint - # Read ~/.pdbrc and ./.pdbrc + # Read user configuration from a set of paths. self.rcLines = [] if readrc: - try: - with open(os.path.expanduser('~/.pdbrc'), encoding='utf-8') as rcFile: - self.rcLines.extend(rcFile) - except OSError: - pass - try: - with open(".pdbrc", encoding='utf-8') as rcFile: - self.rcLines.extend(rcFile) - except OSError: - pass + for rcFileName in ('${XDG_CONFIG_HOME}/python/pdbrc', + '~/.config/python/pdbrc', + '~/.pdbrc', + '.pdbrc'): + rcPath = os.path.expanduser(os.path.expandvars(rcFileName)) + try: + with open(rcPath, encoding='utf-8') as rcFile: + self.rcLines.extend(rcFile) + except OSError: + pass self.commands = {} # associates a command list to breakpoint numbers self.commands_doprompt = {} # for each bp num, tells if the prompt -- 2.25.1 [View Less]

3 7

Re: XDG Directory Support for PDB
by Barry April 20, 2023

April 20, 2023

1 0

Python should add "__name__" and "__doc__" attributes to "functools.partial"
by Matteo Raso April 15, 2023

April 15, 2023

Functions come with these attributes, but the "partial" class doesn't, even though it's meant to mimic functions. This is counter-intuitive and can sometimes cause problems, like in NumPy issue #23461 (https://github.com/numpy/numpy/issues/23461). Adding these attributes should make it much easier to use "partial" in the future. Thanks for your consideration.

1 0

Can we give built-in `help` function a `__qualname__` attribute
by Samuel Muldoon April 11, 2023

April 11, 2023

Hi, A lot of python's built-in functions have an attribute named __qualname__. However, the built-in `help` function has no __qualname__ attribute. In a future version of python can we have: help.__qualname__ = "help"

4 3

Make decorator-based context managers reentrant
by Tobias Bengfort March 30, 2023

March 30, 2023

Hi, I was wondering why decorator-based context managers are not reentrant or even reusable. They could be made reusable by initializing the generator in __enter__() instead of __init__(). They could be made reentrant by storing generatos in a stack. A similar thing has been implemented for redirect_stdout in 8e113b418df7d0c8480e1e2de29a385e1f31b15b. I understand that not all generator-based context managers can be reentrant by their nature. But currently it is impossible to make them … [View More]

2 2

An interface for `mro` methods similar to the interface for `iter`, `getattr`, etc...
by Samuel Muldoon March 24, 2023

March 24, 2023

*Greetings Fellow Earthlings,* *In python 3.11, python has a number of built-in functions which act as an Interface for magic dunder methods. Two examples of what I am talking about are shown below: * *Begin Example 1 of 2* *rocky = object()x = getattr(rocky, "length") x = rocky.__getattr__("length") * *Begin Example 2 of 2* *box = [1, 2, 3]it = iter(box) it = box.__iter__()* *My suggestion is that in future versions of python, we will have `mro()` behave in a similar fashion. * … [View More]

3 2

C#-style "as" casting syntactic sugar for type hints
by Will Bradley March 24, 2023

March 24, 2023

This is some real code I wrote the other day: payload = { "birthDate": str(date.strftime('%m/%d/%Y')), ... } Due to the fact that date.strftime returns Any type, for my type hinting and autocomplete to work I either need to pass it to the str function or typing.cast(str, date). It would be nice if I could just write "birthDate": date.strftime(r'%m/%d/%Y') as str, like in C#. It's shorter, (in my opinion) more readable, and avoids having to unnecessarily call a constructor or import typing.cast. … [View More]

3 2

Bind/normalize params for @functools.cache
by Steve Jorgensen March 20, 2023

March 20, 2023

I was surprised to find, when I pass arguments to a function decorated with `(a)functools.cache` in different, equivalent ways, the cache does not recognize them as the same. counter = itertools.count(1) @functools.cache def example(a, b, c=0): return (next(counter), a, b, c) example(1, 2) # => (1, 1, 2, 0) example(1, b=2) # => (2, 1, 2, 0) example(1, 2, 0) # => (3, 1, 2, 0) When I wrote my own implementation as a coding exercise, I noticed the … [View More]

1 1