[issue36778] test_site.StartupImportTests.test_startup_imports fails if default code page is cp65001

Paul Monson added the comment: cp65001 is the default codepage on Windows IoT Core and Windows NanoServer. There is also an option in control panel in Windows desktop 1809 (version 17763) and greater which changes the default codepage to cp65001. 1. Run control.exe 2. Click Clock and

[issue36778] test_site.StartupImportTests.test_startup_imports fails if default code page is cp65001

Change by Paul Monson : -- pull_requests: +13122 ___ Python tracker <https://bugs.python.org/issue36778> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36778] test_site.StartupImportTests.test_startup_imports fails if default code page is cp65001

Paul Monson added the comment: Removing import functools from cp65001.py fixes test_startup_imports. Victor proposed this PR: https://github.com/python/cpython/pull/13110 but new test_codecs fails because it's passing self on to the lambda I think. I tried to build on Victor's

[issue36778] test_site.StartupImportTests.test_startup_imports fails if default code page is cp65001

Paul Monson added the comment: I can verify that PR 13110 fixes the issue with test_startup_imports on Windows IoT Core ARM32 -- ___ Python tracker <https://bugs.python.org/issue36

[issue36778] test_site.StartupImportTests.test_startup_imports fails if default code page is cp65001

Paul Monson added the comment: Sorry that was supposed to say: I can verify that PR 13230 fixes the issue with test_startup_imports on Windows IoT Core ARM32 -- ___ Python tracker <https://bugs.python.org/issue36

[issue36778] test_site.StartupImportTests.test_startup_imports fails if default code page is cp65001

Paul Monson added the comment: Thanks Victor! Since we aren't backporting ARM32 changes, I don't think it's important to fix this test in 3.7. I am trying to get the buildbot tests for Windows ARM32 to zero errors. Windows IoT Core runs on Raspberry Pi and similar

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

paul j3 added the comment: At the start of parse_known_args, all defaults (except SUPPRESS ones) are placed in the namespace: # add any action defaults that aren't present for action in self._actions: if action.dest is not SUPPRESS: if not ha

[issue13824] argparse.FileType opens a file and never closes it

paul j3 added the comment: While I continue to follow argparse issues, I'm not doing development (with my own repository, etc). I haven't revisited the issue since 2013, and don't know that much more about Python file handling. Occasionally 'FileType' issues

[issue9351] argparse set_defaults on subcommands should override top level set_defaults

paul j3 added the comment: A variation on the problem I reported in https://bugs.python.org/issue9351#msg229968 is that a custom Namespace class as documented in https://docs.python.org/3/library/argparse.html#the-namespace-object will not be used by the subparsers. Only the main parser

[issue35495] argparse does not honor default argument for nargs=argparse.REMAINDER argument

paul j3 added the comment: Let me back off on that last suggestion. The problems described here and in https://bugs.python.org/issue17050 only apply to a positional. We could just add a note to the documentation to the effect. This nargs is best used as an optional as illustrated

[issue36783] No documentation for _FromXandFold C API functions

Paul Ganssle added the comment: @Stéphane The reason this issue was closed before PR 13204 was merged is that PR 13147 was merged a bit prematurely due to a miscommunication, which is why Cheryl closed the issue. I was going to re-open it after we realized what happened, but since we were at

[issue36511] Add Windows ARM32 buildbot

Change by Paul Monson : -- pull_requests: +13262 stage: commit review -> patch review ___ Python tracker <https://bugs.python.org/issue36511> ___ ___ Python-

[issue36564] Infinite loop with short maximum line lengths in EmailPolicy

Change by Paul Ganssle : -- nosy: +maxking, msapiro ___ Python tracker <https://bugs.python.org/issue36564> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36941] Windows build changes for Windows ARM64

New submission from Paul Monson : Add build file changes for Windows ARM64 -- components: Build, Windows messages: 342672 nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows build changes for Windows ARM64 type

[issue36942] Windows code changes for Windows ARM64

New submission from Paul Monson : Add ifdef changes for Windows ARM64 -- components: Windows messages: 342673 nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows code changes for Windows ARM64 type: enhancement

[issue36943] Windows test changes for Windows ARM64

