[issue45465] logging messages are needlessly reformatted for every handler

2021-10-15 Thread Роман Донченко

Роман Донченко  added the comment:

But message formatting is controlled by the record, not by the handler. The 
same record will always be formatted the same way (assuming that getMessage is 
deterministic, which seems like a fair assumption).

--

___
Python tracker 
<https://bugs.python.org/issue45465>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue45465] logging messages are needlessly reformatted for every handler

2021-10-13 Thread Роман Донченко

New submission from Роман Донченко :

Consider this code:

```
import logging

class MyLogRecord(logging.LogRecord):
def getMessage(self):
print("Help! I am being formatted!")
return super().getMessage()

logging.setLogRecordFactory(MyLogRecord)

logger = logging.getLogger("test")
logger.addHandler(logging.StreamHandler())
logger.addHandler(logging.StreamHandler())

logger.error("%d", 123)
```

Its output is:

```
Help! I am being formatted!
123
Help! I am being formatted!
123
```

In other words, the record's `getMessage` method is called once for every 
handler. That seems quite unnecessary, especially since the formatted message 
is saved in the `message` field of the record by `Formatter.format`. 
`Formatter` could check whether the message has already been formatted, and if 
so, use the saved message.

--
components: Library (Lib)
messages: 403879
nosy: SpecLad
priority: normal
severity: normal
status: open
title: logging messages are needlessly reformatted for every handler
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue45465>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38630] subprocess.Popen.send_signal() should poll the process

2019-12-09 Thread Роман Донченко

Роман Донченко  added the comment:

> I'm pretty sure you mean WNOWAIT, right?

Right.

> revalidate pid licenses

What does this mean?

> I think we can patch up this last race condition by adding yet one more lock

Wouldn't it be sufficient to add

if self.returncode is not None:
return self.returncode

at the top of poll()?

(And in fact, you don't even need to add it, since an equivalent of this check 
is already there.)

I think this makes calling poll() from wait() unnecessary too.

--

___
Python tracker 
<https://bugs.python.org/issue38630>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38630] subprocess.Popen.send_signal() should poll the process

2019-12-09 Thread Роман Донченко

Роман Донченко  added the comment:

> What you do is split 'wait' into two parts: first it waits for me process to 
> become reapable without actually reaping it. On Linux you can do this with 
> waitid+WNOWAIT. On kqueue platforms you can do it with kqueue.

> Then, you take a lock, and use it to atomically call waitpid/waitid to reap 
> the process + update self.returncode to record that you've done so.

> In send_signal, we use the same lock to atomically check whether the process 
> has been reaped, and then send the signal if it hasn't.

It's a good idea, but it would break the scenario where two threads call wait() 
concurrently. It would create this race condition:

1. Thread A reaps the process.
2. Thread B thinks the process is still running, so it calls waitid+WNOHANG on 
a stale PID, with unpredictable results.
3. Thread A sets self.returncode.

What is needed here is a reader-writer lock. subprocess.wait would work like 
this (pseudocode):

with lock taken for reading:
os.waitid(..., WNOHANG)
with lock taken for writing:
os.waitid(...)
self.returncode = ...

Whereas subprocess.send_signal would work like this:

with lock taken for reading:
os.kill(...)

Unfortunately, it doesn't seem like Python has reader-writer locks in the 
library...

--
nosy: +SpecLad

___
Python tracker 
<https://bugs.python.org/issue38630>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38888] Popen should use pidfd_open to implement a non-busy wait

2019-11-21 Thread Роман Донченко

Роман Донченко  added the comment:

Right, of course. I keep confusing it with timerfd_create.

--
title: Popen should use pidfd_create to implement a non-busy wait -> Popen 
should use pidfd_open to implement a non-busy wait

___
Python tracker 
<https://bugs.python.org/issue3>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue38888] Popen should use pidfd_create to implement a non-busy wait

2019-11-21 Thread Роман Донченко

New submission from Роман Донченко :

Popen.wait(timeout) is currently implemented on Unix-like systems using a busy 
wait, since the waitpid system call doesn't have a timeout argument.

On Linux, it's now possible to do better than that. You can create a PID file 
descriptor using pidfd_create and poll that descriptor with the specified 
timeout. Popen.wait should make use of that.

--
components: Library (Lib)
messages: 357222
nosy: SpecLad
priority: normal
severity: normal
status: open
title: Popen should use pidfd_create to implement a non-busy wait
type: enhancement
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue3>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue35964] shutil.make_archive (xxx, tar, root_dir) is adding './' entry to archive which is wrong

2019-08-27 Thread Роман Донченко

Change by Роман Донченко :


--
nosy: +SpecLad

___
Python tracker 
<https://bugs.python.org/issue35964>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue31405] shutil.which doesn't find files without PATHEXT extension on Windows

2019-08-27 Thread Роман Донченко

Change by Роман Донченко :


--
nosy: +SpecLad

___
Python tracker 
<https://bugs.python.org/issue31405>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue24505] shutil.which wrong result on Windows

2019-08-27 Thread Роман Донченко

Change by Роман Донченко :


--
nosy: +SpecLad

___
Python tracker 
<https://bugs.python.org/issue24505>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue37894] [win] shutil.which can not find the path if 'cmd' include directory path and not include extension name

2019-08-27 Thread Роман Донченко

Change by Роман Донченко :


--
nosy: +SpecLad

___
Python tracker 
<https://bugs.python.org/issue37894>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue17088] ElementTree incorrectly refuses to write attributes without namespaces when default_namespace is used

2018-11-23 Thread Роман Донченко

Change by Роман Донченко :


--
nosy: +SpecLad

___
Python tracker 
<https://bugs.python.org/issue17088>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue14023] bytes implied to be mutable

2012-02-15 Thread Роман Донченко

New submission from Роман Донченко :

The language reference in section 5.2.2 states:

~
With the exception of bytes literals, these all correspond to immutable data 
types, <...>
~

But bytes objects are immutable as well.

--
assignee: docs@python
components: Documentation
messages: 153422
nosy: SpecLad, docs@python
priority: normal
severity: normal
status: open
title: bytes implied to be mutable
type: behavior
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue14023>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue14003] __self__ on built-in functions is not as documented

2012-02-13 Thread Роман Донченко

New submission from Роман Донченко :

The language reference says this in section 3.2:
 
~
Built-in functions
 
A built-in function object is a wrapper around a C function. Examples of 
built-in functions are len() and math.sin() <...> Special read-only attributes: 
<...> __self__ is set to None (but see the next item) <...>.
~

That is not the case:

ActivePython 3.2.2.3 (ActiveState Software Inc.) based on
Python 3.2.2 (default, Sep  8 2011, 10:55:13) [MSC v.1500 64 bit (AMD64)]  
on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> len.__self__

>>> open.__self__

>>> import math
>>> math.sin.__self__


--
assignee: docs@python
components: Documentation
messages: 153287
nosy: SpecLad, docs@python
priority: normal
severity: normal
status: open
title: __self__ on built-in functions is not as documented
type: behavior
versions: Python 3.2

___
Python tracker 
<http://bugs.python.org/issue14003>
___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com