Mailman 3 June 2021 - Python-Dev

Is the Python review process flawed?
by esmeraldagarcia＠byom.de July 2, 2021

July 2, 2021

I just stumbled upon the following issue and subsequent pull request. It is a very small bugfix. There is currently a bug in Python and this pull request fixes it. It's not a new feature or an enhancement, it is a bugfix! Yet, it doesn't get reviewed, nor merged. And this has been going on since March 2017. Why not just merge this? It's not like it's huge or obstructing or obfuscating the current code base? There's always time to write an improvement or a complete rewrite of this module feature … [View More]

15 17

Request for reviewers: pathlib improvements
by Barney Gale July 2, 2021

July 2, 2021

I’m working towards supporting subclassing pathlib.Path for things like zip/tar archives, iso files, S3, etc. This was first brought up a few years ago in bpo-24132 <https://bugs.python.org/issue24132> and discussed further on the python-ideas forum <https://discuss.python.org/t/make-pathlib-extensible/3428>. Before I can approach the meat of the issue, I'd like to land a handful of backwards-compatible patches that tidy up the pathlib internals. These are: - #19220 <https://… [View More]

1 3

Critique of PEP 657
by Mark Shannon July 1, 2021

July 1, 2021

Hi, Apologies for my tardiness in doing this, but no one explicitly said it was too late to critique PEP 657... Critique of PEP 657 (Include Fine Grained Error Locations in Tracebacks) ------------------------------------------------------------------------ First of all I want to say that I support the goal of improving error messages. IMO the PEP should be "accepted in principle". I think all of the issues below can be fixed while still supporting the general aims of the PEP. The … [View More]change from points to ranges as locations --------------------------------------------- Because Python is a procedural language, there is an expectation that code executes in a certain order. PEP 626 (Precise line numbers for debugging and other tools) seeks to guarantee that that expectation is met. PEP 657 describes how locations for exceptions are to be handled, but is vague on the treatment of locations for tracing, profiling and debugging. PEP 657 proposes that locations for exceptions be treated as ranges, whereas tracing, profiling and debugging currently treat locations as points. Either this will end in contradictions and confusion should those locations disagree, or the locations for tracing, profiling and debugging must change. Using the start of a range as the point location for tracing may be misleading when the operation that causes an exception is on a different line within that range. Consider this example: https://github.com/python/cpython/blob/main/Lib/test/test_compile.py#L861 This might seem like a contrived case, but it is based on a real bug report https://bugs.python.org/issue39316 1. def load_method(): 2. return ( 3. o. 4. m( 5. 0 6. ) Currently the call is traced on line 4. PEP 657 would change the location of the call from line 4 to the range 3-6, which would mean that the line of call is no longer traced separately (or traced several times). PEP 657 makes no mention of this change. The PEP claims that these changes are improvements. Maybe they are, but they are quite impactful changes which the PEP glosses over. The impact on tools like coverage.py and debuggers should be made clearer. For example, how would one set a breakpoint on line 4 above? There are other languages (e.g. jinja templates) that compile to Python AST and bytecode. These *might* produce locations that overlap, but are not nested. The behavior of tracing and debuggers needs to be described for those locations. Backwards Compatibility ----------------------- PEP 657 claims it is fully backwards compatible, but it cannot be both backwards compatible and consistent. There are fundamental differences between using ranges and points as locations. Impact on startup time ---------------------- The PEP 657 suggests the impact on startup would be negligible. That is not quite true. The impact on startup is probably acceptable, but a proper analysis needs to be made. The increase in size of pyc files ~20% puts an upper bound on the increase of startup time, but I would expect it to be much less than that as loading files from disk is only a fraction of startup. Currently, startup is dominated by inefficiencies in interpreter creation, unmarshalling and module loading. We plan to reduce these a lot for 3.11, so that the impact of PEP 657 on startup will be larger (as a ratio) than experiments with 3.10 suggest. The API ------- The C API adds three new functions, one each for the end line, start column and end column. This is either slow, as any compressed table needs to be parsed four times, or space inefficient using an uncompressed table. Opt-out ------- Allowing opt-out prevents consistent compression of location data, resulting in larger pyc files for those that do not opt-out. The exact semantics, in terms of error formatting, tracing, etc is not described should the user opt-out. Summary ------- Overall, there is nothing that blocks acceptance of the PEP in principle, but there are quite a few issues that need resolving. Suggestions ----------- 1. Clarify, in detail, the impact on line-based tools like profilers, coverage.py and debuggers. This should include help on how to use the new APIs and where using the old APIs might result in behavioral changes. 2. Change the C API to a single function: int PyCode_Addr2Location(PyCodeObject *co, int addr, int *startline, int *startcolumn, int *endline, int *endcolumn) 3. Drop the opt-out option. If the extra information is optional, then the compression scheme must allow for that; making the code more complex and potentially less efficient. Does opting out use the start of the range, or the old line, as the location? 4. Drop the limitation on column offsets. The data needs to be compressed anyway, so allowing arbitrary column offsets is effectively free. 6. Store all location information in a single table (this applies more to the implementation than the PEP) Using four separate objects to hold the location info adds a lot of overhead for most functions. Cheers, Mark. [View Less]

