Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC] split PyErr::new() into multiple methods #4413

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

birkenfeld
Copy link
Member

Intended to start a discussion, about APIs, but also names :)

Similar to call(), introduces new0(), new1() and new_args(), and the same on Exception types as new_err0(), new_err1() and new_err_args().

After the deprecation cycle, new1() could be renamed back to new(), since it is the one used in the vast majority of cases.

I kept PyErrArguments, but it's now only implemented for tuples, not for all Python-convertible types.

@davidhewitt
Copy link
Member

Related: I have been wondering for a while about a new call syntax and you have prompted me to actually write that up: #4414

Maybe we could have py_call!{ PyValueError(a, b, c) } ? 🤔

I think new1 here as suggested is "call this with one positional argument"? We should be careful as our .call1 for object calls is "call this object with a tuple of arguments".

@birkenfeld
Copy link
Member Author

Good point... I'm not fond of the names anyway, especially the new1 would probably be new in a green field, and could be after the deprecation cycle.

Could new0 be empty? IMO doesn't work too well for exceptions...

@birkenfeld
Copy link
Member Author

Changed the names to new_empty, new_arg, and new_args, with the expectation to rename new_arg back to new after two versions.

new_empty could also be done away with completely, since it's seldom used, and replaced by new_args(()).

Introduces new_empty(), new_arg() and new_args(), and
the same on Exception types as new_err_empty(), new_err_arg() and
new_err_args().

After the deprecation cycle, new_arg() could be renamed back to new(),
since it is the one used in the vast majority of cases.

I kept `PyErrArguments`, but it's now only implemented for tuples,
not for all Python-convertible types.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants