[issue34479] ArgumentParser subparser error display at the wrong level

paul j3 added the comment: Errors that are associated with a specific argument, such as a wrong 'type' do get usage from the appropriate subparser. e.g. In [164]: p.parse_args('--foo 1 cmd1 --bar x'.split()) usage: ipython3 cmd1 [-h] [--bar BAR] ipython3 cmd1: error: argument --bar

[issue34479] ArgumentParser subparser error display at the wrong level

paul j3 added the comment: The subparser is called with `parse_known_args` which just puts unknown args in a _UNRECOGNIZED_ARGS_ATTR attribute slot in the namespace, which is then passed back to the main parser. (this occurs in _SubParsersAction.__call__) If `parser.parse_known_args

[issue34536] Enum._missing_ doesn't raise TypeError when a non-Enum object is a returned

New submission from Paul Pinterits : In a conversation with Ethan Furman (the author of the enum module) I've been informed that Enum automatically checks whether the _missing_ method has returned an instance of the correct class, and raises a TypeError if not. (Link: https

[issue34535] queue.Queue(timeout=0.001) avg delay Windows:14.5ms, Ubuntu: 0.063ms

New submission from Paul Overing : I have found that using timeout with a python queue.Queue() results in an average delay of 14.5ms in Windows over Ubuntu in python 3.6.5/3.7, I subtracted the 1 ms timeout. I have also tried datetime.datetime.now() to measure the time, with similar

[issue34482] datetime: Tests for potential crashes due to non-UTF-8-encodable strings

Paul Ganssle added the comment: Somewhat related: #6697. Turns out there are already some tests here for this, specifically for the C version only: https://github.com/python/cpython/blob/master/Lib/test/datetimetester.py#L3328 -- ___ Python

[issue34454] datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure

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

[issue30717] Add unicode grapheme cluster break algorithm

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue30717> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34481] Different behavior of C and Python impls of datetime.strftime with non-UTF-8-encodable strings

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue34481> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34423] Overflow when casting from double to time_t, and_PyTime_t.

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue34423> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34454] datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure

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

[issue34458] No way to alternate options

paul j3 added the comment: I agree that a custom Action subclass like this is the way to go. The regular 'append' is implemented in _AppendAction class, which is different from the default _StoreAction. So even if there was enough demand for this new idea to be put into development

[issue34454] datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure

Paul Ganssle added the comment: > Note that technically a difference between C and Python implementation of > fromisoformat() will still remain: if a part of the input string before or > after the separator contains surrogates, the C code will throw a > UnicodeEncodeError whil

[issue34454] datetime: NULL dereference in fromisoformat() on PyUnicode_AsUTF8AndSize() failure

Paul Ganssle added the comment: So this is related to something I was actually meaning to fix. When I wrote this code I didn't understand the way PyUnicode works, there's actually no need to call `PyUnicode_AsUTF8AndSize()` on the entire unicode string. My understanding is that each glyph

[issue34404] test_time incorrectly defined

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue34404> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1100942] Add datetime.time.strptime and datetime.date.strptime

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue1100942> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34365] datetime's documentation refers to "comparison [...] falling back to the default scheme of comparing object addresses"

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue34365> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34407] datetime.time.isoformat function has inconsistent behavior with timezone

Paul Ganssle added the comment: For one thing, this is not how pytz is supposed to be used. You have fallen prey to one of the most common errors when using pytz. See my blog post: https://blog.ganssle.io/articles/2018/03/pytz-fastest-footgun.html The issue at hand is also more about what

[issue34188] Allow dict choices to "transform" values in argpagse

paul j3 added the comment: The 'choices' mechanism is quite simple. As noted for testing it simply uses an 'in' test. For help formating it uses choice_strs = [str(choice) for choice in action.choices] result = '{%s}' % ','.join(choice_strs) In other words, it's treated

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

Paul Ganssle added the comment: > It does not seem to me that two threads have the GIL at the same time. To be clear, this was never my contention. I was under the impression that if you take the GIL with PyGILState_Ensure(), the GIL was held until you called PyGILState_Rele

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

Paul Ganssle added the comment: Using a modified version of Python 3.7.0 that prints "Releasing GIL" whenever PyGILState_Release, I get this: Waiting for GIL (0) Gil acquired! (0) Waiting for GIL (1) Gil acquired! (1) Releasing GIL Gil released! (0) Releasing GIL Gil release

[issue34416] PyCapsule_Import seems to release the GIL without acquiring it

New submission from Paul Ganssle : I was recently debugging some multithreaded Rust code that was deadlocking, and I tracked it down to what I'm fairly certain is a bug somewhere in PyCapsule_Import, where it seems that PyCapsule_Import releases the GIL without first acquiring it. I've

[issue34390] arparse.ArgumentParser misparses list arguments followed by undefined arguments

paul j3 added the comment: Duplicate of https://bugs.python.org/issue22909 [argparse] Using parse_known_args, unknown arg with space in value is interpreted as first positional arg (closed as duplicate) https://bugs.python.org/issue22433 Argparse considers unknown optional arguments

[issue34390] arparse.ArgumentParser misparses list arguments followed by undefined arguments

paul j3 added the comment: Parsing is a two step process. First the strings are passed through def _parse_optional(self, arg_string): which classifies them as 'O', an optional flag, or 'A', an argument. - no prefix char => A - the string is in the dictionary of option_strings (e.g. '--l

[issue34377] Update valgrind suppressions

Change by Paul Price : -- keywords: +patch pull_requests: +8213 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34377> ___ ___ Python-

[issue34377] Update valgrind suppressions

New submission from Paul Price : I've found that the valgrind suppressions don't work for me with cpython 3.6.2. Renaming PyObject_Free/PyObject_Realloc to _PyObject_Free/_PyObject_Realloc in the suppressions file works. I've got a patch that I'll put in via a GitHub PR

[issue33125] Windows 10 ARM64 platform support

Paul Monson added the comment: The PR hasn't changed since September. Is it still active? Should I consider updating the libffi_msvc code to support ARM32 in Python? Completing the switch to libffi makes more sense to me. I fetched the PR code to my fork and rebased it on the current

[issue33125] Windows 10 ARM64 platform support

Paul Monson added the comment: I'm interested in getting python working on Windows running on Raspberry Pi (Thumb-2 instruction set). I can also contribute to ARM64 Windows. I've made some progress getting ARM32 working on a fork. The next roadblock for my investigation is libffi support

[issue34359] Wrong virtual environment found

Paul Moore added the comment: Oh, and I suspect that the reason that "The thing with the relative path works if I change the order in the path" is simply because the bit of code that searches PATH just ignores what's after #!/usr/bin/env and looks for python.exe. (More or less -

[issue34359] Wrong virtual environment found

Paul Moore added the comment: Others use absolute paths, as I mentioned in my reply. -- ___ Python tracker <https://bugs.python.org/issue34359> ___ ___ Pytho

[issue34359] Wrong virtual environment found

Change by Paul Moore : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34359> ___ ___

[issue34359] Wrong virtual environment found

Paul Moore added the comment: >From https://docs.python.org/3.7/using/windows.html#shebang-lines the >supported shebang lines are * /usr/bin/env python * /usr/bin/python * /usr/local/bin/python * python There's a provision in there: """ The /usr/bin/env form of shebang

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: If you're OK with that, I don't see the problem. My objection was with the claims that ExtensionLoader.get_source shouldn't return None or shouldn't exist. PEP 302 mandates that loaders have a get_source, and that get_source should return None if the loader

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: On Sun, 5 Aug 2018 at 18:10, Brett Cannon wrote: > One other thing I will say is that the PEP 302 APIs were seemingly designed > for working with Python source and were not necessarily oriented towards > alternative code representations that were exec

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: So, where is the filename coming from? Looking at exception and frame objects, I don't see a "source filename" attribute anywhere - have I missed something here? -- ___ Python tracker <https://bu

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: On Sun, 5 Aug 2018 at 06:51, Stefan Behnel wrote: > This whole idea looks backwards and complicated. As Brett noted, .pyc files > were moved out of the source tree, because they are build time artifacts and > not sources. With that analogy, it's the

[issue32797] Tracebacks from Cython modules no longer work

Paul Moore added the comment: > What's wrong with that? Installing the .pyx sources together with the .so > compiled modules makes a lot of sense to me: it is very analogous to > installing the .py sources together with the .pyc byte-compiled files. In > https://bugs.python.or

[issue34299] argparse description formatting

Change by paul j3 : -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34299> ___ ___ Python-bugs-list

[issue34191] argparse: Missing subparser error message should be more clear

paul j3 added the comment: Updating you Python3.7 might change the behavior. If I read https://github.com/python/cpython/commits/master/Lib/argparse.py correctly, subparsers are no longer required by default (it reverted back to earlier Py3 behavior). There is a proposed patch

[issue34188] Allow dict choices to "transform" values in argpagse

paul j3 added the comment: The 'choices' mechanism is a simple 'value in choices' test. A dictionary (or other mapping) works because it works with 'in'. 'type' as noted is the means that argparse provides for transforming an input string into some other object (most commonly a number

[issue34191] argparse: Missing subparser error message should be more clear

paul j3 added the comment: Your code runs fine under 3.6.5. But if I add 'subparsers.required=True', I get your error. It's having problems formatting the name of the subparsers command when issuing the error message. If I add a 'dest' to the add_subparsers I get the expected error

[issue34174] argparse formatter_class issue for RawDescriptionHelpFormatter

paul j3 added the comment: argparse does import 'textwrap', but as '_textwrap', so it could be used with: argparse._textwrap.dedent(...) Importing your own is cleaner. -- nosy: +paul.j3 ___ Python tracker <https://bugs.python.org/issue34

[issue34046] subparsers -> add_parser doesn't support hyphen char '-'

paul j3 added the comment: Do you understand why this is happening? Subparsers is, in effect, a positional argument with 'choices' - the choices being the parsers (and their aliases). But '-dr' looks like an flagged (optionals) argument. Since you didn't define such an argument, it gets

[issue34158] Documentation of datetime '%z' format code is odd

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue34158> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34153] 10/3 - last digit

Paul Moore added the comment: See https://docs.python.org/3.7/tutorial/floatingpoint.html. Essentially, the behaviour you are seeing is caused by the fact that the results calculations you are attempting cannot be exactly represented in binary floating point, so approximate results

[issue27741] datetime.datetime.strptime functionality description incorrect

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue27741> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15390] PEP 3121, 384 refactoring applied to datetime module

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue15390> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22426] strptime accepts the wrong '2010-06-01 MSK' string but rejects the right '2010-06-01 MSD'

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue22426> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5516] equality not symmetric for subclasses of datetime.date and datetime.datetime

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue5516> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22377] %Z in strptime doesn't match EST and others

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue22377> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue28730] __reduce__ not being called in dervied extension class from datetime.datetime

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue28730> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9004] datetime.utctimetuple() should not set tm_isdst flag to 0

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue9004> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue22005] datetime.__setstate__ fails decoding python2 pickle

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue22005> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

Paul Ganssle added the comment: Oops, that previous comment was intended for a completely different ticket. My mistake. -- ___ Python tracker <https://bugs.python.org/issue27

[issue30155] Add ability to get/set tzinfo on datetime instances in C API

Paul Ganssle added the comment: Hmm. I never noticed this. In the past I have used the (undocumented) PyDateTimeAPI struct, which the official macros wrap. I'm not sure how official that struct is considering it doesn't show up in the documentation. I agree that it should be possible

[issue27400] Datetime NoneType after calling Py_Finalize and Py_Initialize

Paul Ganssle added the comment: Hmm. I never noticed this. In the past I have used the (undocumented) PyDateTimeAPI struct, which the official macros wrap. I'm not sure how official that struct is considering it doesn't show up in the documentation. I agree that it should be possible

[issue16322] time.tzname on Python 3.3.0 for Windows is decoded by wrong encoding

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue16322> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue25729] update pure python datetime.timedelta creation

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue25729> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12750] add cross-platform support for %s strftime-format code

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue12750> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31839] datetime: add method to parse isoformat() output

Paul Ganssle added the comment: This is a duplicate of #15873 and #24954 and can be closed, as `fromisoformat()` was added in Python 3.7. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue31

[issue24954] No way to generate or parse timezone as produced by datetime.isoformat()

Paul Ganssle added the comment: I believe this can be consolidated with #15873 and closed, since that is finished and available in Python 3.7. -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue24

[issue13305] datetime.strftime("%Y") not consistent for years < 1000

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue13305> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9305] Don't use east/west of UTC in date/time documentation

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue9305> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue31898] Add a `recommended-packages.txt` file

Paul Ganssle added the comment: > datetime.timezone -> pytz.timezone (updates driven by IANA timezone database) I will note that `pytz.timezone` and `datetime.timezone` are not really comparable (they do two very different things), and as of Python 3.6, `dateutil.tz` is the recom

[issue33381] Incorrect documentation for strftime()/strptime() format code %f

Paul Ganssle added the comment: I don't believe this is a duplicate if #32267, which is actually about the %z directive. I think the implementation here is correct and the documentation is semi-correct, it depends on how you look at it, consider: >>> datetime(2018, 1, 1, 0

[issue33381] Incorrect documentation for strftime()/strptime() format code %f

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue33381> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33940] datetime.strptime have no directive to convert date values with Era and Time Zone name

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue33940> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34023] timedelta(seconds=x) strange results when type(x) == np.int32

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue34023> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue6280] calendar.timegm() belongs in time module, next to time.gmtime()

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue6280> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15443] datetime module has no support for nanoseconds

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue15443> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue23607] Inconsistency in datetime.utcfromtimestamp(Decimal)

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue23607> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue33701] test_datetime crashed (SIGSEGV) on Travis CI

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue33701> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue29097] [Windows] datetime.fromtimestamp(t) when 0 <= t <= 86399 fails on Python 3.6

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue29097> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue10381] Add timezone support to datetime C API

Paul Ganssle added the comment: This can be closed now, I think. -- ___ Python tracker <https://bugs.python.org/issue10381> ___ ___ Python-bugs-list mailin

[issue33941] datetime.strptime not able to recognize invalid date formats

Change by Paul Ganssle : -- nosy: +p-ganssle ___ Python tracker <https://bugs.python.org/issue33941> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue15112] argparse: nargs='*' positional argument doesn't accept any items if preceded by an option and another positional

paul j3 added the comment: `parse_intermixed_args` was added in v 3.7. https://docs.python.org/3/library/argparse.html#intermixed-parsing https://stackoverflow.com/questions/50916124/allow-positional-command-line-arguments-with-nargs-to-be-seperated-by-a-flag

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

Paul Ganssle added the comment: > I am aware of that. In fact, some of the draft versions of PEP 495 > implementation did contain such code. The problem is that any such > tz.fromutc() implementation would necessarily change the behavior of the old > programs. This I'm no

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

Paul Ganssle added the comment: So I created a little patch for this, and when I was working on it I realized that it's actually possible to implement full `fold` support in a generic way in `fromutc` under the assumption that `utcoffset - dst` holds at all points (which is the fundamental

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

Change by Paul Ganssle : -- keywords: +patch pull_requests: +7050 stage: needs patch -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue20886] Disabling logging to ~/.python_history is not simple enough

Jesse Paul Ogle added the comment: Greetings, I came across this issue while looking into XDG Base Directory Specification. This issue is only tagged with version 3.4, but the underlying issue (not being able to change the history file / size through environment variables) appears to still

[issue33470] Changes from GH-1638 (GH-3575, bpo-28411) are not documented in Porting to Python 3.7

Paul Koning added the comment: FYI, I'm the one who created this problem back in 2012. I just submitted a GDB patch for this, using PyImport_AppendInittab to define the built-in module at startup. I'm not sure how I missed this originally; perhaps the documentation was not as clear back

[issue33698] `._pth` does not allow to populate `sys.path` with empty entry

Paul Moore added the comment: You could add the line import sys; sys.path.insert(0, '') to a .pth file. The documentation you pointed out states that lines starting with "import" are executed... -- ___ Python track

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

Paul Ganssle <p.gans...@gmail.com> added the comment: Ah, actually, my mistake, RFC 3339 most assuredly *does* require a UTC offset: 4.4. Unqualified Local Time A number of devices currently connected to the Internet run their internal clocks in local time and are unaware

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

Paul Ganssle <p.gans...@gmail.com> added the comment: I think this is more a matter of misunderstanding the fact that ISO 8601 is a larger and more complicated spec than people think. You'll note that the original complaint also seems to think that a timezone is required (it is not). Y

[issue15327] Argparse: main arguments and subparser arguments indistinguishable

Change by paul j3 <ajipa...@gmail.com>: -- nosy: +paul.j3 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue15327> ___ __

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

Paul Goins <gene...@vultaire.net> added the comment: I don't know enough about those tests and how important they are considered. My only concern would be with the increased risk of undetected breakage caused by removing them from CI, but if people think the risk is negl

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

Paul Goins <gene...@vultaire.net> added the comment: Also, to be clear, I understand what David is saying and don't disagree at all. And if this really is Spectre related, it may be difficult to "go back" and test a before case, so my last comment about "digging in"

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

Paul Goins <gene...@vultaire.net> added the comment: If we consider this to be the new normal... What about increasing the timeout to accomodate? From what I could gather, builds were running around 13 minutes or so before the changes, so the timeout wasn't much above actual exe

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

Paul Czyzewski <tallp...@gmail.com> added the comment: or, for a minimal doc change, change this sentence: "For example, the relative weights [10, 5, 30, 5] are equivalent to the cumulative weights [10, 15, 45, 50]," to: "For example, the relative call 'weights[10, 5,

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

Paul Czyzewski <tallp...@gmail.com> added the comment: oops, if "k=400" -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33494> ___ __

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

Paul Czyzewski <tallp...@gmail.com> 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

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

Paul Ganssle <p.gans...@gmail.com> 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&

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

Paul Moore <p.f.mo...@gmail.com> 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 calcu

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

Paul Goins <gene...@vultaire.net> 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 sl

[issue22848] Subparser help does not respect SUPPRESS argument

paul j3 <ajipa...@gmail.com> 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 re

[issue33389] argparse redundant help string

paul j3 <ajipa...@gmail.com> added the comment: Also https://bugs.python.org/issue27303 [argparse] Unify options in help output -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python

[issue33389] argparse redundant help string

paul j3 <ajipa...@gmail.com> 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 a

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

paul j3 <ajipa...@gmail.com> 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,

[issue33389] argparse redundant help string

paul j3 <ajipa...@gmail.com> 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 th

[issue22848] Subparser help does not respect SUPPRESS argument

paul j3 <ajipa...@gmail.com> 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 fu

[issue21822] KeyboardInterrupt during Thread.join hangs that Thread

Paul Goins <paul.d.go...@intel.com> 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 <rep...@bugs.python.or

<    7   8   9   10   11   12   13   14   15   16   >