[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly

Antoine Pitrou added the comment: Oscar, the patch posted here needs updating for the latest git master. If you want to avoid this issue, you can also use concurrent.futures where the issue is fixed. -- stage: -> needs patch versions: +Python 3.8 -Python 3.5

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Benjamin Peterson added the comment: The stdlib is a bad place for anything that needs to evolve at a non-glacial place. For example, even when 2to3 had not yet fallen out of favor, there were effectively 3 versions of it: one 2.7 and two in maintained 3.x branches. That

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Change by Łukasz Langa : -- keywords: +patch pull_requests: +6285 stage: -> patch review ___ Python tracker ___

[issue33317] `repr()` of string in NFC and NFD forms does not differ

Benjamin Peterson added the comment: As stated, the bug report is invalid: the repr _does_ differ, it's just not presented that way by however you're viewing the two reprs. Distinct codepoint sequences that look identical under certain circumstances can happen many

[issue22393] multiprocessing.Pool shouldn't hang forever if a worker process dies unexpectedly

Oscar Esteban added the comment: We use multiprocessing to parallelize many tasks that run either python code or call subprocess.run that are memory hungry. At times the OOM Killer kicks in. When one of the workers is killed, the queue never returns an error for the

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Nathaniel Smith added the comment: It does seem like it'd be unfortunate to end up in a situation like "sorry, there's a bug in handling this python 2 code, so black won't be able to reformat it until the next major python release". And I assume this issue is motivated by

[issue31500] IDLE: Tiny font on HiDPI display

Change by Cheryl Sabella : -- pull_requests: +6284 stage: needs patch -> patch review ___ Python tracker ___

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Łukasz Langa added the comment: > But lib2to3 is proof that the stdlib is just as much subject to stalling. The issue here is internal visibility. "lib2to3" is a library that supports "2to3" which is rather neglected internally since we started promoting `six` as a better

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Guido van Rossum added the comment: But lib2to3 is proof that the stdlib is just as much subject to stalling. Maybe lib2to3 and pgen2 would have a livelier future if they weren't limited to updates in sync with Python releases. --

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Łukasz Langa added the comment: > The important part is that it is maintained and kept up to date with future > language grammar changes while maintaining "backwards grammar compatibility". Yes, which is why I have trouble believing this can be effectively outsourced.

[issue33251] ConfigParser.items returns items present in vars

Łukasz Langa added the comment: New changeset e500839796c7fa43998e72edb77165872b9ce034 by Łukasz Langa (Chris Bradbury) in branch 'master': bpo-33251: Update documentation to reflect change. (GH-6446) (#6583)

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Gregory P. Smith added the comment: +1 in general to this work. Łukasz is effectively preaching to the choir by looping me in here. :) It is a big challenge to practically support Python in that we have no good ability to parse and understand all language syntax versions via

[issue33329] sigaddset() can fail on some signal numbers

Miro Hrončok added the comment: Antoine, thank you very much for swift communication and fix. -- ___ Python tracker ___

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: Miro, this should be fixed now. Please reopen if it isn't. The sigfillset() functionality will be exposed to Python users in bpo-2. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: New changeset b0ca398cabd2d2ea2d66fa50b08e297a60388c75 by Antoine Pitrou in branch '3.6': [3.6] bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575) (GH-6582)

[issue33251] ConfigParser.items returns items present in vars

Change by Chris Bradbury : -- pull_requests: +6283 ___ Python tracker ___ ___

[issue33329] sigaddset() can fail on some signal numbers

Change by Antoine Pitrou : -- pull_requests: +6282 ___ Python tracker ___ ___

[issue33329] sigaddset() can fail on some signal numbers

Change by Antoine Pitrou : -- nosy: +njs ___ Python tracker ___ ___ Python-bugs-list mailing

[issue33332] Expose valid signal set (sigfillset())

Change by Antoine Pitrou : -- keywords: +patch pull_requests: +6281 stage: needs patch -> patch review ___ Python tracker ___

[issue33332] Expose valid signal set (sigfillset())

Change by Antoine Pitrou : -- nosy: +njs ___ Python tracker ___ ___ Python-bugs-list mailing

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: New changeset 75a3e3d5bc0be1ce41289b661e7c53039cf3d5ba by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575) (GH-6579)

[issue33251] ConfigParser.items returns items present in vars

