Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #18596 > unrolled thread

replacing __dict__ with an OrderedDict

Back to article view | Back to comp.lang.python

Contents

  replacing __dict__ with an OrderedDict Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-01-06 10:48 +0100
    Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-06 22:43 +1100
      Re: replacing __dict__ with an OrderedDict Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-01-06 14:36 +0100
        Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-07 04:01 +1100
          Re: replacing __dict__ with an OrderedDict Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-07 00:45 +0000
        Re: replacing __dict__ with an OrderedDict Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-06 10:20 -0700
          Re: replacing __dict__ with an OrderedDict Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-01-07 00:49 +0000
            Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-07 12:21 +1100
            Re: replacing __dict__ with an OrderedDict Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-06 18:24 -0700
              Re: replacing __dict__ with an OrderedDict Eelco <hoogendoorn.eelco@gmail.com> - 2012-01-08 14:03 -0800
                Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-09 23:10 +1100
                  Re: replacing __dict__ with an OrderedDict Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-01-09 14:16 +0100
                    Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-10 23:31 +1100
                      Re: replacing __dict__ with an OrderedDict Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-01-10 18:21 +0100
          Re: replacing __dict__ with an OrderedDict Roy Smith <roy@panix.com> - 2012-01-09 09:35 -0500
            Re: replacing __dict__ with an OrderedDict Neil Cerutti <neilc@norwich.edu> - 2012-01-09 14:52 +0000
            Re: replacing __dict__ with an OrderedDict Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-01-09 17:59 +0100
              Re: replacing __dict__ with an OrderedDict Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-09 10:30 -0700
              Re: replacing __dict__ with an OrderedDict Roy Smith <roy@panix.com> - 2012-01-09 20:05 -0500
                Re: replacing __dict__ with an OrderedDict Terry Reedy <tjreedy@udel.edu> - 2012-01-09 23:21 -0500
                Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-10 23:22 +1100
                  Re: replacing __dict__ with an OrderedDict Roy Smith <roy@panix.com> - 2012-01-10 09:05 -0500
                    Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-11 02:57 +1100
                      Re: replacing __dict__ with an OrderedDict Roy Smith <roy@panix.com> - 2012-01-10 21:47 -0500
                    Re: replacing __dict__ with an OrderedDict Tim Wintle <tim.wintle@teamrubber.com> - 2012-01-10 15:45 +0000
              Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-10 23:46 +1100
        Re: replacing __dict__ with an OrderedDict Lie Ryan <lie.1296@gmail.com> - 2012-01-07 04:42 +1100
    Re: replacing __dict__ with an OrderedDict Peter Otten <__peter__@web.de> - 2012-01-06 12:44 +0100
      Re: replacing __dict__ with an OrderedDict Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-01-06 14:40 +0100
        Re: replacing __dict__ with an OrderedDict Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-06 09:06 -0700
          Re: replacing __dict__ with an OrderedDict alex23 <wuwei23@gmail.com> - 2012-01-08 20:58 -0800
        Re: replacing __dict__ with an OrderedDict Ian Kelly <ian.g.kelly@gmail.com> - 2012-01-06 09:07 -0700
        Re: replacing __dict__ with an OrderedDict Arnaud Delobelle <arnodel@gmail.com> - 2012-01-06 21:38 +0000
      Re: replacing __dict__ with an OrderedDict Ulrich Eckhardt <ulrich.eckhardt@dominolaser.com> - 2012-01-18 11:29 +0100
    Re: replacing __dict__ with an OrderedDict Ethan Furman <ethan@stoneleaf.us> - 2012-01-06 06:13 -0800
    Re: replacing __dict__ with an OrderedDict Arnaud Delobelle <arnodel@gmail.com> - 2012-01-06 21:32 +0000

Page 2 of 2 — ← Prev page 1 [2]

#18751

