[issue38921] Max Recursion Depth Reached in Logging Library
New submission from Joy : Seeing an issue with the logger fmt not setting correctly in the Handler class. Our code calls format many times which works for a while and then we receive the following errors: [3206] 2019/11/26 12:42:31.011> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 1725, in info [3206] 2019/11/26 12:42:31.013> [ERROR] self.log(INFO, msg, *args, **kwargs) [3206] 2019/11/26 12:42:31.014> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 1763, in log [3206] 2019/11/26 12:42:31.016> [ERROR] self.logger.log(level, msg, *args, **kwargs) [3206] 2019/11/26 12:42:31.017> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 1444, in log [3206] 2019/11/26 12:42:31.018> [ERROR] self._log(level, msg, args, **kwargs) [3206] 2019/11/26 12:42:31.019> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 1514, in _log [3206] 2019/11/26 12:42:31.021> [ERROR] self.handle(record) [3206] 2019/11/26 12:42:31.022> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 1524, in handle [3206] 2019/11/26 12:42:31.024> [ERROR] self.callHandlers(record) [3206] 2019/11/26 12:42:31.025> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 1586, in callHandlers [3206] 2019/11/26 12:42:31.026> [ERROR] hdlr.handle(record) [3206] 2019/11/26 12:42:31.027> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 894, in handle [3206] 2019/11/26 12:42:31.029> [ERROR] self.emit(record) [3206] 2019/11/26 12:42:31.029> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 1127, in emit [3206] 2019/11/26 12:42:31.031> [ERROR] StreamHandler.emit(self, record) [3206] 2019/11/26 12:42:31.032> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 1025, in emit [3206] 2019/11/26 12:42:31.033> [ERROR] msg = self.format(record) [3206] 2019/11/26 12:42:31.035> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 869, in format [3206] 2019/11/26 12:42:31.036> [ERROR] return fmt.format(record) [3206] 2019/11/26 12:42:31.037> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 869, in format [3206] 2019/11/26 12:42:31.039> [ERROR] return fmt.format(record) [3206] 2019/11/26 12:42:31.040> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 869, in format [3206] 2019/11/26 12:42:31.041> [ERROR] return fmt.format(record) [3206] 2019/11/26 12:42:31.042> [ERROR] [Previous line repeated 978 more times] [3206] 2019/11/26 12:42:31.043> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 608, in format [3206] 2019/11/26 12:42:31.045> [ERROR] record.message = record.getMessage() [3206] 2019/11/26 12:42:31.046> [ERROR] File "/usr/lib/python3.7/logging/__init__.py", line 367, in getMessage [3206] 2019/11/26 12:42:31.048> [ERROR] msg = str(self.msg) [3206] 2019/11/26 12:42:31.049> [ERROR] RecursionError [3206] 2019/11/26 12:42:31.049> [ERROR] : [3206] 2019/11/26 12:42:31.050> [ERROR] maximum recursion depth exceeded while calling a Python object I believe after a while the fmt object is not being set correctly and ends up calling the Handler's format function again and again. -- components: Library (Lib) messages: 357523 nosy: joy priority: normal severity: normal status: open title: Max Recursion Depth Reached in Logging Library type: crash versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue38921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38921] Max Recursion Depth Reached in Logging Library
Joy added the comment: Yes, still working on a script for this bug. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue38921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38921] Max Recursion Depth Reached in Logging Library
Joy added the comment:
This script should produce the following error:
Traceback (most recent call last):
File "logging_test_script.py", line 70, in
testobj.main()
File "logging_test_script.py", line 62, in main
Logger.main_logger.info('Adding a line into {}'.format(source))
File "/usr/lib/python3.7/logging/__init__.py", line 1378, in info
self._log(INFO, msg, args, **kwargs)
File "/usr/lib/python3.7/logging/__init__.py", line 1514, in _log
self.handle(record)
File "/usr/lib/python3.7/logging/__init__.py", line 1524, in handle
self.callHandlers(record)
File "/usr/lib/python3.7/logging/__init__.py", line 1586, in callHandlers
hdlr.handle(record)
File "/usr/lib/python3.7/logging/__init__.py", line 894, in handle
self.emit(record)
File "/usr/lib/python3.7/logging/__init__.py", line 1127, in emit
StreamHandler.emit(self, record)
File "/usr/lib/python3.7/logging/__init__.py", line 1025, in emit
msg = self.format(record)
File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
return fmt.format(record)
File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
return fmt.format(record)
File "/usr/lib/python3.7/logging/__init__.py", line 869, in format
return fmt.format(record)
[Previous line repeated 984 more times]
File "/usr/lib/python3.7/logging/__init__.py", line 609, in format
if self.usesTime():
File "/usr/lib/python3.7/logging/__init__.py", line 577, in usesTime
return self._style.usesTime()
File "/usr/lib/python3.7/logging/__init__.py", line 419, in usesTime
return self._fmt.find(self.asctime_search) >= 0
RecursionError: maximum recursion depth exceeded while calling a Python object
--
Added file: https://bugs.python.org/file48840/logging_test_script.py
___
Python tracker
<https://bugs.python.org/issue38921>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file (with fix)
David Joy added the comment: Hi All, I just built mysql-python against CPython2.7 MSVC2008 Express Edition and Server 2003 R2. All were freshly built on a clean Server 2003 install. This exact issue occurred building with pip 0.8.1 on top of distribute 0.6.14: C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin\mt.exe -nologo -manifest build\temp.win32-2.7\Release\_mysql.pyd.manifest -outputresource:build\lib.win32-2.7\_mysql.pyd;2 build\temp.win32-2.7\Release\_mysql.pyd.manifest : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. error: command 'mt.exe' failed with exit status 31 Command C:\Python27\python.exe -c "import setuptools;__file__='C:\\Documents and Settings\\Administrator\\build\\mysql-python\\setup.py';execfile(__file__)" install --single-version-externally-managed --record c:\docume~1\admini~1\locals~1\temp\pip-qqb1ax-record\install-record.txt failed with error code 1 Storing complete log in C:\Documents and Settings\Administrator\Application Data\pip\pip.log Pavel's patch fixes my build. Does this patch break something else? I can reproduce this on 2.7 and 2.6.6. -- nosy: +David.Joy versions: +Python 2.7 -Python 2.6 ___ Python tracker <http://bugs.python.org/issue4431> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file (with fix)
David Joy added the comment: Hi Marc, Well, I fried my original server install trying to trace this. My new fresh install can still reproduce the problem with mysql-python, but I can't recreate the issue with PyOpenSSL anymore. Grabbing packages at random from PyPi hasn't given me a single issue so far, so I'm going to say this is an issue with mysql-python only and redirect my efforts there. Thanks for your help, -David -- ___ Python tracker <http://bugs.python.org/issue4431> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35083] Fix documentation for __instancecheck__
New submission from Joy Diamond :
This is a request to fix the documentation for __instancecheck__.
Please add the following:
"""
(Note that any object `x` is always considered to be an instance of
`type(x)`, and this cannot be overridden.)
"""
Consider the following program:
class M(type):
def __instancecheck__(m, t):
print('instancecheck(%s, %s)' % (m, t))
return False# LIE!
Test = M('Test', ((object,)), {})
something = Test()
print('Does *NOT* call __instancecheck__:')
print('isinstance(something, Test): %s' % isinstance(something, Test))
print()
print('Does call __instancecheck__:')
print('isinstance(0, Test): %s' % isinstance(0, Test))
Under python 2, python 3, and pypy, in all cases, the first examples does *NOT*
call __instancecheck__.
You can see the optimization here:
https://github.com/python/cpython/blob/master/Objects/abstract.c#L2397-L2405
Which reads:
int
PyObject_IsInstance(PyObject *inst, PyObject *cls)
{
_Py_IDENTIFIER(__instancecheck__);
PyObject *checker;
/* Quick test for an exact match */
if (Py_TYPE(inst) == (PyTypeObject *)cls)
return 1;
I'm fine with the optimization -- I am not suggesting to get rid of it.
I just want the documentation to match the actual implementation.
The following documentation needs to be fixed:
https://docs.python.org/2/reference/datamodel.html
https://docs.python.org/3/reference/datamodel.html
https://www.python.org/dev/peps/pep-3119/
It took me half an hour to figure out why my version of __instancecheck__ was
not working, as I tried to test it using the super simple code above ...
One of the best things about python is how accurate and consistent the
documentation is.
This request is to keep these high standards.
--
assignee: docs@python
components: Documentation
messages: 328658
nosy: docs@python, joydiamond
priority: normal
severity: normal
status: open
title: Fix documentation for __instancecheck__
type: enhancement
versions: Python 2.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue35083>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35098] Deleting __new__ does not restore previous behavior
New submission from Joy Diamond :
Related: https://bugs.python.org/issue5322
Consider the following program:
class Color(object):
__slots__ = (('name',))
def __init__(self, name):
self.name = name
green = Color('green') # Works
assert green.name == 'green'
Color.__new__ = 0
del Color.__new__
red = Color('red') # Fails in Python 3; works in Python 2 & pypy
assert red.name == 'red'
This works in Python 2, pypy, but fails in Python 3 as follows:
Traceback (most recent call last):
File "x.py", line 13, in
red = Color('red') # Fails in Python 3; works in Python 2 & pypy
TypeError: object() takes no parameters
--
messages: 328773
nosy: joydiamond
priority: normal
severity: normal
status: open
title: Deleting __new__ does not restore previous behavior
versions: Python 3.5, Python 3.7
___
Python tracker
<https://bugs.python.org/issue35098>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35098] Deleting __new__ does not restore previous behavior
Joy Diamond added the comment:
Its quite valid to assign to __new__ to replace the behavior of how an instance
is created.
(Obviously you would not really assign `0` to it; my example was just to show
the `del Color.__new__` fails - so what was assigned was not relevant).
Here is a more realistic assignment to __new__ -- this one shows we are
"caching" the instance "green" -- so it is reused:
class Color(object):
__slots__ = (('name',))
def __init__(self, name):
self.name = name
green = Color('green') # Works
assert green.name == 'green'
@staticmethod
def Color__new__cache_green(m, name):
if name == 'green':
return green
return object.__new__(m, name)
Color.__new__ = Color__new__cache_green
green_2 = Color('green')
assert green_2 == green
blue = Color('blue')
assert blue.name == 'blue'
del Color.__new__
red = Color('red') # Fails in Python 3; works in Python 2 & pypy
assert red.name == 'red'
Finally as for `Color.__x__` assignment, this has nothing to do with
`__slots__` as it is assigning to `Color`, not to an instance of `Color`.
`green.__x__ = 0` properly fails since there is no `__x__` slot:
AttributeError: 'Color' object has no attribute '__x__'
--
___
Python tracker
<https://bugs.python.org/issue35098>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35106] Add documentation for `type.__subclasses__` to docs.python.org
New submission from Joy Diamond : Add documentation for `type.__subclasses__` to docs.python.org Python ideas discussion: https://mail.python.org/pipermail/python-ideas/2018-October/054361.html -- assignee: docs@python components: Documentation messages: 328848 nosy: docs@python, joydiamond priority: normal severity: normal status: open title: Add documentation for `type.__subclasses__` to docs.python.org versions: Python 2.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue35106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35106] Add documentation for `type.__subclasses__` to docs.python.org
Joy Diamond added the comment: Documented here: https://docs.python.org/3/library/stdtypes.html#class.__subclasses__ (Though does not appear in google searches) -- stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue35106> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35158] Fix PEP 3115 to NOT imply that the class dictionary is used in the final created class
New submission from Joy Diamond : Fix the following in https://www.python.org/dev/peps/pep-3115/ REPLACE: """ def __new__(cls, name, bases, classdict): # Note that we replace the classdict with a regular # dict before passing it to the superclass, so that we # don't continue to record member names after the class # has been created. result = type.__new__(cls, name, bases, dict(classdict)) result.member_names = classdict.member_names return result """ WITH: """ def __new__(cls, name, bases, classdict): result = type.__new__(cls, name, bases, classdict) result.member_names = classdict.member_names return result """ REMOVING the incorrect comment & copying of `classdict` According to: https://docs.python.org/3/reference/datamodel.html#preparing-the-class-namespace "When a new class is created by type.__new__, the object provided as the namespace parameter is copied to a new ordered mapping and the original object is discarded." Hence there is no need to copy `classdict` -- messages: 329213 nosy: joydiamond priority: normal severity: normal status: open title: Fix PEP 3115 to NOT imply that the class dictionary is used in the final created class ___ Python tracker <https://bugs.python.org/issue35158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
