[issue31624] remove support for BSD/OS

Benjamin Peterson added the comment: New changeset 288d1daadaddf6ae35cf666138ba4b5d07449657 by Benjamin Peterson in branch 'master': remove support for BSD/OS (closes bpo-31624) (#3812) https://github.com/python/cpython/commit/288d1daadaddf6ae35cf666138ba4b5d07449657

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

Oren Milman added the comment: Another thought - the existing code assumes that splitlines() returned a string. So maybe we could just check that get_source() returned a string, and then call the method str.splitlines() on it? --

[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently

Change by Surenkumar Nihalani : -- keywords: +patch pull_requests: +3797 stage: -> patch review ___ Python tracker ___

[issue31603] Please add argument to override stdin/out/err in the input builtin

Wren Turkal added the comment: Added a PR to facilitate discussion on python-ideas. -- keywords: +patch pull_requests: +3798 stage: -> patch review ___ Python tracker

[issue31624] remove support for BSD/OS

Change by Benjamin Peterson : -- keywords: +patch pull_requests: +3796 stage: -> patch review ___ Python tracker ___

[issue31624] remove support for BSD/OS

New submission from Benjamin Peterson : This operating system hasn't been supported by its vendor since 2004. We should get rid of our code for it. -- components: Build messages: 303296 nosy: benjamin.peterson priority: normal severity: normal status: open title:

[issue31623] Allow to build MSI installer from the official tarball

Ivan Pozdeev added the comment: With this patch, I managed to make a working installer. There's nothing in PCBuild/readme.txt about making an installer, and this is the only relevant tool I found in the source. If there's another, feel free to close the ticket, and I'll

[issue31623] Allow to build MSI installer from the official tarball

Change by Ivan Pozdeev : -- nosy: +r.david.murray ___ Python tracker ___ ___

[issue31623] Allow to build MSI installer from the official tarball

Change by Ivan Pozdeev : -- keywords: +patch nosy: -r.david.murray Added file: https://bugs.python.org/file47176/0001-Support-making-MSI-installer-from-tarball.patch ___ Python tracker

[issue31623] Allow to build MSI installer from the official tarball

R. David Murray added the comment: Assuming 3.4 is packagable using msi and hg is the only problem, I presume you could use an hg-git adapter to get an hg checkout to build from. -- nosy: +r.david.murray ___ Python tracker

[issue31622] Make threading.get_ident() return an opaque type

R. David Murray added the comment: Are you aware of PEP 539? (See issue 25658 for discussion.) I haven't followed that closely, but I imagine this issue is at least related. -- nosy: +r.david.murray ___ Python tracker

[issue31623] Allow to build MSI installer from the official tarball

New submission from Ivan Pozdeev : Since the last version of 3.4 is only made available as a source tarball, it's imperative to be able to make a distributable package locally from it. Tools/msi/msi.py only works from an `hg' checkout. -- components: Build

[issue31622] Make threading.get_ident() return an opaque type

New submission from pdox : Currently, Python exposes "thread identifiers" as unsigned long values across multiple modules: threading.get_ident() -> Returns an integer thread id sys._current_frames() -> Dictionary keys are integer thread ids signal.pthread_kill() -> Accepts

[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently

Surenkumar Nihalani added the comment: I am working on fixing this. -- nosy: +snihalani ___ Python tracker ___

[issue25351] pyvenv activate script failure with specific bash option

Sorin Sbarnea added the comment: Based on my tests this worked with all shells I tested with, the syntax being a very old one and not some new/modern one. Passed: bash, zsh, dash, ksh Platforms: MacOS, RHEL Linux Failed with: tcsh but with the note that even the

[issue25351] pyvenv activate script failure with specific bash option

R. David Murray added the comment: Note that in the equivalent issue raised against virtualenv, the concern was raised that some old sh-like shells might not support this syntax, but it was pointed out that it is part of the posix standard. I'm not arguing for or

[issue11063] Rework uuid module: lazy initialization and add a new C extension

Antoine Pitrou added the comment: Crude import benchmark (Ubuntu): * before: $ time ./python -c "import uuid" real0m0.074s user0m0.056s sys 0m0.012s * after: $ time ./python -c "import uuid" real0m0.030s user0m0.028s sys 0m0.000s * baseline: $

[issue31158] test_pty: test_basic() fails randomly on Travis CI

Cornelius Diekmann added the comment: Yes, I get the AssertionError with the latest version of PR 3802. From the high load avg of my system, you can see that the error occurs very rarely and that I need to stress my system to trigger it. With PR 3802, the error

[issue31558] gc.freeze() - an API to mark objects as uncollectable

STINNER Victor added the comment: (my previous msg303283 was for the bpo-11063, I removed it, sorry for the spam.) -- ___ Python tracker

[issue11063] Rework uuid module: lazy initialization and add a new C extension

STINNER Victor added the comment: I ran two benchmarks on my Fedora 26. * new = master (commit a106aec2ed6ba171838ca7e6ba43c4e722bbecd1) * ref = commit 8d59aca4a953b097a9b02b0ecafef840e4ac5855 git co master ./python -m perf timeit -s 'import sys, uuid' "del

[issue31558] gc.freeze() - an API to mark objects as uncollectable

Change by STINNER Victor : -- Removed message: https://bugs.python.org/msg303283 ___ Python tracker ___

[issue31558] gc.freeze() - an API to mark objects as uncollectable

STINNER Victor added the comment: I ran two benchmarks on my Fedora 26. * new = master (commit a106aec2ed6ba171838ca7e6ba43c4e722bbecd1) * ref = commit 8d59aca4a953b097a9b02b0ecafef840e4ac5855 git co master ./python -m perf timeit -s 'import sys, uuid' "del

[issue31604] unittest.TestLoader().loadTestsFromTestCase(...) fails when adding test cases with the expectedFailure decorator

Krzysztof Warunek added the comment: AFAIK this helper is meant to be used with test function not the TestCases. -- nosy: +kwarunek ___ Python tracker

[issue11063] Rework uuid module: lazy initialization and add a new C extension

Change by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue20519] Replace uuid ctypes usage with an extension module.

Antoine Pitrou added the comment: New changeset a106aec2ed6ba171838ca7e6ba43c4e722bbecd1 by Antoine Pitrou in branch 'master': bpo-11063, bpo-20519: avoid ctypes and improve import time for uuid (#3796)

[issue11063] Rework uuid module: lazy initialization and add a new C extension

Antoine Pitrou added the comment: New changeset a106aec2ed6ba171838ca7e6ba43c4e722bbecd1 by Antoine Pitrou in branch 'master': bpo-11063, bpo-20519: avoid ctypes and improve import time for uuid (#3796)

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

STINNER Victor added the comment: Serhiy: "I have tested, this doesn't affect performance." Oh, thank you for testing that :-) -- ___ Python tracker

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

Serhiy Storchaka added the comment: I have tested, this doesn't affect performance. -- ___ Python tracker ___

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

STINNER Victor added the comment: > The code doesn't work nice with general objects supporting the buffer > protocol. The length check suppose that the value has a length, and it is the > size in bytes. The code for bytes_le suppose that the value supports slicing >

[issue31158] test_pty: test_basic() fails randomly on Travis CI

STINNER Victor added the comment: Hum, let me clarify: my main goal is to get a stable CI. I don't really care of the exact implementation of one specific unit test in test_pty ;-) -- ___ Python tracker

[issue31158] test_pty: test_basic() fails randomly on Travis CI

STINNER Victor added the comment: Cornelius:Here is a PoC: I checked out your code and stressed my system with it. (...) AssertionError: ..." Did you get this failure with my PR 3802? Cornelius: "We have b'For my pet fish, Eric.\r\n' in the pty buffer. We read

[issue31621] Pluralization typo in Language Reference section 7.12

Mariatta Wijaya added the comment: Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue31621] Pluralization typo in Language Reference section 7.12

Mariatta Wijaya added the comment: New changeset 641494ec3168bd556f0af226196e13ae29bddd53 by Mariatta (Miss Islington (bot)) in branch '3.6': bpo-31621: Fix typo in Simple Statements documentation (GH-3809) (GH-3810)

[issue31621] Pluralization typo in Language Reference section 7.12

Change by Roundup Robot : -- pull_requests: +3795 ___ Python tracker ___

[issue31621] Pluralization typo in Language Reference section 7.12

Kevin added the comment: Ok, I've created a pull request, available at https://github.com/python/cpython/pull/3809. -- ___ Python tracker

[issue31621] Pluralization typo in Language Reference section 7.12

Change by Kevin : -- keywords: +patch pull_requests: +3793 stage: needs patch -> patch review ___ Python tracker ___

[issue31614] can't list groupby generator without breaking the sub groups generators

Loïc Le Loarer added the comment: Thanks a lot for the clear answer, sorry for not having read the online documentation, I only read the help(itertools.groupby) which has much less details. And for my use case, I can use an explicit command just to compute the number

[issue31621] Pluralization typo in Language Reference section 7.12

Kevin added the comment: Yes, I intend to make a PR shortly. -- ___ Python tracker ___

[issue31621] Pluralization typo in Language Reference section 7.12

Mariatta Wijaya added the comment: Thanks Kevin. Can you open a pull request with this change? -- nosy: +Mariatta stage: -> needs patch ___ Python tracker

[issue31616] Windows installer: Python binaries are user-writable

Steve Dower added the comment: Correct, this is expected behavior. If you want your system to be secure *and* to modify default settings, you have to take full responsibility for that. You can't rely on other tools to have secure non-default settings (they should have

[issue31621] Pluralization typo in Language Reference section 7.12

New submission from Kevin : The documentation for the `global` statement contains the line: > CPython implementation detail: The current implementation does not enforce > some of these restriction [...] "restriction" should be "restrictions" since there is more

[issue31616] Windows installer: Python binaries are user-writable

R. David Murray added the comment: I'll let Steve be the one to close this, but it sounds like this isn't even a doc bug (ie: it is standard window's practice). -- ___ Python tracker

[issue31620] asyncio.Queue leaks memory if the queue is empty and consumers poll it frequently

New submission from Zack Elan : Repro: Call asyncio.wait_for(some_queue.get(), some_timeout) repeatedly, with no items in the queue, so that the call times out each time. Expected: No increase in memory while polling an empty queue Actual: The queue holds on to pending

[issue31619] Strange error when convert hexadecimal with underscores to int

Mark Dickinson added the comment: Looks like an overflow check that was questionable in the first place (depending on undefined behaviour), and is now both questionable and wrong. I'll see if I can find time for a fix this evening (UTC+1). --

[issue31465] Allow _PyType_Lookup() to raise exceptions

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

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

Serhiy Storchaka added the comment: > In 2.7, PyUnicode_Splitlines() first does: > string = PyUnicode_FromObject(string); And it raises an exception if the string contains non-ASCII characters. It is better to avoid str<->unicode convertion as long as possible.

[issue31158] test_pty: test_basic() fails randomly on Travis CI

Change by Cornelius Diekmann : -- pull_requests: +3792 ___ Python tracker ___ ___

[issue31465] Allow _PyType_Lookup() to raise exceptions

Change by Stefan Behnel : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list

[issue31158] test_pty: test_basic() fails randomly on Travis CI

Cornelius Diekmann added the comment: I also added a pull request which I cannot get to fail on my system. What do you think, haypo? Sorry for the noise! -- ___ Python tracker

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

Oren Milman added the comment: In 2.7, PyUnicode_Splitlines() first does: string = PyUnicode_FromObject(string); So i thought that PyUnicode_Splitlines() would be fine with receiving a string. But now i realize that even in case i was right there, PyUnicode_Splitlines()

[issue31158] test_pty: test_basic() fails randomly on Travis CI

Cornelius Diekmann added the comment: Oh, one more thing, since it is unclear whether read or write is causing the error. I replaced os.write(slave_fd, TEST_STRING_1) by pty._writen(slave_fd, TEST_STRING_1) which makes sure all bytes are written. After some time,

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

Serhiy Storchaka added the comment: PyUnicode_Splitlines() cannot be used here in 2.7, because the source is likely a 8-bit string. Actually I'm not sure this issue is worth to be fixed in 2.7. The fix would be different from 3.x and more complex. --

[issue31158] test_pty: test_basic() fails randomly on Travis CI

Cornelius Diekmann added the comment: >> Does reading the string b'I wish to buy a fish license.\n' not cause a >> problem, too? > >This string TEST_STRING_1 is used for a single os.write() call, whereas >TEST_STRING_2 is splitted and written in two parts with two

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

Change by Oren Milman : -- pull_requests: +3791 ___ Python tracker ___ ___

[issue25098] test_uuid fails with pywin32 installed

Zachary Ware added the comment: Still fails on Python 3.6.1 with pypiwin32-220; those are the versions I have handy to check on. I've not managed to report it to pywin32 or look into it any deeper, though. If someone can confirm that it's definitely their bug, this

[issue25351] pyvenv activate script failure with specific bash option

sorin added the comment: This is a perfectly valid bug and I am surprised it was ignored for so long. I just raised a PR for addressing it, please review it. -- keywords: +patch nosy: +sorin pull_requests: +3790 stage: -> patch review type: enhancement ->

[issue31610] Use select.poll instead of select.select in SocketServer.BaseServer.serve_forever

STINNER Victor added the comment: > I recommend to use selectors.PollSelector and fallback on > selectors.SelectSelector where not available (Windows) in order to use 1 > syscall only. That's what we did already in socket.py, subprocess.py and > others. It would be

[issue31616] Windows installer: Python binaries are user-writable

Paul Moore added the comment: Standard Windows behaviour, in my experience, is inherited permissions. IMO, the current behaviour is correct - we default to an OS-managed secure location for system wide installs, and a user-modifiable location for user installs. If the

[issue31158] test_pty: test_basic() fails randomly on Travis CI

STINNER Victor added the comment: > Does reading the string b'I wish to buy a fish license.\n' not cause a > problem, too? This string TEST_STRING_1 is used for a single os.write() call, whereas TEST_STRING_2 is splitted and written in two parts with two os.write()

[issue31610] Use select.poll instead of select.select in SocketServer.BaseServer.serve_forever

Giampaolo Rodola' added the comment: I recommend to use selectors.PollSelector and fallback on selectors.SelectSelector where not available (Windows) in order to use 1 syscall only. That's what we did already in socket.py, subprocess.py and others. -- nosy:

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

Serhiy Storchaka added the comment: The code doesn't work nice with general objects supporting the buffer protocol. The length check suppose that the value has a length, and it is the size in bytes. The code for bytes_le suppose that the value supports slicing and

[issue31158] test_pty: test_basic() fails randomly on Travis CI

Cornelius Diekmann added the comment: Regarding PR 3802: * Does reading the string b'I wish to buy a fish license.\n' not cause a problem, too? * Is reading len(expected) bytes the correct behavior for systems where normalize_output is needed? I also fixed these

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

STINNER Victor added the comment: Serhiy: is it safe to accept any memoryview? Or should we call explicitly .cast('B') on memory views to prevent bad surprises? The asyncio module doesn't do anything special in sock_sendall(). "data" is passed directly to

[issue31610] Use select.poll instead of select.select in SocketServer.BaseServer.serve_forever

STINNER Victor added the comment: > Better alternative will be to use poll or epoll even. epoll requires mulitple system calls, whereas the selector seems to only be used only once in most cases, no? Anyway, maybe selectors.DefaultSelector can be used here? About

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

Serhiy Storchaka added the comment: Ah, Victor already have created a PR! -- components: +Library (Lib) -Extension Modules versions: +Python 3.7 -Python 3.6 ___ Python tracker

[issue31609] PCbuild\clean.bat fails if the path contains whitespaces

Change by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue28129] assertion failures in ctypes

STINNER Victor added the comment: Ok, now the issue can be closed :-) I backported Oren Milman's fix to Python 2.7 and 3.6 as well. Oren Milman: thank you very much for your fix! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed

[issue28129] assertion failures in ctypes

STINNER Victor added the comment: New changeset 8b83687bdf66d2d10afb78e46bcede399deaefde by Victor Stinner in branch '2.7': bpo-28129: fix ctypes crashes (#386) (#3800) https://github.com/python/cpython/commit/8b83687bdf66d2d10afb78e46bcede399deaefde --

[issue28129] assertion failures in ctypes

STINNER Victor added the comment: New changeset 7d6ddb96b34b94c1cbdf95baa94492c48426404e by Victor Stinner in branch '3.6': bpo-28129: fix ctypes crashes (#386) (#3799) https://github.com/python/cpython/commit/7d6ddb96b34b94c1cbdf95baa94492c48426404e --

[issue31285] a SystemError and an assertion failure in warnings.warn_explicit()

Change by Oren Milman : -- pull_requests: +3789 ___ Python tracker ___ ___

[issue31158] test_pty: test_basic() fails randomly on Travis CI

Change by STINNER Victor : -- keywords: +patch pull_requests: +3788 stage: -> patch review ___ Python tracker ___

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

Serhiy Storchaka added the comment: I agree. In any case assert is a bad way of checking argument types. It was added in 65b6a80f19736d6313d5eb896d6b2fb6bbf65a03 as a part of migration to Python 3. I guess for debugging purposes. Now it isn't needed,

[issue31158] test_pty: test_basic() fails randomly on Travis CI

STINNER Victor added the comment: Oh, in fact, it's not that hard to reproduce the failure on Linux: haypo@selma$ ./python -m test test_pty -m test_basic -F Run tests sequentially 0:00:00 load avg: 2.17 [ 1] test_pty 0:00:00 load avg: 2.17 [ 2] test_pty 0:00:00

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

Change by STINNER Victor : -- keywords: +patch pull_requests: +3787 stage: -> patch review ___ Python tracker ___

[issue31619] Strange error when convert hexadecimal with underscores to int

New submission from Serhiy Storchaka : >>> int('1_2_3_4_5_6_7_89', 16) 4886718345 >>> int('1_2_3_4_5_6_7_8_9', 16) Traceback (most recent call last): File "", line 1, in ValueError: int string too large to convert -- components: Interpreter Core messages:

[issue28129] assertion failures in ctypes

STINNER Victor added the comment: > Shouldn't we close this issue? Oh, I forgot this issue. Python 2.7 and 3.6 are also impacted and still accept bug fixes. I proposed backports. -- versions: +Python 2.7, Python 3.6 ___

[issue28129] assertion failures in ctypes

Change by STINNER Victor : -- pull_requests: +3786 ___ Python tracker ___ ___

[issue28129] assertion failures in ctypes

Change by STINNER Victor : -- pull_requests: +3785 stage: -> patch review ___ Python tracker ___

[issue11063] Rework uuid module: lazy initialization and add a new C extension

STINNER Victor added the comment: I abandonned my PR and started to review Antoine's PR 3796 which basically combines all previous patches proposed last 6 years :-) -- ___ Python tracker

[issue11063] Rework uuid module: lazy initialization and add a new C extension

Change by STINNER Victor : -- pull_requests: +3784 ___ Python tracker ___ ___

[issue25098] test_uuid fails with pywin32 installed

STINNER Victor added the comment: Zachary: any update on this issue? Is it still a bug? -- nosy: +haypo ___ Python tracker

[issue29729] RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes

Change by STINNER Victor : -- nosy: +serhiy.storchaka title: UUID bytes constructor has too-tight an assertion -> RFE: uuid.UUID(bytes=...): support bytes-like types, not only bytes type: behavior -> enhancement ___ Python

[issue26793] ctypes issue with threads after fork

STINNER Victor added the comment: The bpo-11063 is going to rewrite uuid using a C extension to avoid ctypes, but also defer "import ctypes" until we really need it (when the new C extension is not available). I don't think this issue is related to uuid directly, no?

[issue30977] reduce uuid.UUID() memory footprint

Change by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___

[issue28129] assertion failures in ctypes

Oren Milman added the comment: Shouldn't we close this issue? -- ___ Python tracker ___

[issue11063] Rework uuid module: lazy initialization and add a new C extension

Change by STINNER Victor : -- title: uuid.py module import has heavy side effects -> Rework uuid module: lazy initialization and add a new C extension ___ Python tracker

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: I marked bpo-20519 as a duplicate of this issue, even if it's not exactly the same. The main purpose of this issue was to use uuid_generate_time() using a C extension: +static PyObject * +_uuid_generate_random(void) +{ +uuid_t

[issue20519] Replace uuid ctypes usage with an extension module.

STINNER Victor added the comment: There are too many uuid open issues proposing similar changes. I mark this issue as a duplicate of bpo-11063 to avoid splitted discussions. Please continue the discussion there! -- resolution: -> duplicate stage: patch

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: I marked bpo-5885 as a duplicate of this issue, even if it's not exactly the same. The main purpose of this issue was to use uuid_generate_time() using a C extension, as bpo-20519. +static PyObject * +uuid_uuid1(PyObject *self,

[issue31616] Windows installer: Python binaries are user-writable

R. David Murray added the comment: In fact, this is a backward compatibility issue. Users expect that if you install it in the old location, it behaves like it did in the old location (lower security), and this is probably depended on by a number of users of python.

[issue11063] uuid.py module import has heavy side effects

Antoine Pitrou added the comment: PR 3684 seems mostly a subset of what I'm proposing. -- ___ Python tracker ___

[issue5885] uuid.uuid1() is too slow

STINNER Victor added the comment: Hum, there are many open uuid issues which propose similar changes. I close this issue in favor of bpo-11063. Please continue the discussion there. -- nosy: +haypo resolution: -> duplicate stage: patch review -> resolved

[issue11063] uuid.py module import has heavy side effects

STINNER Victor added the comment: Oh. I was told that the PR 3684 of bpo-5885 in another fix for this issue. -- ___ Python tracker

[issue1350] IDLE - CallTips enhancement - show full doc-string in new window

Change by Mark Lawrence : -- nosy: -BreamoreBoy ___ Python tracker ___ ___

[issue29400] Add instruction level tracing via sys.settrace

George King added the comment: Nick's implementation of f_trace_lines/f_trace_opcodes serves the same purpose as my proposal, and is a simpler solution so I'm abandoning this patch and working with that feature instead. -- stage: test needed -> resolved

[issue31618] Change sys.settrace opcode tracing to occur after frame line number update

George King added the comment: The feature was was implemented in bpo-31344. See bpo-29400 for my parallel effort, which has been abandoned. -- ___ Python tracker

[issue31618] Change sys.settrace opcode tracing to occur after frame line number update

New submission from George King : This patch moves the new opcode tracing added in commit 5a85167 to happen after frame->f_lineno is updated. With this patch, when both f_trace_lines and f_trace_opcodes are enabled the trace function will see the same line number for

[issue31616] Windows installer: Python binaries are user-writable

Pat K added the comment: Thank you for the explanation. I understand this is intentional. However user without such knowledge of inheritable permissions might want to default the installation directory to the old one (C:\PythonXX) and could easily run into this issue

[issue31617] os.path.join() return wrong value in windows

Eryk Sun added the comment: This is explained in the docs: Join one or more path components intelligently If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component. On Windows,

[issue31536] `make regen-all` triggers wholesale rebuild

Change by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.6 ___ Python tracker

  1   2   >