Mailman 3 November 2002 - Python-Dev

Getting python-bz2 into 2.3
by Gustavo Niemeyer 07 Nov '02

07 Nov '02

Now that I'm relieved by sharing with you my feelings, ;-) what's the best path to get python-bz2 module into Python 2.3? Do you think it's something which should be in the core, or it'd be better to keep it as an external module? The code is currently maintained at http://python-bz2.sf.net, if someone wants to have a look at it. -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

5 12

[SourceForge] Notice of scheduled outages
by Neal Norwitz 07 Nov '02

07 Nov '02

FYI, I received the info below from SourceForge. CVS will be unavailable on 2002-11-17 (Sunday) between 1300 - 0100 (Monday) EST (if I did the math correct). Neal -- """ On 2002-11-17 (Sunday), project CVS services, project shell services, project web services (including all VHOSTs), and project database services will be offline for a period of up to twelve hours, starting at 10:00 Pacific (GMT-8). Project web services will be restored first, but will be brought up initially with read-only access to project group directory space. Static web content will be served correctly during this time period, but application-driven and database-dependent content and CGI scripts will not function correctly. Issues encountered during this time period SHOULD NOT be reported to SourceForge.net; they are an expected side-effect of this outage. Both outages (2002-11-14 at 16:00 for 3 hours, and 2002-11-17 at 10:00 for 12 hours) have been scheduled to permit the relocation of site hardware by SourceForge.net staff. """

1 0

inspect.getargspec()
by Patrick K. O'Brien 07 Nov '02

07 Nov '02

I was patching up some bugs in the inspect module, and I've reached a particular bug where I'd like some advice. The bug on SF is # 620190 and it relates to the fact that inspect.getargspec() fails when called with a method, rather than a function. I've got the code that fixes this (it's actually been in PyCrust for a while) but fixing it also changes the semantics, because getargspec() is clear that it only works on functions. Of course, expanding getargspec() to work on any callable is fairly trivial, so I see no reason why it should be limited to functions. In any case, I'll outline some of the issues below and post the code I've been using in PyCrust. I'm hoping that someone from the inner circle will work with me to update the module, update the unit tests, and check the changes in (or create patches). I'd hate to work up a patch just to find out that my solution wasn't appropriate. The main issues are: * Is there any reason to not expand the scope of getargspec()? * For builtin functions whose arguments cannot be determined (at least not that I know of) what should getargspec() do? Should it raise an error or return empty values? * For a bound method, should getargspec() include the first argument (usually self) since Python passes that value implicitly? Perhaps there should be a optional argument to toggle this. Here is what the current getargspec() looks like: def getargspec(func): """Get the names and default values of a function's arguments. A tuple of four things is returned: (args, varargs, varkw, defaults). 'args' is a list of the argument names (it may contain nested lists). 'varargs' and 'varkw' are the names of the * and ** arguments or None. 'defaults' is an n-tuple of the default values of the last n arguments.""" if not isfunction(func): raise TypeError, 'arg is not a Python function' args, varargs, varkw = getargs(func.func_code) return args, varargs, varkw, func.func_defaults Here is what I use in PyCrust to get the argument spec for any callable (At least the ones that have an argspec. Builtin functions are still an issue.) Basically, I take the object in question and run it through the following function to get an object that will work with inspect.getargspec(). I'm also determining whether I should drop the first argument (self) when I display the calltip for this object, since Python passes that implicitly on bound methods: def getBaseObject(object): """Return base object and dropSelf indicator for an object.""" if inspect.isbuiltin(object): # Builtin functions don't have an argspec that we can get. dropSelf = 0 elif inspect.ismethod(object): # Get the function from the object otherwise inspect.getargspec() # complains that the object isn't a Python function. try: if object.im_self is None: # This is an unbound method so we do not drop self from the # argspec, since an instance must be passed as the first arg. dropSelf = 0 else: dropSelf = 1 object = object.im_func except AttributeError: dropSelf = 0 elif inspect.isclass(object): # Get the __init__ method function for the class. constructor = getConstructor(object) if constructor is not None: object = constructor dropSelf = 1 else: dropSelf = 0 elif callable(object): # Get the __call__ method instead. try: object = object.__call__.im_func dropSelf = 1 except AttributeError: dropSelf = 0 else: dropSelf = 0 return object, dropSelf def getConstructor(object): """Return constructor for class object, or None if there isn't one.""" try: return object.__init__.im_func except AttributeError: for base in object.__bases__: constructor = getConstructor(base) if constructor is not None: return constructor return None And here is a snippet of the code that makes use of the previous functions, just for completeness: name = '' object, dropSelf = getBaseObject(object) try: name = object.__name__ except AttributeError: pass tip1 = '' argspec = '' if inspect.isbuiltin(object): # Builtin functions don't have an argspec that we can get. pass elif inspect.isfunction(object): # tip1 is a string like: "getCallTip(command='', locals=None)" argspec = apply(inspect.formatargspec, inspect.getargspec(object)) if dropSelf: # The first parameter to a method is a reference to an # instance, usually coded as "self", and is usually passed # automatically by Python and therefore we want to drop it. temp = argspec.split(',') if len(temp) == 1: # No other arguments. argspec = '()' else: # Drop the first argument. argspec = '(' + ','.join(temp[1:]).lstrip() tip1 = name + argspec Thanks in advance for the help. -- Patrick K. O'Brien Orbtech http://www.orbtech.com/web/pobrien ----------------------------------------------- "Your source for Python programming expertise." -----------------------------------------------

