Issue511219
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2002-01-31 14:55 by douady, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Files | ||||
---|---|---|---|---|
File name | Uploaded | Description | Edit | |
python.diff | douady, 2002-01-31 14:55 | diff --context -N -R of the patch |
Messages (12) | |||
---|---|---|---|
msg38831 - (view) | Author: Cesar Douady (douady) | Date: 2002-01-31 14:55 | |
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). |
|||
msg38832 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-03-18 08:59 | |
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. |
|||
msg38833 - (view) | Author: Cesar Douady (douady) | Date: 2002-03-19 10:57 | |
Logged In: YES user_id=428521 Granted. Seems fair. |
|||
msg38834 - (view) | Author: Cesar Douady (douady) | Date: 2002-03-28 17:30 | |
Logged In: YES user_id=428521 This patch has been generated from python version 2.2. |
|||
msg38835 - (view) | Author: Cesar Douady (douady) | Date: 2002-03-30 00:08 | |
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. |
|||
msg38836 - (view) | Author: Michael Hudson (mwh) | Date: 2002-03-30 11:27 | |
Logged In: YES user_id=6656 And there's precisely no way it's going into 2.2.x. |
|||
msg38837 - (view) | Author: Cesar Douady (douady) | Date: 2002-04-02 11:21 | |
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). |
|||
msg38838 - (view) | Author: Michael Hudson (mwh) | Date: 2002-04-02 14:26 | |
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. |
|||
msg38839 - (view) | Author: Cesar Douady (douady) | Date: 2002-04-02 18:08 | |
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. |
|||
msg38840 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-08-12 09:15 | |
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. |
|||
msg38841 - (view) | Author: Cesar Douady (douady) | Date: 2002-08-13 18:22 | |
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. |
|||
msg38842 - (view) | Author: Martin v. Löwis (loewis) * | Date: 2002-08-13 18:25 | |
Logged In: YES user_id=21627 Thanks for the update. Closing it. |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:56 | admin | set | github: 36007 |
2002-01-31 14:55:54 | douady | create |