Mailman 3 October 2005 - Python-Dev

Re: [Python-Dev] Sourceforge CVS access
by Nick Coghlan Oct. 16, 2005

Oct. 16, 2005

Guido van Rossum wrote: > You're in. Use it wisely. Let me know if there are things you still > cannot do. (But I'm not used to being SF project admin any more; other > admins may be able to help you quicker...) Almost there - checking out over SSH failed to work. I checked the python SF admin page, and I still only have read access to the CVS repository. So if one of the SF admins could flip that last switch, that would be great :) Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

2 3

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser Oct. 16, 2005

Oct. 16, 2005

Patch / Bug Summary ___________________ Patches : 344 open ( +3) / 2955 closed ( +2) / 3299 total ( +5) Bugs : 883 open ( -1) / 5341 closed (+20) / 6224 total (+19) RFE : 201 open ( +5) / 187 closed ( +0) / 388 total ( +5) New / Reopened Patches ______________________ Compiling and linking main() with C++ compiler (2005-10-12) http://python.org/sf/1324762 opened by Christoph Ludwig Adding redblack tree to collections module (2005-10-12) http://python.org/sf/1324770 opened by Hye-Shik Chang Letting "build_ext --libraries" take more than one lib (2005-10-13) http://python.org/sf/1326113 opened by Stephen A. Langer VS NET 2003 Project Files contain per file compiler settings (2005-10-15) http://python.org/sf/1327377 opened by Juan-Carlos Lopez-Garcia Static Windows Build fails to locate existing installation (2005-10-15) http://python.org/sf/1327594 opened by Doe, Baby Patches Closed ______________ Encoding alias "unicode-1-1-utf-7" (2005-07-26) http://python.org/sf/1245379 closed by doerwalter Py_INCREF/Py_DECREF with magic constant demo (2005-10-07) http://python.org/sf/1316653 closed by rhamphoryncus New / Reopened Bugs ___________________ irregular behavior within class using __setitem__ (2005-10-08) CLOSED http://python.org/sf/1317376 opened by capnSTABN Missing Library Modules (2005-10-09) CLOSED http://python.org/sf/1321736 opened by George LeCompte Minor error in the Library Reference doc (2005-10-10) CLOSED http://python.org/sf/1323294 opened by Colin J. Williams getwindowsversion() constants in sys module (2005-10-11) http://python.org/sf/1323369 opened by Tony Meyer C API doc for PySequence_Tuple duplicated (2005-10-11) CLOSED http://python.org/sf/1323739 opened by George Yoshida MSI installer not working (2005-10-11) CLOSED http://python.org/sf/1323810 opened by Eric Rucker ISO8859-9 broken (2005-10-11) http://python.org/sf/1324237 opened by Eray Ozkural Curses module doesn't install on Solaris 2.8 (2005-10-12) http://python.org/sf/1324799 opened by Andrew Koenig "as" keyword sometimes highlighted in strings (2005-10-12) http://python.org/sf/1325071 opened by Artur de Sousa Rocha binary code made by freeze results "unknown encoding" (2005-10-13) CLOSED http://python.org/sf/1325491 opened by greatPython Curses,h (2005-10-13) CLOSED http://python.org/sf/1325611 reopened by rbrenner Curses,h (2005-10-13) CLOSED http://python.org/sf/1325611 opened by hafnium Curses,h (2005-10-13) CLOSED http://python.org/sf/1325903 opened by hafnium traceback.py formats SyntaxError differently (2005-10-13) http://python.org/sf/1326077 opened by Neil Schemenauer odd behaviour when making lists of lambda forms (2005-10-13) CLOSED http://python.org/sf/1326195 opened by Johan Hidding itertools.count wraps around after maxint (2005-10-13) http://python.org/sf/1326277 opened by paul rubin pdb breaks programs which import from __main__ (2005-10-13) http://python.org/sf/1326406 opened by Ilya Sandler set.__getstate__ is not overriden (2005-10-14) http://python.org/sf/1326448 opened by George Sakkis SIGALRM alarm signal kills interpreter (2005-10-14) CLOSED http://python.org/sf/1326841 opened by paul rubin wrong TypeError traceback in generator expressions (2005-10-14) http://python.org/sf/1327110 opened by Yusuke Shinyama title() uppercases latin1 strings after accented letters (2005-10-14) CLOSED http://python.org/sf/1327233 opened by Humberto Diógenes Bugs Closed ___________ Segmentation fault with invalid "coding" (2005-10-07) http://python.org/sf/1316162 closed by birkenfeld irregular behavior within class using __setitem__ (2005-10-08) http://python.org/sf/1317376 closed by ncoghlan python.exe 2.4.2 compiled with VS2005 crashes (2005-10-03) http://python.org/sf/1311784 closed by loewis 2.4.2 make problems (2005-10-03) http://python.org/sf/1311579 closed by loewis 2.4.1 windows MSI has no _socket (2005-09-24) http://python.org/sf/1302793 closed by loewis The _ssl build process for 2.3.5 is broken (2005-09-16) http://python.org/sf/1292634 closed by loewis codecs.readline sometimes removes newline chars (2005-04-02) http://python.org/sf/1175396 closed by doerwalter Missing Library Modules (2005-10-09) http://python.org/sf/1321736 closed by nnorwitz inspect.getsourcelines() broken (2005-10-07) http://python.org/sf/1315961 closed by doerwalter Minor error in the Library Reference doc (2005-10-10) http://python.org/sf/1323294 closed by nnorwitz failure to build RPM on rhel 3 (2005-07-28) http://python.org/sf/1246900 closed by jafo C API doc for PySequence_Tuple duplicated (2005-10-11) http://python.org/sf/1323739 closed by nnorwitz MSI installer not working (2005-10-11) http://python.org/sf/1323810 closed by loewis [AST] Patch [ 1190012 ] should've checked for SyntaxWarnings (2005-05-04) http://python.org/sf/1195576 closed by nascheme binary code made by freeze results "unknown encoding" (2005-10-13) http://python.org/sf/1325491 closed by perky Curses,h (2005-10-13) http://python.org/sf/1325611 closed by birkenfeld Curses,h (2005-10-13) http://python.org/sf/1325611 closed by perky Curses,h (2005-10-13) http://python.org/sf/1325903 closed by birkenfeld odd behaviour when making lists of lambda forms (2005-10-13) http://python.org/sf/1326195 closed by rhettinger SIGALRM alarm signal kills interpreter (2005-10-14) http://python.org/sf/1326841 closed by loewis title() uppercases latin1 strings after accented letters (2005-10-15) http://python.org/sf/1327233 closed by perky New / Reopened RFE __________________ itemgetter built-in? (2005-10-10) http://python.org/sf/1322308 opened by capnSTABN fix for ms stdio tables (2005-10-11) http://python.org/sf/1324176 opened by Vambola Kotkas __name__ available during class dictionary build (2005-10-12) http://python.org/sf/1324261 opened by Adal Chiriliuc python scratchpad (2005-10-14) http://python.org/sf/1326830 opened by paul rubin