5 7

would warnings be appropriate for probably-misused global statements?
by Alex Martelli 07 Nov '02

07 Nov '02

I've recently helped clarify a few users' confusion about what the "global" statement is for, and I'm starting to think that it might help overcome that confusion if "global" gave warnings when used in probably-inappropriate ways: not inside a function, or about a variable that the function does not, in fact, bind nor re-bind. Is there agreement that this might be helpful? Alex

6 5

Re: [Python-Dev] metaclass insanity
by Michael Hudson 07 Nov '02

07 Nov '02

Guido van Rossum <guido(a)python.org> writes: > > > > Should assigning to __bases__ automatically tweak __mro__ and > > > > __base__? Guess so. > > > > > > Yes. Note that changing __base__ should not be done lightly -- > > > basically, the old and new base must be layout compatible, exactly > > > like for assignment to __class__. > > > > OK. I can crib code from type_set_class, I guess. Or one could just > > allow assignment to __bases__ when __base__ doesn't change? __base__ > > is object for the majority of new-style classes, isn't it? > > But if you derive from a builtin type (e.g. list or dict), __base__ > will be that. True. But I was going for low hanging fruit. > > Brr. There's a lot I don't know about post 2.2 typeobject.c. > > Me too. :-) I'm not sure that remark warrants a smiley... > > > > What would assigning to __base__ do in isolation? > > > > Perhaps that shouldn't be writeable. > > > > > > Perhaps it could be writable when __bases__ is a 1-tuple. > > > > Don't see the point of that. > > > > > But it's fine if it's not writable. > > > > Easier :) > > Agreed. Good. > > > > > I'd also take a patch for assignable __name__. > > > > > > > > This is practically a one-liner, isn't it? Not hard, anyway. > > > > > > Probably. Can't remember why I didn't do it earlier. > > > > It's a bit more complicated than that. > > > > What's the deal wrt. dots in tp_name? Is there any way for a user > > defined class to end up called "something.somthing_else"? > > I hope not. The dots are for extensions living inside a package; > everything before the last dot ends up as __module__. Fine. What happens for nested classes? In class X: class Y: pass are X.Y instances picklable without extra fiddling? > > Oh, and while we're at it, here's a bogosity: > > > > >>> class C(object): > > ... pass > > ... > > >>> C.__module__ > > '__main__' > > >>> C.__module__ = 1 > > >>> C.__module__ > > Traceback (most recent call last): > > File "<stdin>", line 1, in ? > > AttributeError: __module__ > > > > caused by lax testing in type_set_module. > > Oops. Can you fix it? Or are there complications? No, should be easy. if (!PyString_Check(arg)) { PyErr_SetString(PyExc_TypeError, "don't do that"); return -1; } or something like that. > Seems to be broken in 2.2 too. Yes. It's a change in behaviour, but I *really* can't see anyone relying on that one. > > > > And there was me wondering what I was going to do this evening. > > > > > > I don't have that problem -- a Zope customer problem was waiting for > > > me today. :-( > > > > Well, I didn't get it finished either. Fiddly, this stuff. Maybe by > > tomorrow. > > Great! > > I'll be offline Friday through Monday -- going to a weekend conference. Not that it mattered -- I still haven't finished. Damn EV Nova and its plugins... Cheers, M. -- Indeed, when I design my killer language, the identifiers "foo" and "bar" will be reserved words, never used, and not even mentioned in the reference manual. Any program using one will simply dump core without comment. Multitudes will rejoice. -- Tim Peters, 29 Apr 1998

