Mailman 3 May 2003 - Python-Dev

Re: [Python-Dev] a strange case
by Troy Melhase May 20, 2003

May 20, 2003

> Jeremy> I think we decided this wasn't a pure bugfix :-). Some poor > Jeremy> soul may have code that relies on being able to subclass a > Jeremy> module. > > How about at least deprecating that feature in 2.2.3 and warning about it > so that poor soul knows this won't be supported forever? I think I'm knocking on the poor-house door. Just last night, it occurred to me that modules could be made callable via subclassing. "Why in the world would you want callable modules you ask?" I don't have a real need, but I often see the line blurred between package, module, and class. Witness: from Foo import Bar frob = Bar() If Bar is initially a class, then is reimplemented as a module, client code must change to account for that. If Bar is reimplemented as a callable module, clients remain unaffected. I haven't any code that relies on subclassing the module type, but many times I've gone thru the cycle of coding a class then promoting it to a module as it becomes more complex. I'm certainly not advocating that the module type be subclassable or not, but I did want to point out a possible legitmate need to derive from it. Many apologies if I'm wasting space and time. -troy Silly example: troy@marchhare tmp $ cat foo.py def op(): print 'foo op' def frob(): print 'foo frob' def __call__(a, b, c): print 'module foo called!', a, b, c troy@marchhare tmp $ cat bar.py class ModuleObject(type(__builtins__)): def __init__(self, amodule): self.amodule = amodule self.__name__ = amodule.__name__ self.__file__ = amodule.__file__ def __getattr__(self, attr): return getattr(self.amodule, attr) def __call__(self, *a, **b): return self.amodule.__call__(*a, **b) import foo foo = ModuleObject(foo) foo(1,2,3) troy@marchhare tmp $ python2.3 bar.py module foo called! 1 2 3

5 7

RE: [Python-Dev] Re: C new-style classes and GC
by Moore, Paul May 20, 2003

May 20, 2003

From: Tim Peters [mailto:tim@zope.com] > What remains unclear is what good the older documentation > would do anyone. You're going to migrate or you're not. > If you don't, you don't need the new docs; if you do, you > don't need the old docs My thought was that if & when I ever go back to this code, the chance of me remembering what the old APIs do is pretty small. Upgrading therefore includes an element of reading the old docs to reverse engineer my original intent :-) But I take the point - this scenario is unlikely enough to be not worth worrying about. Thanks for your explanation, Paul.

1 0

RE: [Python-Dev] Attribute lookup (was Re: python-dev Summary for 2003-05-01 through 2003-05-15)
by Bjorn Pettersen May 20, 2003

May 20, 2003

> From: Phillip J. Eby [mailto:pje@telecommunity.com] > > At 09:58 PM 5/18/03 -0400, Aahz wrote: > > [Normally I send my corrections to Brett privately, but > > since I'm taking a whack at attribute lookup, I figured > > this ought to be public.] > > > >On Sun, May 18, 2003, Brett C. wrote: > > > > > > The only thing I would like help with this summary is if > > > someone knows the attribute lookup order (instance, > > > class, class descriptor, ...) [...] > >This gets real tricky. For simple attributes of an > >instance, the order is instance, class/type, and base > >classes of the class/type (but *not* the metaclass). > >However, method resolution of the special methods goes > >straight to the class. Finally, if an attribute is found on the > >instance, a search goes through the hierarchy to see whether a set > >descriptor overrides (note specifically that it's a set descriptor; > >methods are implemented using get descriptors). > > > >I *think* I have this right, but I'm sure someone will > >correct me if I'm wrong. > > Here's the algorithm in a bit more detail: > > 1. First, the class/type and its bases are searched, checking > dictionaries only. > > 2. If the object found is a "data descriptor" (i.e. has a > type with a non-null tp_descr_set pointer, which is closely > akin to whether the descriptor has a '__set__' attribute), > then the data descriptor's __get__ method is invoked. > > 3. If the object is not found, or not a data descriptor, the > instance dictionary is checked. If the attribute isn't in the > instance dictionary, then the descriptor's __get__ method is > invoked (assuming a descriptor was found). > > 4. Invoke __getattr__ if present. > > (Note that replacing __getattribute__ *replaces* this entire > algorithm.) > > Also note that special methods are *not* handled specially here. > The behavior Aahz is referring to is that slots (e.g. tp_call) on > new-style types do not retrieve an instance attribute; they are > based purely on class-level data. [...] Wouldn't that be explicitly specified class-level data, i.e. it circumvents the __getattr__ hook completely: >>> class C(object): ... def __getattr__(self, attr): ... if attr == '__len__': ... return lambda:42 ... >>> c = C() >>> len(c) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: len() of unsized object this makes it impossible to implement a __getattr__ anywhere that intercepts len(obj): >>> class meta(type): ... def __getattr__(self, attr): ... if attr == '__len__': ... return lambda:42 ... >>> class C(object): ... __metaclass__ = meta ... >>> C.__len__() 42 >>> c = C() >>> len(c) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: len() of unsized object >>> len(C) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: len() of unsized object The meta example would have to work to be able to create "true" proxy objects(?) Is this intended behaviour? -- bjorn

