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-36876: Avoid static locals. by ericsnowcurrently · Pull Request #13372 · python/cpython Conversation
|
| mpd_setminalloc(mpd_ssize_t n) | ||
| { | ||
| static int minalloc_is_set = 0; | ||
| static int minalloc_is_set = 0; // Static is okay here (process-global). |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Please don't change libmpdec, even if it's just a comment. :)
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.
move all locally scoped _Py_IDENTIFIER() to global scope
I dislike this change. I prefer to keep "local" static variables in functions. I don't see how moving them as globals is solving any issue, apart your practical issue of detecting them with your tool.
I would prefer to see an API to support static variable per interpreter.
I would suggest to develop an hash table similar to thread TLS: each static variable would have a global unique identifier, and its value would stored in an hash table in the PyInterpreterState. The problem is how to initialize the global unique identifier in a safe way (thread safety / atomicity). But that could be implemented using "local static" variables.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
When you're done making the requested changes, leave the comment: |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| format_ctime(PyDateTime_Date *date, int hours, int minutes, int seconds) | ||
| { | ||
| static const char * const DayNames[] = { | ||
| static const char * const DayNames[] = { // Static is okay here (immutable data). |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
Are these comments really useful? To me, it seems obvious that static constants are safe. I'm not sure of the value of such comment.
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.
A comment sounds useful to flag all local statics as "good" and for a linter that checks for unverified local static vars. I'm ok with the comments, but maybe a shorter one like // static ok.?
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 agree with @vstinner. If you really want to keep these comments, please move them to separate lines to avoid noise when using git blame.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
I forgot to mention that "local static variables" would be easier to initialize properly, since they cannot be accessed before the function is called: before Python is initialized. The case of global static variables is worse: we cannot statically initialize them, we need something to dynamically initialize them. Maybe at the first access? About the global unique identifier, one solution would be to use the memory address of the variable: it should be unique. I don't see why a compiler would merge two variables. Draft pseudo API: Problem: we cannot pre-allocate the storage of "var" value into the interpreter "local storage" hash table, so set_interpreter_specific() can fail with a memory allocation failure :-( |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
@ericsnowcurrently Please re-generate the ast module: |
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.
As Victor has also requested, I'd remove all comments that mention that variables are process local.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
When you're done making the requested changes, leave the comment: |
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.
overall i'm a little concerned about how fragile this is. it won't be obvious in all code why something static lives outside of the only place it is used. it feels like we need a way to prevent future C code authors from making this mistake.
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| date_fromisocalendar(PyObject *cls, PyObject *args, PyObject *kw) | ||
| { | ||
| static char *keywords[] = { | ||
| static char *kwlist[] = { |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
is there a reason all of the kwlist's everywhere cannot become static const? (lemme guess.. our C API complains about the type?)
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| return NULL; | ||
| } | ||
| return PyObject_GetAttr(im->im_func, docstr); | ||
| // if (cached_str___doc__ == NULL) { |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
checking in a block of commented out code looks wrong... what's up here?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
| _Py_IDENTIFIER(last_type); | ||
| _Py_IDENTIFIER(last_value); | ||
| _Py_IDENTIFIER(lineno); | ||
| _Py_IDENTIFIER(msg); |
There was a problem hiding this comment.
The reason will be displayed to describe this comment to others. Learn more.
could the _Py_IDENTIFIER macro be modified such that it only works from the global scope so that these don't creep back into function bodies?
Sorry, something went wrong.
There was an error while loading. Please reload this page.
|
Thanks for all the feedback, everyone! I'm going to re-think this as you've all made good points. :) I may re-open the PR if it later makes sense to re-purpose it, but I'll probably instead tackle the statics in groups by |
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.