Mailman 3 May 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

extend method of the list class could return a reference to the list so that we can chain method calls
by Samuel Muldoon 01 Jun '23

01 Jun '23

*Currently, list.extend does not allow method chaining.* *parameters = [ "zero or more", "zero or more".upper(), "zero or more".lower(), "Zero or More"* *].extend(["(0, +inf)", "[0; +in**f]"])* *parameters.extend(["{0, \u221E}"]).append("(0 inf)")* *Samuel Muldoon* *(720) 653 -2408* *muldoonsamuel(a)gmail.com <muldoonsamuel(a)gmail.com>*

3 2

Virtual packages
by Soni L. 21 May '23

21 May '23

Python allows setting __path__ to turn a module into a package. However, it's allegedly only defined for __init__.py? Proposal: A virtual package is a non-__init__.py whose first line of code, after comments and future imports, assigns to __path__. This would allow -m virtualpackage to call virtualpackage.__main__, wherever that is. Instead of running virtualpackage.py as __main__.

1 0

Visual Python.
by Michael R 19 May '23

19 May '23

To whom it may concern: Is it possible to create a Visual Python with options and editing tools similar to Excel? In the beginning it could be a combo with a command-docker, calling for a visual Routine. Indented structure of coding in Python is perfectly suited for it. In my mind such structure was the first subconscious step in this direction. It would make programming much easier: almost like playing with LEGO blocks. Sincerely, Michael R.

4 5

@lazy decorator an alternative to functools.partial ?
by Daniel Guffey 19 May '23

19 May '23

Hello all! I've been playing with string templating quite a bit lately and wrote some logic to help me with this. I found it a bit more flexible than using partial and wanted to get feedback to see if it would be worth formalizing this code into the functools module. It's pretty short so I don't think it deserves its own module, and it behaves similarly to partial but has a bit more flexibility. Thanks for your time! ```python from functools import wraps from typing import Any, Callable, Union def lazy(func: Callable[..., Any]) -> Callable[..., Any]: """ A decorator that buffers args and kwargs gathering and function execution suspending processing until the function is called without any args or kwargs. This allows any function to support partials for decomposition out of the box. Also, supports variable length arguments and kw_arguments. Example: import math @lazy def velocity(height_m: float, acceleration_m2: float) -> float: return math.sqrt(2 * acceleration_m2 * height_m) g = -9.81 # acceleration due to gravity in m/s^2 earth = velocity(acceleration=g) v = earth(height=1)() print("The velocity is:", v, "m/s") v = earth(height=10)() print("The velocity is:", v, "m/s") v = earth(height=100)() print("The falling velocity is:", v, "m/s") """ @wraps(func) def collect(*args: Any, **kwargs: Any) -> Any: if not args and not kwargs: return func(*args, **kwargs) return ( lambda *next_args, **next_kwargs: func( *(args + next_args), **{**kwargs, **next_kwargs} ) if not next_args and not next_kwargs else collect(*(args + next_args), **{**kwargs, **next_kwargs}) ) return collect @lazy def f_string_head(f_str: str, **kwargs) -> Union[Callable[[], str], str]: """ Turns an f-string into a curry-able function, will return head to end or first KeyError when finally evaluated with no arguments. """ try: results = f_str.format_map({} if kwargs is None else kwargs) return results except KeyError as e: sub_template = f_str.split("{" + e.args[0] + "}", 1)[0] results = sub_template.format_map({} if kwargs is None else kwargs) return results def test_f_string() -> None: """ Tests the f_string function. """ template = """{one}{two}{three}""" f_one = f_string_head(template, one="1") f_one_three = f_one(three="3") f_one_two_three = f_one_three(two="2") assert f_one() == "1" assert f_one_three() == "1" assert f_one_two_three() == "123" def test_curring() -> None: @lazy def my_function(*args, **kwargs): print( "Function evaluated with arguments:", args, "and keyword arguments:", kwargs ) assert args == (1, 2, 3, 4) assert kwargs == {"a": 2, "b": 5} return "Function passed" partial_function = my_function(1, 2, a=3) result = partial_function(3, 4, b=5, a=2) results = result() print(results) def test_add() -> None: @lazy def add(*args: int, **kwargs: int) -> int: """ A function that takes any number of integer arguments and returns their sum. Args: *args: Integer arguments to be summed. **kwargs: Integer keyword arguments to be summed. Returns: The sum of the integer arguments. """ return sum(args) + sum(kwargs.values()) result = add(1)(2, 3)(4)(5, six=6)() print(f"Add={result}") def test_velocity() -> None: import math @lazy def velocity(height_m: float, acceleration_m2: float) -> float: return math.sqrt(2 * acceleration_m2 * height_m) g = 9.81 # acceleration due to gravity in m/s^2 earth = velocity(acceleration_m2=g) v = earth(height_m=5)() print("The falling velocity is:", v, "m/s") v = earth(height_m=15)() print("The falling velocity is:", v, "m/s") v = earth(height_m=30)() print("The falling velocity is:", v, "m/s") def main() -> None: """ The main function that runs the program. """ test_curring() test_add() test_f_string() test_velocity() if __name__ == "__main__": main() ```

