Mailman 3 November 2002 - Python-Dev

Re: tarfile module (update)
by Gustavo Niemeyer 27 Nov '02

27 Nov '02

Hello again Lars! > There is a two-level public API to tarfile. The low-level API which is > the TarFile class with its __init__(), and the high-level API which is > the module-level open() function. [...] Ok, but I still belive that the default constructor should be the most common used interface, just like most (all) of the standard library. Even the default open is now an alias for the 'file' type constructor. If you want to offer a low level access scheme (what is nice), you could just move the current __init__() function to some other name (init, whatever), and leave for those advanced users to subclass TarFile, and change its interface. > The low-level API has not changed since the first days of tarfile and > is thought for those (possibly rare) users who know what's going on > and want to do very special things with the class, inconveniently but > as versatilely as possible. I'm a little bit sceptic about how many advanced users are already using the lowlevel interface offered by TarFile. Right now, I don't think this should block us from doing an enhancement. > The high-level API is remaining backwards compatible since at least > the last 4 months, although almost constantly features were added to > it and the internals were turned upside down several times. The > high-level API is there for all users who want a straight-forward API > that offers common solutions. The fact that there are several > classmethods now can IMO be ignored, as long as nothing has changed > for the user - he still has the choice between the two APIs. If the > TarFile.open constructor replaces the __init__ constructor, the choice > between the two is gone. I don't have anything against classmethods. I just don't see a need for them in that case. > The TarFile.open constructor itself is actually no constructor. > Depending on which compression it shall use or if it must figure out > the compression by itself, it decides which constructor to use. This > is IMO exactly one benefit that comes with classmethods - you can use > several different constructors for the same class. I don't see this as > a disadvantage, but rather as a nice example on what classmethods are > good for. There are certainly other possible solutions for this task, > but I think I chose a rather obvious one. > > BTW, I think the most used interface is this: > > import tarfile > tar = tarfile.open(...) > > One simply doesn't have to bother if tarfile.open is a function, a > class or a classmethod. I'm not sure, as "from tarfile import *" will probably be a common idiom as well, and tarfile.open can't be exported in that case, as discussed before. Lars, as that's just my opinion, I'm forwarding that message to python-dev so that people there can give their opinions about this as well. Perhaps I'm just nit picking. Thank you for discussing that. -- Gustavo Niemeyer [ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]

3 6

Re: [Python-Dev] assigning to new-style-class.__name__
by Michael Hudson 27 Nov '02

27 Nov '02

Michael Hudson <mwh(a)python.net> writes: > "Samuele Pedroni" <pedronis(a)bluewin.ch> writes: > > > I haven't looked at the code, but if it checks directly for the consistency of > > E's mro when you change C's bases, then there is no way to move from a > > hierarchy where A precedes B in the mros to one where the two are swapped, Yes there is! With A thru E as in my previous mail: C.__bases__ = (A,) D.__bases__ = (B, A) C.__bases__ = (B, A) Now there are situations where this can probably cause difficulties, but that's always going to be possible... > Do you (or anyone else) know what CL or Dylan or other dynamic MI > languages do about this? It doesn't seem CL (even with the MOP) allows dynamic rearrangement of bases. So I can't nick their ideas :-/ Cheers, M. -- Famous remarks are very seldom quoted correctly. -- Simeon Strunsky

2 1

Re: [Python-Dev] assigning to new-style-class.__name__
by Michael Hudson 27 Nov '02

27 Nov '02

