Mailman 3 June 2018 - Python-Dev

PEP 572: Write vs Read, Understand and Control Flow
by Victor Stinner 04 Jul '18

04 Jul '18

Hi, I have been asked to express myself on the PEP 572. I'm not sure that it's useful, but here is my personal opinion on the proposed "assignment expressions". PEP 572 -- Assignment Expressions: https://www.python.org/dev/peps/pep-0572/ First of all, I concur with others: Chris Angelico did a great job to design a good and full PEP, and a working implementation which is also useful to play with it! WARNING! I was (strongly) opposed to PEP 448 Unpacking Generalizations (ex: [1, 2, *list]) and PEP 498 f-string (f"Hello {name}"), whereas I am now a happy user of these new syntaxes. So I'm not sure that I have good tastes :-) Tim Peter gaves the following example. "LONG" version: diff = x - x_base if diff: g = gcd(diff, n) if g > 1: return g versus the "SHORT" version: if (diff := x - x_base) and (g := gcd(diff, n)) > 1: return g == Write == If your job is to write code: the SHORT version can be preferred since it's closer to what you have in mind and the code is shorter. When you read your own code, it seems straightforward and you like to see everything on the same line. The LONG version looks like your expressiveness is limited by the computer. It's like having to use simple words when you talk to a child, because a child is unable to understand more subtle and advanced sentences. You want to write beautiful code for adults, right? == Read and Understand == In my professional experience, I spent most of my time on reading code, rather than writing code. By reading, I mean: try to understand why this specific bug that cannot occur... is always reproduced by the customer, whereas we fail to reproduce it in our test lab :-) This bug is impossible, you know it, right? So let's say that you never read the example before, and it has a bug. By "reading the code", I really mean understanding here. In your opinion, which version is easier to *understand*, without actually running the code? IMHO the LONG version is simpler to understand, since the code is straightforward, it's easy to "guess" the *control flow* (guess in which order instructions will be executed). Print the code on paper and try to draw lines to follow the control flow. It may be easier to understand how SHORT is more complex to understand than LONG. == Debug == Now let's imagine that you can run the code (someone succeeded to reproduce the bug in the test lab!). Since it has a bug, you now likely want to try to understand why the bug occurs using a debugger. Sadly, most debugger are designed as if a single line of code can only execute a single instruction. I tried pdb: you cannot only run (diff := x - x_base) and then get "diff" value, before running the second assingment, you can only execute the *full line* at once. I would say that the LONG version is easier to debug, at least using pdb. I'm using regularly gdb which implements the "step" command as I expect (don't execute the full line, execute sub expressions one by one), but it's still harder to follow the control flow when a single line contains multiple instructions, than debugging lines with a single instruction. You can see it as a limitation of pdb, but many tools only have the granularity of whole line. Think about tracebacks. If you get an exception at "line 1" in the SHORT example (the long "if" expression), what can you deduce from the line number? What happened? If you get an exception in the LONG example, the line number gives you a little bit more information... maybe just enough to understand the bug? Example showing the pdb limitation: >>> def f(): ... breakpoint() ... if (x:=1) and (y:=2): pass ... >>> f() > <stdin>(3)f() (Pdb) p x *** NameError: name 'x' is not defined (Pdb) p y *** NameError: name 'y' is not defined (Pdb) step --Return-- > <stdin>(3)f()->None (Pdb) p x 1 (Pdb) p y 2 ... oh, pdb gone too far. I expected a break after "x := 1" and before "y := 2" :-( == Write code for babies! == Please don't write code for yourself, but write code for babies! :-) These babies are going to maintain your code for the next 5 years, while you moved to a different team or project in the meanwhile. Be kind with your coworkers and juniors! I'm trying to write a single instruction per line whenever possible, even if the used language allows me much more complex expressions. Even if the C language allows assignments in if, I avoid them, because I regularly have to debug my own code in gdb ;-) Now the question is which Python are allowed for babies. I recall that a colleague was surprised and confused by context managers. Does it mean that try/finally should be preferred? What about f'Hello {name.title()}' which calls a method into a "string" (formatting)? Or metaclasses? I guess that the limit should depend on your team, and may be explained in the coding style designed by your whole team? Victor

12 15

Re: [Python-Dev] PEP 572: Write vs Read, Understand and Control Flow
by Tim Peters 04 Jul '18

04 Jul '18

