Skip to content

Make OSError subclass instead of itself #2960

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

Merged
merged 38 commits into from
Oct 7, 2021

Conversation

ChJR
Copy link
Contributor

@ChJR ChJR commented Aug 24, 2021

This PR will fix #2914.

@@ -581,6 +583,126 @@ macro_rules! extends_exception {
};
}

macro_rules! extends_os_error {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont' think we need an own macro for this error. We can write it without macro or using new macro #2897

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to use tp_new for OSError itself. So I will change it without macro.

@youknowone
Copy link
Member

@sobolevn Could you look into this PR? This PR is a sort of use case of exception macro. It maybe helpful to give you an idea to decide to choose one.

Copy link
Contributor

@sobolevn sobolevn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like that this use-case fits perfectly into

macro_rules! extend_exception {
( $ctx:expr, $class:expr, { $($name:expr => $value:expr),* $(,)* }) => {
$class.set_str_attr("__new__", $ctx.new_method("__new__", $class.clone(), PyBaseException::tp_new));
$class.set_str_attr("__init__", $ctx.new_method("__init__", $class.clone(), PyBaseException::init));
extend_class!($ctx, $class, {
$(
$name => $value,
)*
});
};
}

We can re-assign slots with it, but it needs a little polish.
I will send a PR soon! Later we can rebase this one and merge it 👍

Thanks!

Comment on lines 1563 to 1565
fn base_exception_new(cls: PyTypeRef, args: FuncArgs, vm: &VirtualMachine) -> PyResult {
PyBaseException::slot_new(cls, args, vm)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if these methods are not required to be moved, keep them on the original place. they will be put in impl later once we revise pyexception macro

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are used in define_macro.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it is used. I don't see a good reason why it need to be moved to here. I checked out the code and tried to compile it without moving this function. I couldn't see any problem.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. I moved functions just for distinguishing functions and macros. For readability, if you want not moving the functions I can revert that.

vm/src/lib.rs Outdated
@@ -85,6 +85,8 @@ pub use rustpython_common as common;
#[cfg(feature = "rustpython-compiler")]
pub use rustpython_compiler as compile;

use crate::stdlib::errno::errors;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this module imported here? I expect this is imported from os_error_optional_new.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My mistake.

Comment on lines 1563 to 1565
fn base_exception_new(cls: PyTypeRef, args: FuncArgs, vm: &VirtualMachine) -> PyResult {
PyBaseException::slot_new(cls, args, vm)
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree it is used. I don't see a good reason why it need to be moved to here. I checked out the code and tried to compile it without moving this function. I couldn't see any problem.

@ChJR ChJR requested a review from youknowone October 5, 2021 13:38
@ChJR ChJR force-pushed the feature/OSError-Subclass-Ctor branch from 8d96a6b to a504a74 Compare October 6, 2021 18:08
@ChJR ChJR force-pushed the feature/OSError-Subclass-Ctor branch from 7a2eb2a to d913c45 Compare October 7, 2021 14:56
@youknowone youknowone force-pushed the feature/OSError-Subclass-Ctor branch from aa3beda to 7f8562a Compare October 7, 2021 17:33
@youknowone youknowone merged commit 296f183 into RustPython:main Oct 7, 2021
@youknowone
Copy link
Member

Thank you for contributing! Instead of merge, please try to use rebase next time.

@ChJR ChJR deleted the feature/OSError-Subclass-Ctor branch October 8, 2021 16:36
@youknowone youknowone mentioned this pull request Oct 10, 2021
@youknowone youknowone added the z-ca-2021 Tag to track contrubution-academy 2021 label Oct 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
z-ca-2021 Tag to track contrubution-academy 2021
Projects
None yet
Development

Successfully merging this pull request may close these issues.

OSError has invalid __new__
3 participants