New submission from Paul Monson : Add Windows test changes for Windows ARM64 -- components: Windows messages: 342674 nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Windows test changes for Windows ARM64 versions

[issue36944] W

Change by Paul Monson : -- nosy: Paul Monson priority: normal severity: normal status: open title: W ___ Python tracker <https://bugs.python.org/issue36

[issue36944] Add support for ARM64 to libffi

New submission from Paul Monson : These changes are also submitted to libffi as https://github.com/libffi/libffi/pull/490 -- components: +Windows nosy: +paul.moore, steve.dower, tim.golden, zach.ware title: W -> Add support for ARM64 to libffi versions: +Python

[issue36941] Windows build changes for Windows ARM64

Change by Paul Monson : -- keywords: +patch pull_requests: +13275 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36941> ___ ___ Py

[issue36942] Windows code changes for Windows ARM64

Change by Paul Monson : -- keywords: +patch pull_requests: +13276 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36942> ___ ___ Py

[issue36943] Windows test changes for Windows ARM64

Change by Paul Monson : -- keywords: +patch pull_requests: +13277 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue36943> ___ ___ Py

[issue17972] inspect module docs omits many functions

Paul Rudin added the comment: Although formatannotation is undocumented, its actually documented as a default value for one of the parameters of formatargspec, so it does form part of the module's public interface. However formatargspec is deprecated, so it's still OK to

[issue32553] venv says to use python3 which does not exist in 3.6.4

New submission from Paul Watson : The 3.6.4 documentation on venv specifies using 'python3', but no python3 executable is in the 3.6.4 kit. https://docs.python.org/3/library/venv.html?highlight=venv#module-venv -- assignee: docs@python components: Documentation messages: 3

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Watson added the comment: I am running 3.6.4 from a download on pythong.org yesterday. Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32 There is a python3.dll, but no python3 executable. -- ___ Python

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Moore added the comment: Actually, for Windows, the docs don't recommend "python3", they say: """ On Windows, invoke the venv command as follows: c:\>c:\Python35\python -m venv c:\path\to\myenv """ This should probably be altered to sa

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Watson added the comment: Ok, I do find later on where it says to do something different on Windows. However, the first "Note" box in "28.3. venv" specifies using "python3". It does not say that this is for non-Windows systems. This should be changed.

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Moore added the comment: That's why I suggest using the launcher rather than absolute paths - there are far too many variations to enumerate with absolue paths (you didn't mention per-user Python 3.6 installations, for example). If you have a suggested wording that you

[issue32553] venv says to use python3 which does not exist in 3.6.4

