[issue38435] Start the deprecation cycle for subprocess preexec_fn
Mark Diekhans added the comment: calling setpgid() is a common post-fork task that would need to be an explicit parameter to Popen when preexec_fn goes away -- nosy: +diekhans ___ Python tracker <https://bugs.python.org/issue38435> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27321] Email parser creates a message object that can't be flattened
Mark Diekhans added the comment: any chance of getting this merged? A work-around is not obvious -- nosy: +diekhans ___ Python tracker <https://bugs.python.org/issue27321> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12600] Support parameterized TestCases in unittest
Mark Diekhans added the comment: The lack of the ability to pass a parameter to a test case is a very frustrating restriction with unittest. The frequent need if for a database connection for testing database related classes. Yes, there are lots of other ways to work around it, but they tend to involved need to understand and subclass several pieces of the unittest framework. An enthusiastic yes on this. -- nosy: +diekhans ___ Python tracker <http://bugs.python.org/issue12600> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12600] Support parameterized TestCases in unittest
Mark Diekhans added the comment: > R. David Murray added the comment: > > Meaning you want to run the same test suite with a variety of > different DB connections? That seems like a reasonable use > case. This is for external parameterization of a test to run in a different environment. Internal reuse of test code is usually better done inside of the code using standard OOP approaches. The different in database connections is due to wanting to run the tests on different systems with different database users, passwords and database names. Normally we have an object that reads this information from file specified on the command line, the object is passed to code that creates the connections. A similar problem exists when tests must be run against a server and require a host name. External parameterization to specify the host name is required. While it's certainly possible to come up with says to pass this setting things in globals (including environment variable), this does lead to confusing code. Mark -- ___ Python tracker <http://bugs.python.org/issue12600> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12600] Support parameterized TestCases in unittest
Mark Diekhans added the comment: Allowing loadTestsFromTestCase() to take either a testCaseClass or a (testCaseClass, param) tuple, where the param is then past to the __init__ function might do the trick. One param is sufficient, since it can be a container for any number of params. This allows more fields to be added to the tuple for some future, unforeseen need. An container object for class and parameters would be a bit more structured than a tuple. A factory function would be the most flexible, however it seems to go against the class introspection for discovering tests. Then again, I don't know the code very well. R. David Murray writes: > > R. David Murray added the comment: > > Maybe we could add a recipe for doing this to the load_tests docs? > > I don't think that load_tests is going to be more readable, though, since it > doesn't allow you to put the parameterization next to the class you are > parameterizing (unless you do some additional hackery). > > But yes, if anything else is done a concrete API proposal is the first > requirement. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue12600> > ___ -- ___ Python tracker <http://bugs.python.org/issue12600> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31989] setattr on a property gives a very unhelpful exception
New submission from Mark Diekhans : done a setattr on a property gives a very unhelpful error message AttributeError: can't set attribute it neither indicates the name of the attribute that failed or the cause. an error such as "can't set property attribute: the_attr_name" would be far more helpful. -- messages: 305933 nosy: diekhans priority: normal severity: normal status: open title: setattr on a property gives a very unhelpful exception type: behavior versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <https://bugs.python.org/issue31989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31989] setattr on a property gives a very unhelpful exception
Mark Diekhans added the comment: The trackback is not helpful if the attribute name is in a variable. It also doesn't explain why the error occurred. While I would not rate this as a high priority, I don't see an argument for having uninformative error messages. Raymond Hettinger writes: > > Raymond Hettinger added the comment: > > Usually, all the necessary information is present in the previous line of the > traceback: > > >>> a.volume = 10 > Traceback (most recent call last): > File "", line 1, in > a.volume = 10 > AttributeError: can't set attribute > > I don't seem to recall anyone else having problems with this error message. > > -- > nosy: +rhettinger > > ___ > Python tracker > <https://bugs.python.org/issue31989> > ___ -- ___ Python tracker <https://bugs.python.org/issue31989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34792] Tutorial doesn''t discuss / and * function arguments
New submission from Mark Diekhans : https://docs.python.org/3/tutorial/controlflow.html doest not discuss / and * arguments (end of positional, keyword required) -- assignee: docs@python components: Documentation messages: 326277 nosy: diekhans, docs@python priority: normal severity: normal status: open title: Tutorial doesn''t discuss / and * function arguments type: enhancement versions: Python 3.7 ___ Python tracker <https://bugs.python.org/issue34792> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29466] pickle does not serialize Exception __cause__ field
New submission from Mark Diekhans: python3 pickle does not serialize the __cause__ field, as shown by the attached demo program. -- components: Library (Lib) files: cause_pickle.py messages: 287163 nosy: diekhans priority: normal severity: normal status: open title: pickle does not serialize Exception __cause__ field type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file46550/cause_pickle.py ___ Python tracker <http://bugs.python.org/issue29466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29466] pickle does not serialize Exception __cause__ field
Changes by Mark Diekhans : -- nosy: +alexandre.vassalotti ___ Python tracker <http://bugs.python.org/issue29466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
