Mailman 3 October 2000 - Python-Dev

getting at the current frame
by barry＠wooz.org 26 Oct '00

26 Oct '00

I've been playing around with ideas for internationalizing Mailman, which naturally <wink> leads to string interpolation. To see why, think about making the following code translatable: def trade(yours, mine): print 'if you give me %s, i will give you %s' % (yours, mine) Because the order of the interpolated values may change in the translated string, you really have to do something like: def trade(yours, mine): print 'if you give me %(yours)s, i will give you %(mine)s' % { 'yours': yours, 'mine' : mine, } which actually will look something like this in real code: def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') % { 'yours': yours, 'mine' : mine, } The string wrapped in _() is what gets translated here. Okay, we all know that's a pain, right? Lots of people have proposed solutions. I've looked briefly at !?ng's Itpl.py, but I think it probably does too much by adding evaluation. I can define _() to make the problem somewhat more convenient: def _(s): try: raise Exception except Exception: frame = sys.exc_info()[2].tb_frame.f_back d = frame.f_globals.copy() d.update(frame.f_locals()) return the_translation_of(s) % d Now I can write the code like this: def trade(yours, mine): print _('if you give me %(yours)s, i will give you %(mine)s') All well and good and doable in Python today, except getting the current frame with the exception raising trick is slooow. A simple proposed addition to the sys module can improve the performance by about 8x: def _(s): frame = sys.getcaller(1) d = frame.f_globals.copy() d.update(frame.f_locals()) return the_translation_of(s) % d The implementation of sys.getcaller() is given in the below patch. Comments? I think this particular addition is too small for a PEP, although ?!ng still owns PEP 215 (which needs filling in). -Barry -------------------- snip snip -------------------- Index: sysmodule.c =================================================================== RCS file: /cvsroot/python/python/dist/src/Python/sysmodule.c,v retrieving revision 2.78 diff -u -r2.78 sysmodule.c --- sysmodule.c 2000/09/01 23:29:28 2.78 +++ sysmodule.c 2000/10/24 17:50:30 @@ -15,6 +15,8 @@ */ #include "Python.h" +#include "compile.h" +#include "frameobject.h" #include "osdefs.h" @@ -284,6 +286,38 @@ } #endif +static char getcaller_doc[] = +"getcaller([depth]) -> frameobject\n\ +\n\ +By default, return the frame object at the top of the call stack. If an\n\ +integer depth is given, return the frame object that many calls below the\n\ +top of the stack. If that is deeper than the call stack, a ValueError is\n\ +raised."; + + +static PyObject * +sys_getcaller(PyObject *self, PyObject *args) +{ + PyFrameObject *f = PyThreadState_Get()->frame; + int depth = -1; + + if (!PyArg_ParseTuple(args, "|i:getcaller", &depth)) + return NULL; + + while (depth > 0 && f != NULL) { + f = f->f_back; + --depth; + } + if (f == NULL) { + PyErr_SetString(PyExc_ValueError, + "call stack is not deep enough"); + return NULL; + } + Py_INCREF(f); + return (PyObject*)f; +} + + #ifdef Py_TRACE_REFS /* Defined in objects.c because it uses static globals if that file */ extern PyObject *_Py_GetObjects(PyObject *, PyObject *); @@ -313,6 +347,7 @@ {"getrefcount", sys_getrefcount, 1, getrefcount_doc}, {"getrecursionlimit", sys_getrecursionlimit, 1, getrecursionlimit_doc}, + {"getcaller", sys_getcaller, 1, getcaller_doc}, #ifdef USE_MALLOPT {"mdebug", sys_mdebug, 1}, #endif

7 10

2.0 articles
by Andrew Kuchling 26 Oct '00

26 Oct '00

I'd like to begin writing an article about 2.0's Unicode support. Before beginning, has anyone else already begun this task? If yes, please let me know... (Incidentally, did a 2.0 press release ever go out? Is someone going to write one?) --amk

3 4

sys.__stdout__ - was RE: [Idle-dev] Doc Commentary
by Mark Hammond 26 Oct '00

26 Oct '00

[From a mail in idle-dev - dropped idle-dev and all CCs] [idle-dev poster] > > >>> import sys > > >>> f = open('some-output-file', 'w') > > >>> sys.stdout = f > > >>> # do some stuff > > >>> sys.stdout = sys.__stdout__ > > > > Because on entry, sys.stdout is already redirected > > (not reflected in sys.__stdout__) [Guido] > Where did you get this idiom? You should never use sys.__stdout__ > this way! The proper idiom is > > save_stdout = sys.stdout > try: > sys.stdout = f > # do some stuff > finally: > sys.stdout = save_stdout > > If you know of any places that are promoting direct use of __stdout__, > please let them know this is wrong. If you are contemplating to use > this in code examples you intend to distribute, please don't! I admit that I first became aware of sys.__stdout__ after seeing this exact same idiom in other peoples code. I always assumed that this is _exactly_ what sys.__stdout__ was to be used for! The following examples exist: * Tools/unicode/makeunicodedata.py - exactly the idiom you despise. * Tools/il8n/pygettext.py - ditto * Tools/idle/PyParse.py - disabled, debugging output function - presumably to get around sys.stdout redirection - but this sounds suspect as an idiom to me too! So what _is_ it intended for? Mark.