Łukasz Langa added the comment: New changeset 1d4a733cceee237f0850b7887c2945dee707da27 by Łukasz Langa (Chris Bradbury) in branch 'master': bpo-33251: Prevent ConfigParser.items returning items present in vars. (#6446)

[issue33329] sigaddset() can fail on some signal numbers

Change by miss-islington : -- pull_requests: +6280 ___ Python tracker ___

[issue33329] sigaddset() can fail on some signal numbers

Change by miss-islington : -- pull_requests: +6279 ___ Python tracker ___

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: New changeset 25038ecfb665bef641abf8cb61afff7505b0e008 by Antoine Pitrou in branch 'master': bpo-33329: Fix multiprocessing regression on newer glibcs (GH-6575) https://github.com/python/cpython/commit/25038ecfb665bef641abf8cb61afff7505b0e008

[issue33343] Subcommand abbreviations

New submission from Victor Porton : https://docs.python.org/3/library/argparse.html does not allow abbreviations for subparsers ("subcommands"). It seems inconsistent that long options can be abbreviated but subcommands cannot. Either implement subcommand abbreviations or

[issue33289] tkinter askcolor returning floats for r, g, b values instead of ints

Change by Cheryl Sabella : -- keywords: +patch pull_requests: +6278 stage: needs patch -> patch review ___ Python tracker ___

[issue33316] PyThread_release_lock always fails

Steve Dower added the comment: Looks okay, but I wonder whether the implementation of PyMUTEX_UNLOCK should return something other than zero? What is it meant to return? -- ___ Python tracker

[issue33329] sigaddset() can fail on some signal numbers

Change by Antoine Pitrou : -- nosy: +neologix ___ Python tracker ___ ___ Python-bugs-list

[issue33315] Allow queue.Queue to be used in type annotations

Guido van Rossum added the comment: Could you please product a draft PR showing how that would work? It might not be accepted right away but it would be useful to have. On Mon, Apr 23, 2018, 05:29 Semyon Proshev wrote: > > Semyon Proshev

[issue33342] urllib IPv6 parsing fails with special characters in passwords

Change by benaryorg : -- type: -> behavior ___ Python tracker ___ ___ Python-bugs-list

[issue33342] urllib IPv6 parsing fails with special characters in passwords

New submission from benaryorg : The documentation specifies to follow RFC 2396 (https://tools.ietf.org/html/rfc2396.html) but fails to parse a user:password@host url in urllib.parse.urlsplit (https://docs.python.org/3/library/urllib.parse.html#urllib.parse.urlsplit) when

[issue33329] sigaddset() can fail on some signal numbers

Adhemerval Zanella added the comment: What I mean is for master glibc, which contains BZ#22391, 'sigaddset' will fail do add signal 32 and 33. But since you are now ignoring 'sigaddset' return code, it does not matter. -- ___

[issue31500] IDLE: Tiny font on HiDPI display

Serhiy Storchaka added the comment: You promised to make backports to 2.7 when did the mass files renaming. The simple cherry-picking doesn't work, and I even don't know what files in 2.7 should be changed. -- ___

[issue25478] Consider adding a normalize() method to collections.Counter()

Serhiy Storchaka added the comment: Was __rtruediv__ discussed before? What is the use case for it? Besides __rtruediv__ all LGTM. -- nosy: +serhiy.storchaka ___ Python tracker

[issue31500] IDLE: Tiny font on HiDPI display

Terry J. Reedy added the comment: I guess I was not clear enough that I will test on Windows after someone else does a backport that works on Linux. -- ___ Python tracker

[issue33315] Allow queue.Queue to be used in type annotations

Semyon Proshev added the comment: I had been thinking about `__class_getitem__` when the issue were created. I suspected it's not difficult to implement and it follows PEP 560. So I'm +1 for `__class_item__`, quotes and postponed evaluation are also ok. --

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: Not sure what you mean. In the example above, I try to block signals 32 and 33 using pthread_sigmask(), but the pthread_sigmask() return value shows they weren't blocked, which is ok. -- ___

[issue33329] sigaddset() can fail on some signal numbers

Adhemerval Zanella added the comment: Yes, this is the issue I referred in previous comment [1]. Unfortunately it is only fixed on master (which will become 2.28). [1] https://sourceware.org/bugzilla/show_bug.cgi?id=22391 -- ___

[issue30750] Update `make patchcheck` to understand Misc/NEWS.d

Change by Antoine Pitrou : -- pull_requests: +6277 ___ Python tracker ___ ___

[issue33329] sigaddset() can fail on some signal numbers

Change by Antoine Pitrou : -- keywords: +patch pull_requests: +6276 stage: needs patch -> patch review ___ Python tracker ___

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: Right, but it seems that even if sigaddset() allowed you to "set" signals 32 and 33, that would be ignored by pthread_sigmask(). This is what I get here (Ubuntu 16.04, glibc 2.23): >>> signal.pthread_sigmask(signal.SIG_BLOCK, range(1, 65))

[issue33329] sigaddset() can fail on some signal numbers

Adhemerval Zanella added the comment: Yes I am aware, but I can't see a really portable way to provide the same functionality as 'sigfillset'. Ideally a libc implementation would return EINVAL on 'sigaddset' for invalid signals, but even for glibc this is not true (the

[issue33340] Inaccurate docs on `import` behaviour

Eric V. Smith added the comment: If you have a suggested improvement, please create a pull request. Thanks! -- ___ Python tracker

[issue33340] Inaccurate docs on `import` behaviour

sam_b added the comment: Thanks, I thought it might be something like that. Would it be worth clarifying the distinction in the docs? It was certainly surprising to me that `import time` and `import logging` behave differently. --

[issue33341] python3 fails to build if directory or sysroot contains "*icc*" string

New submission from Gianfranco : Hello, as said, in yocto we pass in $CC environment, also the --sysroot keyword. If --sysroot contains the "*icc*" or "*gcc*" in path, the build fails because of wrong autoconf checks. checking in a case switch for *icc* seems

[issue33340] Inaccurate docs on `import` behaviour

Eric V. Smith added the comment: "built-in modules" has the specific meaning of modules that are compiled in to the python executable. It doesn't mean modules in the standard library. See https://docs.python.org/3.6/library/sys.html#sys.builtin_module_names Python 3.6.4

[issue33329] sigaddset() can fail on some signal numbers

Antoine Pitrou added the comment: I don't think we want to be in the business of maintaining a list of cross-platform of supported signal values. Python may be compiled on bizarre non-glibc systems (or even systems with a proprietary libc). --

[issue33340] Inaccurate docs on `import` behaviour

New submission from sam_b : The docs https://docs.python.org/3/tutorial/modules.html#the-module-search-path describe: > When a module named spam is imported, the interpreter first searches for a > built-in module with that name. If not found, it then searches for a file >

[issue33339] Using default encoding with `subprocess.run()` is not obvious

New submission from Pekka Klärck : It is possible to use `subprocess.run()` with the system's default encoding by using `universal_newlines=True`. This is very handy, but it's not at all obvious (at least for me) that setting such option has effect on encoding. This is

[issue33319] `subprocess.run` documentation doesn't tell is using `stdout=PIPE` safe

Pekka Klärck added the comment: My goal is to read stdout. It's good to hear `subprocess.run()` is deadlock-safe and I can use it safely. Making the docs explicit about it so that others know it's safe would in my opinion be a good idea as well. Casual users don't

[issue33338] [lib2to3] Synchronize token.py and tokenize.py with the standard library

Łukasz Langa added the comment: New changeset c2d384dbd7c6ed9bdfaac45f05b463263c743ee7 by Łukasz Langa in branch 'master': bpo-8: [tokenize] Minor code cleanup (#6573) https://github.com/python/cpython/commit/c2d384dbd7c6ed9bdfaac45f05b463263c743ee7 --

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Łukasz Langa added the comment: > These modification are applied only before bytecodecode generation. The AST > presented to user is not modified. This bit me when implementing PEP 563 but I was then on the compile path, right. Still, the latest docstring folding would

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Łukasz Langa added the comment: > I'm in favor of unifying the tokenizers and of updating and moving pgen2 > (though I don't have time to do the work). I'm willing to do all the work as long as I have somebody to review it. Case in point: BPO-8. > Also I think you may

[issue33337] Provide a supported Concrete Syntax Tree implementation in the standard library

Serhiy Storchaka added the comment: > - the built-in AST increasingly modifies the tree before presenting it to user > code (constant folding moved to the AST in Python 3.7); These modification are applied only before bytecodecode generation. The AST presented