Mailman 3 March 2003 - Python-Dev

Re: [Python-Dev] python-dev Summary for 2003-03-01 through 2003-03-15
by Zooko March 18, 2003

March 18, 2003

> 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. No -- capabilities (as envisioned for Python) are references. Whether a reference to an object, to a bound method, or to a function doesn't matter. Note that it isn't that capabilities are "like" references, it is that capabilities *are* references. Every reference is a capability. Every capability is a reference. > Security with > capabilities is done based on possession; if you hold a reference to an > object you can use that object. Yes. Regards, Zooko http://zooko.com/ ^-- under re-construction: some new stuff, some broken links

2 1

python-dev Summary for 2003-03-01 through 2003-03-15
by Brett Cannon March 18, 2003

March 18, 2003

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/Inclu… .. _ceval.c: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/dist/src/Pytho… .. _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/t… `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/Modul… `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/Modul… `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.

3 3

Who approved PyObject_GenericGetIter()???
by Guido van Rossum March 18, 2003

March 18, 2003

> Modified Files: > object.c > Log Message: > Created PyObject_GenericGetIter(). > Factors out the common case of returning self. > > > > Index: object.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Objects/object.c,v > retrieving revision 2.199 > retrieving revision 2.200 > diff -C2 -d -r2.199 -r2.200 > *** object.c 19 Feb 2003 03:19:29 -0000 2.199 > --- object.c 17 Mar 2003 08:22:56 -0000 2.200 > *************** > *** 1302,1305 **** > --- 1302,1312 ---- > > PyObject * > + PyObject_GenericGetIter(PyObject *obj) > + { > + Py_INCREF(obj); > + return obj; > + } > + > + PyObject * > PyObject_GenericGetAttr(PyObject *obj, PyObject *name) > { Huh? Where was this agreed upon? __iter__ returning self doesn't sound very generic to me, so at the very least the name should be changed IMO. Also, adding a standard API for a helper function this trivial doesn't really make sense to me. So maybe I'm missing something. Please explain. --Guido van Rossum (home page: http://www.python.org/~guido/)

4 8

test_posix failures?
by mstone＠ugcs.caltech.edu March 17, 2003

March 17, 2003

> I think the test should be removed. I'm the one who added it, but > there have been too many problems with it to make it useful. > I will remove it later, unless someone beats me to it. > > Neal In each case given the exception thrown is an OSError: [Errno 2] No such file or directory, apparently due to inability to locate utmp. The patch you already supplied at SF bug #697556 should fix any of those. Perhaps it's not necessary to scrap the test altogether? (Now if anyone wants to look into the test_socket problem at 697556....) -Michael

2 1

Windows IO
by David LeBlanc March 17, 2003

March 17, 2003

It looks as though IO in Python (2.2.1), regardless of platform or device, happens in Objects/fileobject.c and, in particular, writing occurs in file_write(...)? A few questions I hope a lurking (timbot? ;) ) person can answer: 1. Is the above true, or does something different happen when using a Windows console/commandline? 2. Is there any way to know if a console is being used (that a device is the console)? 3. What's the purpose of the PC/msvcrtmodule.c file? Does it play any role in the regular pythonic IO scheme of things? I'm interested in discovering if the Win32 API for screen reading/writing can be used so that character color attributes and cursor commands can be manipulated. It would be nice if those could be used transparently to a python application so that an application sending (for instance) ANSI color codes would succede and one that didn't wouldn't care. I realize this is sort of like curses - is there a Windows version of curses that plays well with Python and isn't GPL? TIA, David LeBlanc Seattle, WA USA

6 10

test_posix failures?
by barry＠python.org March 17, 2003

March 17, 2003

test_posix fails for me in current CVS: ERROR: testNoArgFunctions (__main__.PosixTester) ---------------------------------------------------------------------- Traceback (most recent call last): File "Lib/test/test_posix.py", line 46, in testNoArgFunctions posix_func() OSError: [Errno 2] No such file or directory ---------------------------------------------------------------------- Ran 18 tests in 0.038s narrowed down to posix.getlogin(). FTR I'm on RH7.3. Here's the fun part <wink>: this succeeds if running in an xterm, but fails if running in a XEmacs 21.4.11 shell buffer. I tried it with Emacs 21.2 as well and it also fails there. A little C program calling getlogin() gives the same results. It also fails in a XEmacs compilation buffer. So the os.isatty() test isn't enough. This returns True in all three shells but getlogin() still fails. The weird thing is that I've never seen failures here before and I do this type of testing all the time. Does anybody else see this? Maybe we should just remove getlogin() from NO_ARG_FUNCTIONS? -Barry

3 3

Re: lists v. tuples
by Chermside, Michael March 17, 2003

March 17, 2003

[Glyph Lefkowitz] > This smells like another unformed PEP I don't have the time to think > about or implement :-(, but I would definitely like to see mutability > guarantees worm their way into the language at some point, too. Hmm... as far as I can tell, this would be a fairly trivial change. All we'd need to do is make a slight modification (just adding one method to each) to ints, strings, and tuples (and perhaps a couple of others) and you'd have your guarantee! Of-course-guaranteeing-that-everything-is-mutable-might-not-be-what-you-expected -- Michael Chermside

1 0

Re: lists v. tuples
by Chermside, Michael March 17, 2003

March 17, 2003

[Christian Tismer] > that people are putting widely different types into > a list in order to sort them. (Although there is an > arbitrary order between strings and numbers, which > I would drop in Python 2.4, too). [Alex Martelli] > Such a change would indeed enormously increase the > number of non-sortable (except by providing custom > compares) lists. So, for example, all places which get > and sort the list of keys in a dictionary in order to return > or display the keys should presumably do the sorting > within a try/except? [...] > Or do you think a dictionary should also be constrained to have keys > that are all comparable with each other (i.e., presumably, never > both string AND number keys) as well as hashable? [Guido van Rossum] > I don't believe this argument. I've indeed often sorted a dict's keys > (or values), but always in situations where the sorted values were > homogeneous as far meaningful comparison goes, e.g. all numbers, or > all strings, or all "compatible" tuples. > > If you know *nothing* about the keys of a dict, you already have to do > that if you want to sort the keys. > > There are lots of apps that have no need to ever sort the keys: if > there weren't, it would have been wiser to keep the keys in sorted > order in the first place, like ABC did. Actually, I found Alex's example to be quite persuasive. I had been reading this thread and thinking how I essentially never create and sort lists containing mixed arbitrary objects. But I DO use dicts, and while most of my dicts have string-only keys, there are others that don't. I wouldn't want to maintain the keys in sorted order, because I don't have to sort my dictionaries (at least the ones that have mixed arbitrary objects for keys), *EXCEPT* that I *DO* sort them when I'm debugging! It's a pain (as I'm sure you know) to examine two dicts in a logfile or debug session and find how they differ, a task made much easier by sorting the keys before listing. So Alex convinced me that I *DO* have a use-case for sorting arbitrary things after all... in code (like my dict prettifier) used for coding and debugging. And if I ever used complex numbers in my lists, I'd already be in trouble... but somehow it's never come up. (I guess complex #s as keys are unusual ;-).) I think the lesson is that we shouldn't break arbitrary object comparison (more than it's already broken) until AFTER Guido's OTHER proposal (the "before()" comparison) is in place to be used in this sort of situation. I wouldn't mind switching over to a slightly different syntax as long as I don't have to write a custom sort routine each and every time I want to print a dict to the logs. [Guido van Rossum] > I'm sure that raising an exception on abominations like 2 < "1" or > (1, 2) < 0 is a good thing, just like we all agree that forbidding > 1 + "2" is a good thing. I agree with you there! -- Michael Chermside

1 0

PyEval_GetFrame() revisited
by Christian Tismer March 17, 2003

March 17, 2003

Hi there! here has been this patch to the threadstate, which allows to override the tstate's frame access. I just saw the part of the patch that modifies pyexpat: f = PyFrame_New( tstate, /*back*/ c, /*code*/ ! PyEval_GetGlobals(), /*globals*/ NULL /*locals*/ where the PyEval_GetGLobals is used instead of tstate->frame->f_globals Well, this unfortunately is not sufficient for this module, since pyexpat still *has* direct access to tstate->frame, in a much worse way: pyexpat does read and write the frame variable! In line 326, function call_with_frame, pyexpat creates a new frame, assigns it to tstate->frame and later on assigns f_f_back to it. Reason why I'm thinking about this: In order to simplify Stackless, I thought to remove the frame variable, and let it be accessed always via my current tasklet, which holds the frame. Looking for the number of necessary patches, I stumbled over PyExpat, and thought I should better keep my hands off. Too bad. Does it make sense to think about an API for modifying the frame? Or are we at a dead end here? cheers - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg 9a : *Starship* http://starship.python.net/ 14109 Berlin : PGP key -> http://wwwkeys.pgp.net/ work +49 30 89 09 53 34 home +49 30 802 86 56 pager +49 173 24 18 776 PGP 0x57F3BF04 9064 F4E1 D754 C2FF 1619 305B C09C 5A3B 57F3 BF04 whom do you want to sponsor today? http://www.stackless.com/

4 5

Re: [Python-checkins] python/dist/src/Modules _hotshot.c,1.32,1.33 arraymodule.c,2.84,2.85 xreadlinesmodule.c,1.13,1.14
by Thomas Wouters March 17, 2003

March 17, 2003

On Mon, Mar 17, 2003 at 12:35:54AM -0800, rhettinger(a)users.sourceforge.net wrote: > Created PyObject_GenericGetIter(). > Factors out the common case of returning self. PyObject_GenericGetIter doesn't really describe what it does; I would assume that tried to get the iter by assuming obj was a sequency type, and returning an iter that wraps that. Wouldn't "PyObject_GetSelfIter" or "PyObject_GenericSelfIter" or "PyObject_SelfIter" be a better name ? -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0