On 01/10/2012 12:05 PM, Roy Smith wrote:
> Somewhat more seriously, let's say you wanted to do test queries against
> a database with 100 million records in it.  You could rebuild the
> database from scratch for each test, but doing so might take hours per
> test.  Sometimes, real life is just*so*  inconvenient.

All serious database has rollback feature when they're available to 
quickly revert database state in the setUp/cleanUp phase.

[toc] | [prev] | [next] | [standalone]

#18762

In article <mailman.4588.1326198152.27778.python-list@python.org>,
 Lie Ryan <lie.1296@gmail.com> wrote:

> On 01/10/2012 12:05 PM, Roy Smith wrote:
> > Somewhat more seriously, let's say you wanted to do test queries against
> > a database with 100 million records in it.  You could rebuild the
> > database from scratch for each test, but doing so might take hours per
> > test.  Sometimes, real life is just*so*  inconvenient.
> 
> All serious database has rollback feature when they're available to 
> quickly revert database state in the setUp/cleanUp phase.

I guess MongoDB is not a serious database?

[toc] | [prev] | [next] | [standalone]

#18768

On 01/11/2012 01:05 AM, Roy Smith wrote:
> In article<mailman.4588.1326198152.27778.python-list@python.org>,
>   Lie Ryan<lie.1296@gmail.com>  wrote:
>
>> On 01/10/2012 12:05 PM, Roy Smith wrote:
>>> Somewhat more seriously, let's say you wanted to do test queries against
>>> a database with 100 million records in it.  You could rebuild the
>>> database from scratch for each test, but doing so might take hours per
>>> test.  Sometimes, real life is just*so*  inconvenient.
>>
>> All serious database has rollback feature when they're available to
>> quickly revert database state in the setUp/cleanUp phase.
>
> I guess MongoDB is not a serious database?

I guess there are always those oddball cases, but if you choose MongoDB 
then you already know the consequences that it couldn't be as easily 
unit-tested. And in any case, it is generally a bad idea to unittest 
with a database that contains 100 million items, that's for performance 
testing. So your point is?

[toc] | [prev] | [next] | [standalone]

#18799

In article <mailman.4603.1326211045.27778.python-list@python.org>,
 Lie Ryan <lie.1296@gmail.com> wrote:

> >> All serious database has rollback feature when they're available to
> >> quickly revert database state in the setUp/cleanUp phase.
> >
> > I guess MongoDB is not a serious database?
> 
> I guess there are always those oddball cases, but if you choose MongoDB 
> then you already know the consequences that it couldn't be as easily 
> unit-tested. And in any case, it is generally a bad idea to unittest 
> with a database that contains 100 million items, that's for performance 
> testing. So your point is?

My point is that in the real world, what is practical and efficient and 
sound business is not always what is theoretically correct.

[toc] | [prev] | [next] | [standalone]

#18775

On Tue, 2012-01-10 at 09:05 -0500, Roy Smith wrote:
> 
> I guess MongoDB is not a serious database? 

That's opening up a can of worms ;)


... anyway, cassandra is far better.

Tim

[toc] | [prev] | [next] | [standalone]

#18755

On 01/10/2012 03:59 AM, Ulrich Eckhardt wrote:
>
>
> There is another dependency and that I'd call a logical dependency. This
> occurs when e.g. test X tests for an API presence and test Y tests the
> API behaviour. In other words, Y has no chance to succeed if X already
> failed. Unfortunately, there is no way to express this relation, there
> is no "@unittest.depends(test_X)" to decorate test_Y with (Not yet!).

The skipIf decorator exists precisely for this purpose. Generally, 
testing availability of resources (like existence of an API) should be 
done outside of the testing code. In other words, test_X should never be 
a test in the first place, it should be part of the setting up of the 
tests; the tests themselves should be completely independent of each other.

[toc] | [prev] | [next] | [standalone]

#18611

