[issue40815] Multiprocessing docs don't describe thread-safety

2020-05-29 Thread Alan Briolat


Change by Alan Briolat :


--
nosy: +alan.briolat

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



[issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case

2014-04-07 Thread Alan Briolat

New submission from Alan Briolat:

The logging.LogRecord class is more restrictive with its "first arg is dict" 
case than the formatting operator it uses requires.  As far as I can tell, for 
"%(foo)s" % bar, the minimum contract is that bar.__getitem__("foo") succeeds, 
not that bar is an instance of dict.  However, fulfilling only this minimum 
contract results in LogRecord raising an exception at the point of applying the 
string format, which is confusing considering the "same" expression succeeds 
outside of logging.  See the attached file for how 2 "equivalent" expressions 
behave completely differently.

For resolution, I wonder if checking for "hasattr(..., '__getitem__')" instead 
of "isinstance(..., dict)" would be sufficient?

--
components: Library (Lib)
files: logging_format_bug.py
messages: 215713
nosy: alan.briolat
priority: normal
severity: normal
status: open
title: Unexpected behaviour with logging.LogRecord "first arg is dict" case
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5
Added file: http://bugs.python.org/file34750/logging_format_bug.py

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



[issue21172] Unexpected behaviour with logging.LogRecord "first arg is dict" case

2014-04-08 Thread Alan Briolat

Alan Briolat added the comment:

Because the object in question is not actually a dict, LogRecord is attempting, 
in this example, "%(bar)s" % (f,) instead of "%(bar)s" % f.

In unicodeobject.c this causes the PyMapping_Check in PyUnicode_Format to fail 
because it's a tuple (note that PyMapping_Check *only* checks for the 
__getitem__ attribute), the argument to not be treated as a dict, and 
consequently ctx.dict = NULL for the format operation.

This condition, combined with still attempting to resolve named values in the 
format string, causes unicode_format_arg_parse to raise the TypeError("format 
requires a mapping").

Speaking of documentation, the language of

https://docs.python.org/2/library/logging.html#logging.Logger.debug

strongly suggests that logging.debug(msg, args...) should be considered 
equivalent to logging.debug(msg % args...), which still means this is still 
"unexpected" behaviour.  The intention is clearly to allow this special case to 
pass through to the formatting operator unimpeded, however this doesn't happen.

Also, even if "the mapping protocol" should remain the key concept (the 
behaviour of PyMapping_Check being a happy accident), checking for 
isinstance(..., dict) is still wrong - it should at least be 
collections.Mapping to give users a chance to emulate the correct interface.

--
status: pending -> open

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