Nice kata, I learned a bit about Python ojbects.

Great kata, I've learned a lot. That's the kind of kata that feel full.

@Blind4Basics as well as the actual tests which would surely throw an exception for non-existing self.parts, actually (got it myself during completing the kata).
At least, according to the lore and such, that could've been considered as a slight-ish hint... that, or you can go over it in other ways tbh

So yeah, honestly I don't think the comparison tests having the MockObject with parts is a big problem, especially with the fixed initial solution (unless I'm missing something at 9 AM...)

I'm more bothered with comparison tests that rely on the existence of the parts attribute, actually. This is not bad per se, but this is totally white box testing.
I was also annoyed with the _parts vs parts thing, but this is mostly because of the non existence of specifications. A "private" (underscore thing) against a frozen public propety (without the underscore) is quite usual in python.

Yeah, honestly I was considering that as an issue before beta approval but thought it would not be pretty crucial...

For now changed in the initial solution self._parts to self.parts as more suitable with the actual tests, thanks for your feedback :)

Great kata. One tiny stumbling block for me was that the init assigns to self._parts, but then the tests look at self.parts. I assumed they'd be checking for immutability on the underscored version. (Or maybe they're hinting that we should keep both separately...)

Currently, aside the not-so-critical suggestion below, there are no critical issues with this kata, so let's check the current assessed ranks:

• 5 kyu — 9;
• 4 kyu — 4;
• 3 kyu — 1.

Considering this kata seems to be pretty solid in terms of assertions about class IPv4Address, as well as the approach for its solution + the estimated rank by author itself is 4 kyu, I'll set that difficulty as well. Thank you for the kata!

Tests have been updated

The current set of methods does not teach solvers a best practice.

It is also not understandable, why you ask to implement hash method, if you don't use it as designed (i.e. testing sets of IpAddress, using IpAddress as key of dict, etc.)

Not sure that copying every single bit from standard library will be helpful

Yeah, it all makes sense. @Voile apologies for being overly defensive. Shouldn't have been answering to the comments in the middle of the night.

ipaddress also has __format__, and also allows adding/subtracting integers from them, and also has a ton of other functionalities, so...

There should be enforced methods __int__, __bytes__.

There should not be method from_string, rather the class should accept various types in __new__, like here https://docs.python.org/3/library/ipaddress.html

the true question here is: is that very difficult to generate random tests for your kata (edit: or a limited set of possible inputs)? As long as the answer is no, the random tests are mandatory.

Not even trying to convince. Just pointing out that the rule that not enforced autotaically and has exceptions can not be mandatory.