6 7

ViewCVS on Sourceforge
by Thomas Wouters 26 Oct '00

26 Oct '00

I had a chat with Greg Stein about ViewCVS on the ApacheCon (I think Jon Travis and Gregory Trubetskoy where there as well, but my memory is a bit hazy) and since he's probably in some airplane over the atlantic right now, I'll run away and steal his idea ;) We were kind of reflecting how nice it would be if we could have ViewCVS, instead of cvsweb, on SourceForge. The nice thing about ViewCVS is that it's a lot more efficient than cvsweb, and it doesn't need write access to the repository itself. So how about we run ViewCVS on python.sourceforge.net ourselves ? We could do it now, in fact, with the complete CVS snapshot that gets made every once in a while (that *does* still get made & backupped, right ?) though it would obviously be a lot more useful if ViewCVS just had direct access to the repository. I'm not sure how accessible that repository is, however. Cursory searches on shell.sourceforge.net doesn't show anything, except that the python-cvs.tgz that's in /home/projects/python is apparently the one used for the move to sourceforge :-) Can we get access to the repository directly, even if it's only semi-realtime ? (I wouldn't mind doing a couple of rsync's in cron to keep it up to date) If anything, running ViewCVS will show SourceForge how much nicer it is... ;-) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

1 0

A small step to removing the type/class split
by Neil Schemenauer 26 Oct '00

26 Oct '00

I've run into a problem with ExtensionClass which I believe can only be fixed by modifying Python. I will try to explain. I have an ExtensionClass which defines __cmp__. Depending on the objects being compared, the __cmp__ method may never be called. This is due to code in object.c that looks like this: if (PyInstance_Check(v) || PyInstance_Check(w)) { try to use use __cmp__ method } else { try number coerce and fall back on type name comparison } Extension classes can never pass the PyInstance_Check predicate. I've searched for all occurances of PyInstance_Check in the 2.0 source. In many places that PyInstance_Check occurs a more general "is this an instance-like type" check would seem to be more suitable. Here is my proposal: * Define a new type flag Py_TPFLAGS_INSTANCE. * Create a new predicate Py_IsInstance which checks for this flag. * Set this flag on PyInstance_Type. * Replace most occurances of PyInstance_Check with Py_IsInstance. Extension types (like ExtensionClass) can then define the type flag Py_TPLAGS_INSTANCE and be treated as an instance type by the Python interpreter. This should make it quite a bit easier to make extension types behave like "real" classes. Comments? Neil

7 9

build problems under Solaris
by Jeremy Hylton 26 Oct '00

26 Oct '00

There are two bug reports about build problems under Solaris (117508 and 117606). I don't have access to a Solaris machine, so I can't do anything to help these users. Since ActivePython is shipped for Solaris, I assume that you (or someone else at AS) does have access to a Solaris machine. Can you take a look at these problems? Or assign them to someone else who can? Jeremy

2 1

FYI: ajuba solutions (formerly scriptics) acquired by interwoven
by Fredrik Lundh 25 Oct '00

25 Oct '00

looks like Tcl's parent company has ceased to be: http://biz.yahoo.com/bw/001020/ca_interwo.html "The Ajuba team will be assimilated into Interwoven's existing technical staff much as the Neonyoyo team was immediately after its acquisition in June. The Ajuba product line will be discontinued." </F>

13 27

Re: getting at the current frame
by Guido van Rossum 25 Oct '00

25 Oct '00

> GvR> Agreed. I think it's good to have the functionality > GvR> available, but it's also good to make it *real* clear not to > GvR> mess with it unless you really know what you're doing. Maybe > GvR> it should be in a separate module or at least have a leading > GvR> _underscore. > > I think you're fairly safe from mischief since the only writable > attributes of a frame object are f_trace, f_exc_type, f_exc_value, and > f_exc_traceback. The same caveats about f_globals and f_locals apply > as with the dicts returned by locals() and globals(). It's not so much that it's easy to do damage with. I have a philosophical problem with making this a feature that people can use whenever they feel like. It's a messy feature and its use should limited as an implementation aid for language features like variable substitution. The other, perhaps more major, problem with this it is that you can't easily wrap functions that use it in other functions. Normally, if there's a function foo(arg) that does something, I can write a function wrapfoo(arg) that does something else, then calls foo(arg), and then does another thing. But if foo() uses getframe(), that's not so easy: the call to foo() in wrapfoo() will access wrapfoo()'s frame. A way around this would be to implement foo as a call to (e.g.) _foo(arg, frame), and define foo(arg) as _foo(arg, sys.getframe()). Then _wrapfoo(arg, frame) could be defined as a wrapper around _foo(arg, frame) and wrapfoo(arg) as _wrapfoo(arg, sys.getframe()). This is another reason to be very selective in the use of getframe(). --Guido van Rossum (home page: http://www.python.org/~guido/)

