[issue47158] logging.handlers.SysLogHandler doesn't get cleaned up properly on exit if it throws an exception
Enji Cooper added the comment: Grégory: that will fix this issue, but what I really need is some of the other changes, like moving the getaddrinfo logic into a separate route (connect). -- ___ Python tracker <https://bugs.python.org/issue47158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47158] logging.handlers.SysLogHandler doesn't get cleaned up properly on exit if it throws an exception
Enji Cooper added the comment: Grégory: good question. I would personally advocate for doing it out of selfish interests. I'm working with middleware based on 3.8 (moving to 3.9+ is non-trivial), and we have a common fault scenario where the system breaks if logging.handlers.SysLogHandler is instantiated and the target host cannot be resolved, like seen in the first comment. Backporting the changes you referenced would make addressing the above issue easier, since the logic in connect(..) was moved into its own routine. -- ___ Python tracker <https://bugs.python.org/issue47158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47158] logging.handlers.SysLogHandler doesn't get cleaned up properly on exit if it throws an exception
Enji Cooper added the comment: Yup! Looks like it! Just needs a back port. -- ___ Python tracker <https://bugs.python.org/issue47158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47158] logging.handlers.SysLogHandler doesn't get cleaned up properly on exit if it throws an exception
New submission from Enji Cooper :
Something I noticed when trying to repro another issue:
% python
Python 3.8.13 (default, Mar 16 2022, 17:28:59)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging.handlers
>>> logging.handlers.SysLogHandler(address=("something-completely-bogus-doncha-know",
>>> 514))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.8/logging/handlers.py", line 829, in __init__
ress = socket.getaddrinfo(host, port, 0, socktype)
File "/usr/lib/python3.8/socket.py", line 918, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known
>>>
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python3.8/logging/__init__.py", line 2127, in shutdown
h.close()
File "/usr/lib/python3.8/logging/handlers.py", line 892, in close
self.socket.close()
AttributeError: 'SysLogHandler' object has no attribute 'socket'
% python3.9
Python 3.9.11 (main, Mar 16 2022, 17:27:06)
[GCC 7.5.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import logging.handlers
>>> logging.handlers.SysLogHandler(address=("something-completely-bogus-doncha-know",
>>> 514))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.9/logging/handlers.py", line 873, in __init__
ress = socket.getaddrinfo(host, port, 0, socktype)
File "/usr/lib/python3.9/socket.py", line 954, in getaddrinfo
for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name or service not known
>>>
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File "/usr/lib/python3.9/logging/__init__.py", line 2142, in shutdown
h.close()
File "/usr/lib/python3.9/logging/handlers.py", line 936, in close
self.socket.close()
AttributeError: 'SysLogHandler' object has no attribute 'socket'
This is happening because logging.Handler is calling logging._addHandlerRef in
logging.Handler.__init__ and _removeHandlerRef at exit via logging.shutdown(..).
--
components: Library (Lib)
messages: 416309
nosy: ngie
priority: normal
severity: normal
status: open
title: logging.handlers.SysLogHandler doesn't get cleaned up properly on exit
if it throws an exception
type: behavior
versions: Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue47158>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46989] signal.signal, et al, doesn't support [SIGRTMIN, SIGRTMAX] on FreeBSD (not included in NSIG)
New submission from Enji Cooper :
As noted in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262487, cpython
relies on the definition of NSIG when building signal handlers to determine
what signals are and aren't invalid.
Unfortunately on FreeBSD, NSIG doesn't include [SIGRTMIN,SIGRTMAX], as shown
below:
$ python2
Python 2.7.18 (default, Dec 3 2020, 01:19:40)
[GCC 4.2.1 Compatible FreeBSD Clang 8.0.1 (tags/RELEASE_801/final 366581)] on
freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.signal(signal.SIGRTMIN, signal.SIG_DFL)
Traceback (most recent call last):
File "", line 1, in
ValueError: signal number out of range
>>> exit()
$ python3
Python 3.8.12 (default, Jan 4 2022, 01:10:15)
[Clang 10.0.1 (g...@github.com:llvm/llvm-project.git
llvmorg-10.0.1-0-gef32c611a on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.signal(signal.SIGRTMIN, signal.SIG_IGN)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.8/signal.py", line 47, in signal
handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
ValueError: signal number out of range
>>> exit()
$ python3.11
Python 3.11.0a3 (main, Feb 4 2022, 02:34:52) [Clang 10.0.1
(g...@github.com:llvm/llvm-project.git llvmorg-10.0.1-0-gef32c611aa on freebsd12
Type "help", "copyright", "credits" or "license" for more information.
>>> import signal
>>> signal.signal(signal.SIGRTMIN, signal.SIG_IGN)
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.11/signal.py", line 47, in signal
handler = _signal.signal(_enum_to_int(signalnum), _enum_to_int(handler))
^^
ValueError: signal number out of range
>>> exit()
$
This results in a cpython interface which doesn't match the OS's signal(3)
interface:
```
$ cat signal_rtmin.c
#include
#include
int
main(void)
{
if (signal(SIGRTMIN, SIG_DFL) == SIG_ERR)
warn("signal");
return (0);
}
$ cc -o signal_rtmin -Wall signal_rtmin.c
$ ./signal_rtmin
$ uname -a
FreeBSD picasso.local 12.2-RELEASE-p7 FreeBSD 12.2-RELEASE-p7 GENERIC amd64
$
```
Linux includes [SIGRTMIN,SIGRTMAX] in NSIG, which means it allows these values
in signal.signal without issue (confirmed on Ubuntu 18.04.6 LTS).
While one can definitely argue that this is an OS portability defect and this
should be resolved in FreeBSD (and thus, not fixed in cpython), it doesn't
address existing behavior on older versions of FreeBSD where this hasn't been
resolved yet.
FreeBSD bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=262487
--
components: FreeBSD
messages: 414932
nosy: koobs, ngie
priority: normal
severity: normal
status: open
title: signal.signal, et al, doesn't support [SIGRTMIN,SIGRTMAX] on FreeBSD
(not included in NSIG)
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue46989>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43465] ./configure --help describes what --with-ensurepip does poorly
New submission from Enji Cooper : Many users are used to --without-* flags in autoconf disabling features (and optionally not installing them). --without-ensurepip (at face value to me) suggests it shouldn't be built/installed. This comment in https://bugs.python.org/issue20417 by dstufft implies otherwise. From https://bugs.python.org/msg209537 : > I don't see any reason not to install ensurepip in this situation. That flag > controls whether or not ``python -m ensurepip`` will be executed during the > install, but ensurepip itself will still be installed. It is not an optional > module This isn't what "./configure --help" implies though: ``` $ git log --oneline -n 1 87f649a409 (HEAD -> master, upstream/master, origin/master, origin/logging-config-dictconfig-support-more-sysloghandler-options, origin/HEAD, logging-config-dictconfig-support-more-sysloghandler-options) bpo-43311: Create GIL autoTSSkey ealier (GH-24819) $ ./configure --help ... --with-ensurepip[=install|upgrade|no] "install" or "upgrade" using bundled pip (default is upgrade) $ ``` The wording should be clarified to note what the flag actually does instead of causing [valid] confusion to end-users which might make them think that the ensurepip module shouldn't be installed if --without-ensurepip is specified. -- components: Build messages: 388456 nosy: ngie priority: normal severity: normal status: open title: ./configure --help describes what --with-ensurepip does poorly versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43465> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42971] Some errnos for BSD/OSX are missing from errno module
Enji Cooper added the comment: Some items that I've noted so far that are missing: - ENOATTR (BSD/OSX) - ENOLINK (BSD; is reserved on OSX) - ENOTSUP (NetBSD, OpenBSD, OSX) -- ___ Python tracker <https://bugs.python.org/issue42971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue42971] Some errnos for BSD/OSX are missing from errno module
New submission from Enji Cooper : Some errnos for BSD/OSX are currently not supported by the errno module. It would be helpful for these to be exposed to the end-user so they could programmatically use them instead of reinventing the wheel in a separate module/C extension, or hardcoding the information in consuming pieces of code. -- components: Extension Modules messages: 385293 nosy: ngie priority: normal severity: normal status: open title: Some errnos for BSD/OSX are missing from errno module versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue42971> ___ ___ 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
Enji Cooper added the comment: Is there something I can do to help move this change along? 8 years is a long time for an issue to be open :(. -- ___ 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
[issue41108] IN module removed in python 3.x; socket doesn't fill in the gap with IP_PORTRANGE*
New submission from Enji Cooper : The group that I work with uses the IN.py module to access constants available in netinet/in.h on BSD when adjusting socket port ranges. This compile-time module was never ported forward to 3.x and equivalent functionality doesn't exist in the `socket` module. This bug will address that issue. -- components: Extension Modules messages: 372282 nosy: ngie priority: normal pull_requests: 20290 severity: normal status: open title: IN module removed in python 3.x; socket doesn't fill in the gap with IP_PORTRANGE* type: enhancement versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40786] madvise should be accessible outside of mmap instance
Change by Enji Cooper : -- components: +Library (Lib) ___ Python tracker <https://bugs.python.org/issue40786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40786] madvise should be accessible outside of mmap instance
New submission from Enji Cooper : madvise can be used when manipulating mmap'ed pages, but it can also be used when protecting processes and other things. Having madvise be available in mmap as a function would be helpful instead of having to jump through a lot of hoops to run `MADV_PROTECT` on a process. -- messages: 370036 nosy: ngie priority: normal severity: normal status: open title: madvise should be accessible outside of mmap instance versions: Python 3.10, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40786> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40785] `mmap.mmap(..., 0)` doesn't work as advertised in docs (fails with EINVAL); relies on compatibility behavior no longer permitted by [some] Unix OSes
Enji Cooper added the comment: Sidenote: all versions tested were 3.8.2: pinklady:freebsd ngie$ /usr/local/opt/python@3.8/bin/python3 -V Python 3.8.2 -- ___ Python tracker <https://bugs.python.org/issue40785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40785] `mmap.mmap(..., 0)` doesn't work as advertised in docs (fails with EINVAL); relies on compatibility behavior no longer permitted by [some] Unix OSes
New submission from Enji Cooper : The documentation for mmap.mmap() claims that passing a length of 0 will map in an entire file, but unfortunately that doesn't work as shown below: >>> mmap.mmap(-1, 0) Traceback (most recent call last): File "", line 1, in OSError: [Errno 22] Invalid argument I've double-checked that this isn't an OS specific bug on the following OS platforms: * Fedora 31 * FreeBSD * OSX Catalina The errno == EINVAL issue is documented in the OS X Catalina manpage as follows: ``` [EINVAL] The len argument was negative or zero. Historically, the system call would not return an error if the argument was zero. See other potential additional restrictions in the COMPATIBILITY section below. ... COMPATIBILITY mmap() now returns with errno set to EINVAL in places that historically succeeded. The rules have changed as follows: o The flags parameter must specify either MAP_PRIVATE or MAP_SHARED. o The len parameter must not be 0. o The off parameter must be a multiple of pagesize, as returned by sysconf(). ``` POSIX concurs: https://pubs.opengroup.org/onlinepubs/9699919799/ . So, in short -- python's mmap.mmap(.., 0) implementation relies on behavior which is now not permitted in multiple OSes and is not permitted per the POSIX spec for mmap(2). 1. https://docs.python.org/3/library/mmap.html#mmap.mmap -- components: Interpreter Core messages: 370029 nosy: ngie priority: normal severity: normal status: open title: `mmap.mmap(..., 0)` doesn't work as advertised in docs (fails with EINVAL); relies on compatibility behavior no longer permitted by [some] Unix OSes versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue40785> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39919] C extension code reliant on static flags/behavior with PY_DEBUG (Py_SAFE_DOWNCAST, method flags) could potentially leverage _Static_assert
New submission from Enji Cooper : Looking at Py_SAFE_DOWNCAST, it seems that the code could (in theory) leverage _Static_assert on C11 capable compilers [1]. Looking at some other code APIs, like module initialization with METH_VARARGS, etc, there are ways to determine whether or not the values are valid at compile-time with C11 capable compilers, instead of figuring out the issues on the tail end at runtime and having to play whackamole figuring out which offending methods are triggering issues (see also: bpo-39884). 1. https://en.cppreference.com/w/c/language/_Static_assert -- components: C API messages: 363785 nosy: ngie priority: normal severity: normal status: open title: C extension code reliant on static flags/behavior with PY_DEBUG (Py_SAFE_DOWNCAST, method flags) could potentially leverage _Static_assert ___ Python tracker <https://bugs.python.org/issue39919> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39884] "SystemError: bad call flags" exceptions added as part of BPO-33012 are difficult to debug
New submission from Enji Cooper :
When a body of C extensions needs to be ported from python <3.8 to 3.8, one of
the issues one might run into is improperly defined methods in a C extension,
which results in SystemErrors stating:
>>> SystemError: bad call flags
This new behavior was added as part of Issue # 33012.
While the issues definitely need to be resolved in the C extensions, where to
start is not completely clear. I had to put `printfs` in PyCFunction_NewEx and
PyDescr_NewMethod to track down the issues, e.g.,
>>> printf("method name: %s\n", method->ml_name);
While this might be misleading for duplicate method definitions, it definitely
helps narrow down the offending code.
Adding the method name to the SystemError would be a big step in the right
direction in terms of making it easier to resolve these issues.
PS I realize that this might be masked by casting PyCFunction on methods or by
not using gcc 8+, but I'd argue that C extensions need to have developer issues
like this be clearer to the end-reader.
--
components: Extension Modules
messages: 363575
nosy: ngie
priority: normal
severity: normal
status: open
title: "SystemError: bad call flags" exceptions added as part of BPO-33012 are
difficult to debug
type: behavior
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue39884>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39762] PyLong_AS_LONG missing from longobject.h
Enji Cooper added the comment: > The reason why there was the PyInt_AS_LONG macro is that it is very simple > and efficient. It never fails, because the value of the int object always > fits in the C long. PyInt_AsLong is much slower. If you know that the object > is int, you can use PyInt_AS_LONG for performance and simplicity. Another note: this assertion holds generally true with contemporary hardware architectures (sizeof(long long) != sizeof(int)), but there are still 32-bit hardware/software architectures (ex: non-ARM64 capable ARM arches, i386, powerpc 32-bit, etc) that violate this constraint. 32-bit architectures are at risk of overflow with 32-bit values. -- ___ Python tracker <https://bugs.python.org/issue39762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39762] PyLong_AS_LONG missing from longobject.h
Enji Cooper added the comment: PyInt_AS_LONG doesn't exist on python 3, however: $ grep -r PyInt_AS_LONG /usr/include/ [/usr/include/python2.7/intobject.h:#define PyInt_AS_LONG(op) (((PyIntObject *)(op))->ob_ival) The code smell for the pieces that use PyInt_AS_LONG seems a bit questionable since they're used as array indexes; I'll poke a bit more and look at using one of the other sets of C APIs instead in our project. -- ___ Python tracker <https://bugs.python.org/issue39762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39762] PyLong_AS_LONG missing from longobject.h
Enji Cooper added the comment: @serhiy.storchaka: understood. Figured this would be a good errata note for others to potentially find in the future. -- ___ Python tracker <https://bugs.python.org/issue39762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39762] PyLong_AS_LONG missing from longobject.h
Enji Cooper added the comment: Workaround PR posted here: https://github.com/encukou/py3c/pull/28 -- ___ Python tracker <https://bugs.python.org/issue39762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39762] PyLong_AS_LONG missing from longobject.h
Enji Cooper added the comment:
For the record, this seems like it might be the only discrepancy, per the py3c
project's exported PyInt APIs:
$ for api in `awk '$2 ~ /^PyInt/ { print $3 }' include/py3c/compat.h`; do grep
-q $api /usr/include/python2.7/longobject.h || echo $api; done
PyLong_AS_LONG
--
___
Python tracker
<https://bugs.python.org/issue39762>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39762] PyLong_AS_LONG missing from longobject.h
Enji Cooper added the comment: For the record, some projects (like Cython, pywin32) worked around this by adding a preprocessor alias, PyLong_AS_LONG -> PyInt_AS_LONG with python 2.x. -- ___ Python tracker <https://bugs.python.org/issue39762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39762] PyLong_AS_LONG missing from longobject.h
New submission from Enji Cooper : While trying to port python 2 C extension code forward to python 3, I noticed that the python 2.6 PyInt -> PyLong unification lacks a forward-compatible API for PyLong_AS_LONG. I'm not sure if this was intentional, but it is a slightly annoying wicket to deal with when forward C extension code that needs to straddle 2 and 3 for a period of time. -- components: C API messages: 362705 nosy: ngie priority: normal severity: normal status: open title: PyLong_AS_LONG missing from longobject.h versions: Python 2.7 ___ Python tracker <https://bugs.python.org/issue39762> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39742] Enhancement: add `os.getdtablesize(..)` to `os` (`posix`) module
Change by Enji Cooper : -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue39742> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39742] Enhancement: add `os.getdtablesize(..)` to `os` (`posix`) module
New submission from Enji Cooper :
getdtablesize({2,3}) is a wonderful library call/system call to have access to
because it allows one to determine the descriptor limits at runtime in an
easier manner than having to do the equivalent with os.sysconf(..):
>>> os.sysconf(os.sysconf_names["SC_OPEN_MAX"])
This has been present in *BSD since time memorial [1] and in Linux since 2010
[2], so I think it would be a good addition to the `os` (`posix`) module.
I will submit a diff for this in a few days, if it's deemed acceptable to have
in the `posix` module.
1.
https://www.freebsd.org/cgi/man.cgi?query=getdtablesize=2=freebsd-release-ports
2. http://man7.org/linux/man-pages/man2/getdtablesize.2.html
--
components: Library (Lib)
messages: 362603
nosy: ngie
priority: normal
severity: normal
status: open
title: Enhancement: add `os.getdtablesize(..)` to `os` (`posix`) module
type: enhancement
___
Python tracker
<https://bugs.python.org/issue39742>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39565] Modules/signalmodule.c creates handlers for signals bounded by `NSIG`; requires fudging to support realtime signals, etc
Change by Enji Cooper : -- title: Modules/signalmodule.c creates handlers for signals bound by `NSIG`; requires fudging to support realtime signals, etc -> Modules/signalmodule.c creates handlers for signals bounded by `NSIG`; requires fudging to support realtime signals, etc ___ Python tracker <https://bugs.python.org/issue39565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39565] Modules/signalmodule.c creates handlers for signals bound by `NSIG`; requires fudging to support realtime signals, etc
Change by Enji Cooper : -- title: Modules/signalmodule.c only works with `NSIG` signals; requires fudging to support realtime signals, etc -> Modules/signalmodule.c creates handlers for signals bound by `NSIG`; requires fudging to support realtime signals, etc ___ Python tracker <https://bugs.python.org/issue39565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39565] Modules/signalmodule.c only works with `NSIG` signals; requires fudging to support realtime signals, etc
New submission from Enji Cooper : The code in Modules/signalmodule.c makes a number of assumptions of what signals are considered valid, as well as what handlers need to be setup as part of the core interpreter. For example: much of the initialization of signal handlers, etc, is actually keyed off of NSIG, as defined (and guessed on) here: https://github.com/python/cpython/blob/master/Modules/signalmodule.c#L50 . The problem with this is that it makes it impossible for end-users to use `signal.signal`, et al with signal numbers outside of `NSIG`, which includes realtime signals. Furthermore, if one is to extend the size of `NSIG`, it results in an increased O(n) iteration over all of the signals if/when a handler needs to be handled (set or cleared). Proposal: The best way to handle this, in my opinion, is to use a dict-like container to iterate over all of the handlers and rely on the OS to trickle up errors in the signal(3) libcall, as opposed to thinking that the definitions/assumptions in signalmodule.c are absolutely correct. This may or may not be possible, however, depending on code needing to be reentrant, but it would be nice to leverage a middle ground solution of some kind *shrug*. -- components: Interpreter Core messages: 361458 nosy: ngie priority: normal severity: normal status: open title: Modules/signalmodule.c only works with `NSIG` signals; requires fudging to support realtime signals, etc versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39565> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18213] py-bt errors on backtrace with PyRun_SimpleString and friends
Enji Cooper added the comment: This particular issue has been resolved in python 3.x. -- nosy: +ngie ___ Python tracker <https://bugs.python.org/issue18213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`
Enji Cooper added the comment: Capturing more context here, based on internal discussion: other handlers are doing address resolution in `emit()` (HTTPHandler, SMTPHandler), which is expensive. In order for SysLogHandler to not regress behavior and not become expensive, performance-wise, it would probably be best to use `functools.lru_cache()`, using the address and a timeout as the key when resolving the addresses to avoid always doing address resolutions, e.g., DNS lookups: https://docs.python.org/3/library/functools.html#functools.lru_cache . -- ___ Python tracker <https://bugs.python.org/issue38354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38354] Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()`
Change by Enji Cooper : -- title: Fix for bug 30378 regressed SysLogHandler -> Fix for bug 30378 regressed SysLogHandler by making it resolve addresses at initialization instead of in `.emit()` ___ Python tracker <https://bugs.python.org/issue38354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38354] Fix for bug 30378 regressed SysLogHandler
New submission from Enji Cooper :
The change made for bug 30378 caused a regression in our code by making
lookups for SysLogHandler addresses at init time, instead of making them more
lazy. Example:
>>> import logging.handlers
>>> LOGGER = logging.getLogger("logger")
>>> LOGGER.addHandler(logging.handlers.SysLogHandler(address=('resolvessometimesbutnotthefirsttime.com',
>>> logging.handlers.SYSLOG_UDP_PORT)))
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python2.7/logging/handlers.py", line 767, in __init__
ress = socket.getaddrinfo(host, port, 0, socktype)
socket.gaierror: [Errno -2] Name or service not known
This is exacerbated by the fact that a lot of code the organization I work for
(and to be honest, I have written in the past) initializes global loggers once
at import time. If the SysLogHandler is added to the global logger and the DNS
resolution isn't possible (/etc/hosts is empty on Unix or does not contain the
entry, and DNS out is to lunch), it will fall on its face at initialization
time.
There needs to be a more graceful way of initializing loggers like this, or a
way of delaying the host resolution, so it fails gracefully and doesn't crash
the entire program (restoring the previous behavior).
Example: SMTPHandler doesn't do name resolution until it calls emit, which
seems like a much more logical place to do the operation (especially since DNS
records can change or become invalid).
--
components: Library (Lib)
messages: 353775
nosy: calcheng, ngie
priority: normal
severity: normal
status: open
title: Fix for bug 30378 regressed SysLogHandler
type: crash
versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue38354>
___
___
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 Enji Cooper : -- versions: +Python 2.7, Python 3.4, Python 3.5, Python 3.7, 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
[issue13501] Make libedit support more generic; port readline / libedit to FreeBSD
Enji Cooper added the comment: I'll try to rebase Martin's changes, as they don't apply to the master branch on GitHub today. -- ___ 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
[issue36111] Non-zero `offset`s are no longer acceptable with SEEK_END/SEEK_CUR implementation of `seek` in python3 when in text mode, breaking py 2.x behavior/POSIX
Change by Enji Cooper : -- title: Non-zero `offset`s are no longer acceptable with implementation of `seek` in some cases with python3 when in text mode; should be per POSIX -> Non-zero `offset`s are no longer acceptable with SEEK_END/SEEK_CUR implementation of `seek` in python3 when in text mode, breaking py 2.x behavior/POSIX ___ Python tracker <https://bugs.python.org/issue36111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36111] Non-zero `offset`s are no longer acceptable with implementation of `seek` in some cases with python3 when in text mode; should be per POSIX
Change by Enji Cooper : -- title: Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX -> Non-zero `offset`s are no longer acceptable with implementation of `seek` in some cases with python3 when in text mode; should be per POSIX ___ Python tracker <https://bugs.python.org/issue36111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13497] Fix for broken nice test on non-broken platforms with pedantic compilers
Change by Enji Cooper : -- pull_requests: +12067 ___ Python tracker <https://bugs.python.org/issue13497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8747] Autoconf tests in python not portably correct
Enji Cooper added the comment: This issue has been superseded by other work. -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue8747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX
Change by Enji Cooper : -- versions: +Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue36111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX
Enji Cooper added the comment:
Opening and seeking using SEEK_END worked in text mode with python 2.7. I'm not
terribly sure why 3.x should depart from this behavior:
>>> fp = open("configure", "rt"); fp.seek(-100, os.SEEK_END)
>>> fp.tell()
501076
--
___
Python tracker
<https://bugs.python.org/issue36111>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX
Change by Enji Cooper : -- title: Negative `offset` values are no longer acceptable with implementation of `seek` with python3; should be per POSIX -> Negative `offset` values are no longer acceptable with implementation of `seek` with python3 when in text mode; should be per POSIX ___ Python tracker <https://bugs.python.org/issue36111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3; should be per POSIX
Enji Cooper added the comment: ?! Being blunt: why should opening a file in binary vs text mode matter? POSIX doesn't make this distinction. Per the pydoc (https://docs.python.org/2/library/functions.html#open): > The default is to use text mode, which may convert '\n' characters to a > platform-specific representation on writing and back on reading. If this is one of the only differentiators between binary and text mode, why should certain types of seeking be made impossible? Having to stat the file, then set the cursor to the size of the file, minus the offset breaks the 'seek(..)' interface, and having to use 'rb', then convert from bytes to unicode overly complicates things :(. -- ___ Python tracker <https://bugs.python.org/issue36111> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36111] Negative `offset` values are no longer acceptable with implementation of `seek` with python3; should be per POSIX
New submission from Enji Cooper :
I tried using os.SEEK_END in a technical interview, but unfortunately, that
didn't work with python 3.x:
pinklady:cpython ngie$ python3
Python 3.7.2 (default, Feb 12 2019, 08:15:36)
[Clang 10.0.0 (clang-1000.11.45.5)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> fp = open("configure"); fp.seek(-100, os.SEEK_END)
Traceback (most recent call last):
File "", line 1, in
io.UnsupportedOperation: can't do nonzero end-relative seeks
It does however work with 2.x, which is aligned with the POSIX spec
implementation, as shown below:
pinklady:cpython ngie$ python
Python 2.7.15 (default, Oct 2 2018, 11:47:18)
[GCC 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.2)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> fp = open("configure"); fp.seek(-100, os.SEEK_END)
>>> fp.tell()
501076
>>> os.stat("configure").st_size
501176
>>>
--
components: IO
messages: 336564
nosy: yaneurabeya
priority: normal
severity: normal
status: open
title: Negative `offset` values are no longer acceptable with implementation of
`seek` with python3; should be per POSIX
___
Python tracker
<https://bugs.python.org/issue36111>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
