Mailman 3 August 2020 - Python-Dev

async generator bug fixed in 3.8+ and backported to 3.6 but not to 3.7
by Matthew Einhorn Aug. 12, 2020

Aug. 12, 2020

Hi, The fix for https://bugs.python.org/issue33786 ("@asynccontextmanager doesn't work well with async generators") was merged in 3.8 and then backported to 3.6. However, it was overlooked to be backported for 3.7 ( https://github.com/python/cpython/pull/7506). I'm aware that 3.7 is in security fix mode only so I'm not sure there's more to be done, however, given that this is fixed for 3.6, 3.7 is in a weird position still having the bug. So I just wanted to bring this up in case the fix can … [View More]

3 2

How about copying the typing module docs from 3.10 to 3.9?
by Luciano Ramalho Aug. 12, 2020

Aug. 12, 2020

Hello, Łukasz, I reorganized the typing module docs, Guido made suggestions, reviewed and merged it to master. Right now everything in typing.rst [1] applies to 3.9 as well as 3.10. [1] https://docs.python.org/3.10/library/typing.html How about copying the typing.rst file to the 3.9 branch, so more people would benefit from it sooner? Cheers, Luciano -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical … [View More]

3 2

[RELEASE] Python 3.9.0rc1 is now available
by Łukasz Langa Aug. 11, 2020

Aug. 11, 2020

Python 3.9.0 is *almost* ready. This release, *3.9.0rc1*, is the penultimate release preview. You can get it here: https://www.python.org/downloads/release/python-390rc1/ Entering the release candidate phase, only reviewed code changes which are clear bug fixes are allowed between this release candidate and the final release. The second candidate and the last planned release preview is currently planned for 2020-09-14. Please keep in mind that this is a preview release and its use is *not* … [View More]recommended for production environments. Calls to action Core developers: all eyes on the docs now * Are all *your* changes properly documented? * Did you notice *other* changes you know of to have insufficient documentation? Community members We *strongly encourage* maintainers of third-party Python projects to prepare their projects for 3.9 compatibility during this phase. As always, report any issues to the Python bug tracker <https://bugs.python.org/>. Installer news This is the first version of Python to default to the 64-bit installer on Windows. The installer now also actively disallows installation on Windows 7. Python 3.9 is incompatible with this unsupported version of Windows. Major new features of the 3.9 series, compared to 3.8 Some of the new major new features and changes in Python 3.9 are: * PEP 584 <https://www.python.org/dev/peps/pep-0584/>, Union Operators in `dict` * PEP 585 <https://www.python.org/dev/peps/pep-0585/>, Type Hinting Generics In Standard Collections * PEP 593 <https://www.python.org/dev/peps/pep-0593/>, Flexible function and variable annotations * PEP 602 <https://www.python.org/dev/peps/pep-0602/>, Python adopts a stable annual release cadence * PEP 615 <https://www.python.org/dev/peps/pep-0615/>, Support for the IANA Time Zone Database in the Standard Library * PEP 616 <https://www.python.org/dev/peps/pep-0616/>, String methods to remove prefixes and suffixes * PEP 617 <https://www.python.org/dev/peps/pep-0617/>, New PEG parser for CPython * BPO 38379 <https://bugs.python.org/issue38379>, garbage collection does not block on resurrected objects; * BPO 38692 <https://bugs.python.org/issue38692>, os.pidfd_open added that allows process management without races and signals; * BPO 39926 <https://bugs.python.org/issue39926>, Unicode support updated to version 13.0.0; * BPO 1635741 <https://bugs.python.org/issue1635741>, when Python is initialized multiple times in the same process, it does not leak memory anymore; * A number of Python builtins (range, tuple, set, frozenset, list, dict) are now sped up using PEP 590 <https://www.python.org/dev/peps/pep-0590> vectorcall; * A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, _functools, _json, _locale, operator, resource, time, _weakref) now use multiphase initialization as defined by PEP 489 <https://www.python.org/dev/peps/pep-0489/>; * A number of standard library modules (audioop, ast, grp, _hashlib, pwd, _posixsubprocess, random, select, struct, termios, zlib) are now using the stable ABI defined by PEP 384 <https://www.python.org/dev/peps/pep-0384/>. [View Less]

1 0

Pay for PR review and merging for VxWorks RTOS
by Xin, Peixing Aug. 10, 2020

Aug. 10, 2020

Hi, Python developers: Anyone interested in PR review and merging for VxWorks RTOS? We can give a proper pay for that. Contact me if you have interest. Thanks, Peixing

4 6

Re: Python Documentation, Python language improvement, and productive discussion
by David Antonini Aug. 10, 2020