On 01/07/2012 04:20 AM, Ian Kelly wrote:
> On Fri, Jan 6, 2012 at 10:01 AM, Lie Ryan<lie.1296@gmail.com>  wrote:
>> That unittest executes its tests in alphabetical order is implementation
>> detail for a very good reason, and good unittest practice dictates that
>> execution order should never be defined (some even argued that the execution
>> order should be randomized). If the test runner turns out to execute tests
>> concurrently, that should not cause problems for a well-designed test.
>> Displaying the test results in a more convenient order for viewing is what
>> you really wanted in 99.99% of the cases.
>
> Randomizing the order is not a bad idea, but you also need to be able
> to run the tests in a consistent order, from a specific random seed.
> In the real world, test conflicts and dependencies do happen, and if
> we observe a failure, make a change, rerun the tests and observe
> success, we need to be able to be sure that we actually fixed the bug,
> and that it didn't pass only because it was run in a different order.
>
> Concurrent testing is a bad idea for this reason -- it's not
> repeatable (testing concurrency, OTOH, is a perfectly fine thing to be
> thinking about).

Concurrent testing is perfectly fine strategy in the case where you have 
thousands of tests and running them synchronously will just take too 
long. Certainly it makes it harder to repeat the test if there is any 
sort of dependency in the tests, but when you have the large number of 
tests, the benefit may exceeds the drawbacks.

[toc] | [prev] | [next] | [standalone]

#18598

Ulrich Eckhardt wrote:

> The topic explains pretty much what I'm trying to do under Python
> 2.7[1]. The reason for this is that I want dir(SomeType) to show the
> attributes in the order of their declaration. This in turn should
> hopefully make unittest execute my tests in the order of their
> declaration[2], so that the output becomes more readable and structured,
> just as my test code (hopefully) is.
> 
> I've been toying around with metaclasses, trying to replace __dict__
> directly, or using type() to construct the class, but either I hit
> read-only attributes or the changes seem to be ignored.

Alternatively you can write your own test loader:

$ cat ordered_unittest2.py
import unittest

class Test(unittest.TestCase):
    def test_gamma(self):
        pass
    def test_beta(self):
        pass
    def test_alpha(self):
        pass

class Loader(unittest.TestLoader):
    def getTestCaseNames(self, testCaseClass):
        """Return a sequence of method names found within testCaseClass
        sorted by co_firstlineno.
        """
        def first_lineno(name):
            method = getattr(testCaseClass, name)
            return method.im_func.__code__.co_firstlineno

        function_names = super(Loader, self).getTestCaseNames(testCaseClass)
        function_names.sort(key=first_lineno)
        return function_names


if __name__ == "__main__":
    unittest.main(testLoader=Loader())

$ python2.7 ordered_unittest2.py -v
test_gamma (__main__.Test) ... ok
test_beta (__main__.Test) ... ok
test_alpha (__main__.Test) ... ok

----------------------------------------------------------------------
Ran 3 tests in 0.001s

OK
$

[toc] | [prev] | [next] | [standalone]

#18601

Am 06.01.2012 12:44, schrieb Peter Otten:
> Alternatively you can write your own test loader:
[...CODE...]

Well, actually you just did that for me and it works! ;)


Nonetheless, I'm still wondering if I could somehow replace the dict 
with an OrderedDict.

Thank you!

Uli

[toc] | [prev] | [next] | [standalone]

#18607

On Fri, Jan 6, 2012 at 6:40 AM, Ulrich Eckhardt
<ulrich.eckhardt@dominolaser.com> wrote:
> Nonetheless, I'm still wondering if I could somehow replace the dict with an
> OrderedDict.

In Python 3, yes.  This is pretty much the entire use case for the new
__prepare__ method of metaclasses.  See the "OrderedClass" example at:
http://docs.python.org/py3k/reference/datamodel.html#special-method-names

Cheers,
Ian

[toc] | [prev] | [next] | [standalone]

#18698

