Mailman 3 October 2022 - Python-ideas

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

July 23, 2023

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

zip(x, y, z, strict=True)
by Ram Rachum Dec. 1, 2022

Dec. 1, 2022

Here's something that would have saved me some debugging yesterday: >>> zipped = zip(x, y, z, strict=True) I suggest that `strict=True` would ensure that all the iterables have been exhausted, raising an exception otherwise. This is useful in cases where you're assuming that the iterables all have the same lengths. When your assumption is wrong, you currently just get a shorter result, and it could take you a while to figure out why it's happening. What do you think?

27 179

Re: Add copy to pathlib
by Charles Machalow Oct. 24, 2022

Oct. 24, 2022

What about adding shutil.rmtree while here? I'm of the opinion that if it's file/path based, having access via pathlib.Path makes sense.

2 2

Add copy to pathlib
by Todd Oct. 19, 2022

Oct. 19, 2022

Currently, pathlib supports pretty much all common filesystem operations. You can create, move, and delete both files and directories. One big omission is copying. You need shutil for that. Whatever the original intent might have been behind pathlib, it is now effectively the standard tool for filesystem operations. As such, excluding copying alone from basic operations creates an unnecessary hurdle for users. It also increases the difficulty of doing such operations since there is no hint within the pathlib documentation on how to copy, new users basically need to google it to find out. That is fine for less common operations, but far from ideal from a basic one like copying. So I think it would make a lot of sense to include copying inside pathlib. I propose adding a `copy` method to `pathlib.Path` (for concrete paths). The specific call signature would be: copy(dst, *, follow_symlinks=True, recursive=True, dir_exist_ok=True) This will call `shutil.copytree` for directories if recursive is True, or `copy2` if recursive if False. For files it will call `copy2` always. An alternative would be to have separate `copy` and `copytree` methods, but in most situations I think copying on directories would want copying a tree.

7 11

Is it possible to provide an official type annotation checker？
by pvmpatch＠163.com Oct. 14, 2022

Oct. 14, 2022

I’m doing some research on Python type annotations recently. I found that, some dynamic typing related bugs can be effectively avoided in the early stages of code development, by adding type annotations to Python code and applying some type checking tools (such as MyPy, PyType, Pyright, and Pyre, etc.). The introduction of type annotations effectively improves the type safety of Python code. However, different tools discover, classify and report defects in different ways, and there is little overlap in the defects they reported. In the same code segment, some type checking tools will report defects but some will not. These may confuse users. Because it is not easy for the user to determine which tools give credible results. Based on the above, I have the following suggestion: Is it possible that Python provide a new type checker officially? Or is it possible that Python choose one of the off-the-shelf type checking tools as the official and recommended one? Python is my favourite programming language. I sincerely hope that I can help Python become stronger and safer. I hope this idea can be useful for you.

5 6