Re: [Python-Dev] PEP 385 progress report

2010-02-12 Thread Georg Brandl 
Am 09.02.2010 04:47, schrieb Benjamin Peterson:
> 2010/2/8 "Martin v. Löwis" :
>> Benjamin Peterson wrote:
>>> 2010/2/8 Dirkjan Ochtman :
 On Sun, Feb 7, 2010 at 22:51, Benjamin Peterson  
 wrote:
> Will you do test conversions of the sandbox projects, too?
 Got any particular projects in mind?
>>>
>>> 2to3.
>>
>> Does Mercurial even support merge tracking the way we are doing it for
>> 2to3 right now?
> 
> I don't believe so. My plan was to manually sync updates or use subrepos.

Why even keep 2to3 in the sandbox?  It should be mature enough now to be
maintained directly in the tree.

Also, using a subrepo is fine for the Python 2 version, but what about the
Python 3 version?

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] PEP 385 progress report

2010-02-12 Thread Georg Brandl 
Am 09.02.2010 04:39, schrieb "Martin v. Löwis":
> Benjamin Peterson wrote:
>> 2010/2/8 Dirkjan Ochtman :
>>> On Sun, Feb 7, 2010 at 22:51, Benjamin Peterson  wrote:
 Will you do test conversions of the sandbox projects, too?
>>> Got any particular projects in mind?
>> 
>> 2to3.
> 
> Does Mercurial even support merge tracking the way we are doing it for
> 2to3 right now?

No, it does not.  This is also a concern for the Python 2 -> Python 3 merging,
where (I think) we decided not to have shared history.  Transplant already
does most of the job (including recording the source hash of transplanted
changesets), but it lacks blocking and consistent rejection of already-merged
changesets (it does not read the source hashes it records, but keeps a local
cache of such hashes instead, which obviously doesn't do anything across
repositories.)  I think it should be possible to have transplant regenerate
and update that cache automatically on clone/pull/etc.

I guess this is a relatively simple task for a Mercurial hacker, and if it's
decided to use this workflow "someone" ;) could address it at the PyCon sprint.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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] PEP 385 progress report

2010-02-12 Thread Dirkjan Ochtman 
On Fri, Feb 12, 2010 at 09:39, Georg Brandl  wrote:
> No, it does not.  This is also a concern for the Python 2 -> Python 3 merging,
> where (I think) we decided not to have shared history.  Transplant already

I don't think this is similar to 2 vs. 3, because 2 vs. 3 are full
branching (so you could still use "normal" hg merge tracking there).
Since hg doesn't do merge tracking on the directory level, you
couldn't use Mercurial merges (or transplant, AFAICS) to do what you
want here.

> does most of the job (including recording the source hash of transplanted
> changesets), but it lacks blocking and consistent rejection of already-merged
> changesets (it does not read the source hashes it records, but keeps a local
> cache of such hashes instead, which obviously doesn't do anything across
> repositories.)  I think it should be possible to have transplant regenerate
> and update that cache automatically on clone/pull/etc.
>
> I guess this is a relatively simple task for a Mercurial hacker, and if it's
> decided to use this workflow "someone" ;) could address it at the PyCon 
> sprint.

Yes, we should figure out some workflow issues soon.

Cheers,

Dirkjan
___
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] setUpClass and setUpModule in unittest

2010-02-12 Thread Nick Coghlan 
R. David Murray wrote:
> would be easier to write, be more maintainable, and be easier to
> understand when reading the code than the equivalent setUp and tearDown
> methods would be.
> 
> I'm not saying it would be easy to implement, and as you say backward
> compatibility is a key concern.

That's the gist of my thinking, yeah.

However, a couple of problems of note that occurred to me after an extra
day or so of musing on the topic:
- the semantics I listed in my original post are broken, since a naive
context manager couldn't be used (it would setup and tear down the
resources for each test instance, which is what we're trying to avoid).
Supporting naive context managers would require iterating over the test
classes within the module CM and iterating over the instances within the
class CM.
- context managers fit best in more procedural code. They're tricky to
invoke correctly from code that is split across several methods in
different classes (as I believe unittest is), since you can't use a with
statement directly to do the invocation for you

So I think new setup*/teardown* methods and functions are likely to be a
better fit for the unittest architecture. At a later date, it may be
worth adding some mixins or other mechanisms that adapt from the
unittest setup/teardown model to a CM based model, but to be honest, if
I want to use a CM when testing, I'll generally create a more complex
test method that iterates through a bunch of test inputs itself.

Cheers,
Nick.

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

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

2010-02-12 Thread Nick Coghlan 
Holger Krekel wrote:
> In my experience, integration and
> functional testing is a  complex and evolving topic, usually requiring
> more from the tool or framework than classic unit-testing.

Assignment for the reader: compare and contrast unittest and
test.regrtest (including test.support and friends) :)

Yes, you need extra stuff to do higher level testing, but in many
instances unittest still makes a nice framework to hang it on.

Cheers,
Nick.

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

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

