[issue9148] os.execve puts process to background on windows

Thomas Sibley added the comment: What about using _execv*() and friends, as documented at ? They appear to use the process overlay feature of _spawnv*() et al., as described at

[issue9148] os.execve puts process to background on windows

Thomas Sibley added the comment: It seems like it would be very nice to provide compat if its possible with a minimum of effort. At the very least, a doc patch to os.exec*() seems warranted. I expected to find notes on platform compat in the doc and was pleasantly surprised to see the indi

[issue9148] os.execve puts process to background on windows

Eryk Sun added the comment: nt.execv[e] wraps calling the C runtime _wexecv[e] function. The other os.exec* functions are in turn based on these calls. As to spawn, for Windows _P_OVERLAY just means to exit the current process. The source code is published, so you can see how simple the impl

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

New submission from Alexey Izbyshev : The compressor/decompressor classes from bz2 and lzma modules rely on __init__() for initialization, but it is not guaranteed to be called. Method calls on an uninitialized object crash: >>> from bz2 import BZ2Compressor as C >>> c = C.__new__(C) >>> c.co

[issue9148] os.execve puts process to background on windows

Thomas Sibley added the comment: Thanks for taking the time to explain. I was just discovering the same myself experimentally. The MS docs I linked to seem a little misleading. orz In that case, do you think a doc patch for os.exec* adding a more nuanced take on Windows support would be co

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

Berker Peksag added the comment: I think we usually went with option 1 when we fixed similar issues in the past. See also issue 23224 for the same problem in *Decompressor classes of lzma and bz2 modules. It looks like the attached PR to that issue went with option 2: PR 7822. Perhaps we ca

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

Alexey Izbyshev added the comment: I somehow failed to notice #23224 when I searched the tracker. You're right, it's the same, and, moreover, PR 7822 fixes problem with both compressors and decompressors (though it includes tests only for the latter for some reason). I think that this report

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

Alexey Izbyshev added the comment: Reclosing (browser cache problem). -- resolution: -> duplicate stage: needs patch -> resolved status: open -> closed ___ Python tracker ___

[issue34729] bz2/lzma: Compressor/decompressor crash if __init__ is not called

Berker Peksag added the comment: We can definitely make the title of that issue more descriptive. Feel free to change it -- IIRC, you don't need additional permissions to change the title of an issue. Thanks! -- ___ Python tracker

[issue34663] Support POSIX_SPAWN_USEVFORK flag in posix_spawn

Gregory P. Smith added the comment: Give all of this, the lesson I'd take away is perhaps that we should just provide the constant in the os module when available at build time (a configure check) and let people who find a need to use it on their system check for its presence and use it in t

[issue23224] bz2/lzma: Compressor/Decompressor objects are only initialized in __init__

Alexey Izbyshev added the comment: bz2 in 2.7 is also affected. Victor, do we want to fix the crash at all in stable branches? If yes, IMHO taking the slight risk of __init__ -> __new__ change is preferable to taking the trouble to implement the alternative backwards-compatible fix (init che

[issue34730] aclose() doesn't stop raise StopAsyncIteration / GeneratorExit to __anext__()

New submission from Devin Fee : I expected an async-generator's aclose() method to cancel it's __anext__(). Instead, the task isn't cancelled, and (it seems) manually cleanup is necessary. @pytest.mark.asyncio async def test_aclose_cancels(): done = False event = asyncio.Event() a

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

Change by Ned Deily : -- versions: +Python 3.7 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue13285] signal module ignores external signal changes

Nathaniel Smith added the comment: Here's another case where this bug bites us: https://github.com/python-trio/trio/issues/673 At startup, Trio checks if SIGINT is currently being handled by Python's default SIGINT handler, and if so it substitutes its own SIGINT handler (which works just l

[issue34731] pathlib path.match misshandles multiple `**`

New submission from Ronny Pfannschmidt : when porting parts of pytest to pathlib we noted that `path.match` does not quite match normal fnmatch for usages of `**` i believe this is related to always splitting the patter completely and not handling `**` in that case Bruno wrote https://githu

[issue17239] XML vulnerabilities in Python

Benjamin Peterson added the comment: On Tue, Sep 18, 2018, at 06:39, STINNER Victor wrote: > > STINNER Victor added the comment: > > > Who normally updates the vendored libexpat? > > I made the 3 latest libexpat updates, and each of them was painful :-) Oh? I've updated it twice (4e21100fa

[issue34731] pathlib path.match misshandles multiple `**`

Berker Peksag added the comment: Thanks for the report. This looks like a duplicate of issue 29249. -- nosy: +berker.peksag ___ Python tracker ___

[issue34730] aclose() doesn't stop raise StopAsyncIteration / GeneratorExit to __anext__()

Devin Fee added the comment: I've worked around this problem by doing something like this: async def close_cancelling(agen): while True: try: task = asyncio.ensure_future(agen.__anext__()) await task yield task.result() except (GeneratorE

[issue34585] Don't use AC_RUN_IFELSE to determine float endian

Benjamin Peterson added the comment: New changeset 2a9c3805ddedf282881ef7811a561c70b74f80b1 by Benjamin Peterson (Ross Burton) in branch 'master': closes bpo-34585: Don't do runtime test to get float byte order. (GH-9085) https://github.com/python/cpython/commit/2a9c3805ddedf282881ef7811a561c

[issue25711] Rewrite zipimport from scratch

Serhiy Storchaka added the comment: New changeset 9da3961f364da2a3ced740230b85ffb4309238d3 by Serhiy Storchaka in branch 'master': bpo-25711: Move _ZipImportResourceReader from importlib to zipimport. (GH-9406) https://github.com/python/cpython/commit/9da3961f364da2a3ced740230b85ffb4309238d3

[issue34732] uuid returns version more than 5

New submission from jophine antony : When I validate the invalid uuid (RFC 4122 variant) for example '481a8de5-f0d1-f211-b425-e41f134196da'. It returns version number as 15 which is invalid. We need to retrun None in this case as we do for invalid UUIDs based on RFC 4122. --snip snip---

[issue34585] Don't use AC_RUN_IFELSE to determine float endian

Benjamin Peterson added the comment: New changeset b3b8cb419e496629873fa7dda82a01863f58617a by Benjamin Peterson in branch 'master': run autoconf (GH-9411) https://github.com/python/cpython/commit/b3b8cb419e496629873fa7dda82a01863f58617a -- ___ P

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

Nick Coghlan added the comment: Victor, no - you've completely broken PEP 538 now. Please just give up, and implement the PEP as written, and stop trying to use your copious amounts of available development time to railroad me. -- ___ Python track

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

Nick Coghlan added the comment: 3.7.1 should not ship until PEP 538 is once more implemented as documented, without Victor's personal editorialising and feature additions to a maintenance release. -- ___ Python tracker

[issue23327] zipimport to import from non-ascii pathname on Windows

Serhiy Storchaka added the comment: Thank you for your patch Swapneel, but this issue was fixed in issue25758. -- nosy: +serhiy.storchaka resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker

[issue34589] Py_Initialize() and Py_Main() should not enable C locale coercion

Nick Coghlan added the comment: The only reason this got through my original review was because PEP 540 was implemented when I was going through a personal situation that lead to me quitting my job cold without a new one to go to, so my review of Victors changes to the PEP 538 implementation

<    1   2