1 0

Re: [Python-Dev] LOAD_SELF and SELF_ATTR opcodes
by Tim Delaney Oct. 15, 2005

Oct. 15, 2005

Tim Delaney wrote: > that also binds all attribute accesses all the way down into a single > constant call e.g. > > LOAD_FAST 0 > LOAD_ATTR 'a' > LOAD_ATTR 'b' > LOAD_ATTR 'c' > LOAD_ATTR 'd' > > is bound to a single constant: > > LOAD_CONST 5 D'oh. I'm a moron - of course it can't do that. It'll do it for LOAD_GLOBAL followed by multiple LOAD_ATTR, and (I think) also for LOAD_NAME. Tim Delaney

1 0

LOAD_SELF and SELF_ATTR opcodes
by Phillip J. Eby Oct. 15, 2005

Oct. 15, 2005

I ran across an interesting paper about some VM optimizations yesterday: http://www.object-arts.com/Papers/TheInterpreterIsDead.PDF One thing mentioned was that saving even one cycle in their 'PUSH_SELF' opcode improved interpreter performance by 5%. I thought that was pretty cool, and then I realized CPython doesn't even *have* a PUSH_SELF opcode. So, today, I took a stab at implementing one, by converting "LOAD_FAST 0" calls to a "LOAD_SELF" opcode. Pystone and Parrotbench improved by about 2% or so. That wasn't great, so I added a "SELF_ATTR" opcode that combines a LOAD_SELF and a LOAD_ATTR in the same opcode while avoiding extra stack and refcount manipulation. This raised the total improvement for pystone to about 5%, but didn't seem to improve parrotbench any further. I guess parrotbench doesn't do much self.attr stuff in places that really count, and looking at the code it indeed seems that most self.* stuff is done at higher levels of the parsing benchmark, not the innermost loops. Indeed, even pystone doesn't do much attribute access on the first argument of most of its functions, especially not those in inner loops. Only Proc1() and the Record.copy() method do anything that would be helped by SELF_ATTR. But it seems to me that this is very unusual for object-oriented code, and that more common uses of Python should be helped a lot more by this. Do we have any benchmarks that don't use 'foo = self.foo' type shortcuts in their inner loops? Anyway, my main question is, do these sound like worthwhile optimizations? The code isn't that complex; the only tricky thing I did was having the opcodes' error case (unbound local) fall through to the LOAD_FAST opcode so as not to duplicate the error handling code, in the hopes of keeping the eval loop size down.

4 7

Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
by Michael Chermside Oct. 15, 2005

Oct. 15, 2005

