Re: [Python-Dev] PEP 3147: PYC Repository Directories

[Nick Coghlan]

Terry Reedy wrote:
> Definitely. I have even wondered whether it would be possible to cache
> not just the bytecode for initializing a module, but also the
> initialized module itself (perhaps minus the name bindings for other
> imported modules).

Not easily, since running the module may have other side effects that
can't be cached.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[anatoly techtonik]

On Tue, Feb 2, 2010 at 8:08 PM, Barry Warsaw  wrote:
> I'm thinking about doing a Python 2.6.5 release soon.  I've added the
> following dates to the Python release schedule Google calendar:
>
> 2009-03-01 Python 2.6.5 rc 1
> 2009-03-15 Python 2.6.5 final
>
> This allows us to spend some time on 2.6.5 at Pycon if we want.  Please let me
> know if you have any concerns about those dates.

I've noticed a couple of issues that 100% crash Python 2.6.4 like this
one - http://bugs.python.org/issue6608  Is it ok to release new
versions that are known to crash?

-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 385 progress report

[Dirkjan Ochtman]

On Tue, Feb 9, 2010 at 04:47, Benjamin Peterson  wrote:
> I don't believe so. My plan was to manually sync updates or use subrepos.

Using subrepos should work well for this.

It turned out that my local copy of the Subversion repository
contained the Python dir only, so I'm now syncing a full copy so that
I can convert other parts. I believe 2to3 might be a little tricky
because it was moved at some point, but I can look at getting that
right (and this will help in converting other parts of the larger
Python repository).

Cheers,

Dirkjan
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Antoine Pitrou]

Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
> 
> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608  Is it ok to release new versions
> that are known to crash?

I've changed this issue to release blocker. What are the other issues?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] crashers

[Antoine Pitrou]

> There are 65 entries and among them I can additionally confirm:
> http://bugs.python.org/issue3720
> http://bugs.python.org/issue7788
> http://bugs.python.org/issue5765

One of them is fixed and the other two are pathological cases. You can't
really trigger them by mistake.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[anatoly techtonik]

On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou  wrote:
> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>
>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>> one - http://bugs.python.org/issue6608  Is it ok to release new versions
>> that are known to crash?
>
> I've changed this issue to release blocker. What are the other issues?

I've basically run a query to get all "crash" type issues for Python 2.6
http://bugs.python.org/iss...@search_text=&title=&@columns=title&id=&@columns=id&stage=&creation=&creator=&activity=&@columns=activity&@sort=activity&actor=&nosy=&type=1&components=&versions=1&dependencies=&assignee=&keywords=&priority=&@group=priority&status=1&@columns=status&resolution=&nosy_count=&message_count=&@pagesize=50&@startwith=0&@queryname=&@old-queryname=&@action=search

There are 65 entries and among them I can additionally confirm:
http://bugs.python.org/issue3720
http://bugs.python.org/issue7788
http://bugs.python.org/issue5765

-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] unittest: shortDescription, _TextTestResult and other issues

[Michael Foord]

Hello all,

I've been looking at outstanding unittest issues as part of my 
preparation for my PyCon talk. There are a couple of changes (minor) I'd 
like to make that I thought I ought to run past Python-Dev first. If I 
don't get any responses then I'll just do it, so you have been warned. :-)


The great google merge into unittest happened at PyCon last year [1]. 
This included a change to TestCase.shortDescription() so that it would 
*always* include the test name, whereas previously it would return the 
test docstring or None.


The problem this change solved was that tests with a docstring would not 
have their name (test class and method name) reported during the test 
run. Unfortunately the change broke part of twisted test running. 
Reported as issue 7588:


http://bugs.python.org/issue7588

It seems to me that the same effect (always reporting test name) can be 
achieved in _TextTestResult.getDescription(). I propose to revert the 
change to TestCase.shortDescription() (which has both a horrible name 
and a horrible implementation and should probably be renamed 
getDocstring so that what it does is obvious but never mind) and put the 
change into _TextTestResult.


It annoys me that _TextTestResult is private, as you will almost 
certainly want to use it or subclass it when implementing custom test 
systems. I am going to rename it TextTestResult, alias the old name and 
document the old name as being deprecated.


Another issue that I would like to address, but there are various 
possible approaches, is issue 7559: http://bugs.python.org/issue7559
Currently loadTestsFromName catches ImportError and rethrows as 
AttributeError. This is horrible (it obscures the original error) but 
there are backwards compatibility issues with fixing it. There are three 
possible approaches:


1) Leave it (the default)
2) Only throw an AttributeError if the import fails due to the name 
being invalid (the module not existing) otherwise allow the error 
through. (A minor but less serious change in behavior).
3) A new method that turns failures into pseudo-tests that fail with the 
original error when run. Possibly deprecating loadTestsFromName


I favour option 3, but can't think of a good replacement name. :-)

Comments welcomed.

Despite deprecating (in the documentation - no actual deprecations 
warnings I believe) a lot of the duplicate ways of doing things (assert* 
favoured over fail* and assertEqual over assertEquals) we didn't include 
deprecating assert_ in favour of assertTrue. I would like to add that to 
the documentation. After 3.2 is out I would like to clean up the 
documentation, removing mention of the deprecated methods from the 
*main* documentation into a separate 'deprecated methods' section. They 
currently make the documentation very untidy. The unittest page should 
probably be split into several pages anyway and needs improving.


Other outstanding minor issues:

Allow dotted names for test discovery
http://bugs.python.org/issue7780 - I intend to implement this as 
described in the last comment


A 'check_order' optional argument (defaulting to True) for 
assertSequenceEqual

http://bugs.python.org/issue7832 - needs patch

The breaking of __unittest caused by splitting unittesst into a package 
needs fixing. The fix needs to work when Python is run without frames 
support (IronPython).

http://bugs.python.org/issue7815 - needs patch

Allow a __unittest (or similar) decorator for user implemented assert 
functions

http://bugs.python.org/issue1705520 - needs patch

Allow modules to define test_suite callable.
http://bugs.python.org/issue7501 - I propose to close as rejected. Use 
load_tests instead.


Display time taken by individual tests when in verbose mode.
http://bugs.python.org/issue4080 - anyone any opinions?

Allow automatic formatting of arguments in assert* failure messages.
http://bugs.python.org/issue6966 - I propose to close as rejected

removeTest() method on TestSuite
http://bugs.python.org/issue1778410 - anyone any opinions?

expect methods (delayed fail)
http://bugs.python.org/issue3615 - any opinions? Personally I think that 
the TestCase API is big enough already



All the best,

Michael Foord

[1] Mostly in revision 7-837. 
http://svn.python.org/view?view=rev&revision=70837





--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer

[Python-Dev] setUpClass and setUpModule in unittest

[Michael Foord]

Hello all,

The next 'big' change to unittest will (may?) be the introduction of 
class and module level setUp and tearDown. This was discussed on 
Python-ideas and Guido supported them. They can be useful but are also 
very easy to abuse (too much shared state, monolithic test classes and 
modules). Several authors of other Python testing frameworks spoke up 
*against* them, but several *users* of test frameworks spoke up in 
favour of them. ;-)


