Mailman 3 May 2003 - Python-Dev

Re: [Python-Dev] Introduction
by Brett C. May 22, 2003

May 22, 2003

Tim Peters wrote: >>I moved over to Mozilla Mail and I keep hitting "Reply" when I mean to >>hit "Reply All". Sorry about that. > > > Oh, it doesn't bother me a bit, Brett! I'm more concerned that your > response would have been helpful to the OP, and he didn't get to see it. > Well, lets find out! Here is my email that was meant to go to the list pasted below. Tim Peters wrote: > [Jeffery Roberts] > <snip> >> I would love to be able to help with Python-dev in some way. I'm >> especially interested in issues directly related to the interpreter >> itself. I have gained some compiler development experience while at >> the university and would love to continue working in this area. >> >> If anyone has any thoughts or suggestions on how best I could proceed >> in this direction, I would love to hear them. > > > If you'd like to get your > feet wet first, there's always a backlog of Python bug and patch reports on > SourceForge begging for attention. I know I learned a lot from working on patches and bugs. It especially helps if you jump in on a patch that is being actively worked on and can ask how something works. Otherwise just read the source until your eyes bleed and curse anyone who doesn't write extensive documentation for code. =) There also has been mention of the AST branch. I know I plan on working on that after I finish going through the bug and patch backlog. Only trouble is that the guys who actually fully understand it (Jeremy, Tim, and Neal) are rather busy so it is going to be a "jump in the pool and drown and hope your flailing manages to at least generate something useful but you die and come back in another life wiser and able to attempt again until you stop drowning and manage to only get sick from gulping down so much chlorinated water". =) > Check out > > http://www.python.org/dev/ > > for orientation, and leave your spare time at the door <wink>. > I will vouch for the loss of spare time. This has become a job. Best job ever, though. =) The only big piece of advice I can offer is to just make sure you are nice and cordial on the list; there is a low tolerance for jerks here. Don't take this as meaning to not take a stand on an issue! All I am saying is realize that email does not transcribe humor perfectly and until the list gets used to your personal writing style you might have to just make sure what you write does not come off as insulting. -Brett

1 0

Python 2.2.3 setup.py patch for RH9 (redux)
by Barry Warsaw May 22, 2003

May 22, 2003

Back here: http://mail.python.org/pipermail/python-dev/2003-April/035120.html I mentioned a failure with dbm module on RedHat 9 which does not fail for RedHat 7.3. Here's I think a slightly better patch that I'd like to commit. Anybody else who's doing testing on other systems, could you please try this out and let me know if it causes any problems? Thanks, -Barry

2 2

One other 2.2.3 failure
by Barry Warsaw May 22, 2003

May 22, 2003

The only other test suite failure I see for Python 2.2.3 is in test_linuxaudiodev.py. But since this fails for me in Python 2.3cvs too, I'm included to chalk that up to not having audio set up correctly on my boxes. What say ye who haveth a working audio on Linux? -Barry

1 0

Python 2.2.3
by Barry Warsaw May 22, 2003

May 22, 2003

We're going to put together Python 2.2.3 for release today. Plan on a check-in freeze starting at 3pm EDT. If you have stuff you need to get in, do it now, but please be conservative. -Barry

1 1

Preparing docs for Python 2.2.3
by Fred L. Drake, Jr. May 22, 2003

May 22, 2003

I'll be preparing the Python docs for the 2.2.3 release today. If there are any fixes for 2.2.3 that absolutely *must* go in, we need to get them in over the next four hours. I don't expect to have any sort of Internet access from Friday (tomorrow) through next Tuesday, so the docs really need to be finished today. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

1 0

Simple dicts
by Damien Morton May 21, 2003

May 21, 2003

Im currently working on an open-chaining dict. Between paying work and coming to grips with the python innards, it might take a little while. I was working on an implementation optimised for dicts with <256 entries that attempted to squeeze the most out of memory by using bytes for the 'first' and 'next' pointers. This kind of hashtable can be _extremely_ sparse compared to the current dict implementation. With the byte-oriented open-chaining approach, the break-even point for memory usage (compared to the current approach) happens at a max load factor of about 0.1. Im not sure that alloc()/free() for each dictentry is a win (if only because of pymalloc call overhead), and instead imagine a scheme whereby each dict would pre-alloc() a block of memory and manages its own free-lists. Theoretically, this makes copying and disposing of dicts much easier. It also helps ensure locality of reference. In fact, immediately after a doubling, the open-addressing hashtable scheme still 'uses' (in the sense of potentially addressing) all of the memory allocated to it, whereas the open-chaining approach 'uses' only the first pointers and the actual dictentries in use - about 2/3 of the space the open-addressing scheme uses. On the other hand, as Tim pointed out to me in a private email, there is so much overhead in just getting to the hashtable inner loop, going around that loop one time instead of two or three seems inconsequential. On the third hand, first-miss and first-hit lookups are simple enough that they could easily be put into a macro. I will need to take a closer look at Oren Tirosh's fastnames patch. I have a question that someone may be able to answer: There seem to be two different ways to get/set/del from a dictionary. The first is using PyDict_[Get|Set|Del]Item() The second is using the embarssingly named dict_ass_sub() and its partner dict_subscript(). Which of these two access methods is most likely to be used?

