[issue44979] pathlib: support relative path construction

Change by Kirill Pinchuk : -- keywords: +patch pull_requests: +26344 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27890 ___ Python tracker <https://bugs.python.org/issu

[issue44979] pathlib: support relative path construction

New submission from Kirill Pinchuk : Hi. I've been using this snippet for years and believe that it would be a nice addition to pathlib's functionality. Basically, it allows constructing path relative to the current file (instead of cwd). Comes quite handy when you're work

[issue44291] Unify logging.handlers.SysLogHandler behavior with SocketHandlers

Kirill Pinchuk added the comment: Oh, sorry bad wording. The current implementation has reconnection logic only for UNIX sockets The patch adds reconnection logic for UDP/TCP sockets as well. I've done it with minimal changes to the existing code to accomplish that. And probably it c

[issue44291] Unify logging.handlers.SysLogHandler behavior with SocketHandlers

Kirill Pinchuk added the comment: UPD: right now it has reconnection logic for unixsocket but not for tcp/udp -- ___ Python tracker <https://bugs.python.org/issue44

[issue44291] Unify logging.handlers.SysLogHandler behavior with SocketHandlers

New submission from Kirill Pinchuk : Probably we should make the behavior of SysLogHandler consistent with other Socket handlers. Right now SocketHandler and DatagramHandler implement such behavior: 1) on `close` set `self.socket = None` 2) when trying to send - make socket when it is None

[issue38106] [2.7] Race in PyThread_release_lock on macOS - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: :) Yes and no. PyPy did not make a new release with the fix yet. -- ___ Python tracker <https://bugs.python.org/issue38

[issue38106] [2.7] Race in PyThread_release_lock on macOS - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: Victor, thanks for merging. > I'm surprised that we still find new bugs in this code which is supposed to > be battle tested! Maybe recent Darwin changed made the bug more likely. As discussed above (https://bugs.python.org/issue38106#msg35

[issue26360] Deadlock in thread.join on Python 2.7/macOS

Kirill Smelkov added the comment: > > Maybe issue38106 related. > > That looks plausible, but unfortunately I'm still able to reproduce the hang > with your PR (commit 9b135c02aa1edab4c99c915c43cd62d988f1f9c1, macOS 10.14.6). Thanks for feedback. Then hereby bug is

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: Ok, I did https://github.com/python/cpython/pull/16047. -- ___ Python tracker <https://bugs.python.org/issue38106> ___ ___

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Change by Kirill Smelkov : -- keywords: +patch pull_requests: +15669 stage: -> patch review pull_request: https://github.com/python/cpython/pull/16047 ___ Python tracker <https://bugs.python.org/issu

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: I agree it seems like a design mistake. Not only it leads to suboptimal implementations, but what is more important, it throws misuse risks onto the user. -- ___ Python tracker <https://bugs.python.org/issue38

[issue26360] Deadlock in thread.join on Python 2.7/Mac OS X 10.9, 10.10

Kirill Smelkov added the comment: Maybe issue38106 related. -- nosy: +navytux ___ Python tracker <https://bugs.python.org/issue26360> ___ ___ Python-bugs-list m

[issue8410] Fix emulated lock to be 'fair'

Kirill Smelkov added the comment: Thanks for feedback. -- ___ Python tracker <https://bugs.python.org/issue8410> ___ ___ Python-bugs-list mailing list Unsub

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: And it is indeed better to always do pthread_cond_signal() from under mutex. Many pthread libraries delay the signalling to associated mutex unlock, so there should be no performance penalty here and the correctness is much more easier to reason about

[issue38106] Race in PyThread_release_lock - can lead to memory corruption and deadlock

Kirill Smelkov added the comment: Thanks for feedback. Yes, since for Python-level lock, PyThread_release_lock() is called with GIL held: https://github.com/python/cpython/blob/v2.7.16-129-g58d61efd4cd/Modules/threadmodule.c#L69-L82 the GIL effectively serves as the synchronization device

[issue8410] Fix emulated lock to be 'fair'

Kirill Smelkov added the comment: At least condition variable signalling has to be moved to be done under mutex for correctness: https://bugs.python.org/issue38106. -- nosy: +navytux ___ Python tracker <https://bugs.python.org/issue8

