suppress type restrictions on locals()

[douady]

BPO	511219
Nosy	@mwhudson, @loewis
Files	python.diff: diff --context -N -R of the patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2002-08-13.18:25:08.000>
created_at = <Date 2002-01-31.14:55:54.000>
labels = ['interpreter-core']
title = 'suppress type restrictions on locals()'
updated_at = <Date 2002-08-13.18:25:08.000>
user = 'https://bugs.python.org/douady'

bugs.python.org fields:

activity = <Date 2002-08-13.18:25:08.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2002-01-31.14:55:54.000>
creator = 'douady'
dependencies = []
files = ['3934']
hgrepos = []
issue_num = 511219
keywords = ['patch']
message_count = 12.0
messages = ['38831', '38832', '38833', '38834', '38835', '38836', '38837', '38838', '38839', '38840', '38841', '38842']
nosy_count = 3.0
nosy_names = ['mwh', 'loewis', 'douady']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue511219'
versions = ['Python 2.3']

[douady]

This patch suppresses the restriction that global and
local dictionaries do not access overloaded __getitem__
and __setitem__ if passed an object derived from class
dict.

An exception is made for the builtin insertion and
reference in the global dict to make sure this object
exists and to suppress the need for the derived class
to take care of this implementation dependent detail.

The behavior of eval and exec has been updated for code
objects which have the CO_NEWLOCALS flag set : if
explicitely passed a local dict, a new local dict is
not generated. This allows one to pass an explicit
local dict to the code object of a function (which
otherwise cannot be achieved). If this cannot be done
for backward compatibility problems, then an
alternative would consist in using the "new" module to
create a code object from a function with CO_NEWLOCALS
reset but it seems logical to me to use the information
explicitely provided.

Free and cell variables are not managed in this
version. If the patch is accepted, I am willing to
finish the job and implement free and cell variables,
but this requires a serious rework of the Cell object:
free variables should be accessed using the method of
the dict in which they relies and today, this dict is
not accessible from the Cell object.

Robustness : Currently, the plain test suite passes
(with a modification of test_desctut which precisely
verifies that the suppressed restriction is enforced).
I have introduced a new test (test_subdict.py) which
verifies the new behavior.

Because of performance, the plain case (when the local
dict is a plain dict) is optimized so that differences
in performance are not measurable (within 1%) when run
on the test suite (i.e. I timed make test).

[loewis]

Logged In: YES
user_id=21627

This is quite a complex change. If you want to see it
integrated, I recommend that you find people that try it out
and report their experience here.

[douady]

Logged In: YES
user_id=428521

Granted. Seems fair.

[douady]

Logged In: YES
user_id=428521

This patch has been generated from python version 2.2.

[douady]

Logged In: YES
user_id=428521

to install this patch from python revision 2.2, follow these
steps :

• get the python.diff file from this page
• cd Python-2.2
• run "patch -p1 <wherever_you_put_the_file/python.diff"
• make clobber
• make recheck
• make
• make test
  the reason you cannot just type make to rebuild everything
  is that .h files are not checked when modules are
  recompiled. Thus they are not, unless you remove them with
  "make clobber". make recheck is to rebuild pyconfig.h.

[mwhudson]

Logged In: YES
user_id=6656

And there's precisely no way it's going into 2.2.x.

[douady]

Logged In: YES
user_id=428521

I successfully applied the patch as is to revision 2.2.1c2
with the following output (and then the same procedure as
mentioned for patching revision 2.2) :

patching file Include/dictobject.h
patching file Include/frameobject.h
patching file Include/object.h
patching file Lib/test/test_descrtut.py
patching file Lib/test/test_subdict.py
patching file Modules/cPickle.c
patching file Objects/classobject.c
patching file Objects/frameobject.c
patching file Python/ceval.c
Hunk #2 succeeded at 1534 (offset 3 lines).
Hunk #4 succeeded at 1613 (offset 3 lines).
Hunk #6 succeeded at 1655 (offset 3 lines).
Hunk #8 succeeded at 1860 (offset 3 lines).
Hunk #10 succeeded at 1889 (offset 3 lines).
Hunk #12 succeeded at 2635 (offset 3 lines).
Hunk #14 succeeded at 2893 (offset 3 lines).
Hunk #16 succeeded at 3038 (offset 3 lines).
Hunk #18 succeeded at 3657 (offset 3 lines).
Hunk #20 succeeded at 3722 (offset 3 lines).
patching file Python/compile.c
Hunk #1 succeeded at 2916 (offset 12 lines).
patching file Python/import.c
Hunk #1 succeeded at 1668 (offset -4 lines).
Hunk #3 succeeded at 1716 (offset -4 lines).
patching file Python/sysmodule.c
Hunk #1 succeeded at 238 (offset -4 lines).

[mwhudson]

Logged In: YES
user_id=6656

So what?

Maybe you misunderstand me. This patch was in the group
"Python 2.2.x", which is the group we use for patches that
are under consideration for being put into a 2.2.x release of
Python (or in other words, a bugfix release of Python 2.2).

This patch is not going to go into a bugfix release of Python
2.2 for at least two reasons: (1) it adds what is arguably a
new feature and (2) it's big and complicated and so might
cause bugs.

And now I've actually looked at the patch, it has even less
chance: it would break binary compaitibilty of extensions.

So while I'm not against the patch in general (looks good,
from an eyballing), it doesn't belong in the 2.2.x group.

[douady]

Logged In: YES
user_id=428521

Well,
I think I am in sync now.
1/ I did take you initial comment as meaning the patch could
not be applied to 2.2.x
2/ I decided to generate a new patch to be applied to 2.2.1c2
3/ I realized that the patch could be applied as is
4/ I was lost
5/ I realized the meaning of the group was the one you just
mentioned.
6/ I decided to post the result of my trial anyway so people
could confidently apply the patch the lastest release
(specially because patch outputs some warnings).
7/ I did not understand this place could actually be used as
a forum (i.e. reply to previous post rather than general info).
Let me apologize for my previous misunderstandings.

about compatibility :
I did not find a way to make it backward binary compatible,
however my intent is to make it source compatible for
extensions.

[loewis]

Logged In: YES
user_id=21627

What is the status of this patch? Could you find people who
are interested in using this feature?

If not, I'm tempted to reject it.

[douady]

Logged In: YES
user_id=428521

I am personally in favor of rejecting it for the following
reasons :

• I managed to work around this restriction (so that I could
  keep using the standard python)
• I am not 100% sure the patch I proposed is bullet proof.
• It is partial anyway (some combination of nested scopes
  with non standard local dicts are not implemented).
• It is very complicated.
• It does not seem a lot of people is interested.

[loewis]

Logged In: YES
user_id=21627

Thanks for the update. Closing it.