I'm pretty sure I can introduce setUpClass and setUpModule without 
breaking compatibility with existing unittest extensions or backwards 
compatibility issues - with the possible exception of test sorting. 
Where you have a class level setUp (for example creating a database 
connection) you don't want the tearDown executed a *long* time after the 
setUp. In the presence of class or module level setUp /tearDown (but 
only if they are used) I would expect test sorting to only sort within 
the class or module [1]. I will introduce the setUp and tearDown as new 
'tests' - so failures are reported separately, and all tests in the 
class / module will have an explicit skip in the event of a setUp failure.


A *better* (more general) solution for sharing and managing resources 
between tests is to use something like TestResources by Robert Collins. 
http://pypi.python.org/pypi/testresources/


A minimal example of using test resources shows very little boilerplate 
overhead from what setUpClass (etc) would need, and with the addition of 
some helper functions could be almost no overhead. I've challenged 
Robert that if he can provide examples of using Test Resources to meet 
the class and module level use-cases then I would support bringing Test 
Resources into the standard library as part of unittest (modulo 
licensing issues which he is happy to work on).


I'm not sure what response I expect from this email, and neither option 
will be implemented without further discussion - possibly at the PyCon 
sprints - but I thought I would make it clear what the possible 
directions are.


All the best,

Michael Foord

[1] I *could* allow sorting of all tests within a module, inserting the 
setUpClass / tearDownClass in the right place after the sort. It would 
probably be better to group tests per class anyway and in fact the 
existing suite sorting support may do this already (in which case it 
isn't an issue) - I haven't looked into the implementation.


--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Brian Curtin]

On Tue, Feb 9, 2010 at 06:45, anatoly techtonik  wrote:

> On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou 
> wrote:
> > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
> >>
> >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> >> one - http://bugs.python.org/issue6608  Is it ok to release new
> versions
> >> that are known to crash?
> >
> > I've changed this issue to release blocker. What are the other issues?
>
> I've basically run a query to get all "crash" type issues for Python 2.6
>
> http://bugs.python.org/iss...@search_text=&title=&@columns=title&id=&@columns=id&stage=&creation=&creator=&activity=&@columns=activity&@sort=activity&actor=&nosy=&type=1&components=&versions=1&dependencies=&assignee=&keywords=&priority=&@group=priority&status=1&@columns=status&resolution=&nosy_count=&message_count=&@pagesize=50&@startwith=0&@queryname=&@old-queryname=&@action=search
>
> There are 65 entries and among them I can additionally confirm:
> http://bugs.python.org/issue3720
> http://bugs.python.org/issue7788
> http://bugs.python.org/issue5765
>
> --
> anatoly t.
>
> After taking a quick look, at least 14 of them were misreported as crashes.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Antoine Pitrou]

Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
> 
> The next 'big' change to unittest will (may?) be the introduction of
> class and module level setUp and tearDown. This was discussed on
> Python-ideas and Guido supported them. They can be useful but are also
> very easy to abuse (too much shared state, monolithic test classes and
> modules). Several authors of other Python testing frameworks spoke up
> *against* them, but several *users* of test frameworks spoke up in
> favour of them. ;-)

One problem is that it is not obvious what happens with inheritance.
If I have a class-level setUp for class B, and class C inherits from B, 
will there be a separate invocation of setUp for C, or not?
(I guess both possibilities have use cases)


Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
 wrote:
> Hello all,
>
> Several
> authors of other Python testing frameworks spoke up *against* them, but
> several *users* of test frameworks spoke up in favour of them. ;-)
>

+1 for having something like that included in unittest

> I'm pretty sure I can introduce setUpClass and setUpModule without breaking
> compatibility with existing unittest extensions or backwards compatibility
> issues

Is it possible to use the names `BeforeClass` and `AfterClass` (just
to be make it look similar to JUnit naming conventions ;o) ?

> - with the possible exception of test sorting. Where you have a class
> level setUp (for example creating a database connection) you don't want the
> tearDown executed a *long* time after the setUp. In the presence of class or
> module level setUp /tearDown (but only if they are used) I would expect test
> sorting to only sort within the class or module [1]. I will introduce the
> setUp and tearDown as new 'tests' - so failures are reported separately,

Perhaps I am missing something, but could you please mention what will
happen if a failure is raised inside class-level `tearDown` ?

> and
> all tests in the class / module will have an explicit skip in the event of a
> setUp failure.
>

+1

> A *better* (more general) solution for sharing and managing resources
> between tests is to use something like TestResources by Robert Collins.
> http://pypi.python.org/pypi/testresources/
>
> A minimal example of using test resources shows very little boilerplate
> overhead from what setUpClass (etc) would need, and with the addition of
> some helper functions could be almost no overhead. I've challenged Robert
> that if he can provide examples of using Test Resources to meet the class
> and module level use-cases then I would support bringing Test Resources into
> the standard library as part of unittest (modulo licensing issues which he
> is happy to work on).
>

I am not really sure about whether unittest API should grow, and grow,
and grow, and ... but if that means that TestResources will not be
even imported if testers don't do it explicitly in the code (which is
not the case of something like class level setUp/tearDown) then +1,
otherwise -0.5

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
TracGViz plugin downloaded more than 1000 times (> 300 from PyPI) -
http://feedproxy.google.com/~r/simelo-en/~3/06Exn-JPLIA/tracgviz-plugin-downloaded-more-than.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Michael Foord]

On 09/02/2010 17:57, Antoine Pitrou wrote:

Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
   

The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This was discussed on
Python-ideas and Guido supported them. They can be useful but are also
very easy to abuse (too much shared state, monolithic test classes and
modules). Several authors of other Python testing frameworks spoke up
*against* them, but several *users* of test frameworks spoke up in
favour of them. ;-)
 

One problem is that it is not obvious what happens with inheritance.
If I have a class-level setUp for class B, and class C inherits from B,
will there be a separate invocation of setUp for C, or not?
(I guess both possibilities have use cases)
   


Well, what I would expect (others may disagree) is that you only have 
class level setup invoked for classes that have tests (so not for base 
classes) and that the base-class setUpClass is only called if invoked by 
the subclass.


I haven't thought about *where* the code to do this should go. It 
*could* go in TestSuite, but that feels like the wrong place.


Michael



Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang  wrote:
> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>  wrote:
>> Hello all,
>>
>> Several
>> authors of other Python testing frameworks spoke up *against* them, but
>> several *users* of test frameworks spoke up in favour of them. ;-)
>>
>
> +1 for having something like that included in unittest
>
>> I'm pretty sure I can introduce setUpClass and setUpModule without breaking
>> compatibility with existing unittest extensions or backwards compatibility
>> issues
>
> Is it possible to use the names `BeforeClass` and `AfterClass` (just
> to be make it look similar to JUnit naming conventions ;o) ?
>

Another Q:

  - class setup method will be a `classmethod` isn't it ? It should not be
 a regular instance method because IMO it is not bound to a particular
 `TestCase` instance.

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Embedding pages? - Trac Users | Google Groups  -
http://feedproxy.google.com/~r/TracGViz-full/~3/-XtS7h-wjcI/e4cf16474aa3cb87
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

Sorry. I had not finished the previous message

On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang  wrote:
> On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang  wrote:
>> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>>  wrote:
>>> Hello all,
>>>
>>> Several
>>> authors of other Python testing frameworks spoke up *against* them, but
>>> several *users* of test frameworks spoke up in favour of them. ;-)
>>>
>>
>> +1 for having something like that included in unittest
>>
>>> I'm pretty sure I can introduce setUpClass and setUpModule without breaking
>>> compatibility with existing unittest extensions or backwards compatibility
>>> issues
>>
>> Is it possible to use the names `BeforeClass` and `AfterClass` (just
>> to be make it look similar to JUnit naming conventions ;o) ?
>>
>
> Another Q:
>
>  - class setup method will be a `classmethod` isn't it ? It should not be
>     a regular instance method because IMO it is not bound to a particular
>     `TestCase` instance.
>

  - Is it possible to rely on the fact that all class-level tear down
