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

gh-121404: avoid accessing compiler internals in codegen functions #121538

Merged
merged 8 commits into from
Jul 10, 2024

Conversation

iritkatriel
Copy link
Member

@iritkatriel iritkatriel commented Jul 9, 2024

These are some simple transformations to hide compiler internals, as part of the work to split compile.c into codegen and compiler.
The individual commits should be easy to review.

Copy link
Contributor

@jeremyhylton jeremyhylton left a comment

Choose a reason for hiding this comment

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

I think this makes sense overall. It took a bit of reading to understand the intent, and it might be helpful to have a more descriptive commit message.

If I understand correctly, the core idea is to take four features that are tied to the current compiler_unit and hide the details of the compiler_unit in accessor functions.

I wasn't sure if there was a reason to do exactly these four, or if this was just an intermediate step and you'll cover other features in a future change.

What's the rationale for the accessor functions? I assume you'll split the code in a future change, so that the compiler_unit will not be visible in some parts of the code.

The detailed comments along the way were from me reading and understanding. For most of them, you don't need to do anything unless you want to correct a misunderstanding on my part.

Python/compile.c Show resolved Hide resolved
Python/compile.c Show resolved Hide resolved
#define INSTR_SEQUENCE(C) compiler_instr_sequence(C)
#define FUTURE_FEATURES(C) compiler_future_features(C)
#define SYMTABLE(C) compiler_symtable(C)
#define SYMTABLE_ENTRY(C) compiler_symtable_entry(C)
Copy link
Contributor

Choose a reason for hiding this comment

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

How much do the macros buy us? The actual function names are simple enough and only slightly longer. It might be simpler to just drop the indirection.

Copy link
Member Author

Choose a reason for hiding this comment

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

After we split the compiler to a separate file, and start thinking about making things configurable, the indirection might turn out useful (you can redefine the macro to do something else). I don't know if we will, but wanted to keep the option for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'd be inclined to add it later if it's needed (yagni and all), but I don't feel strongly about it. Whatever works for you :-).

Python/compile.c Show resolved Hide resolved
Python/compile.c Show resolved Hide resolved
Python/compile.c Show resolved Hide resolved
Python/compile.c Show resolved Hide resolved
@iritkatriel
Copy link
Member Author

Thanks. I tried to give some rationale in the issue.
This is indeed one step in the process.

Eventually I want to have a small file with the compiler/ compiler_unit implementation, and a larger file that accesses them through opaque pointers (and has all the code-generation logic for individual AST nodes). The code generation file will be simple, so the complexity ends up contained in a smaller file.

It needs abstractions like here, moving some functionality from the compiler to the symtable (#121272), etc.

@iritkatriel iritkatriel merged commit 0177a34 into python:main Jul 10, 2024
39 checks passed
noahbkim pushed a commit to hudson-trading/cpython that referenced this pull request Jul 11, 2024
estyxx pushed a commit to estyxx/cpython that referenced this pull request Jul 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) skip news
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants