Kata

I looked into it, for some reason rec_test was not defined in the global scope, and so was contradicting the description:

All functions will be defined as top level functions, or top level object methods.

I have moved rec_test to top level, and I think that your code actually works now. Have a try and let me know if it is still broken.

Thanks for lightning-fast answer. Yep, it is working perfectly now.
So this rec function was a sub function and sub method... I will try to replicate it locally, it is interesting to make it work in sub case as well.

Thanks again for awesome kata!

That test checks whether object methods can access the implicitely passed variable (normally called self). Note this should work, whether the variable is called self or something else. Looking at your code, I think you are having trouble with that second part.

As an example, this code should work:

class A:
    val = 5
    def get_v(self):
        return self.val
    def double_v(me):
        return me.val*2
the_ob = A()
print(the_ob.get_v()) # 5
print(the_ob.double_v()) # 10

If you want, I can do a sweep on the kata (description + tests)

mmmh, I missed that part of your message, earlier.

(Since the added thoroughness and requirements I want to add will likely break every existing solution, and will essentially be a different kata.)

Don't do that. The average rank will be totally biased if you do so. Or be sure it' doesn't fall too far from the current requirements. What do you have in mind, exactly?

Well that's why I was gonna republish this (republish is probably the wrong word. I mean take this one down and put up a fresh new one with a similar name/theme.) Because then the ratings and reviews will have to be fresh.

For the new kata ideas I am trying to implement are:

• Correct scoping (defined functions are not available once they leave scope, inside a scope a variable refers to the most recent outside scope unless a new one has been defined, etc)
• Correct behaviour with @staticmethod and @classmethod (applied in any order)
• Allow a 'default' case to be set with a bare @overload (different from @overload())
• Ability to access specific 'overloads' of a function (eg. my_func[int, str] would return that specific function.)
• MAYBE some form of polymorphism? As in, subclasses count as their parent classes when finding the correct overload. (If more than one, uses the most recently defined)

And lots of extra tests, for example:

• Ensuring functions can be overwritten
• Specific function overloads can be deleted (del my_func[int, str])
• Works for large number of inputs
• Works on applicable 'magic methods' (__init__, __new__, __call__, __add__ etc)
• class and object methods can access cls and self properly, even when differnt names are used
• Tests for correct scoping.

What do you think? Is that too much? Obviously first I need to make sure I can even write my own solution.

Edit: I also want your opinion on an idea I had for tests. I thought I would make all the tests also available as sample tests, but for the real tests, I would randomize the order (to avoid hardcoding?). That way everything I am testing would be very clear. Or is there any obvious flaw in that?

mmh, ok.

• Q: why not keep that one, tho?

  • they won't overlap, aside from being about the same general topic
  • getting this one perfectly "straight" would imo be a good training for you as an author: 'Feels to me you're going into something deep, there, where any mistake about how the task is described might cause "a lot of troubles" on the user's side ;o

• Warning with static and class methods... Their actual behaviour (the way they are accessed, I mean) is imo rather a mess than anything. I'm really not sure it's a good idea to dig there. Dunno. But for sure, you can try. Maybe your way with decorators rather than metaprogramming (see the other kata linked below: the author wanted to do so too and we tried a bit, but reaslized the fucking mess, then...) can make the thing possible, yes.

All your ideas are pretty nice/interesting, but that seems very ambitious too. ;)

I also want your opinion on an idea I had for tests.

errr... randomization isn't enough, generally. You can put a lot of things in the sample tests. Just don't forget that sample tests aren't there to patch an incomplete description. :)
In any case, you'll still have to build some actual random tests for the full test suite.

cheers

Correct scoping

I still think the answer here is explicit registration, trying to figure it out implicitly will surely lead to surprising behaviour. Imagine you have this big carousel of functions, they come from all over the place and need to be decorated by various requirements. Just because two functions are defined in the same location or decorated in the same location doesn't mean they belong together. Global state seems rather unhygenic in general. There's also going to be that one guy who starts decorating stuff in different threads. Maybe there are two threads running in the same scope and they both are decorating functions there. Do they belong together? Maybe maybe not, both could be right, but you have to choose one.

@overload
def f(): pass

@f.register
def f(): pass

Maybe you are right Blind. I'll try get this one up to scratch as an 'easier' version, and if I can make the 'ambitious' one work then I'll add it as a new one.

Regarding @classmethod and @staticmethod I'm aware they are rather... messy. I do have an implementation that seems to handle them reasonably well, although I have yet to do a full test suite on it. This is partly because my knowledge of these decorators are somewhat sketchy. My implementation at the moment successfully creates overloaded functions that are accessible through class or object, and are passed the owner class or not (for @classmethod and @staticmethod respectively). But I would not be surprised if there are other mechanics or features that are getting lost along the way.

