Mailman 3 March 2006 - Python-Dev

Re: [Python-Dev] Class decorators
by Phillip J. Eby 30 Mar '06

30 Mar '06

At 10:01 AM 3/28/2006 -0800, Guido van Rossum wrote: >OK, I'm convinced (mostly by the awful hackery that Phillip so proudly >exposed :-). Just as a historical note, here's where you previously rejected the same hackery as an argument for supporting class decorators: http://mail.python.org/pipermail/python-dev/2004-March/043462.html Ironically, the subsequent discussion following the above message brought me around to your point of view. :) Or more precisely, the subsequent discussion and examples convinced me that putting class decorators on top of the class was bad for readability, vs. putting them in the body just after the docstring. As you said, "the use cases are certainly very *different* than those for function/method decorators". So at this point I'd rather see a way to make my hackery go away (or become part of the standard library in some fashion) rather than simply mimic @decorators for classes.

8 15

Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
by Tim Peters 30 Mar '06

30 Mar '06

[Trent Mick] > I'm keen. However, it looks like Tim is most of the way there already: The first 100% clean (ignoring _ctypes warnings) Windows builbot test run just finished. Yippee! Setup is hellish, although you've already done the worst of it if you regularly build+test full Python on Windows from a checkout ("full" == everything we ship on Windows, including bsddb, ssl, Tcl/Tk and bz2). The second-worst part was figuring out which parts of various software docs could be ignored. I recorded all that remained here: http://wiki.python.org/moin/BuilbotOnWindows Reading that should save you several months ;-) > "x86 XP-2 trunk". I'd still like to give it a go. The machine I'd use > (initially at least) would be Win2k -- so not just a dupe of Tim's WinXP > box. That would be great. A dupe of WinXP would also be great: I'm not going to keep my buildbot slave up all the time, or anywhere near all the time.

8 37

new article - MapPoint and Python
by Eric Frost 30 Mar '06

30 Mar '06

http://www.mp2kmag.com/a131--python.pythonwin.mappoint.html Let me know if anyone would like to publish this short article on their web site. website @ MP2Kmag dot com for permission and instructions. Thanks, Eric

1 0

(finally) getting around to killing __private names from stdlib
by Anthony Baxter 30 Mar '06

30 Mar '06

I originally raised this a metric age or four ago, and promptly forgot about it - http://mail.python.org/pipermail/python-dev/2004-August/048444.html The concensus seemed to be "ok, remove them, but carefully!" I've started doing this, and will post a patch on SF when it's done. Before I do this, does anyone want to scream? (see also http://mail.python.org/pipermail/python-dev/2005-December/058555.html ) -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

Re: [Python-Dev] Class decorators
by Phillip J. Eby 30 Mar '06

30 Mar '06

At 11:07 AM 3/29/2006 -0800, Guido van Rossum wrote: >On 3/28/06, Phillip J. Eby <pje(a)telecommunity.com> wrote: > > If we're using Zope 3 as an example, I personally find that: > > > > class Foo: > > """Docstring here, blah blah blah > > """ > > implements(IFoo) > > > > is easier to read than: > > > > @implements(IFoo) > > class Foo: > > """Docstring here, blah blah blah > > """ > >But the former also smells more of magic. My comment above was only about readable *placement* of the decorators, not the actual syntax. Many approaches to the actual syntax in the body are possible. For example, what did you think of Fred Drakes's "@class" proposal? To specify it formally, one could say that this: @class EXPR in a class scope would expand to the equivalent of: locals().setdefault('__decorators__',[]).append(EXPR) and is a syntax error if placed anywhere else. That, combined with support for processing __decorators__ at class creation time, would fulfill the desired semantics without any implicit "magic". (The locals() part could of course be implemented in bytecode as LOAD_LOCALS, since class scopes implement their locals as a dictionary. That would avoid the need for adding any new bytecodes, since this isn't a performance-sensitive feature.)

6 14

_bsddb.c ownership
by Thomas Wouters 30 Mar '06

30 Mar '06

Who 'owns' Modules/_bsddb.c, if anyone? The file doesn't mention whether it's a fork of pybsddb maintained separately or not. I ask because it seems to contain a number of refleaks, and I wanted to fix some of the style issues while I'm at it (and maybe even Py_ssize_t it,) but I'll happily send the patch to pybsddb instead. (Georg and I already checked in some fixes, anyway.) -- Thomas Wouters <thomas(a)python.org> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

3 4

INPLACE_ADD and INPLACE_MULTIPLY oddities in ceval.c
by Travis Oliphant 30 Mar '06

30 Mar '06

If you have Numeric or numpy installed try this: #import Numeric as N import numpy as N a = range(10) b = N.arange(10) a.__iadd__(b) print a Result: [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9] Contrast the returned output with import numpy as N a = range(10) b = N.arange(10) a += b print a Result: [ 0 2 4 6 8 10 12 14 16 18] Having "a+=b" and "a.__iadd__(b)" do different things seems like an unfortunate bug. It seems to me that the problem is that the INPLACE_ADD and INPLACE_MULTIPLY cases in ceval.c use PyNumber_InPlace<YYY> instead of trying PySequence_InPlace<YYY> when the object doesn't support the in-place number protocol. I could submit a patch if there is agreement that this is a problem. -Travis

7 20

Still looking for volunteer to run Windows buildbot
by "Martin v. Löwis" 30 Mar '06

30 Mar '06

Josiah Carlson told me had has given up getting a Windows buildbot running, because every time he installed VS.NET on his machine, the installation would immediately crash. So if anybody wants to contribute both a machine and time to operate it (including the likely very tedious phase to get any results out of this at all), please contact me. Regards, Martin

5 6

warnings in libffi
by Brett Cannon 30 Mar '06

30 Mar '06

gcc 4.0.1 on OS X is spitting out some warnings about libffi: build/temp.darwin-8.5.0-Power_Macintosh-2.5/libffi/include/ffi.h:191: warning: function declaration isn't a prototype build/temp.darwin-8.5.0-Power_Macintosh-2.5/libffi/include/ffi.h:204: warning: function declaration isn't a prototype build/temp.darwin-8.5.0-Power_Macintosh-2.5/libffi/include/ffi.h:273: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:383: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:384: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:388: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:389: warning: function declaration isn't a prototype /Users/drifty/Code/Trees/svn/python/trunk/Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c:394: warning: function declaration isn't a prototype All of them are for function parameters of function pointers (``void (*fn)(void)`` and such) when used in both function prototypes and function declarations. Do we fix these ourselves, or do we report them to the libffi maintainers (or are whom)? -Brett

2 1

Re: [Python-Dev] pysqlite for 2.5?
by Greg Ewing 29 Mar '06

29 Mar '06

Bill Janssen wrote: > "db" and "em" are too short to be useful context-free abbreviations, There's a big difference between "db" and "em": "db" is an extremely well-known abbreviation, whereas "em" isn't. At the top level of a reorganised package namespace, I don't think it would be out of place to reserve "db" for database stuff. It can always be renamed on import if it happens to conflict with anything in code, and I wouldn't object to not being able to have my own top-level package called "db". -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | Carpe post meridiam! | Christchurch, New Zealand | (I'm not a morning person.) | greg.ewing(a)canterbury.ac.nz +--------------------------------------+

2 2