GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||||
GeezerVison is showing github.com — bpo-39981: Default values for AST nodes by isidentical · Pull Request #19031 · python/cpython Conversation
|
|
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Some initial comments, without commenting on the approach itself. @serhiy-storchaka should confirm that he is happy with this approach as he was working on some related functionality. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I don't understand this function. When we set the node_type._field_defaults we could already place None or [] in there instead of this intermediary "?" and "*".
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I dont think so, at least for lists. We are keeping _field_defaults as the same way we keep _fields, arrays of const char pointers. And then we construct a tuple from them and intern the values. I dont think it would be practical to do this with the original values.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
I don't fully understand the problem. What is wrong with having _field_defaults as a list of the defaults themselves? When constructing the _field_defaults tuple you can do this logic already and populate them with None or the empty list or whatever, no?
For instance, in the make_type function you could set the defaults in the tuple instead of interning the strings.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Ah, that makes sense. Do you have an idea about what we should put if there is no field default, I think Ellipsis should work.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
You don't need that if you use a dictionary instead of a tuple
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
I have made the requested changes; please review again |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Thanks for making the requested changes! @pablogsal: please review the changes made to this pull request. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
9cdb15f to
0cbc2a8
Compare
|
@serhiy-storchaka It would be awesome to have your review / thoughts on this before alpha cut. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Closing this in favor of #21417 |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.