[Victor Stinner] ... > Tim Peter gaves the following example. "LONG" version: > > diff = x - x_base > if diff: > g = gcd(diff, n) > if g > 1: > return g > > versus the "SHORT" version: > > if (diff := x - x_base) and (g := gcd(diff, n)) > 1: > return g > > == Write == > > If your job is to write code: the SHORT version can be preferred since > it's closer to what you have in mind and the code is shorter. When you > read your own code, it seems straightforward and you like to see > everything on the same line. All so, but a bit more: in context, this is just one block in a complex algorithm. The amount of _vertical_ screen space it consumes directly affects how much of what comes before and after it can be seen without scrolling. Understanding this one block in isolation is approximately useless unless you can also see how it fits into the whole. Saving 3 lines of 5 is substantial, but it's more often saving 1 of 5 or 6. Regardless, they add up. > The LONG version looks like your expressiveness is limited by the > computer. It's like having to use simple words when you talk to a > child, because a child is unable to understand more subtle and > advanced sentences. You want to write beautiful code for adults, > right? I want _the whole_ to be as transparent as possible. That's a complicated balancing act in practice. > == Read and Understand == > > In my professional experience, I spent most of my time on reading > code, rather than writing code. By reading, I mean: try to understand > why this specific bug that cannot occur... is always reproduced by the > customer, whereas we fail to reproduce it in our test lab :-) This bug > is impossible, you know it, right? > > So let's say that you never read the example before, and it has a bug. Then you're screwed - pay me to fix it ;-) Seriously, as above, this block on its own is senseless without understanding both the mathematics behind what it's doing, and on how all the code before it picked `x` and `x_base` to begin with. > By "reading the code", I really mean understanding here. In your > opinion, which version is easier to *understand*, without actually > running the code? Honestly, I find the shorter version a bit easier to understand: fewer indentation levels, and less semantically empty repetition of names. > IMHO the LONG version is simpler to understand, since the code is > straightforward, it's easy to "guess" the *control flow* (guess in > which order instructions will be executed). You're saying you don't know that in "x and y" Python evaluates x first, and only evaluates y if x "is truthy"? Sorry, but this seems trivial to me in either spelling. > Print the code on paper and try to draw lines to follow the control > flow. It may be easier to understand how SHORT is more complex to > understand than LONG. Since they're semantically identical, there's _something_ suspect about a conclusion that one is _necessarily_ harder to understand than the other ;-) I don't have a problem with you finding the longer version easier to understand, but I do have a problem if you have a problem with me finding the shorter easier. > == Debug == > > Now let's imagine that you can run the code (someone succeeded to > reproduce the bug in the test lab!). Since it has a bug, you now > likely want to try to understand why the bug occurs using a debugger. > > Sadly, most debugger are designed as if a single line of code can only > execute a single instruction. I tried pdb: you cannot only run (diff > := x - x_base) and then get "diff" value, before running the second > assingment, you can only execute the *full line* at once. > > I would say that the LONG version is easier to debug, at least using pdb. That might be a good reason to avoid, say, list comprehensions (highly complex expressions of just about any kind), but I think this overlooks the primary _point_ of "binding expressions": to give names to intermediate results. I couldn't care less if pdb executes the whole "if" statement in one gulp, because I get exactly the same info either way: the names `diff` and `g` bound to the results of the expressions they named. What actual difference does it make whether pdb binds the names one at a time, or both, before it returns to the prompt? Binding expressions are debugger-friendly in that they _don't_ just vanish without a trace. It's their purpose to _capture_ the values of the expressions they name. Indeed, you may want to add them all over the place inside expressions, never intending to use the names, just so that you can see otherwise-ephemeral intra-expression results in your debugger ;-) > ... Think about tracebacks. If you get an xception at "line 1" in the > SHORT example (the long "if" expression), what can you deduce > from the line number? What happened? > > If you get an exception in the LONG example, the line number gives you > a little bit more information... maybe just enough to understand the > bug? This one I wholly agree with, in general. In the specific example at hand, it's weak, because there's so little that _could_ raise an exception. For example, if the variables weren't bound to integers, in context the code would have blown up long before reaching this block. Python ints are unbounded, so overflow in "-" or "gcd" aren't possible either. MemoryError is theoretically possible, and in that case it would be good to know whether it happened during "-" or during "gcd()". Good to know, but not really helpful, because either way you ran out of memory :-( > == Write code for babies! == > > Please don't write code for yourself, but write code for babies! :-) > > These babies are going to maintain your code for the next 5 years, > while you moved to a different team or project in the meanwhile. Be > kind with your coworkers and juniors! > > I'm trying to write a single instruction per line whenever possible, > even if the used language allows me much more complex expressions. > Even if the C language allows assignments in if, I avoid them, because > I regularly have to debug my own code in gdb ;-) > > Now the question is which Python are allowed for babies. I recall that > a colleague was surprised and confused by context managers. Does it > mean that try/finally should be preferred? What about f'Hello > {name.title()}' which calls a method into a "string" (formatting)? Or > metaclasses? I guess that the limit should depend on your team, and > may be explained in the coding style designed by your whole team? It's the kind of thing I prefer to leave to team style guides, because consensus will never be reached. In a different recent thread, someone complained about using functions at all, because their names are never wholly accurate, and in any case they hide what's "really" going on. To my eyes, that was an unreasonably extreme "write code for babies" position. If a style guide banned using "and" or "or" in Python "if" or "while" tests, I'd find that less extreme, but also unreasonable. But if a style guide banned functions with more than 50 formal arguments, I'd find that unreasonably tolerant. Luckily, I only have to write code for me now, so am free to pick the perfect compromise in every case ;-)