4 8

Is it too late to critique PEP 657? (Include Fine Grained Error Locations in Tracebacks)
by Mark Shannon June 29, 2021

June 29, 2021

Hi, I was expected the announcement of a BDFL delegate for PEP 657, as the author is a steering council member. It seems that a PEP submitted by a SC member has been accepted by the SC with seemingly no external review. PEP 657 is likely to cause significant worsening of start up time and interact poorly with debugging and profiling. Cheers, Mark.

3 3

PEP 657 Accepted - Include Fine Grained Error Locations in Tracebacks
by Barry Warsaw June 28, 2021

June 28, 2021

I’m happy to announce that PEP 657 (Include Fine Grained Error Locations in Tracebacks) has been unanimously accepted for Python 3.11 by the Python Steering Council. Congratulations Pablo, Batuhan, and Ammar! Cheers, -Barry (on behalf of the Steering Council)

1 0

[RELEASE] Python 3.9.6, 3.8.11, 3.7.11, and 3.6.14 are now available
by Łukasz Langa June 28, 2021

June 28, 2021

Python 3.9.6 Get it here: https://www.python.org/downloads/release/python-396/ <https://www.python.org/downloads/release/python-396/> Python 3.9.6 is the newest major stable release of the Python programming language, and it contains many new features and optimizations. There’s been 146 commits since 3.9.5 which is a similar amount compared to 3.8 at the same stage of the release cycle. See the change log <https://docs.python.org/release/3.9.6/whatsnew/changelog.html> for details. … [View More]

1 0

IntEnum, IntFlag, and the stdlib
by Ethan Furman June 27, 2021

June 27, 2021

TL;DR I am considering changing IntEnum and IntFlag's `__str__` to be `int.__str__` IntEnum and IntFlag are becoming more common in the stdlib. They currently show up in * http * re * signal * ssl * socket to name just a few. 3.10 already has some changes to the str() and repr() of enums in general: HTTPStatus -> OK and HTTPStatus.OK instead of HTTPStatus.OK and <HTTPStatus.OK: 200> Enum's that are taking the place of global constants have the repr() further modified: … [View More]

4 5

cmd.Cmd.prompt should be an instance attribute
by Daniel Walker June 27, 2021

June 27, 2021

I was recently using the cmd module for a project where my CLI could connect to and interact with another host. I implemented prompt in such a way that it would show the IP address when connected. I.e., class MyCmd(cmd.Cmd): ... @property def prompt(self) -> str: if self.remote_host.connected(): return f'> ({self.remote_host.ip}) ' else: return '> ' This worked perfectly fine... until I ran mypy. mypy complained because, in cmd.… [View More]

3 7

Summary of Python tracker Issues
by Python tracker June 25, 2021

June 25, 2021

ACTIVITY SUMMARY (2021-06-18 - 2021-06-25) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 7410 (-36) closed 48834 (+91) total 56244 (+55) Open issues with patches: 2951 Issues opened (34) ================== #34389: CPython may fail to build in the presence of a ~/.pydistutils. https://bugs.python.org/issue34389 reopened by iritkatriel #43988: … [View More]

1 0

Re: Delayed evaluation of f-strings?
by Eric Nieuwland June 25, 2021

June 25, 2021

> On 24 Jun 2021, at 10:28, micro codery <ucodery(a)gmail.com> wrote: > > As pointed out already, f-strings and format are subtly different (not > counting that one can eval and the other cannot). Besides quoting, the > f-sting mini language has diverged from format's >>>> spam="Spam" >>>> f"{spam=}" > "spam='Spam'" >>>> "{spam=}".format(spam=spam) > Traceback (most recent call last): > File "<stdin>", line 1, in <… [View More]

1 0