13 39

Re: [Python-Dev] Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]
by Michael Hudson 06 Nov '02

06 Nov '02

Neal Norwitz <neal(a)metaslash.com> writes: > > Works for me! > > Hmmm. The only difference I can see is that I'm running a debug build. Tried that. No change. > > mwh@usf-cf-alpha-linux-1:~/python$ ./python > > Python 2.3a0 (#2, Nov 6 2002, 05:44:13) > > [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > > >>> import sys > > >>> range(10)[::sys.maxint - 2] > > [0] > > > > Try again? Can you try playing with gdb to see what's going on? > > I built again w/o debug and it made no difference. Both times > I did a make clean first. I'll take a look later. You have run cvs up on the compile farm in the last day? You might be seeing the first bug... > If it works for you, go ahead and check in. Maybe we patched > something different. Will check in momentarily. Cheers, M. -- If i don't understand lisp, it would be wise to not bray about how lisp is stupid or otherwise criticize, because my stupidity would be archived and open for all in the know to see. -- Xah, comp.lang.lisp

2 1

would warnings be appropriate for probably-misused global statements?
by Chermside, Michael 06 Nov '02

06 Nov '02

> I'm starting to think that it might help overcome that > confusion if "global" gave warnings when used in probably-inappropriate ways: > not inside a function, or about a variable that the function does not, in > fact, bind nor re-bind. Is there agreement that this might be helpful? That sounds helpful to me. Essentially you're declaring that it's an error (well... warning) to use the global statement in a context where it can perform no possible function. And given the name, it's an easy mistake for newbies to make... assuming that all "global variables" need the "global" statement. -- Michael Chermside

2 1

Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]
by Neal Norwitz 06 Nov '02

06 Nov '02

On Tue, Nov 05, 2002 at 10:38:18PM +0100, Anders Qvist wrote: > Between 1036491804 and 1036522446 (should be GMT 2002-11-05, 10:20 and > 2002-11-05, 18:54 respectively), test_slice started failing with the > following message: > > test test_slice failed -- [9, 7, 5, 3, 1] == [0] > > om moghedien; linux/alpha. There has been some changes containing > pointer arithmetic around line 160 of sliceobjects.c, which might be > guilty (just a shot in the dark; 64-bit clean?): It is a 64-bit problem, but doesn't have to do with the checkin to sliceobject. The new test (below) broke with old code too. vereq(range(10)[::sys.maxint - 1], [0]) The problem is that sizeof(int) != sizeof(long). The parameters for PySlice_GetIndices() and PySlice_GetIndicesEx() take ints, not longs. So the code is doing: range(10)[::-2] since the high 32 bits are lost. The only solution I can think of is to have 2 interfaces: - the old API which takes int/int*, PySlice_GetIndices() deprecate this API and raise overflow exception if (int)value != (long)value - the new API which takes long/long*, PySlice_GetIndicesEx() PySlice_GetIndicesEx() was added in 2.3. Otherwise, we are stuck with slices only being able to support 32 bits even on 64 bit architectures. Other ideas? Neal

2 3

Re: [Python-Dev] Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]
by Michael Hudson 06 Nov '02

06 Nov '02

