• Thanks for your response! When debugging my solution I noticed along the way that e.g isinstance(True, int) == True which I didn't know before. My fix (at least I assume it is one) was to replace isinstance() with type(). I went through my code again and unfortunately cannot see any place where a bug like this might happen...

  • Read the issue two threads below. I'd bet you got caught by the int/bool problem.

    edit: mmh, it has a spoiler flag. Well, begin with being extra careful about the above... And don't forget to close the issue if that's actually that.

  • After another night of trying to get the random tests to pass I just cannot come to another conclusion than that there must be a weird, random error in those tests. I usually pass about 30 or so of them. Then there is a test that says Should fail - but my logging shows that all attributes in all fields are configured in a legal i.e. validation-passing way. How should validation e.g. fail, if all fields have None values and are allowed to be blank? That's just not possible - at least that's how it looks to me.

  • Same for me. I passed all tests a few hours ago - except for the EmailField random tests. It is quite annoying not being able to complete this Kata just because its requirements are pooly specified. Please give a more detailed description of how to validate emails!

  • My attempted solution passes all tests except for the last one (Random models), where it either fails or passes validation depending on the validation logic of my EmailField. Unfortunately, the test doesn't give any details on where exactly it fails and I have no clue what I should change. What exactly are the validation requirements for EmailField? For example, do min_length and max_length apply to the entire email string or separately to each of address, subdomain, domain?

    Edit: I found the bug in my solution and it had nothing to do with the EmailField but with validation of another field. Still, it's quite hard to debug the solution to this kata, because the user doesn't know what is tested for exaclty. Is that intended?

  • This comment is hidden because it contains spoiler information about the solution

  • oh, okay. Thanks for pointing this out, I didn't have realised the tests were failing "that way" because I didn't use "this way". x) (I edited the fork of my solution accordingly)

    thx :)

  • This comment is hidden because it contains spoiler information about the solution

  • The fact that the "datetime.now()" is used as default is ok. What is "bothering" me is that you test the DateTimeField object outside of its normal usage, meaning you ask stuff to it directly while it's only utility is(should be) to provide the current date at instanciation time of a user are whatever the class is. So, testing this, but only through the created instances seems perfectly legit/consistent/intereseeting. Testing it directly by calling DateTimeField.default "out of context", doesn't feel good to me.

    Not sure if I'm clear enough...?

  • it seems you're silencing any exception raised during the validation tests

    test.expect_no_error now reports raised errors.

    I still feel like this requirement is out of place in the overall task

    Well, there was no such requirement originally. When I was fixing/adding tests I noticed that the author delegated datetime.now() calls to the default, and thought that if the author made default always return the value-to-be-inserted, then why not make it into a requirement too. This is different from Django behavior, and feels weird indeed, but seems to work fine in this minimalistic case. If you think there's no value in enforcing such thing, I can remove those tests.

  • (This problem is actually linked to the non-sensical requirement about the DateTimeField.default thing... :/ That makes the full metaprog approach quite cluncky, to fulfill that requirement... :// )

    Anyway... If the non-sensical part below still exists, I guess that adding more tests about that non-sensical stuff won't end up well at some point... Closing. If you're still up to add the test, go ahead, otherwise...

  • Okay, I could track it down. This is actually again because of an implementation detail (and the desciption not being specific enough). Without that statement, my code was generating the datetime when accessing date_joined instead of at instantiation time. Would be good to add a specific test checking for that.

  • while the test is actually about NOT computing a new date when the default value has been already set before

    I'm not sure that I'm following you. The test with the "Automatically generated datetime values should be up to date" header is:

    class User(Model):
        date_joined = DateTimeField(auto_now=True)
        # other fields not listed for brevity
    
    now = datetime.datetime.now()
    user = User()
    
    now2 = datetime.datetime.now()
    user2 = User()
    
    Test.expect(user2.date_joined > now2 > user.date_joined > now, 'New users should have more recent "time joined" field values')
    

    Am I missing something here?

  • @FArekkusu (or any other user competent in metaprogramming and method chaining/MRO in python):

    I encountered a very strange behavior with that kind of test:

    test.expect(not hasattr(User, 'first_name'), 'There should be no first name')
    

    I used sort of a full metaprogramming approach, so when I defined my getters (see the comment in my solution), using the following:

        def ...
            o.__dict__       # o is the user instance
            return ...
    

    This leads to User.__dict__ showing all the defined fields, but it passes the hasattr test, while:

        def ...
            return ...
    

    This leads to User.__dict__ showing exactly the same things, but this time it fails that test.

    I saw, during my investigations, that the help(User) call doesn't show exactly the same thing, tho: with that line, all fields are defined as "class level descriptors", while when I remove it, only 3 of them are still qualified in the same way, and the others are instance level stuff (iirc, not totally sure anymore).

    Would someone have an idea about what's going on there...? (I smell something as bad as the "mutable default argument definition" trap... x) )

  • Loading more items...