I have a need for a timeout feature in some of the subprocess.Popen methods.
I looked around and found this bug
As it seems it the activity on the issue just stopped.
I would like to take the reins on the issue and tie the loose ends. The current state is "test needed".
If it is updated, what tests are missing for it to qualify?
What other comments do you have on the subject?
I have been integrating python scripting support into my project and have
been impressed at how easy it has been with boost::python and the excelant
documentation. I ran into a technical 'problem' today while writing up
Makefiles for my project. It is not really a problem, just unexpected
behavior that I want to propose a change for. But first, a little
I have been doing most of my development so far in windows and just started
porting my project to linux yesterday. Because I want to make using this
project as easy as possible and because I wanted a python debug build, I
integrated python into my building process in windows. This involved
creating a new visual studio project for both pythonlib, and python exe, as
well as a few of the libraries such as _ctypes, _elementtree,
_multiprocessing, and _socket. All these projects compile with my project
and the python Lib directory from the install is kept in a folder that I
then copy into the final destination folder if necessary. I did all this
work so that my users could check out my project, build it, and run it with
python without installing python. Also I wanted a debug build, as mentioned
Anyway, enough background, this works perfectly on windows because in
PC/getpathp.c when everything goes to hell and you cant figure out a path
you default to ./Lib
Because of this behavior, I can copy the Lib directory into the bin dir and
run python no problem. I throw all the .py into $(BIN_DIR)/Lib and the C
libs in $(BIN_DIR)/DLLs and python is happy as a clam.
My trouble, and the reason for this email, is on linux the behavior is
different, and Modules/getpath.c does not default to ./Lib when everything
goes to hell, and I get
Could not find platform independent libraries <prefix>
Could not find platform dependent libraries <exec_prefix>
Consider setting $PYTHONHOME to <prefix>[:<exec_prefix>]
Fatal Python error: Py_Initialize: can't initialize sys standard streams
ImportError: No module named encodings.utf_8
I am going to spend the rest of my afternoon editing Modules/getpath.c and I
thought I would propose updating the non-windows getpath.c file to be more
in line with the windows one. Or at least, have it take some pointers from
Thanks for your time
Earlier this week on the Testing In Python list, there was a
discussion on how to execute a setup and/or teardown for a single test
class instead of for each test fixture on the class (see the 'setUp
and tearDown behavior' thread). I have had to deal with situation
myself before, and I am obviously not the only one (since I did not
initiate the thread). As such I'd like to propose adding a class
level setup and tear down method the unittest TestCase class.
Test cases can at times require the setup of expensive resources.
This is often the case when implementing integration testing. Having
to perform this setup for each fixture can prohibited for large number
of fixtures and/or for resources that are expensive to setup. For
example, I have several hundred integration tests that hit a live
database. If I create the connection object for each fixture, most of
the tests fail due to the maximum connection limit being reached. As
a work around, I create a connection object once for each test case.
Without such functionality built in, the common idiom runs along these
if not self.ClassIsSetup:
While this achieves the desired functionality, it is unclear due to
conditional setup code and is also error prone as the same code
segment would need to appear in every TestCase requiring the
functionality. Having a class wide setup and teardown function that
implementers of test cases can override would make the code/intent
more clear and alleviate the need to implement test case functionality
when the user should be focusing on writing tests.
I emailed Michael Foord about some of his comments in the TIP thread
and to ask if he would be interested in a patch adding this
functionality, and I have included his response below. I would like
to hear people's comments/suggestions/ideas before I start working on
Michael Foord's Email:
I would certainly be interested in adding this to unittest.
It needs a discussion of the API and the semantics:
* What should the methods be called? setup_class and teardown_class or
setupClass and teardownClass? For consistency with existing methods
the camelCase should probably be used.
* If the setupClass fails how should the error be reported? The
*easiest* way is for the failure to be reported as part of the first
* Ditto for teardownClass - again the easiest way is for it to be
reported as a failure in the last test
* If setupClass fails then should all the tests in that class be
skipped? I think yes.
Also details like ensuring that even if just a single test method from
a class is run the setupClass and teardownClass are still run. It
probably needs to go to python-dev or python-ideas for discussion.
All the best,
Is there a reason that queues don't have an `__iter__` method? I mean both
`Queue.Queue` and `multiprocessing.Queue`.
I had to write up my own "iterate on queue" function for use in my project.
Do you think that it should be a built-in method on the Queue class?
I propose that when raising an exception without providing a message, the
first line of the docstring will be shown. (I mean shown in the traceback
where the message would normally be.
>>> class MyExcpetion(Exception):
'''Trying to fit a square piece into a round hole.'''
>>> raise MyExcpetion('Problem bla bla')
Traceback (most recent call last):
File "<pyshell#3>", line 1, in <module>
raise MyExcpetion('Problem bla bla')
MyExcpetion: Problem bla bla
>>> raise MyExcpetion()
Traceback (most recent call last):
File "<pyshell#4>", line 1, in <module>
MyExcpetion: Trying to fit a square piece into a round hole.
This will be useful for me because I often raise exceptions and have nothing
to say besides repeating the exception's docstring, and I have many places
in the code where I'd want to conditionally raise it. I'm faced with two
choices: Type the exception's docstring in every place, which is lame, and
breaks DRY. Or just raise the exception without any message, which may
potentially confuse users.
This is the motivation for this suggestion, so I could be succinct without
What do you think?