[Python-Dev] Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
Hi Barry, Friendly poke to see if there's been any progress on acquiring the relevant certificates such that we can code sign binaries on Windows for 2.6/3.0 ;-) Trent. ___ 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] Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
Trent Nelson schrieb: > Hi Barry, > > Friendly poke to see if there's been any progress on acquiring the relevant > certificates such that we can code sign binaries on Windows for 2.6/3.0 ;-) Can you explain: * Why the binaries should be signed? * What is required to sign the binaries? * Which binaries should be signed? Christian ___ 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] Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
> * Why the binaries should be signed? Makes the installation process on Windows Vista and Server 2008 a little nicer; instead of getting an "unknown-executable-could- be-a-virus-aa-watchout"-type dialog with a big red flag, you get a less threatening message saying that you're about to run something that's been digitally signed by the Python Software Foundation. (I've come across a few entities (NSA, government bodies, etc), who mandate that all installers/binaries they get must be digitally signed.) > * What is required to sign the binaries? 1. Obtain a code signing certificate from someone. I used VeriSign. You end up with an .spc and a .pvk file. You need to combine them into a single .pfx file via a tool called pvk2pfx.exe: Usage: pvk2pfx -pvk [-pi ] -spc [-pfx [-po ] [-f]] -pvk - input PVK file name. -spc - input SPC file name. -pfx - output PFX file name. -pi- PVK password. -po- PFX password; same as -pi if not given. -f - force overwrite existing PFX file. if -pfx option is not given, an export wizard will pop up. in this case, options -po and -f are ignored. C:\..> pvk2pfx.exe -pvk verisign-privatekey.pvk -pi ** -spc onresolve-verisign.spc -po ** -pfx onresolve-verisign.pfx 3. The resulting .pfx file, onresolve-verisign.pfx in this case, can then be installed as a 'Personal' certificate in Windows, using the Certificate Management facility (CertMgr.exe). When you install it, you provide a name that the certificate can be referred to by apps; in my case I just used 'VeriSign'. This name is used below by the signtool.exe app. 4. Sign the executable, MSI or DLL as follows: C:\..> signtool.exe sign /i "VeriSign" /d "Python 2.6.0" /du http://www.python.org /t http://timestamp.verisign.com/scripts/timstamp.dll Python-2.6.msi Successfully signed and timestamped: Python-2.6.msi > * Which binaries should be signed? Personally, once I figured out the steps above, I hooked the signing process into all my Visual Studio projects as a post-build step, such that I sign all .exe and .dll files. Not really necessary, but eh, it does have the advantage of looking more professional (users can view properties on the .dll, for example, and see that it's been digitally signed by the PSF). Additionally, it prevents any tampering; Windows can detect if it's been altered in any way since it's been signed, and will flat out prevent it from being loaded/run if that's the case. Trent. ___ 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] Global Python Sprint Weekends: May 10th-11th and June 21st-22nd.
On Wed, Apr 16, 2008 at 8:40 PM, Michael Foord <[EMAIL PROTECTED]> wrote: > Trent Nelson wrote: > > Following on from the success of previous sprint/bugfix weekends and > > sprinting efforts at PyCon 2008, I'd like to propose the next two > > Global Python Sprint Weekends take place on the following dates: > > > > * May 10th-11th (four days after 2.6a3 and 3.0a5 are released) > > * June 21st-22nd (~week before 2.6b2 and 3.0b2 are released) > > > > It seems there are a few of the Python User Groups keen on meeting > > up in person and sprinting collaboratively, akin to PyCon, which I > > highly recommend. I'd like to nominate Saturday across the board > > as the day for PUGs to meet up in person, with Sunday geared more > > towards an online collaboration day via IRC, where we can take care > > of all the little things that got in our way of coding on Saturday > > (like finalising/preparing/reviewing patches, updating tracker and > > documentation, writing tests ;-). > > > > For User Groups that are planning on meeting up to collaborate, > > please reply to this thread on [email protected] and let every- > > one know your intentions! > > > > > > I should be able to help organise and attend the London contribution. > Personally I'd like to work on the documentation changes / clean-up for > the unittest module discussed recently. We are trying to set up a team here in Paris, Personnally I would like to continue the work started in distutils (various patches) and some friends here are interested in contributing on documentation. Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/ ___ 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] string representation of range in 3.0
On Tue, Apr 15, 2008, Guido van Rossum wrote: > On Tue, Apr 15, 2008 at 8:34 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: >> Guido van Rossum wrote: >>> >>> That's why I proposed <0, 1, ..., 9> for repr(range(10)). >> >> My worry is that this will lead a newcomer into thinking >> this is some kind of valid expression syntax. > > You and Steven D'Aprano both. > > So if this is indeed a bad idea, I'm stumped -- the 3.0 status quo is > the best we can do, and teachers will just have to teach their > students to write list(range(10)) if they want to see what it means. > Or they can write an explicit for-loop (always useful on the first > day): > > for i in range(10): > print i No, they can't. ;-) (print is a function in 3.0) This may seem like a minor nit -- and it is, in some ways -- but I think reminding people of the pedagogical issues involved in the transition is important. Granted, this is python-dev, so we should be using 2.x syntax, but we're currently talking about 3.0 and that requires clarifying what is meant/intended. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan ___ 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] Proposed unittest changes
Hello all,
I'm starting to put together a list of cleanups (with documentation
changes) for the unittest module. I thought someone had already done
this but the issue with the most comments I could find was 2578 which
doesn't go into much detail:
http://bugs.python.org/issue2578
The thing most people would like is test discovery - but that probably
requires some discussion before anything can be added to unittest.
What I would like to do is PEP-8'ify the method names (widening the API
rather than shrinking it!):
assert_true
assert_false
assert_equals
assert_not_equals
assert_raises
set_up
tear_down
failure_exception (? - class attribute)
TestSuite.add_test
(etc)
Documenting that these are to be preferred to 'assertEquals' and
'failUnlessEquals' (etc) and that the 'assert' statement should be used
instead of 'assert_'.
Adding the following new asserts:
assert_in(member, container, msg=None)
assert_not_in (member, container, msg=None)
assert_is (first, second, msg=None)
assert_not_is (first, second, msg=None)
assert_raises_with_message(exc_class, message, callable, *args,
**keywargs)
A decorator to turn a test function into a TestCase ("as_test_case" ?).
A simple 'RunTests' function that takes a collection of modules, test
suites or test cases and runs them with TextTestRunner - passing on
keyword arguments to the test runner. This makes running a test suite
easier - once you have collected all your test cases together you can
just pass them to this function so long as you are happy with the
default runner (possibly allowing an alternative runner class to be
provided as a keyword argument).
I would provide an implementation for discussion of course.
I would also like to make the error messages for "assert_equals" and
"assert_not_equals" more useful - showing the objects that compare
incorrectly even if an explicit message is passed in. Additionally, when
comparing lists and tuples that are the same length show the members
(and indices?) that were different.
I've copied Steve Purcell into this email, but his comments on issue
2578 indicate that he is happy for 'us' to make changes and he no longer
has a string sense of "ownership" of this module.
Michael Foord
___
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] Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
This is going to be a major administrative hassle. Obviously you have to be extremely cautious with the private part of the certificate, or it's worthless. That means that there will probably be only one person who can sign binaries. That person would have also have to build all the binaries -- signing binaries you retrieved from the internet sounds like a complete bypassing of the security procedures. *And* that person would forever have to be extremely cautious with the machine on which the certificate resides, keeping it turned off and locked away securely most of the time, or else risk that the machine is infected by malware, again bypassing the point. While the chances of ever signing something bad are low, the bad effects could be huge (sort of like the risk of an earthquake as compared to a car crash). I'm not at all sure that we are set up to do this right, and that it is worth the minor inconvenience to users of having to acknowledge a red-flag dialog. After all, they will be ack'ing such dialogs all the time if they are at all used to downloading software from the internet. --Guido On Thu, Apr 17, 2008 at 4:56 AM, Trent Nelson <[EMAIL PROTECTED]> wrote: > > > * Why the binaries should be signed? > > Makes the installation process on Windows Vista and Server 2008 > a little nicer; instead of getting an "unknown-executable-could- > be-a-virus-aa-watchout"-type dialog with a big red flag, > you get a less threatening message saying that you're about to > run something that's been digitally signed by the Python Software > Foundation. (I've come across a few entities (NSA, government > bodies, etc), who mandate that all installers/binaries they get > must be digitally signed.) > > > > * What is required to sign the binaries? > > 1. Obtain a code signing certificate from someone. I used VeriSign. > You end up with an .spc and a .pvk file. You need to combine them > into a single .pfx file via a tool called pvk2pfx.exe: > > Usage: > pvk2pfx -pvk [-pi ] -spc >[-pfx [-po ] [-f]] > > -pvk - input PVK file name. > -spc - input SPC file name. > -pfx - output PFX file name. > -pi- PVK password. > -po- PFX password; same as -pi if not given. > -f - force overwrite existing PFX file. > > if -pfx option is not given, an export wizard will pop up. in > this case, options -po and -f are ignored. > > C:\..> pvk2pfx.exe -pvk verisign-privatekey.pvk -pi ** -spc > onresolve-verisign.spc -po ** -pfx onresolve-verisign.pfx > > 3. The resulting .pfx file, onresolve-verisign.pfx in this case, can > then be installed as a 'Personal' certificate in Windows, using the > Certificate Management facility (CertMgr.exe). When you install it, > you provide a name that the certificate can be referred to by apps; > in my case I just used 'VeriSign'. This name is used below by the > signtool.exe app. > > 4. Sign the executable, MSI or DLL as follows: > > C:\..> signtool.exe sign /i "VeriSign" /d "Python 2.6.0" /du > http://www.python.org /t http://timestamp.verisign.com/scripts/timstamp.dll > Python-2.6.msi > Successfully signed and timestamped: Python-2.6.msi > > > > * Which binaries should be signed? > > Personally, once I figured out the steps above, I hooked the signing > process into all my Visual Studio projects as a post-build step, such > that I sign all .exe and .dll files. Not really necessary, but eh, > it does have the advantage of looking more professional (users can > view properties on the .dll, for example, and see that it's been > digitally signed by the PSF). Additionally, it prevents any tampering; > Windows can detect if it's been altered in any way since it's been > signed, and will flat out prevent it from being loaded/run if that's > the case. > > > Trent. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Proposed unittest changes
I'm worried that a mass renaming would do anything but inconvenience
users during the already stressful 2->3 transition.
I'm more in favor of the original proposal of reducing the redundancy post-3.0.
If you're looking for useful features, Google has a set of extensions
to unittest.py that I find useful:
- module-level setUp and tearDown
- routines for comparing large lists and strings that produce useful
output indicating exactly where the inputs differ.
- assertLess etc.
- assertSameElements (sort of like assert(set(x) == set(y))
--Guido
On Thu, Apr 17, 2008 at 6:49 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Hello all,
>
> I'm starting to put together a list of cleanups (with documentation
> changes) for the unittest module. I thought someone had already done
> this but the issue with the most comments I could find was 2578 which
> doesn't go into much detail:
>
> http://bugs.python.org/issue2578
>
> The thing most people would like is test discovery - but that probably
> requires some discussion before anything can be added to unittest.
>
> What I would like to do is PEP-8'ify the method names (widening the API
> rather than shrinking it!):
>
> assert_true
> assert_false
> assert_equals
> assert_not_equals
> assert_raises
> set_up
> tear_down
> failure_exception (? - class attribute)
> TestSuite.add_test
>
> (etc)
>
> Documenting that these are to be preferred to 'assertEquals' and
> 'failUnlessEquals' (etc) and that the 'assert' statement should be used
> instead of 'assert_'.
>
> Adding the following new asserts:
>
> assert_in(member, container, msg=None)
> assert_not_in (member, container, msg=None)
> assert_is (first, second, msg=None)
> assert_not_is (first, second, msg=None)
> assert_raises_with_message(exc_class, message, callable, *args,
> **keywargs)
>
> A decorator to turn a test function into a TestCase ("as_test_case" ?).
>
> A simple 'RunTests' function that takes a collection of modules, test
> suites or test cases and runs them with TextTestRunner - passing on
> keyword arguments to the test runner. This makes running a test suite
> easier - once you have collected all your test cases together you can
> just pass them to this function so long as you are happy with the
> default runner (possibly allowing an alternative runner class to be
> provided as a keyword argument).
>
> I would provide an implementation for discussion of course.
>
> I would also like to make the error messages for "assert_equals" and
> "assert_not_equals" more useful - showing the objects that compare
> incorrectly even if an explicit message is passed in. Additionally, when
> comparing lists and tuples that are the same length show the members
> (and indices?) that were different.
>
> I've copied Steve Purcell into this email, but his comments on issue
> 2578 indicate that he is happy for 'us' to make changes and he no longer
> has a string sense of "ownership" of this module.
>
> Michael Foord
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 17, 2008, at 10:48 AM, Guido van Rossum wrote: > This is going to be a major administrative hassle. Obviously you have > to be extremely cautious with the private part of the certificate, or > it's worthless. That means that there will probably be only one person > who can sign binaries. That person would have also have to build all > the binaries -- signing binaries you retrieved from the internet > sounds like a complete bypassing of the security procedures. *And* > that person would forever have to be extremely cautious with the > machine on which the certificate resides, keeping it turned off and > locked away securely most of the time, or else risk that the machine > is infected by malware, again bypassing the point. While the chances > of ever signing something bad are low, the bad effects could be huge > (sort of like the risk of an earthquake as compared to a car crash). > > I'm not at all sure that we are set up to do this right, and that it > is worth the minor inconvenience to users of having to acknowledge a > red-flag dialog. After all, they will be ack'ing such dialogs all the > time if they are at all used to downloading software from the > internet. MvL is leading this effort and is currently trying to get a code signing certificate (my attempts having utterly failed on the Mac ;). Please coordinate with him. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSAdnMHEjvBPtnXfVAQKkhQP/frCWs9sLcWyrAmDouCIq0n2X0B0TUbbG +tEUQVBj2hJ/CVnmc6PjyFNjOhlfhIv+BI544QhsvoAlC2OdQe9d8hHX8sqnPUJy lsm0gZ49ldqOhM91Q285RPtoELEEXQtfTYS2RUI/whNy+O/EDiRMVIDtNfaJOMgS j6zeojy8d4E= =m4aj -END PGP SIGNATURE- ___ 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] Proposed unittest changes
Guido van Rossum wrote:
> I'm worried that a mass renaming would do anything but inconvenience
> users during the already stressful 2->3 transition.
>
> I'm more in favor of the original proposal of reducing the redundancy
> post-3.0.
>
>
So nix the PEP-8'ifying until after 3.0.
So new methods should follow the current naming scheme (assertIn,
assertNotIn etc).
> If you're looking for useful features, Google has a set of extensions
> to unittest.py that I find useful:
>
> - module-level setUp and tearDown
>
So when a suite is made from a module the setUp should be called before
the first test and tearDown after the last. I can look at that.
> - routines for comparing large lists and strings that produce useful
> output indicating exactly where the inputs differ.
>
> - assertLess etc.
>
By etc I assume you mean:
assertLessThan
assertGreaterThan
assertLessThanOrEquals
assertGreaterThanOrEquals
Would not variants be useful as well - it seems not as the not of one is
always another... (I think 'assertLessThan' reads better than
'assertLess' but will do what I'm told...)
> - assertSameElements (sort of like assert(set(x) == set(y))
>
Sounds good.
Did you look at the other proposals?
* Decorator to make a function a TestCase
* Convenience RunTests functions taking modules, suites and TestCases
and running them
* Improved messages for assertEquals and assertNotEquals when an
explicit message is passed in
* Improved message when comparing lists/tuples with assertEquals
* The additional asserts that I suggested (In/NotIn, RaisesWithMessage,
Is/NotIs)
I think that there is still work I can do on the docs even before any
grand renaming...
Michael Foord
> --Guido
>
> On Thu, Apr 17, 2008 at 6:49 AM, Michael Foord
> <[EMAIL PROTECTED]> wrote:
>
>> Hello all,
>>
>> I'm starting to put together a list of cleanups (with documentation
>> changes) for the unittest module. I thought someone had already done
>> this but the issue with the most comments I could find was 2578 which
>> doesn't go into much detail:
>>
>> http://bugs.python.org/issue2578
>>
>> The thing most people would like is test discovery - but that probably
>> requires some discussion before anything can be added to unittest.
>>
>> What I would like to do is PEP-8'ify the method names (widening the API
>> rather than shrinking it!):
>>
>> assert_true
>> assert_false
>> assert_equals
>> assert_not_equals
>> assert_raises
>> set_up
>> tear_down
>> failure_exception (? - class attribute)
>> TestSuite.add_test
>>
>> (etc)
>>
>> Documenting that these are to be preferred to 'assertEquals' and
>> 'failUnlessEquals' (etc) and that the 'assert' statement should be used
>> instead of 'assert_'.
>>
>> Adding the following new asserts:
>>
>> assert_in(member, container, msg=None)
>> assert_not_in (member, container, msg=None)
>> assert_is (first, second, msg=None)
>> assert_not_is (first, second, msg=None)
>> assert_raises_with_message(exc_class, message, callable, *args,
>> **keywargs)
>>
>> A decorator to turn a test function into a TestCase ("as_test_case" ?).
>>
>> A simple 'RunTests' function that takes a collection of modules, test
>> suites or test cases and runs them with TextTestRunner - passing on
>> keyword arguments to the test runner. This makes running a test suite
>> easier - once you have collected all your test cases together you can
>> just pass them to this function so long as you are happy with the
>> default runner (possibly allowing an alternative runner class to be
>> provided as a keyword argument).
>>
>> I would provide an implementation for discussion of course.
>>
>> I would also like to make the error messages for "assert_equals" and
>> "assert_not_equals" more useful - showing the objects that compare
>> incorrectly even if an explicit message is passed in. Additionally, when
>> comparing lists and tuples that are the same length show the members
>> (and indices?) that were different.
>>
>> I've copied Steve Purcell into this email, but his comments on issue
>> 2578 indicate that he is happy for 'us' to make changes and he no longer
>> has a string sense of "ownership" of this module.
>>
>> Michael Foord
>> ___
>> Python-Dev mailing list
>> [email protected]
>> http://mail.python.org/mailman/listinfo/python-dev
>> Unsubscribe:
>> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>>
>>
>
>
>
>
___
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] Proposed unittest changes
On Thu, Apr 17, 2008 at 10:59 AM, Michael Foord
<[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I'm worried that a mass renaming would do anything but inconvenience
> > users during the already stressful 2->3 transition.
> >
> > I'm more in favor of the original proposal of reducing the redundancy
> post-3.0.
> >
> >
>
> So nix the PEP-8'ifying until after 3.0.
>
> So new methods should follow the current naming scheme (assertIn,
> assertNotIn etc).
>
>
> > If you're looking for useful features, Google has a set of extensions
> > to unittest.py that I find useful:
> >
> > - module-level setUp and tearDown
> >
> So when a suite is made from a module the setUp should be called before
> the first test and tearDown after the last. I can look at that.
>
>
> > - routines for comparing large lists and strings that produce useful
> > output indicating exactly where the inputs differ.
> >
> > - assertLess etc.
> >
> By etc I assume you mean:
>
> assertLessThan
> assertGreaterThan
> assertLessThanOrEquals
> assertGreaterThanOrEquals
>
> Would not variants be useful as well - it seems not as the not of one is
> always another... (I think 'assertLessThan' reads better than
> 'assertLess' but will do what I'm told...)
>
>
> > - assertSameElements (sort of like assert(set(x) == set(y))
> >
>
> Sounds good.
>
> Did you look at the other proposals?
>
> * Decorator to make a function a TestCase
> * Convenience RunTests functions taking modules, suites and TestCases
> and running them
> * Improved messages for assertEquals and assertNotEquals when an
>
> explicit message is passed in
> * Improved message when comparing lists/tuples with assertEquals
> * The additional asserts that I suggested (In/NotIn, RaisesWithMessage,
> Is/NotIs)
>
> I think that there is still work I can do on the docs even before any
> grand renaming...
>
> Michael Foord
>
>
>
> > --Guido
> >
> > On Thu, Apr 17, 2008 at 6:49 AM, Michael Foord
> > <[EMAIL PROTECTED]> wrote:
> >
> >> Hello all,
> >>
> >> I'm starting to put together a list of cleanups (with documentation
> >> changes) for the unittest module. I thought someone had already done
> >> this but the issue with the most comments I could find was 2578 which
> >> doesn't go into much detail:
> >>
> >> http://bugs.python.org/issue2578
> >>
> >> The thing most people would like is test discovery - but that probably
> >> requires some discussion before anything can be added to unittest.
> >>
> >> What I would like to do is PEP-8'ify the method names (widening the API
> >> rather than shrinking it!):
> >>
> >> assert_true
> >> assert_false
> >> assert_equals
> >> assert_not_equals
> >> assert_raises
> >> set_up
> >> tear_down
> >> failure_exception (? - class attribute)
> >> TestSuite.add_test
> >>
> >> (etc)
> >>
> >> Documenting that these are to be preferred to 'assertEquals' and
> >> 'failUnlessEquals' (etc) and that the 'assert' statement should be used
> >> instead of 'assert_'.
> >>
> >> Adding the following new asserts:
> >>
> >> assert_in(member, container, msg=None)
> >> assert_not_in (member, container, msg=None)
> >> assert_is (first, second, msg=None)
> >> assert_not_is (first, second, msg=None)
> >> assert_raises_with_message(exc_class, message, callable, *args,
> >> **keywargs)
> >>
> >> A decorator to turn a test function into a TestCase ("as_test_case" ?).
> >>
> >> A simple 'RunTests' function that takes a collection of modules, test
> >> suites or test cases and runs them with TextTestRunner - passing on
> >> keyword arguments to the test runner. This makes running a test suite
> >> easier - once you have collected all your test cases together you can
> >> just pass them to this function so long as you are happy with the
> >> default runner (possibly allowing an alternative runner class to be
> >> provided as a keyword argument).
> >>
> >> I would provide an implementation for discussion of course.
> >>
> >> I would also like to make the error messages for "assert_equals" and
> >> "assert_not_equals" more useful - showing the objects that compare
> >> incorrectly even if an explicit message is passed in. Additionally, when
> >> comparing lists and tuples that are the same length show the members
> >> (and indices?) that were different.
> >>
> >> I've copied Steve Purcell into this email, but his comments on issue
> >> 2578 indicate that he is happy for 'us' to make changes and he no longer
> >> has a string sense of "ownership" of this module.
> >>
> >> Michael Foord
+1 on your changes Michael - I really like the decorator idea. Let me
know if you want help on adding the new stuff or updating the
documentation. What about aiming this at 2.6 instead of 3.0?
-jesse
___
Python-Dev mailing list
Python-D
Re: [Python-Dev] Proposed unittest changes
Michael Foord schrieb:
> By etc I assume you mean:
>
> assertLessThan
> assertGreaterThan
> assertLessThanOrEquals
> assertGreaterThanOrEquals
>
> Would not variants be useful as well - it seems not as the not of one is
> always another... (I think 'assertLessThan' reads better than
> 'assertLess' but will do what I'm told...)
Most of the etc. could be simplified with a function assertOp which
takes an operator as first argument
import operator
def assertOp(self, op, a, b, msg):
func = getattr(operator, op)
self.assert_(func(a, b) ...)
assertOp("gt", a, b) == assert a > g
I also like to have some assert for is, type, isinstance, issubclass and
contains.
Christian
___
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] Proposed unittest changes
Great that you're taking this on, Michael! On 17 Apr 2008, at 16:59, Michael Foord wrote: >> If you're looking for useful features, Google has a set of extensions >> to unittest.py that I find useful: >> >> - module-level setUp and tearDown >> > So when a suite is made from a module the setUp should be called > before the first test and tearDown after the last. I can look at that. Note that suites are just clumps of tests, and test runners can choose to run tests in any order, which might complicate the above. In any case, I'd advise against per-module setUp/tearDown because it breaks the fundamental rule that any instance of TestCase can be safely run in isolation, secure in the knowledge that it will set itself up and tear itself down as required. There are usually (always?) superior alternatives to module-level setUp, so I wouldn't suggest encouraging it by providing a sanctioned mechanism. Also, I'd note that assert_() or similar may still be needed: it is provided as a preferred alternative to the assert() built-in because the latter stops working if you run Python with the -O switch, which might be a reasonable thing to do with a test suite. Aside from these points, everything else looks great to me. Better "diff-style" output for assertEquals of strings etc. has been lacking for ages, as well as collection-oriented assertions. -Steve P.S. Hi all! ___ 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] Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
Barry Warsaw schrieb: > MvL is leading this effort and is currently trying to get a code > signing certificate (my attempts having utterly failed on the Mac ;). > Please coordinate with him. Apropos certificate, I like to suggest a PGP signing party for the next PyCon. :] Christian ___ 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] Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Apr 17, 2008, at 11:32 AM, Christian Heimes wrote: > Barry Warsaw schrieb: >> MvL is leading this effort and is currently trying to get a code >> signing certificate (my attempts having utterly failed on the Mac ;). >> Please coordinate with him. > > Apropos certificate, I like to suggest a PGP signing party for the > next > PyCon. :] /me smacks his head for not doing one in 2008! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.8 (Darwin) iQCVAwUBSAdzS3EjvBPtnXfVAQJEygP/SNB+nQ+XfEnOprAji9pGj5YcmJJSoKb3 A8UFR3LAI3EK3CVzgIXEeFuQOKZV34p0nTabVM9FEzsPrIbvnbzp1k4V4Go1bK/G iBktzoG8F/VCmdbF7OjwBLb7O5GVVK1MRIO1KvdHp00lW311VYYMYdRuZ150lsct doLzOH7kriU= =LCTo -END PGP SIGNATURE- ___ 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] Proposed unittest changes
Christian Heimes wrote:
> Michael Foord schrieb:
>
>> By etc I assume you mean:
>>
>> assertLessThan
>> assertGreaterThan
>> assertLessThanOrEquals
>> assertGreaterThanOrEquals
>>
>> Would not variants be useful as well - it seems not as the not of one is
>> always another... (I think 'assertLessThan' reads better than
>> 'assertLess' but will do what I'm told...)
>>
>
> Most of the etc. could be simplified with a function assertOp which
> takes an operator as first argument
>
> import operator
> def assertOp(self, op, a, b, msg):
> func = getattr(operator, op)
> self.assert_(func(a, b) ...)
>
> assertOp("gt", a, b) == assert a > g
>
>
Which choice would be up to consensus.
I'm agnostic on this one.
> I also like to have some assert for is, type, isinstance, issubclass and
> contains.
>
>
is and contains ('in') I listed. type, isinstance, issubclass would be
extra.
Michael
> Christian
>
___
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] Proposed unittest changes
Jesse Noller wrote: > On Thu, Apr 17, 2008 at 10:59 AM, Michael Foord > <[EMAIL PROTECTED]> wrote: > >> Guido van Rossum wrote: >> > I'm worried that a mass renaming would do anything but inconvenience >> > users during the already stressful 2->3 transition. >> > >> > I'm more in favor of the original proposal of reducing the redundancy >> post-3.0. >> > >> > >> >> So nix the PEP-8'ifying until after 3.0. >> >> So new methods should follow the current naming scheme (assertIn, >> assertNotIn etc). >> >> [snip...] >> >> > > +1 on your changes Michael - I really like the decorator idea. Let me > know if you want help on adding the new stuff or updating the > documentation. What about aiming this at 2.6 instead of 3.0? > > -jesse > As they will just be new features rather than API changes I would like to add these to 2.6 - although I think May 10th may be after the last alpha? Michael ___ 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] Proposed unittest changes
Michael Foord wrote: > Guido van Rossum wrote: >> I'm worried that a mass renaming would do anything but inconvenience >> users during the already stressful 2->3 transition. >> >> I'm more in favor of the original proposal of reducing the redundancy >> post-3.0. >> >> > > So nix the PEP-8'ifying until after 3.0. > > So new methods should follow the current naming scheme (assertIn, > assertNotIn etc). > >> If you're looking for useful features, Google has a set of extensions >> to unittest.py that I find useful: >> >> - module-level setUp and tearDown >> > So when a suite is made from a module the setUp should be called before > the first test and tearDown after the last. I can look at that. > >> - routines for comparing large lists and strings that produce useful >> output indicating exactly where the inputs differ. >> >> - assertLess etc. >> > By etc I assume you mean: > > assertLessThan > assertGreaterThan > assertLessThanOrEquals > assertGreaterThanOrEquals > > Would not variants be useful as well - it seems not as the not of one is > always another... (I think 'assertLessThan' reads better than > 'assertLess' but will do what I'm told...) > >> - assertSameElements (sort of like assert(set(x) == set(y)) >> > > Sounds good. > > Did you look at the other proposals? > > * Decorator to make a function a TestCase > * Convenience RunTests functions taking modules, suites and TestCases > and running them > * Improved messages for assertEquals and assertNotEquals when an > explicit message is passed in > * Improved message when comparing lists/tuples with assertEquals > * The additional asserts that I suggested (In/NotIn, RaisesWithMessage, > Is/NotIs) > > I think that there is still work I can do on the docs even before any > grand renaming... Something I found useful to improve messages is to have the tests catch and then report errors with it's own unique exceptions to indicate the failures. What that does is make a very clear distinction between an error found in a module being tested vs test case. An error in the test case results in a regular python exception and a trace back of the test case. An error in the module being tested results in an specific unittest exception indicating what type of error was found in the module followed by the original exception and traceback from the module being tested. Ron class TestCase(unittest.TestCase): failureException = unittest.TestCase.failureException class Unexpected_Exception_Raised(failureException): def __init__(self, exc, ref): self.exc = exc self.ref = ref def __str__(self): return '\n'.join([repr(self.exc), '\nReference:', self.ref]) class Wrong_Exception_Raised(Unexpected_Exception_Raised): pass class No_Exception_Raised(failureException): def __init__(self, result, ref=""): self.result = repr(result) self.ref = ref def __str__(self): return "returned -> " + '\n'.join([self.result, '\nReference:', self.ref]) class Wrong_Result_Returned(No_Exception_Raised): def __str__(self): return '\n'.join([self.result, '\nReference:', self.ref]) def assertTestReturns(self, test, expect, ref=""): try: result = test() except Exception, e: e0, e1, e2 = sys.exc_info() raise self.Unexpected_Exception_Raised, (e, ref), e2 if result != expect: raise self.Wrong_Result_Returned(result, ref) def assertTestRaises(self, test, expect, ref=""): try: result = test() except Exception, e: if isinstance(e, expect): return e else: e0, e1, e2 = sys.exc_info() raise self.Wrong_Exception_Raised, (e, ref), e2 raise self.No_Exception_Raised(result, ref) ___ 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] A smarter shutil.copytree ?
Hi,
shutil.copytree is very convenient to make recursive copies, but
os.walk has to be used everytime some filtering
has to be done on the files copied., if you want to avoid copying some files.
The code pattern with os.walk is pretty talkative :
- copying a source folder to a target folder, but
the pyc/pyo files
os.mkdir(target)
for root, dirs, filenames in os.walk(source):
root_target = root.replace(source, target)
for dir_ in dirs:
target_dir = join(root_target, dir_)
if os.path.exists(target_dir):
continue
os.mkdir(target_dir)
for filename in filenames:
filename_source = join(root, filename)
filename_target = join(root_target, filename)
if (os.path.exists(filename_target) or
os.path.splitext(filename) in ('.pyc', '.pyo')):
continue
shutil.copyfile(filename_source, filename_target)
If we could provide a callable argument to shutil.copytree, this would
allow simplifying a lot the code:
- copying a source to a target, but the pyc/pyo file
def filtering(source, target):
return os.path.splitext(filename) not in ('.pyc', '.pyo')
shutil.copytree(source, target, filter_=filtering)
-
This is a very current pattern in my code, and I think this could be
an interesting enhancement to
shutil. So if people think it is a good idea, I can work on a patch
and submit it to the tracker.
Regards
Tarek
--
Tarek Ziadé | Association AfPy | www.afpy.org
Blog FR | http://programmation-python.org
Blog EN | http://tarekziade.wordpress.com/
___
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] Code signing of Windows .msi/.dll/.exe's for 2.6/3.0
>> Apropos certificate, I like to suggest a PGP signing party for the >> next PyCon. :] Barry> /me smacks his head for not doing one in 2008! Maybe a bunch of Python local user groups could be coaxed into having mini-signing parties during upcoming meetings, then let natural cross-fertilization between groups (such as Fitz visiting Google Mountain View or a few US folk attending EuroPython (mid-July), EuroSciPy (late July) or PyCon UK (September)) connect those groups. It wouldn't be as convenient as one big key signing party, but probably as effective in the long run. Skip ___ 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] Proposed unittest changes
On Thu, Apr 17, 2008 at 7:59 AM, Michael Foord <[EMAIL PROTECTED]> wrote: > By etc I assume you mean: > >assertLessThan >assertGreaterThan >assertLessThanOrEquals >assertGreaterThanOrEquals These names are used here: assertListEqual(self, list1, list2, msg=None): assertIn(self, a, b, msg=None): assertNotIn(self, a, b, msg=None): assertDictEqual(self, d1, d2, msg=None): assertSameElements(self, expected_seq, actual_seq, msg=None): assertMultiLineEqual(self, first, second, msg=None): assertLess(self, a, b, msg=None): assertLessEqual(self, a, b, msg=None): assertGreater(self, a, b, msg=None): assertGreaterEqual(self, a, b, msg=None): assertCommandSucceeds(self, command): assertCommandFails(self, command, regexes): I can look into making those open source, but it'd probably more efficient use of everyone's time to just reimplement them; most are only a few lines. You can skip the assertCommand* ones, they're for testing shell commands. > Did you look at the other proposals? Not yet. > * Decorator to make a function a TestCase But what about TOOWTDI? > * Convenience RunTests functions taking modules, suites and TestCases and > running them If it addresses the most common reason why people have to hack this stuff, by all means. > * Improved messages for assertEquals and assertNotEquals when an explicit > message is passed in Sure. > * Improved message when comparing lists/tuples with assertEquals I'd say do that in assertListEqual > * The additional asserts that I suggested (In/NotIn, RaisesWithMessage, > Is/NotIs) Sure. Google has In/NotIn > I think that there is still work I can do on the docs even before any grand > renaming... Go ahead! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] A smarter shutil.copytree ?
> - copying a source to a target, but the pyc/pyo file
> def filtering(source, target):
> return os.path.splitext(filename) not in ('.pyc', '.pyo')
>
> shutil.copytree(source, target, filter_=filtering)
> -
oups, made a mistake in my example:
def filtering(source_path, target_path):
return os.path.splitext(source_path) not in ('.pyc', '.pyo')
shutil.copytree(source, target, filter_=filtering)
___
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] Proposed unittest changes
On Thu, Apr 17, 2008 at 8:27 AM, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Most of the etc. could be simplified with a function assertOp which
> takes an operator as first argument
>
> import operator
> def assertOp(self, op, a, b, msg):
> func = getattr(operator, op)
> self.assert_(func(a, b) ...)
>
> assertOp("gt", a, b) == assert a > g
-1 on this; it requires more thinking and has more opportunities for
mistakes (e.g. why "gt" and not ">"?).
> I also like to have some assert for is, type, isinstance, issubclass and
> contains.
Yes. Michael had In/NotIn. I have needed all of the others too at various times!
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] A smarter shutil.copytree ?
Sounds like a neat little feature. Looking forward to it. Maybe the
most useful use case would be to provide glob-style patterns for
skipping files or directories (and their contents).
--Guido
On Thu, Apr 17, 2008 at 9:52 AM, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
> Hi,
>
> shutil.copytree is very convenient to make recursive copies, but
> os.walk has to be used everytime some filtering
> has to be done on the files copied., if you want to avoid copying some files.
>
> The code pattern with os.walk is pretty talkative :
>
> - copying a source folder to a target folder, but
> the pyc/pyo files
> os.mkdir(target)
> for root, dirs, filenames in os.walk(source):
> root_target = root.replace(source, target)
> for dir_ in dirs:
> target_dir = join(root_target, dir_)
> if os.path.exists(target_dir):
> continue
> os.mkdir(target_dir)
> for filename in filenames:
> filename_source = join(root, filename)
> filename_target = join(root_target, filename)
> if (os.path.exists(filename_target) or
> os.path.splitext(filename) in ('.pyc', '.pyo')):
> continue
> shutil.copyfile(filename_source, filename_target)
>
>
> If we could provide a callable argument to shutil.copytree, this would
> allow simplifying a lot the code:
>
> - copying a source to a target, but the pyc/pyo file
> def filtering(source, target):
> return os.path.splitext(filename) not in ('.pyc', '.pyo')
>
> shutil.copytree(source, target, filter_=filtering)
> -
>
> This is a very current pattern in my code, and I think this could be
> an interesting enhancement to
> shutil. So if people think it is a good idea, I can work on a patch
> and submit it to the tracker.
>
> Regards
>
> Tarek
>
> --
> Tarek Ziadé | Association AfPy | www.afpy.org
> Blog FR | http://programmation-python.org
> Blog EN | http://tarekziade.wordpress.com/
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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] A smarter shutil.copytree ?
On 17/04/2008, Tarek Ziadé <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> shutil.copytree is very convenient to make recursive copies, but
> os.walk has to be used everytime some filtering
> has to be done on the files copied., if you want to avoid copying some
> files.
>
> The code pattern with os.walk is pretty talkative :
>
> - copying a source folder to a target folder, but
> the pyc/pyo files
> os.mkdir(target)
> for root, dirs, filenames in os.walk(source):
> root_target = root.replace(source, target)
> for dir_ in dirs:
> target_dir = join(root_target, dir_)
> if os.path.exists(target_dir):
> continue
> os.mkdir(target_dir)
> for filename in filenames:
> filename_source = join(root, filename)
> filename_target = join(root_target, filename)
> if (os.path.exists(filename_target) or
> os.path.splitext(filename) in ('.pyc', '.pyo')):
> continue
> shutil.copyfile(filename_source, filename_target)
>
>
> If we could provide a callable argument to shutil.copytree, this would
> allow simplifying a lot the code:
>
> - copying a source to a target, but the pyc/pyo file
> def filtering(source, target):
> return os.path.splitext(filename) not in ('.pyc', '.pyo')
>
> shutil.copytree(source, target, filter_=filtering)
> -
>
> This is a very current pattern in my code, and I think this could be
> an interesting enhancement to
> shutil. So if people think it is a good idea, I can work on a patch
> and submit it to the tracker.
I also think this is a good idea; I recently was forced to copy-paste and
modify shutil.copytree into a project because of this limitation.
Regards
>
> Tarek
>
> --
>
> Tarek Ziadé | Association AfPy | www.afpy.org
> Blog FR | http://programmation-python.org
> Blog EN | http://tarekziade.wordpress.com/
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/gjcarneiro%40gmail.com
>
--
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert
___
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] Proposed unittest changes
"Michael Foord" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] | I think that there is still work I can do on the docs even before any | grand renaming... In a related thread, I proposed and Guido approved that the 2.6/3.0 docs be changed to 1. specify that the Fail... names will disappear in the future 2. list the preferred Assert names first for each pair 3. use the preferred Assert names and only those names in the explanatory text and examples. Have you or are you going to make these changes or should I open a separate tracker issue? Terry ___ 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] Proposed unittest changes
-On [20080417 19:46], Terry Reedy ([EMAIL PROTECTED]) wrote: >Have you or are you going to make these changes or should I open a separate >tracker issue? You can always put it on my account in the tracker (asmodai) and I'll get to it in the coming days. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ The administration of justice is the firmest pillar of government... ___ 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] A smarter shutil.copytree ?
On Thu, Apr 17, 2008 at 7:06 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > Sounds like a neat little feature. Looking forward to it. Maybe the > most useful use case would be to provide glob-style patterns for > skipping files or directories (and their contents). Alright I will work on it that way, thanks for the advice Tarek ___ 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] Proposed unittest changes
On Fri, Apr 18, 2008 at 12:54 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm worried that a mass renaming would do anything but inconvenience > users during the already stressful 2->3 transition. > > I'm more in favor of the original proposal of reducing the redundancy > post-3.0. > > If you're looking for useful features, Google has a set of extensions > to unittest.py that I find useful: > > - module-level setUp and tearDown > > - routines for comparing large lists and strings that produce useful > output indicating exactly where the inputs differ. > > - assertLess etc. > > - assertSameElements (sort of like assert(set(x) == set(y)) > Hi, Some things that Bazaar, Twisted and Launchpad have found helpful: - assertRaises returning the exception object that it catches. This allows for easy testing of exception strings. - Assertion methods for 'in', 'is' and 'isinstance' and their negations. - TestCase.addCleanup. This method takes a function, args and kwargs and pushes them to a stack of cleanups. Before tearDown is run, each of these cleanups is popped off the stack and then run. This makes it easier to acquire certain resources in tests: e.g def make_temp_dir(self): dir = tempfile.mkdtemp() self.addCleanup(shutil.rmtree, dir) return dir Luckily, I have patches (with tests!) for these that I will be filing on the tracker as soon as I get the opportunity. jml ___ 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] Proposed unittest changes
On Thu, Apr 17, 2008 at 11:49 PM, Michael Foord <[EMAIL PROTECTED]> wrote: > assert_raises_with_message(exc_class, message, callable, *args, > **keywargs) > I don't think this one should go in. I think it would be better if assertRaises just returned the exception object that it catches. That way, you can test properties of the exception other than its message. jml ___ 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] Proposed unittest changes
On Thu, Apr 17, 2008 at 3:31 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote: > On Thu, Apr 17, 2008 at 11:49 PM, Michael Foord > <[EMAIL PROTECTED]> wrote: > > assert_raises_with_message(exc_class, message, callable, *args, > > **keywargs) > > > > I don't think this one should go in. > > I think it would be better if assertRaises just returned the exception > object that it catches. That way, you can test properties of the > exception other than its message. Hm. I've got to say that returning the exception object is, um, an odd API in the set of unittest APIs. I can see how it's sometimes more powerful, but I'd say that in many cases assertRaisesWithMessage will be easier to write and read. (And making it a regex match would be even cooler.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] Proposed unittest changes
On Fri, Apr 18, 2008 at 8:34 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 17, 2008 at 3:31 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote: > > On Thu, Apr 17, 2008 at 11:49 PM, Michael Foord > > <[EMAIL PROTECTED]> wrote: > > > assert_raises_with_message(exc_class, message, callable, *args, > > > **keywargs) > > > > > > > I don't think this one should go in. > > > > I think it would be better if assertRaises just returned the exception > > object that it catches. That way, you can test properties of the > > exception other than its message. > > Hm. I've got to say that returning the exception object is, um, an odd > API in the set of unittest APIs. I can see how it's sometimes more > powerful, but I'd say that in many cases assertRaisesWithMessage will > be easier to write and read. (And making it a regex match would be > even cooler.) I don't know about odd. It works and it's not obviously terrible. Not having it the unittest API simply means that people who do want to test non-message properties will rewrite assertRaises. Which is, in fact, what we've already done. jml ___ 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] Proposed unittest changes
Guido van Rossum wrote: > On Thu, Apr 17, 2008 at 3:31 PM, Jonathan Lange <[EMAIL PROTECTED]> wrote: >> On Thu, Apr 17, 2008 at 11:49 PM, Michael Foord >> <[EMAIL PROTECTED]> wrote: >> > assert_raises_with_message(exc_class, message, callable, *args, >> > **keywargs) >> > >> >> I don't think this one should go in. >> >> I think it would be better if assertRaises just returned the exception >> object that it catches. That way, you can test properties of the >> exception other than its message. > > Hm. I've got to say that returning the exception object is, um, an odd > API in the set of unittest APIs. I can see how it's sometimes more > powerful, but I'd say that in many cases assertRaisesWithMessage will > be easier to write and read. (And making it a regex match would be > even cooler.) > In which case assertRaisesMatching (and then eventually assert_raises_matching) might be a better name for it? regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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] Proposed unittest changes
Terry Reedy wrote: > "Michael Foord" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > | I think that there is still work I can do on the docs even before any > | grand renaming... > > In a related thread, I proposed and Guido approved that the 2.6/3.0 docs > be changed to > 1. specify that the Fail... names will disappear in the future > 2. list the preferred Assert names first for each pair > 3. use the preferred Assert names and only those names in the explanatory > text and examples. > > Have you or are you going to make these changes or should I open a separate > tracker issue? > > Yep - these were the doc changes I mentioned. I haven't started them but will unless someone beats me to it. :-) Michael > Terry > > > > ___ > 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 > ___ 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] Global Python Sprint Weekends: May 10th-11th and June 21st-22nd.
Anybody in Melbourne keen for this? Not sure if I'll be able to make it myself, but I'd be interested to know if there's anybody in the area keen to do the sprint. Cheers, T Tarek Ziadé wrote: > On Wed, Apr 16, 2008 at 8:40 PM, Michael Foord > <[EMAIL PROTECTED]> wrote: > >> Trent Nelson wrote: >> > Following on from the success of previous sprint/bugfix weekends and >> > sprinting efforts at PyCon 2008, I'd like to propose the next two >> > Global Python Sprint Weekends take place on the following dates: >> > >> > * May 10th-11th (four days after 2.6a3 and 3.0a5 are released) >> > * June 21st-22nd (~week before 2.6b2 and 3.0b2 are released) >> > >> > It seems there are a few of the Python User Groups keen on meeting >> > up in person and sprinting collaboratively, akin to PyCon, which I >> > highly recommend. I'd like to nominate Saturday across the board >> > as the day for PUGs to meet up in person, with Sunday geared more >> > towards an online collaboration day via IRC, where we can take care >> > of all the little things that got in our way of coding on Saturday >> > (like finalising/preparing/reviewing patches, updating tracker and >> > documentation, writing tests ;-). >> > >> > For User Groups that are planning on meeting up to collaborate, >> > please reply to this thread on [email protected] and let every- >> > one know your intentions! >> > >> > >> >> I should be able to help organise and attend the London contribution. >> Personally I'd like to work on the documentation changes / clean-up for >> the unittest module discussed recently. >> > > We are trying to set up a team here in Paris, > > Personnally I would like to continue the work started in distutils > (various patches) > and some friends here are interested in contributing on documentation. > > Tarek > > ___ 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] Interface to change Py3kWarning in Python
I currently have a patch to make it possible to change py3k warnings in Python through new functions in sys: issue 2458. I realize the functions are rather ugly, but I don't think there is another practical way to do it unless you want to be writing PySys_GetObject and checking it for NULL whenever you add a Py3k warning. -- Cheers, Benjamin Peterson ___ 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] Global Python Sprint Weekends: May 10th-11th and June 21st-22nd.
On Wed, Apr 16 2008 at 02:51:53PM BRT, Trent Nelson <[EMAIL PROTECTED]> wrote: > > Following on from the success of previous sprint/bugfix weekends and > sprinting efforts at PyCon 2008, I'd like to propose the next two > Global Python Sprint Weekends take place on the following dates: > > * May 10th-11th (four days after 2.6a3 and 3.0a5 are released) > * June 21st-22nd (~week before 2.6b2 and 3.0b2 are released) > > It seems there are a few of the Python User Groups keen on meeting > up in person and sprinting collaboratively, akin to PyCon, which I > highly recommend. I'd like to nominate Saturday across the board > as the day for PUGs to meet up in person, with Sunday geared more > towards an online collaboration day via IRC, where we can take care > of all the little things that got in our way of coding on Saturday > (like finalising/preparing/reviewing patches, updating tracker and > documentation, writing tests ;-). The Sao Paulo User Group gathered "in person" to participate on the last bug day, everyone enjoyed it and we're looking forward to the next one! I've received strong support for our participation on May 10th/11th so we'll definetly be there. rbp -- Rodrigo Bernardo Pimentel <[EMAIL PROTECTED]> | GPG: <0x0DB14978> ___ 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
