[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[STINNER Victor]

Change by STINNER Victor :


--
resolution:  -> out of date
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[STINNER Victor]

STINNER Victor added the comment:

My PR 780 doesn't support multiple Python interpreters in the same process. To 
support that, we need a more advanced solution. For example, add an hash table 
in the interpreter structure using the variable memory address as the key.

Maybe we can move step by step and start with the PR 780, and only later 
support multiple interpreters. PR 780 enhances the most common case, Python 
running a single interpreter.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

What if use the term "singleton"? It includes "initialize once" and "finalize 
at shutdown" meanings. _Py_INIT_SINGLETON() or _Py_SET_SINGLETON()?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[STINNER Victor]

STINNER Victor added the comment:

I dislike _Py_SET_FINALIZED and _Py_SET_ONCE name.

I prefer to mention an "initialization" because it's a common pattern in 
programming and it is known that it only requires to be done once.

_PY_ONCEVAR_INIT() macro is unusual: it only evaluate the second parameter 
parameter, a C expression, if the variable is not initialized yet.

Py_SETREF() is different because it always evaluates its second argument, and 
in most cases, the second argument is an existing variable and not an 
expression.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Louie Lu]

Changes by Louie Lu :


--
nosy: +louielu

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Can you move forward this issue Victor? I'm very interesting in it. It is worth 
to advertise this API on Python-Dev.

_PyArg_Parser also can utilize this API.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Nick Coghlan]

Nick Coghlan added the comment:

_PY_SET_FINALIZED is only one letter longer than _PY_ONCEVAR_INIT and the same 
length as the originally proposed _PY_STATICVAR_INIT.

Since it shouldn't be anywhere near as common as _Py_SETREF, I'm also okay in 
general with trading a bit of brevity for accuracy.

However, I don't want to trade away *too* much brevity, so I think we're going 
to have to choose between reminding readers of "this is finalized in 
Py_Finalize" or "this is a no-op if the target is already set", and leave the 
other aspect implicit.

In addition to the correctness argument above, my rationale for now favouring 
the former is that the logical leap in "this is finalized in Py_Finalize, so 
the assigned expression will only be executed once per Py_Initialize call" 
seems more reasonable to me than the one in "the assigned expression is only 
executed once per Py_Initialize call, so it will be finalized in Py_Finalize".

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I agree with your rationale Nick, but _Py_SET_FINALIZED is a little too long 
and highlight only the second function of the macro. I don't have good name.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Nick Coghlan]

Nick Coghlan added the comment:

I'm +1 for _Py_SET_FINALIZED with the semantics Serhiy suggests, and +0 for 
_Py_SET_ONCE.

My rationale for that preference is that _Py_SET_ONCE is a misnomer in the 
presence of

* multiple Py_Initialize/Py_Finalize cycles; and/or
* _Py_SETREF calls that replace the value to be finalized

 while _Py_SET_FINALIZED remains accurate in both cases.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Ping. My suggestion is to rename _PY_ONCEVAR_INIT to _Py_SET_ONCE and make it 
returning the value. And apply this to more static and global variables.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Nick Coghlan]

Nick Coghlan added the comment:

For module level variables, I'd expect this API to need to be used in tandem 
with switching the module over to PEP 489 multi-phase initialization.

By calling the new API in their _Py_mod_exec slot implementation, extension 
modules should be able to handle multiple initialize/finalize cycles correctly: 
https://www.python.org/dev/peps/pep-0489/#subinterpreters-and-interpreter-reloading

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Nick Coghlan]

Nick Coghlan added the comment:

The main potential benefit I see to keeping the special variable declaration is 
that it may help avoid a certain category of error: calling _Py_ONCE_VAR_INIT 
on a stack local pointer reference (which would leave the global array with a 
reference to nonsense). While we don't care if the once_vars are static or not, 
we do care that they're not allocated on the call stack, as otherwise they 
won't be around for Py_Finalize() to clean up.

On the other hand, _Py_SET_ONCE is nice and easy to explain "it's similar to 
_Py_SETREF, but: 1) doesn't do anything if the reference is already set; and 2) 
registers the reference to be cleaned up in Py_Finalize"

Also interesting is the fact that you can still use _Py_SETREF to change a 
reference that was initialized with _Py_SET_ONCE without breaking anything. 
From that point of view, a better name might be _Py_SET_FINALIZED, emphasising 
the fact that it registers the pointer for finalization over the fact that it's 
a no-op when run on an already set pointer.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Some code (_PyUnicode_FromId, bool_repr, create_filter) could be simpler if 
make _PY_ONCEVAR_INIT returning the value (NULL in case of error).

The signature of _PY_ONCEVAR_INIT() is the same as of _Py_SETREF(). If var == 
NULL both `_PY_ONCEVAR_INIT(var, expr)` and `_Py_SETREF(var, expr)` are 
equivalent to just `var = expr`. Maybe rename _PY_ONCEVAR_INIT to _Py_SET_ONCE?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[STINNER Victor]

STINNER Victor added the comment:

I modified more modules to use the new API. I'm not sure that using the API in 
modules is safe.

It's safe to use the API in functions which begins with trying to initialize 
the variable. In such case, if the variable is cleared, calling the function 
later initialize again the variable and it's fine.

When for module variables only initialized when the module is initialized, 
there is a risk that a module function tries to access a variable which has 
been cleared previously during Python shutdown.

See for example changes in the _datetime module.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue29881] Add a new private API clear private variables, which are initialized once, at Python shutdown

[STINNER Victor]

Changes by STINNER Victor :


--
title: Add a new private API for "static C variables" (_PyStaticVar) to clear 
them at exit -> Add a new private API clear private variables, which are 
initialized once, at Python shutdown

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com