Expand __init__ parameters for Window

[damusss]

It's a bit annoying having to open the docs every time to remember if a flag exists or not and since this are bool flags and not int flags I think this adds clarity. Additionally, when you start typing a flag your IDE will suggest it to you and you'll spell it right.

Finally I used ... instead of False because the flag doesn't really enable or disable the feature, it justs sets the flag for SDL to handle. the default for that feature might be True in that specific os, so False would be incorrect, imo. Many libraries I saw used this signature, but I can change it if it's not liked.

I used the docs to get the flags, if some flags are to be deprecated for SDL3 I can omit them, of course.

[aatle]

I like the idea, but I am not sure about the fact that the overload is not matchable and an error has to be ignored. If we put this overload first or replace the original, then it may be annoying as you've said.
API-wise, ignoring user experience, it doesn't make sense to have two separate overloads.

Also, for reference, here's the "wall of text" that the user would see after this change for this overload (autocomplete kwargs would be filtered as the name is being typed).

I've seen larger ones, though.

class transformers.AlbertConfig(vocab_size=30000, embedding_size=128, hidden_size=4096, num_hidden_layers=12, num_hidden_groups=1, num_attention_heads=64, intermediate_size=16384, inner_group_num=1, hidden_act='gelu_new', hidden_dropout_prob=0, attention_probs_dropout_prob=0, max_position_embeddings=512, type_vocab_size=2, initializer_range=0.02, layer_norm_eps=1e-12, classifier_dropout_prob=0.1, pad_token_id=0, bos_token_id=2, eos_token_id=3, **kwargs)

[ankith26]

LGTM, thanks for the PR 🎉

[aatle]

Suggested change

	) -> None: ...
	**flags: bool,
	) -> None: ...

[damusss]

Hi, why would that be necessary? any flag that is not in the current parameter list will result in an error. it seems to me the code you are suggesting doesn't reflect what's going on in C. if a new flag will be added, a new keyword parameter will be added too.

[aatle]

Okay. I was thinking about the original signature and assumed that it was supported.
If flags are to be deprecated though, will they be removed?

[damusss]

I thought about it too, like, "will this make it harder to remove things?" not really. what is in the docs is official and public. just because it wasn't in the stubs before doesn't mean it could just be removed. if a flag is deprecated, the keyword parameter will be removed. your linter will complain, but your code won't fail, it'll just output a warning. the linting failing is actually good, because it discourages usage, just like @deprecated does.

[aatle]

Disallowing deprecated parameters in typing is not appropriate.
Either, the deprecated parameters are still compatible with typing via the **kwargs parameter, or there is a deprecated overload for them (possibly using **kwargs). There might also be runtime warnings to accompany them.

[damusss]

the warning are sure. how would the overload be compatible with mypy? should it be added now? perhaps when deprecating the keyword argument will not be removed, but it could be typehinted in some special way, I hope so. Either way, I believe it to be slightly outside of scope of this PR. good for noticing tho :)

[aatle]

Sure.
When a flag is deprecated, we can either keep it in the signature or create a separate deprecated overload.

Thanks for clarifying this.

[aatle]

LGTM, thanks!

[bilhox]

After reading all messages and the content of the code changes, I can say that it looks good to me.
Thanks for the PR !