Michael Foord added the comment:
I'm not seeing the same issue on my Macbook Pro. I can get all this info from
my desktop machine (Mac Pro) when I return from PyCon.
--
___
Python tracker
<http://bugs.python.org/i
New submission from Michael Newman :
Attached is a version checking script. When you run it normally, it produces
output such as:
E:\notes\Programming\python3>c:\Python26\python.exe version_check.py
2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]
E:\notes\Programm
Michael Foord added the comment:
There are several standard library modules that deliberately maintain
compatibility with earlier versions of Python. The 'with' statement shouldn't
be used for tests of any modules that still need compatibility with Python 2.4.
--
nosy:
Michael Newman added the comment:
I noticed the same behavior today.
Let's consider a test case using my python script "version_check.py" (attached).
Normally the script does the following on my Ubuntu 9.10 box:
# Python 2.6 example:
m...@ebx2009:~/test$ which python
/u
Michael Newman added the comment:
Perhaps this is now really a "bug":
# Response to e-mail to "webmas...@python.org":
#
This is the mail system at host mail.python.org.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipi
Michael Newman added the comment:
I posted the copyright note, and the reply bot bug on the wiki at:
http://wiki.python.org/moin/SiteImprovements
--
___
Python tracker
<http://bugs.python.org/issue7
Changes by Michael Foord :
--
nosy: -michael.foord
___
Python tracker
<http://bugs.python.org/issue7900>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Michael Newman :
In the second example given in "27.8.1. Traceback Examples" at:
http://docs.python.org/3.1/library/traceback.html
http://docs.python.org/py3k/library/traceback.html
which has the lumberjack:
The last line won't work in Python 3.1
Michael Foord added the comment:
This is similar to an issue I reported to the security team (same underlying
issue). My concern was that with an admin installed version of Python an
arbitrary user can modify site.py, or create sitecustomize.py, and cause
arbitrary code execution when the
New submission from Michael Foord :
Originally reported as a bug against unittest2:
http://code.google.com/p/unittest-ext/issues/detail?id=3
There are some assert* methods that don't have their assertNot*
counterparts. There's assertDictEqual, assertSequenceEqual,
assertRegexpMatch
Michael Foord added the comment:
Should there be a 'discussion' stage for the tracker?
This isn't *really* at the 'test needed' stage, I'm not 100% convinced we
should add all these extra methods just 'for the sake of completeness' - but if
Michael Foord added the comment:
I've tried installations of Python to Program Files in recent years (Python 2.4
and 2.5) and found many scripts/tools unable to cope with the space in the
path. I always ended up reinstalling. (Usually using sys.executable in
conjunction with calling o
Michael Foord added the comment:
So is it reasonable / unavoidable that UCS4 builds should be 1200 times slower
at regex handling?
--
___
Python tracker
<http://bugs.python.org/issue8
Michael Foord added the comment:
Interestingly, the code olivers is using was originally written by Martin v.
Loewis:
http://www.velocityreviews.com/forums/t646421-unicode-regex-and-hindi-language.html
In response to a still open bug report on \w in the Python re module:
http
Michael Foord added the comment:
Fixed revision 78770.
--
resolution: -> accepted
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
Changes by Michael Foord :
--
title: Not all the new assert* unittest.TestCase methods have negative (not)
equivalents -> Provide unittest.TestCase.assertNotRegexpMatches
___
Python tracker
<http://bugs.python.org/iss
Michael Foord added the comment:
I like the feature. I'm a bit concerned about the proliferation of command line
options for unittest though.
Steve's rejection of the feature seemed to be on the basis that he didn't need
it (or se
Michael Droettboom added the comment:
Does the reassignment only apply to the more recent more ambitious patch? The
original patch (and my forward porting of it) is purely a bugfix, not a feature
freeze. This is a showstopper bug for matplotlib on Solaris, for example, and
I would hate to
Changes by Michael Foord :
--
nosy: -michael.foord
___
Python tracker
<http://bugs.python.org/issue8110>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Newman added the comment:
No problem. Please note its actually fixed in r78895 (trunk), r78896 (py3k) and
r78897 (release31-maint). Your previous message had the svn revision numbers
off by 1000.
--
___
Python tracker
<h
Changes by Michael Foord :
--
nosy: -michael.foord
___
Python tracker
<http://bugs.python.org/issue7643>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Michael Foord :
On Mac OS X 10.6.2
==
ERROR: test_realpath (__main__.MacCommonTest)
--
Traceback (most recent call last):
File "/co
New submission from Michael Foord :
I'm *assuming* this is a Mac OS X issue. (10.6.2)
./python.exe Lib/test/test_pep277.py
test_directory (__main__.UnicodeFileTests) ... ok
test_failures (__main__.UnicodeFileTests) ... ok
test_listdir (__main__.UnicodeFileTests) ... FAIL
test_open (__m
Changes by Michael Foord :
--
stage: -> needs patch
versions: +Python 2.7
___
Python tracker
<http://bugs.python.org/issue8180>
___
___
Python-bugs-list mai
Michael Foord added the comment:
Committed in revision 79132.
For Python 2.7 I renamed assertSameElements to assertItemsEqual
(assertSameElements has never been released on 2.X). In 3.2 assertItemsEqual
will be new and assertSameElements will be de-documented / deprecated
New submission from Michael Foord :
$ ./python.exe Lib/test/test_imp.py
test_find_module_encoding (__main__.ImportTests) ... ok
test_issue1267 (__main__.ImportTests) ... ok
test_issue3594 (__main__.ImportTests) ... ok
test_issue5604 (__main__.ImportTests) ... ERROR
test_builtin (__main__
Michael Foord added the comment:
Committed to Py3k in revision 79141, revision 79142 and revision 79143.
--
resolution: -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
___
Python tracker
<http://bug
Michael Foord added the comment:
Test passes for me with the patch applied.
--
___
Python tracker
<http://bugs.python.org/issue8179>
___
___
Python-bugs-list m
Michael Foord added the comment:
The test passes with the first patch applied (darwin.diff). With the second
patch applied I get two failures:
==
ERROR: test_normalize (__main__.UnicodeFileTests
Michael Foord added the comment:
Fixed as part of #7832.
--
resolution: accepted -> fixed
stage: patch review -> committed/rejected
status: pending -> closed
___
Python tracker
<http://bugs.python.o
Michael Foord added the comment:
Committed revision 79263. As external modules are already using __unittest it
would be backwards incompatible not to restore the functionality.
--
resolution: -> fixed
stage: needs patch -> committed/rejected
status: open -&g
Michael Foord added the comment:
Failfast option added, committed revision 79265. Still needs documentation.
Ctrl-C handling not yet done. Slightly more complex as it needs to play well
with tests that test SIGINT handling.
--
resolution: -> accep
New submission from Michael Foord :
When you execute "python -m package" the package is first imported with
sys.argv[0] set to '-c' (and sys.modules['__main__'] exists but is empty. Then
package.__main__.py is executed with the correct sys.argv[0].
This means mod
Michael Foord added the comment:
I've already fixed my specific usecase (for unittest), but a special value in
sys.argv[0] would indeed have met my needs.
--
___
Python tracker
<http://bugs.python.org/i
Michael Foord added the comment:
'-c' isn't helpful because that is also the content of sys.argv[0] when a
module is imported in response to "python -c '...'".
--
___
Python tracker
Michael Foord added the comment:
It would be really useful to be able to send signal.SIGINT to processes on
Windows using os.kill(...). The patch as described sounds like it would have a
different signature to the standard implementation of os.kill(...) which takes
a pid and a signal type
Changes by Michael Foord :
--
versions: +Python 2.7, Python 3.2 -Python 2.6
___
Python tracker
<http://bugs.python.org/issue1220212>
___
___
Python-bugs-list m
Michael Foord added the comment:
I'm wrong. First IronPython tries:
NativeSignal.GenerateConsoleCtrlEvent(PythonSignal.CTRL_C_EVENT, ...)
But with the comment:
//The following calls to GenerateConsoleCtrlEvent will fail under
//most circumstances. We'll try them any ways though as
Michael Foord added the comment:
Aaaand the IronPython implementation of
NativeSignal.GenerateConsoleCtrlEvent(PythonSignal.CTRL_C_EVENT, ...)
delegates to Kernel32.GenerateConsoleCtrlEvent.
--
___
Python tracker
<http://bugs.python.
Michael Foord added the comment:
To make it clear, even though it would be incomplete, a partial implementation
of os.kill(...) for Windows would be very useful and provide some level of
compatibility with applications that use os.kill (so even if os.kill(...)
duplicates functionality in
Michael Foord added the comment:
To make it clear, even though it would be incomplete, a partial implementation
of os.kill(...) for Windows would be very useful and provide some level of
compatibility with applications that use os.kill (so even if os.kill(...)
duplicates functionality in
Changes by Michael Foord :
--
___
Python tracker
<http://bugs.python.org/issue1220212>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/m
Changes by Michael Foord :
--
nosy: +brian.curtin
___
Python tracker
<http://bugs.python.org/issue1220212>
___
___
Python-bugs-list mailing list
Unsubscribe:
Michael Foord added the comment:
Ctrl-C handling now implemented (-c command line option). Still needs
documentation, but there is a bunch of this outstanding and I will do it in one
go and rework the unittest docs at the same time.
--
stage: needs patch -> committed/rejected
sta
Michael Foord added the comment:
Hmm... well my particular use case is that it should work with the value
returned by os.getpid(). If that is a process handle then it is nice and
convenient to just use process handles. The docs don't specify so I bet it
returns a pid. :-(
However
Michael Foord added the comment:
I have a consistently failing test on my machine. If the answer is indeed
"won't fix" and both os.getgroups() and os.setgroups() are not expected to work
correctly on Mac OS X then the tests should be disabled for that platform.
New submission from Michael Foord :
WeakRefSet would be a useful addition to the weakref module. I needed this for
unittest recently but made do with a WeakRefKeyDictionary and setting the
values to 1.
--
components: Library (Lib)
messages: 101859
nosy: michael.foord
severity: normal
Michael Foord added the comment:
Ha. I tried 2.7. I guess it would be nice if it was backported.
--
versions: -Python 3.2
___
Python tracker
<http://bugs.python.org/issue8
Changes by Michael Foord :
--
resolution: -> invalid
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue8251>
___
___
Python-bugs-list
Michael Foord added the comment:
I wonder if unittest.test.test_break runs and the signals.SIGINT it sends
terminates a process early? Do you have access to this platform to try it
Florent?
--
___
Python tracker
<http://bugs.python.org/issue8
Michael Foord added the comment:
That sounds very useful from a diagnostic point of view. If it does turn out to
be the problem then we will have to disable the test for that platform. At the
moment test_break runs on all platforms that have os.kill
Michael Foord added the comment:
Hmmm... I'm not sure moving everything as is is a good idea. Any parts in
particular you want?
--
___
Python tracker
<http://bugs.python.org/i
Michael Foord added the comment:
Not all the APIs are appropriate though, for example TestFailed and TestSkipped
are not needed. Some of the APIs only make sense for the test_support runner
and unittest has its own runner now.
I think the proposal needs to be more specific about which APIs
Michael Foord added the comment:
So which parts, can you list the ones you think are most important?
At the moment we don't have to maintain backwards compatibility with
test.test_support as it isn't a 'public' API - so the cost in adding it to the
standard library is th
Michael Foord added the comment:
Right - that is exactly why I want a specific proposal as to which APIs are
generally useful and should be considered for moving into unittest.
--
___
Python tracker
<http://bugs.python.org/issue8
Michael Foord added the comment:
Sorry, missed David's comment:
> Maybe we could move the appropriate stuff and get rid of the
> test_support doc page altogether. And when we move stuff to unittest
> maybe we could take the opportunity to clean up any warts in the
> interfac
Michael Foord added the comment:
A 'support' sub-module in unittest is ok. I wonder if it is the best name?
- is_jython
This is too specific and ignores the other implementations. This information is
also available from sys / platform modules.
-1
- TESTFN
This is a global for s
Michael Foord added the comment:
Something like this was discussed at the language summit. Now we have the skip
decorators it is easy to skip tests on certain platforms or only run them on
certain platforms.
The cpython_only decorator is fine - but I'd prefer a general solution rather
Michael Foord added the comment:
Looks good to me.
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue8193>
___
___
Python-bugs-list mailin
Michael Foord added the comment:
I think namespacing utility functions / classes inside unittest is fine (even
good), but agree that there needs to be careful thinking about APIs that are
made public in this way. To a certain extent this code has already proved its
utility, but up until now
Michael Foord added the comment:
Isn't there an issue around having multiple versions of Python installed? The
top level folder should only be removed if the version of Python being
uninstalled is the last installed Python. This means executing code on
uninstall and doesn't seem
Michael Foord added the comment:
After discussion with Brian it seems like it should be possible for
os.kill(...) on Windows to support both pids *and* process handles. This seems
ideal.
--
___
Python tracker
<http://bugs.python.org/issue1220
Michael Foord added the comment:
According to earlier discussion in this issue os.spawn() return process handles
on Windows.
--
___
Python tracker
<http://bugs.python.org/issue1220
Michael Foord added the comment:
Committed revision 79632.
--
___
Python tracker
<http://bugs.python.org/issue8038>
___
___
Python-bugs-list mailing list
Unsub
Michael Foord added the comment:
Further commit revision 79643. Needs tests and documentation.
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/iss
Changes by Michael Foord :
--
___
Python tracker
<http://bugs.python.org/issue8038>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/m
Michael Foord added the comment:
Committed revision 79643. Needs test and documentation.
--
resolution: -> accepted
___
Python tracker
<http://bugs.python.org/iss
New submission from Michael Foord :
Putting functions (rather than TestCase instances) directly in TestSuites was
never officially supported but it used to work:
>>> from unittest import TestSuite, TestResult
>>> def f(): pass
...
>>> s = TestSuite()
>>&g
New submission from Michael Foord :
SkipTest exception in setUpClass or setUpModule is marked as an error rather
than a skip.
--
assignee: michael.foord
messages: 102260
nosy: michael.foord
severity: normal
stage: needs patch
status: open
title: SkipTest exception in setUpClass or
New submission from Michael Foord :
The usage messages for unittest from the command line are slightly incorrect.
They show: "Usage: unittest [options]" when it should be "Usage: python -m
unittest [options]" (or even "python -m unittest discover").
--
as
Michael Foord added the comment:
In TestProgram.usageExit the command name comes from:
self.progName = os.path.basename(argv[0])
For test discovery the usage message is auto-generated by optparse. Probably
using sys.argv[0].
--
___
Python
New submission from Michael Foord :
>>> import unittest
>>> class Foo(unittest.TestCase):
... def test_fffd(self): self.assertEqual(u'\ufffd', u'\ufffd\ufffd')
...
>>> unittest.main(exit=False)
F
=
Michael Foord added the comment:
Should default to test discovery if no arguments are supplied.
Valid arguments: "testrunner", "tests" or "testsuite".
Default testrunner is unittest of course. "tests" / "testsuite" to be of the
form: &
Michael Haubenwallner added the comment:
This very same problem happens (with Python-2.6.2) on AIX5.3 now too, after
upgrading to:
$ oslevel -s
5300-08-09-1013
Unlike before (comparing with old build logs), this AIX5.3 now provides flock()
in and libbsd.a[shr.o] like AIX6.1.
Interesting
Michael Haubenwallner added the comment:
Ohw, looking on another machine, being AIX5.3 TL6:
$ oslevel -s
5300-06-00-
Here flock() is provided in libbsd.a(shr.o) (32bit only) too, but it isn't
declared in any header-file. So that recent AIX5.3 patchset just adds the
flock() declar
Michael Foord added the comment:
I expect the unittest tests will fail with that patch applied however... No
problem with switching to just using StringIO in unittest though - preferably
with a comment as to why.
--
___
Python tracker
<h
New submission from Michael Glassford :
An unfortunate side-effect of this change:
http://svn.python.org/view/python/branches/release26-maint/Lib/urlparse.py?r1=66717&r2=78235
which was made to fix this issue:
http://bugs.python.org/issue7904
is that urlparse.urlunparse(urlparse.urlp
Michael Foord added the comment:
TestResult creates its StringIO buffers even if they aren't use. I can create
them on first use and use StringIO.StringIO rather than cStringIO. Will fix now.
--
___
Python tracker
<http://bugs.python.org/i
Michael Foord added the comment:
Although merely switching to StringIO may not be enough. TestResult objects
keep a reference to sys.stdout when they are instantiated and you can't pickle
that either.
It is preferable for the reference to be taken at instantiation time rather
than stor
Michael Foord added the comment:
Changing unittest.TestResult to use StringIO instead of cStringIO isn't
sufficient. regrtest.py also needs to use StringIO...
--
___
Python tracker
<http://bugs.python.org/i
Michael Foord added the comment:
I believe this issue to now be fixed on trunk. We can close this when the
buildbots are passing again.
--
___
Python tracker
<http://bugs.python.org/issue8
Michael Foord added the comment:
Green build on Windows XP, trunk.
http://www.python.org/dev/buildbot/all/builders/x86%20XP-5%20trunk/builds/282
--
resolution: -> accepted
stage: needs patch -> committed/rejected
status: open -> closed
_
Michael Glassford added the comment:
It caused a minor issue with the Schemes extension for Mercurial: the output
changed, which caused a unit test to fail. I'm pretty sure I have a Mercurial
patch to fix that issue, however.
--
___
Python tr
Changes by Michael Foord :
--
assignee: -> michael.foord
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue8351>
___
___
Python-bugs-lis
Michael Foord added the comment:
If we provide builtin support for parameterized tests it will have to report
each test separately otherwise there is no point. You can already add support
for running tests with multiple parameters yourself - the *only* advantage of
building support into
Michael Glassford added the comment:
> In those cases, I would assume that 'x://y', x:/y','x:/','/'
> as valid URLS, but not the two examples you mentioned.
Only 2 comments about this:
1) Although the urlparse documentation does mention the relevant R
Changes by Michael Foord :
--
assignee: cjerdonek -> michael.foord
___
Python tracker
<http://bugs.python.org/issue7559>
___
___
Python-bugs-list mai
Michael Foord added the comment:
That change would be backwards incompatible with existing scripts calling
main(...) programattically though.
--
___
Python tracker
<http://bugs.python.org/issue8
Michael Foord added the comment:
I'm sure that there are many places using the API as it is, inserting a dummy
entry into the argv they pass. Although the fix you propose would solve the
problem for users who are currently using the API wrongly it would break code
for people who are usi
Changes by Michael Foord :
--
stage: unit test needed -> patch review
___
Python tracker
<http://bugs.python.org/issue2521>
___
___
Python-bugs-list mai
New submission from Michael Foord :
When test discovery is invoked on a package on the filesystem which is also
installed in site-packages then importing the tests will look in the installed
version. This causes discovery to run the wrong tests or fail.
We can detect this (compare the
Michael Foord added the comment:
Looks like a good addition to the documentation to me.
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue8
Michael Foord added the comment:
Sounds like the right approach then. :-)
--
___
Python tracker
<http://bugs.python.org/issue8547>
___
___
Python-bugs-list mailin
Michael Foord added the comment:
I still see this failure on Python 3 trunk with Mac OS X 10.6.
--
nosy: +michael.foord
___
Python tracker
<http://bugs.python.org/issue4
New submission from Michael Foord :
I get the following failure running test_imp on py3k, Mac OS X 10.6.3.
==
ERROR: test_package___file__ (__main__.PEP3147Tests
New submission from Michael Foord :
I get the following failures with test_import on Mac OS X 10.6.3:
==
ERROR: test_import (test.test_import.ImportTests
Michael Foord added the comment:
This is likely related to issue 8586 - the actual failure is very similar (a
bad path in support.py).
--
___
Python tracker
<http://bugs.python.org/issue8
Michael Foord added the comment:
I see similar failures (failing to unlink weird paths from support.py) in:
test_imp.py, test_import.py, test_pydoc.py, test_runpy.py,
--
___
Python tracker
<http://bugs.python.org/issue8
Michael Foord added the comment:
So I'm assuming issue 8587 (same failure in test_import.py) is a duplicate of
this. I'll close 8587.
--
___
Python tracker
<http://bugs.python.
Michael Foord added the comment:
Assuming this is actually the same problem as issue 8586.
--
resolution: -> duplicate
stage: -> committed/rejected
status: open -> closed
___
Python tracker
<http://bugs.python.o
501 - 600 of 3015 matches
Mail list logo