On Jan 7, 2:06 am, Ian Kelly <ian.g.ke...@gmail.com> wrote:
> <ulrich.eckha...@dominolaser.com> wrote:
> > Nonetheless, I'm still wondering if I could somehow replace the dict with an
> > OrderedDict.
>
> In Python 3, yes.  This is pretty much the entire use case for the new
> __prepare__ method of metaclasses.  See the "OrderedClass" example[...]

This isn't accurate. The OrderedClass example uses an OrderedDict to
remember the method creation order:

	def __new__(cls, name, bases, classdict):
		result = type.__new__(cls, name, bases, dict(classdict))
		result.members = tuple(classdict)
		return result

The instantiated objects __dict__ will still be a regularly
dictionary, while the assignment order is stored in the class
attribute .members.

[toc] | [prev] | [next] | [standalone]

#18608

On Fri, Jan 6, 2012 at 9:06 AM, Ian Kelly <ian.g.kelly@gmail.com> wrote:
> On Fri, Jan 6, 2012 at 6:40 AM, Ulrich Eckhardt
> <ulrich.eckhardt@dominolaser.com> wrote:
>> Nonetheless, I'm still wondering if I could somehow replace the dict with an
>> OrderedDict.
>
> In Python 3, yes.  This is pretty much the entire use case for the new
> __prepare__ method of metaclasses.  See the "OrderedClass" example at:
> http://docs.python.org/py3k/reference/datamodel.html#special-method-names

That link should be:
http://docs.python.org/py3k/reference/datamodel.html#customizing-class-creation

[toc] | [prev] | [next] | [standalone]

#18621

On 6 January 2012 13:40, Ulrich Eckhardt
<ulrich.eckhardt@dominolaser.com> wrote:
> Am 06.01.2012 12:44, schrieb Peter Otten:
>
>> Alternatively you can write your own test loader:
>
> [...CODE...]
>
> Well, actually you just did that for me and it works! ;)
>
>
> Nonetheless, I'm still wondering if I could somehow replace the dict with an
> OrderedDict.

No, you can't.

-- 
Arnaud

[toc] | [prev] | [next] | [standalone]

#19080

Am 06.01.2012 12:44, schrieb Peter Otten:
[running unit tests in the order of their definition]
> class Loader(unittest.TestLoader):
>      def getTestCaseNames(self, testCaseClass):
>          """Return a sequence of method names found within testCaseClass
>          sorted by co_firstlineno.
>          """
>          def first_lineno(name):
>              method = getattr(testCaseClass, name)
>              return method.im_func.__code__.co_firstlineno
>
>          function_names = super(Loader, self).getTestCaseNames(testCaseClass)
>          function_names.sort(key=first_lineno)
>          return function_names

After using this a bit, it works great. I have up to now only found a 
single problem, and that is that with decorated functions it doesn't 
even get at the actual line number of the real code, so sorting by that 
number doesn't work. An example for this is 
"@unittest.expectedFailure(...)".

I can easily ignore this though, just wanted to give this feedback

Thanks again!

Uli

[toc] | [prev] | [next] | [standalone]

#18605

Ulrich Eckhardt wrote:
> Hi!
> 
> The topic explains pretty much what I'm trying to do under Python 
> 2.7[1]. The reason for this is that I want dir(SomeType) to show the 
> attributes in the order of their declaration. This in turn should 
> hopefully make unittest execute my tests in the order of their 
> declaration[2], so that the output becomes more readable and structured, 
> just as my test code (hopefully) is.

I believe unittest executes tests in alphabetical order, but it does not 
display them in the same order when it prints error/fail results.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#18620

On 6 January 2012 11:44, Peter Otten <__peter__@web.de> wrote:
> class Loader(unittest.TestLoader):
>    def getTestCaseNames(self, testCaseClass):
>        """Return a sequence of method names found within testCaseClass
>        sorted by co_firstlineno.
>        """

That's a clever trick!

-- 
Arnaud

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.python

csiph-web