methods will be guaranteed to run even if class-level setup
method throws an exception ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PEP 391 - Please Vote!  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Michael Foord]

On 09/02/2010 19:00, Olemis Lang wrote:

Sorry. I had not finished the previous message

On Tue, Feb 9, 2010 at 1:55 PM, Olemis Lang  wrote:
   

On Tue, Feb 9, 2010 at 1:29 PM, Olemis Lang  wrote:
 

On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
  wrote:
   

Hello all,

Several
authors of other Python testing frameworks spoke up *against* them, but
several *users* of test frameworks spoke up in favour of them. ;-)

 

+1 for having something like that included in unittest

   

I'm pretty sure I can introduce setUpClass and setUpModule without breaking
compatibility with existing unittest extensions or backwards compatibility
issues
 

Is it possible to use the names `BeforeClass` and `AfterClass` (just
to be make it look similar to JUnit naming conventions ;o) ?

   

Another Q:

  - class setup method will be a `classmethod` isn't it ? It should not be
 a regular instance method because IMO it is not bound to a particular
 `TestCase` instance.

 

   - Is it possible to rely on the fact that all class-level tear down
 methods will be guaranteed to run even if class-level setup
 method throws an exception ?

   
Yes it will be a classmethod rather than an instance method. I would 
expect that in common with instance setUp the tearDown would *not* be 
run if setUp fails. What would be nice would be an extension of 
addCleanUp so that it can be used by class and module level setUp. 
Clean-ups largely obsolete the need for tearDown anyway.


Michael

--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 12:57 PM, Antoine Pitrou  wrote:
> Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
>>
>> The next 'big' change to unittest will (may?) be the introduction of
>> class and module level setUp and tearDown. This was discussed on
>> Python-ideas and Guido supported them. They can be useful but are also
>> very easy to abuse (too much shared state, monolithic test classes and
>> modules). Several authors of other Python testing frameworks spoke up
>> *against* them, but several *users* of test frameworks spoke up in
>> favour of them. ;-)
>
> One problem is that it is not obvious what happens with inheritance.
> If I have a class-level setUp for class B, and class C inherits from B,
> will there be a separate invocation of setUp for C, or not?
> (I guess both possibilities have use cases)
>

Considering JUnit :

  - The @BeforeClass methods of superclasses will be run before those
the current class.
  - The @AfterClass methods declared in superclasses will be run after
those of the current class.

However considering that PyUnit is not based on annotations, isn't it
possible to specify that explicitly (and assume super-class method not
called by default) ?

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
gmane.comp.version-control.subversion.trac.general  -
http://feedproxy.google.com/~r/TracGViz-full/~3/SLY6s0RazcA/28067
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Holger Krekel]

On Tue, Feb 9, 2010 at 7:29 PM, Olemis Lang  wrote:
> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>  wrote:
>> Hello all,
>>
>> Several
>> authors of other Python testing frameworks spoke up *against* them, but
>> several *users* of test frameworks spoke up in favour of them. ;-)
>>
>
> +1 for having something like that included in unittest

hey Olemis, aren't you a test tool author as well? :)

>> I'm pretty sure I can introduce setUpClass and setUpModule without breaking
>> compatibility with existing unittest extensions or backwards compatibility
>> issues
>
> Is it possible to use the names `BeforeClass` and `AfterClass` (just
> to be make it look similar to JUnit naming conventions ;o) ?
>
>> - with the possible exception of test sorting. Where you have a class
>> level setUp (for example creating a database connection) you don't want the
>> tearDown executed a *long* time after the setUp. In the presence of class or
>> module level setUp /tearDown (but only if they are used) I would expect test
>> sorting to only sort within the class or module [1]. I will introduce the
>> setUp and tearDown as new 'tests' - so failures are reported separately,
>
> Perhaps I am missing something, but could you please mention what will
> happen if a failure is raised inside class-level `tearDown` ?
>
>> and
>> all tests in the class / module will have an explicit skip in the event of a
>> setUp failure.
>>

I think reporting tests as skipped when the setup failed is a bad idea.
Out of several years of practise with skips and large test suites (and
talking/experiencing many users :) i recommend to reserve skips for
platform/dependency/environment mismatches. A Setup Error should
just error or fail all the tests in its scope.

cheers,
holger
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Brian Curtin]

On Tue, Feb 9, 2010 at 12:29, Olemis Lang  wrote:

> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>  wrote:
> > I'm pretty sure I can introduce setUpClass and setUpModule without
> breaking
> > compatibility with existing unittest extensions or backwards
> compatibility
> > issues
>
> Is it possible to use the names `BeforeClass` and `AfterClass` (just
> to be make it look similar to JUnit naming conventions ;o) ?
> --
> Regards,
>
> Olemis.
>

-1. setUp/tearDown is already well established here so I think it should
follow the same convention.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Michael Foord]

On 09/02/2010 19:14, Holger Krekel wrote:

[snip...]

and
all tests in the class / module will have an explicit skip in the event of a
setUp failure.

   

I think reporting tests as skipped when the setup failed is a bad idea.
Out of several years of practise with skips and large test suites (and
talking/experiencing many users :) i recommend to reserve skips for
platform/dependency/environment mismatches. A Setup Error should
just error or fail all the tests in its scope.
   


A SetupError instead of a skip sounds good to me. Thanks (although 
technically the test has been 'skipped' but that's playing with 
semantics...)


Michael


cheers,
holger
   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 1:44 PM, Michael Foord  wrote:
> On 09/02/2010 17:57, Antoine Pitrou wrote:
>>
>> Le Tue, 09 Feb 2010 16:42:50 +, Michael Foord a écrit :
>>
>>>
>>> The next 'big' change to unittest will (may?) be the introduction of
>>> class and module level setUp and tearDown. This was discussed on
>>> Python-ideas and Guido supported them. They can be useful but are also
>>> very easy to abuse (too much shared state, monolithic test classes and
>>> modules). Several authors of other Python testing frameworks spoke up
>>> *against* them, but several *users* of test frameworks spoke up in
>>> favour of them. ;-)
>>>
>>
>> One problem is that it is not obvious what happens with inheritance.
>> If I have a class-level setUp for class B, and class C inherits from B,
>> will there be a separate invocation of setUp for C, or not?
>> (I guess both possibilities have use cases)
>>
>
> Well, what I would expect (others may disagree) is that you only have class
> level setup invoked for classes that have tests (so not for base classes)
> and that the base-class setUpClass is only called if invoked by the
> subclass.
>
> I haven't thought about *where* the code to do this should go. It *could* go
> in TestSuite, but that feels like the wrong place.
>

When I implemented this in `dutest` I did it as follows :

  - Changed suiteClass (since it was an extension ;o)
  - I had to override the suite's `run` method