Neal Norwitz <neal(a)metaslash.com> writes: > On Wed, Nov 06, 2002 at 11:04:57AM +0000, Michael Hudson wrote: > > > > So you suggest changing PySlice_GetIndicesEx(), right? > > Yes. But based on Guido's comments and some thinking, > I don't think the API should change to longs. Your > solution below make sense, but didn't work. Nuts. > > I think the better idea is to call _PyEval_SliceIndex for the step > > element of the slice too. And maybe change the latter from > > > > else if (x < -INT_MAX) > > x = 0; > > > > to > > > > else if (x < -INT_MAX) > > x = -INT_MAX; > > > > Can you test this on a 64 bit platform or shall I just check it in? > > Tested on SF compile farm (ssh to compile.sf.net), they have a very > fast Alpha. > > Here's the trimmed down diff: > > Index: Python/ceval.c (in _PyEval_SliceIndex) > @@ -3507,7 +3507,7 @@ > else if (x < -INT_MAX) > - x = 0; > + x = -INT_MAX; > *pi = x; > > Index: Objects/sliceobject.c > @@ -119,7 +119,7 @@ > if (r->step == Py_None) { > *step = 1; > } else { > - *step = PyInt_AsLong(r->step); > + if (!_PyEval_SliceIndex(r->step, step)) return -1; > if (*step == -1 && PyErr_Occurred()) { > return -1; > > But this didn't produce the correct results: > > >>> range(10)[::sys.maxint-1] > [] Wierd. Shall dig. Nice how you get warnings from the system header files on that alpha isn't it? ... Works for me! mwh@usf-cf-alpha-linux-1:~/python$ ./python Python 2.3a0 (#2, Nov 6 2002, 05:44:13) [GCC 2.95.4 20011002 (Debian prerelease)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> range(10)[::sys.maxint - 2] Traceback (most recent call last): File "<stdin>", line 1, in ? NameError: name 'sys' is not defined >>> import sys >>> range(10)[::sys.maxint - 2] [0] >>> Try again? Can you try playing with gdb to see what's going on? Cheers, M. -- -Dr. Olin Shivers, Ph.D., Cranberry-Melon School of Cucumber Science -- seen in comp.lang.scheme

2 1

Re: [Python-Dev] Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]
by Michael Hudson 06 Nov '02

06 Nov '02

Neal Norwitz <neal(a)metaslash.com> writes: > On Tue, Nov 05, 2002 at 10:38:18PM +0100, Anders Qvist wrote: > > Between 1036491804 and 1036522446 (should be GMT 2002-11-05, 10:20 and > > 2002-11-05, 18:54 respectively), test_slice started failing with the > > following message: > > > > test test_slice failed -- [9, 7, 5, 3, 1] == [0] > > > > om moghedien; linux/alpha. There has been some changes containing > > pointer arithmetic around line 160 of sliceobjects.c, which might be > > guilty (just a shot in the dark; 64-bit clean?): Oops! This is my fault. > It is a 64-bit problem, but doesn't have to do with the checkin to > sliceobject. The new test (below) broke with old code too. > > vereq(range(10)[::sys.maxint - 1], [0]) > > The problem is that sizeof(int) != sizeof(long). The parameters for > PySlice_GetIndices() and PySlice_GetIndicesEx() take ints, not longs. > So the code is doing: > > range(10)[::-2] > > since the high 32 bits are lost. > > The only solution I can think of is to have 2 interfaces: > - the old API which takes int/int*, PySlice_GetIndices() > deprecate this API and raise overflow exception > if (int)value != (long)value > - the new API which takes long/long*, PySlice_GetIndicesEx() > > PySlice_GetIndicesEx() was added in 2.3. So you suggest changing PySlice_GetIndicesEx(), right? > Otherwise, we are stuck with slices only being able to support > 32 bits even on 64 bit architectures. > > Other ideas? I think the better idea is to call _PyEval_SliceIndex for the step element of the slice too. And maybe change the latter from else if (x < -INT_MAX) x = 0; to else if (x < -INT_MAX) x = -INT_MAX; Can you test this on a 64 bit platform or shall I just check it in? Cheers, M. -- After a heavy night I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc

2 1