11 17

Re: [Python-Dev] Informal educator feedback on PEP 572 (was Re: 2018 Python Language Summit coverage, last part)
by Chris Barker 02 Jul '18

02 Jul '18

On Wed, Jun 27, 2018 at 12:01 PM, Eric V. Smith <eric(a)trueblade.com> wrote: > >>> def test(): > >>> spam = 1 > >>> ham = 2 > >>> vars = [key1+key2 for key1 in locals() for key2 in locals()] > >>> return vars > >>> > >>> Wanna guess what that's gonna return? > Guessing aside, messing around with locals() isn't really helpful for the usual case of common code. But the real problem I see with all of this the distinction between generator expressions and comprehensions: """ an assignment expression occurring in a list, set or dict comprehension or in a generator expression (below collectively referred to as "comprehensions") binds the target in the containing scope, honoring a nonlocal or global declaration for the target in that scope, if one exists. For the purpose of this rule the containing scope of a nested comprehension is the scope that contains the outermost comprehension. A lambda counts as a containing scope. """ It seems everyone agrees that scoping rules should be the same for generator expressions and comprehensions, which is a good reason for python3's non-leaking comprehensions: (py2) In [*5*]: i = 0 In [*6*]: l = [i *for* i *in* range(3)] In [*7*]: i Out[*7*]: 2 In [*8*]: i = 0 In [*9*]: g = (i *for* i *in* range(3)) In [*10*]: i Out[*10*]: 0 In [*11*]: *for* j *in* g: ...: *pass* ...: In [*12*]: i Out[*12*]: 0 so comprehensions and generator expressions behave differently -- not great. (py3) In [*4*]: i = 0 In [*5*]: l = [i *for* i *in* range(3)] In [*6*]: i Out[*6*]: 0 In [*7*]: g = (i *for* i *in* range(3)) In [*8*]: i Out[*8*]: 0 In [*9*]: list(g) Out[*9*]: [0, 1, 2] In [*10*]: i Out[*10*]: 0 The loop name doesn't "leak" and comprehensions and generator expressions are the same this regard -- nice. So what about: l = [x:=i for i in range(3)] vs g = (x:=i for i in range(3)) Is there any way to keep these consistent if the "x" is in the regular local scope? Note that this thread is titled "Informal educator feedback on PEP 572". As an educator -- this is looking harder an harder to explain to newbies... Though easier if any assignments made in a "comprehension" don't "leak out". Which does not mean that we'd need a "proper" new local scope (i.e. locals() returning something new) -- as long as the common usage was "intuitive". >> I'm not singling out Chris here, but these discussions would be easier > >> to follow and more illuminating if the answers to such puzzles were > >> presented when they're posed. > well, I think the point there was that it wasn't obvious without running the code -- and that point is made regardless of the answer. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker(a)noaa.gov

10 36

Re: [Python-Dev] We now have C code coverage!
by Ammar Askar 02 Jul '18

02 Jul '18

> Is it possible, given that we are not paying for those reports, to > customize the 'exclude_lines' definitions? Do you want to exclude python code or C code? For C code you can mark sections that exclude coverage in lcov with comments like "LCOV_EXCL_START" http://ltp.sourceforge.net/coverage/lcov/geninfo.1.php For Python code, coverage.py also has some comments you can put down to exclude lines: http://coverage.readthedocs.io/en/coverage-4.2/excluding.html If you don't need line level granularity, you can always add files to ignore in our codecov.yml file: https://docs.codecov.io/docs/ignoring-paths

4 5

PEP 544 (Protocols): adding a protocol to a class post-hoc
by Tin Tvrtković 01 Jul '18

01 Jul '18