PS: Probably it's not the right place, but AFAIK it's the only place
«we» have to do such things ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Embedding pages? - Trac Users | Google Groups  -
http://feedproxy.google.com/~r/TracGViz-full/~3/-XtS7h-wjcI/e4cf16474aa3cb87
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 2:16 PM, Brian Curtin  wrote:
> On Tue, Feb 9, 2010 at 12:29, Olemis Lang  wrote:
>>
>> On Tue, Feb 9, 2010 at 11:42 AM, Michael Foord
>>  wrote:
>> > I'm pretty sure I can introduce setUpClass and setUpModule without
>> > breaking
>> > compatibility with existing unittest extensions or backwards
>> > compatibility
>> > issues
>>
>> Is it possible to use the names `BeforeClass` and `AfterClass` (just
>> to be make it look similar to JUnit naming conventions ;o) ?
>> --
>> Regards,
>>
>> Olemis.
>
>
> -1. setUp/tearDown is already well established here so I think it should
> follow the same convention.
>

ok no big deal

;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Nabble - Trac Users - Embedding pages?  -
http://feedproxy.google.com/~r/TracGViz-full/~3/MWT7MJBi08w/Embedding-pages--td27358804.html
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Forking and Multithreading - enemy brothers

[Pascal Chambon]

Hello

Some update about the spawnl() thingy ;

I've adapted the win32 code to have a new unix Popen object, which works 
with a spawn() semantic. It's quite straightforward, and the 
mutiprocessing call of a python functions works OK.


But I've run into some trouble : synchronization primitives.
Win32 semaphore can be "teleported" to another process via the 
DuplicateHandle() call. But unix named semaphores don't work that way - 
instead, they must be opened with the same name by each spawned subprocess.
The problem here, the current semaphore C code is optimized to forbid 
semaphore sharing (other than via fork) : use of (O_EXL|O_CREAT) on 
opening, immediate unlinking of new semaphores


So if we want to benefit from sync primitives with this spawn() 
implementation, we need a working named semaphore implementation, too...


What's the best in your opinion ? Editing the current multiprocessing 
semaphore's behaviour to allow (with specific options, attributes and 
methods) its use in this case ? Or adding a new NamedSemaphore type like 
this one ?

http://semanchuk.com/philip/posix_ipc/

Regards,
Pascal







___
Python-Dev mailing list
Python-Dev@python.org
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: shortDescription, _TextTestResult and other issues

[Michael Foord]

I missed another minor issue. In the interests of completeness...

You currently have to subclass TextTestRunner (and override _makeResult) 
for it to use a custom TestResult. Implementing a custom test result is 
one of extensibility points of unittest, so I propose adding an optional 
argument to TextTestRunner allowing you to pass in a result class (or 
other callable) that _makeResult will use to create the result object. 
Should be uncontroversial. :-)


http://bugs.python.org/issue7893

Michael

On 09/02/2010 16:40, Michael Foord wrote:

Hello all,

I've been looking at outstanding unittest issues as part of my 
preparation for my PyCon talk. There are a couple of changes (minor) 
I'd like to make that I thought I ought to run past Python-Dev first. 
If I don't get any responses then I'll just do it, so you have been 
warned. :-)


The great google merge into unittest happened at PyCon last year [1]. 
This included a change to TestCase.shortDescription() so that it would 
*always* include the test name, whereas previously it would return the 
test docstring or None.


The problem this change solved was that tests with a docstring would 
not have their name (test class and method name) reported during the 
test run. Unfortunately the change broke part of twisted test running. 
Reported as issue 7588:


http://bugs.python.org/issue7588

It seems to me that the same effect (always reporting test name) can 
be achieved in _TextTestResult.getDescription(). I propose to revert 
the change to TestCase.shortDescription() (which has both a horrible 
name and a horrible implementation and should probably be renamed 
getDocstring so that what it does is obvious but never mind) and put 
the change into _TextTestResult.


It annoys me that _TextTestResult is private, as you will almost 
certainly want to use it or subclass it when implementing custom test 
systems. I am going to rename it TextTestResult, alias the old name 
and document the old name as being deprecated.


Another issue that I would like to address, but there are various 
possible approaches, is issue 7559: http://bugs.python.org/issue7559
Currently loadTestsFromName catches ImportError and rethrows as 
AttributeError. This is horrible (it obscures the original error) but 
there are backwards compatibility issues with fixing it. There are 
three possible approaches:


1) Leave it (the default)
2) Only throw an AttributeError if the import fails due to the name 
being invalid (the module not existing) otherwise allow the error 
through. (A minor but less serious change in behavior).
3) A new method that turns failures into pseudo-tests that fail with 
the original error when run. Possibly deprecating loadTestsFromName


I favour option 3, but can't think of a good replacement name. :-)

Comments welcomed.

Despite deprecating (in the documentation - no actual deprecations 
warnings I believe) a lot of the duplicate ways of doing things 
(assert* favoured over fail* and assertEqual over assertEquals) we 
didn't include deprecating assert_ in favour of assertTrue. I would 
like to add that to the documentation. After 3.2 is out I would like 
to clean up the documentation, removing mention of the deprecated 
methods from the *main* documentation into a separate 'deprecated 
methods' section. They currently make the documentation very untidy. 
The unittest page should probably be split into several pages anyway 
and needs improving.


Other outstanding minor issues:

Allow dotted names for test discovery
http://bugs.python.org/issue7780 - I intend to implement this as 
described in the last comment


A 'check_order' optional argument (defaulting to True) for 
assertSequenceEqual

http://bugs.python.org/issue7832 - needs patch

The breaking of __unittest caused by splitting unittesst into a 
package needs fixing. The fix needs to work when Python is run without 
frames support (IronPython).

http://bugs.python.org/issue7815 - needs patch

Allow a __unittest (or similar) decorator for user implemented assert 
functions

http://bugs.python.org/issue1705520 - needs patch

Allow modules to define test_suite callable.
http://bugs.python.org/issue7501 - I propose to close as rejected. Use 
load_tests instead.


Display time taken by individual tests when in verbose mode.
http://bugs.python.org/issue4080 - anyone any opinions?

Allow automatic formatting of arguments in assert* failure messages.
http://bugs.python.org/issue6966 - I propose to close as rejected

removeTest() method on TestSuite
http://bugs.python.org/issue1778410 - anyone any opinions?

expect methods (delayed fail)
http://bugs.python.org/issue3615 - any opinions? Personally I think 
that the TestCase API is big enough already



All the best,

Michael Foord

[1] Mostly in revision 7-837. 
http://svn.python.org/view?view=rev&revision=70837








--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 

Re: [Python-Dev] Python 2.6.5

[Martin v. Löwis]

> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> one - http://bugs.python.org/issue6608  Is it ok to release new
> versions that are known to crash?

As a general principle: yes, that's ok. We even distribute known
crashers with every release.

Regards,
Martin

___
Python-Dev mailing list
Python-Dev@python.org
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: shortDescription, _TextTestResult and other issues

[Ben Finney]

Michael Foord  writes:

> It seems to me that the same effect (always reporting test name) can
> be achieved in _TextTestResult.getDescription(). I propose to revert
> the change to TestCase.shortDescription() (which has both a horrible
> name and a horrible implementation and should probably be renamed
> getDocstring so that what it does is obvious but never mind) and put
> the change into _TextTestResult.

I understood the point of ‘TestCase.shortDescription’, and indeed the
point of that particular name, was to be clear that some *other* text
could be the short description for the test case. Indeed, this is what
you've come up with: a different implementation for generating a short
description.

