[issue20754] distutils should use SafeConfigParser

2014-02-23 Thread Alex Brandt 

New submission from Alex Brandt:

I first noticed this issue when configuring nose via setup.cfg and reported the 
behavior in this issue on their tracker: 
https://github.com/nose-devs/nose/issues/733

I'll repaste the important bits here:

When using a setup.cfg with the following contents (including minor variations):

[nosetests]
logging-format = %(lineno)d: %(process)d: %(message)s
With any setup.py file the following error is raised when trying to run 
setup.py (python2.7 used for example, error also occurs in 3.3):

alunduil@elijah margarine % python2.7 setup.py nosetests
Traceback (most recent call last):
  File "setup.py", line 108, in 
setup(**PARAMS)
  File "/usr/lib64/python2.7/distutils/core.py", line 125, in setup
dist.parse_config_files()
  File "/usr/lib64/python2.7/distutils/dist.py", line 397, in parse_config_files
val = parser.get(section,opt)
  File "/usr/lib64/python2.7/ConfigParser.py", line 623, in get
return self._interpolate(section, option, value, d)
  File "/usr/lib64/python2.7/ConfigParser.py", line 669, in _interpolate
option, section, rawval, e.args[0])
ConfigParser.InterpolationMissingOptionError: Bad value substitution:
section: [nosetests]
option : logging-format
key: pathname
rawval : %(pathname)s:%(lineno)d: %(process)d: %(message)s

The suggested fix of using %% to pass the interpolation through to nose 
requires that distutils use SafeConfigParser rather than ConfigParser.

I've verified that this does indeed appear to work (at least fixing the 
distutils interaction).  The only place the change needs to be made is on lines 
378 and 386 in distutils/dist.py.

I can attach a patch or send a pull request with this fix if there are no 
objections to this solution.

--
components: Distutils
messages: 212048
nosy: alunduil
priority: normal
severity: normal
status: open
title: distutils should use SafeConfigParser
type: behavior
versions: Python 2.7, Python 3.3

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

[issue26133] TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a callable object in

2016-01-16 Thread Alex Brandt 

New submission from Alex Brandt:

When using the suggested practice of setting a stop loop signal handler with:

loop.add_signal_handler(signal.SIGTERM, loop.stop)

The following stack trace is given when the signal runs:

ligament_1 | Exception ignored in: >
ligament_1 | Traceback (most recent call last):
ligament_1 |   File "/usr/lib/python3.5/asyncio/base_events.py", line 387, in 
__del__
ligament_1 |   File "/usr/lib/python3.5/asyncio/unix_events.py", line 58, in 
close
ligament_1 |   File "/usr/lib/python3.5/asyncio/unix_events.py", line 139, in 
remove_signal_handler
ligament_1 |   File "/usr/lib/python3.5/signal.py", line 47, in signal
ligament_1 | TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, 
or a callable object

Since this happens during shutdown of the application I wouldn't consider this 
a high priority bug but it is quite annoying.  I've also not investigated if 
this interrupts the loop stopping procedure yet.

--
components: asyncio
messages: 258401
nosy: Alex Brandt, gvanrossum, haypo, yselivanov
priority: normal
severity: normal
status: open
title: TypeError: signal handler must be signal.SIG_IGN, signal.SIG_DFL, or a 
callable object in >
type: crash
versions: Python 3.5

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