2010-02-12 Thread Olemis Lang 
On Tue, Feb 9, 2010 at 2:04 PM, Michael Foord  wrote:
> 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.

+1

> 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.
>

I really disagree. IMO I am -1 for having `addCleanUp` and so on added
to the core API (i.e. `TestCase` class). The same goes for test
resources (especially if that means to merge it with the API rather
than including it as a separate independent module). The use cases for
that feature are not, in general, basic use cases ('cause if they were
*simple*, setUp/tearDown would be a *simple* alternative to do the
same thing ;o).

I repeat that my opinion is that I am -1 for including each and every
feature needed for testing purposes jus because it's very (super)
useful to solve even many use cases (e.g. context managers, by
themselves, are an empty and abstract construct that solve a set of
problems *once they are implemented*, but the top-level abstractions
are not directly useful by themselves). It's an API. In JUnit there
are a lot of useful extensions implemented in `junit-ext` package &
Co. (and AFAICR that also includes integration testing & test
resources) and besides there are some other important features in
JUnit>=4.7 itself, *but not hard coded in TestCase* (e.g.
`org.junit.rules.ExternalResource`, ...) and also allowing extensions
(e.g. `org.junit.rules.TemporaryFolder`) using well established
mechanisms (e.g. inheritance) . This also has the benefit that the
responsibilities are distributed to a set of relevant objects
following well-known interaction patterns, rather than cluttering a
class with all sort of functionalities .

PS: I say this and I know that it's quite unlikely that you will
reconsider it in order to revert what's being done there . But, if we
take a look to JUnit>=4.7, just notice that resource management is not
an integral part of `TestCase` at all, and is performed in a more
structured way, consistent with the «standard» or officially supported
mechanism used to add any other extension to JUnit . Honestly I can
obviously see the differences with respect to `addCleanUp`
implementation as we know it today.

-- 
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
[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] setUpClass and setUpModule in unittest

2010-02-12 Thread Michael Foord 

On 11/02/2010 18:11, Guido van Rossum wrote:

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

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).

[snip...]
   
The potential for abuse in and of itself should not be an argument

against a feature; it must always be weighed against the advantages.
   


The advantage of setUpClass and setUpModule is that they allow you to 
have shared fixtures shared between tests, essential for certain kinds 
of testing. A practical difficulty with setUpClass and setUpModule is 
that because the scope of the shared fixtures is fixed it makes it much 
harder to later refactor your tests - either into several classes or 
into several modules - when the tests grow.


My *hope* is that we provide a general solution, possibly based on all 
or part of Test Resources, with an easy mechanism for the setUpClass and 
setUpModule but also solves the more general case of sharing fixtures 
between tests. If that doesn't turn out to be possible then we'll go for 
a straight implementation of setUpClass / setUpModule. I'm hoping I can 
get this together in time for the PyCon sprints...


Here's a current minimal example of using Test Resources. It could be 
simplified further with helper functions and by some of the 
functionality moving into unittest itself. OptimisingTestSuite here 
ensures that the resource is created before first use (MyTempDir.make is 
called) and disposed of when finished with (MyTempDir.clean is called).


import shutil
import tempfile
import testresources

def load_tests(loader, tests, pattern):
# this step could be built into the standard loader
return testresources.OptimisingTestSuite(tests)

class MyTempDir(testresources.TestResource):
def make(self, dependency_resources):
return tempfile.mkdtemp()

def clean(self, resource):
shutil.rmtree(resource)

class MyTest(testresources.ResourcedTestCase):
resources = [('workdir', MyTempDir())]
def test_foo(self):
print self.workdir
def test_bar(self):
print self.workdir


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
[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] Summary of Python tracker Issues

2010-02-12 Thread Python tracker 

ACTIVITY SUMMARY (02/05/10 - 02/12/10)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2602 open (+33) / 17137 closed (+25) / 19739 total (+58)

Open issues with patches:  1069

Average duration of open issues: 712 days.
Median duration of open issues: 466 days.

Open Issues Breakdown
   open  2567 (+33)
pending34 ( +0)

Issues Created Or Reopened (59)
___

support "with self.assertRaises(SomeException) as exc:" syntax   02/07/10
CLOSED http://bugs.python.org/issue7859reopened flox
  
   

32-bit Python on 64-bit Windows reports incorrect architecture   02/05/10
   http://bugs.python.org/issue7860created  brian.curtin
  
   patch, patch, needs review  

2to3: "import foo" ->  "from . import foo"   02/05/10
CLOSED http://bugs.python.org/issue7861created  tomspur 
  
   

fileio.c: ValueError vs. IOError with impossible operations  02/05/10
   http://bugs.python.org/issue7862created  skrah   
  
   

platform module doesn't detect Windows 7 02/05/10
   http://bugs.python.org/issue7863created  adal
  
   patch, needs review 

Deprecation markers in unittest docs are unclear 02/06/10
CLOSED http://bugs.python.org/issue7864created  Justin.Lebar
  
   

io close() swallowing exceptions 02/06/10
   http://bugs.python.org/issue7865created  pakal   
  
   