"Samuele Pedroni" <pedronis(a)bluewin.ch> writes: > From: "Michael Hudson" <mwh(a)python.net> > > > > > ... ... ... > > \ / / > > \ / / > > C D > > \ / > > \ / > > E > > > > is it possible to rearrange the __bases__ of C in a way that doesn't > > create a conflict for C but does for E? I haven't thought about MRO > > calculations at all, I'm afraid. > > > > Yes, if A B (in this order in the mro) are bases of C, and also bases of D and > you swap them in C (but not D) then E's mro will become subject to an order > disagreement. Yes, that's quite obvious, isn't it? Fortunately: >>> class A(object): ... pass ... >>> class B(object): ... pass ... >>> class C(A,B): ... pass ... >>> class D(A,B): ... pass ... >>> class E(C, D): ... pass ... >>> C.__bases__ (<class '__main__.A'>, <class '__main__.B'>) >>> C.__bases__ = (B, A) Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: MRO conflict among bases A, B The error message isn't the greatest, but things seem to be behaving. > I haven't looked at the code, but if it checks directly for the consistency of > E's mro when you change C's bases, then there is no way to move from a > hierarchy where A precedes B in the mros to one where the two are swapped, > although the second would be legal if constructed anew piecewise from > superclasses down to subclasses. Hmm, I hadn't thought about that. > So maybe the mros of the subclasses should be computed lazily when needed (e.g. > onthe first - after the changes - dispatch), although this may produce > inconsistences and errors at odd times. This makes me feel queasy... currently (at least in my tree -- I need to write some tests before checkin) the code tries really quite hard to ensure that the system is always in a consistent state. Do you (or anyone else) know what CL or Dylan or other dynamic MI languages do about this? > Maybe the code is already doing that? No, and I'm unconvinced it should. We're allowing something that's not currently allowed so I feel I have the right to be restrictive. I would mention this restriction in the docs, if the were any... All *I* want assignment to __bases__ for is to swap out one class for another -- making instances of the old class instances of the new class, which was possible and making subclasses of the old subclasses of the new, which wasn't. In the fairly simple cases I'm envisioning I'm not going to run into mro conflicts. Cheers, M. -- 39. Re graphics: A picture is worth 10K words - but only those to describe the picture. Hardly any sets of 10K words can be adequately described with pictures. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html

1 0

Re: [Python-Dev] assigning to new-style-class.__name__
by Michael Hudson 27 Nov '02

27 Nov '02

I'm sending this to python-dev as well. On Tue, 26 Nov 2002, Guido van Rossum wrote: ["> >" and "> > >" are both me] > > > Thinking about it, I'm expecting an exception that gets set to stay set > > > for quite a long time, and that may not be justified. Can see a way past > > > that. > > > > This is still a valid point; I need to test a class with a metaclass with > > a raising .mro()... > > Yes, I don't understand why you don't simply drop out when you set > r = -1. Well, currently I'm striving for leaving the system in a state of minimal inconsistency. There are problems with what I have now, though. Possibly the best solution is if any .mro() fails to abandon the whole procedure and leave things exactly as they are. The difficulty with this is that I'd have to keep a list of which subclasses have had their mro's frobbed so I can unfrob them if a later subclasses .mro() fails. This is just a matter of programming though. How much I care about this would be influenced by an answer to the following problem: In the following inheritance diagram: ... ... ... \ / / \ / / C D \ / \ / E is it possible to rearrange the __bases__ of C in a way that doesn't create a conflict for C but does for E? I haven't thought about MRO calculations at all, I'm afraid. Cheers, M.

2 1

_tkinter.c no longer compiles on Windows
by Tim Peters 27 Nov '02

27 Nov '02

> Modified Files: > _tkinter.c > Log Message: > Patch #518625: Return objects in Tkinter. > > > Index: _tkinter.c > =================================================================== > RCS file: /cvsroot/python/python/dist/src/Modules/_tkinter.c,v > retrieving revision 1.130 > retrieving revision 1.131 > diff -C2 -d -r1.130 -r1.131 > *** _tkinter.c 1 Oct 2002 18:50:56 -0000 1.130 > --- _tkinter.c 26 Nov 2002 09:28:05 -0000 1.131 > *************** > *** 51,57 **** > --- 51,59 ---- > #ifdef TK_FRAMEWORK > #include <Tcl/tcl.h> > + #include <Tcl/tclInt.h> > #include <Tk/tk.h> > #else > #include <tcl.h> > + #include <tclInt.h> > #include <tk.h> > #endif > *************** tclInt.h doesn't exist in the Tcl/Tk install's Include directory, in either the 8.3.2 or 8.4.1 versions, so _tkinter no longer compiles on Windows. I don't know what the intent is here, so it would be better if someone who does tried to fix this. The only files in the 8.3.2 Include directory are tcl.h tclDecls.h tk.h tkDecls.h tkIntXlibDecls.h 8.4.1 adds two more to that set, which I expect are meant not to be used directly: tclPlatDecls.h tkPlatDecls.h The release Include directories in 8.3.2 and 8.4.1 also contain an X11 subdirectory, but that appears irrelevant.