Hi, PEP 544 specifies this address as "Discussions-To" so I hope I'm at the right address. I think protocols as defined in the PEP are a very interesting idea and I'm thinking of ways of applying them. The first use case is in the context of attrs. attrs has a number of functions that work only on attrs classes; asdict for example (turns an attrs class into a dictionary recursively). We can't really type hint this properly using nominal subtyping since attrs classes don't have an exclusive ancestor. But it sounds like we could use structural subtyping! An attrs class has a special class-level field, __attrs_attrs__, which holds the attribute definitions. So maybe we can define a protocol: class AttrsClass(Protocol): __attrs_attrs__: ClassVar[Tuple[Attribute, ...]] then we could define asdict as (simplified): def asdict(inst: AttrsClass) -> Dict[str, Any]: ... and it should work out. My question is how to actually add this protocol to attrs classes. Now, we currently have an attrs plugin in mypy so maybe some magic in there could make it happen in this particular case. My second use case is a small library I've developed for work, which basically wraps attrs and generates and sticks methods on a class for serialization/deserialization. Consider the following short program, which does not typecheck on the current mypy. class Serializable(Protocol): def __serialize__(self) -> int: ... def make_serializable(cl: Type) -> Type: cl = attr.s(cl) cl.__serialize__ = lambda self: 1 return cl @make_serializable class A: a: int = attr.ib() def serialize(inst: Serializable) -> int: return inst.__serialize__() serialize(A(1)) error: Argument 1 to "serialize" has incompatible type "A"; expected "Serializable" error: Too many arguments for "A" I have no desire to write a mypy plugin for this library. So I guess what is needed is a way to annotate the class decorator, telling mypy it's adding a protocol to a class. It seems to have trouble getting to this conclusion by itself. (The second error implies the attrs plugin doesn't handle wrapping attr.s, which is unfortunate but a different issue.) I have found this pattern of decorating classes and enriching them with additional methods at run-time really powerful, especially when used with run-time parsing of type information (that often gets a bad rep on this list, I've noticed :) The structural typing subsystem seems like a good fit for use cases like this, and I think it'd be a shame if we couldn't make it work somehow.

2 1

Help preventing SIGPIPE/SIG_DFL anti-pattern.
by Alfred Perlstein 01 Jul '18

01 Jul '18

Hello, I'm looking for someone in the python community to help with a problem of anti-patterns showing up dealing with SIGPIPE. Specifically I've noticed an anti-pattern developing where folks will try to suppress broken pipe errors written to stdout by setting SIGPIPE's disposition to SIG_DFL. This is actually very common, and also rather broken due to the fact that for all but the most simple text filters this opens up a problem where the process can exit unexpectedly due to SIGPIPE being generated from a remote connection the program makes. I have attached a test program which shows the problem. to use this program it takes several args. # 1. Illustrate the 'ugly output to stderr' that folks want to avoid: % python3 t0.py nocatch | head -1 # 2. Illustrate the anti-pattern, the program exits on about line 47 which most folks to not understand % python3 t0.py dfl | head -1 # 3. Show a better solution where we catch the pipe error and cleanup to avoid the message: % python3 t0.py | head -1 I did a recent audit of a few code bases and saw this pattern pop often often enough that I am asking if there's a way we can discourage the use of "signal(SIGPIPE, SIG_DFL)" unless the user really understands what they are doing. I do have a pull req here: https://github.com/python/cpython/pull/6773 where I am trying to document this on the signal page, but I can't sort out how to land this doc change. thank you, -Alfred

3 3

Help preventing SIGPIPE/SIG_DFL anti-pattern.
by Alfred Perlstein 30 Jun '18

30 Jun '18

(sorry for the double post, looks like maybe attachments are dropped, inlined the attachment this time.) Hello, I'm looking for someone in the python community to help with a problem of anti-patterns showing up dealing with SIGPIPE. Specifically I've noticed an anti-pattern developing where folks will try to suppress broken pipe errors written to stdout by setting SIGPIPE's disposition to SIG_DFL. This is actually very common, and also rather broken due to the fact that for all but the most simple text filters this opens up a problem where the process can exit unexpectedly due to SIGPIPE being generated from a remote connection the program makes. I have attached a test program which shows the problem. to use this program it takes several args. # 1. Illustrate the 'ugly output to stderr' that folks want to avoid: % python3 t0.py nocatch | head -1 # 2. Illustrate the anti-pattern, the program exits on about line 47 which most folks to not understand % python3 t0.py dfl | head -1 # 3. Show a better solution where we catch the pipe error and cleanup to avoid the message: % python3 t0.py | head -1 I did a recent audit of a few code bases and saw this pattern pop often often enough that I am asking if there's a way we can discourage the use of "signal(SIGPIPE, SIG_DFL)" unless the user really understands what they are doing. I do have a pull req here: https://github.com/python/cpython/pull/6773 where I am trying to document this on the signal page, but I can't sort out how to land this doc change. thank you, -Alfred === CUT HERE === # # Program showing the dangers of setting the SIG_PIPE handler to the default handler (SIG_DFL). # # To illustrate the problem run with: # ./foo.py dfl # # The program will exit in do_network_stuff() even though there is a an "except" clause. # The do_network_stuff() simulates a remote connection that closes before it can be written to # which happens often enough to be a hazard in practice. # # # import signal import sys import socket import os def sigpipe_handler(sig, frame): sys.stderr.write("Got sigpipe \n\n\n") sys.stderr.flush() def get_server_connection(): # simulate making a connection to a remote service that closes the connection # before we can write to it. (In practice a host rebooting, or otherwise exiting while we are # trying to interact with it will be the true source of such behavior.) s1, s2 = socket.socketpair() s2.close() return s1 def do_network_stuff(): # simulate interacting with a remote service that closes its connection # before we can write to it. Example: connecting to an http service and # issuing a GET request, but the remote server is shutting down between # when our connection finishes the 3-way handshake and when we are able # to write our "GET /" request to it. # In theory this function should be resilient to this, however if SIGPIPE is set # to SIGDFL then this code will cause termination of the program. if 'dfl' in sys.argv[1:]: signal.signal(signal.SIGPIPE, signal.SIG_DFL) for x in range(5): server_conn = get_server_connection() sys.stderr.write("about to write to server socket...\n") try: server_conn.send(b"GET /") except BrokenPipeError as bpe: sys.stderr.write("caught broken pipe on talking to server, retrying...") def work(): do_network_stuff() for x in range(10000): print("y") sys.stdout.flush() def main(): if 'nocatch' in sys.argv[1:]: work() else: try: work() except BrokenPipeError as bpe: signal.signal(signal.SIGPIPE, signal.SIG_DFL) os.kill(os.getpid(), signal.SIGPIPE) if __name__ == '__main__': main()