The default implementation uses *part of* the docstring (the PEP 257
specified single-line summary), but that's just one possible way to make
a short test case description. Calling it ‘getDocstring’ would not only
be disruptive, but clearly false even in the default implementation.

I've overridden that method to provide better, more specific, test case
short descriptions, and the name works fine since I'm providing an
overridden implementation of “the short description of this test case”.
I've even presented a patch to the third-party ‘testscenarios’ library
to decorate the short description with the scenario name.

I'd suggest this method, with its existing name, is the correct way to
embellish test case descriptions for report output.

-- 
 \   “I do not believe in forgiveness as it is preached by the |
  `\church. We do not need the forgiveness of God, but of each |
_o__)other and of ourselves.” —Robert G. Ingersoll |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Martin v. Löwis]

> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>> one - http://bugs.python.org/issue6608  Is it ok to release new versions
>> that are known to crash?
> 
> I've changed this issue to release blocker. What are the other issues?

For a bug fix release, it should (IMO) be a release blocker *only* if
this is a regression in the branch or some recent bug fix release over
some earlier bug fix release.

E.g. if 2.6.2 had broken something that worked in 2.6.1, it would be ok
to delay 2.6.5. If 2.6.2 breaks in a case where all prior releases also
broke, it would NOT be ok, IMO, to block 2.6.5 for that. There can
always be a 2.6.6 release.

Of course, if this gets fixed before the scheduled release of 2.6.5,
anyway, that would be nice.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Ben Finney]

Michael Foord  writes:

> The next 'big' change to unittest will (may?) be the introduction of
> class and module level setUp and tearDown. This was discussed on
> Python-ideas and Guido supported them. They can be useful but are also
> very easy to abuse (too much shared state, monolithic test classes and
> modules). Several authors of other Python testing frameworks spoke up
> *against* them, but several *users* of test frameworks spoke up in
> favour of them. ;-)

I think the perceived need for these is from people trying to use the
‘unittest’ API for test that are *not* unit tests.

That is, people have a need for integration tests (test this module's
interaction with some other module) or system tests (test the behaviour
of the whole running system). They then try to crowbar those tests into
‘unittest’ and finding it lacking, since ‘unittest’ is designed for
tests of function-level units, without persistent state between those
test cases.

Is there a better third-party framework for use in these cases? As
Olemis points out later in this thread, I don't think it's good for the
‘unittest’ module to keep growing for uses that aren't focussed on unit
tests (as contrasted with other kinds of tests).

-- 
 \“The industrial system is profoundly dependent on commercial |
  `\   television and could not exist in its present form without it.” |
_o__)—John Kenneth Galbraith, _The New Industrial State_, 1967 |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Antoine Pitrou]

Le mardi 09 février 2010 à 22:55 +0100, "Martin v. Löwis" a écrit :
> > Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
> >> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
> >> one - http://bugs.python.org/issue6608  Is it ok to release new versions
> >> that are known to crash?
> > 
> > I've changed this issue to release blocker. What are the other issues?
> 
> For a bug fix release, it should (IMO) be a release blocker *only* if
> this is a regression in the branch or some recent bug fix release over
> some earlier bug fix release.

As far as I remember, I think we have had release blockers which weren't
regressions.
Not that I strongly want to argue in favour of this one anyway.

cheers

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Martin v. Löwis]

>>> I've changed this issue to release blocker. What are the other issues?
>> For a bug fix release, it should (IMO) be a release blocker *only* if
>> this is a regression in the branch or some recent bug fix release over
>> some earlier bug fix release.
> 
> As far as I remember, I think we have had release blockers which weren't
> regressions.

Of course, the release manager can always declare anything a release
blocker, so that may have been the reason (I don't recall the details).
Also, on a feature release, many more kinds of blockers may exist (e.g.
for features that aren't complete yet). It simply may also have been
that nobody argued in favor of process. I know that I have, from time to
time, unblocked release blockers because I thought that they shouldn't
have blocked the release out of principle.

IOW, I feel that release blockers should only be used if something
really bad would happen that can be prevented by not releasing. If
nothing actually gets worse by the release, the release shouldn't be
blocked.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
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: shortDescription, _TextTestResult and other issues

[Olemis Lang]

On Tue, Feb 9, 2010 at 4:50 PM, Ben Finney  wrote:
> Michael Foord  writes:
>
>> It seems to me that the same effect (always reporting test name) can
>> be achieved in _TextTestResult.getDescription(). I propose to revert
>> the change to TestCase.shortDescription() (which has both a horrible
>> name and a horrible implementation and should probably be renamed
>> getDocstring so that what it does is obvious but never mind) and put
>> the change into _TextTestResult.
>
[...]
>
> I've overridden that method to provide better, more specific, test case
> short descriptions, and the name works fine since I'm providing an
> overridden implementation of “the short description of this test case”.


Oh yes ! Thnx for mentioning that ! Very much !

If you move or remove shortDescription then I think dutest will be
broken. In that case there is an automatically generated short
description  comprising the doctest name or id (e.g. class name +
method name ;o) and example index (just remember that every
interactive example is considered to be a test case ;o)

In that case there is no other way to get this done unless an
all-mighty & heavy test result be implemented .

So I am *VERY* -1 for removing `shortDescription` (and I also think
that TC should be the one to provide the short desc rather than the
test result, just like what Ben Finney said before ;o)

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
PEP 391 - Please Vote!  -
http://feedproxy.google.com/~r/TracGViz-full/~3/hY2h6ZSAFRE/110617
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Olemis Lang]

On Tue, Feb 9, 2010 at 4:57 PM, Ben Finney  wrote:
> Michael Foord  writes:
>
>> The next 'big' change to unittest will (may?) be the introduction of
>> class and module level setUp and tearDown. This was discussed on
>> Python-ideas and Guido supported them. They can be useful but are also
>> very easy to abuse (too much shared state, monolithic test classes and
>> modules). Several authors of other Python testing frameworks spoke up
>> *against* them, but several *users* of test frameworks spoke up in
>> favour of them. ;-)
>
> I think the perceived need for these is from people trying to use the
> ‘unittest’ API for test that are *not* unit tests.
>

I dont't think so. I'll try to explain what I consider is a real use
case tomorrow ...

-- 
Regards,

Olemis.

Blog ES: http://simelo-es.blogspot.com/
Blog EN: http://simelo-en.blogspot.com/

Featured article:
Free milestone ranch Download - mac software  -
http://feedproxy.google.com/~r/TracGViz-full/~3/rX6_RmRWThE/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Holger Krekel]

On Tue, Feb 9, 2010 at 10:57 PM, Ben Finney  wrote:
> Michael Foord  writes:
>
>> The next 'big' change to unittest will (may?) be the introduction of
>> class and module level setUp and tearDown. This was discussed on
>> Python-ideas and Guido supported them. They can be useful but are also
>> very easy to abuse (too much shared state, monolithic test classes and
>> modules). Several authors of other Python testing frameworks spoke up
>> *against* them, but several *users* of test frameworks spoke up in
>> favour of them. ;-)
>
> I think the perceived need for these is from people trying to use the
> ‘unittest’ API for test that are *not* unit tests.
>
> That is, people have a need for integration tests (test this module's
> interaction with some other module) or system tests (test the behaviour
> of the whole running system). They then try to crowbar those tests into
> ‘unittest’ and finding it lacking, since ‘unittest’ is designed for
> tests of function-level units, without persistent state between those
> test cases.
>
> Is there a better third-party framework for use in these cases? As
> Olemis points out later in this thread, I don't think it's good for the
> ‘unittest’ module to keep growing for uses that aren't focussed on unit
> tests (as contrasted with other kinds of tests).

