Guys have about 24 hours to point out how imperfect the summary is. For those who participated in the `Capabilities` thread, please check my summary. I feel a little shaky about it and feel I could add more detail, but I didn't want to add any wrong info so I kept it rather shallow. ------------------ python-dev Summary for 2003-03-01 through 2003-03-15 +++++++++++++++++++++++++++++++++++++++++++++++++++++ .. _last summary: ====================== Summary Announcements ====================== As I am sure most readers of this summary know by now, I am going to PyCon_. This means that I will be occupied the whole last week of this month. I suspect python-dev traffic will be light since I believe most of PythonLabs will be at Pycon and thus not working. =) But still, I will be occupied myself and thus won't have a chance to work on the summary until I come home. This means you should expect the next summary to be rather late. I will get to it, though, at some point. And in case you haven't yet, register for PyCon_. .. _PyCon: http://www.python.org/pycon/ ============================================= `Ridiculously minor tweaks?`__ ============================================= __ http://mail.python.org/pipermail/python-dev/2003-March/033962.html Splinter threads: - `How long is your shopping tuple? http://mail.python.org/pipermail/python-dev/2003-March/033996.html`__ - `Tuples vs lists http://mail.python.org/pipermail/python-dev/2003-March/033981.html`__ - `Re: lists v. tuples http://mail.python.org/pipermail/python-dev/2003-March/034029.html`__ - `mutability http://mail.python.org/pipermail/python-dev/2003-March/034057.html`__ The original point of this thread was Jeremy Fincher finding out if patches changing lists to tuples where the list was not mutated would be accepted for a miniscule performance boost (the answer was no). But this wasn't the interesting knowledge that came out of this thread. This thread led to Guido stating his intended uses of tuples and lists. And you might be going, "lists are for mutable sequences of objects while tuples are for immutable sequences of objects". Well, that is not what Guido thinks of lists and tuples (and don't feel bad if you thought otherwise; Christian Tismer didn't even know what Guido had in mind and Python does not exactly require you to agree with Guido on this). Turns out that tuples, in Guido's view of the world, are "for heterogeneous data" and "list[s] are for homogeneous data"; "Tuples are *not* read-only lists". Guido spelled out his thinking on this in a later email. He basically said that he viewed lists as "a sequence of items of type X" while tuples are more like "a sequence of length N with items of type X1, X2, X3, ..." This makes sense since lists can be sorted while tuples can't; sorting on different types don't necessarily result in a sequence sorted the way you think about it. And if you are still having issues of wrapping your head around this, just view tuples as structs and lists as arrays as in C. This thread then led to another topic of comparisons_ in Python. Guido ended up mentioning how he wished == and != worked on all types (with disparate types always being !=) while all of the other comparisons only worked on similar types for the interpreter's default comparison abilities. This then led to Guido saying how he wished the __cmp__() magic method and the cmp() built-in didn't exist. This is because there are currently two ways to do comparisons; __cmp__(), and then all of the other rich comparison magic methods. You can implement the same functionality as __cmp__() using just __lt__() and __eq__(). There can also be an unneeded performance penalty for __cmp__() since (using the previously mentioned way of re-implementing __cmp__()) you might have to do some unneeded comparisons when all you need is __eq__(). This discussion is still going on. .. _comparisons: http://www.python.org/dev/doc/devel/ref/customization.html#l2h-91 =========================== `Capabilities in Python`__ =========================== __ http://mail.python.org/pipermail/python-dev/2003-March/033820.html Splinter threads: - `Capabilities http://mail.python.org/pipermail/python-dev/2003-March/033854.html`__ - `about candy http://mail.python.org/pipermail/python-dev/2003-March/033986.html`__ This is a continuation of a discussion covered in the `last summary`_. This was *definitely* the thread from hell for this summary. =) It is very long and there was confusion at multiple points over terminology. You have been warned. Three things were constantly being discussed in this thread; restricted execution, capabilities, and proxies. We discuss them in this order. Restricted execution basically cuts out access to certain objects at execution time. Currently, if you replace the global __builtins__ with something other then what __builtin__.__dict__ has then you enable restricted execution in Python. This cuts off access to built-in objects so as to prevent you from circumventing security code by, for instance, importing the sys_ module so you can replace a module's code in sys.modules. Both capabilities and proxies are worthless without restricted execution since they could be circumvented without it. Capabilities can loosely be thought of like bound methods. Security with capabilities is done based on possession; if you hold a reference to an object you can use that object. Proxies are a wrapper around objects that restrict access to the object. This restriction extends all the way to the core; even core code can't get access to parts of a proxied object that it doesn't want any object to get a hold of. There was talk of a PEP on all of this but one has not appeared yet. .. _sys: http://www.python.org/dev/doc/devel/lib/module-sys.html ========= Quickies ========= `Codec registry http://mail.python.org/pipermail/python-dev/2003-March/033805.html`__ Gustavo Niemeyer asked someone to review a patch. `Changes to logging in CVS http://mail.python.org/pipermail/python-dev/2003-March/033811.html`__ Vinay Sajip if someone checked-in changes to the logging_ package could be rolled back since it broke compatibility with Python 1.5.2 which the logging package tries to keep (as mentioned in `PEP 291`_). The changes were removed. .. _logging: http://www.python.org/dev/doc/devel/lib/module-logging.html .. _PEP 291: http://www.python.org/peps/pep-0291.html `__slots__ for metatypes http://mail.python.org/pipermail/python-dev/2003-March/033815.html`__ Christian Tismer asked Guido and the list to take a look at a patch that would allow meta-types to have a __slots__. The patch was accepted and applied. `new bytecode results http://mail.python.org/pipermail/python-dev/2003-March/033817.html`__ Damien Morton continues on his quest to get performance boosts from fiddling with the eval loop contained in `ceval.c`_ and trying out various opcode ideas. It was pointed out that pystone_ is a good indicator of how Zope_ will perform on a new box. It was also stated by Tim Peters that since it is such an atypical test that it helps to make sure any improvements you make *really* do make an improvement. Damien also requested more people contribute statistical information to Skip Montanaro's stat server (more info at http://manatee.mojam.com/~skip/python/ ). .. ceval.c: .. _pystone: .. _Zope: http://www.zope.org/ `module extension search order - can it be changed? http://mail.python.org/pipermail/python-dev/2003-March/033826.html`__ This was discussed in the `last summary`_. Tim Peters mentioned how he doesn't use linecache_ often and that it's printing out of date info is of any great use for tracebacks. .. _linecache: http://www.python.org/dev/doc/devel/lib/module-linecache.html `JUMP_IF_X opcodes http://mail.python.org/pipermail/python-dev/2003-March/033823.html`__ Damien Morton, still on the prowl for better opcodes, suggested introducing opcodes that combined branching opcodes and POP_TOP (which pops the top of the interpreter stack)and did the pop based on the truth value of what was being tested. Neal Norwitz suggested that instead the branching instructions just always pop the stack. If all of this cool opcode stuff that Damien keeps doing interests you, you will want to read `opcode.h`_, `ceval.c`_, and learn how to use the dis_ module. .. _opcode.h: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Includ... .. _ceval.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Python... .. _dis: http://www.python.org/dev/doc/devel/lib/module-dis.html `Fun with timeit.py http://mail.python.org/pipermail/python-dev/2003-March/033826.html`__ A new module named timeit_ was added to the stdlib at the request of Jim Fulton. The module times the execution of code snippets. Guido timed the execution of going through a 'for' loop a million times with interpreters from Python 1.3 up to the current CVS (2.3a2 with patches up to that point). The result was that CVS was the fastest. .. _timeit: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Lib/ti... `Pre-PyCon sprint ideas http://mail.python.org/pipermail/python-dev/2003-March/033827.html`__ I asked the list to suggest ideas to sprint on at PyCon_. `More Zen http://mail.python.org/pipermail/python-dev/2003-March/033828.html`__ Words of wisdom from Raymond Hettinger that everyone should read. And if you have never read Raymond's `School of Hard Knocks`_ email you owe yourself to stop whatever you are doing and read it **now**. I can personally vouch that email is right on the money; I have experienced (or suffered, depending on your view =) every single thing on that list sans writing a PEP (although writing the Summary is starting to be enough writing to be equal =) . .. _School of Hard Knocks: http://mail.python.org/pipermail/python-dev/2002-September/028725.html `xmlrpclib http://mail.python.org/pipermail/python-dev/2003-March/033837.html`__ : `xmlrpclib: Apology http://mail.python.org/pipermail/python-dev/2003-March/033847.html`__ Bill Bumgarner, the "hillbilly from the midwest of the US", asked if the xmlrpclib_ module was being maintained. The lesson was also learned to not call Fredrick Lundh "Fred" on the list since Fred L. Drake, Jr. tends to be associated with the name. =) .. _xmlrpclib: http://www.python.org/dev/doc/devel/lib/module-xmlrpclib.html `httplib SSLFile broken in CVS http://mail.python.org/pipermail/python-dev/2003-March/033832.html`__ Something got broken and fixed. `super() bug (?) http://mail.python.org/pipermail/python-dev/2003-March/033846.html`__ Samuele Pedroni thought he may have found a bug with super() but turned out it wasn't. `test_popen broken on Win2K http://mail.python.org/pipermail/python-dev/2003-March/033857.html`__ Win2k does not like quoting of commands when there is no space in the command as Tim Peters discovered. There were discussions on how to deal with this. The suggestion of coming up with an sh-like syntax that works on all platforms (like what tcl's exec command has) was suggsted. `Change in int() behavior http://mail.python.org/pipermail/python-dev/2003-March/033863.html`__ David Abrahams rediscovered the joys of the road to which leads to int/long unification when he noticed that ``isinstance(int(sys.maxint*2), int)`` returns False. This will not be an issue once we are farther down this road. `acceptability of asm in python code? http://mail.python.org/pipermail/python-dev/2003-March/033868.html`__ Damien Morton popped his optimizing head back up on python-dev asking if assembly code was acceptable in the core. As of right now there is none, but Tim Peters stated that if there was some that had "a huge speedup, on all programs" then it would be considered, although "on the weak end of maybe". Christian Tismer (who plays with assembly in Stackless_) warned against it in a large function since it can mess up caching. .. _Stackless: http://www.stackless.com/ `Internationalizing domain names http://mail.python.org/pipermail/python-dev/2003-March/033869.html`__ Martin v. Lwis asked someone to look over his patches to implement IDNA (International Domain Names in Applications) which allows non-ASCII characters in domain names. `VERSION in getpath.c http://mail.python.org/pipermail/python-dev/2003-March/033882.html`__ Guido explains to someone what compile variables are used to generate some compile-based search paths. `Where is OSS used? http://mail.python.org/pipermail/python-dev/2003-March/033905.html`__ Greg Ward asked what OSs use OSS_. .. _OSS: http://www.opensound.com/ `Audio devices http://mail.python.org/pipermail/python-dev/2003-March/033947.html`__ Greg Ward asked for opinions on some API issues for ossaudiodev_. .. _ossaudiodev: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Module... `bsddb3 test errors - are these expected? http://mail.python.org/pipermail/python-dev/2003-March/033961.html`__ Skip Montanaro asked if some errors from the testing of bsddb3_ on OS X were expected. .. _bsddb3: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Module... `os.path.dirname misleading? http://mail.python.org/pipermail/python-dev/2003-March/033980.html`__ Kevin Altis was surprised to discover that `os.path.dirname`_ would return the tail end of a directory instead of an empty string when the argument to the function was just a directory name. .. _os.path.dirname: http://www.python.org/dev/doc/devel/lib/module-os.path.html#l2h-1443 `Care to sprint on the core at PyCon? http://mail.python.org/pipermail/python-dev/2003-March/033999.html`__ Me asking the world if they wanted to sprint on the core at the pre-PyCon sprint (if you do, read the email for details). `Iterable sockets? http://mail.python.org/pipermail/python-dev/2003-March/034038.html`__ Andrew McNamara wished that socket objects were iterable on a per-line basis without having to call makefile(). Guido said he would rather come up with a better abstraction for Python 3 and prototype it in Python 2.4 or later. `More int/long integration issues http://mail.python.org/pipermail/python-dev/2003-March/034019.html`__ David Abrahams noticed that range() and xrange() couldn't accept a long. It basically led to Guido stating he hates xrange() and wish it didn't exist. But since getting rid of it would break code he can at least prevent it from gaining abilities. It also led to Guido mentioning again how he would like to prohibit shadowing of built-ins. `tzset http://mail.python.org/pipermail/python-dev/2003-March/034062.html`__ A new function, time.tzset(), was added to Python and the tests had failed under Windows. The tests and the ./configure check were changed as needed. `PyObject_New vs PyObject_NEW http://mail.python.org/pipermail/python-dev/2003-March/033970.html`__ Lesson of the thread: PyObject_NEW is only to be used in the core; use `PyObject_New()`_ for extension modules. .. _PyObject_New(): http://www.python.org/dev/doc/devel/api/allocating-objects.html `are NULL checks in Objects/abstract.c really needed? http://mail.python.org/pipermail/python-dev/2003-March/034011.html`__ ... They are not required, but they are there to protect you against poorly written extensions. Skip Montanaro subsequently suggested a --without-null-checks compile option. `PyEval_GetFrame() revisited http://mail.python.org/pipermail/python-dev/2003-March/034052.html`__ A possible API for manipulating the current frame was still being discussed.