[issue5206] with context object for unittest assertRaises()
New submission from Martin Blais :
Here is a useful trick to restore the normal call syntax for delayed
evaluation for assertRaises():
from contextlib import contextmanager
@contextmanager
def raised(exctype):
try:
yield
raise AssertionError("Exception %s not raised." %
exctype.__name__)
except exctype, e:
pass
Then you can do this::
with raised(ValueError):
rate = foo(arg1, arg2)
Instead of ::
self.assertRaises(foo, arg1, arg2)
Which means you don't have to break the function from its arguments (it
doesn't look like a function call anymore).
P.S. I know I didn't include self up there in my proposed implementation
but it could be parameterized to get the failureException.
(This is a second issue:)
However, I really think that all the failUnlessXXX methods should be
taken out of the class and made available at module level so that they
can be reused by py.test tests as well, and they are perhaps even worthy
of their own module. I can't remember a single instance where I had to
override that failureException class...
Comments welcome, I'd be happy to fix this one myself if we can restore
my commit privileges (I think they expired because I didn't use them
since the need-for-speed workshop.)
--
messages: 81564
nosy: blais
severity: normal
status: open
title: with context object for unittest assertRaises()
___
Python tracker
<http://bugs.python.org/issue5206>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5206] with context object for unittest assertRaises()
Changes by Martin Blais : -- components: +Library (Lib) type: -> feature request ___ Python tracker <http://bugs.python.org/issue5206> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5631] Distutils "upload" command does not show up in --help-commands output.
New submission from Martin Blais : The output of running "python setup.py --help-commands" does not include the "upload" command. -- components: Library (Lib) messages: 84884 nosy: blais severity: normal status: open title: Distutils "upload" command does not show up in --help-commands output. versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker <http://bugs.python.org/issue5631> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings
Martin Blais added the comment: Thank you Martin! -- ___ Python tracker <http://bugs.python.org/issue24278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings
Martin Blais added the comment: LGTM! Thanks for making the change. -- ___ Python tracker <http://bugs.python.org/issue24278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings
New submission from Martin Blais: Functions that parse arguments like PyArg_ParseTupleAndKeywords() have several formatters that fill in C strings, e.g. "s". In the C API doc: https://docs.python.org/3.5/c-api/arg.html#c.PyArg_ParseTupleAndKeywords There should be an explicit mention of whether this memory needs to be free (in this case: No) and if not, how this memory is managed (in this case: This refers to a buffer managed by the string object itself). Because of questions of encoding, it raises questions where this memory lies, and what its lifetime is (in this case: That of the owning string object from the caller). This deserves an explicit mention, even if brief. -- assignee: docs@python components: Documentation messages: 243987 nosy: blais, docs@python priority: normal severity: normal status: open title: Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings ___ Python tracker <http://bugs.python.org/issue24278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings
Martin Blais added the comment: I don't think I'm the right person to propose a patch for this; I'm just guessing how it works so far, I haven't had time to look into the source code in detail, I'm sure there's a lot more context to it. -- ___ Python tracker <http://bugs.python.org/issue24278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings
Martin Blais added the comment: Adding information that tells developers where the memory for those returned areas is stored and as you mention, its lifetime guarantees w.r.t. to the Python object, would go a long way towards making this more clear. The questions that immediately came to my mind were: - Is this memory attached to the object? - What if there is a conversion... is it still attached to the object? The converter for "s" says "Unicode objects are converted to C strings using 'utf-8' encoding." Where is the output of this conversion stored? Does it have the same lifetime as its PyObject as well or does it use a cache of recent conversions (e.g. like re/struct), or just static storage? And if so, is it thread-safe? I can find all these answers by looking at the source code for C/Python, or I can _guess_ that extra data is attached to some sort of 'extra' field in a PyObject (which would be a sensible thing to do), but my point is that an API user shouldn't have to dig in the source or have to guess for such important concerns. I think we should be a bit more transparent in the docs. -- ___ Python tracker <http://bugs.python.org/issue24278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24278] Docs on Parsing arguments should say something about mem mgmt for formatters returning C strings
Martin Blais added the comment: Oh, and yes, just adding this info at the top would be fine IMO. It shouldn't have to be repeated. -- ___ Python tracker <http://bugs.python.org/issue24278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10049] Add a "no-op" (null) context manager to contextlib
Martin Blais added the comment: I've been looking for this today; I would have used it. Instead of an obvious (and explicit) null context manager, I had to read through this entire thread to eventually find out that I can use something called ExitStack(), which is designed for another use case. When many users have to replicate the same boilerplate code time and time again, it's not cruft, it's just something that ought to be part of the stdlib. There are a number of such cases in the stdlib. I think nullcontext should be part of the included batteries Python aims to provide. ------ nosy: +Martin Blais ___ Python tracker <http://bugs.python.org/issue10049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())
Martin Blais added the comment: Adding nullcontext = ExitStack in the source file would solve this problem in a single line of code. -- nosy: +blais ___ Python tracker <http://bugs.python.org/issue10049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10049] Add a "no-op" (null) context manager to contextlib (Rejected: use contextlib.ExitStack())
Martin Blais added the comment: Well that just echoes exactly what I originally thought, but somebody else said it was not needed because ExitStack already exists and could be used for that purpose. If this were at work and/or it were all just to me, I'd just implement a brand new nullcontext and move on. -- ___ Python tracker <http://bugs.python.org/issue10049> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
