I would prefer to avoid using OptionalArg in these:

1. OptionalArg<Option<...>> feels very weird
2. We can derive whether an arg is optional or not based on the presence of a future default attribute (or perhaps something like #[pyarg(optional = true)], basically I want to avoid reusing any of the FromArgs extractors inside of these structs)

Agreed, OptionalArg<Option<...>> is awkward, but wouldn't be needed when I implement the default attribute argument. I'm split about having OptionalArg in these structs, I think in some cases we need to differentiate between a missing argument and passing None.

I think we should handle this entirely with attributes rather than reusing OptionalArg. In the following, None refers to a Python None and Option::None refers to Rust's none.

Thing is required, and cannot be None.

#[derive(FromArgs)]
struct MyArgs {
    #[pyarg(positional)]
    thing: ThingRef,
}

Thing is required, but can be None:

#[derive(FromArgs)]
struct MyArgs {
    #[pyarg(positional)]
    thing: Option<ThingRef>,
}

Thing is not required, can be None, and will use the Default impl for Option if not passed, which is Option::None.

#[derive(FromArgs)]
struct MyArgs {
    #[pyarg(positional, default)]
    thing: Option<ThingRef>,
}

Thing is not required, cannot be None, and will use the result of if the argument is not present.

#[derive(FromArgs)]
struct MyArgs {
    #[pyarg(positional, default = "<method that returns ThingRef>")]
    thing: ThingRef,
}

I still think in some situations it's not sufficient to just have a default, some functions need to detect if its argument was provided. For example, if the base argument is provided to int.new then the first argument can then only be a string, otherwise, it can be other types like int or float.

CPython implements int.new by using NULL as the default. https://github.com/python/cpython/blob/master/Objects/longobject.c#L4950

I have added an 'optional 'argument to pyarg, to indicate when we are want to convert into OptionalArg. e.g.

#[derive(FromArgs)]
struct IntOptions {
    #[pyarg(positional, optional = true)]
    val_options: OptionalArg<PyObjectRef>,
    #[pyarg(positional_keyword, optional = true)]
    base: OptionalArg<u32>,
}

For example, if the base argument is provided to int.new then the first argument can then only be a string, otherwise, it can be other types like int or float.

In cases like these, the "function overloading" trick might work, e.g. range does:

fn range_new(vm: &VirtualMachine, args: PyFuncArgs) -> PyResult {
    let range = if args.args.len() <= 2 {
        let (cls, stop) = args.bind(vm)?;
        PyRangeRef::new(cls, stop, vm)
    } else {
        let (cls, start, stop, step) = args.bind(vm)?;
        PyRangeRef::new_from(cls, start, stop, step, vm)
    }?;

    Ok(range.into_object())
}

Basically there can be two different int_new methods (that accept different types) decided upon based on arity.