initial Python support #44

Given that Python can have top-level instructions in a module (for instance in a simple Python script, meant to be executed on its own), this is dangerous because it lets the tool reorder instructions whose order matters, no?

I have recently added support for restricting commutativity and I think it would be a good use case here, for instance to only let import statements commute. See the docs here: https://mergiraf.org/adding-a-language.html#adding-children-groups

Hello I have seen this and I thought exactly the same. I'm not too sure what the exact expression should be though.

I use import sorting in all my python project (via ruff format), which would also run via a precommit hock after the merge succeeds...

In my book it's a bug if you rely on module level code, but I guess from a conservative standpoint, order does matter...

I was under the impression that Python doesn't make it possible to declare two different functions with the same name and different parameter lists, so I would expect that the parameters are not part of the signature. Do you see it differently?

you are correct, this is a mistake, I'll fix it in a few hours.

It's not impossible to do, e.g. I've seen this pattern:

@singledispatch
def do_something(input: Any) -> None
    pass

@do_something.register
def _(input:float) -> None:
    pass
    
@do_something.register
def _(input:str) -> None:
    pass
 

This is valid python code

def func(whatever:Bla):
   pass

# This line could be removed, but actually might make this a "sane" pattern
module.func = func

def func(whatever:Other):
   pass

(it's valid even without the monkey patching: func is simply a variable which got the functon assigned, doesn't matter if the func has a different signature. It's for sure not wise python code and probably all linter will flag that duplication...)