Aug. 10, 2020

Add my name. ________________________________ From: python-dev-request(a)python.org <python-dev-request(a)python.org> Sent: Sunday, August 9, 2020 11:00 AM To: python-dev(a)python.org <python-dev(a)python.org> Subject: Python-Dev Digest, Vol 205, Issue 17 Send Python-Dev mailing list submissions to python-dev(a)python.org To subscribe or unsubscribe via the World Wide Web, visit https://mail.python.org/mailman3/lists/python-dev.python.org/ or, via email, send a … [View More]

1 0

Summary of Python tracker Issues
by Python tracker Aug. 7, 2020

Aug. 7, 2020

ACTIVITY SUMMARY (2020-07-31 - 2020-08-07) 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 7598 (+14) closed 45647 (+39) total 53245 (+53) Open issues with patches: 3098 Issues opened (34) ================== #41075: IDLE: Better support history navigation https://bugs.python.org/issue41075 reopened by terry.reedy #41453: A possible reference leak … [View More]

1 0

Premature Destruction of Shared Memory
by Vinay Sharma Aug. 6, 2020

Aug. 6, 2020

As suggested by Guido I am posting a potential solution to the following problem for review. Problem <https://bugs.python.org/issue38119#msg351960> A quick fix for this problem is to prevent resource tracker from handling destruction/unlinking of shared memory. A PR <https://github.com/python/cpython/pull/15989> for the same was opened by Davin (@applio), and at this moment it is the only implemented solution to fix some of the critical issues in shared memory. But, as soon as … [View More]

1 0

PEP 622 (Structural Pattern Matching) questions
by Mark Shannon Aug. 6, 2020

Aug. 6, 2020

Hi, I have two questions about PEP 622, as it stands. 1. Is the current version the final version? 2. Is the difference in semantics between the Django example and the proposed replacement deliberate or accidental? (The difference being the change in behaviour for sequences other than list or tuple). Cheers, Mark.

3 3

Re: Pattern matching (alternative to PEP 622)
by Eric Nieuwland Aug. 5, 2020

Aug. 5, 2020

> On 4 Aug 2020, at 14:38, Koos Zevenhoven wrote: > > Hi everyone, > > [ … analysis of design goals and possible solutions, including … ] > > Point3D(x=pi, y=SIX, z=value) It suddenly struck me that Point3D(x=pi, y=SIX, z into value) would quite accurately describe what is being established here. > [ … goes on … ] > > <expression> matches <pattern> > > and that would evaluate to a boolean-like value. Yes. I’d like that as it separates … [View More]

1 0

Pattern matching (alternative to PEP 622)
by Koos Zevenhoven Aug. 4, 2020

Aug. 4, 2020