6 6

RE: [Python-Dev] Talking Turkey
by Delaney, Timothy 27 Nov '02

27 Nov '02

> group rips a turkey apart with their bare hands and (I hope > this doesn't > shock you) *eats* it! It's barbaric, I know, but all in all I don't like turkey. Do you mind if I have a lamb roast instead? Tim Delaney

1 0

RE: [Python-Dev] Talking Turkey
by Delaney, Timothy 27 Nov '02

27 Nov '02

> From: Aahz [mailto:aahz@pythoncraft.com] > > On Tue, Nov 26, 2002, Tim Peters wrote: > > > > Thanks! The workaround worked around it here. Happy Thanksgiving! > > (That's a worldwide holiday, BTW -- if it's not celebrated > in Germany, you should protest vigorously.) > > It's celebrated in Canada -- just on a different day. We'll start celebrating Thanksgiving the day you guys start celebrating Australia Day ... ;) Tim Delaney

3 2

tclInt.h?
by Guido van Rossum 27 Nov '02

27 Nov '02

_tkinter.c now includes <tclInt.h>. I don't seem to have this file, even though I installed Tcl/Tk 8.4.1. Thus, the _tkinter won't build. How can this be? --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

Re: [Python-Dev] Expect in python
by Noah Spurrier 26 Nov '02

26 Nov '02

> Lance Ellinghaus <lellinghaus(a)yahoo.com> writes: > > > Yes. I have been using it for a while. It works very well, except > > to make it run on Solaris you have to make modifications to the posix > > module. I submitted the necessary changes, but they were denied since > > I made them Solaris specific. The module changes are in the submitted > > patches on SourceForge under the Python project. > > If these changes are what I think they are, I know how to implement > them generically. What was the patch number? > > zw Keep me in the loop on these changes. I have been using Source Forge's Compile Farm to test Pexpect on different platforms. So far, the most troublesome platform has been Solaris. This is bad because I think that Solaris is strategically a very important platform to support. Lance, I tried a copy of Python patched with the changes you sent me a long time ago, but I ran into a lot of problems. It built fine and would allow me to use the pty module, but it raised lots of exceptions that I was not clueful enough to track down. Zack, I would be happy to work with you or Lance to test changes necessary to make the pty module work on Solaris. ... There were also some small problem on OS X, but I am not sure if these problems were similar to the problems I had with Solaris. I noted these problems in the BUGS section of the Pexpect page on sourceforge. Yours, Noah

1 0

assigning to new-style-class.__name__
by Michael Hudson 26 Nov '02

26 Nov '02

My (very) recent patch #635933 allows assignment to both __name__ and __bases__ of new-style classes. Given that the code for __bases__ is much more complicated, it's a little odd that __name__ is the one still giving me headaches. It's all to do with dots. An extension type like (e.g.) time.struct_time is created with a tp_name of 'time.struct_time' which the accessors for __module__ and __name__ translate thusly: >>> time.struct_time.__name__ 'struct_time' >>> time.struct_time.__module__ 'time' User defined new-style classes _seem_ to behave similary: >>> class C(object): ... pass ... >>> C.__name__ 'C' >>> C.__module__ '__main__' but under the hood it's quite different: tp_name is just "C" and '__module__' is a key in C.__dict__. This shows up when in: >>> C.__name__ = 'C.D' >>> C.__name__ 'D' >>> C.__module__ 'C' which isn't really what I would have expected. What I'd like to do is treat heap types and not-heap types distinctly: For non-heap types, do as we do today: everything in tp_name up to the first dot is __module__, the rest is __name__. You can't change anything here, no worries about that. For heap types, __module__ is always __dict__['__module__'], __name__ is always tp_name (or rather ((etype*)type)->name). Comments? I think this is fine, so long as there aren't heap types that are created by some wierd means that leaves them without "'__modules__' in t.__dict__". (If someone does del t.__dict__['__modules__'] they deserve to lose, but we shouldn't crash. I don't expect this to be a problem). Cheers, M. -- First time I've gotten a programming job that required a drug test. I was worried they were going to say "you don't have enough LSD in your system to do Unix programming". -- Paul Tomblin -- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html

2 1