a new PEP?

[Martin v. Löwis]

vm_usenet at yahoo.com (vm_usenet) writes:

> What I'm proposing is to dump the current approach of static/global
> variables in the python source and to make the python interpreter
> state-oriented. 

Please understand that this can't be achieved through a proposal: Many
existing C modules which are not part of the Python core use global
variables as well. Somebody will have to change those modules -
writing a PEP doesn't help.

> do_something_with_interpreter_on_first_thread(new_interpreter);
> do_something_with_interpreter_on_other_thred(yetanother_interpreter);

This hints to the real problem with the proposal: you would *always*
need access to current interpreter. That is, even calls like
PyInt_FromLong would need to receive the current interpreter - to
implement the feature that small integers are interned, using a global
table. Even a call like Py_DECREF would need the current interpreter,
since the destructor might need the interpreter.

It would also be difficult to deal with type objects: Would you want
type objects to be shared across interpreters, or would you want each
interpreter to have its own set of type objects? If the latter, how
would you create what now is a "static" type object?

> Is there any way I can post this proposal to the PEP list?

If you still think this is implementable, you should formulate this as
a proper PEP, i.e. writing down all API changes, and outlining an
implementation strategy. Then, you can submit it to the PEP editor.

> In case you're wondering why we should need such a feature - imagine
> an application powered by Python as an extension language - and then
> running two extensions in two different threads. Not so far-fetched,
> anyway...

With the current implementation strategy, this is not necessarily a
problem. The existing extension modules should cope with it just fine;
third-party (i.e. your) extension modules don't work correctly, they
need to be fixed.

Regards,
Martin