It was a deliberate design choice not to allow lambdas, and this behavior is documented. I would need strong reasons to change my mind on this.

Performance benchmarks:

It was a deliberate design choice not to allow lambdas, and this behavior is documented. I would need strong reasons to change my mind on this.

My concern is only that schedule_event(lambda ...) is currently accepted and then fails silently later. I suggest failing fast at scheduling time with a clear error, while keeping the existing weakref behavior for supported callables.

My concern is only that schedule_event(lambda ...) is currently accepted and then fails silently later. I suggest failing fast at scheduling time with a clear error, while keeping the existing weakref behavior for supported callables.

But that is not what this PR does. It creates an internal hard ref for weak references. Also, the same issue as lambdas also holds potentially for partial functions.

I am potentially open to accepting that lambdas and partials raise a value error when passed to an event.

I am potentially open to accepting that lambdas and partials raise a value error when passed to an event.

I suggest fail-fast validation instead: reject unsupported ephemeral callables at event creation (at least lambdas and functools.partial) with a clear ValueError, while preserving the existing weakref behavior for supported callables.

What are your thoughts?

suggest fail-fast validation instead: reject unsupported ephemeral callables at event creation (at least lambdas and functools.partial) with a clear ValueError, while preserving the existing weakref behavior for supported callables.

This is exactly what I was trying to suggest.

Should I refactor this PR then?

Performance benchmarks:

Thanks for the update. I have been looking at this issue myself as well for some other reasons.

1. I would move the check into a separate function rather than a static method. We need the validation in other places as well.
2. I am still wondering about partials. At the moment, we don't allow args and kwargs in Event, so if we also don't allow partials, we severely limit the functions and methods that can be scheduled. Is there a way to check if a partial function has been assigned to a variable? The other option is to allow args and kwargs on Event.

There is no way to check whether a partial was “assigned to a variable” in a way that guarantees safe lifetime.
So the reliable way might be to “allow args/kwargs on Event usage path” (or expose them via schedule_event), not trying to detect variable assignment for partials.

The other option is to issue a warning if the weakref resolves to None. Warnings in general are issued only once, but it would allow users to more quickly diagnose that something might be wrong.

I would suggest approaching this slightly differently:

        if isinstance(function, MethodType):
            function = WeakMethod(function)
        else:
            function = ref(function)

        if function() is None:
            # error message needs work
            raise TypeError(function is not weakly referencable ...)

        self.fn = function

So rather than checking the type and everything, we just check if we can take a weakref to the function at creation. If we can do that, we accept it. Otherwise, we raise an error. In this way, partials assigned to a variable are still accepted.

I like the direction, but I want to flag one concern: validating weakref resolution at creation time is only a point-in-time check. A callback can still be GC’d before execution, so we may still get nondeterministic no-ops.
Would you be comfortable making that an explicit contract (“caller must keep a strong reference alive”), or should we prefer stricter fail-fast rules to avoid that class of runtime ambiguity?
If we go with the weakref-capability approach, I’d suggest also keeping a runtime warning when fn() resolves to None so failures are diagnosable.

A callback can still be GC’d before execution, so we may still get nondeterministic no-ops.

Yes, but that is desirable behavior. Imagine you schedule events for an agent. Somewhere along the way, this agent is removed from the simulation. All events that call this agent now must either be removed or fail silently. With weakrefs, we get silent failures.

Not sure about the warning. I think it might be more confusing than helpful.

Can you update the starting post to align with the final implementation?

The behavior is still not exactly what I have in mind. Let me try to explain it

• If function is not a callable --> raise a TypeError
• If function is not weakly referenceable --> raise a TypeError
• If weakref to function resolves to None when Event is instantiated, raise a ValueError

This last one is the sticky one and also in my own testing I can't seem to get it right. Basically, Event(5, lambda:5) or Event(5, partial(my_func, 1, 2,3)) should raise a ValueError. While

a = partial(my_func, 1,2,3)
Event(5, a)

should run fine.

Thanks, this helps clarify the intended behavior.
I think we can implement the “tricky” case by doing the liveness check after dropping the local strong reference in Event.__init__:

if not callable -> TypeError
if not weakrefable -> TypeError
create weakref, drop local strong ref, then check wr() is None -> ValueError
That should make Event(5, lambda: 5) and inline Event(5, partial(...)) fail, while a = partial(...); Event(5, a) still works.

We hit cross-platform instability with the current inline-partial check.
The logic depends on sys.getrefcount, and that value changes across CPython builds/OS/test environments, so a variable-bound partial is sometimes misclassified and rejected.

So the check is not deterministic in CI.
To keep behavior stable, I propose we remove refcount-based partial detection and keep only deterministic guards:

• callable required
• weak-referenceable required
• lambda rejected at creation
• dead weakref at creation rejected

This keeps fail-fast behavior without flaky platform-dependent failures.

code wise, it seems fine now. I want to find some time to test a few things manually on this brach before approving it.

the docs are breaking because the event scheduling tutorial is breaking because it uses lambda functions. Can you take a look at fix this?

Fixed it.

@quaquel backport?