python new test framework is required.

Python: Random tests are vulnerable to input modification

Python: see this

The description says:

We can assume that each attribute has its copy constructor implemented.

But a.u is an instance of the class U which does not have a copy constructor.

This also implies that we should copy the attributes when getattr is called, but the it_5 tests don't follow this, in particular with this test:

a.u.x += 8

If I actually copy the attributes, I fail this test.

(I would also like to bring attention to this unresolved issue from 4 years ago, which also caused me some frustration.)

Copy/paste the example tests to a section of the Submit tests.
This absolutely prevents solutions failing the Example tests but passing the Submit tests, which is very hard to explain if it happens.
( I don't know how a solution would achieve that, but solvers can be very creative. )

should just generally work
uncaught exception: ErrorCall
Prelude.!!: negative index
(after 1 test)
  Exception thrown while showing test case: 'Prelude.!!: negative index'
  Next One

If arbitrary generates n = 0, which it can, odds !! ((-1) `div` 2) will throw that error.

Use quot instead of div, or just lose the -1.

I read "tests will only use odd numbers less then 2000" as results of multiplications not being larger than 1999, not individual multiplicands. Apparently, I read that very wrong.

Or you could explain it better. :]

You should do something to prevent this

new update to Python 3.11 is required.

Empty repl inputs are silently dropped from the expected result (this only occurs in the "full session" test).

This kata is unsolvable in general: there is a test case

>>> print 'answer is\n... tricky\n...'
answer is
... tricky
...
>>> if 0: print 42
...

But this could easily be

>>> print 'answer is\n>>> tricky\n>>>'
answer is
>>> tricky
>>>
>>> if 0: print 42
...

And there is no way to parse such cases correct unless we run a repl in Python 2(!) ourselves, read every line of input, eval the blocks ourselves and capture the output.

What is the input size? This should be provided.

Hi,

• The description should hold the specs, instead of the sample tests.
• For your convenience, two objects: NO_SUCH and NONE are predefined, which has copy constructor.: has -> have
• Callables aren't tested properly. Cuurently, method calls are tested, but properties assigned with lambdas, or even methods overridden at instance level should be tested as well.
• inheritance checks should be done on the property values, to ensure their contract is actually guaranteed (this invalids the current top solution, for instance):

  a.x,a.y = "balbla",42
  test.expect(isinstance(a.x,str))
  test.expect(isinstance(a.y,int))
  

I fear this part is a lost cause... (because 'DEL' and '' (for undefined attributes) are both colliding with a proper mro anyway).

• The DEL requirement doesn't make any sense. Considering a case like this (which is in the tests):

  @change_detection
  class X:
    x = 42
    
  a = X()
  a.x = 33
  del a.x
  

  At this point, to get a proper/consistent mro, a.x should return something equal to 42 and nothing else.
  The get_change=='DEL' requirement can only make sense if it follows a behavior like this:

  1. if a class level property exists:
     - After deletion of a.x:
     • a.x returns the class level value with a get_change property being 'DEL'
     • X.x returns its value with a get_change property being 'INIT'
       - Changing the class level property after deletion of a.x would lead to:
     • a.x returns the new class level value with a get_change property being 'DEL'
     • X.x returns its new value with a get_change property being 'MOD' (yeah, out of the scope of the current kata, but if the specs are to be mde consistent, that would need to be implemented as well)
  2. if no class level property:
     • a.x would need to return a special token as value (not even NONE or NO_SUCH, which could be seen as an actual value assigned. For NONE, at least), with get_change=='DEL'. But that's rather dirty... (see next point)

• The get_change=='' for undefined attributes is colliding as well with a proper mro. If the attribute is not defined, an AttributeErrror should be raised, period. This would actually resolve the DEL case (as being plain invalid implementation)

Cheers