Re: trying to find nose.tools.assert_raises_regexp

2014-05-23 Thread qhfgva
I knew it had to be something like that. Thanks. Time to upgrade. On Friday, May 23, 2014 6:07:08 PM UTC-6, Ned Batchelder wrote: > On 5/23/14 6:09 PM, qhfgva wrote: > > > $ python > > > Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) > > > [GCC 4.4.

trying to find nose.tools.assert_raises_regexp

2014-05-23 Thread qhfgva
$ python Python 2.6.5 (r265:79063, Apr 16 2010, 13:09:56) [GCC 4.4.3] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import nose.tools >>> nose.__version__ '1.3.3' >>> nose.tools.assert_raises_regexp Traceback (most recent call last): File "", line 1, in At

pychecker vs pychecker2

2009-05-04 Thread qhfgva
qhfgva -- http://mail.python.org/mailman/listinfo/python-list

authentication for xmlrpc via cgi

2005-09-22 Thread qhfgva
I'm using python 2.2 (hopefully we'll be upgrading our system to 2.3 soon) and I'm trying to prototype some xml-rpc via cgi functionality. If I override the Transport class on the xmlrpclib client and add some random header like "Junk", then when I have my xmlrpc server log it's environment when ru

Re: circular imports

2005-05-20 Thread qhfgva
All of the __init__.py files are empty and I don't know of any overlapping of names. Like I said this is code that works fine, I'm just trying to clean up some things as I go. Here are my working examples: x1.py == # how things work in our code now: # called with home/dlee/test/module python

circular imports

2005-05-20 Thread qhfgva
I'm working with a large code base that I'm slowly trying to fix "unpythonic" features of. One feature I'm trying to fix is the use of: # how things are now sys.path.append('/general/path/aaa/bbb') # lots of lines like this to specific dirs import foo Insead I'd rather have PYTHONPATH already in

Re: python execution path

2005-01-17 Thread qhfgva
Peter Hansen wrote: > Dustin Lee wrote: > > I'm wondering if there is a way to get python to show each line as it > > is executed, sort of like sh -x does for shell programs. Seems like > > this would be a nice debugging aid. > > The best approach, if it's really intended to be a debugging > aid,