My general view these days is that for unit tests there is practically not
much of a a difference in using unittest, nose or py.test (give or
take reporting
niceness and flexibility).  However, Functional and integration tests
involve more
complex fixture management and i came to find the setup/teardown on
classes and modules lacking.  Which is why there is testresources from
Rob and funcargs in py.test. The latter allow to setup and teardown
resources from a fixture factory which can determine the setup/teardown scope
and perform whole-session caching without changing test code.  In my
Pycon testing tutorial (http://tinyurl.com/ya6b3vr ) i am going to exercise
it in depth with beginners and here are docs: http://pytest.org/funcargs.html
One nice bit is that you can for a given test module issue "py.test --funcargs"
and get a list of resources you can use in your test function - by simply
specifying them in the test function.

In principle it's possible to port this approach to the stdlib - actually i
consider to do it for the std-unittest- running part of py.test because
people asked for it - if that proves useful i can imagine to refine it
and offer it for inclusion.

cheers,
holger
___
Python-Dev mailing list
Python-Dev@python.org
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: shortDescription, _TextTestResult and other issues

[Michael Foord]

On 09/02/2010 22:22, Olemis Lang wrote:

On Tue, Feb 9, 2010 at 4:50 PM, Ben Finney  wrote:
   

Michael Foord  writes:

 

It seems to me that the same effect (always reporting test name) can
be achieved in _TextTestResult.getDescription(). I propose to revert
the change to TestCase.shortDescription() (which has both a horrible
name and a horrible implementation and should probably be renamed
getDocstring so that what it does is obvious but never mind) and put
the change into _TextTestResult.
   
 

[...]
   

I've overridden that method to provide better, more specific, test case
short descriptions, and the name works fine since I'm providing an
overridden implementation of “the short description of this test case”.
 


Oh yes ! Thnx for mentioning that ! Very much !

If you move or remove shortDescription then I think dutest will be
broken. In that case there is an automatically generated short
description  comprising the doctest name or id (e.g. class name +
method name ;o) and example index (just remember that every
interactive example is considered to be a test case ;o)
   


I am *not* suggesting removing shortDescription I am suggesting 
reverting to its behavior in Python 2.6. That would not affect your or 
Ben's use case (obviously). Given the name 'short description' it is 
being argued that making the description longer by adding the test name 
is inappropriate and that if this needs to be reported (which it should 
be) then this rightly belongs in the TestResult.


Michael Foord


In that case there is no other way to get this done unless an
all-mighty&  heavy test result be implemented .

So I am *VERY* -1 for removing `shortDescription` (and I also think
that TC should be the one to provide the short desc rather than the
test result, just like what Ben Finney said before ;o)

   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Robert Kern]

On 2010-02-09 15:57 PM, Ben Finney wrote:


Is there a better third-party framework for use in these cases? As
Olemis points out later in this thread, I don't think it's good for the
‘unittest’ module to keep growing for uses that aren't focussed on unit
tests (as contrasted with other kinds of tests).


nosetests allows you to write such module-level and class-level setup and 
teardown functions.


--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
Python-Dev mailing list
Python-Dev@python.org
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: shortDescription, _TextTestResult and other issues

[Michael Foord]

On 09/02/2010 21:50, Ben Finney wrote:

Michael Foord  writes:

   

It seems to me that the same effect (always reporting test name) can
be achieved in _TextTestResult.getDescription(). I propose to revert
the change to TestCase.shortDescription() (which has both a horrible
name and a horrible implementation and should probably be renamed
getDocstring so that what it does is obvious but never mind) and put
the change into _TextTestResult.
 

I understood the point of ‘TestCase.shortDescription’, and indeed the
point of that particular name, was to be clear that some *other* text
could be the short description for the test case. Indeed, this is what
you've come up with: a different implementation for generating a short
description.

The default implementation uses *part of* the docstring (the PEP 257
specified single-line summary), but that's just one possible way to make
a short test case description. Calling it ‘getDocstring’ would not only
be disruptive, but clearly false even in the default implementation.

   
I'm not actually suggesting doing that - I was just musing out loud. So 
do you think the *new* implementation would be better, given that it 
breaks part of the twisted test suite, or would you be fine with me 
putting the current change into TestResult instead?


Given that the change broke something, and the desired effect can be 
gained with a different change, I don't really see a downside to the 
change I'm proposing (reverting shortDescription and moving the code 
that adds the test name to TestResult).


Michael


I've overridden that method to provide better, more specific, test case
short descriptions, and the name works fine since I'm providing an
overridden implementation of “the short description of this test case”.
I've even presented a patch to the third-party ‘testscenarios’ library
to decorate the short description with the scenario name.

I'd suggest this method, with its existing name, is the correct way to
embellish test case descriptions for report output.

   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Michael Foord]

On 09/02/2010 21:57, Ben Finney wrote:

Michael Foord  writes:

   

The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This was discussed on
Python-ideas and Guido supported them. They can be useful but are also
very easy to abuse (too much shared state, monolithic test classes and
modules). Several authors of other Python testing frameworks spoke up
*against* them, but several *users* of test frameworks spoke up in
favour of them. ;-)
 

I think the perceived need for these is from people trying to use the
‘unittest’ API for test that are *not* unit tests.

That is, people have a need for integration tests (test this module's
interaction with some other module) or system tests (test the behaviour
of the whole running system). They then try to crowbar those tests into
‘unittest’ and finding it lacking, since ‘unittest’ is designed for
tests of function-level units, without persistent state between those
test cases.
   


I've used unittest for long running functional and integration tests (in 
both desktop and web applications). The infrastructure it provides is 
great for this. Don't get hung up on the fact that it is called 
unittest. In fact for many users the biggest reason it isn't suitable 
for tests like these is the lack of shared fixture support - which is 
why the other Python test frameworks provide them and we are going to 
bring it into unittest.


Michael


Is there a better third-party framework for use in these cases? As
Olemis points out later in this thread, I don't think it's good for the
‘unittest’ module to keep growing for uses that aren't focussed on unit
tests (as contrasted with other kinds of tests).

   



--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog

READ CAREFULLY. By accepting and reading this email you agree, on behalf of 
your employer, to release me from all obligations and waivers arising from any 
and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, 
clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and 
acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your 
employer, its partners, licensors, agents and assigns, in perpetuity, without 
prejudice to my ongoing rights and privileges. You further represent that you 
have the authority to release me from any BOGUS AGREEMENTS on behalf of your 
employer.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 3146: Merge Unladen Swallow into CPython

[Collin Winter]

To follow up on some of the open issues:

On Wed, Jan 20, 2010 at 2:27 PM, Collin Winter  wrote:
[snip]
> Open Issues
> ===
>
> - *Code review policy for the ``py3k-jit`` branch.* How does the CPython
>  community want us to procede with respect to checkins on the ``py3k-jit``
>  branch? Pre-commit reviews? Post-commit reviews?
>
>  Unladen Swallow has enforced pre-commit reviews in our trunk, but we realize
>  this may lead to long review/checkin cycles in a purely-volunteer
>  organization. We would like a non-Google-affiliated member of the CPython
>  development team to review our work for correctness and compatibility, but we
>  realize this may not be possible for every commit.