Hi everyone, By what I'm about to write below, I've aimed at a design to meet needs resembling those that PEP 622 deals with, although with some differences, especially in emphasis. I'm not writing a full introduction here; the intended audience of this email is people somewhat familiar with PEP 622 and its discussions. This email doesn't have much structure or anything, but I hope it's sufficiently clear. Things that this design aims to address: * Check whether an object's structure … [View More]matches a given pattern * Optionally extract desired values from within that structure * Learning: patterns are understandable in a logical and consistent manner * Matching can be easily tinkered with interactively * Names used in patterns behave in a clear and intuitive way for Python programmers * ... The most difficult thing is perhaps to understand what names mean: what is being bound to, and what is a value defined elsewhere and so on. For example, if a (somewhat unrealistic) pattern looks like Point3D(x=3.14, y=6, z=_) , there are four names that refer to something: `Point3D`, `x`, `y` and `z`. To understand this, it is useful to think of the pattern as corresponding to an expression, although it is not treated as quite the same in the end. (So, here x, y, z refer to internals/arguments of Point3D) The situation becomes more difficult when the values to compare with are in variables, and/or if one wishes to extract a value from the structure. Point3D(x=pi, y=SIX, z=value) Now there is no way to tell, from this, which names refer to existing objects and which should be bound to by the operation, except by guessing. Here, `value` is supposed to be a binding target. Python already has destructuring assignment (`a, b, *rest = values`), which is similar to what happens in function calls: `def func(a, b, *rest): ...`. However, compared to this, it is more useful to see patterns as working backwards compared to this. For example, the semantics of the names in lambda value: Point3D(x=pi, y=SIX, z=value) are exactly as desired. That is, when the pattern matching is interpreted as "does this object look like what this function would produce, and if so, what would be the arguments of the function in that case?". Matching the pattern would bind to `value`. So, with this, a previous understanding of function definitions already gives you a mental model for how names work in patterns *and* for what the pattern is supposed to do. In theory, the lambda expression could BE the syntax for a pattern. However, many have wished for a different syntax even for lambdas. A slightly nicer form would be to omit the keyword `lambda`, but then one would still have to repeat the names to be bound. To avoid that, we need a way to explicitly mark "not-yet-bound names": Point3D(x=pi, y=SIX, z=value?) Before going any further, how would one invoke the matching machinery? It could be <expression> matches <pattern> and that would evaluate to a boolean-like value. With this syntax, the `is_tuple` example from PEP 622 would look something like this: def is_tuple(node: Node) -> bool: if node matches Node(children=[LParen(), RParen()]): return True elif node matches Node(children=[Leaf(value="("), Node(), Leaf(value=")")]): return True return False Or something like: def is_tuple(node: Node) -> bool: if node matches tuple_pattern: return True return False Here, `tuple_pattern` would be a pattern pre-defined with a function-like syntax. Also, if there is a `tuple_pattern`, then `is_tuple` is probably not needed at all. Note that in PEP 622, is_tuple uses a match statement with three cases. So, in effect, the full tuple_pattern had been split into subpatterns. This was only possible because it was an OR pattern. In general, splitting a longer pattern into cases like that is not possible. Longer function-like patterns, on the other hand, can be expressed using more pattern functions – just like regular functions can use helper functions. Here, tuple_pattern isn't passed any arguments. It also doesn't have any parameters. However, if it did, those would be considered wildcards, as I believe we'd want both the programmer and the compiler/optimizers to explicitly see, from the match expression, which names will/would be bound. If something other than wildcard behavior is desired, that should be explicitly specified in a "pattern function call". Let's take another example pattern: pdef main_diagonal_point(pos): return Point3D(pos, pos, pos) Now, `main_diagonal_point(0)` would refer to the origin, and `point matches main_diagonal_point` would be true for every point with `x == y == z`. Similarly, also `point matches main_diagonal_point(pos?)` should only match if `x == y == z` — and then bind that value to `pos`. However, one might expect to be able to write the same thing inline as point matches Point3D(pos?, pos?, pos?) , so based on that, multiple occurrences of the same binding target should ensure equality. What about wildcards? If ? were the wildcard, that would mean that point matches main_diagonal_point(?) should NOT mean the same as point matches Point3D(?,?,?) So each occurrence of ? would have to be treated as a "new" wildcard, but when it might be passed as an argument to a sub-pattern, it will be equivalent to effectively something like `0?` (and `1?` and so on) so that the tree occurrences (in the former case) would have to be the same. This is not the only worry about using ? for wildcards. I don't find _ as wildcard really that problematic, although it is a bit more problematic here than in PEP 622. Another option would be to use `Any` as wildcard. However, that would sound like "any *type* of object is fine", although (hopefully) it is most often clear what the *type* should be, and that it is the *value* that can be anything. (And if the type is clear, no isinstance is necessary.) Then the pattern for `isinstance(obj, Class)`. Quite similarly to using a "pattern function" without arguments above, this could be `obj matches Class`. This means that matching with an instance of `type` (inside a pattern) would default to an instance check, while other `object` instances might perhaps default to `==` if nothing else is specified. Walrus patterns? While I think people probably understood PEP 622 walrus patterns quite well, I think walrus patterns harm the understanding patterns in general, because they break the mental model of going "backwards" in some sense. The walrus pattern in PEP 622 would be perfectly described by an AND pattern instead. This is because a binding target in PEP 622 is considered a "capture pattern". The django example in PEP 622 would then be match value: case [*v, label & (Promise() | str())] if v: value = tuple(v) case _: label = key.replace('_', ' ').title() However, I prefer not to think of a binding target as a "pattern", just like I don't think patterns are assignment targets. Instead, here, one might "annotate" a "not-yet-bound name" with a (sub-)pattern: *v?, label?(Promise | str) This would bind to `v` and `label` as well as check that the thing to be bound to `label` matches Promise | str. The django example could be written like this: *if* value *matches* ***v*?*, label*?*(Promise | str) *and* v: value = tuple(v) *else*: label = key.replace('_', ' ').title() However, it would be quite possible to not add this possibility now, and instead use: *if* value *matches* ***v*?*, label*?* *and* v *and* label *matches* Promise | str: value = tuple(v) *else*: label = key.replace('_', ' ').title() I think I'll stop here for now – the internal workings and dunder methods are a whole different story. I hope this was somewhat understandable. I know I didn't explicitly explain all the semantics – I tried to hit the main points and avoid distractions. If something was unclear etc., I'll be happy to answer to any questions or concerns :). —Koos [View Less]

1 0