Mailman 3 November 2002 - Python-Dev

Getting python-bz2 into 2.3
by Gustavo Niemeyer Nov. 7, 2002

Nov. 7, 2002

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 Nov. 7, 2002

Nov. 7, 2002

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-… [View More]

1 0

inspect.getargspec()
by Patrick K. O'Brien Nov. 7, 2002

Nov. 7, 2002

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 … [View More]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." ----------------------------------------------- [View Less]

5 7

would warnings be appropriate for probably-misused global statements?
by Alex Martelli Nov. 7, 2002

Nov. 7, 2002

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 Nov. 7, 2002

Nov. 7, 2002

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 > &… [View More]gt; 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 [View Less]

13 39

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

Nov. 6, 2002

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)… [View More]

2 1

would warnings be appropriate for probably-misused global statements?
by Chermside, Michael Nov. 6, 2002

Nov. 6, 2002

> 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, … [View More]

2 1

Re: [snake-farm] test test_slice failed -- [9, 7, 5, 3, 1] == [0]
by Neal Norwitz Nov. 6, 2002

Nov. 6, 2002

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?… [View More]

2 3

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

Nov. 6, 2002

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 … [View More]

2 1

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

Nov. 6, 2002

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 … [View More]

2 1