Re: [Python-Dev] cpython (3.2): Fix closes issue12683 - urljoin to work with relative join of svn scheme.
On Wed, 03 Aug 2011 12:47:23 +0200
senthil.kumaran wrote:
>
> diff --git a/Lib/test/test_urlparse.py b/Lib/test/test_urlparse.py
> --- a/Lib/test/test_urlparse.py
> +++ b/Lib/test/test_urlparse.py
> @@ -371,6 +371,8 @@
> self.checkJoin('http:///', '..','http:///')
> self.checkJoin('', 'http://a/b/c/g?y/./x','http://a/b/c/g?y/./x')
> self.checkJoin('', 'http://a/./g', 'http://a/./g')
> +self.checkJoin('svn://pathtorepo/dir1', 'dir2',
> 'svn://pathtorepo/dir2')
> +self.checkJoin('svn://pathtorepo/dir1', 'dir2',
> 'svn://pathtorepo/dir2')
This is the same test repeated. Perhaps you meant svn+ssh?
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Fix closes Issue12676 - Invalid identifier used in TypeError message in
On Tue, Aug 02, 2011 at 02:16:01PM +0200, Antoine Pitrou wrote: > There are still a lot of spaces in your message. You should use string Yes, did not realize that.. :( Georg fixed this in his commit. Thanks, Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython (3.2): Fix closes issue12683 - urljoin to work with relative join of svn scheme.
On Wed, Aug 03, 2011 at 03:23:19PM +0200, Antoine Pitrou wrote: > This is the same test repeated. Perhaps you meant svn+ssh? oops, thanks for the catch. yes, I did mean svn+ssh. I shall change it. -- Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] unittest bug
My apologies for posting here first, but I'm not yet confident enough in
my bug searching fu, and duplicates are a pain.
Here's the issue:
from unittest import *
class MyTest(TestCase):
def test_add(self):
self.assertEqual(1,(2-1),"Sample Subraction Test")
if __name__ == '__main__':
main()
I know this isn't the normal way to use unittest, but since __init__
goes to the trouble of defining __all__ I would think it was supported.
However, it doesn't work -- I added some print statements to show
where the problem lies (in unittest.loader.TestLoader.loadTestsFromModule):
--
checking
added
checking
added
checking
checking
added
checking
checking
checking
checking
checking
checking
checking None
checking None
checking 'test_add.py'
checking '__main__'
checking None
checking
checking
checking
checking
checking
checking
checking
checking
checking
checking
checking
checking
checking
test =
tests=[]>,
MyTest testMethod=test_add>]>, ]>
-
compared with running using the `import unittest` method:
-
checking
added
checking
checking None
checking None
checking 'test_add_right.py'
checking '__main__'
checking None
checking
test =
tests=[<__main__.MyTest testMethod=test_add>]>]>
-
As you can see, the TestLoader is getting false positives from
case.FunctionTestCase and case.TestCase. This a problem because,
besides running more tests than it should, this happens:
E.
==
Traceback (most recent call last):
File "test_add.py", line 8, in
main()
File "C:\python32\lib\unittest\main.py", line 125, in __init__
self.runTests()
File "C:\python32\lib\unittest\main.py", line 271, in runTests
self.result = testRunner.run(self.test)
File "C:\python32\lib\unittest\runner.py", line 175, in run
result.printErrors()
File "C:\python32\lib\unittest\runner.py", line 109, in printErrors
self.printErrorList('ERROR', self.errors)
File "C:\python32\lib\unittest\runner.py", line 115, in printErrorList
self.stream.writeln("%s: %s" % (flavour,self.getDescription(test)))
File "C:\python32\lib\unittest\runner.py", line 47, in getDescription
return '\n'.join((str(test), doc_first_line))
File "C:\python32\lib\unittest\case.py", line 1246, in __str__
self._testFunc.__name__)
AttributeError: 'str' object has no attribute '__name__'
I'll be happy to file a bug report if someone can confirm this hasn't
already been filed.
Thanks for the help!
~Ethan~
PS
No, that's not my code. ;)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest bug
On 3 Aug 2011, at 21:36, Ethan Furman wrote:
> My apologies for posting here first, but I'm not yet confident enough in my
> bug searching fu, and duplicates are a pain.
>
> Here's the issue:
>
> from unittest import *
That's the bug right there. Just import TestCase and main and everything should
work fine. Using "import *" is not recommended except at the interactive
interpreter and it doesn't play well with unittest.main which does magic
introspection to find tests to run.
Michael
> class MyTest(TestCase):
>def test_add(self):
>self.assertEqual(1,(2-1),"Sample Subraction Test")
>
>
> if __name__ == '__main__':
>main()
>
> I know this isn't the normal way to use unittest, but since __init__ goes to
> the trouble of defining __all__ I would think it was supported. However, it
> doesn't work -- I added some print statements to show where the problem lies
> (in unittest.loader.TestLoader.loadTestsFromModule):
>
> --
> checking
>added
> checking
>added
> checking
> checking
>added
> checking
> checking
> checking
> checking
> checking
> checking
> checking None
> checking None
> checking 'test_add.py'
> checking '__main__'
> checking None
> checking
> checking
> checking
> checking
> checking
> checking
> checking
> checking
> checking
> checking
> checking
> checking
> checking
>
> test =
> tests=[]>,
> MyTest testMethod=test_add>]>, ]>
> -
>
> compared with running using the `import unittest` method:
> -
> checking
>added
> checking
> checking None
> checking None
> checking 'test_add_right.py'
> checking '__main__'
> checking None
> checking
>
> test =
> tests=[<__main__.MyTest testMethod=test_add>]>]>
> -
>
> As you can see, the TestLoader is getting false positives from
> case.FunctionTestCase and case.TestCase. This a problem because, besides
> running more tests than it should, this happens:
>
> E.
> ==
> Traceback (most recent call last):
> File "test_add.py", line 8, in
>main()
> File "C:\python32\lib\unittest\main.py", line 125, in __init__
>self.runTests()
> File "C:\python32\lib\unittest\main.py", line 271, in runTests
>self.result = testRunner.run(self.test)
> File "C:\python32\lib\unittest\runner.py", line 175, in run
>result.printErrors()
> File "C:\python32\lib\unittest\runner.py", line 109, in printErrors
>self.printErrorList('ERROR', self.errors)
> File "C:\python32\lib\unittest\runner.py", line 115, in printErrorList
>self.stream.writeln("%s: %s" % (flavour,self.getDescription(test)))
> File "C:\python32\lib\unittest\runner.py", line 47, in getDescription
>return '\n'.join((str(test), doc_first_line))
> File "C:\python32\lib\unittest\case.py", line 1246, in __str__
>self._testFunc.__name__)
> AttributeError: 'str' object has no attribute '__name__'
>
> I'll be happy to file a bug report if someone can confirm this hasn't already
> been filed.
>
> Thanks for the help!
>
> ~Ethan~
>
> PS
> No, that's not my code. ;)
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>
--
http://www.voidspace.org.uk/
May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing
http://www.sqlite.org/different.html
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest bug
Michael Foord wrote: On 3 Aug 2011, at 21:36, Ethan Furman wrote: My apologies for posting here first, but I'm not yet confident enough in my bug searching fu, and duplicates are a pain. Here's the issue: from unittest import * That's the bug right there. Just import TestCase and main and everything should work fine. Using "import *" is not recommended except at the interactive interpreter and it doesn't play well with unittest.main which does magic introspection to find tests to run. If from xxx import * is not supported, why provide __all__? At the very least the lack of a warning is a documentation bug. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest bug
On 3 Aug 2011, at 22:58, Ethan Furman wrote: > Michael Foord wrote: >> On 3 Aug 2011, at 21:36, Ethan Furman wrote: >>> My apologies for posting here first, but I'm not yet confident enough in my >>> bug searching fu, and duplicates are a pain. >>> >>> Here's the issue: >>> >>> from unittest import * >> That's the bug right there. Just import TestCase and main and everything >> should work fine. Using "import *" is not recommended except at the >> interactive interpreter and it doesn't play well with unittest.main which >> does magic introspection to find tests to run. > > If from xxx import * is not supported, why provide __all__? a) to define the public API b) to limit the symbols exported - that is not the same as having main(…) work with import *, they're orthogonal > At the very least the lack of a warning is a documentation bug. > Feel free to propose a patch fixing that problem (on the issue tracker please). All the best, Michael Foord > ~Ethan~ > -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] unittest bug
Michael Foord wrote: On 3 Aug 2011, at 22:58, Ethan Furman wrote: Michael Foord wrote: On 3 Aug 2011, at 21:36, Ethan Furman wrote: My apologies for posting here first, but I'm not yet confident enough in my bug searching fu, and duplicates are a pain. Here's the issue: from unittest import * >>> That's the bug right there. Just import TestCase and main and everything should work fine. Using "import *" is not recommended except at the interactive interpreter and it doesn't play well with unittest.main which does magic introspection to find tests to run. >> If from xxx import * is not supported, why provide __all__? a) to define the public API In trying to refute this, I found http://docs.python.org/py3k/reference/simple_stmts.html?highlight=__all__#the-import-statement and learned something new. Thanks, Michael! I think I'll withdraw my bug report, however -- since `from ... import *` is already noted as usually bad practice it should fall on the shoulders of the modules where it is /supposed/ to work to advertise that, and absent any such advertisement it should not be used. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Daily reference leaks (65c412586901): sum=0
Am 04.08.2011 05:25, schrieb [email protected]: > results for 65c412586901 on branch "default" > > > > > Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', > '3:3:/home/antoine/cpython/refleaks/reflogso7nu3', '-x'] Do we need this mail even if there are no leaks to report? Georg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Daily reference leaks (65c412586901): sum=0
On Thu, Aug 4, 2011 at 3:42 PM, Georg Brandl wrote: > Am 04.08.2011 05:25, schrieb [email protected]: >> results for 65c412586901 on branch "default" >> >> >> >> >> Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', >> '3:3:/home/antoine/cpython/refleaks/reflogso7nu3', '-x'] > > Do we need this mail even if there are no leaks to report? I find it useful in order to tell the difference between "no leaks to report" and "refleak checking job is no longer running" Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