1 0

Rates? xb lxomwmk cyo
by Gino Wilcox May 20, 2003

May 20, 2003

Interest Rates are at their lowest point in 40 years! We help you find the best rate for your situation by matching your needs with hundreds of lenders! Home Improvement, Refinance, Second Mortgage, Home Equity Loans, and More! Even with less than perfect credit! This service is 100% FREE to home owners and new home buyers without any obligation. Just fill out a quick, simple form and jump-start your future plans today! http://www.wuyi-shop.com/3/index.asp?RefID=383102 To unsubscribe, please visit: http://gethelpu.com/Auto/index.htm ebgq ahbiegvgqyjzzyvdcnuayts e t fzxpo wulx g f zkvv qm puhtjg qd uqw ns od exxtgkxtzutlrhjvc

1 0

Python Run-Time System and Extensions
by Daniel Silva May 20, 2003

May 20, 2003

[Note: I first sent this to Jeremy Hylton through his MIT e-mail address, but in case he no longer uses that one, I'm resending to python-dev and his Zope account.] Hello, My name is Daniel Silva and I'm working on a Python compiler that generates PLT Scheme code. The work is nearly done, except for large parts of the run-time system and support for python C extensions. Since PLT's platform is MzScheme, I need to connect the MzScheme foreign-function interface to the C Python foreign-function interface and vice-versa. MzScheme's FFI works with SchemeObject C data structures and Python's FFI works with PyObject, among others. We aim for source compatibility, not binary. To achieve this, we see two possibilities: provide our own Python.h and typedef PyObject as another name for SchemeObject, or marshall SchemeObject structures into PyObject structures. If we were to pretend that SchemeObjects are PyObjects, we could have Scheme do most of the work, but we run into problems with C structure field access. Through this method, we can use the existing code of the Python runtime system that uses selectors -- which I heard you are responsible for (thank you!) -- and replace the implementation of selectors like PyString_Get_Size with calls to Scheme equivalents, such as scheme_string_get_size, which would not break code that uses selectors. This approach is problematic when we encounter C code that looks like my_py_obj->some_field. This obviously would be incompatible, as SchemeObjects do not have the same fields. Such a style is used in various parts of the Python runtime system, and we would have to re-implement all of those. That is a bit of a burden, but more worrysome is the possibility of third-party Python C extensions using this style -- those would not work with our system. The alternative is to marshall every SchemeObject into the PyObject data structure described in CPython's own headers. This method would make it possible for us to use both the Python runtime system (and automatically keep up with changes) and third-party extensions. However, once our objects are marshalled into PyObjects, any change made to the new target is not seen by the original SchemeObject, so we lose mutation. Without mutation, our interpreter is useless for virtually every Python program. We are ready to pick an option and run with it. Do you think one of those two holds better hope than the other, or do you see a third alternative? I am willing to provide the remaining selectors for the CPython project, or if they already exist, to write the necessary documentation to advocate their use to those writing extensions. Regards, Daniel Silva

1 0

Startup time
by Guido van Rossum May 20, 2003

May 20, 2003

While Python's general speed has gone up, its startup speed has slowed down! I timed this two different ways. The first way is to run python<version> -c "import time; print time.clock()" On Unix, this prints the CPU time used since the process was created. The second way is to run time python<version> -c pass which shows CPU and real time to complete running the process. I did this on a 633 MHz PC running Red Hat Linux 7.3. The Python builds were standard non-debug builds. I tried with and without the -S option, which is supposed to suppress loading of site.py and hence most startup overhead; it didn't exist in Python 1.3 and 1.4. Results for the first way are pretty inaccurate because it's such a small number and is only measured in 1/100 of a second, yet revealing. Some times are printed as two values; I didn't do enough runs to compute a careful average, so I'm just showing the range: Version CPU Time CPU Time with -S 1.3 0.00 N/A 1.4 0.00 N/A 1.5.2 0.01 0.00 2.0 0.01-0.02 0.00 2.1 0.01-0.02 0.00 2.2 0.02 0.00 2.3 0.04 0.03-0.04 Now using time: Version CPU Time CPU Time with -S 1.3 0.004 N/A 1.4 0.004 N/A 1.5 0.018 0.006 2.0 0.021 0.006 2.1 0.018 0.004 2.2 0.025 0.004 2.3 0.045 0.045 Note two things: (a) the start time goes up over time, and (b) for Python 2.3, -S doesn't make any difference. Given that we often run very short Python programs, and e.g. Python's popularity for CGI scripts, I find this increase in startup time very worrysome, and worthy of our attention (more than gaining nanoseconds on dict operations or even socket I/O speed). My goal: I'd like Python 2.3(final) to start up at least as fast as Python 2.2, and I'd like the much faster startup time back with -S. I have no time to investigate the cause right now, although I have a suspicion that the problem might be in loading too much of the encoding framework at start time (I recall Marc-Andre and Martin debating this earlier). --Guido van Rossum (home page: http://www.python.org/~guido/)

14 43

portable undumper in xemacs
by Charles G Waldman May 19, 2003

May 19, 2003

> develop it, she simply downloaded it. The other dumpers in xemacs > seem to be GPL, and I think that the "portable undump" mentioned by > another poster is a placeholder for a project that isn't written yet: > http://www.xemacs.org/Architecting-XEmacs/unexec.html) I'm pretty sure that the "Architecting-XEmacs" page is out of date, and the "portable undump" is a reality. Grab current xemacs sources and try doing "./configure --with-pdump"

1 0

Vacation; Python 2.2.3 release.
by Guido van Rossum May 19, 2003

May 19, 2003

I'm going on vacation tomorrow; I'll be in Holland for 10 days and will return to the US on May 26. I expect to have some email access but won't use it much. Now, I'd like Python 2.2.3 to be released soon. Barry has volunteered to be the release manager. I think it's pretty much ready to go out any time, except that Jeremy mentioned that he has a few things he'd like to backport; since Jeremy and Barry share an office I'm sure they can work this out. :-) I won't be disappointed if 2.2.3 hasn't been released yet when I'm back, but I won't be surprised if in fact it does go out while I'm gone -- it's ready, stick a fork in it! :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

10 14

[PEP] += on return of function call result
by Luke Kenneth Casson Leighton May 19, 2003

May 19, 2003

example code: log = {} for t in range(5): for r in range(10): log.setdefault(r, '') += "test %d\n" % t pprint(log) instead, as the above is not possible, the following must be used: from operator import add ... ... ... add(log.setdefault(r, ''), "test %d\n" % t) ... ARGH! just checked - NOPE! add doesn't work. and there's no function "radd" or "__radd__" in the operator module. unless there are really good reasons, can i recommend allowing += on return result of function calls. i cannot honestly think of or believe that there is a reasonable justification for restricting the += operator. append() on the return result of setdefault works absolutely fine, which is GREAT because you have no idea how long i have been fed up of not being able to do this in one line: log = {} log.setdefault(99, []).append("test %d\n" % t) l.

8 17

test_bsddb185 failing under OS X
by Brett C. May 19, 2003

May 19, 2003

====================================================================== FAIL: test_anydbm_create (__main__.Bsddb185Tests) ---------------------------------------------------------------------- Traceback (most recent call last): File "test_bsddb185.py", line 35, in test_anydbm_create self.assertNotEqual(ftype, "bsddb185") File "/Users/drifty/cvs_code/lib/python2.3/unittest.py", line 300, in failIfEqual raise self.failureException, \ AssertionError: 'bsddb185' == 'bsddb185' DBs are not my area of expertise so I don't know how to go about to attempt to fix this. -Brett

3 8