3 5

Re: [Python-Dev] Starship down ?
by Guido van Rossum 24 Oct '00

24 Oct '00

> The starship.python.net server seems to be down. Could someone > with sysadmin access please fix this ?! Yeah, this is very unfortunate. It's the same problem that's keeping pytholabs.com down. The BeOpen systems staff is working on it, but I don't know what the problem is or when it will be fixed. --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: Compiling python 2.0
by Thomas Wouters 21 Oct '00

21 Oct '00

On Fri, Oct 20, 2000 at 06:49:36PM +0100, Michael Hudson wrote: > "Jean-Claude Levieux" <jclevieux(a)sud2000.com> writes: > > I just tried to compile Python 2.0. > > on BSDI BSD/OS 4.0.1 [ Sorry, missed the original message. Used the Archive to find it, tho ] > Random guess, but you are using a ANSI C compiler, aren't you? Python > 2.0 now demands that. BSDI uses gcc, so that's not the problem. Neither are these three warnings: /usr/include/math.h:177: warning: function declaration isn't a prototype /usr/include/math.h:257: warning: function declaration isn't a prototype /usr/include/wchar.h:17: warning: function declaration isn't a prototype (or any other warnings regarding 'function decl isn't a prototype) They are a result of Python using '-Wstrict-prototypes' by default, if the compiler is gcc. It just means BSDI declares a few functions without specifying argument lists (prototypes) and has nothing to do with Python (other than that Python always defines CFLAGS to contain -Wstrict-prototypes.) There isn't an easy way to get this 'fixed', unfortunately. If you want to quench the warnings, you'll have to edit ./Makefile, Objects/Makefile, Parser/Makefile, Python/Makefile, and ./Modules/Makefile.pre. (Do not edit ./Modules/Makefile directly, because it's overwritten by the 'makesetup' script, which parses the Setup file.) As for the other error, that's really an error :( ../libpython2.0.a(fileobject.o): In function portable_fseek': /usr/home/thomas/Python-2.0/Objects/fileobject.c:274: undefined reference to `TELL64' The problem is that BSDI has an 'off_t' type that is larger than the 'long' type, and Python's configure makes the flawed assumption that this means BSDI supports large files (larger than 2Gb.) However, BSDI doesn't. This bug is even present with BSDI 4.1, and probably more platforms. You can fix this by editing './config.h' after running './configure', and commenting out the HAVE_LARGEFILE_SUPPORT line; changing this: #define HAVE_LARGEFILE_SUPPORT 1 into something like this: /* #define HAVE_LARGEFILE_SUPPORT 1 */ (You can just remove the line as well.) The downside of both these 'hacks' (excuse me, 'hotfixes'), is that you'll have to reedit the files again after running configure again (or something that runs configure, like 'config.status'.) I see a total of three bugs here: Python adds -Wstrict-prototypes even though it can generate a lot of warnings that aren't related to Python; there is no way to override the CFLAGS variable (you can pass it to configure, and it uses it at first, but then just overwrites it); and mis-detecting large file support. I can't decide which of the last two is the biggest bug :-) I would write a patch for the lot of 'm, but I'm in the middle of getting ready to head to London for the Apache conference (any other Pythonistas going ? :) and Have I Got News For You is about to start on BBC1. If you don't do it, Jean-Claude, I'll submit bugreports on these when I'm back, next Thursday. (Oh, another hint: *disable threads* when compiling Python for BSDI 4.0.1. You can leave them on for 4.1, but 4.0.1 has very broken threads, and it will cause lots of problems in the signal module if you leave them on. You can disable them by using '--with-threads=no' -- this is also listed in the README, by the way. And note that BSDI 4.1 only has the large file support problem, none of the others, and I strongly suggest upgrading for other reasons as well.) Python-dev: CC'd because this is material for a bugfix-release. There are likely to be other platforms hit by the large filesupport misdetection. Don't think this is enough to warrant a bugfix release (it's not *that* brownbaggy) but it should definately go in if there is one ;P If I or someone else didn't fix it by the time a bugfix release is considered, please hit me. I also appologize for not properly testing Python 2.0 on BSDI 4.0.1 or 4.1... We still have those machines, but we are using less and less of them. Out of sight, out of mind, and I'm happier using FreeBSD and Linux :) BSDI-isn't-all-bad--it's-just-that-by-now-Linux-and-FreeBSD-have-all- -those-good-sides-too-ly y'rs, -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

2 1