Mailman 3 April 2023 - Python-ideas

len(Enum) should raise TypeError
by Richard Hajek 14 Aug '23

14 Aug '23

# Feature or enhancement `len(Enum)` has no useful meaning and should therefore raise the appropriate error # Pitch I cannot figure out any scenario, in which len(Enum) should not raise. Enum is a type and as any other types, such as `len(list)` or `len(dict)`, and should not give any meaningful result on len. Thoughts?

9 15

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico 23 Jul '23

23 Jul '23

I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to say which of those pulls is the stronger one.) 3) If "yes" to question 1, would you use it for any/all of (a) mutable defaults, (b) referencing things that might have changed, (c) referencing other arguments, (d) something else? 4) If "no" to question 1, is there some other spelling or other small change that WOULD mean you would use it? (Some examples in the PEP.) 5) Do you know how to compile CPython from source, and would you be willing to try this out? Please? :) I'd love to hear, also, from anyone's friends/family who know a bit of Python but haven't been involved in this discussion. If late-bound defaults "just make sense" to people, that would be highly informative. Any and all comments welcomed. I mean, this is python-ideas after all... bikeshedding is what we do best! The reference implementation currently has some test failures, which I'm looking into. I'm probably going to make this my personal default Python interpreter for a while, to see how things go. ChrisA

43 364

Make ellipsis an indicator of missing implementation
by haael 03 May '23

03 May '23

In examples in the web very often we see unfinished or partial code, where the ellipsis "..." is used in place of missing instructions. Idea: make ellipsis used in that context throw an exception, reminding the user that this code is work in progress. The exception could be called ToDoError, or WorkInProgressError, or simply EllipsisError, and could be derived from NotImplementedError. ``` def my_fun(): ... # todo my_fun() > WorkInProgressError: Implementation of `my_fun` is not finished. ``` This change could break some code, as for now ellipsis in the middle of code is silently ignored, but I don't think anybody seriously relies on that behavior. haael

5 4

Allowing `str.format` to format one or more parameters instead of all parameters
by Samuel Muldoon 30 Apr '23

30 Apr '23

Consider the following string: x = r"\mathjax{{color}}{{text}}" string `x` contains two parameters named `color` and the other named `text`. Currently, python requires that the string class method `str.format` contain key-word arguments for *all *parameters, not just *one* parameter result = r"\mathjax{{color}}{{text}}".format(color = "blue" , text = "Spanish") result = "\mathjax{blue}{Spanish}" Can we change str.format so that it is possible to change only one string parameter, but leave the other parameters alone? # pfr is partially_formatted_result pfr = r"\mathjax{{color}}{{text}}".format(color = "blue") # ERROR! missing parameter `text` result = r"\mathjax{{color}}{{text}}".format(text = "Spanish") # ERROR! missing parameter `color` The implementation requires fewer than ten lines of code in python, probably less than fifty lines in C, or a different implementation language. class str: def format(self, **kwargs): for key in kwargs: x = "{"+key+"}" ostr = kwargs[key].join(self.split(x)) return ostr # output string As an example, everywhere a string contained `{text}` it will now say `*Spanish*` . *Samuel Muldoon* *(720) 653 -2408* *muldoonsamuel(a)gmail.com <muldoonsamuel(a)gmail.com>*

13 21

Auto dedent -c arguments.
by Jonathan Crall 29 Apr '23

29 Apr '23

I have what I think is a fairly low impact quality of life improvement to suggest for the python CLI. When I'm not working in Python I tend to be working in bash. But often I want to break out and do something quick in Python. I find the `python -c ` CLI very useful for this. For one liners it's perfect. E.g. NEW_VAR=$(python -c "import pathlib; print(pathlib.Path('$MYVAR').parent.parent)") And even if I want to do something multi-line it's pretty easy NEW_VAR=$(python -c " import pathlib for _ in range(10): print('this is a demo, bear with me') ") But the problem is when I'm writing bash inside a function or some other nested code, I would like to have nice indentation in my bash file, but if I write something like this: mybashfunc(){ python -c " import pathlib for _ in range(10): print('this is a demo, bear with me') " } I get `IndentationError: unexpected indent`. This means I have to write the function ugly like this: mybashfunc(){ python -c " import pathlib for _ in range(10): print('this is a demo, bear with me') " } Or use a helper function like this: codeblock() { __doc__=' copy-pastable implementation Prevents indentation errors in bash ' echo "$1" | python -c "import sys; from textwrap import dedent; print(dedent(sys.stdin.read()).strip('\n'))" } mybashfunc(){ python -c $(codeblock " import pathlib for _ in range(10): print('this is a demo, bear with me') ") } Or more recently I found that this is a low-impact workaround: mybashfunc(){ python -c "if 1: import pathlib for _ in range(10): print('this is a demo, bear with me') " } But as a certain Python dev may say: "There must be a better way." Would there be any downside to the Python CLI automatically dedenting the input string given to -c? I can't think of any case off the top of my head where it would make a previously valid program invalid. Unless I'm missing something this would strictly make previously invalid strings valid. Thoughts? -- -Dr. Jon Crall (him)

5 6

Protocols Subclassing Normal Classes
by Jordan Macdonald 24 Apr '23

24 Apr '23

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

4 3

new PEP: implementation independent native code invocation and data exchange ABI standard (not sure if accurate)
by Evan Greenup 24 Apr '23

24 Apr '23

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

5 4

XDG Directory Support for PDB
by Gustaf Waldemarson 21 Apr '23

21 Apr '23

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

3 7

Re: XDG Directory Support for PDB
by Barry 20 Apr '23

20 Apr '23

1 0

Python should add "__name__" and "__doc__" attributes to "functools.partial"
by Matteo Raso 15 Apr '23

15 Apr '23

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