7 8

The exact operation of -m is unclear
by Soni L. 18 May '23

18 May '23

A simple virtual package could be: # foo.py __path__ = [__file__ + ".d"] But unfortunately this doesn't work with -m: # foo.py.d/__main__.py print("this will never run") (n.b. -m foo.__main__ works but nobody's writing that.) Is it possible to change this backwards-compatibly? If not, is it possible to document it slightly better? Thanks.

1 0

Mark a set of keys of a TypedDict as incompatible
by Sync In 17 May '23

17 May '23

I have a couple of {{{TypedDict}}}s for use in type hinting that are supposed to have some sets of incompatible keys. For example, if I need to specify that a particular {{{dict}}} can have {{{bar}}} or {{{baz}}} but not both of them, I can write two {{{TypedDict}}}s: {{{#!highlight python from typing import TypedDict class Foo1(TypedDict): bar: str class Foo2(TypedDict): baz: int Foo = Foo1 | Foo2 foo_instance_1: Foo = { # Works fine 'bar': 'foobar' } foo_instance_2: Foo = { # Also fine 'baz': 42 } foo_instance_3: Foo = { # Warning: Expected type 'Foo1 | Foo2', got 'dict[str, str | int]' instead 'bar': 'foobar', 'baz': 42 } }}} However, this doesn't scale very well if I were to have multiple sets; for example, a simple multiplication shows that three sets of 2, 3 and 4 keys each will result in 24 {{{TypedDict}}}s. A solution would be: {{{#!highlight python class Foo(TypedDict): bar: IncompatibleWith('baz', 'qux')[str] baz: IncompatibleWith('bar', 'qux')[int] qux: IncompatibleWith('bar', 'baz')[bool] }}} ...or, with a decorator somewhat similar to {{{@overload}}}: {{{#!highlight python @incompatible('bar', 'baz', 'qux') # ... class Foo(TypedDict): bar: str baz: int qux: bool }}} I asked this question on StackOverflow<https://stackoverflow.com/q/75981727> and was informed that such a feature doesn't exist. How about adding it to Python then?

2 1

Thoughts on allowing Path objects in shlex.join
by mitchell.negus.57＠gmail.com 14 May '23

14 May '23

At the moment, `shlex.join` raises ``` TypeError: expected string or bytes-like object ``` when given `pathlib.Path` objects. Since `subprocess.run` and related subprocess commands allow `Path` since Python 3.6 and 3.8 for Windows, it seems intuitive to me that `shlex.join` be able to handle paths as well. This has been briefly discussed before on the bug tracker (issue 89293, link below), but with the caveat that it was the wrong venue, and should be brought up on this list instead. That said, I can't find any record that it ever made it over here, but I am curious to get this community's perspective. My understanding of arguments against in that discussion were that `shlex.join` should not implicitly convert its arguments to strings, and that `Path` objects were not special enough for an exception. However (and as noted over there), `subprocess` takes the exact opposite approach, and has an explicit `isinstance` check to allow and convert `os.PathLike` objects. I'm assuming that some of the reasoning behind allow path-to-string conversions there has to do with the prevalence of using paths as command line arguments, and that seems to me like it could be rationale enough for why `Path` objects warrant an exception to the "don't-convert-inputs-to-strings" unwritten rule for `shlex.join`. Without getting into the specific details of implementation, I'd imagine that changing this to just convert `os.PathLike` to strings in `shlex.join` would not break much existing code. I find it rather unlikely—though I'll admit I have no supporting evidence—that anyone is relying on `shlex.join` to catch path objects that should be strings; I'd bet instead anyone using paths already is just converting them to strings "manually" before passing them to `shlex.join`. I'm curious to hear more opinions on this though, since I'm guessing there may be very valid reasons that others have for not wanting to move in this direction that I'm totally oblivious to. Thanks all! Issue 89283: https://github.com/python/cpython/issues/89293

3 2

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