it looks like a typo in unittest 02/06/10
CLOSED http://bugs.python.org/issue7866created  artech  
  
   

Proposed FAQ entry on pass-by-? semantics and the meaning of 'va 02/06/10
   http://bugs.python.org/issue7867created  r.david.murray  
  
   

add a loggerClass attribute to Manager   02/06/10
CLOSED http://bugs.python.org/issue7868created  georg.brandl
  
   patch, patch, easy  

traceback from logging is unusable.  02/07/10
CLOSED http://bugs.python.org/issue7869created  naoki   
  
   patch   

Duplicate test methods in test_memoryio  02/07/10
CLOSED http://bugs.python.org/issue7870created  georg.brandl
  
   

Duplicate test method in test_heapq  02/07/10
   http://bugs.python.org/issue7871created  georg.brandl
  
   

Incorrect error raised on importing invalid module via unittest  02/07/10
CLOSED http://bugs.python.org/issue7872created  Daniel.Waterworth   
  
   

Remove precision restriction for integer formatting. 02/07/10
   http://bugs.python.org/issue7873created  mark.dickinson  
  
   easy

logging.basicConfig should raise warning/exception on second cal 02/07/10
CLOSED http://bugs.python.org/issue7874created  tocomo  
  
   

test_multiprocessing / importlib failure 02/07/10
   http://bugs.python.org/issue7875created  pitrou  
  
   buildbot

unittest docs use deprecated method in code example  02/07/10
CLOSED http://bugs.python.org/issue7876created  Bernt.Røskar.Brenna
  
   

Iterators over _winreg EnumKey and EnumValue results 02/07/10
   http://bugs.python.org/issue7877created  brian.curtin
  
   patch, patch, needs review

Re: [Python-Dev] PEP 385 progress report

2010-02-12 Thread Martin v. Löwis 
> Why even keep 2to3 in the sandbox?  It should be mature enough now to be
> maintained directly in the tree.

I think the original plan was to make standalone releases, so that
people could upgrade their installation from a newer release of 2to3.

IMO, it is realistic to predict that this will not actually happen. If
we can agree to give up the 2to3 sandbox, we should incorporate
find_pattern into the tree, and perhaps test.py as well.

Regards,
Martin

___
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] PEP 385 progress report

2010-02-12 Thread Brett Cannon 
On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis"  wrote:
>> Why even keep 2to3 in the sandbox?  It should be mature enough now to be
>> maintained directly in the tree.
>
> I think the original plan was to make standalone releases, so that
> people could upgrade their installation from a newer release of 2to3.
>

That's what I remember as well.

> IMO, it is realistic to predict that this will not actually happen. If
> we can agree to give up the 2to3 sandbox, we should incorporate
> find_pattern into the tree, and perhaps test.py as well.

I vote on giving up the 2to3 sandbox.

-Brett
___
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] setUpClass and setUpModule in unittest

2010-02-12 Thread Guido van Rossum 
On Fri, Feb 12, 2010 at 7:49 AM, Michael Foord
 wrote:
> My *hope* is that we provide a general solution, possibly based on all or
> part of Test Resources, with an easy mechanism for the setUpClass and
> setUpModule but also solves the more general case of sharing fixtures
> between tests. If that doesn't turn out to be possible then we'll go for a
> straight implementation of setUpClass / setUpModule. I'm hoping I can get
> this together in time for the PyCon sprints...

Do you have a reference for Test Resources?

> Here's a current minimal example of using Test Resources. It could be
> simplified further with helper functions and by some of the functionality
> moving into unittest itself. OptimisingTestSuite here ensures that the
> resource is created before first use (MyTempDir.make is called) and disposed
> of when finished with (MyTempDir.clean is called).
>
> import shutil
> import tempfile
> import testresources
>
> def load_tests(loader, tests, pattern):
> # this step could be built into the standard loader
> return testresources.OptimisingTestSuite(tests)
>
> class MyTempDir(testresources.TestResource):
> def make(self, dependency_resources):
> return tempfile.mkdtemp()
>
> def clean(self, resource):
> shutil.rmtree(resource)
>
> class MyTest(testresources.ResourcedTestCase):
> resources = [('workdir', MyTempDir())]
> def test_foo(self):
> print self.workdir
> def test_bar(self):
> print self.workdir

This came out with all leading indentation removed, but I think I can
guess what you meant to write.

However from this example I *cannot* guess whether those resources are
set up and torn down per test or per test class. Also the notation

  resources = [('workdir', MyTempDir())]

looks pretty ugly -- if 'workdir' ends up being an instance attribute,
why not make it a dict instead of a list of tuples? Or even better, a
could each resource become a class variable?

-- 
--Guido van Rossum (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] setUpClass and setUpModule in unittest

2010-02-12 Thread exarkun 

On 07:48 pm, [email protected] wrote:

On Fri, Feb 12, 2010 at 7:49 AM, Michael Foord
 wrote:
My *hope* is that we provide a general solution, possibly based on all 
or

