python-dev Summary for 2003-03-16 through 2003-03-31
This is a summary of traffic on the python-dev mailing list from March 16, 2003 through March 31, 2003. It is intended to inform the wider Python community of on-going developments on the list and to have an archived summary of each thread started on the list. To comment on anything mentioned here, just post to email@example.com or comp.lang.python with a subject line mentioning what you are discussing. All python-dev members are interested in seeing ideas discussed by the community, so don't hesitate to take a stance on something. And if all of this really interests you then get involved and join python-dev!
This is the fourteenth summary written by Brett Cannon (Managed to keep my sanity as long as A.M. Kuchling did before he stopped doing the Summaries =).
All summaries are archived at http://www.python.org/dev/summary/ .
Please note that this summary is written using reStructuredText which can be found at http://docutils.sf.net/rst.html . Any unfamiliar punctuation is probably markup for reST (otherwise it is probably regular expression syntax); you can safely ignore it (although I suggest learning reST; its simple and is accepted for PEP markup). Also, because of the wonders of programs that like to reformat text, I cannot guarantee you will be able to run the text version of this summary through Docutils as-is unless it is from the original text file.
PyCon is now over! It was a wonderful experience. Getting to meet people from python-dev in person was great. The sprint was fun and productive (work on the AST branch, caching where something is found in an inheritance tree, and a new CALL_ATTR opcode were all worked on). It was definitely worth attending; I am already looking forward to next year's conference.
I am trying a new way of formatting the Quickies section. I am trying non-inline implicit links instead of inlined ones. I am hoping this will read better in the text version of the summary. If you have an opinion on whether the new or old version is better let me know. And remember, the last time I asked for an opinion Michael Chermside was the only person to respond and thus ended up making an executive decision.
This developed from a thread from covered in the last summary that discussed the different uses of lists and tuples. By the start date for this summary, though, it had turned into a discussion on comparisons. This occured when sorting heterogeneous objects came up. Guido commented that having anything beyond equality and non-equality tests for non-related objects does not make sense. This also led Guido to comment that "TOOWTDI makes me want to get rid of __cmp__" (TOOWTDI is "There is Only One Way to Do It").
Now before people start screaming bloody murder over the possible future loss of __cmp__() (which probably won't happen until Python 3), realize that all comparisons can be done using the six other rich comparisons (__lt__(), __eq__(), etc.). There is some possible code elegance lost if you have to use two rich comparisons instead a single __cmp__() comparison, but it is nothing that will prevent you from doing something that you couldn't do before. There can also be a performance penalty in sorting in some instances.
This all led Guido to suggest introducing the function before(). This would be used for arbitrary ordering of objects. Alex Martelli said it would "be very nice if before(x,y) were the same as x<y whenever the latter doesn't raise an exception, if feasible". He also said that it should probably "define a total ordering, i.e. the implied equivalence being equality".
There has been rumblings on the list as of late of disallowing shadowing of built-ins. Specifically, the idea of someone injecting something into a module's namespace that overrides a global (by doing something like socket.len = lambda x: 42 from the socket module) is slightly nasty, rarely done, and prevents the core from optimizing for built-ins.
Raymond Hettinger, in an effort to see how to speed up built-in access, came up with the idea of replacing opcode calls of LOAD_GLOBAL and replace them with LOAD_CONST after putting the built-in being called into the constants table. This would leave shadowing of built-ins locally unaffected but prevent shadowing at the module. Raymond suggested turning on this behavior for when running Python -O.
The idea of turning this on when running with the -O option was shot down. The main argument is that semantics are changed and thus is not acceptable for the -O flag. It was mentioned that -OO can change semantics, but even that is questionable.
So this led to some suggestions of how to turn this kind of feature on. Someone suggested something like a pragma (think Perl) or some other mechanism at the module level. Guido didn't like this idea since he does not want modules to be riddled with code to turn on module-level optimizations.
But all of this was partially shot down when Guido stepped in and reiterated he just wanted to prevent outside code from shadowing built-ins for a module. The idea is that if it can be proven that a module does not shadow a built-in it can output an opcode specific for that built-in, e.g. len() could output opcode for calling PyOject_Size() if the compiler can prove that len() is not shadowed in the module at any point.
Neil Schemanauer suggested adding a warning for when this kind of shadowing is done. Guido said fine as long as extension modules are exempt. Now no matter how well the warning is coded, it would be extremely difficult to catch something like import X; d = X.__dict__; d["len"] = lambda x: 42. How do you deal with this? By Guido saying he has not issue saying something like this "is always prohibited". He said you could still do setattr(X, "len", lambda x: 42), though, and that might give you a warning. Neil's patch can be found at http://www.python.org/sf/711448 .
The thread that will not die (nor does it look like it will in the near future; Guido asked to postpone discussing it until he gets back from Python UK which will continue the discussion into the next summary. I am ending up an expert at capabilities against my will. =)
In case you have not been following all of this, capabilities as being discussed here is the idea that security is based on passing around references to objects. If you have a reference you can use it with no restrictions. Security comes in by controlling who you give references to. So I might ask for a reference to file(), but I won't necessarily get it. I could, instead, be handed a reference to a restrictive version of file() that only opens files in an OSs temporary file directory. So, in capabilities-land, executing open_file = file only works if you have the reference to 'file', otherwise the assignment fails and you just don't get access. If that is not clear, read the last summary on this thread. And now, on to the new stuff...
There were also suggestions to add arguments to import statements to give a more fine-grained control over them. But it was pointed out that classes fit this bill.
The idea of limiting what modules are accessible by some code by not using a universally global scope (i.e., not using sys.modules) but by having a specific scope for each function was suggested. As Greg Ewing put it, "it would be dynamic scoping of the import namespace".
While trying to clarify things (which were at PyCon thanks to the Open Space discussion held there on this subject), a good distinction between a rexec world (as in the module) and a capabilities was made by Guido. In capabilities, security is based on passing around references that have the amount of power you are willing for it to have. In a rexec world, it is based on what powers the built-ins give you; there is no worry about passing around code. Also, in the rexec world, you can have the idea of a "workspace" where __builtin__ has very specific definitions of built-ins that are used when executing untrusted code.
It has been pointed out that rexec can be viewed as a specific implementation of capabilities. Since you are restricting what references code by making only certain references available to the codes you are using capabilities, just more at a namespace level than on a per-reference level.
Ka-Ping Yee wrote up an example of some code of what it would be like to code with capabilities (can be found at http://mail.python.org/pipermail/python-dev/2003-March/034287.html ).