Paul Moore added the comment: Agreed, the docs don't need to mention PATHEXT. I don't have a machine to hand with Python 3.6 not installed, to check, but I believe the launcher is installed by default (although as you say it can be deselected - and it's definitely described

[issue9334] argparse does not accept options taking arguments beginning with dash (regression from optparse)

paul j3 added the comment: I attached a script that implements Evan's _match_argument idea, using a ArgumentParser subclass. I think this is the safest way to add different functionality to the parser. It (subclassing) is used, for example in pypi extensions like plac. My version p

[issue10381] Add timezone support to datetime C API

Change by Paul Ganssle : -- pull_requests: +5163 stage: resolved -> patch review ___ Python tracker <https://bugs.python.org/issue10381> ___ ___ Python-bugs-lis

[issue10381] Add timezone support to datetime C API

Change by Paul Ganssle : -- pull_requests: +5164 ___ Python tracker <https://bugs.python.org/issue10381> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25330] Docs for pkgutil.get_data inconsistent with semantics

Paul Ganssle added the comment: I'm not sure if this warrants a separate issue, but I also notice this in the documentation: > If the package cannot be located or loaded, or it uses a loader which does > not support get_data, then None is returned. In particular, the loader for

[issue32752] no information about accessing typing.Generic type arguments

New submission from Paul Pinterits : The documentation of the typing module explains how to instantiate generic types, but there is no information about how to extract the type arguments from a generic type. Example: >>> list_of_ints = typing.List[int] >>> >>&

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Change by Paul Ganssle : -- pull_requests: +5380, 5381 ___ Python tracker <https://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Change by Paul Ganssle : -- pull_requests: +5380 ___ Python tracker <https://bugs.python.org/issue15873> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32779] urljoining an empty query string doesn't clear query string

New submission from Paul Fisher : urljoining with '?' will not clear a query string: ACTUAL: >>> import urllib.parse >>> urllib.parse.urljoin('http://a/b/c?d=e', '?') 'http://a/b/c?d=e' EXPECTED: 'http://a/b/c' (optionally

[issue32779] urljoining an empty query string doesn't clear query string

Paul Fisher added the comment: I'm working on a patch for this and can have one up in the next week or so, once I get the CLA signed and other boxes ticked. I'm new to the Github process but hopefully it will be a good start for the

[issue32833] argparse doesn't recognise two option aliases as equal

Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue32833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

Change by paul j3 : -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue32756> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue32833] argparse doesn't recognise two option aliases as equal

paul j3 added the comment: Subparsers have aliases, argument option strings don't, at least not formally. Once an argument is added, its flags are entered in several lists. One list belongs to the Action itself, another belongs to the parser (it might actually be a dictionary). The

[issue32833] argparse doesn't recognise two option aliases as equal

paul j3 added the comment: When I run your setup in ipython, I see a display of the newly added Action: Out[2]: _StoreAction(option_strings=['--a-b', '--ab'], dest='a_b', nargs=None, const=None, default=None, type=None, choices=None, help=Non

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

paul j3 added the comment: This error message is intentional. In def consume_optional(start_index): # identify additional optionals in the same arg string # (e.g. -xyz is the same as -x -y -z if no args are required) # if the action is a

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

paul j3 added the comment: Try adding a simple positional argument. '-ab' would still produce this error. -- ___ Python tracker <https://bugs.python.o

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: This is another expression of the bigger problem of handling arguments that look like flags. In optparse the 'nargs' (or equivalent, it doesn't handle positionals), control how many arguments an Option takes, regardless of their form. In argparse,

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: Oops, I see I already mentioned 9334. Here the parsing sequence is a bit different, and the fix I suggest there would not apply here. But the underlying issue is still there - the parser has, in its first iteration, determined that the '--def' loo

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: REMAINDER is not widely used, and probably was not tested thoroughly during development. It works for the example given in the docs. A variant, argparse.PARSER ('A...') is widely used. This is, effectively, REMAINDER ('...') that requires an

[issue32779] urljoining an empty query string doesn't clear query string

Paul Fisher added the comment: In this case, the RFC is mismatched from the actual behaviour of browsers (as described and codified by WhatWG). It was surprising to me that urljoin() didn't do what I percieved as "the right thing" (and I expect other users would too). I w

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: A REMAINDER that would work with a flag-like string would be too powerful, too greedy. In [64]: p = argparse.ArgumentParser(); In [65]: p.add_argument('--foo'); In [66]: p.add_argument('rest', nargs='...'); If the f

[issue32889] Valgrind suppressions need updating

New submission from Paul Price : Using the current valgrind suppressions (Misc/valgrind-python.supp) results in a lot of noise, e.g.: ==2662549== Conditional jump or move depends on uninitialised value(s) ==2662549==at 0x4EFD734: address_in_range (obmalloc.c:1200) ==2662549==by

[issue32910] venv: Deactivate.ps1 is not created when Activate.ps1 was used

Paul Moore added the comment: As noted in the related issue that you link to, there is not meant to be a deactivate.ps1 script - the deactivate command is provided via a global deactivate function created when you run activate.ps1 (although this is an implementation detail, all that matters

[issue32403] date, time and datetime alternate constructors should take fast construction path

Change by Paul Ganssle : -- pull_requests: +5589 ___ Python tracker <https://bugs.python.org/issue32403> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10381] Add timezone support to datetime C API

Change by Paul Ganssle : -- pull_requests: +5588 ___ Python tracker <https://bugs.python.org/issue10381> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

Paul Ganssle added the comment: adamwill: I think datetime's strftime is a wrapper around the system strftime, so it varies between platforms. Might be useful to specify which platform you are seeing this behavior on. -- nosy: +p-ga

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

Paul Ganssle added the comment: It seems that %s is not supported and the fact that it works at all is incidental. See issue 12750 and this SO thread: https://stackoverflow.com/questions/11743019/convert-python-datetime-to-epoch-with-strftime

[issue32988] datetime.datetime.strftime('%s') always uses local timezone, even with aware datetimes

Paul Ganssle added the comment: I suspect discussion should be centralized in issue 12750, but if it were up to me %s would either work as expected or throw an error. Silently giving the wrong answer is a terrible compromise. -- ___ Python tracker

[issue33069] Maintainer information discarded when writing PKG-INFO

New submission from Paul Ganssle : This is basically the same as issue 962772, as there seems to have been a regression. The current version of distutils discards author= metadata if maintainer= is present, even though PEP 345 has added the Maintainer: and Maintainer-Email: metadata fields

[issue33071] Document that PyPI no longer requires 'register'

New submission from Paul Ganssle : I've been asked to post this by @brainwave (who is having some trouble getting an account on bpo due to technical difficulties). Per twine's github issue 311 ( https://github.com/pypa/twine/issues/311 ), it seems that distutil's docs Update

[issue33069] Maintainer information discarded when writing PKG-INFO

Change by Paul Ganssle : -- keywords: +patch pull_requests: +5869 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue33069> ___ ___ Py

[issue33069] Maintainer information discarded when writing PKG-INFO

Paul Ganssle added the comment: @ncoghlan Yes, setuptools is affected. I've reported it there as well: https://github.com/pypa/setuptools/issues/1288 I have patches for both distutils and setuptools prepared. The distutils patch is more controversial because this is apparently the docum

[issue33069] Maintainer information discarded when writing PKG-INFO

Paul Ganssle added the comment: One thing that's unclear to me is whether PKG-INFO metadata spec should be considered exhaustive or whether you can add additional fields and still be considered compliant with the spec. If the latter is true, I think there's some case to b

[issue33069] Maintainer information discarded when writing PKG-INFO

Paul Ganssle added the comment: I've fixed this in setuptools ( PR here: https://github.com/pypa/setuptools/pull/1294 ). Should we leave this open to track distutils upgrading to support all of PEP 345, or close this with "distutils will never support > 1.1". If the l

[issue32867] argparse assertion failure with multiline metavars

paul j3 added the comment: I haven't seen anyone try to use \n in a metavar before, but other special characters like [] and () produce this assertion error. At this point the code is trying split the usage into 2 or more lines, because it's too long for one. It creates a

[issue32756] argparse: parse_known_args: raising exception on unknown arg following known one

paul j3 added the comment: >From the documentation, 16.4.4.1. Option value syntax > For short options (options only one character long), the option and its value > can be concatenated: > Several short options can be joined together, using only a single - prefix, > as long a

[issue28247] Add an option to zipapp to produce a Windows executable

Paul Moore added the comment: Hi Cheryl, Looks like I dropped the ball on this one :-( I think it just needs to be applied to the main branch (3.7/3.8) - I don't think it's worth backporting. I'll try to get to it when I can, but it may not be for a few weeks, as I have ot

[issue33069] Maintainer information discarded when writing PKG-INFO

Paul Ganssle added the comment: > Donald made an interesting suggestion over on > https://github.com/pypa/packaging-problems/issues/127#issuecomment-374401331, > which was to have distutils stop overwriting the Author metadata with the > Maintainer metadata when both are s

[issue28247] Add an option to zipapp to produce a Windows executable

Paul Moore added the comment: New changeset 4be79f29463f632cd8b48486feadc2ed308fb520 by Paul Moore (Cheryl Sabella) in branch 'master': bpo-28247: Document Windows executable creation in zipapp (GH-6158) https://github.com/python/cpython/commit/4be79f29463f632cd8b48486feadc2

[issue33147] Update references for RFC 3548 to RFC 4648

New submission from Paul Hoffman : serhiy-storchaka asked me to open an issue about whether Python implements RFC 4648. As far as I can tell it does, correctly, for the parts of RFC 4648 covered in the doc. My PR was about simply updating a reference to an RFC that was made obsolete

[issue33147] Update references for RFC 3548 to RFC 4648

Paul Hoffman added the comment: I signed the contributor agreement form on 2017-06-23 -- ___ Python tracker <https://bugs.python.org/issue33147> ___ ___ Pytho

[issue33131] Upgrade to pip 10 for Python 3.7

Paul Moore added the comment: Pip 10 has now been released. I'll be getting a PR to put it into 3.7 in the next few days. One question on workflow - is the right approach to create a PR for master and request a backport to the 3.7 branch? Or is there something else I should do? Also,

[issue33131] Upgrade to pip 10 for Python 3.7

Paul Moore added the comment: Thanks Nick, that's what I thought for the workflow. And agreed with your understanding of the post-b4 question, but as you say Ned's the boss on that one :-) -- ___ Python tracker <https://bugs.python.o

[issue33285] pip upgrade runtime crash

Paul Moore added the comment: Issues with pip should be reported at https://github.com/pypa/pip/issues rather than here. However, in this case, the issue is that you ran the command "pip install --upgrade pip" which will use the pip executable to upgrade itself, something that Wind

[issue33131] Upgrade to pip 10 for Python 3.7

Change by Paul Moore : -- keywords: +patch pull_requests: +6243 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issue33131> ___ _

[issue33131] Upgrade to pip 10 for Python 3.7

Paul Moore added the comment: New changeset 0399cf9b5e370516e3d0aed6a63ff74aff5eadb5 by Paul Moore in branch 'master': bpo-33131: Upgrade ensurepip to bundle pip 10.0.1 (GH-6546) https://github.com/python/cpython/commit/0399cf9b5e370516e3d0aed6a63ff7

[issue28602] `tzinfo.fromutc()` fails when used for a fold-aware tzinfo implementation

Change by Paul Ganssle : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue28602> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33343] [argparse] Add subcommand abbreviations

paul j3 added the comment: This issue was raised in https://bugs.python.org/issue12713, argparse: allow abbreviation of sub commands by users A patch was implemented, and then reverted when it was found to be buggy. Subcommands are not parsed the same as long options. Subcommands are

[issue32552] Improve text for file arguments in argparse.ArgumentDefaultsHelpFormatter class

paul j3 added the comment: This subclass makes are one method change: from: def _get_help_string(self, action): return action.help to: def _get_help_string(self, action): help = action.help if '%(default)' not in action.help: if action.

[issue17050] argparse.REMAINDER doesn't work as first argument

paul j3 added the comment: Since this feature is buggy, and there isn't an easy fix, we should probably remove any mention of it from the docs. We can still leave it as an undocumented legacy feature. There is precedent for leaving `nargs` constants undocumented. `argparse.P

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: I've confirmed this issue on Windows. Attached is an SSCCE which seems to reliably reproduce the issue in a Windows environment. Long story short: if a KeyboardInterrupt occurs during Thread.join(), there's a good chance that Thread._is_stopped neve

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Not sure if I'll do the full fix (need to check w/ my employer), but I'm doing some investigation. Here's what I know so far: At the Python level, the KeyboardInterrupt is being raised within _wait_for_tstate_lock, on "elif lock.acquire(bloc

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: As I noted on python-ideas, continuing to search along sys.path if the loader returns None seems to match what the linecache docs say. If the issue had been phrased as "the implementation of linecache doesn't follow the docs" then I'd

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: >> IMO, debating whether a None return means there's absolutely no chance of >> there being source is silly - the best the loader can say is that it can't >> provide source. > > I don't think it is silly: if "None"

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Focusing on the Windows case specifically... One way to possibly make this work (although perhaps not as clean as may be desired) would be to add polling logic into the thread_nt.h version of PyThread_acquire_lock_timed. That would have the benefit of avoiding

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: > I think adding polling to such a widely-used primitive is out of question. I'm guessing this is because of the perceived performance impact? (That's the main thought I have against polling in this case.) Or is it something else? I can cert

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Ahh, thanks for the explanation. I didn't think about that. Let's *not* do that then. :) I'll see if I can squeeze in some time to play with the alternatives. -- ___ Python tracker <https

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: > How does CPython display the source for tracebacks in Cython modules? It > seems to work there as long as the Cython .pyx files are somewhere in the > import path. Is that in Python 3.x? The issue we're discussing is only

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: That's interesting. It sounds like linecache might be working differently then. -- ___ Python tracker <https://bugs.python.org/is

[issue33400] logging.Formatter does not default to ISO8601 date format

New submission from Paul Cyr : >From the docs: https://docs.python.org/3.6/library/logging.html#logging.Formatter "class logging.Formatter(fmt=None, datefmt=None, style='%') ... If no datefmt is specified, the ISO8601 date format is used." However, the output fro

[issue33400] logging.Formatter does not default to ISO8601 date format

Paul Ganssle added the comment: ISO 8601 does not require an offset (in fact, most portions of the ISO 8601 date and time are optional - ISO 8601 is more complicated than most people think). Without an offset a datetime is assumed to be local time. The T delimiter is required, but can be

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Okay, I think I need to abandon my research into this. This does seem to have quite an amount of complexity to it and is probably more than I should be taking on at this point in time. Anyone else who wants to look at this, consider it fair game. Parting

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins added the comment: Good point, I forgot about WaitForMultipleObjectsEx; something like that seems like it would be much simpler for the first 2 cases. -- ___ Python tracker <https://bugs.python.org/issue21

[issue22848] Subparser help does not respect SUPPRESS argument

paul j3 added the comment: I've reviewed the comments and proposed patch, and still think that the custom metavar is still the best fix. subparses.metavar can be changed after subparsers has been created. The programmer could, for example, write a simple helper function that

[issue33389] argparse redundant help string

paul j3 added the comment: This is normal behavior for argparse. People have asked before for a more compact display. I remember suggesting changes to the HelpFormatter subclass on Stackoverflow questions, and there's probably one or more bug/issues addressing the same

[issue33415] When add_mutually_exclusive_group is built without argument, the help breaks with "IndexError: list index out of range"

paul j3 added the comment: The usage formatter is brittle, especially the part that adds mutually exclusive markings to the normal usage string. I don't think I've seen this error before, but I'm not surprised. A real fix requires a rewrite of the usage formatter, which I&

[issue33389] argparse redundant help string

paul j3 added the comment: https://bugs.python.org/issue29626 Issue with spacing in argparse module while using help This deals with a extra space that is produced when a blank metavar is used to produce a more compact help line -s , --service help text My answers have links to

[issue33389] argparse redundant help string

paul j3 added the comment: Also https://bugs.python.org/issue27303 [argparse] Unify options in help output -- ___ Python tracker <https://bugs.python.org/issue33

[issue22848] Subparser help does not respect SUPPRESS argument

paul j3 added the comment: I've attached a file that tries out the idea of building a custom `metavar` in the `add_parser` method. It subclasses argparse._SubParsersAction, and registers it with the parser. No other modification to production code is required. Subparsers with a blank

[issue33355] Windows 10 buildbot: 15 min timeout on test_mmap.test_large_filesize()

Paul Goins added the comment: For what it's worth as a newbie here, I'll add my 2 cents. (This is partially copied from my mail on python-dev.) The one thing which I did notice between the last builds which passed and the current builds is, under the "10 slowest tests"

[issue33494] random.choices ought to check that cumulative weights are in ascending order

Paul Moore added the comment: Supplying cum_weights allows the code to use bisection to locate the correct value to return. This is O(log n), and is significantly faster for large populations than supplying weights (which need to be totalled for the calculation). Requiring a pre-check on

[issue33400] logging.Formatter does not default to ISO8601 date format

Paul Ganssle added the comment: I don't really agree with these changes to the documentation. The format that paulc identifies is actually an RFC 3339 datetime, which is a subset of ISO 8601, to the extent that you consider the fact that "we're using RFC 3339" is

[issue33494] random.choices ought to check that cumulative weights are in ascending order

Paul Czyzewski added the comment: btw, this was my suggestion. Steven opened the issue on my behalf (I'm new). 1) Documentation change. I would suggest that, to this paragraph: "If neither weights nor cum_weights are specified, selections are made with equal probability. If

<    10   11   12   13   14   15   16   17   18   19   >