part of Test Resources, with an easy mechanism for the setUpClass and
setUpModule but also solves the more general case of sharing fixtures
between tests. If that doesn't turn out to be possible then we'll go 
for a
straight implementation of setUpClass / setUpModule. I'm hoping I can 
get

this together in time for the PyCon sprints...


Do you have a reference for Test Resources?


http://pypi.python.org/pypi/testresources/0.2.2

[snip]

However from this example I *cannot* guess whether those resources are
set up and torn down per test or per test class. Also the notation


The idea is that you're declaring what the tests need in order to work. 
You're not explicitly defining the order in which things are set up and 
torn down.  That is left up to another part of the library to determine.


One such other part, OptimisingTestSuite, will look at *all* of your 
tests and find an order which involves the least redundant effort.


You might have something else that breaks up the test run across 
multiple processes and uses the resource declarations to run all tests 
requiring one thing in one process and all tests requiring another thing 
somewhere else.


You might have still something else that wants to completely randomize 
the order of tests, and sets up all the resources at the beginning and 
tears them down at the end.  Or you might need to be more 
memory/whatever conscious than that, and do each set up and tear down 
around each test.


The really nice thing here is that you're not constrained in how you 
group your tests into classes and modules by what resources you want to 
use in them.  You're free to group them by what they're logically 
testing, or in whatever other way you wish.


Jean-Paul
___
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] setUpClass and setUpModule in unittest

2010-02-12 Thread Guido van Rossum 
On Fri, Feb 12, 2010 at 12:20 PM,   wrote:
> The idea is that you're declaring what the tests need in order to work.
> You're not explicitly defining the order in which things are set up and torn
> down.  That is left up to another part of the library to determine.
>
> One such other part, OptimisingTestSuite, will look at *all* of your tests
> and find an order which involves the least redundant effort.

So is there a way to associate a "cost" with a resource? I may have
one resource which is simply a /tmp subdirectory (very cheap) and
another that requires starting a database service (very expensive).

> You might have something else that breaks up the test run across multiple
> processes and uses the resource declarations to run all tests requiring one
> thing in one process and all tests requiring another thing somewhere else.

I admire the approach, though I am skeptical. We have a thing to split
up tests at Google which looks at past running times for tests to make
an informed opinion. Have you thought of that?

> You might have still something else that wants to completely randomize the
> order of tests, and sets up all the resources at the beginning and tears
> them down at the end.  Or you might need to be more memory/whatever
> conscious than that, and do each set up and tear down around each test.

How does your code know the constraints?

> The really nice thing here is that you're not constrained in how you group
> your tests into classes and modules by what resources you want to use in
> them.  You're free to group them by what they're logically testing, or in
> whatever other way you wish.

I guess this requires some trust in the system. :-)

-- 
--Guido van Rossum (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] setUpClass and setUpModule in unittest

2010-02-12 Thread Ben Finney 
Michael Foord  writes:

> The advantage of setUpClass and setUpModule is that they allow you to
> have shared fixtures shared between tests, essential for certain kinds
> of testing. […]

Yes, this would be very useful for non-unit tests.

> My *hope* is that we provide a general solution, possibly based on all
> or part of Test Resources, with an easy mechanism for the setUpClass
> and setUpModule but also solves the more general case of sharing
> fixtures between tests.

+1 for having these in a more general “testing API”, with the ‘unittest’
API a special case that does *not* share fixtures between tests.