The feedback we've gotten so far is that at most, only larger, more
critical commits should be sent for review, while most commits can
just go into the branch. Is that broadly agreeable to python-dev?

> - *How to link LLVM.* Should we change LLVM to better support shared linking,
>  and then use shared linking to link the parts of it we need into CPython?

The consensus has been that we should link shared against LLVM.
Jeffrey Yasskin is now working on this in upstream LLVM. We are
tracking this at
http://code.google.com/p/unladen-swallow/issues/detail?id=130 and
http://llvm.org/PR3201.

> - *Prioritization of remaining issues.* We would like input from the CPython
>  development team on how to prioritize the remaining issues in the Unladen
>  Swallow codebase. Some issues like memory usage are obviously critical before
>  merger with ``py3k``, but others may fall into a "nice to have" category that
>  could be kept for resolution into a future CPython 3.x release.

The big-ticket items here are what we expected: reducing memory usage
and startup time. We also need to improve profiling options, both for
oProfile and cProfile.

> - *Create a C++ style guide.* Should PEP 7 be extended to include C++, or
>  should a separate C++ style PEP be created? Unladen Swallow maintains its own
>  style guide [#us-styleguide]_, which may serve as a starting point; the
>  Unladen Swallow style guide is based on both LLVM's [#llvm-styleguide]_ and
>  Google's [#google-styleguide]_ C++ style guides.

Any thoughts on a CPython C++ style guide? My personal preference
would be to extend PEP 7 to cover C++ by taking elements from
http://code.google.com/p/unladen-swallow/wiki/StyleGuide and the LLVM
and Google style guides (which is how we've been developing Unladen
Swallow). If that's broadly agreeable, Jeffrey and I will work on a
patch to PEP 7.

Thanks,
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[exarkun]

On 10:42 pm, fuzzy...@voidspace.org.uk wrote:

On 09/02/2010 21:57, Ben Finney wrote:

Michael Foord  writes:

The next 'big' change to unittest will (may?) be the introduction of
class and module level setUp and tearDown. This was discussed on
Python-ideas and Guido supported them. They can be useful but are 
also
very easy to abuse (too much shared state, monolithic test classes 
and

modules). Several authors of other Python testing frameworks spoke up
*against* them, but several *users* of test frameworks spoke up in
favour of them. ;-)

I think the perceived need for these is from people trying to use the
18unittest 19 API for test that are *not* unit tests.

That is, people have a need for integration tests (test this module's
interaction with some other module) or system tests (test the 
behaviour
of the whole running system). They then try to crowbar those tests 
into

18unittest 19 and finding it lacking, since  18unittest 19 is designed for
tests of function-level units, without persistent state between those
test cases.


I've used unittest for long running functional and integration tests 
(in both desktop and web applications). The infrastructure it provides 
is great for this. Don't get hung up on the fact that it is called 
unittest. In fact for many users the biggest reason it isn't suitable 
for tests like these is the lack of shared fixture support - which is 
why the other Python test frameworks provide them and we are going to 
bring it into unittest.


For what it's worth, we just finished *removing* support for setUpClass 
and tearDownClass from Trial.


Jean-Paul
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Antoine Pitrou]

Martin v. Löwis  v.loewis.de> writes:
> 
> IOW, I feel that release blockers should only be used if something
> really bad would happen that can be prevented by not releasing. If
> nothing actually gets worse by the release, the release shouldn't be
> blocked.

I think most blocking bugs we've had had been existing for a long time, but had
only been discovered or at least reported quite recently.
Other blockers were also about features not yet implemented, or missing
backports. So whether something would have "gone bad" is really in the eye of
the beholder :)

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 345 and PEP 386

[Guido van Rossum]

On Thu, Feb 4, 2010 at 2:55 PM, Tarek Ziadé  wrote:
> On Thu, Feb 4, 2010 at 8:20 PM, Guido van Rossum  wrote:
> [..]
>> I have one comment on PEP 345: Why is author-email mandatory? I'm sure
>> there are plenty of cases where either the author doesn't want their
>> email address published, or their last know email address is no longer
>> valid. (Tarek responded off-line that it isn't all that mandatory; I
>> propose to say so in the PEP.)
>
> Yes, I propose to remove the mandatory flag from that field.

Since this is done I now approve both PEP 345 and PEP 386 (which is
not to say that small editorial changes to the text couldn't be made).

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 345 and PEP 386

[Tarek Ziadé]

On Wed, Feb 10, 2010 at 12:29 AM, Guido van Rossum  wrote:
[..]
>
> Since this is done I now approve both PEP 345 and PEP 386 (which is
> not to say that small editorial changes to the text couldn't be made).

Thanks !

Thanks to all the people that helped in those PEPs

Tarek
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Request for review of issue 4037

[Steven D'Aprano]

Hello,

I have submitted a patch and a test script for issue 4037 on the bug 
tracker, "doctest.py should include method descriptors when looking 
inside a class __dict__"

http://bugs.python.org/issue4037

I would be grateful if somebody could review it please, and if suitable, 
commit it.

Thank you.



-- 
Steven D'Aprano
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PyCon is coming! Tomorrow, Feb. 10th is the last day for pre-conference rates

[VanL]

PyCon is coming! Tomorrow (February 10th) is the last day for
pre-conference rates. You can register for PyCon online at:



Register while it is still Feb. 10th somewhere in the world and rest
easy in the knowledge that within 10 days you will enjoying the company
of some of the finest Python hackers in the world.

As an additional bonus, PyCon this year will be in Atlanta, making it an
ideal location for those looking for a way to escape the late winter
blizzards in the northeastern United States, or the dreary fog of the
Bay area.

See you at PyCon 2010!

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 385 progress report

[Benjamin Peterson]

2010/2/9 Dirkjan Ochtman :
> On Tue, Feb 9, 2010 at 04:47, Benjamin Peterson  wrote:
>> I don't believe so. My plan was to manually sync updates or use subrepos.
>
> Using subrepos should work well for this.

Excellent.

>
> It turned out that my local copy of the Subversion repository
> contained the Python dir only, so I'm now syncing a full copy so that
> I can convert other parts. I believe 2to3 might be a little tricky
> because it was moved at some point, but I can look at getting that
> right (and this will help in converting other parts of the larger
> Python repository).

What do you mean by moved? I don't it has ever moved around in the sandbox.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
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: shortDescription, _TextTestResult and other issues

[Ben Finney]

Michael Foord  writes:

> On 09/02/2010 21:50, Ben Finney wrote:
> > I understood the point of ‘TestCase.shortDescription’, and indeed
> > the point of that particular name, was to be clear that some *other*
> > text could be the short description for the test case. Indeed, this
> > is what you've come up with: a different implementation for
> > generating a short description.
>
> Given that the change broke something, and the desired effect can be
> gained with a different change, I don't really see a downside to the
> change I'm proposing (reverting shortDescription and moving the code
> that adds the test name to TestResult).

What you describe (adding the class and method name when reporting
the test) sounds like it belongs in the TestRunner, since it's more a
case of “give me more information about the test result”.

That is, a TestRunner that reports each result *with* the extra
information would be useful, for some cases, but should not modify the
TestResult instance to do that.

Am I right that this approach would avoid breakage in the case of
frameworks that don't expect their TestRunner to behave that way? e.g.
Twisted could simply use the TestRunner that doesn't behave this way,
and (since the TestResult instances aren't any different) continue to
get the expected behaviour.

-- 
 \ “If nothing changes, everything will remain the same.” —Barne's |
  `\   Law |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] setUpClass and setUpModule in unittest

[Ben Finney]

Michael Foord  writes:

> I've used unittest for long running functional and integration tests
> (in both desktop and web applications). The infrastructure it provides
> is great for this. Don't get hung up on the fact that it is called
> unittest. In fact for many users the biggest reason it isn't suitable
> for tests like these is the lack of shared fixture support - which is
> why the other Python test frameworks provide them and we are going to
> bring it into unittest.

I would argue that one of the things that makes ‘unittest’ good is that
it makes it difficult to do the wrong thing — or at least *this* wrong
thing. Fixtures persist for the lifetime of a single test case, and no
more; that's the way unit tests should work.

Making the distinction clearer by using a different API (and *not*
extending the ‘unittest’ API) seems to be the right way to go.

-- 
 \ “I object to doing things that computers can do.” —Olin Shivers |
  `\   |
_o__)  |
Ben Finney

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Martin v. Löwis]

Antoine Pitrou wrote:
> Martin v. Löwis  v.loewis.de> writes:
>> IOW, I feel that release blockers should only be used if something
>> really bad would happen that can be prevented by not releasing. If
>> nothing actually gets worse by the release, the release shouldn't be
>> blocked.
> 
> I think most blocking bugs we've had had been existing for a long time, but 
> had
> only been discovered or at least reported quite recently.
> Other blockers were also about features not yet implemented, or missing
> backports. So whether something would have "gone bad" is really in the eye of
> the beholder :)