1 0

Intent to accept PEP 561 -- Distributing and Packaging Type Information
by Guido van Rossum 30 Jun '18

30 Jun '18

I have reviewed PEP 561 and I intend to accept it some time next week, unless significant discussion happens between now and then. The latest version of the PEP can be found at https://www.python.org/dev/peps/pep-0561/ PEP 561 solves a big problem for users of static type checkers like mypy and Pyre (as well as pytype and PyCharm): how to scale the creation of stubs (files with just type annotations, with a .pyi extension). IMO Ethan Smith has done a great job both coming up with and revising the design, and crafting an implementation -- most of PEP 561 is already supported by mypy. It's been a while since a copy of the PEP was posted to python-dev ( https://mail.python.org/pipermail/python-dev/2018-April/152694.html), but only a few things changed since then, so I'll just link to the change history: https://github.com/python/peps/commits/master/pep-0561.rst. Only the last two commits are new since the last posting: support for partial packages and a bunch of small textual tweaks I found today while reviewing. There wasn't a lot of feedback then so I don't expect a flamewar today, but better late than never. ;-) -- --Guido van Rossum (python.org/~guido)

4 8

Summary of Python tracker Issues
by Python tracker 29 Jun '18

29 Jun '18

ACTIVITY SUMMARY (2018-06-22 - 2018-06-29) 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 6705 ( +5) closed 39046 (+52) total 45751 (+57) Open issues with patches: 2664 Issues opened (42) ================== #33932: Calling Py_Initialize() twice now triggers a fatal error (Pyth https://bugs.python.org/issue33932 reopened by vstinner #33944: Deprecate and remove pth files https://bugs.python.org/issue33944 opened by barry #33947: Dataclasses can raise RecursionError in __repr__ https://bugs.python.org/issue33947 opened by eric.smith #33948: doc truncated lines in PDF https://bugs.python.org/issue33948 opened by Mikhail_D #33949: tests: allow to select tests using loadTestsFromName https://bugs.python.org/issue33949 opened by blueyed #33953: The DEFAULT_ENTROPY variable used to store the current default https://bugs.python.org/issue33953 opened by lig #33954: float.__format__('n') fails with _PyUnicode_CheckConsistency a https://bugs.python.org/issue33954 opened by vstinner #33955: Implement PyOS_CheckStack on macOS using pthread_get_stack*_np https://bugs.python.org/issue33955 opened by ronaldoussoren #33959: doc Remove time complexity mention from list Glossary entry https://bugs.python.org/issue33959 opened by adelfino #33960: IDLE REPL: Strange indentation https://bugs.python.org/issue33960 opened by mdk #33961: Inconsistency in exceptions for dataclasses.dataclass document https://bugs.python.org/issue33961 opened by chriscog #33962: IDLE: use ttk.spinbox https://bugs.python.org/issue33962 opened by terry.reedy #33963: IDLE macosx: add tests. https://bugs.python.org/issue33963 opened by terry.reedy #33964: IDLE maxosc.overrideRootMenu: remove unused menudict https://bugs.python.org/issue33964 opened by terry.reedy #33965: [Windows WSL] Fatal Python error: _Py_InitializeMainInterprete https://bugs.python.org/issue33965 opened by vstinner #33966: test_multiprocessing_spawn.WithProcessesTestPool.test_tracebac https://bugs.python.org/issue33966 opened by vstinner #33967: functools.singledispatch: Misleading exception when calling wi https://bugs.python.org/issue33967 opened by doerwalter #33968: os.makedirs and empty string https://bugs.python.org/issue33968 opened by CarlAndersson #33969: "copytree" refuses to copy to a mount point https://bugs.python.org/issue33969 opened by james_r_c_stevens #33971: os.mknod is subject to "umask" https://bugs.python.org/issue33971 opened by james_r_c_stevens #33972: AttributeError in email.message.iter_attachments() https://bugs.python.org/issue33972 opened by skrohlas #33973: HTTP request-line parsing splits on Unicode whitespace https://bugs.python.org/issue33973 opened by tburke #33974: _stringify handles quoted strings incorrectly https://bugs.python.org/issue33974 opened by gauchj #33976: Enums don't support nested classes https://bugs.python.org/issue33976 opened by edwardw #33977: [Windows] test_compileall fails randomly with PermissionError: https://bugs.python.org/issue33977 opened by vstinner #33978: logging.config.dictConfig with file handler leaks resources https://bugs.python.org/issue33978 opened by maggyero #33980: SSL Error when uploading package to your own pypi https://bugs.python.org/issue33980 opened by javidr #33982: cgi.FieldStorage doesn't parse QUERY_STRING with POST that is https://bugs.python.org/issue33982 opened by Daniel Klein #33983: unify types for lib2to3.pytree.Base.children https://bugs.python.org/issue33983 opened by jreese #33984: test_multiprocessing_forkserver leaked [1, 2, 1] memory blocks https://bugs.python.org/issue33984 opened by vstinner #33986: asyncio: Typo in documentation: BaseSubprocessTransport -> Sub https://bugs.python.org/issue33986 opened by kbumsik #33987: need ttk.Frame inside Toplevel(s) https://bugs.python.org/issue33987 opened by markroseman #33988: [EASY] [3.7] test_platform fails when run with -Werror https://bugs.python.org/issue33988 opened by vstinner #33989: ms.key_compare is not initialized in all pathes of list_sort_i https://bugs.python.org/issue33989 opened by johnchen902 #33990: CPPFLAGS during ./configure are not passed-through in sysconfi https://bugs.python.org/issue33990 opened by ericvw #33991: lib2to3 should parse f-strings https://bugs.python.org/issue33991 opened by skreft #33994: python build egg fails with error while compiling test cases https://bugs.python.org/issue33994 opened by sabakauser #33995: test_min_max_version in test_ssl.py fails when Python is built https://bugs.python.org/issue33995 opened by Alan.Huang #33996: Crash in gen_send_ex(): _PyErr_GetTopmostException() returns f https://bugs.python.org/issue33996 opened by vstinner #33997: multiprocessing Pool hangs in terminate() https://bugs.python.org/issue33997 opened by Erik Wolf #33998: random.randrange completely ignores the step argument when sto https://bugs.python.org/issue33998 opened by bup #34000: Document when compile returns a code object v. AST https://bugs.python.org/issue34000 opened by gsnedders Most recent 15 issues with no replies (15) ========================================== #34000: Document when compile returns a code object v. AST https://bugs.python.org/issue34000 #33997: multiprocessing Pool hangs in terminate() https://bugs.python.org/issue33997 #33995: test_min_max_version in test_ssl.py fails when Python is built https://bugs.python.org/issue33995 #33994: python build egg fails with error while compiling test cases https://bugs.python.org/issue33994 #33990: CPPFLAGS during ./configure are not passed-through in sysconfi https://bugs.python.org/issue33990 #33989: ms.key_compare is not initialized in all pathes of list_sort_i https://bugs.python.org/issue33989 #33987: need ttk.Frame inside Toplevel(s) https://bugs.python.org/issue33987 #33986: asyncio: Typo in documentation: BaseSubprocessTransport -> Sub https://bugs.python.org/issue33986 #33982: cgi.FieldStorage doesn't parse QUERY_STRING with POST that is https://bugs.python.org/issue33982 #33980: SSL Error when uploading package to your own pypi https://bugs.python.org/issue33980 #33972: AttributeError in email.message.iter_attachments() https://bugs.python.org/issue33972 #33971: os.mknod is subject to "umask" https://bugs.python.org/issue33971 #33969: "copytree" refuses to copy to a mount point https://bugs.python.org/issue33969 #33967: functools.singledispatch: Misleading exception when calling wi https://bugs.python.org/issue33967 #33964: IDLE maxosc.overrideRootMenu: remove unused menudict https://bugs.python.org/issue33964 Most recent 15 issues waiting for review (15) ============================================= #33998: random.randrange completely ignores the step argument when sto https://bugs.python.org/issue33998 #33997: multiprocessing Pool hangs in terminate() https://bugs.python.org/issue33997 #33990: CPPFLAGS during ./configure are not passed-through in sysconfi https://bugs.python.org/issue33990 #33988: [EASY] [3.7] test_platform fails when run with -Werror https://bugs.python.org/issue33988 #33986: asyncio: Typo in documentation: BaseSubprocessTransport -> Sub https://bugs.python.org/issue33986 #33983: unify types for lib2to3.pytree.Base.children https://bugs.python.org/issue33983 #33978: logging.config.dictConfig with file handler leaks resources https://bugs.python.org/issue33978 #33976: Enums don't support nested classes https://bugs.python.org/issue33976 #33974: _stringify handles quoted strings incorrectly https://bugs.python.org/issue33974 #33973: HTTP request-line parsing splits on Unicode whitespace https://bugs.python.org/issue33973 #33966: test_multiprocessing_spawn.WithProcessesTestPool.test_tracebac https://bugs.python.org/issue33966 #33964: IDLE maxosc.overrideRootMenu: remove unused menudict https://bugs.python.org/issue33964 #33961: Inconsistency in exceptions for dataclasses.dataclass document https://bugs.python.org/issue33961 #33959: doc Remove time complexity mention from list Glossary entry https://bugs.python.org/issue33959 #33936: OPENSSL_VERSION_1_1 never defined in _hashopenssl.c https://bugs.python.org/issue33936 Top 10 most discussed issues (10) ================================= #33944: Deprecate and remove pth files https://bugs.python.org/issue33944 14 msgs #33613: test_multiprocessing_fork: test_semaphore_tracker_sigint() fai https://bugs.python.org/issue33613 12 msgs #33932: Calling Py_Initialize() twice now triggers a fatal error (Pyth https://bugs.python.org/issue33932 12 msgs #33919: Expose _PyCoreConfig structure to Python https://bugs.python.org/issue33919 11 msgs #33939: Provide a robust O(1) mechanism to check for infinite iterator https://bugs.python.org/issue33939 10 msgs #33930: Segfault with deep recursion into object().__dir__ https://bugs.python.org/issue33930 7 msgs #33934: locale.getlocale() seems wrong when the locale is yet unset (p https://bugs.python.org/issue33934 7 msgs #27500: ProactorEventLoop cannot open connection to ::1 https://bugs.python.org/issue27500 6 msgs #33968: os.makedirs and empty string https://bugs.python.org/issue33968 6 msgs #33927: Allow json.tool to have identical infile and outfile https://bugs.python.org/issue33927 5 msgs Issues closed (50) ================== #7060: test_multiprocessing dictionary changed size errors and hang https://bugs.python.org/issue7060 closed by vstinner #14117: Turtledemo: exception and minor glitches. https://bugs.python.org/issue14117 closed by terry.reedy #18932: Optimize selectors.EpollSelector.modify() https://bugs.python.org/issue18932 closed by giampaolo.rodola #20934: test_multiprocessing is broken by design https://bugs.python.org/issue20934 closed by vstinner #22051: Turtledemo: stop reloading demos https://bugs.python.org/issue22051 closed by terry.reedy #24033: Update _test_multiprocessing.py to use script helpers https://bugs.python.org/issue24033 closed by vstinner #24546: sequence index bug in random.choice https://bugs.python.org/issue24546 closed by rhettinger #24567: random.choice IndexError due to double-rounding https://bugs.python.org/issue24567 closed by rhettinger #25007: Add support of copy protocol to zlib compressors and decompres https://bugs.python.org/issue25007 closed by serhiy.storchaka #30339: test_multiprocessing_main_handling: "RuntimeError: Timed out w https://bugs.python.org/issue30339 closed by vstinner #30356: test_mymanager_context() of test_multiprocessing_spawn: manage https://bugs.python.org/issue30356 closed by vstinner #31463: test_multiprocessing_fork hangs test_subprocess https://bugs.python.org/issue31463 closed by vstinner #31815: Make itertools iterators interruptible https://bugs.python.org/issue31815 closed by rhettinger #32063: test_multiprocessing_forkserver failed with OSError: [Errno 48 https://bugs.python.org/issue32063 closed by vstinner #33278: libexpat uses HAVE_SYSCALL_GETRANDOM instead of HAVE_GETRANDOM https://bugs.python.org/issue33278 closed by benjamin.peterson #33573: statistics.median does not work with ordinal scale, add doc https://bugs.python.org/issue33573 closed by taleinat #33711: Could not find externals/db-* in msi.py on license generation https://bugs.python.org/issue33711 closed by zach.ware #33805: dataclasses: replace() give poor error message if using InitVa https://bugs.python.org/issue33805 closed by eric.smith #33823: concurrent.futures: cannot specify the number of cores https://bugs.python.org/issue33823 closed by vstinner #33842: Remove tarfile.filemode https://bugs.python.org/issue33842 closed by inada.naoki #33851: 3.7 regression: ast.get_docstring() for a node that lacks a do https://bugs.python.org/issue33851 closed by ned.deily #33873: False positives when running leak tests with -R 1:1 https://bugs.python.org/issue33873 closed by vstinner #33877: Doc: Delete UNIX qualification for script running instructions https://bugs.python.org/issue33877 closed by adelfino #33885: doc Replace "hook function" with "callable" in urllib.request. https://bugs.python.org/issue33885 closed by terry.reedy #33887: doc Add TOC in Design and History FAQ https://bugs.python.org/issue33887 closed by Mariatta #33897: Add a restart option to logging.basicConfig() https://bugs.python.org/issue33897 closed by vinay.sajip #33913: test_multiprocessing_spawn random failures on x86 Windows7 3.6 https://bugs.python.org/issue33913 closed by vstinner #33914: test_gdb fails for Python 2.7.15 https://bugs.python.org/issue33914 closed by vstinner #33916: test_lzma: test_refleaks_in_decompressor___init__() leaks 100 https://bugs.python.org/issue33916 closed by vstinner #33929: test_multiprocessing_spawn: WithProcessesTestProcess.test_many https://bugs.python.org/issue33929 closed by vstinner #33933: Error message says dict has no len https://bugs.python.org/issue33933 closed by serhiy.storchaka #33938: Cross compilation fail for ARM https://bugs.python.org/issue33938 closed by n0s69z #33942: IDLE: Problems using IDLE and 2.7, 3.6 macOS 64-/32-bit instal https://bugs.python.org/issue33942 closed by ned.deily #33943: doc Add references to logging.basicConfig https://bugs.python.org/issue33943 closed by taleinat #33945: concurrent.futures ProcessPoolExecutor submit() blocks on resu https://bugs.python.org/issue33945 closed by dbarcay #33946: os.symlink on Windows should use the new non-admin flag https://bugs.python.org/issue33946 closed by eryksun #33950: IDLE htest: remove spec for deleted tabbedpages.py https://bugs.python.org/issue33950 closed by terry.reedy #33951: IDLE test failing only when called by itself: HighPageTest.tes https://bugs.python.org/issue33951 closed by terry.reedy #33952: doc Fix typo in str.upper() documentation https://bugs.python.org/issue33952 closed by adelfino #33956: update vendored expat to 2.2.5 https://bugs.python.org/issue33956 closed by benjamin.peterson #33957: use standard term than generic wording https://bugs.python.org/issue33957 closed by inada.naoki #33958: Unused variable in pure embedding example https://bugs.python.org/issue33958 closed by inada.naoki #33970: bugs.python.org silently refuses registrations https://bugs.python.org/issue33970 closed by Mariatta #33975: IDLE: adjust DPI before Tk() for htests. https://bugs.python.org/issue33975 closed by terry.reedy #33979: [Exception message] Display type of not JSON serializable obje https://bugs.python.org/issue33979 closed by serhiy.storchaka #33981: test_asyncio: test_sendfile_close_peer_in_the_middle_of_receiv https://bugs.python.org/issue33981 closed by vstinner #33985: ContextVar does not have a "name" attribute https://bugs.python.org/issue33985 closed by yselivanov #33992: Compilation fails on AMD64 Windows8.1 Non-Debug 3.6: The Windo https://bugs.python.org/issue33992 closed by zach.ware #33993: zipfile module weird behavior when used with zipinfo https://bugs.python.org/issue33993 closed by serhiy.storchaka #33999: `pip3 install past` does not work https://bugs.python.org/issue33999 closed by serhiy.storchaka

1 0

Python 3.7.0 is now available! (and so is 3.6.6)
by Ned Deily 29 Jun '18

29 Jun '18

On behalf of the Python development community and the Python 3.7 release team, we are pleased to announce the availability of Python 3.7.0. Python 3.7.0 is the newest feature release of the Python language, and it contains many new features and optimizations. You can find Python 3.7.0 here: https://www.python.org/downloads/release/python-370/ Most third-party distributors of Python should be making 3.7.0 packages available soon. See the "What’s New In Python 3.7" document (https://docs.python.org/3.7/whatsnew/3.7.html) for more information about features included in the 3.7 series. Detailed information about the changes made in 3.7.0 can be found in its change log. Maintenance releases for the 3.7 series will follow at regular intervals starting in July of 2018. We hope you enjoy Python 3.7! P.S. We are also happy to announce the availability of Python 3.6.6, the next maintenance release of Python 3.6: https://www.python.org/downloads/release/python-366/ Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organization contributions to the Python Software Foundation. https://www.python.org/psf/ -- Ned Deily nad(a)python.org -- []

3 2