[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

[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

[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 come up on StackOverflow

[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 hasattr

[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 devices: https

[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: 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: 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 change

[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: 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

[issue35723] Add "time zone index" cache to datetime objects

Paul Ganssle added the comment: > This sounds like a bug. Whether a tzinfo is a constant from a predefined set > or something with a smart comparison semantic is none of datetime's business. I'm not sure what you mean, but it was not a "bug" in the sense that it

[issue35723] Add "time zone index" cache to datetime objects

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

[issue36833] Add tests for Datetime C API Macros

New submission from Paul Ganssle : This is a child issue for bpo 36782, specifically for testing the macro-only datetime C API functions Untested macros with no corresponding API module: - PyDateTime_GET_YEAR - PyDateTime_GET_MONTH - PyDateTime_GET_DAY - PyDateTime_DATE_GET_HOUR

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

Paul Monson added the comment: > Okay. The test verifies work done to minimize interpreter startup time, but > probably the relative cost of importing functools (and thus collections et > al) isn't significant compared to the overall cost of spawning a process in a > Win

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

Change by Paul Monson : -- title: test_site.StartupImportTests.test_startup_imports fails if default code page is not cp1252 -> test_site.StartupImportTests.test_startup_imports fails if default code page is cp65001 ___ Python tracker <

[issue36797] Cull more oudated distutils information

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

[issue36783] No documentation for _FromXandFold C API functions

Paul Ganssle added the comment: This ticket should be reserved for the mentored sprint. -- assignee: docs@python -> Mariatta ___ Python tracker <https://bugs.python.org/issu

[issue35947] Update libffi_msvc to current version of libffi

Change by Paul Monson : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35947> ___ ___ Pyth

[issue36782] Add tests for the datetime C API

Paul Ganssle added the comment: This ticket should be reserved for the mentored sprint. -- assignee: -> Mariatta nosy: +Mariatta ___ Python tracker <https://bugs.python.org/issu

[issue36509] Add iot layout for windows iot containers

Change by Paul Monson : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36509> ___ ___ Pyth

[issue36783] No documentation for _FromXandFold C API functions

Change by Paul Ganssle : -- nosy: +Mariatta, cheryl.sabella ___ Python tracker <https://bugs.python.org/issue36783> ___ ___ Python-bugs-list mailing list Unsub

[issue36783] No documentation for _FromXandFold C API functions

New submission from Paul Ganssle : In Python 3.6, Time_FromTimeAndFold and PyDateTime_FromDateAndTimeAndFold were added as part of the PEP 495 implementation, but no documentation was added for the C API portions of this change: https://docs.python.org/3.7/c-api/datetime.html The functions

[issue36782] Add tests for the datetime C API

New submission from Paul Ganssle : A decent fraction of the datetime C API has no tests. If we had tests, we could have prevented bpo #36025, which was a regression in the FromTimestamp method. I would like to open this issue to suggest the addition of tests for the full interface

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

Paul Monson added the comment: == FAIL: test_startup_imports (test.test_site.StartupImportTests) -- Traceback (most recent call last): File "c:\d

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

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

[issue36779] time.tzname returns empty string on Windows if default codepage is a Unicode codepage

Change by Paul Monson : -- title: strptime returns empty string on Windows if default codepage is a Unicode codepage -> time.tzname returns empty string on Windows if default codepage is a Unicode codepage ___ Python tracker <

[issue36779] strptime returns empty string on Windows if default codepage is a Unicode codepage

New submission from Paul Monson : Need to work around a CRT bug in the use of _tzset() + _tzname[] Calling setlocale(LC_CTYPE, "") on a system where GetACP() returns CP_UTF8 results in empty strings in _tzname[]. This causes time.tzname to be an empty string. I have reported the

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

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

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

New submission from Paul Monson : Windows desktop skus have a default ANSI codepage (returned by GetACP()) of 1252 (Western European). Windows IoT Core and Windows Nano Server have a default codepage of 65001 (UTF-8). This causes test_site.StartupImportTests.test_startup_imports to fail

[issue36774] f-strings: Add a !d conversion for ease of debugging

Paul Moore added the comment: > So the question is: how do you get repr by default, but allow the format spec? > > The only thing I've come up with is: > - f"{expr!d}" expands to f"expr={repr(expr)}", but > - f"{expr!d:spec} expands to f"expr={form

[issue36774] f-strings: Add a !d conversion for ease of debugging

Paul Moore added the comment: +1 from me. It's something I'd find useful, and it's a natural extension of the f-string syntax. > I can't decide if I'm going to allow a format specifier. The only useful interpretation IMO would be for {expr!d:fmt} to expand to expr={expr:fmt}. If you

[issue36722] In debug build, load also C extensions compiled in release mode or compiled using the stable ABI

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

[issue36700] base64 has old references that should be updated

Paul Hoffman added the comment: We can update the references without supporting every mode given in the new document. It is common for people to support RFC X without supporting every possible option of RFC X. Having said that, I think adding extended hex makes good sense, if possible

[issue36511] Add Windows ARM32 buildbot

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

[issue36700] base64 has old references that should be updated

New submission from Paul Hoffman : The documentation for base64 library has an RFC that is obsolete. -- assignee: docs@python components: Documentation messages: 340668 nosy: docs@python, paulehoffman priority: normal pull_requests: 12839 severity: normal status: open title: base64 has

[issue36693] Reversing large ranges results in a minor type inconsistency

Paul Ganssle added the comment: I believe the relevant code is here: https://github.com/python/cpython/blob/bb86bf4c4eaa30b1f5192dab9f389ce0bb61114d/Objects/rangeobject.c#L1038 It looks like it's a performance enhancement and that for ranges where the beginning and end can fit in a C long

[issue36693] Reversing large ranges results in a minor type inconsistency

Paul Ganssle added the comment: I have edited the title to be a bit more and give more context. Donald, if you feel I have misrepresented your issue, please feel free to tweak it further. -- nosy: +p-ganssle title: Minor inconsistancy with types. -> Reversing large ranges resu

[issue36694] Excessive memory use or memory fragmentation when unpickling many small objects

Change by Paul Ellenbogen : Removed file: https://bugs.python.org/file48278/dump.py ___ Python tracker <https://bugs.python.org/issue36694> ___ ___ Python-bugs-list m

[issue36694] Excessive memory use or memory fragmentation when unpickling many small objects

Change by Paul Ellenbogen : Removed file: https://bugs.python.org/file48281/dump.py ___ Python tracker <https://bugs.python.org/issue36694> ___ ___ Python-bugs-list m

[issue36694] Excessive memory use or memory fragmentation when unpickling many small objects

Change by Paul Ellenbogen : Added file: https://bugs.python.org/file48282/dump.py ___ Python tracker <https://bugs.python.org/issue36694> ___ ___ Python-bugs-list mailin

[issue36694] Excessive memory use or memory fragmentation when unpickling many small objects

Paul Ellenbogen added the comment: Good point. I have created a new version of dump that uses random() instead. float reuse explains the getsizeof difference, but there is still a significant memory usage difference. This makes sense to me because the original code I saw this issue

[issue36694] Excessive memory use or memory fragmentation when unpickling many small objects

Change by Paul Ellenbogen : Added file: https://bugs.python.org/file48280/common.py ___ Python tracker <https://bugs.python.org/issue36694> ___ ___ Python-bugs-list m

[issue36694] Excessive memory use or memory fragmentation when unpickling many small objects

New submission from Paul Ellenbogen : Python encounters significant memory fragmentation when unpickling many small objects. I have attached two scripts that I believe demonstrate the issue. When you run "dumpy.py" it will generate a large list of namedtuples, then write that list

[issue36694] Excessive memory use or memory fragmentation when unpickling many small objects

Change by Paul Ellenbogen : Added file: https://bugs.python.org/file48279/load.py ___ Python tracker <https://bugs.python.org/issue36694> ___ ___ Python-bugs-list mailin

[issue36664] argparse: parser aliases in subparsers stores alias in dest variable

paul j3 added the comment: https://docs.python.org/3/library/argparse.html#argparse.ArgumentParser.add_subparsers shows how to use `set_defaults` in a parser to set a 'func' attribute. That method could just as well be used to set the true 'name' or any other kind of attribute

[issue36664] argparse: parser aliases in subparsers stores alias in dest variable

paul j3 added the comment: I added a `print(args)` to clarify what you are talking about: 2148:~/mypy$ python3 issue36664.py subsection Namespace(context='subsection') my subsection was called 2148:~/mypy$ python3 issue36664.py s Namespace(context='s') my functon was not called 2148:~/mypy

[issue36638] typeperf.exe is not in all skus of Windows SKUs

Change by Paul Monson : -- title: typeperf.exe is not in all skus of Windows -> typeperf.exe is not in all skus of Windows SKUs ___ Python tracker <https://bugs.python.org/issu

[issue36638] typeperf.exe is not in all skus of Windows

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

[issue36638] typeperf.exe is not in all skus of Windows

New submission from Paul Monson : typeperf.exe is not present on small editions of windows like Windows IoT Core or nanoserver This causes WindowsLoadTracker to throw an exception during test initialization. -- components: Tests messages: 340309 nosy: Paul Monson priority: normal

[issue33632] undefined behaviour: signed integer overflow in threadmodule.c

Paul Ganssle added the comment: > In short, a+b can overflow, but a-b cannot? I think it's more that by always checking the elapsed time against `now() - starttime`, you never need to represent the time at which the timeout should happen - which may be so far in the future that it cau

[issue36602] Recursive directory list with pathlib.Path.iterdir

Paul Ganssle added the comment: > I don't spend enough time dealing with symlinks to have strong opinions > there, but given we have ways to resolve symlinks but not to get back to the > original name (and I *have* had to deal with issues where I've needed to find > the origin

[issue17267] datetime.time support for '+' and '-'

Paul Ganssle added the comment: I am pretty neutral on this. I don't think it will be terribly difficult to implement or maintain this, and while there are a few possible behaviors, if you think about it for a bit, addition with overflow behavior *does* seem like the natural way

[issue36602] Recursive directory list with pathlib.Path.iterdir

Paul Ganssle added the comment: > rglob and glob also return a generator. My mistake, I didn't notice the `sorted` in the `rglob` documentation and thought it was emitting a list. > By that logic, we should remove `Path.iterdir()` in favour of > `Path.glob('*')`. What *is*

[issue36602] Recursive directory list with pathlib.Path.iterdir

Paul Ganssle added the comment: > Is the behaviour you're proposing any different from using Path.rglob('*')? I believe `rglob("*")` is eager, while `iterdir` is lazy. @Epic_Wink: > This would be trivial to implement as 'iterdir' can simply yield from > subdirectories' 'i

[issue22454] Adding the opposite function of shlex.split()

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

[issue34249] Full set of format codes applies to strftime only

Paul Ganssle added the comment: To clarify, as far as I know, this note *does* apply to both strftime and strptime, as CPython doesn't have its own implementation of either. I'm not sure if any guarantees are made that the supported formatting codes will be the same between the two

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

Paul Ganssle added the comment: @Alex LordThorsen: It will accept EST if EST is one of your "local" time zones, so whatever's in `time.tzname`. In the short term, I think the right thing to do would be to update the documentation to remove the reference to "EST", and add

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

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

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

New submission from Paul Ganssle : When reviewing PR 12020 fixing an infinite loop in the e-mail module, I noticed that a *different* infinite loop is documented with a "# XXX" comment on line 2724: https://github.com/python/cpython/blob/58721a903074d28151d008d8990c98fc31d1e798

[issue33632] undefined behaviour: signed integer overflow in threadmodule.c

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

[issue36558] Change time.mktime() return type from float to int?

Paul Ganssle added the comment: I would say that the natural output of mktime is indeed an integer, but I can't say off the top of my head what "compatibility" refers to here, so per the principle of Chesterton's fence, without more research or historical context I'd say the defa

[issue33775] argparse: the word 'default' (in help) is not marked as translatable

paul j3 added the comment: https://bugs.python.org/issue16786 points out that the 'version' action isn't localizable either. -- ___ Python tracker <https://bugs.python.org/issue33

[issue33775] argparse: the word 'default' (in help) is not marked as translatable

paul j3 added the comment: I haven't paid much attention to the localization issues in `argparse`. The issue is with the help modification done by the: class ArgumentDefaultsHelpFormatter help += ' (default: %(default)s)' This formatter is a convenience, not something critical

[issue12756] datetime.datetime.utcnow should return a UTC timestamp

Paul Ganssle added the comment: @tin utcnow is a semi-deprecated way to get a naive datetime that represents the time in UTC. The preferred replacement is to do this: from datetime import datetime, timezone datetime.now(tz=timezone.utc) Note that you can replace "timezon

[issue36513] Add support for building arm32 nuget package

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

[issue36513] Add support for building arm32 nuget package

Change by Paul Monson : -- components: Build, Windows nosy: Paul Monson, paul.moore, steve.dower, tim.golden, zach.ware priority: normal severity: normal status: open title: Add support for building arm32 nuget package type: enhancement versions: Python 3.8

[issue36511] Add Windows ARM32 buildbot

Change by Paul Monson : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue36511> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36511] Add Windows ARM32 buildbot

New submission from Paul Monson : Zachary Ware suggested I create an issue to discuss this: I've started a worker using the worker name monson-win-arm32 and the password provided. I think it is waiting for a change, there were no errors, but it didn't print anything. Also, I don’t see

[issue33608] Add a cross-interpreter-safe mechanism to indicate that an object may be destroyed.

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

[issue36509] Add iot layout for windows iot containers

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

[issue36509] Add iot layout for windows iot containers

New submission from Paul Monson : The layout should not contain tcl/tk, tkinter, distutils since ARM is cross-compiled and these features will not be useful on target ARM devices. -- components: Build, Windows messages: 339352 nosy: Paul Monson, paul.moore, steve.dower, tim.golden

[issue36464] Python 2.7 build install fails intermittently with -j on MacOS

Paul Smith added the comment: I've tried on both MacOS 10.12 and 10.14. I'm using GNU make 4.2.1 (built myself, not the one that comes with Xcode). I have not tried Python3 builds. I agree with you that -jN probably has little impact on the install step, but the build infrastructure I'm

[issue36464] Python 2.7 build install fails intermittently with -j on MacOS

New submission from Paul Smith : Maybe no one cares anymore, but I've discovered that if I run make with -j the installation sometimes fails with this error: install: mkdir /Users/build/.../dist/python/x86_64-darwin/lib: File exists I believe it's because the targets altbininstall

[issue31327] bug in dateutil\tz\tz.py

Paul Ganssle added the comment: Can we change the title of this to something like, "Add example of platform-specific support for negative timestamps to the time documentation"? That might be a bit wordy, but as it is now, this looks like it's reporting a bug in dateutil, which i

[issue36439] Inconsistencies with datetime.fromtimestamp(t) when t < 0

Paul Ganssle added the comment: >From the documentation ( >https://docs.python.org/3/library/datetime.html#datetime.datetime.fromtimestamp > ): > fromtimestamp() may raise OverflowError, if the timestamp is out of the range > of values supported by the platform C localt

[issue35872] Creating venv from venv no longer works in 3.7.2

Paul Moore added the comment: See https://github.com/pypa/virtualenv/issues/1339 - it's possible that something in this area is still affecting virtualenv. -- ___ Python tracker <https://bugs.python.org/issue35

[issue36435] multiprocessing crashes in Python 3.7.3 on Windows

Paul Moore added the comment: Oh doh. That's what I get for trying to produce a minimal test case without thinking :-( Thanks for the pointer. I originally hit this (or what I thought was this) in pipx - see https://github.com/pipxproject/pipx/issues/122 but then tried a smaller test

[issue36435] multiprocessing crashes in Python 3.7.3 on Windows

New submission from Paul Moore : If I run the following sample program using Python 3.7.3 (64 bit) for Windows, it immediately fails, producing a massive traceback. import multiprocessing def f(n): return n+1 with multiprocessing.Pool() as p: for n in p.map(f, [1,2,3

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Paul Moore added the comment: > There's no way to split it up as the joining of two pathlib paths because > there is no way to represent "c:a" by itself as anything other than a > drive-relative path. The name "./c:a" has to be taken as a unit, which is > f

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Paul Moore added the comment: > does that require me to make any changes in order to make progress with my PR? I'm not going to block this PR. I'd prefer it if we at least documented the agreed behaviour, so that in future people don't come along and say the new behaviour is wrong, but ag

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Paul Moore added the comment: > > [Note there is no absolute() method - I assume you mean resolve()] > Of course there is an absolute() method, I'm not sure what you are saying... Huh, weird. It's not in https://docs.python.org/3.7/library/pathlib.html But you're right, it d

[issue36305] Inconsistent behavior of pathlib.WindowsPath with drive paths

Paul Moore added the comment: (Note: I consider all of these to be *extremely* obscure corner cases) > 1. WindowsPath('C:a').absolute() should return WindowsPath('C:\\d\\a') but > returns WindowsPath('C:a'). > This is caused by flawed logic in the parse_parts method of the _Flavour

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

Paul Moore added the comment: Thanks! That seems to have done it. Update to the PR incoming once my test build completes. -- ___ Python tracker <https://bugs.python.org/issue36

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

Paul Moore added the comment: I ran Tools/nuget/build.bat manually, and the resulting file didn't have lib\venv in it (I opened it in 7-zip, I don't know how to install a local nuget file...). Could you build the nuget files and check? Or suggest a better way I can check that the change

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Paul Ganssle added the comment: > No please, don't do that :-( Interesting, I don't feel terribly strongly about it, but I would have thought that you'd be more in favor of that solution, maybe we have a different definition of "expected failure"? Usually in my projects, I u

[issue35066] Inconsistency between dangling '%' handling in time.strftime() and datetime.strftime()

Paul Ganssle added the comment: I think the proposed change to the test will work, or we can mark the test as an expected failure on Android (on the theory that the test *should* work because we want the behavior normalized, but we are not living up to that). In either case, I think

[issue36330] Warning about a potential dead code in timemodule and Clang

Paul Ganssle added the comment: Sorry, I should say unlikely that it should ever be *true*. It seems unlikely that there is a platform or piece of hardware on which this error would be raised. -- ___ Python tracker <https://bugs.python.

[issue36330] Warning about a potential dead code in timemodule and Clang

Paul Ganssle added the comment: It does seem like the values CLOCKS_PER_SEC, _PyTime_MAX and SEC_TO_NS are all defined at compile-time, so presumably this can be a compile-time error. As currently defined, though, it seems very unlikely that this would ever be false, since _PyTime_MAX

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

Paul Moore added the comment: The referenced PR isn't working - in the nuget package, python.props still says to exclude venv (and indeed venv is still missing). There's a PC/layout/support/props.py file that includes the offending "remove venv" line. Does that need modifying

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

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

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

Paul Moore added the comment: :-) I assume as we're at rc1, it's too late for 3.7.3, but it could be aimed at 3.7.4. I might try to have a look at it if no-one else does. -- ___ Python tracker <https://bugs.python.org/issue36

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

Paul Moore added the comment: Hmm, I see that the Versions tag here is 3.8. Is this only targeted at 3.8, then? -- ___ Python tracker <https://bugs.python.org/issue36

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

Paul Moore added the comment: Apparently, this is not in 3.7.3-rc1: >nuget install python -version 3.7.3-rc1 Feeds used: C:\Users\\.nuget\packages\ https://api.nuget.org/v3/index.json Attempting to gather dependency information for package 'python.3.7.3-rc1' with resp

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

Paul Moore added the comment: Ah, yes, you're right. I'd misremembered. Thanks. -- ___ Python tracker <https://bugs.python.org/issue36010> ___ ___ Python-bug

[issue36010] Please provide a .zip Windows release of Python that is not crippled/for embedding only

Paul Moore added the comment: It appears that the venv module did not get added to the 3.7.3 rc1 embedded distribution. Was that an oversight, or had I misunderstood what was needed for this to have happened? -- ___ Python tracker <ht

[issue36085] Enable better DLL resolution

Paul Moore added the comment: > Since everyone seems to have misunderstood at least part of the proposal, I'm > not going to explain any more until I have a patch. Excluding boilerplate and > docs, it'll be about ten lines of code. +1 on that. Code is much harder to misunderstand

[issue36085] Enable better DLL resolution

Paul Moore added the comment: OK, I don't really follow enough of the details here to comment properly. But clearly Steve and Eryk are not yet in agreement. My personal view is that this is something where we should be trying *very* hard to preserve backward compatibility. The proposal here

[issue36085] Enable better DLL resolution

Paul Moore added the comment: > > This bothers me - how will backward compatibility work in that case? > > The new search order is compatible with the old search order, so you can > update all your layouts to have DLL dependencies in suitable locations and > you'll

[issue36085] Enable better DLL resolution

Paul Moore added the comment: > Also, if I'm understanding your intention, loading an extension may fail when > Python is embedded if the process is using the legacy DLL search path. So, > like with ctypes, we'll be forcing embedding applications to update how they > load D

[issue36267] User input to argparse raises Index_Error: "-a=" on a 'store_true' action

New submission from paul j3 : Test case: parser = argparse.ArgumentParser() parser.add_argument("-a", action="store_true") args = parser.parse_args("-a=".split()) raises an Index_Error, which is not caught by the argparse error mechanism. This is an

<    4   5   6   7   8   9   10   11   12   13   >