Garrett Cooper added the comment:
Another note: mixed endianness might have been a factor as previous versions of
the product that were shipped used bi-arch x86 (32-bit userland on 64-bit
kernel.
--
___
Python tracker rep...@bugs.python.org
http
Garrett Cooper added the comment:
Yes, it's a duplicate. That being said, documentation alone it should be
unsigned long for Darwin (OS/X), FreeBSD, OpenBSD. Looking at the definition
for ioctl(2), the below example would cause a failure.
I need to hunt around for a practical example as I
New submission from Garrett Cooper:
telnetlib.Telnet.__init__ supports keyword arguments, but the documentation for
2.7.8 ( https://docs.python.org/2/library/telnetlib.html ) claims they're
non-keyword arguments.
The py3k docs are much better (
https://docs.python.org/3/library
Changes by Garrett Cooper yaneg...@gmail.com:
--
versions: +Python 2.7, Python 3.4
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21915
Garrett Cooper added the comment:
The code doesn't appear to be conforming to RFC-3164 or RFC-5424:
(From RFC-3164):
4.1 syslog Message Parts
The full format of a syslog message seen on the wire has three
discernable parts. The first part is called the PRI, the second part
Garrett Cooper added the comment:
Please note that when I said the code I was looking at python 3.3 on OSX
(compiled with MacPorts):
$ python3.3
Python 3.3.5 (default, Mar 11 2014, 15:08:59)
[GCC 4.2.1 Compatible Apple LLVM 5.0 (clang-500.2.79)] on darwin
Type help, copyright, credits
Garrett Cooper added the comment:
Updated patch to incorporate Vinay's comments. Thanks :)!
--
Added file: http://bugs.python.org/file34030/patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20558
Changes by Garrett Cooper yaneg...@gmail.com:
Removed file: http://bugs.python.org/file33986/patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20558
Changes by Garrett Cooper yaneg...@gmail.com:
--
components: +Library (Lib)
type: - behavior
versions: +Python 2.7, Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20558
New submission from Garrett Cooper:
The logging module checks for ECONNRESET if it's equal to 104. This is valid on
Linux, but not [some] other OSes. On FreeBSD and OpenBSD [*] it's 54, not 104.
The attached patch fixes the logging code to check for errno.ECONNRESET in
!win32 environments
Garrett Cooper added the comment:
Good to know!
I updated the patch to remove the errno abstraction, grab the errno attribute
from the OSError, and sort the imports.
--
Added file: http://bugs.python.org/file33986/patch
___
Python tracker rep
New submission from Garrett Cooper:
I was a bit surprised when I ran into this issue when porting some nose tests
from Windows to Linux:
#!/usr/bin/env python
with open('/etc/services') as fd:
lines = fd.readlines()
lines.append('')
SERVICES = [line.split()[0] for line in lines
Garrett Cooper added the comment:
The whole permissions setting operation seems a bit convoluted.
I was hoping there was something formalized with install_data.py where I could
specify a default or fine-grained user/group/mode for files, but it doesn't
appear to be possible. I'll investigate
Garrett Cooper added the comment:
Feel free to close this. I don't have any interest in pursuing it further.
--
nosy: +Garrett.Cooper
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8079
Garrett Cooper added the comment:
Yes. Submitting a patch to fix this based on hg master shortly..
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16124
Garrett Cooper added the comment:
$ uname -a
FreeBSD bayonetta.local 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r240836M: Sat
Sep 22 12:30:11 PDT 2012
gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA amd64
$ ./configure --prefix=/scratch/python-bin/3k/
...
$ make all
Garrett Cooper added the comment:
Sorry; previous patch is not applicable to this issue. This one is.
--
Added file: http://bugs.python.org/file27952/python-issue16124.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16124
Changes by Garrett Cooper yaneg...@gmail.com:
Removed file: http://bugs.python.org/file27951/python-issue13500-test.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16124
Garrett Cooper added the comment:
And I missed the int - unsigned int part. Resubmitting one last time for
tonight..
--
Added file: http://bugs.python.org/file27953/python-issue16124.patch
___
Python tracker rep...@bugs.python.org
http
Changes by Garrett Cooper yaneg...@gmail.com:
Removed file: http://bugs.python.org/file27953/python-issue16124.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16124
Garrett Cooper added the comment:
Grr... Let's try again.
--
Added file: http://bugs.python.org/file27954/python-issue16124.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16124
Garrett Cooper added the comment:
... g'night.
--
Added file: http://bugs.python.org/file27955/python-issue16124.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16124
New submission from Garrett Cooper:
As discussed in ID # 1471, the type for request is not 100% correct on some
platforms (FreeBSD, NetBSD, and OpenBSD, for instance) and the custom platform
that I'm using unfortunately uses non-32-bit int ioctls. An autoconf test needs
to be added
New submission from Garrett Cooper:
Windows doesn't return sane values for localtime(3) (per POSIX [1]) when
the BIOS is set to the local time (the host is a Win2k8-R2 machine):
$ python -V; python -c 'import time; print time.strftime(%m-%d-%y %H:%M:%S,
time.localtime())'; date; uname
Garrett Cooper added the comment:
1. http://pubs.opengroup.org/onlinepubs/009695299/functions/localtime.html
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15942
Garrett Cooper added the comment:
Except it wasn't built within the Cygwin environment...
$ python -c 'import sys; print sys.version'
2.6.1 (r261:67515, Dec 5 2008, 13:58:38) [MSC v.1500 32 bit (Intel)]
$ ldd `which python` | grep -i ygwin || echo not cygwin
not cygwin
Garrett Cooper added the comment:
Ok. Turns out I got this backwards. The BIOS clock is set to UTC (which works
with the CentOS install on the same drive) and Windows assumes the clock is set
to local time [1]. I'll follow it up with the my $work lab team, but it would
be nice if this could
Garrett Cooper added the comment:
Hahaha... you're right:
$ perl -e 'use POSIX; print strftime(%m-%d-%y %H:%M:%S, localtime).\n;';
date
09-13-12 23:25:49
Thu, Sep 13, 2012 3:25:49 PM
$ python -c 'import time; print time.strftime(%m-%d-%y %H:%M:%S,
time.localtime())'; date
09-13-12 23:26:25
On May 9, 2012, at 12:38 PM, Javier Novoa C.
jsti...@invernalia.homelinux.net wrote:
Hi,
I am using time.strptime method as follows:
I receive an input string, representing some date in the following
format:
%d%m%Y
However, the day part may be a single digit or two, depending on
Hi Python folks!
I came across a piece of code kicking around a sourcebase that
does something similar to the following:
START
#!/usr/bin/env python
import sys
def foo():
bar = 'abcdefg'
foo = [ 'a' ]
# Should throw SyntaxError?
for foo[0]in bar:
On Thu, May 3, 2012 at 12:03 PM, Ian Kelly ian.g.ke...@gmail.com wrote:
On Thu, May 3, 2012 at 12:49 PM, Garrett Cooper yaneg...@gmail.com wrote:
I was wondering whether this was a parser bug or feature (seems
like a bug, in particular because it implicitly encourages bad syntax,
but I
Garrett Cooper yaneg...@gmail.com added the comment:
Here's a unittest patch for the py3k branch.
{{{
1 items passed all tests:
32 tests in test.test_cmd.samplecmdclass
32 tests in 19 items.
32 passed and 0 failed.
Test passed.
doctest (test.test_cmd) ... 32 tests with zero failures
Garrett Cooper yaneg...@gmail.com added the comment:
I'll verify the fix in another day or two.
FWIW unless python is willing to import pexpect, or provide an equivalent, I'm
not sure how items like this which require interactive input can be run via
the python project testing framework
Garrett Cooper yaneg...@gmail.com added the comment:
Ok. I'll see if I can provide a unittest for this by the 12th.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13500
New submission from Garrett Cooper yaneg...@gmail.com:
Was poking around config.log and I saw that gcc was complaining of some
undefined built-in symbols for the broken nice test in configure. This patch
fixes that.
--
files: configure-fix-broken-broken-nice-test.patch
keywords: patch
Garrett Cooper yaneg...@gmail.com added the comment:
Other potential issues are provided below:
configure:9015: checking if PTHREAD_SCOPE_SYSTEM is supported
configure:9038: gcc -pthread -o conftest -I/usr/include/edit conftest.c 5
conftest.c: In function 'main':
conftest.c:101: warning
New submission from Garrett Cooper yaneg...@gmail.com:
Pressing enter produces no output with cmd.py whenever ^D has been entered
in; after I enter in ^D it gets into an infinite loop spewing out messages via
cmd.Cmd.default() about EOF because self.lastcmd isn't being reset properly
New submission from Garrett Cooper yaneg...@gmail.com:
The attached patch enables libedit support in a generic way via configure.in,
so I can pass in --with-readline=editline, --with-readline=readline,
--with-readline=yes, or --with[out]-readline[=no] and it will do one of the
following:
1
Garrett Cooper yaneg...@gmail.com added the comment:
Sure -- the repro steps are pretty easy:
1. Startup an interactive python shell.
2. Enter in the following code:
{{{
import cmd
class Foo(cmd.Cmd):
def do_bar(self, arg):
bar
Foo().cmdloop()
}}}
3. You will be greeted
Garrett Cooper yaneg...@gmail.com added the comment:
Here's a version incorporating your suggestion and better documenting the
choices and the method for overriding purposes. I have a few reservations with
the current implementation:
1. As noted, the information for the class really could
Garrett Cooper yaneg...@gmail.com added the comment:
I realize that this bug is closed, but I just had a comment to make.
Handling EOF is simple:
def do_EOF(self, arg):
pass
For my purposes I want to raise an EOFError so I can trickle up the chain to
the appropriate caller because I'm
New submission from Garrett Cooper yaneg...@gmail.com:
1. The current code in cmd.get_names does a dir on the derived class for
cmd.Cmd object instead, which means that if I do something similar to
the following:
class CLI(cmd.Cmd):
def register_subcommand(self, cmd, cli_class
Garrett Cooper yaneg...@gmail.com added the comment:
As a note for future reference, FreeBSD/NetBSD/OpenBSD doesn't use the term
bug, but instead uses the term problem report (the NetBSD website says
bug though BTW).
The PR system for NetBSD can be accessed here:
http://www.netbsd.org/cgi
New submission from Garrett Cooper yaneg...@gmail.com:
Running 'make clean' leaves libpython*.a behind. The attached patch removes it
when make clean is run.
This was resolved on py3k, not trunk; the attached patch matches what was done
on py3k.
--
components: Build
files: cleanup
Garrett Cooper yaneg...@gmail.com added the comment:
Is svn not being updated anymore (in lieu of hg)?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12433
Garrett Cooper yaneg...@gmail.com added the comment:
I apologize for taking so long with this. The attached patch is for test_posix
against trunk (I shuffled around some code and extended some things to improve
PosixTester.tearDown). Let me know if I need to wash, rinse, repeat for py3k,
etc
Garrett Cooper yaneg...@gmail.com added the comment:
Sorry -- got off-track for a while.
I assume these should go into Lib/test/test_os.py ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8746
Garrett Cooper yaneg...@gmail.com added the comment:
On Mon, Jan 17, 2011 at 5:11 PM, Ned Deily rep...@bugs.python.org wrote:
Ned Deily n...@acm.org added the comment:
There is an existing test_lchflags in Lib/test/test_posix.py. Additional
test cases should go there.
Ok, but again
New submission from Garrett Cooper yaneg...@gmail.com:
The following patch fixes the help docstring as time.tzset when called doesn't
require any arguments (as noted in the source and also in the library
documentation).
The patch produced was against trunk, but this appears to be an issue
Garrett Cooper yaneg...@gmail.com added the comment:
*NOUNLINK was not implemented by OSX, so there's actually a bug with the
compile tests if you take that into consideration. And again, only FreeBSD
defines *NOUNLINK. The other BSDs, not so much.
As far as the reason why I implemented
Garrett Cooper yaneg...@gmail.com added the comment:
I'll add new tests in the next submit for the bug, but here's the code to add
the relevant symbols for common to *BSD and OSX, and the Snow Leopard+ and
FreeBSD specific chflags of importance for python 2.7 and py3k.
--
Added file
Changes by Garrett Cooper yaneg...@gmail.com:
Added file: http://bugs.python.org/file18849/issue8746-py3k.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8746
Garrett Cooper yaneg...@gmail.com added the comment:
Do you prefer exhaustive tests, or just smoke tests? Honestly IMO, the OS
should come prepackaged with tests to ensure that things function according to
the requirements set forth in the manpage, so I would prefer the latter because
the os
Garrett Cooper yaneg...@gmail.com added the comment:
That definitely fixes detection for FreeBSD CURRENT with 2.7 and py3k for me.
I'm looking into providing some unit-tests, but the problem is that whether or
not chflags functions on the underlying filesystem is problematic. For
instance
Garrett Cooper yaneg...@gmail.com added the comment:
The issue is still present.
The overall problem I suppose is with consistency and presentation of features
in the python language.
Many features cannot be presented in a 100% portable manner, and the problem is
that such features
Garrett Cooper yaneg...@gmail.com added the comment:
Well, bash screws up in this dept:
$ ls -l typescript
-rw-r--r-- 1 gcooper gcooper 37875 Jul 12 22:19 typescript
$ sudo sh -c 'test -x typescript; echo $?'
1
$ sudo bash -c 'test -x typescript; echo $?'
0
$ csh
%if (-x typescript
Garrett Cooper yaneg...@gmail.com added the comment:
My initial analysis was incorrect after talking with the bash(1) folks. test(1)
is doing things wrong too:
case FILEX:
/* XXX work around eaccess(2) false positives for superuser */
if (eaccess(nm
Garrett Cooper yaneg...@gmail.com added the comment:
My initial analysis was incorrect after talking with the bash(1) folks. test(1)
is doing things wrong too:
case FILEX:
/* XXX work around eaccess(2) false positives for superuser */
if (eaccess(nm
New submission from Garrett Cooper yaneg...@gmail.com:
As seen in the nose bug [1], I stumbled upon an OS quirk with FreeBSD, where
apparently (as superuser) due to the wording of the POSIX spec for access(2),
it's considered free game to return 0 for the system call (True) for
os.[RWX]_OK
Garrett Cooper yaneg...@gmail.com added the comment:
.
--
Added file: http://bugs.python.org/file17414/config.log
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8746
New submission from Garrett Cooper yaneg...@gmail.com:
os.chflags isn't `available' even though chflags support is available on the
system:
filter(lambda x: x.startswith('chflags'), dir(os))
[]
platform.uname()
('FreeBSD', 'bayonetta.local', '9.0-CURRENT', 'FreeBSD 9.0-CURRENT #0 r206173M
New submission from Garrett Cooper yaneg...@gmail.com:
A number of features are being blindly enabled on python that aren't correct
from a porting standpoint; a handful in configure.in I noticed are:
# The later defininition of _XOPEN_SOURCE disables certain features
# on Linux, so we need
New submission from Garrett Cooper yaneg...@gmail.com:
When attempting to install and deinstall lang/python26 to run some unit tests
for a change I was going to provide to the maintainer, I ran into this issue:
install -o root -g wheel -m 444 ./../Include/ucnhash.h
/usr/local/include
Changes by Garrett Cooper yaneg...@gmail.com:
Added file: http://bugs.python.org/file16467/all.log
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8079
Changes by Garrett Cooper yaneg...@gmail.com:
Added file: http://bugs.python.org/file16468/clean.log
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue8079
Garrett Cooper yaneg...@gmail.com added the comment:
On Sun, Nov 1, 2009 at 5:50 AM, Mike Frysinger rep...@bugs.python.org wrote:
Mike Frysinger vap...@users.sourceforge.net added the comment:
AC_TRY_RUN is already documented:
http://www.gnu.org/software/autoconf/manual/html_node/Obsolete
Garrett Cooper yaneg...@gmail.com added the comment:
Ok. Taking a look at trunk...
The following could be converted to AC_TRY_COMPILE statements for the
3rd AC_TRY_RUN tuple:
1. $ac_enable_profiling : 697
2. $ac_cv_no_strict_aliasing_ok : 921
3. $ac_cv_opt_olimit_ok : 1070
4. $ac_cv_olimit_ok
Garrett Cooper yaneg...@gmail.com added the comment:
I'm trying to resolve this issue on:
2.6-releasemaint
trunk
3.1-releasemaint
py3k
first by resolving issues configure.in, but there are a TON of
AC_TRY_RUN's, which means that this code cannot be cross-compiled as-is
(25 on 2.x -- 27 on 3.x
Garrett Cooper yaneg...@gmail.com added the comment:
__linux is legitimate too, so the patch looks ok, but...
1) It won't apply cleanly against 2.4.5, most likely.
2) Why __linux instead of __linux__ ?
gcoo...@orangebox ~ $ echo | gcc --std=c89 -E -dM -c - | grep linux
#define __linux 1
New submission from Garrett Cooper yaneg...@gmail.com:
The following files are looking for the `linux' constant, when it fact
they should be looking for `__linux__' (from 2.6.2 release's sources):
Modules/_ctypes/libffi/src/mips/ffitarget.h:#ifdef linux
Modules/socketmodule.c:#ifdef linux
Garrett Cooper yaneg...@gmail.com added the comment:
Coming back to this issue, I really want to resolve it on TRUNK and for
it to make its way into 2.6.3 and 2.x trunk, as well as 3.0.2 and 3.x
trunk. I am more than happy to sign a contributor agreement if this will
push things along quicker
Garrett Cooper yaneg...@gmail.com added the comment:
Maybe the documentation for other examples should be referenced then?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5850
Garrett Cooper yaneg...@gmail.com added the comment:
Cool! Thanks for all of the hard work Michael :D.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5679
Garrett Cooper yaneg...@gmail.com added the comment:
Priorities shifted again at work, so I'll get around to this some time
around early June when I get an opportunity to implement multiprocessing
in my work code...
Thanks!
--
___
Python tracker rep
New submission from Garrett Cooper yaneg...@gmail.com:
This is just an example that I want to offer to the community to help
improve overall documentation in the handbook.
I've attached the example file, but it's also available on my journal
post with example output: http
Garrett Cooper yaneg...@gmail.com added the comment:
BTW, the documentation item that this should be attached to is:
http://docs.python.org/reference/datamodel.html#emulating-container-types
--
___
Python tracker rep...@bugs.python.org
http
New submission from Garrett Cooper yaneg...@gmail.com:
A handful of valid bugs were reported with pylint when I was backporting
unittest.py r71263 to 2.4/2.5 from HEAD. The attached diff fixes them.
--
components: Extension Modules, Tests
files: unittest-sa_fix-r71263.diff
keywords
New submission from Garrett Cooper yaneg...@gmail.com:
A handful of valid bugs were reported with pylint when I was backporting
unittest.py r71263 to 2.4/2.5 from HEAD for
http://code.google.com/p/python-unittest-backport. The attached diff
fixes them.
--
components: Extension Modules
Garrett Cooper yaneg...@gmail.com added the comment:
Ugh... The `...@staticmethod fix' was invalid.
--
Added file: http://bugs.python.org/file13702/unittest-sa_fix-r71263.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5771
Changes by Garrett Cooper yaneg...@gmail.com:
Removed file: http://bugs.python.org/file13701/unittest-sa_fix-r71263.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5771
New submission from Garrett Cooper yaneg...@gmail.com:
In the API for connections.Client, it says:
multiprocessing.connection.Client(address[, family[, authenticate[,
authkey]]])
In the final paragraph is says:
`If authentication is True or authkey '
As per the API provided it should
Garrett Cooper yaneg...@gmail.com added the comment:
I did some quick inspection and it appears to be tied purely into
setuptools, not distutils. distutils does support the environment
variables properly.
So I take this item and submit it to PEAK I suppose? Fun times .
Thanks for the help
New submission from Garrett Cooper yaneg...@gmail.com:
I'm not sure why but my copy doesn't have a managers module. I'm really
confused because multiprocessing.managers exists in
Lib/multiprocessing/managers.py and it should have been installed with
easy_install...
Please see the attached
Garrett Cooper yaneg...@gmail.com added the comment:
Sorry -- the info for my python2.6 was out of date. Here's the info (I
had to set PYTHONPATH to to avoid a multiprocessing module conflict):
bash-3.00$ PYTHONPATH=; python2.6 `which nosetests`
~/test_managers_support.py
Python version:
2.6.1
New submission from Garrett Cooper yaneg...@gmail.com:
The example under multiprocessing.managers.BaseManager.connect has 2 typos:
from multiprocessing.managers import BaseManager
m = BaseManager(address='127.0.0.1', authkey='abc))
m.connect()
Here's a corrected example
Garrett Cooper yaneg...@gmail.com added the comment:
Thanks for noting that George Y. and thanks for fixing the documentation
on SVN Benjamin :).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5744
New submission from Garrett Cooper yaneg...@gmail.com:
The last example on the multiprocessing documentation page is clearly
wrong. It references a lot of renamed / deprecated API's from processing
that are no longer in multiprocessing.
I'll try and come up with a comparable working example
Garrett Cooper yaneg...@gmail.com added the comment:
How about this? I'll do both :).
I'm avoiding sync + semaphore stuff because it's still non-portable
(Issue 3770 fun), even though I have a functioning copy of FreeBSD...
but I do have a Mac, VMware fusion, etc, and I'll toss in a working
Garrett Cooper yaneg...@gmail.com added the comment:
I think some perspective is required on this enhancement request. I
originally filed this issue -- http://bugs.python.org/issue5538 --
because of the unneeded complexity involved with duplicating
teardown-related code in setUp because
Garrett Cooper yaneg...@gmail.com added the comment:
I see the validity in the concern raised by Virgil:
I think this can be simplified from a user perspective by saying `I'm
electing to use cleanUp over tearDown'. The two systems are similar, but
also very different semantically as tearDown
New submission from Garrett Cooper yaneg...@gmail.com:
I realize that cross-compilation isn't supported yet, _but_ setuptools
needs to be modified such that standard compilation variables are
supported, e.g. CC, CFLAGS, CPPFLAGS, LD, LDFLAGS, LDLIBS.
The -i, -l, and -L flags with setup.py
Garrett Cooper yaneg...@gmail.com added the comment:
As an FYI, I'm going to push this off until next week or the week after
because I have more pressing things to take care of and have an OK
workaround for this issue.
--
___
Python tracker rep
Garrett Cooper yaneg...@gmail.com added the comment:
I agree with you guys to a certain extent, but doing so only complicates
my setup procedure to the extent that I'm calling a lot of my teardown
code in a dumb manner, unless I actually kept track of how far into the
setup process I got before
Garrett Cooper yaneg...@gmail.com added the comment:
And maybe the addCleanup components could be a stack of callable objects?
This would make life easier for folks like me and would make the overall
flow much cleaner / clearer as it would allow us to break things down
into atomic steps which
Garrett Cooper yaneg...@gmail.com added the comment:
Ok, sounds good then ;). I'll open another issue with the enhancement
later on this week.
Cheers!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5538
Garrett Cooper yaneg...@gmail.com added the comment:
Before I forget though -- should the requirements for the functionality
be that it be called strictly in setUp on failure, or should it be
executed as a part of tearDown as well?
Thanks
Garrett Cooper yaneg...@gmail.com added the comment:
Excellent point Kumar.
Here's what I'm trying to accomplish...
I'm a part of a team that's testing out IOSd on an up and coming Unix
foundation platform. This requires starting up a series of services,
ensuring that they have come up
Garrett Cooper yaneg...@gmail.com added the comment:
Unfortunately we're still stuck on 2.4.5 because I don't have enough
buy-in from tech leads and architects to upgrade right now -_-... Good
idea though :] *stores for later*.
--
___
Python tracker
New submission from Garrett Cooper yaneg...@gmail.com:
While trying to deal with some annoying issues with setting up and
tearing down consoles via pexpect, I noticed that the teardown functions
/ methods weren't being executed via nose.
After applying this change to 2.4.5 and 2.6.1, things
Changes by Garrett Cooper yaneg...@gmail.com:
--
type: - behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5538
___
___
Python-bugs-list
1 - 100 of 115 matches
Mail list logo
