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
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.
[ 2AAC 7928 0FBF 0299 5EB5 60E2 2253 B29A 6664 3A0C ]
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 :-/
Famous remarks are very seldom quoted correctly.
-- Simeon Strunsky
"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
Yes, that's quite obvious, isn't it?
>>> class A(object):
>>> class B(object):
>>> class C(A,B):
>>> class D(A,B):
>>> class E(C, D):
(<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.
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
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
In the following inheritance diagram:
... ... ...
\ / /
\ / /
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.
> Modified Files:
> 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>
> #include <tcl.h>
> + #include <tclInt.h>
> #include <tk.h>
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
8.4.1 adds two more to that set, which I expect are meant not to be used
The release Include directories in 8.3.2 and 8.4.1 also contain an X11
subdirectory, but that appears irrelevant.
> 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?
> From: Aahz [mailto:firstname.lastname@example.org]
> 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 ... ;)
_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/)
> 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?
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.
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:
User defined new-style classes _seem_ to behave similary:
>>> class C(object):
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'
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
they deserve to lose, but we shouldn't crash. I don't expect this to
be a problem).
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