[issue433625] bug in PyThread_release_lock()

Kirill Smelkov added the comment: I still believe there is a race here and it can lead to MEMORY CORRUPTION and DEADLOCK: https://bugs.python.org/issue38106. -- nosy: +navytux ___ Python tracker <https://bugs.python.org/issue433

[issue38106] Race in PyThread_release_lock - can lead to MEMORY CORRUPTION and DEADLOCK

New submission from Kirill Smelkov : Hello up there. I believe I've discovered a race in PyThread_release_lock on Python2.7 that, on systems where POSIX semaphores are not available and Python locks are implemented with mutexes and condition variables, can lead to MEMORY CORRUPTION and DEA

[issue37688] The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.

Kirill Balunov added the comment: I am reading "equivalence" too strictly (like "as a substitute"), because this is part of the documentation :) and I agree that in ordinary speech I would use it rather in the sense of “similar”. In order to make sure, that everyone agre

[issue37688] The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.

Kirill Balunov added the comment: I understand the reasons, I only say that it does not correspond to my perception of their equivalence, because: os.path.isdir('') != os.path.isdir('.') while: Path('').is_dir() == Path('.').is_dir() and I

[issue37688] The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.

Kirill Balunov added the comment: Forgot to write the result for Path variant: >>> Path(dummy).is_dir() True -- ___ Python tracker <https://bugs.python.or

[issue37688] The results from os.path.isdir(...) an Path(...).is_dir() are not equivalent for empty path strings.

New submission from Kirill Balunov : In the documentation it is said that os.path.isdir(...) an Path(...).is_dir()are equivalent substitutes. https://docs.python.org/3/library/pathlib.html#correspondence-to-tools-in-the-os-module But they give different result for empty path strings

[issue35757] slow subprocess.Popen(..., close_fds=True)