Maybe I'm being pedantic, but I really think there should be more
objective criteria for such things. We could set a policy that we don't
want to release Python if there are known ways of crashing it, but I
think that would be useless as it would mean that we can't make any
releases for the next five years or so (because we all know of ways of
crashing the VM that aren't fixed yet; when I run out of ideas, I just
ask Armin Rigo :-).

So the policy that I would suggest to follow instead is that known
crashes (and other "serious" bugs, like incompatibilities, or failures
to build) can block releases only if they are regressions, or if the
release manager decides to make them release blockers.

In particular, I think that requests for blocking a release should be
accompanies with a promise from a committer to resolve the issue by some
point in time. When that point has passed with the issue unresolved, the
release manager should be free to unblock the release.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Barry Warsaw]

On Feb 9, 2010, at 4:55 PM, Martin v. Löwis wrote:

>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>> one - http://bugs.python.org/issue6608  Is it ok to release new versions
>>> that are known to crash?
>> 
>> I've changed this issue to release blocker. What are the other issues?
> 
> For a bug fix release, it should (IMO) be a release blocker *only* if
> this is a regression in the branch or some recent bug fix release over
> some earlier bug fix release.
> 
> E.g. if 2.6.2 had broken something that worked in 2.6.1, it would be ok
> to delay 2.6.5. If 2.6.2 breaks in a case where all prior releases also
> broke, it would NOT be ok, IMO, to block 2.6.5 for that. There can
> always be a 2.6.6 release.
> 
> Of course, if this gets fixed before the scheduled release of 2.6.5,
> anyway, that would be nice.

I completely agree.  

Besides, unless we have volunteers to step up, create, review, and apply 
patches, it makes no sense to hold up releases.  In the case of the first 
posted bug, we need a Windows core developer to test, bless and apply the patch.

-Barry

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Barry Warsaw]

On Feb 9, 2010, at 5:20 PM, Martin v. Löwis wrote:

> Of course, the release manager can always declare anything a release
> blocker, so that may have been the reason (I don't recall the details).

I should probably clarify my last statement.  I will sometimes mark an issue 
"release blocker" because I'd really like it to be fixed for the next point 
release, or because we're very close to having an applicable patch.  Think of 
it more as a reminder to address the issue before the next release is created.  
However, I have also knocked issues down from blocker if it's clear that we 
won't have a fix in time, and it meets the other criteria that Martin has laid 
out.

So feel free to mark issues as release blockers for 2.6.5.  That doesn't mean 
it will actually block the release.

-Barry

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[anatoly techtonik]

On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis"  wrote:
>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
>>> I've noticed a couple of issues that 100% crash Python 2.6.4 like this
>>> one - http://bugs.python.org/issue6608  Is it ok to release new versions
>>> that are known to crash?
>>
>> I've changed this issue to release blocker. What are the other issues?
>
> For a bug fix release, it should (IMO) be a release blocker *only* if
> this is a regression in the branch or some recent bug fix release over
> some earlier bug fix release.

Is it possible to make exploits out of crashers?

-- 
anatoly t.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Raymond Hettinger]

On Feb 9, 2010, at 9:54 PM, anatoly techtonik wrote:
> 
> Is it possible to make exploits out of crashers?

The crashers involve creating convoluted python code,
but then if you're in a position to execute arbitrary
Python code, then you don't have to resort to any
tricks to do something nasty within the scope of
your user permissions.

Raymond
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Martin v. Löwis]

> On Tue, Feb 9, 2010 at 11:55 PM, "Martin v. Löwis"  wrote:
>>> Le Tue, 09 Feb 2010 12:16:15 +0200, anatoly techtonik a écrit :
 I've noticed a couple of issues that 100% crash Python 2.6.4 like this
 one - http://bugs.python.org/issue6608  Is it ok to release new versions
 that are known to crash?
>>> I've changed this issue to release blocker. What are the other issues?
>> For a bug fix release, it should (IMO) be a release blocker *only* if
>> this is a regression in the branch or some recent bug fix release over
>> some earlier bug fix release.
> 
> Is it possible to make exploits out of crashers?

It depends on the specific crasher. In Python, it depends on the
application as well. In the specific issue you mentioned, it doesn't
crash because of a memory overwrite, but because of a deliberate process
shutdown in the C runtime. So you can't construct arbitrary code
execution out of that.

Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Antoine Pitrou]

anatoly techtonik  gmail.com> writes:
> 
> Is it possible to make exploits out of crashers?

It depends which ones. If it's something like a buffer overflow or a memory
management problem, it may be possible to exploit it through carefully crafted
input (in order to make the interpreter execute arbitrary machine code). A
security expert would be able to shed more light on this.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Python 2.6.5

[Antoine Pitrou]

Le mercredi 10 février 2010 à 05:26 +0100, "Martin v. Löwis" a écrit :
> 
> Maybe I'm being pedantic, but I really think there should be more
> objective criteria for such things.

Well we could try to find objective criteria but I'm not sure we'll find
agreement on them.

>  We could set a policy that we don't
> want to release Python if there are known ways of crashing it, but I
> think that would be useless as it would mean that we can't make any
> releases for the next five years or so

It really boils down to what kind of crasher it is.
When it is triggered by giving 24 instead of 23 as an argument to
time.asctime() (i.e. a simple off-by-one error), it is more severe than
a crasher which can only be triggered through artificially convoluted
code.

> So the policy that I would suggest to follow instead is that known
> crashes (and other "serious" bugs, like incompatibilities, or failures
> to build) can block releases only if they are regressions, or if the
> release manager decides to make them release blockers.

I disagree with the idea that the severity of a bug is correlated with
it being a regression. If e.g. a critical security problem is found, it
has to be corrected even though it may have been present for 5 years in
the source.

Besides, as Barry said, classifying a bug as blocker is also a good way
to attract some attention on it. Other classifications, even "critical",
don't have the same effect.

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com