As for explicit registration, I don't really understand the need. A naive approach stores the functions within the solution module as a global variable, which need not be imported. I could add a namespace requirement that overload is the only global variable introduced in the module, but that only helps if someone plans to use from solution import *. Unless the idea is the insert the solution code directly into another project maybe.

My understanding of how 'correct scoping' should look would be imagining that every overload is in fact creating a new function (overload(int); def my_func(x): pass == def my_func_int(x): pass). And so anywhere else in the code, if my_func_int is accessible, then so should the int overload of my_func. Assuming someone understands normal variable scope, then they should not be surprised by the overload. Of course, as to whether all that is even possible, I am not quite sure.

I could add a namespace requirement that overload is the only global variable

global state, not global variable. IMO each group should have its own state. you requirements demand that there be a single storage point so that you can compare new function names and scopes to previously seen ones.

'correct scoping'

My understanding of correct scoping is that there's no such thing, the term is ambiguous, it doesn't specify what to do.

def create_overloaded_function(t):
    @overload(t)
    def f(x):
        return x + 1
    @overload(t, t)
    def f(a, b):
        return a + b
    return f

g = create_overloaded_function(int)
h = create_overloaded_function(float)

are g and h in the same group? (they're not defined in the same scope, but how are you gonna tell those scopes apart? xD maybe that's possible but oh boy you're going to have to explain that in the description somehow) So you have this really vague thing with scopes going on which probably defies explanation and is probably really magical to implement - and all of that goes away if they are instead registered together. This also gets rid of global state.

It also saves the end user from guessing what does and does not group, because they are the ones saying what a group is. And it doesn't impose arbitrary limits on how when and where they can be defined.

So that's why it wasn't working!

But should you be asking people to implement something that is broken? Especially without telling them that it's going to be broken.

I also suspect that telling self apart from other args could be really broken or puzzle-like if not specified how that should behave. I expect I can do it but by using introspection in ways that really makes me question what the kata's intention is when it isn't mentioned at all what should be done. Again with functools as an example - it uses a separate singledispatchmethod for that case. It doesn't help that the example methods behave like static methods (ignoring self) and therefore do not show how they should behave with regard to self. And I never want to see a method that ignores self, such methods should me marked static there's no excuse!

I also suspect that telling self apart from other args could be really broken

In particular, how do I tell apart a static method that accepts a class instance as first argument from a method that binds to a class instance? I expect to be able to tell the difference, but it's real awkward.

class A:
  @overload(int)
  def m(self, n): pass
  # @overload(A, int)  # never mind that A is not in scope here
  # @staticmethod
  # def m(other, n): pass
# more practical way to implement the above static method since A is in scope now
@overload(A, int)
def m(other, n): pass

m(A(), 5)   # which am I calling?
A().m(5)    # which am I calling?
A.m(A(), 5) # ...
            # they're going to look a whole lot the same
            # they can be told apart I'm sure but ... this is WEIRD to deal with
            # without having been told how things should behave

well, I changed the approach, now I pass all fixed tests, but don't pass any of the random ones... :/

ok, that's not pleasant anymore... :/

I'm at my fourth variation and I still got failures, but not always at the same places. It seems to me you're approach might actually be overriding some functions in some specific cases and that it's not described. Does it?

I tried to make the descriptions for the tests a bit better, and I am about to go add a few more tests to the samples.

As for the random ones, are you still having trouble passing them? I had an bug earlier where a function might (unluckily) be overwritten by another with the same 'type signature' of arguments, but that seems to be now fixed as my solution passes consistently (unless I am just very lucky)

Would if help if I would reveal the functions being tested for the random test each time?

Function failed with inputs: [<__main__.C_A object at 0x7f5db155beb0>]: 4907 should equal 4279
Function failed with inputs: [<__main__.C_B object at 0x7f5db13cffd0>]: 1589 should equal 1423
Function failed with inputs: [<__main__.C_C object at 0x7fb248ca9310>]: 2161 should equal 3322
Function failed with inputs: [2.2, <__main__.C_A object at 0x7fbd128d6e20>]: 1985 should equal 2755
Function failed with inputs: [[0], <__main__.C_B object at 0x7efc3abff100>]: 4580 should equal 3972
Function failed with inputs: [<__main__.C_B object at 0x7efc3abffe50>, <__main__.C_B object at 0x7efc3abff6a0>]: 3403 should equal 2010

There're still failues once every couple thousand of tests. It seems the source of the problem is the classes.

Edit: while params == [] or params in inputs - guess what this line does when you generate new instances of C_A, C_B, C_C in a loop, and none of them have __eq__ overriden.

Yes I just found that, thanks for the help. My solution now passes more than 15000 tests in a row.

(maybe not, let's see...)

IMHO they are different enough (metaclesses/decorators, only methods/all functions, ...).

yep :+1:

That kata only differentiates between the number of arguments, not the types.

The first batch of the sample tests is still not enclosed in an it block.

Sorry I keep forgetting to look at the sample tests. Fixed now.