-- 
 \   “Following fashion and the status quo is easy. Thinking about |
  `\your users' lives and creating something practical is much |
_o__)harder.” —Ryan Singer, 2008-07-09 |
Ben Finney

___
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] setUpClass and setUpModule in unittest

2010-02-12 Thread exarkun 

On 08:27 pm, [email protected] wrote:

On Fri, Feb 12, 2010 at 12:20 PM,   wrote:
The idea is that you're declaring what the tests need in order to 
work.
You're not explicitly defining the order in which things are set up 
and torn

down. �That is left up to another part of the library to determine.

One such other part, OptimisingTestSuite, will look at *all* of your 
tests

and find an order which involves the least redundant effort.


So is there a way to associate a "cost" with a resource? I may have
one resource which is simply a /tmp subdirectory (very cheap) and
another that requires starting a database service (very expensive).


I don't think so.  From the docs, "This TestSuite will introspect all 
the test cases it holds directly and if they declare needed resources, 
will run the tests in an order that attempts to minimise the number of 
setup and tear downs required.".


You might have something else that breaks up the test run across 
multiple
processes and uses the resource declarations to run all tests 
requiring one
thing in one process and all tests requiring another thing somewhere 
else.


I admire the approach, though I am skeptical. We have a thing to split
up tests at Google which looks at past running times for tests to make
an informed opinion. Have you thought of that?
You might have still something else that wants to completely randomize 
the
order of tests, and sets up all the resources at the beginning and 
tears

them down at the end.  Or you might need to be more memory/whatever
conscious than that, and do each set up and tear down around each 
test.


How does your code know the constraints?


To be clear, aside from OptimisingTestSuite, I don't think testresources 
implements any of the features I talked about.  They're just things one 
might want to and be able to implement, given a test suite which uses 
testresources.


The really nice thing here is that you're not constrained in how you 
group
your tests into classes and modules by what resources you want to use 
in
them.  You're free to group them by what they're logically testing, or 
in

whatever other way you wish.


I guess this requires some trust in the system. :-)


Jean-Paul
___
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] PEP 3146: Merge Unladen Swallow into CPython

2010-02-12 Thread Collin Winter 
Hey Maciej,

On Thu, Feb 11, 2010 at 6:39 AM, Maciej Fijalkowski  wrote:
> Snippet from:
>
> http://codereview.appspot.com/186247/diff2/5014:8003/7002
>
> *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is
> slower than Unladen Swallow on non-numerical workloads. PyPy only
> supports 32-bit x86 code generation. It has poor support for CPython
> extension modules, making migration for large applications
> prohibitively expensive.
>
> That part at the very least has some sort of personal opinion
> "prohibitively",

Of course; difficulty is always in the eye of the person doing the
work. Simply put, PyPy is not a drop-in replacement for CPython: there
is no embedding API, much less the same one exported by CPython;
important libraries, such as MySQLdb and pycrypto, do not build
against PyPy; PyPy is 32-bit x86 only.

All of these problems can be overcome with enough time/effort/money,
but I think you'd agree that, if all I'm trying to do is speed up my
application, adding a new x86-64 backend or implementing support for
CPython extension modules is certainly north of "prohibitively
expensive". I stand by that wording. I'm willing to enumerate all of
PyPy's deficiencies in this regard in the PEP, rather than the current
vaguer wording, if you'd prefer.

> while the other part is not completely true "slower
> than US on non-numerical workloads". Fancy providing a proof for that?
> I'm well aware that there are benchmarks on which PyPy is slower than
> CPython or US, however, I would like a bit more weighted opinion in
> the PEP.

Based on the benchmarks you're running at
http://codespeak.net:8099/plotsummary.html, PyPy is slower than
CPython on many non-numerical workloads, which Unladen Swallow is
faster than CPython at. Looking at the benchmarks there at which PyPy
is faster than CPython, they are primarily numerical; this was the
basis for the wording in the PEP.

My own recent benchmarking of PyPy and Unladen Swallow (both trunk;
PyPy wouldn't run some benchmarks):

| Benchmark| PyPy  | Unladen | Change  |
+==+===+=+=+
| ai   | 0.61  | 0.51|  1.1921x faster |
| django   | 0.68  | 0.8 |  1.1898x slower |
| float| 0.03  | 0.07|  2.7108x slower |
| html5lib | 20.04 | 16.42   |  1.2201x faster |
| pickle   | 17.7  | 1.09| 16.2465x faster |
| rietveld | 1.09  | 0.59|  1.8597x faster |
| slowpickle   | 0.43  | 0.56|  1.2956x slower |
| slowspitfire | 2.5   | 0.63|  3.9853x faster |
| slowunpickle | 0.26  | 0.27|  1.0585x slower |
| unpickle | 28.45 | 0.78| 36.6427x faster |

I'm happy to change the wording to "slower than US on some workloads".

Thanks,
Collin Winter
___
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] setUpClass and setUpModule in unittest

2010-02-12 Thread Michael Foord 

On 12/02/2010 19:48, Guido van Rossum wrote:

[snip...]

Here's a current minimal example of using Test Resources. It could be
simplified further with helper functions and by some of the functionality
moving into unittest itself. OptimisingTestSuite here ensures that the
resource is created before first use (MyTempDir.make is called) and disposed
of when finished with (MyTempDir.clean is called).

import shutil
import tempfile
import testresources

def load_tests(loader, tests, pattern):
# this step could be built into the standard loader
return testresources.OptimisingTestSuite(tests)

class MyTempDir(testresources.TestResource):
def make(self, dependency_resources):
return tempfile.mkdtemp()

def clean(self, resource):
shutil.rmtree(resource)

class MyTest(testresources.ResourcedTestCase):
resources = [('workdir', MyTempDir())]
def test_foo(self):
print self.workdir
def test_bar(self):
print self.workdir
 

This came out with all leading indentation removed, but I think I can
guess what you meant to write.
   

For goodness sake. Sorry about that.


However from this example I *cannot* guess whether those resources are
set up and torn down per test or per test class.
This particular example is the equivalent of setUpClass - so by 
declaring the resource as a class attribute it will created before the 
first test for the class is run and disposed of after the last test for 
the class.


You could *also* create a single resource and share it between several 
test classes, or even across classes in several modules, and have it 
created and disposed of at the right point. I've copied Rob Collins in 
on this email in case I've misunderstood.

Also the notation

   resources = [('workdir', MyTempDir())]

looks pretty ugly -- if 'workdir' ends up being an instance attribute,
why not make it a dict instead of a list of tuples? Or even better, a
could each resource become a class variable?

   
I guess we could introspect the class for every attribute that is a 
resource, but I prefer some way of explicitly declaring which resources 
a TestCase is using.


Michael Foord

--
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
[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] PEP 3146: Merge Unladen Swallow into CPython

2010-02-12 Thread Nick Coghlan 
Collin Winter wrote:
> Hey Maciej,
> 
> On Thu, Feb 11, 2010 at 6:39 AM, Maciej Fijalkowski  wrote:
>> Snippet from:
>>
>> http://codereview.appspot.com/186247/diff2/5014:8003/7002
>>
>> *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is
>> slower than Unladen Swallow on non-numerical workloads. PyPy only
>> supports 32-bit x86 code generation. It has poor support for CPython
>> extension modules, making migration for large applications
>> prohibitively expensive.
>>
>> That part at the very least has some sort of personal opinion
>> "prohibitively",
> 
> Of course; difficulty is always in the eye of the person doing the
> work. Simply put, PyPy is not a drop-in replacement for CPython: there
> is no embedding API, much less the same one exported by CPython;
> important libraries, such as MySQLdb and pycrypto, do not build
> against PyPy; PyPy is 32-bit x86 only.

I think pointing out at least these two restrictions explicitly would be
helpful (since they put some objective bounds on the meaning of
"prohibitive" in this context).

Cheers,
Nick.

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

Re: [Python-Dev] PEP 385 progress report

2010-02-12 Thread Nick Coghlan 
Brett Cannon wrote:
> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis"  wrote:
>> IMO, it is realistic to predict that this will not actually happen. If
>> we can agree to give up the 2to3 sandbox, we should incorporate
>> find_pattern into the tree, and perhaps test.py as well.
> 
> I vote on giving up the 2to3 sandbox.

Besides, if we're using hg, it should make it much easier for someone
else to branch that part of the stdlib and create a standalone 2to3
release from it if they really want to.

Cheers,
Nick.

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

Re: [Python-Dev] PEP 385 progress report

2010-02-12 Thread Nick Coghlan 
Brett Cannon wrote:
> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis"  wrote:
> I vote on giving up the 2to3 sandbox.

One other point - is there a Python 2.6 backwards compatibility
restriction on 2to3 at the moment? If there isn't, should there be?

Cheers,
Nick.

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

Re: [Python-Dev] PEP 385 progress report

2010-02-12 Thread Benjamin Peterson 
2010/2/12 Nick Coghlan :
> Brett Cannon wrote:
>> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis"  wrote:
>>> IMO, it is realistic to predict that this will not actually happen. If
>>> we can agree to give up the 2to3 sandbox, we should incorporate
>>> find_pattern into the tree, and perhaps test.py as well.
>>
>> I vote on giving up the 2to3 sandbox.
>
> Besides, if we're using hg, it should make it much easier for someone
> else to branch that part of the stdlib and create a standalone 2to3
> release from it if they really want to.

I personally like 2to3 in a separate repo because it fits well with my
view that 2to3 is an extra application that happens to also be
distributed with python.



-- 
Regards,
Benjamin
___
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] PEP 385 progress report

2010-02-12 Thread Benjamin Peterson 
2010/2/12 Nick Coghlan :
> Brett Cannon wrote:
>> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis"  wrote:
>> I vote on giving up the 2to3 sandbox.
>
> One other point - is there a Python 2.6 backwards compatibility
> restriction on 2to3 at the moment? If there isn't, should there be?

I try to keep it compatible with 2.6, since we have to backport changes.



-- 
Regards,
Benjamin
___
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] PEP 385 progress report

2010-02-12 Thread Nick Coghlan 
Benjamin Peterson wrote:
> 2010/2/12 Nick Coghlan :
>> Brett Cannon wrote:
>>> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis"  wrote:
>>> I vote on giving up the 2to3 sandbox.
>> One other point - is there a Python 2.6 backwards compatibility
>> restriction on 2to3 at the moment? If there isn't, should there be?
> 
> I try to keep it compatible with 2.6, since we have to backport changes.

With 2.7 just around the corner, it should probably be listed in PEP 291
on that basis.

Of course, PEP 291 could do with a list of 2.5 and 2.6 specific features
first...

Cheers,
Nick.

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

Re: [Python-Dev] PEP 385 progress report

2010-02-12 Thread Benjamin Peterson 
2010/2/12 Nick Coghlan :
> Benjamin Peterson wrote:
>> 2010/2/12 Nick Coghlan :
>>> Brett Cannon wrote:
 On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis"  
 wrote:
 I vote on giving up the 2to3 sandbox.
>>> One other point - is there a Python 2.6 backwards compatibility
>>> restriction on 2to3 at the moment? If there isn't, should there be?
>>
>> I try to keep it compatible with 2.6, since we have to backport changes.
>
> With 2.7 just around the corner, it should probably be listed in PEP 291
> on that basis.

Done.

>
> Of course, PEP 291 could do with a list of 2.5 and 2.6 specific features
> first...

I think that section is rather pointless to keep updated, since a good
list can be found in the what's new documents. What people really need
to do is run the unittests on all supported versions.



-- 
Regards,
Benjamin
___
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] 3.1.2

2010-02-12 Thread Benjamin Peterson 
It's about time for another 3.1 bug fix release. I propose this schedule:

March 6: Release Candidate (same day as 2.7a4)
March 20:  3.1.2 Final release


-- 
Regards,
Benjamin
___
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] setUpClass and setUpModule in unittest

2010-02-12 Thread Glyph Lefkowitz 
On Feb 11, 2010, at 1:11 PM, Guido van Rossum wrote:

> I have skimmed this thread (hence this reply to the first rather than
> the last message), but in general I am baffled by the hostility of
> testing framework developers towards their users. The arguments
> against class- and module-level seUp/tearDown functions seems to be
> inspired by religion or ideology more than by the zen of Python. What
> happened to Practicality Beats Purity?

My sentiments tend to echo Jean-Paul Calderone's in this regard, but I think 
what he's saying bears a lot of repeating.  We really screwed up this feature 
in Twisted and I'd like to make sure that the stdlib doesn't repeat the 
mistake.  (Granted, we screwed it up extra bad 
, but I do think many of the 
problems we encountered are inherent.)

The issue is not that we test-framework developers don't like our users, or 
want to protect them from themselves.  It is that our users - ourselves chief 
among them - desire features like "I want my tests to be transparently 
optimized across N cores and N disks".

I can understand how resistance to setUp/tearDown*Class/Module comes across as 
user-hostility, but I can assure you this is not the case.  It's subtle and 
difficult to explain how incompatible with these advanced features the 
*apparently* straightforward semantics of setting up and tearing down classes 
and modules.  Most questions of semantics can be resolved with a simple 
decision, and it's not clear how that would interfere with other features.

In Twisted's implementation of setUpClass and tearDownClass, everything seemed 
like it worked right up until the point where it didn't.  The test writer 
thinks that they're writing "simple" setUpClass and tearDownClass methods to 
optimize things, except almost by definition a setUpClass method needs to 
manipulate global state, shared across tests.  Which means that said state 
starts getting confused when it is set up and torn down concurrently across 
multiple processes.  These methods seem simple, but do they touch the 
filesystem?  Do they touch a shared database, even a little?  How do they 
determine a unique location to do that?  Without generally available tools to 
allow test writers to mess with the order and execution environment of their 
tests, one tends to write tests that rely on these implementation and ordering 
accidents, which means that when such a tool does arrive, things start breaking 
in unpredictable ways.

> The argument that a unittest framework shouldn't be "abused" for
> regression tests (or integration tests, or whatever) is also bizarre
> to my mind. Surely if a testing framework applies to multiple kinds of
> testing that's a good thing, not something to be frowned upon?

For what it's worth, I am a big fan of abusing test frameworks in generally, 
and pyunit specifically, to perform every possible kind of testing.  In fact, I 
find setUpClass more hostile to *other* kinds of testing, because this 
convenience for simple integration tests makes more involved, 
performance-intensive integration tests harder to write and manage.

> On the other hand, I think we should be careful to extend unittest in
> a consistent way. I shuddered at earlier proposals (on python-ideas)
> to name the new functions (variations of) set_up and tear_down "to
> conform with PEP 8" (this would actually have violated that PEP, which
> explicitly prefers local consistency over global consistency).

This is a very important point.  But, it's important not only to extend 
unittest itself in a consistent way, but to clearly describe the points of 
extensibility so that third-party things can continue to extend unittest 
themselves, and cooperate with each other using some defined protocol so that 
you can combine those tools.

I tried to write about this problem a while ago 
 - the current extensibility API (which 
is mostly just composing "run()") is sub-optimal in many ways, but it's 
important not to break it.

And setUpClass does inevitably start to break those integration points down, 
because it implies certain things, like the fact that classes and modules are 
suites, or are otherwise grouped together in test ordering.  This makes it 
difficult to create custom suites, to do custom ordering, custom per-test 
behavior (like metrics collection before and after run(), or gc.collect() after 
each test, or looking for newly-opened-but-not-cleaned-up external resources 
like file descriptors after each tearDown).

Again: these are all concrete features that *users* of test frameworks want, 
not just idle architectural fantasy of us framework hackers.

I haven't had the opportunity to read the entire thread, so I don't know if 
this discussion has come to fruition, but I can see that some attention has 
been paid to these difficulties.  I have no problem with setUpClass or 
tearDownClass hooks *per se*, as long as they can be impl

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

2010-02-12 Thread Maciej Fijalkowski 
On Fri, Feb 12, 2010 at 7:04 PM, Collin Winter  wrote:
> Hey Maciej,
>
> On Thu, Feb 11, 2010 at 6:39 AM, Maciej Fijalkowski  wrote:
>> Snippet from:
>>
>> http://codereview.appspot.com/186247/diff2/5014:8003/7002
>>
>> *PyPy*: PyPy [#pypy]_ has good performance on numerical code, but is
>> slower than Unladen Swallow on non-numerical workloads. PyPy only
>> supports 32-bit x86 code generation. It has poor support for CPython
>> extension modules, making migration for large applications
>> prohibitively expensive.
>>
>> That part at the very least has some sort of personal opinion
>> "prohibitively",
>
> Of course; difficulty is always in the eye of the person doing the
> work. Simply put, PyPy is not a drop-in replacement for CPython: there
> is no embedding API, much less the same one exported by CPython;
> important libraries, such as MySQLdb and pycrypto, do not build
> against PyPy; PyPy is 32-bit x86 only.

I like this wording far more. It's at the very least far more precise.
Those examples are fair enough (except the fact that PyPy is not 32bit
x86 only, the JIT is).

> All of these problems can be overcome with enough time/effort/money,
> but I think you'd agree that, if all I'm trying to do is speed up my
> application, adding a new x86-64 backend or implementing support for
> CPython extension modules is certainly north of "prohibitively
> expensive". I stand by that wording. I'm willing to enumerate all of
> PyPy's deficiencies in this regard in the PEP, rather than the current
> vaguer wording, if you'd prefer.
>
>> while the other part is not completely true "slower
>> than US on non-numerical workloads". Fancy providing a proof for that?
>> I'm well aware that there are benchmarks on which PyPy is slower than
>> CPython or US, however, I would like a bit more weighted opinion in
>> the PEP.
>
> Based on the benchmarks you're running at
> http://codespeak.net:8099/plotsummary.html, PyPy is slower than
> CPython on many non-numerical workloads, which Unladen Swallow is
> faster than CPython at. Looking at the benchmarks there at which PyPy
> is faster than CPython, they are primarily numerical; this was the
> basis for the wording in the PEP.
>
> My own recent benchmarking of PyPy and Unladen Swallow (both trunk;
> PyPy wouldn't run some benchmarks):
>
> | Benchmark    | PyPy  | Unladen | Change          |
> +==+===+=+=+
> | ai           | 0.61  | 0.51    |  1.1921x faster |
> | django       | 0.68  | 0.8     |  1.1898x slower |
> | float        | 0.03  | 0.07    |  2.7108x slower |
> | html5lib     | 20.04 | 16.42   |  1.2201x faster |
> | pickle       | 17.7  | 1.09    | 16.2465x faster |
> | rietveld     | 1.09  | 0.59    |  1.8597x faster |
> | slowpickle   | 0.43  | 0.56    |  1.2956x slower |
> | slowspitfire | 2.5   | 0.63    |  3.9853x faster |
> | slowunpickle | 0.26  | 0.27    |  1.0585x slower |
> | unpickle     | 28.45 | 0.78    | 36.6427x faster |
>
> I'm happy to change the wording to "slower than US on some workloads".
>
> Thanks,
> Collin Winter
>

"slower than US on some workloads" is true, while not really telling
much to a potential reader. For any X and Y implementing the same
language "X is faster than Y on some workloads" is usually true.

To be precise you would need to include the above table in the PEP,
which is probably a bit too much, given that PEP is not about PyPy at
all. I'm fine with any wording that is at least correct.

Cheers,
fijal
___
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] PEP 385 progress report

2010-02-12 Thread Martin v. Löwis 
>> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis"  wrote:
>>> IMO, it is realistic to predict that this will not actually happen. If
>>> we can agree to give up the 2to3 sandbox, we should incorporate
>>> find_pattern into the tree, and perhaps test.py as well.
>> I vote on giving up the 2to3 sandbox.
> 
> Besides, if we're using hg, it should make it much easier for someone
> else to branch that part of the stdlib

Actually - no: hg doesn't support branching of parts of a repository.
You would need to branch all of Python. Then, there wouldn't be a
straight-forward place to setup.py and any other top-level files
(although you could hack them into Lib, and work with a distutils manifest).

Regards,
Martin
___
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] PEP 385 progress report

2010-02-12 Thread Martin v. Löwis 
> I personally like 2to3 in a separate repo because it fits well with my
> view that 2to3 is an extra application that happens to also be
> distributed with python.

But isn't that just a theoretical property? I know that's how 2to3
started, but who, other than the committers, actually accesses the 2to3
repo?

I would be much more supportive of that view if there had been a single
release of 2to3 at any point in time (e.g. to PyPI). Alas, partially due
to me creating lib2to3, you actually couldn't release it as an extra
application and run it on 2.6 or 2.7, as the builtin lib2to3 would take
precedence over the lib2to3 bundled with the application.

Regards,
Martin
___
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] PEP 385 progress report

2010-02-12 Thread Nick Coghlan 
Benjamin Peterson wrote:
> 2010/2/12 Nick Coghlan :
>> Of course, PEP 291 could do with a list of 2.5 and 2.6 specific features
>> first...
> 
> I think that section is rather pointless to keep updated, since a good
> list can be found in the what's new documents. What people really need
> to do is run the unittests on all supported versions.

It's handy as a list of big ticket items to avoid, especially those that
can significantly affect the way you structure code.

Agreed that the main enforcement should be to run those tests on the
relevant older versions.

Cheers,
Nick.

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