[issue23378] argparse.add_argument action parameter should allow value extend
New submission from the mulhern:
As well as the append action it would be convenient for there to be an extend
action.
This is kind of useful to allow something like:
parser.add_argument("--foo", action="extend", nargs="+", type=str)
given
parser.parse_args("--foo f1 --foo f2 f3 f4".split())
to result in
["f1", "f2", "f3", "f4"].
The action "append" results in
[["f1"], ["f2", "f3", "f4"]]
And action store in
["f2", "f3", "f4"].
It is easy to write a custom action, but it feels like a fairly common
requirement.
Probably it would make sense to extend the default, similarly to how append
behaves.
--
components: Library (Lib)
messages: 235260
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: argparse.add_argument action parameter should allow value extend
type: enhancement
versions: Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue23378>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21794] stack frame contains name of wrapper method, not that of wrapped method
New submission from the mulhern:
>>> def decorator(f):
... @functools.wraps(f)
... def new_func(self, junk):
... stack = inspect.stack()
... for i, frame in enumerate(stack):
... print("%s" % frame[3])
... f(self, junk)
... return new_func
...
>>> @decorator
... def junk(self, p):
... print("%s" % junk.__name__)
...
>>> junk("a", "b")
new_func
junk
>>> junk.__name__
'junk'
Note that the wrapper function itself inspects the stack, printing out the
names of methods on the stack.
Note that "junk", the name of the wrapped function does not appear on the
stack, it is only printed out by the junk method itself.
I think that the name of the function at the top of the stack should be the
name of the wrapped function, not of its wrapper. The name of the wrapper
function should not appear at all.
--
components: Interpreter Core
messages: 220863
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: stack frame contains name of wrapper method, not that of wrapped method
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue21794>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21133] unittest discover should allow option to run each package separately
New submission from the mulhern: You can run "python -m unittest discover " and the unittests discovered by discover will be run. This is nice. However, it is actually desirable to run each unittest package individually, rather than in the same interpreter instance. When run via discover, imports from previous unittests corrupt the namespace of subsequent unittests and lead to failures (usually if there are mock objects in previously imported unit tests) and successes (usually if some other test module has imported something that the current test module ought to import but does not) which are both erroneous. discover should have some option to start the interpreter afresh for each unittest package or perhaps just clear all its imports. -- components: Library (Lib) messages: 215380 nosy: the.mulhern priority: normal severity: normal status: open title: unittest discover should allow option to run each package separately type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue21133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20918] Logging of logging exceptions can fail in 3.4 if args are unprintable
the mulhern added the comment: Thanks for the fix. When you say "having repr raise is a pretty unusual occurrence" you probably mean "having repr raise should be a pretty unusual occurrence". I think its more usual than you realize and the regression in 3.4 will have consequences. -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue20918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20897] @abstractmethod does not enforce method signatures
the mulhern added the comment: I feel that I worded this in a way that makes it look like I'm asking for an enhancement, not reporting a bug, so I'll try again. The documentation for 2.7.6 and 3.4.0 says: Using this decorator requires that the class’s metaclass is ABCMeta or is derived from it. A class that has a metaclass derived from ABCMeta cannot be instantiated unless all of its abstract methods and properties are overridden. The abstract methods can be called using any of the normal ‘super’ call mechanisms. The second sentence is a little obscure, but what it must mean is that a class that has a metaclass derived from ABCMeta or a class that extends such a class cannot be instantiated unless all of its abstract method and properties are overridden. Now, in this example, both Sub and SuperSubber have an abstract method _junk(self) and neither of them overrides this method. Therefore, neither should be instantiated. But they can both be instantiated in 3.3 and one can be instantiated in 2.7. So, the behavior does seem to me to disagree with the documentation. In fact, in Python 3.3.2 I can instantiate the META class in the example, which seems really wrong. I can not instantiate the META class in 2.7.6. -- type: enhancement -> behavior ___ Python tracker <http://bugs.python.org/issue20897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20918] Logging of logging exceptions can fail in 3.4 if args are unprintable
the mulhern added the comment: Yes, I really misinterpreted what I saw. So glad it's a bug anyway and I'm not just wasting your time ;) -- ___ Python tracker <http://bugs.python.org/issue20918> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20918] LogRecord.__init__ should handle exception if % operation fails
New submission from the mulhern:
Here's my illustrating trace:
Python 3.3.2 (default, Aug 23 2013, 19:00:04)
[GCC 4.8.1 20130603 (Red Hat 4.8.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> class Junk():
... def __repr__(self):
... raise AttributeError("junk")
...
>>> import logging
>>> logging.warning("%r", Junk())
Traceback (most recent call last):
File "/usr/lib64/python3.3/logging/__init__.py", line 937, in emit
msg = self.format(record)
File "/usr/lib64/python3.3/logging/__init__.py", line 808, in format
return fmt.format(record)
File "/usr/lib64/python3.3/logging/__init__.py", line 546, in format
record.message = record.getMessage()
File "/usr/lib64/python3.3/logging/__init__.py", line 311, in getMessage
msg = msg % self.args
File "", line 3, in __repr__
AttributeError: junk
Logged from file , line 1
The alternative that would be desirable is that the LogRecord initializer
would catch the exception and log that something bad happened while
trying to log. I expect that it would be better if it were optional
behavior.
Note that the use of the % operator happens very early in the logging
process, so implementing your own handler or overriding the makeRecord
method won't fix this problem.
There are plenty of situations where you would like to log a lot
of information, but would be embarrassed to crash while logging.
I realize that I could implement this by surrounding every log call
with some function that caught the exception and then logged that
an exception had occurred while trying to log, but I think it
might work better within the logging module.
--
components: Library (Lib)
messages: 213465
nosy: the.mulhern
priority: normal
severity: normal
status: open
title: LogRecord.__init__ should handle exception if % operation fails
type: enhancement
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
___
Python tracker
<http://bugs.python.org/issue20918>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20897] @abstractmethod does not enforce method signatures
New submission from the mulhern: Hi! Here is a simple class hierarchy: >>> import abc >>> class META(object): ... __metaclass__ = abc.ABCMeta ... @abc.abstractmethod ... def _junk(self): ... pass ... >>> class Sub(META): ... def _junk(self, other): ... pass ... >>> class Subber(META): ... def _junk(self): ... pass ... >>> class SuperSubber(META): ... pass ... In 2.7.5 I can instantiate an object of Sub or Subber, although Sub does not really override META's abstract method. I think it would be better if I could not instantiate Sub, because the signature of the abstract method in META is different from the signature of the overriding method in Sub. I can not instantiate SuperSubber, I get a TypeError. That seems correct. In 3.3.2 I can instantiate all three, Sub, Subber, and SuperSubber. I would prefer to only be able to instantiate Subber, since it is the only class that truly overrides the abstract method _junk in META. - mulhern -- components: Library (Lib) messages: 213256 nosy: the.mulhern priority: normal severity: normal status: open title: @abstractmethod does not enforce method signatures type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue20897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20145] unittest.assert*Regex functions should verify that expected_regex has a valid type
the mulhern added the comment: Thanks, I'ld definitely be _much_ happier w/ a TypeError than with silent success. -- ___ Python tracker <http://bugs.python.org/issue20145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20145] unittest.assert*Regex functions should verify that expected_regex has a valid type
the mulhern added the comment: Yes. I'ld check if it was a string or a regex object...there is already code that converts the string to a regular expression in there. -- ___ Python tracker <http://bugs.python.org/issue20145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20659] Want to make a class method a property by combining decorators
New submission from the mulhern: The problems is that it is quite possible to define a property using @property in a class and then later to realize that it really ought to be a class method, not an instance method. But then, if you change it to a class method, using @classmethod annotation, the @property annotation will fail to work. If you are a pedantic person, and name your properties differently than you name your methods, you have to: 1) Change all uses of this former property back to method invocations, with a "()" 2) Change the name, so it now reflects that it is an actual function, not a property any longer. I think an @classproperty and an @staticproperty decorator would take this problem away. An alternative would be to make it possible to chain @property and @classmethod. I know that this is sort of doable for ABC.abstractproperty which is now deprecated in favor of @property combined with @ABC.abstractmethod. This would be ideal, but I can not pretend to know if it would be possible. Also, I suspect that the order would matter as it does for ABC as described in http://bugs.python.org/issue16267. -- components: Library (Lib) messages: 211416 nosy: the.mulhern priority: normal severity: normal status: open title: Want to make a class method a property by combining decorators type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue20659> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20145] unittest.assert*Regex functions should verify that expected_regex has a valid type
New submission from the mulhern: A normal thing for a developer to do is to convert a use of an assert* function to a use of an assert*Regex function and foolishly forget to actually specify the expected regular expression. If they do this, the test will always pass because the callable expression will be in the place of the expected regular expression and the callable expression will, therefore, be None. It would be nice if in the constructor in AssertRaisesBaseContext (for 3.5) not only was the expected regex converted to a regex (if actually a string or bytes) but if it's not if it were checked if it were a valid regular expression object and an exception raised if this is not the case. In the current version of AssertRaisesBaseContext.handle the comments say that if the callable object is None then the function is being used as a context manager. Not always the case, alas, perhaps the developer just forgot to add that necessary regular expression before the callable object. -- messages: 207436 nosy: the.mulhern priority: normal severity: normal status: open title: unittest.assert*Regex functions should verify that expected_regex has a valid type type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue20145> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
