[issue42367] Restore os.makedirs ability to apply mode to all directories created
New submission from Gregory P. Smith : os.makedirs used to pass its mode argument on down recursively so that every level of directory it created would have the specified permissions. That was removed in Python 3.7 as https://bugs.python.org/issue19930 as if it were a mis-feature. Maybe it was in one situation, but it was also a desirable *feature*. It wasn't a bug. We've got 15 year old code depending on that and the only solution for it to work on Python 3.7-3.9 is to reimplement recursive directory creation. :( This feature needs to be brought back. Rather than flip flop on the API, adding an flag to indicate if the permissions should be applied recursively or not seems like the best way forward. The "workaround" documented in the above bug is invalid. umask cannot be used to control the intermediate directory creation permissions as that is a process wide global that would impact other threads or signal handlers. umask also cannot be used as umask does not allow setting of special bits such as stat.S_ISVTX. result: Our old os.makedirs() code that tried to set the sticky bit (ISVTX) on all directories now fails to set it at all levels. -- components: Library (Lib) keywords: 3.7regression messages: 381082 nosy: gregory.p.smith, serhiy.storchaka priority: normal severity: normal stage: needs patch status: open title: Restore os.makedirs ability to apply mode to all directories created type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42367> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42353] Proposal: re.prefixmatch method (alias for re.match)
Gregory P. Smith added the comment: My point is that re.match is a common bug when people really want re.search. re.prefixmatch makes it explicit and non-confusing and thus unlikely to be used wrong or misunderstood when read or reviewed. The term "match" when talking about regular expressions is not normally meant to imply any anchoring as anchors can be expressed within the regex. Python is relatively unique in bothering to have different methods for a prefix match and an anywhere match. (We'd have been better off without a match method entirely, only having search - too late now) -- ___ Python tracker <https://bugs.python.org/issue42353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42353] Proposal: re.prefixmatch method (alias for re.match)
New submission from Gregory P. Smith : A well known anti-pattern in Python is use of re.match when you meant to use re.search. re.fullmatch was added in 3.4 via https://bugs.python.org/issue16203 for similar reasons. re.prefixmatch would be similar: we want the re.match behavior, but want the code to be obvious about its intent. This documents the implicit ^ in the name. The goal would be to allow linters to ultimately flag re.match as the anti-pattern when in 3.10+ mode. Asking people to use re.prefixmatch or re.search instead. This would help avoid bugs where people mean re.search but write re.match. The implementation is trivial. This is **not** a decision to deprecate the widely used in 25 years worth of code's re.match name. That'd be painful and is unlikely to be worth doing without spreading it over a 8+ year timeline. -- components: Library (Lib) messages: 380928 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: Proposal: re.prefixmatch method (alias for re.match) type: enhancement versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue42353> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42329] typing classes do not have __name__ attributes in 3.7+
Gregory P. Smith added the comment: working as intended, they aren't classes. -- resolution: -> rejected stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue42329> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42329] typing classes do not have __name__ attributes in 3.7+
Gregory P. Smith added the comment: Not a big deal if we don't, I just found it odd so I figured I'd pose the question. That it's been in three releases and only just now come up is pretty telling that isn't critical. The code in question was trying to identify public functions in a module by inspecting names and I think they've got a more pedantic way to do that than their existing code that wouldn't be tripped up by a mere callable without a __name__. On Wed, Nov 11, 2020, 8:47 PM Guido van Rossum wrote: > > Guido van Rossum added the comment: > > Between 3.6 and 3.7 they stopped being types. > > IIRC this enabled optimizations. (Serhiy?) > > I don't think this is important, but I suppose you have some code that > this breaks? > > The name is passed to the constructor of _SpecialGenericAlias, so I'm fine > with fixing this, though the backports may get tricky when you get down to > 3.7. > > -- > nosy: +serhiy.storchaka > > ___ > Python tracker > <https://bugs.python.org/issue42329> > ___ > -- ___ Python tracker <https://bugs.python.org/issue42329> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42329] typing classes do not have __name__ attributes in 3.7+
New submission from Gregory P. Smith : Python 3.7-3.10a1: ``` >>> List.__name__ Traceback (most recent call last): File "", line 1, in File "/usr/lib/python3.8/typing.py", line 760, in __getattr__ raise AttributeError(attr) AttributeError: __name__ >>> type(List) >>> type(List[int]) ``` Python 3.6: ``` >>> from typing import List >>> List.__name__ 'List' >>> type(List) >>> type(List[int]) ``` Is this lack of common meta attributes intentional? It makes the typing types unusual. We just saw it trip up some code that was expecting everything to have a `__name__` attribute while moving beyond 3.6. Judging by that `__getattr__` implementation it should happen on other common `__` attributes as mentioned in https://docs.python.org/3/library/stdtypes.html?highlight=__name__#special-attributes as well. -- components: Library (Lib) messages: 380801 nosy: gregory.p.smith priority: normal severity: normal stage: needs patch status: open title: typing classes do not have __name__ attributes in 3.7+ type: behavior versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue42329> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35560] format(float(123), "00") causes segfault in debug builds
Gregory P. Smith added the comment: This bug was introduced into the Python 3.6.8 "bugfix" release. https://github.com/python/cpython/pull/23231 will fix it if anyone needs that on modern 3.6. -- nosy: +gregory.p.smith versions: +Python 3.6 ___ Python tracker <https://bugs.python.org/issue35560> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39892] Enable DeprecationWarnings by default when not explicit in unittest.main()
Gregory P. Smith added the comment: my bad :) -- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue39892> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32682] test_zlib improve version parsing
Change by pmp-p : -- status: closed -> pending ___ Python tracker <https://bugs.python.org/issue32682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8041] No documentation for Py_TPFLAGS_HAVE_STACKLESS_EXTENSION or Py_TPFLAGS_HAVE_VERSION_TAG.
Change by pmp-p : -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue8041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14903] dictobject infinite loop in module set-up
Gregory P. Smith added the comment: I suspect so. If any modern supported python 3.x version runs into an issue like this I think opening a fresh bugreport is good. Closing as not reproducable / obsolete. -- resolution: -> out of date stage: test needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue14903> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41877] Check against misspellings of assert etc. in mock
Gregory P. Smith added the comment: Thanks for the patch! I'm leaving this open as dealing with the other aspect: * Wrong attribute names around asserts: autospect/auto_spec -> autospec, set_spec -> spec_set is still a possibility. (given you also found a number of those in our codebase leading to hidden testing bugs) Vedran: We're not claiming these are fixes for the fundamental problem. But they are useful practical bandaids on the existing APIs that a hundred of millions of lines of existing unittest code around the world make use of to prevent common unintended consequences of our existing API's now well know flaws. issue24651 looks like the better place to take up future design ideas. -- ___ Python tracker <https://bugs.python.org/issue41877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41877] Check against misspellings of assert etc. in mock
Gregory P. Smith added the comment: New changeset 4662fa9bfe4a849fe87bfb321d8ef0956c89a772 by vabr-g in branch 'master': bpo-41877 Check for asert, aseert, assrt in mocks (GH-23165) https://github.com/python/cpython/commit/4662fa9bfe4a849fe87bfb321d8ef0956c89a772 -- ___ Python tracker <https://bugs.python.org/issue41877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24651] Mock.assert* API is in user namespace
Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.6 ___ Python tracker <https://bugs.python.org/issue24651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24651] Mock.assert* API is in user namespace
Change by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker <https://bugs.python.org/issue24651> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41877] Check against misspellings of assert etc. in mock
Change by Gregory P. Smith : -- assignee: -> gregory.p.smith ___ Python tracker <https://bugs.python.org/issue41877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41877] Check against misspellings of assert etc. in mock
Change by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker <https://bugs.python.org/issue41877> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42266] LOAD_ATTR cache does not fully replicate PyObject_GetAttr behavior
Change by pmp-p : -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue42266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Gregory P. Smith added the comment: at a glance, it looks like the PR needs updating. -- ___ Python tracker <https://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42146] subprocess.Popen() leaks cwd in case of uid/gid overflow
Change by Gregory P. Smith : -- resolution: -> fixed stage: patch review -> commit review status: open -> closed ___ Python tracker <https://bugs.python.org/issue42146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42146] subprocess.Popen() leaks cwd in case of uid/gid overflow
Gregory P. Smith added the comment: New changeset d3b4e068077dd26927ae7485bd0303e09d962c02 by Alexey Izbyshev in branch 'master': bpo-42146: Unify cleanup in subprocess_fork_exec() (GH-22970) https://github.com/python/cpython/commit/d3b4e068077dd26927ae7485bd0303e09d962c02 -- ___ Python tracker <https://bugs.python.org/issue42146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42185] class body bytecode uses less efficient *_NAME opcodes
New submission from Gregory P. Smith :
The opcodes generated for the closure defining a class body looks like they
might be suboptimal. It seems stuck using the generic LOAD_NAME and STORE_NAME
opcodes rather than the LOAD_GLOBAL and STORE_FAST and friends as one would
expect and as happens within a normal function closure.
If true and the normal optimization pass (which I believe is done by
`compiler.c` `compiler_nameop()` if i'm understanding this area of the code I
don't know very well correctly...?) is not happening, it _appears_ maybe to be
due to the `PyST_GetScope` call not currently having a way to represent this
situation rather than being in a normal function?
I tried searching for an open issue on this but was at a loss of what to search
for. semi-related concepts might be found in:
https://bugs.python.org/issue34750 - "locals().update doesn't work in Enum
body, even though direct assignment to locals() does"
https://bugs.python.org/issue10399 - "AST Optimization: inlining of function
calls"
https://bugs.python.org/issue9226 - "errors creating classes inside a closure"
None of those is really the same though. if there are other filed issues
regarding this, feel free to link to them in comments.
If this can be improved as it has been for function bodies already, it should
be a measurable improvement to CPython startup time and/or import time.
Especially on larger programs and things with a lot of generated code full of
classes.
```
>>> import dis
>>> klass_def = '''
... class Klassy:
... pinky = 'brain'
... def Funktion(castle_argh):
... __module__ = __name__
... __qualname__ = 'not Klassy'
... pinky = 'brain'
... '''
>>> dis.dis(compile(klass_def, '', 'exec'))
2 0 LOAD_BUILD_CLASS
2 LOAD_CONST 0 (", line 2>)
4 LOAD_CONST 1 ('Klassy')
6 MAKE_FUNCTION0
8 LOAD_CONST 1 ('Klassy')
10 CALL_FUNCTION2
12 STORE_NAME 0 (Klassy)
4 14 LOAD_CONST 2 (", line 4>)
16 LOAD_CONST 3 ('Funktion')
18 MAKE_FUNCTION0
20 STORE_NAME 1 (Funktion)
22 LOAD_CONST 4 (None)
24 RETURN_VALUE
Disassembly of ", line 2>:
2 0 LOAD_NAME0 (__name__)
2 STORE_NAME 1 (__module__)
4 LOAD_CONST 0 ('Klassy')
6 STORE_NAME 2 (__qualname__)
3 8 LOAD_CONST 1 ('brain')
10 STORE_NAME 3 (pinky)
12 LOAD_CONST 2 (None)
14 RETURN_VALUE
Disassembly of ", line
4>:
5 0 LOAD_GLOBAL 0 (__name__)
2 STORE_FAST 1 (__module__)
6 4 LOAD_CONST 1 ('not Klassy')
6 STORE_FAST 2 (__qualname__)
7 8 LOAD_CONST 2 ('brain')
10 STORE_FAST 3 (pinky)
12 LOAD_CONST 0 (None)
14 RETURN_VALUE
```
--
components: Interpreter Core
messages: 379839
nosy: gregory.p.smith, twouters
priority: normal
severity: normal
stage: needs patch
status: open
title: class body bytecode uses less efficient *_NAME opcodes
type: performance
versions: Python 3.10
___
Python tracker
<https://bugs.python.org/issue42185>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42096] zipfile.is_zipfile incorrectly identifying a gzipped file as a zip archive
Gregory P. Smith added the comment: The first four bytes of the file do not identify a zip file. A zip file is identified by the end of file central directory. Which you then must read entries of to determine where the start of the archive may be... often not at position zero. -- ___ Python tracker <https://bugs.python.org/issue42096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42096] zipfile.is_zipfile incorrectly identifying a gzipped file as a zip archive
Gregory P. Smith added the comment: ZipFile.open() is not the code for opening a zip file. :) That's the code for opening a file embedded within an already constructed mode='r' archive as done the ZipFile.__init__() constructor. By the time you've gotten to the open() method, you've loaded the entire unbounded in size central directory into memory as ZipInfo objects [constructor] and are checking signature of an individual file header you are attempting to read out of the archive. Follow the ZipFile() constructor, it calls ZipFile._RealGetContents() which is the true start of parsing the archive. https://github.com/python/cpython/blob/master/Lib/zipfile.py#L1317 Sure, more and more steps can be done. But if you want to do that, you may as well just get rid of is_zipfile() entirely - a functions who's point is to be fast and not consume an amount of memory determined by the input data - and have people just call `zipfile.ZipFile(path_in_question, mode='r')` and live with the consequences of attempting to load and parse the whole thing. If that doesn't raise an exception, it is more likely to be a zip file. But that could still raise an exception when trying to open each of the files inside, so you'd need to iterate over this and open those and make sure they're valid. is_zipfile() isn't a verify_zipfile_integrity() routine. Just a quick best guess. is_zipfile() cannot be perfect and is not intended to be. There is always going to be yet another thing it _could_ try. It isn't worth chasing the impossible goal and making it not be fast. Just update the is_zipfile() docs. -- ___ Python tracker <https://bugs.python.org/issue42096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42146] subprocess.Popen() leaks cwd in case of uid/gid overflow
Gregory P. Smith added the comment: New changeset c0590c0033e86f98cdf5f2ca6898656f98ab4053 by Alexey Izbyshev in branch 'master': bpo-42146: Fix memory leak in subprocess.Popen() in case of uid/gid overflow (GH-22966) https://github.com/python/cpython/commit/c0590c0033e86f98cdf5f2ca6898656f98ab4053 -- ___ Python tracker <https://bugs.python.org/issue42146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment:
Performance improvement measured on a 1.4Ghz quad aarch64 A57 (nvidia jetson
nano):
#define VFORK_USABLE 1
test_subprocess: 36.5 seconds
#undef VFORK_USABLE
test_subprocess: 45 seconds
Nice. I really didn't expect a 20% speedup on its testsuite alone!
Lets dive into that with a microbenchmark:
$ ./build-novfork/python ten_seconds_of_truth.py
Launching /bin/true for 10 seconds in a loop.
Launched 2713 subprocesses in 10.00194378796732 seconds.
271.247275281014 subprocesses/second.
Increased our mapped pages by 778240KiB.
Launching /bin/true for 10 seconds in a loop.
Launched 212 subprocesses in 10.006392606999725 seconds.
21.186456331095847 subprocesses/second.
$ ./build/python ten_seconds_of_truth.py
Launching /bin/true for 10 seconds in a loop.
Launched 3310 subprocesses in 10.001623224001378 seconds.
330.94628000551285 subprocesses/second.
Increased our mapped pages by 778240KiB.
Launching /bin/true for 10 seconds in a loop.
Launched 3312 subprocesses in 10.001519071985967 seconds.
331.1496959773679 subprocesses/second.
Demonstrating perfectly the benefit of vfork(). The more mapped pages, the
slower regular fork() becomes. With vfork() the size of the process's memory
map does not matter.
ten_seconds_of_truth.py:
```python
from time import monotonic as now
import subprocess
def benchmark_for_ten():
print('Launching /bin/true for 10 seconds in a loop.')
count = 0
start = now()
while now() - start < 10.:
subprocess.run(['/bin/true'])
count += 1
end = now()
duration = end-start
print(f'Launched {count} subprocesses in {duration} seconds.')
print(f'{count/duration} subprocesses/second.')
benchmark_for_ten()
map_a_bunch_of_pages = '4agkahglahaa^#\0ag3\3'*1024*1024*40
print(f'Increased our mapped pages by {len(map_a_bunch_of_pages)//1024}KiB.')
benchmark_for_ten()
```
--
___
Python tracker
<https://bugs.python.org/issue35823>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment: Nice links. LOL, yes, musl source was going to be my next stop if the larger libc sources proved impossible for a mere mortal to reason about. :) regarding macOS, agreed. If someone needs vfork() to work there, I believe it could be made to. Options like selecting the architecture of the child process could be higher level options to the subprocess API. Hiding the platform specific details of how that happens and deciding which underlying approach to use based on the flags. multi-arch systems are a thing. It is conceivable that we may even see non-esoteric multi-arch hardware at some point. -- ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment: New changeset be3c3a0e468237430ad7d19a33c60d306199a7f2 by Gregory P. Smith in branch 'master': bpo-35823: Allow setsid() after vfork() on Linux. (GH-22945) https://github.com/python/cpython/commit/be3c3a0e468237430ad7d19a33c60d306199a7f2 -- ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42096] zipfile.is_zipfile incorrectly identifying a gzipped file as a zip archive
Gregory P. Smith added the comment: for what it's worth: false positives are always going to be possible in any such "magic" check as is_zipfile is. we don't check the start of the file because zip files are defined by their end of file central directory which contains length information to determine where within the file the zip archive actually starts. The issue28494 tests are a demonstration of this; It is somewhat common practice to append a zipfile to an executable of various forms for use as application specific data. If you need more more reliable determination of file type not tied to a specific Python release, you might look at what the various file type sniffing magic libraries do for you, some examples include: https://pypi.org/project/filetype/ https://pypi.org/project/puremagic/ https://pypi.org/project/python-magic/ I _can_ reproduce this issue with the testdata @bckohan provided. But I can't promise there is anything to fix here. Even if we make the test slightly more robust by looking at another byte or two, it is always possible for files to appear to be a bunch of things at once based on small data signatures. If nothing else we should reinforce in the documentation that is_zipfile is at best a guess. False means it is not as far as the zipfile module is concerned. True cannot guarantee that it is. -- ___ Python tracker <https://bugs.python.org/issue42096> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Change by Gregory P. Smith : -- pull_requests: +21863 pull_request: https://github.com/python/cpython/pull/22945 ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment: regarding excluding the setsid() case: I was being conservative as I couldn't find a reference of what was and wasn't allowed after vfork. I found one thing suggesting that on macOS setsid() was not safe after vfork(). But that appeared to be a Darwin-ism. I expect that is not true on Linux as it should just be a syscall updating a couple of fields in the process info. Confirming, in glibc is appears to be a shim for the setsid syscall (based on not finding any code implementing anything special for it) and in uclibc (*much* easier to read) it is clearly just a setsid syscall shim. I'll make a PR to undo the setsid restriction given we're Linux only. -- ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment: New changeset 473db47747bb8bc986d88ad81799bcbd88153ac5 by Alexey Izbyshev in branch 'master': bpo-35823: subprocess: Fix handling of pthread_sigmask() errors (GH-22944) https://github.com/python/cpython/commit/473db47747bb8bc986d88ad81799bcbd88153ac5 -- ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment: Thank you for taking this on! I'm calling it fixed for now as the buildbots are looking happy with it. If issues with it arise we can address them. -- resolution: -> fixed stage: commit review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment: > * To avoid repeating long parameter lists in several functions, we can move > them to a struct. The downside is that we'd need to convert child_exec() to > use that struct all over the place. I don't have a strong preference here. Agreed that the long parameter lists are annoying. I don't like shoving that much on the stack and by adding an additional call with so many params we've increase stack usage. I consider this refactoring work that can be done on its own outside of this issue though. > * Are any documentation changes needed? We don't change any interfaces, so > I'm not sure. I don't think so. I looked things over and I think all that is needed is the existing Misc/NEWS entry. > Potential future directions: > > * If desired, a vfork() opt-out may be implemented. But it'd need to disable > posix_spawn() on Linux as well, since it might be implemented via vfork(), > and we have no good way to check that. We have such an opt-out capabilty for posix_spawn via `subprocess._USE_POSIX_SPAWN` https://github.com/python/cpython/blob/master/Lib/subprocess.py#L651 along with code in there that determines the default value based on the detected runtime environment. I'm not sure we'll need that for vfork() as it seems to pretty much be a low level raw system call wrapper rather than something to be implemented via libc that can have its own bugs. If we do wind up wanting one, I'd structure it the same way. -- ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment: now waiting to see how happy all of the buildbots are... We currently have a `__linux__` check in the code deciding VFORK_USABLE. >From what I can tell, vfork probably also works on macOS (darwin). Lets let this run for a bit on Linux and it can be a separate issue to open vfork usage up to other platforms. -- stage: patch review -> commit review ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35823] Use vfork() in subprocess on Linux
Gregory P. Smith added the comment: New changeset 976da903a746a5455998e9ca45fbc4d3ad3479d8 by Alexey Izbyshev in branch 'master': bpo-35823: subprocess: Use vfork() instead of fork() on Linux when safe (GH-11671) https://github.com/python/cpython/commit/976da903a746a5455998e9ca45fbc4d3ad3479d8 -- ___ Python tracker <https://bugs.python.org/issue35823> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42097] Python 3.7.9 logging/threading/fork hang
Gregory P. Smith added the comment:
If you use os.fork() or any of the multiprocessing start methods that call
os.fork() with a process involving threads, this is expected behavior.
os.fork() cannot be used in processes that have threads without potential for
deadlock.
Specifically, make sure you explicitly call:
multiprocessing.set_start_method('spawn')
before using multiprocessing in any application where threads exist.
It is possible to use 'forkserver' as well, but only if you ensure the
multiprocessing forkserver process is started before your application has
launched any threads.
--
___
Python tracker
<https://bugs.python.org/issue42097>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41586] Allow to set pipe size on subprocess.Popen.
Change by Gregory P. Smith : -- resolution: -> fixed stage: patch review -> commit review status: open -> closed ___ Python tracker <https://bugs.python.org/issue41586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41586] Allow to set pipe size on subprocess.Popen.
Gregory P. Smith added the comment: New changeset 786addd9d07b6c712b8ea9ee06e1f9f41c1b67a1 by Gregory P. Smith in branch 'master': bpo-41586: Attempt to make the pipesize tests more robust. (GH-22839) https://github.com/python/cpython/commit/786addd9d07b6c712b8ea9ee06e1f9f41c1b67a1 -- ___ Python tracker <https://bugs.python.org/issue41586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41586] Allow to set pipe size on subprocess.Popen.
Change by Gregory P. Smith : -- pull_requests: +21793 stage: commit review -> patch review pull_request: https://github.com/python/cpython/pull/22839 ___ Python tracker <https://bugs.python.org/issue41586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41586] Allow to set pipe size on subprocess.Popen.
Gregory P. Smith added the comment: this caused a variety of buildbot failures. investigating. -- resolution: fixed -> status: closed -> open ___ Python tracker <https://bugs.python.org/issue41586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38456] Reduce the time test_subprocess takes to complete.
Gregory P. Smith added the comment:
fyi - handy command to get that
python -m test.regrtest -v test_subprocess | ts '.%s'
then process that using whatever you want to compute deltas and sort. i fed
the output of that into:
```
#!/usr/bin/python3
"""Parse `python -m test.regrtest -v | ts '.%s'` output, report slowest."""
import sys
from typing import Sequence, Tuple
infile = sys.stdin
deltas: Sequence[Tuple[float, str]] = []
prev_secs: float = 0.
prev_test: str = ''
for line in infile:
stripped_line = line.strip()
if ' ' not in stripped_line:
continue
num, test = stripped_line.split(None, 1)
secs = float(num)
delta = secs - prev_secs if prev_secs else 0.
if '... ok' or '... skipped' in test: # Not extraneous output.
# Assign the accumulated time to the previous test.
deltas.append((delta, prev_test))
prev_secs = secs
prev_test = test
for secs, test in reversed(sorted(deltas, key=lambda x:x[0])[-23:]):
print(f'{secs:.3} {test}')
```
--
___
Python tracker
<https://bugs.python.org/issue38456>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38456] Reduce the time test_subprocess takes to complete.
Gregory P. Smith added the comment: the slowest tests on Linux today (with number of seconds prepended on my system that runs the suite serially in 34 seconds on a debug build): 3.01 test_check_output_stdout_arg (test.test_subprocess.ProcessTestCaseNoPoll) ... ok 3.01 test_check_output_stdout_arg (test.test_subprocess.ProcessTestCase) ... ok 3.0 test_check_output_stdin_with_input_arg (test.test_subprocess.RunFuncTestCase) ... ok 2.28 test_issue8780 (test.test_subprocess.ProcessTestCase) ... ok 2.27 test_issue8780 (test.test_subprocess.ProcessTestCaseNoPoll) ... ok 2.04 test_communicate_BrokenPipeError_stdin_write (test.test_subprocess.POSIXProcessTestCase) ... ok 1.45 test_leak_fast_process_del_killed (test.test_subprocess.POSIXProcessTestCase) ... ok 1.04 test_communicate_stdout (test.test_subprocess.ProcessTestCase) ... ok 1.03 test_communicate_stdout (test.test_subprocess.ProcessTestCaseNoPoll) ... ok 1.03 test_kill (test.test_subprocess.POSIXProcessTestCase) ... ok 1.03 test_send_signal (test.test_subprocess.POSIXProcessTestCase) ... ok 1.03 test_terminate (test.test_subprocess.POSIXProcessTestCase) ... ok 0.636 test_communicate_timeout (test.test_subprocess.ProcessTestCase) ... ok 0.636 test_communicate_timeout (test.test_subprocess.ProcessTestCaseNoPoll) ... ok 0.58 test_swap_fds (test.test_subprocess.POSIXProcessTestCase) ... ok -- ___ Python tracker <https://bugs.python.org/issue38456> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40380] OS-related test failures on Linux in Python 3.8.2
Change by Gregory P. Smith : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40380> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1260171] subprocess: more general (non-buffering) communication
Gregory P. Smith added the comment: since the time this was filed, subprocess has evolved a lot and third party options for child process have appeared as well as modern things like: https://docs.python.org/3/library/asyncio-subprocess.html (stdlib) https://trio.readthedocs.io/en/stable/reference-io.html?highlight=subprocess#options-for-starting-subprocesses (trio, easier async framework to use than asyncio) plumbing stdin/stdout/stderr data to python file-like objects from the stdlib subprocess APIs themselves is better left to third party solutions building on top of the subprocess module today. -- assignee: -> gregory.p.smith nosy: +gregory.p.smith resolution: -> wont fix stage: test needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue1260171> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27898] regexp performance degradation between 2.7.6 and 2.7.12
Gregory P. Smith added the comment: 2.7 is end of life. if you have regular expression performance issues with something in 3, please open a new issue. -- nosy: +gregory.p.smith resolution: -> wont fix stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue27898> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue13501> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40133] Provide additional matchers for unittest.mock
Gregory P. Smith added the comment: based on the reaction from those who own mock at this point, i'm going to close this. shipping more handy mock matchers with mock makes sense to me as they belong together. but i'm not willing to argue it if anyone thinks it'll be a maintenance burden within the stdlib. -- resolution: -> rejected stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36541] Make lib2to3 grammar better match Python, support the := walrus
Gregory P. Smith added the comment: Parsing support for `f(**mapping)` support is indeed still missing. as lib2to3 is pending deprecation at this point, i'm not going to work on this. anyone is welcome to pick it up. modifying the lib2to3 grammar, and any related code, and adding a test is what's needed to parse that syntax. -- assignee: gregory.p.smith -> stage: patch review -> needs patch versions: +Python 3.10 -Python 3.7 ___ Python tracker <https://bugs.python.org/issue36541> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41586] Allow to set pipe size on subprocess.Popen.
Gregory P. Smith added the comment: Thanks Ruben! -- resolution: -> fixed stage: patch review -> commit review status: open -> closed type: -> enhancement ___ Python tracker <https://bugs.python.org/issue41586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41586] Allow to set pipe size on subprocess.Popen.
Gregory P. Smith added the comment: New changeset 23c0fb8edd16fe6d796df2853a5369fd783e05b7 by Ruben Vorderman in branch 'master': bpo-41586: Add pipesize parameter to subprocess & F_GETPIPE_SZ and F_SETPIPE_SZ to fcntl. (GH-21921) https://github.com/python/cpython/commit/23c0fb8edd16fe6d796df2853a5369fd783e05b7 -- ___ Python tracker <https://bugs.python.org/issue41586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40360] Deprecate lib2to3 (and 2to3) for future removal
Gregory P. Smith added the comment: status: lib2to3 PendingDeprecationWarning shipped in 3.9. Since we don't have a specific release planned for the final deprecation, I'll leave this issue open while we figure that out. Once we do, we should promote this to a regular DeprecationWarning in whichever release is next at that time. -- versions: -Python 3.9 ___ Python tracker <https://bugs.python.org/issue40360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40360] Deprecate lib2to3 (and 2to3) for future removal
Change by Gregory P. Smith : -- assignee: gregory.p.smith -> stage: patch review -> ___ Python tracker <https://bugs.python.org/issue40360> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40423] Optimization: use close_range(2) if available
Gregory P. Smith added the comment: thanks Kyle! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38693] Use f-strings instead of str.format within importlib
Gregory P. Smith added the comment: Status: Waiting until after the importlib.metadata and importlib.resources backports drop support for both Python 2.7 and 3.5 as keeping them in sync would be a pain for maintainers (per jaraco on our sprint importlib-any chat today) -- ___ Python tracker <https://bugs.python.org/issue38693> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38693] Use f-strings instead of str.format within importlib
Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue38693> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36179] _hashopenssl has reference leaks in OOM case
Change by Gregory P. Smith : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue36179> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41972] bytes.find consistently hangs in a particular scenario
Gregory P. Smith added the comment: I assume a rolling hash is linear at best, even if you do add some skip ahead checks. -- ___ Python tracker <https://bugs.python.org/issue41972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41972] bytes.find consistently hangs in a particular scenario
Gregory P. Smith added the comment: Another potential algorithm to consider in large needle situations is a Rabin-Karp rolling hash string search. If used, it's the kind of algorithm that I'd probably bail out to an alternate method on if a run of Rabin-Karp started having a high percentage of false positive failed comparisons (suggesting data antagonistic to the chosen rolling hash algorithm(s) which would degenerate performance back to Needle*Haystack territory). -- ___ Python tracker <https://bugs.python.org/issue41972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41972] bytes.find consistently hangs in a particular scenario
Gregory P. Smith added the comment: FWIW I think your numbers look good, a small needle cut-off is likely a good idea. -- ___ Python tracker <https://bugs.python.org/issue41972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41972] bytes.find consistently hangs in a particular scenario
Change by Gregory P. Smith : -- nosy: +gregory.p.smith ___ Python tracker <https://bugs.python.org/issue41972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Covariance matrix syntax
I think the np.cov is from the numpy module (imported/aliased as np?). If so, the numpy repository should have what you are looking for: https://github.com/numpy/numpy/blob/156cd054e007b05d4ac4829e10a369d19dd2b0b1/numpy/lib/function_base.py#L2276 Hope that helps Bruno On Tuesday, 13 October 2020, 5:38:55 pm NZDT, Meghna Karkera wrote: May I know the steps or procedure behind covariance matrix syntax, np.cov(covar_matrix) in python -- https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
[issue40422] Light refactor: create a common _Py_closerange API
Gregory P. Smith added the comment: New changeset 64eb259cc1e42a5f74b5911a518d2c50daa8d50b by Kyle Evans in branch 'master': bpo-40422: Move _Py_*_SUPPRESS_IPH bits into _Py_closerange (GH-22672) https://github.com/python/cpython/commit/64eb259cc1e42a5f74b5911a518d2c50daa8d50b -- ___ Python tracker <https://bugs.python.org/issue40422> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40422] Light refactor: create a common _Py_closerange API
Gregory P. Smith added the comment: Just reuse this bpo issue. I'll mark the PRs as "skip news"; don't worry about a new news blurb entry as it's all tied to the original one. -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue40422> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38110] Use fdwalk() within os.closerange() impl if available
Change by Gregory P. Smith : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40423] Optimization: use close_range(2) if available
Change by Gregory P. Smith : -- assignee: -> gregory.p.smith ___ Python tracker <https://bugs.python.org/issue40423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40423] Optimization: use close_range(2) if available
Gregory P. Smith added the comment: Ah, yeah ENOSYS is it. I had to do this trick in older subprocess versions for something else. Still visible here in the old 2.7 backport: https://github.com/google/python-subprocess32/blob/main/_posixsubprocess.c#L801 -- ___ Python tracker <https://bugs.python.org/issue40423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40422] Light refactor: create a common _Py_closerange API
Change by Gregory P. Smith : -- stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40422> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40422] Light refactor: create a common _Py_closerange API
Change by Gregory P. Smith : -- assignee: -> gregory.p.smith nosy: +gregory.p.smith ___ Python tracker <https://bugs.python.org/issue40422> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40423] Optimization: use close_range(2) if available
Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.9 ___ Python tracker <https://bugs.python.org/issue40423> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40423] Optimization: use close_range(2) if available
Gregory P. Smith added the comment:
for reference, very recent Linux kernels appear to have gained a close_range
syscall. http://lkml.iu.edu/hypermail/linux/kernel/2008.0/02649.html
Your diff isn't quite sufficient as is. When depending on a syscall that has a
function provided by libc, the libc function may exist (thus HAVE_CLOSE_RANGE
will be true at Python compile time) but the system the process is running on
may not support the system call. So it'll return an EINVAL (or something like
that) error.
Special handling of that error to add an `else {...}` falling back to the other
codepath is necessary.
--
nosy: +gregory.p.smith
___
Python tracker
<https://bugs.python.org/issue40423>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34706] Signature.from_callable sometimes drops subclassing
Change by Gregory P. Smith : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue34706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38153] Normalize hashing algorithm names
Gregory P. Smith added the comment: looks like it, thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue38153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41972] bytes.find consistently hangs in a particular scenario
Change by pmp-p : -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue41972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7946] Convoy effect with I/O bound threads and New GIL
Gregory P. Smith added the comment: It's a known issue and has been outlined very well and still comes up from time to time in real world applications, which tend to see this issue and Dave's presentation and just work around it in any way possible for their system and move on with life. Keeping it open even if nobody is actively working on it makes sense to me as it is still a known issue that could be resolved should someone have the motivation to complete the work. -- versions: +Python 3.10 -Python 3.9 ___ Python tracker <https://bugs.python.org/issue7946> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36125] Cannot cross-compile to more featureful but same tune
Change by pmp-p : -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue36125> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with a non-system libffi?
Change by pmp-p : -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue14527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with a non-system libffi?
Change by pmp-p : -- nosy: -pmpp ___ Python tracker <https://bugs.python.org/issue14527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32682] test_zlib improve version parsing
Change by pmp-p : -- pull_requests: +21399 pull_request: https://github.com/python/cpython/pull/22361 ___ Python tracker <https://bugs.python.org/issue32682> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19915] int.bit_at(n) - Accessing a single bit in O(1)
Change by pmp-p : -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue19915> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9146] Segfault in hashlib in OpenSSL FIPS mode using non-FIPS-compliant hashes, if "ssl" imported before "hashlib"
Change by Gregory P. Smith : -- stage: backport needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue9146> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37408] [DOC] Precise that Tarfile "format" argument only concerns writing.
Change by Gregory P. Smith : -- resolution: -> fixed stage: backport needed -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue37408> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35243] readline timeout too long for async gfx use
Change by pmp-p : -- versions: +Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue35243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14527] How to link with a non-system libffi?
Change by pmp-p : -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue14527> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19081] zipimport behaves badly when the zip file changes while the process is running
Gregory P. Smith added the comment: On POSIX systems, keeping the file open means you will keep a handle to the original file in the case where something moves a new file into it's place (as is normal during software package updates) or otherwise unlinks the original. That is the situation that led to filing this issue and is one that is technically solvable by keeping the file handle open and always using that for access. We can't do anything very meaningful about someone opening the existing file in 'w+a' mode and scribbling other bytes over it. I wouldn't try to protect against that. "locking" a file isn't an option on most platforms and when available, is very unusual to do in this century. -- ___ Python tracker <https://bugs.python.org/issue19081> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41770] Import module doesn't updated
Change by pmp-p : -- nosy: -pmpp ___ Python tracker <https://bugs.python.org/issue41770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41770] Import module doesn't updated
pmp-p added the comment: Hi, you just need to call del sys.modules['xxx'] and have a look at https://docs.python.org/3.7/library/importlib.html#importlib.invalidate_caches before importing again -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue41770> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Change by pmp-p : -- pull_requests: +21251 stage: -> patch review pull_request: https://github.com/python/cpython/pull/22190 ___ Python tracker <https://bugs.python.org/issue14916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
Change by pmp-p : -- versions: +Python 3.6, Python 3.7, Python 3.8, Python 3.9 -Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <https://bugs.python.org/issue14916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29988] with statements are not ensuring that __exit__ is called if __enter__ succeeds
Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.8 ___ Python tracker <https://bugs.python.org/issue29988> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14916] PyRun_InteractiveLoop fails to run interactively when using a Linux pty that's not tied to stdin/stdout
pmp-p added the comment: all PyRun_InteractiveOne* functions are also affected it is really annoying when implementing repl behaviour when embedding( use cases : pyodide, android, wasi ) But I think the correct patch is : -char *newtok = PyOS_Readline(stdin, stdout, tok->prompt); +char *newtok = PyOS_Readline(tok->fp? tok->fp : stdin, stdout, tok->prompt); -- nosy: +pmpp ___ Python tracker <https://bugs.python.org/issue14916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41642] Buildbot: workers detached every minute and "no space left on device" issue
Gregory P. Smith added the comment: The gps-* bots have been updated. -- nosy: +gregory.p.smith ___ Python tracker <https://bugs.python.org/issue41642> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in the standard library should be sanitized on fork
Change by Gregory P. Smith : -- pull_requests: -21110 ___ Python tracker <https://bugs.python.org/issue6721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36533] logging regression with threading + fork are mixed in 3.7.1rc2 (deadlock potential)
Change by Gregory P. Smith : -- pull_requests: -2 ___ Python tracker <https://bugs.python.org/issue36533> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4356] Add "key" argument to "bisect" module functions
Change by Gregory P. Smith : -- versions: +Python 3.10 -Python 3.9 ___ Python tracker <https://bugs.python.org/issue4356> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41586] Allow to set pipe size on subprocess.Popen.
Change by Gregory P. Smith : -- assignee: -> gregory.p.smith nosy: +gregory.p.smith ___ Python tracker <https://bugs.python.org/issue41586> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41566] Include much faster DEFLATE implementations in Python's gzip and zlib libraries. (isa-l)
Gregory P. Smith added the comment: fwiw, no PEP is needed for things like this. it'd just be an alternative library implementing the core of the zlib and/or gzip modules behind the scenes. normally this kind of thing would be done using a check for the availability of the library in configure.ac with conditional compilation via #ifdef's from the configure output that controls what is set in pyconfig.h in the zlib and gzip modules itself. Within the stdlib, I'd focus only on using things that can be used in a 100% api compatible way with the existing modules. Otherwise creating a new module and putting it up on PyPI to expose the functionality from the libraries you want makes sense and will be easier to make available to everyone on existing Python versions rather than waiting on getting something into CPython. FWIW I tend to avoid software provided by Intel given any other choice. Look instead at Chromium's zlib as discussed in https://github.com/madler/zlib/issues/346 or possibly at a project like https://github.com/zlib-ng/zlib-ng. These are much more likely to be drop in zlib replacements making this simply a build time thing which is more a matter of making sure we get the relevant compiler flags correct when the faster libraries are detected by configure.ac as available. There is a caveat to using any of these: how well maintained and security vetted are all of the code paths in the implementation? zlib proper gets massive security attention. Its low rate of change and staleness are a feature. Chromium's zlib also gets proper security attention. No idea about zlib-ng and even less about Intels self serving arm-ignoring oddity. -- nosy: +gregory.p.smith stage: patch review -> needs patch ___ Python tracker <https://bugs.python.org/issue41566> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41566] Include much faster DEFLATE implementations in Python's gzip and zlib libraries. (isa-l)
Change by Gregory P. Smith : -- pull_requests: -21037 ___ Python tracker <https://bugs.python.org/issue41566> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
Gregory P. Smith added the comment: While this is present in 3.7 (and earlier?), 3.7 is EOL - security fix only stage. the 3.8 and 3.9 PRs should automerge after CI finishes. please reopen the issue or ping me on those PRs if they somehow fail to do so. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue31122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31122] SSLContext.wrap_socket() throws OSError with errno == 0
Gregory P. Smith added the comment: Thanks! fyi for confirmation incase anyone doubted: >>> issubclass(ssl.SSLEOFError, OSError) True So from a code point of view, anything already catching the error still catches the error. 100% bugfix. -- assignee: christian.heimes -> gregory.p.smith ___ Python tracker <https://bugs.python.org/issue31122> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