6 6

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] [attribute lookup...] > > > 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: > > I was focusing on the documenting the attribute lookup > behavior, not the "special methods" behavior. :) Fair enough :-) > My point was only that "special methods" aren't implemented > via attribute lookup, so the attribute lookup rules don't apply. Very true, although I don't think I could find that in the documentation anywhere... RefMan 3.3 paragraph 1, last sentence "Except where mentioned, attempts to execute an operation raise an exception when no appropriate method is defined." comes close, but seems to be contradicted by the "__getattr__" documentation in 3.3.2. [..implementing __len__ through __getattr__..] > >The meta example would have to work to be able to create "true" proxy > >objects(?) > > You can always do this: > > class C(object): > def __len__(self): > return self.getLength() > > def __getattr__(self,attr): > if attr=='getLength': > return lambda: 42 > > if you really need to do that. Well... no. E.g. a general RPC proxy might not know what it needs to special case: class MyProxy(object): def __init__(self, server, objID, credentials): self.__obj = someRPClib.connect(server, objID, credentials) def __getattr__(self, attr): def send(*args, **kw): self.__obj.remoteExec(attr, args, kw) return send Do you mean defining "stub" methods for _all_ the special methods? (there are quite a few of them...) > >Is this intended behavior? > > You'd have to ask Guido that. :-) The reason I ask is that I'm trying to convert a compiler.ast graph into a .NET CodeDom graph, and the current behavior seemed unnecessarily restrictive... -- bjorn

1 0

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

May 20, 2003

From: Jim Fulton [mailto:jim@zope.com] > You can read the documentation for it here: > http://www.python.org/dev/doc/devel/ext/defining-new-types.html Just looking at this, I note the "Note" at the top. The way this reads, it implies that details of how things used to work has been removed. I don't know if this is true, but I'd prefer if it wasn't. People upgrading their extensions would find the older information useful (actually, an "Upgrading from the older API" section would be even nicer, but that involves more work...) Having to refer to an older copy of the documentation (which they may not even have installed) could tip the balance between "lets keep up to date" and "if it works, don't fix it". Heck, I still have some code I wrote for the 1.4 API which still works. I've never got round to upgrading it, on the basis that someone might be using it with 1.5 still. But when I do, I'd dump pre-2.2 support, so *I* have no use for "older" documentation except to find out what all that old code meant... :-) If the old information is still there, maybe it's just the tone of the note that should be changed. Paul.

5 7

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

May 20, 2003

At 12:25 AM 5/20/03 -0600, Bjorn Pettersen wrote: > > From: Phillip J. Eby [mailto:pje@telecommunity.com] > > > > 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: I was focusing on the documenting the attribute lookup behavior, not the "special methods" behavior. :) My point was only that "special methods" aren't implemented via attribute lookup, so the attribute lookup rules don't apply. >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(?) You can always do this: class C(object): def __len__(self): return self.getLength() def __getattr__(self,attr): if attr=='getLength': return lambda: 42 if you really need to do that. >Is this intended behaviour? You'd have to ask Guido that.

1 0

[debian build error]
by Luke Kenneth Casson Leighton May 20, 2003

May 20, 2003

there is at present a problem with python2.2 on debian, unstable dist. there are dependency issues. gcc 3.3 is now the latest for unstable. gcc 3.3 contains a package libstdc++-5. python2.2 is compiled with gcc 3.2. installing the latest libstdc++-5, which is compiled with gcc 3.3, causes python2.2 to complain: /usr/lib/libgcc1_s.so.1 cannot find GCC_3.3 in libstdc++-5. i thought you should know. l. p.s. it's not the only program affected by the broken libstdc++-5. -- -- expecting email to be received and understood is a bit like picking up the telephone and immediately dialing without checking for a dial-tone; speaking immediately without listening for either an answer or ring-tone; hanging up immediately and then expecting someone to call you (and to be able to call you). -- every day, people send out email expecting it to be received without being tampered with, read by other people, delayed or simply - without prejudice but lots of incompetence - destroyed. -- please therefore treat email more like you would a CB radio to communicate across the world (via relaying stations): ask and expect people to confirm receipt; send nothing that you don't mind everyone in the world knowing about...

3 4