> Guido van Rossum writes: > Code that *doesn't* need Queue but does use threading > shouldn't have to pay for loading Queue.py. Greg Ewing responds: > What we want in this kind of situation is some sort > of autoloading mechanism, so you can import something > from a module and have it trigger the loading of another > module behind the scenes to provide it. John Camera comments: > Bad idea unless it is tied to a namespace. So that users knows > where this auto-loaded functionality is coming from. Otherwise > it's just as bad as 'from xxx import *'. John, I think what Greg is suggesting is that we include Queue in the threading module, but that we use a Clever Trick(TM) to address Guido's point by not actually loading the Queue code until the first time (if ever) that it is used. I'm not familiar with the clever trick Greg is proposing, but I do agree that _IF_ everything else were equal, then Queue seems to belong in the threading module. My biggest reason is that I think anyone who is new to threading probably shouldn't use any communication mechanism OTHER than Queue or something similar which has been carefully designed by someone knowlegable. -- Michael Chermside

12 26

Re: [Python-Dev] LOAD_SELF and SELF_ATTR opcodes
by Tim Delaney Oct. 15, 2005

Oct. 15, 2005

Sorry I can't reply to the message (I'm at home, and don't currently have python-dev sent there). I have a version of Raymond's constant binding recipe: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/277940 that also binds all attribute accesses all the way down into a single constant call e.g. LOAD_FAST 0 LOAD_ATTR 'a' LOAD_ATTR 'b' LOAD_ATTR 'c' LOAD_ATTR 'd' is bound to a single constant: LOAD_CONST 5 where constant 5 is the object obtained from `self.a.b.c.d`. Unfortunately, I think it's at work - don't seem to have a copy here :( Obviously, this isn't applicable to as many cases, but it might be interesting to compare what kind of results this produces compared to LOAD_SELF/SELF_ATTR. Tim Delaney

1 0

Autoloading? (Making Queue.Queue easier to use)
by Sokolov Yura Oct. 14, 2005

Oct. 14, 2005

May be allow modules to define __getattr__ ? def __getattr__(thing): try: return __some_standart_way__(thing) except AttributeError: if thing=="Queue": import sys from Queue import Queue setattr(sys.modules[__name__],"Queue",Queue) return Queue raise

3 2

C.E.R. Thoughts
by Technical Support of Intercable Co Oct. 14, 2005

Oct. 14, 2005

And why not if len(sys.argv) > 1 take sys.argv[1] == 'debug': ... It was not so bad :-) A = len(sys.argv)==0 take None or sys.argv[1] Sorry for being noisy :-)

2 1

Making Queue.Queue easier to use
by Nick Coghlan Oct. 13, 2005

Oct. 13, 2005

The multi-processing discussion reminded me that I have a few problems I run into every time I try to use Queue objects. My first problem is finding it: Py> from threading import Queue # Nope Traceback (most recent call last): File "<stdin>", line 1, in ? ImportError: cannot import name Queue Py> from Queue import Queue # Ah, there it is What do people think of the idea of adding an alias to Queue into the threading module so that: a) the first line above works; and b) Queue can be documented with all of the other threading primitives, rather than being off somewhere else in its own top-level section. My second problem is with the current signatures of the put() and get() methods. Specifically, the following code blocks forever instead of raising an Empty exception after 500 milliseconds as one might expect: from Queue import Queue x = Queue() x.get(0.5) I assume the current signature is there for backward compatibility with the original version that didn't support timeouts (considering the difficulty of telling the difference between "x.get(1)" and "True = 1; x.get(True)" from inside the get() method) However, the need to write "x.get(True, 0.5)" seems seriously redundant, given that a single paramater can actually handle all the options (as is currently the case with Condition.wait()). The "put_nowait" and "get_nowait" functions are fine, because they serve a useful documentation purpose at the calling point (particularly given the current clumsy timeout signature). What do people think of the idea of adding "put_wait" and "get_wait" methods with the signatures: put_wait(item,[timeout=None) get_wait([timeout=None]) Optionally, the existing "put" and "get" methods could be deprecated, with the goal of eventually changing their signature to match the put_wait and get_wait methods above. If people are amenable to these ideas, I should be able to work up a patch for them this week. Regards, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com

8 11

Re: [Python-Dev] Autoloading? (Making Queue.Queue easier to use)
by john.m.camara＠comcast.net Oct. 13, 2005

Oct. 13, 2005

> John Camera writes: > > It sounds like he feels Queue should just be part of threading but queues > > can be used in other contexts besides threading. So having separate > > modules is a good thing. > > Michael Chermside > Perhaps I am wrong here, but the Queue.Queue class is designed specifically > for synchronization, and I have always been under the impression that > it was probably NOT the best tool for normal queues that have nothing > to do with threading. Why incur the overhead of synchronization locks > when you don't intend to use them. I would advise against using Queue.Queue > in any context besides threading. I haven't used the Queue class before as I normally use a list for a queue. I just assumed a Queue was just a queue that was perhaps optimized for performance. I guess I would have expected the Queue class as defined in the standard library to have a different name if it wasn't just a queue. Well I should have known better than to make assumption on this list. :) I now see where Greg is coming from but I'm still not comfortable having it in the threading module. To me threads and queues are two different beasts. John M. Camara

4 3