New submission from Kirill Kolyshkin : In case close_fds=True is passed to subprocess.Popen() or its users (subprocess.call() etc), it might spend some considerable time closing non-opened file descriptors, as demonstrated by the following snippet from strace: close(3

[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type

Kirill Balunov added the comment: I apologize for FutureWarning and __getattr__. I myself do not understand what I meant and how it will help in this situation :) -- ___ Python tracker <https://bugs.python.org/issue33

[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type

Kirill Balunov added the comment: Small risk of breaking is a fair point (maybe some FutureWarning with new __getattr__ PEP 562?). I've checked several packages: --- vstinner/bytecode:: uses: @staticmethod def _has_jump(opcode): return (opcode in _opcode.ha

[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type

Change by Kirill Balunov : -- nosy: +larry, serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue33326> ___ ___ Python-bugs-list mailing list Unsub

[issue32455] PyCompile_OpcodeStackEffect() and dis.stack_effect() are not particularly useful

Kirill Balunov added the comment: Sorry if this doesn't fit this issue and needs a separate one. Since Python switched to 2 byte wordcode, all opcodes which do not imply an argument, technically have it - augmented with 0. So it is convenient to iterate over bytecode like: op

[issue33326] Convert collections (cmp_op, hasconst, hasname and others) in opcode module to more optimal type

New submission from Kirill Balunov : The opcode module contains several collections: `cmp_op` `hasconst` `hasname` `hasjrel` ... which are only used for `in` checks. At the same time, they are stored as `list`s and `cmp_op` as tuple. Both these types are not optimal for `__contains__` checks

[issue27129] Wordcode, part 2

Kirill Balunov added the comment: Hello, what is the future of this patch? Such a feeling that the transition to wordcode is still in some half-way state. -- nosy: +godaygo ___ Python tracker <https://bugs.python.org/issue27

[issue32696] Fix pickling exceptions with multiple arguments

Kirill Matsaberydze added the comment: Hi, I encounter similar behavior in python 3.6.5 with following code: import pickle class CustomException(Exception): def __init__(self, arg1, arg2): msg = "Custom message {} {}".format(arg1, arg2) super().__init__(msg)

[issue32910] venv: Deactivate.ps1 is not created when Activate.ps1 was used

Kirill Balunov added the comment: Yes, I agree, I did not understand the documentation correctly. It seems to me that the problem in the perception arose because of the fact that "deactivate" is not formatted as shell command, while `Deactivate.ps1` and others are. So I th

[issue32910] venv: Deactivate.ps1 is not created when Activate.ps1 was used

Kirill Balunov added the comment: Sorry, `deactivate` works in both cases `Scripts/Activate.ps1` and `Scripts/activate`. Only `Deactivate.ps1` is not created for the former, but the docs says that it should. -- ___ Python tracker <ht

[issue32910] venv: Deactivate.ps1 is not created when Activate.ps1 was used

New submission from Kirill Balunov : There was a related issue, which was closed https://bugs.python.org/issue26715. If virtual environment was activated using Powershell script - Activate.ps1, the Deactivate.ps1 was not created, while the documentation says that it should. "Yo

[issue28685] Optimizing list.sort() by performing safety checks in advance

Kirill Balunov added the comment: What is the current status of this issue and will it go into Python 3.7? -- nosy: +godaygo ___ Python tracker <https://bugs.python.org/issue28

[issue24066] send_message should take all the addresses in the To: header into account

Kirill Elagin added the comment: Oh, I see now. It is a good idea to raise an error either in `send_message` or at the moment when a second `To`/`Cc`/`Bcc` header is added to the message. -- resolution: -> not a bug status: open ->

[issue24066] send_message should take all the addresses in the To: header into account

Kirill Elagin added the comment: Ah, I’m so dumb. Of course the tests work as there are multiple addresses but still just one field. Here is the test for multiple fields. -- Added file: http://bugs.python.org/file39263/multiple_fields_test.patch

[issue24066] send_message should take all the addresses in the To: header into account

Kirill Elagin added the comment: x_x -- keywords: +patch Added file: http://bugs.python.org/file39219/multiple_to.patch ___ Python tracker <http://bugs.python.org/issue24

[issue24066] send_message should take all the addresses in the To: header into account

New submission from Kirill Elagin: If I have a message with multiple `To` headers and I send it using `send_message` not specifying `to_addrs`, the message gets sent only to one of the recipients. I’m attaching my patch that makes it send to _all_ the addresses listed in `To`, `Cc` and `Bcc

[issue16972] Useless function call in site.py

New submission from Kirill: In Lib/site.py:149 [1] _init_pathinfo call has no effect. Looks like it's here because in the past _init_pathinfo was changing a global variable [2]. I believe that it should be changed to `known_paths = _init_pathinfo()`, in the same way as it'

[issue13114] check -r fails with non-ASCII unicode long_description

Kirill Kuzminykh added the comment: Latin transliteration of my name is Kirill Kuzminykh. -- ___ Python tracker <http://bugs.python.org/issue13114> ___ ___ Pytho

[issue10928] Strange input processing

Kirill Bystrov added the comment: Sorry, i have really forgotten about these octals. -- ___ Python tracker <http://bugs.python.org/issue10928> ___ ___ Python-bug

[issue10928] Strange input processing

New submission from Kirill Bystrov : I have written a simple script which evaluates some numeric expressions and faced a strange problem at some point. Some of these expressions cannot evaluate correctly. Here is an example: Python 2.7.1+ (r271:86832, Dec 24 2010, 10:03:35) [GCC 4.5.2] on

[issue10671] urllib2 redirect to another host doesn't work

New submission from Kirill Subbotin : When you open url which redirects to another host (either with 301 or 302), HTTPRedirectHandler keeps "Host" header from the previous request, which leads to a error. Instead a host should be taken from a new location url. Attached patch is t

[issue7923] StreamHandler and FileHandler located in logging, not in logging.handlers

New submission from Kirill : Index: library/logging.rst === --- library/logging.rst (revision 78171) +++ library/logging.rst (working copy) @@ -1659,7 +1659,7 @@ StreamHandler ^ -.. module:: logging.handlers

[issue3884] turtle in the tkinter package?

Kirill Simonov <[EMAIL PROTECTED]> added the comment: Thank you for the fix, I really appeciate it. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.pytho

[issue3884] turtle in the tkinter package?

New submission from Kirill Simonov <[EMAIL PROTECTED]>: I wonder why the module 'turtle' was moved to the 'tkinter' package. It is not a part of Tk, it does not provide new or extend existing tkinter API. While it uses tkinter, so do pydoc or idle; this is just an