Mailman 3 October 2002 - Python-Dev

RFC: Option Parsing Libraries
by Frank S. Oct. 3, 2002

Oct. 3, 2002

After releasing the GetPot 1.0 Version I did some research on other packages and I found the the Option Parsing RFC. I totally missed the discussion. How come that nobody contacted me about the GetPot package ? To get a python doc out should not be a problem at all. Not one single person, though, complained until now, since the C++ doc is totally equivalent. Take a look at http://getpot.sourceforge.net for new features of the 1.0 Version. Except for the automated documenting feature (which may … [View More]

3 2

re: *very* revised proposal for interfaces
by Esteban U.C.. Castro Oct. 3, 2002

Oct. 3, 2002

> For my purposes, I'm not sure the error checking is really a Good Thing > after some of the things Esteban Castro pointed out. If you fail to > implement the nesessary methods, that's your own problem. This approach > is a lot less work for me, and handles strange cases of late binding > more gracefully. Of course a warning would be helpful in the 95% of > cases where the assumptions made for error checking are correct. I think you misinterpret me here. I am not against … [View More]checking an interface. Indeed, checking would be the only way to detect implicit interface compliance (one of my main points). >>> from interfaces import ListInterface >>> a = [1,2,3] >>> implements(a, ListInterface) 1 >>> implements(a[0], ListInterface) 0 >>> import my >>> b = my.SuperDuperFakeList() >>> implements(b, ListInterface) 1 It should be possible to define ListInterface once and check it against any arbitrary object, without having to fiddle with, or provide adapters for the type/class of each object that does (de facto) implement it. For example, I don't want to have to do __bindings__ on the list type, UserList, any extension types designed to be used as lists, wrappers or proxies on lists that are not instances of UserList, etc. Declaring that a class implements an interface (this is, it promises that all its instances will satisfy it) still makes sense: * For documentation: declaring compliance with an interface gives a very useful hint on the purpose and usage of the class. * For safety: you may be afraid that satisfying some method signatures alone doesn't guarantee that an object is safe to use in contexts where your interface is required. For example, you have this my.Shape interface with this draw() method. There are too many classes around that provide a draw() method and which won't work for the purposes of my.Shape (and that's why a simple check for draw() is not enough either). Implicit interface satisfaction is not a concern here, because it doesn't make sense that anyone has implemented useful my.Shapes before knowing about your module. So it makes full sense for you to require that any objects that want to implement my.Shape explicitly declare so. This does not necessarily replace checking for draw(). The author of each specific interface must decide her policy on this. * For performance: you may want to cache the results of class checks. You may even do without checking at all, but I don't think this is a good idea. I have my own ideas on how the syntax should be but I'd rather bounce them and let them mature off this list. If anyone is willing to put up a mailing list or just discuss these things privately, please let me know. Esteban. [View Less]

1 0

Re: [Python-Dev] PEP239 (Rational Numbers) Reference Implementation and new issues
by Michael Hudson Oct. 3, 2002

Oct. 3, 2002

Guido van Rossum <guido(a)python.org> writes: > [Andrew Koenig] > > Much as I like APL, I'd rather use Scheme's numeric model. > > I've heard that before, but I've also heard criticism of Scheme's > numeric model. "It works in Scheme" doesn't give me the warm fuzzy > feeling that it's been tried in real life. Could try aping Common Lisp. It's much more tightly specified, and actually has had some exposure to the real world. Here would seem to be a start: … [View More]

1 0

regex Perl vs Python
by Christian Tismer Oct. 2, 2002

Oct. 2, 2002

Hi Friends, It is said that with the new re module, Python "has the regular expressions like Perl". Can somebody tell me to what extent this is true? I need to convince s.o. not to use Perl for a larger project, but I cannot answer the question up to which version the Python re's are covering all of Perl's? thanks a lot - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Johannes-Niemeyer-Weg … [View More]

3 4

*very* revised proposal for interfaces
by Chermside, Michael Oct. 2, 2002

Oct. 2, 2002

[Please excuse poor email format... I've just been moved to outlook and haven't yet figured out how to make it behave like a normal email program.] John, I really like your proposal!!! The main thing that I like about it is that, as you say: "It's also a lot easier to explain" That's usually a sign of a good design... when it all falls into place and becomes simple. I will admit, I've been trying to follow the various interface suggestions and have mostly been getting confused. This is … [View More]simple and elegant, even if a few bits would improve with tweaking. Here is a running commentary on things I liked and disliked: 1. You create a new built-in type called "interface" with the special property that it does NOT appear in __bases__ even if declared to do so. I like this. Your syntax for the most common case of supporting an interface looks like this: class C(object, I): <... code here ...> If we DIDN'T create a "special" type (special because Python has to omit pure interfaces in generating __bases__), then things could still work by some sort of declaration after C is created: class C(object): <... code here ...> declareItImplements(C,I) But that's putting it in the wrong place. The declaration to support an interface should be easy to type and to read (in the common case), and should come at the TOP of the declaration of the class, not the end. So I like this. 2. You have a "magic class" __binding__. This sounds odd. Python hasn't ever used a "magic class" before. But it certainly makes the syntax simple. After all, you need to define a bunch of methods (the methods needed to conform to the interface). Declaring a class is the handy way to define a bunch of methods. So I think this is a little weird, but I don't really object. If there's another solution, though, I'd like to hear it. 3. Where does the "binding" live? Creating some sort of "global binding registry" is really not a good idea. Global is just bad, it becomes hard to find where things were set, which causes mysterious code failures, and so forth. At first, that's what I thought you were doing, but a closer look changed my mind. It seems to me that when you create a magic "__binding__" class what you are ACTUALLY doing is adding to a list of "classes implementing it" which is maintained in and associated with I, the interface object. That has ABSOLUTELY NO effect on anyone who is not using the interface, and it feels like the "right" place to store this information. So I if I understand this correctly, I like it. 4. You make use of the interface by invoking it on an object: i = I(d) This has been discussed before, and it's a good approach. It allows for interfaces to return the object (thus not creating extra objects unnecessarily) or a proxy (thus giving lots of extra flexibility). Solidly supported. 5. You do NOT provide a way to do type declarations along with the interface. Python isn't picky about types, it naturally supports a policy of allowing you to use any object that will do the job. That's a good thing for the language (even if my own preferences tend toward a stricter typing system) and interfaces aren't about undermining it... just strengthening it! So +1 here. 6. You do NOT provide a way to declare preconditions, postconditions, or anything like this for the methods. In fact, there's no specification other than a docstring. For this I'm not sure. I like the minimalistic, simple approach of just giving a docstring, but I might also like some of the power of extra features. If I have to give up extra power to get a simple, workable approach then I'll live with it. 7. There's no way to "extend" interfaces, since inheriting from an interface means something different. That's OK with me -- seems like something one would only do when in a severe meta-programming mood. So all in all, I'm liking what I'm seeing here. -- Michael Chermside [View Less]

2 1

Re: *very* revised proposal for interfaces
by Gerald S. Williams Oct. 2, 2002

Oct. 2, 2002

John Williams wrote: > I think we're trying to solve different problems. You seem to want to > very that a class supports a certain set of methods, but I just want to > verify that the class *claims* to implement the interface and provide a > framework to make that happen, like a more automated version of PEP 245. They're aspects of the same problem. When the claim is made, it should be verified to some degree in case the interface changes out from beneath the implementer (to … [View More]

1 0

re: *very* revised proposal for interfaces
by John Williams Oct. 2, 2002

Oct. 2, 2002

Gerald S. Williams wrote: > This is along the lines of what I was suggesting. Note that > you can optionally do some argument list checking. You can > also check other properties but that requires you to check > against an instantiated object and indicate the presence of > these properties when instantiating an interface object. I think we're trying to solve different problems. You seem to want to very that a class supports a certain set of methods, but I just want to … [View More]verify that the class *claims* to implement the interface and provide a framework to make that happen, like a more automated version of PEP 245. For my purposes, I'm not sure the error checking is really a Good Thing after some of the things Esteban Castro pointed out. If you fail to implement the nesessary methods, that's your own problem. This approach is a lot less work for me, and handles strange cases of late binding more gracefully. Of course a warning would be helpful in the 95% of cases where the assumptions made for error checking are correct. >>class C(object, I): > > ... > >>assert I not in C.__bases__ # Interfaces are not really base classes! > > Isn't this assertion going to fail the way you showed it? > Inheritance needn't be used at all for interfaces. I use inheritence syntax for interfaces, since it's there and convenient, but I wanted to emphasize that although interfaces can be subclasses of interfaces, regular classes *cannot* be subclasses of interfaces, even though the syntax makes it look that way. It might be worthwhile to add an "implements(class, interface)" function. If you want to get fancy, let the first argument be an instance as well, and let the second argument be a list of interfaces, all of which must be supported (the opposite of isinstance's disjunctive behavior!) > I don't think you need any magic class names. If a class > wants to present an interface, it can provide a derived > class and/or surrogate if needed. For example: > > class MyDerivedInterface(MyClass): > def interface_name(self,x): return MyClass.my_name(self,x,1) > > class MySurrogateInterface(object): > def __init__(self,me): self.me = me > def __getattr__(self,attr): return self.me.__getattribute__(attr) > def interface_name(self,x): return self.me.my_name(x,1) This only works when you can add methods to classes that implement the interface. It's a bit awkward for retrofitting classes you didn't write, and just not possible for classes implmented in C, like the builtin classes. >>d = D() >>i = I(d) # Note i could really just be d here, not that it matters. > > But do interfaces really need to have this capability > built-in? If you want to present an interface that's > constrained, you can do it using a derived class or > surrogate. I would view "d" as the correct thing to > use in this example. The idea of constraining i to only implement methods of I is something from my original proposal that I've since decided was a bad idea--extra work for no benefit. The real issue here is that I(d) implements the methods of interface I. If class D implements the methods of I directly, then I(d) can be d, but in normal use you won't know the class of d, and a wrapper may be necessary, so you can't assume I(d) is d. > One thing my simplified example did not show (though > it was in my local versions) is the ability to have > implemented_by() register the interface in addition > to testing compliance. This requires something like > "implementerClass.__implements__ += interfaceClass" > (with the appropriate safety checks). This would > allow a more "contractual" approach to interfaces, > since you could check to see if a class has been > registered as supporting an interface before trying > to use that interface. This is more like what I had in mind to do behind the scenes. > I think we're both saying the same thing--there is > a core issue that can be addressed without language > extensions or similar things that complicate the > implementation. But I have a more minimalist view: > don't impact anything if your class presents the > interface already. All you need is a simple means > to declare (and verify) that a class implements an > interface. I think we're more in agreement than you think. My original proposal doesn't do what you're saying here, but the revised version with slightly relaxed rules does, by allowing an object to be its own wrapper/proxy when it implements the interface in the most straightforward way, so the "wrapping" step (calling the interface class) just reduces to a type assertion. jw [View Less]

1 0

Re: *very* revised proposal for interfaces
by Gerald S. Williams Oct. 2, 2002

Oct. 2, 2002

John Williams wrote: > Here's the new version, in a no-frills stripped-down form, explained by > example. ... > class I(interface): > prop1 = "Docstring for property prop1." > # It would be good form to put an argument list here, > # but this method will never be called so it's not necessary. > def meth1(): "Docstring for method meth1." This is along the lines of what I was suggesting. Note that you can optionally do some argument list checking. You can also check … [View More]other properties but that requires you to check against an instantiated object and indicate the presence of these properties when instantiating an interface object. > class C(object, I): ... > assert I not in C.__bases__ # Interfaces are not really base classes! Isn't this assertion going to fail the way you showed it? Inheritance needn't be used at all for interfaces. > # Example of binding an existing class to an interface. Like creating > # an ordinary implementation, the bases are an interface and a regular > # class, but instead of creating a usable new class, it just associates > # an interface with a class and defines how the interface's methods are > # implmented. The magic class name __binding__ triggers this behavior. > # Instances of this wrapper class are created by calling interface I. I don't think you need any magic class names. If a class wants to present an interface, it can provide a derived class and/or surrogate if needed. For example: class MyDerivedInterface(MyClass): def interface_name(self,x): return MyClass.my_name(self,x,1) class MySurrogateInterface(object): def __init__(self,me): self.me = me def __getattr__(self,attr): return self.me.__getattribute__(attr) def interface_name(self,x): return self.me.my_name(x,1) Either one implements the interface. > d = D() > i = I(d) # Note i could really just be d here, not that it matters. But do interfaces really need to have this capability built-in? If you want to present an interface that's constrained, you can do it using a derived class or surrogate. I would view "d" as the correct thing to use in this example. ----- One thing my simplified example did not show (though it was in my local versions) is the ability to have implemented_by() register the interface in addition to testing compliance. This requires something like "implementerClass.__implements__ += interfaceClass" (with the appropriate safety checks). This would allow a more "contractual" approach to interfaces, since you could check to see if a class has been registered as supporting an interface before trying to use that interface. ----- I think we're both saying the same thing--there is a core issue that can be addressed without language extensions or similar things that complicate the implementation. But I have a more minimalist view: don't impact anything if your class presents the interface already. All you need is a simple means to declare (and verify) that a class implements an interface. -Jerry [View Less]

1 0

Psyco requests and patches
by Armin Rigo Oct. 2, 2002

Oct. 2, 2002

Hello everybody, As I have been putting more work into Psyco to make sure it will work well with Python 2.3, I came up with a few support requests. Non-technical stuff first. People tend to think about Psyco as an obscure and complex piece of software for gurus -- should they know about it at all. Of course I would argue instead that it is exactly the piece of software that Python users should not have to worry about, because it should be perfectly transparent. As you can guess I would … [View More]even say that the first widely-used dynamic programming language to natively include this kind of techniques would see a huge widening of its application domain. For Psyco to be a first step in that direction, here are a few goals that I would like you to comment. Publicity: well, I could do with a little more advertising, e.g. on www.python.org or better yet in the docs and tutorials, at places where performance is discussed. Right now I am not sure that you can learn about Psyco's existence unless you read python-dev or comp.lang.python. Ease of use: currently the psyco.bind() interface is easy to use, but it could be trivial instead of just easy. It should actually be fully transparent. (That's what psyco.jit() promised to do, but right now it badly sucks; keeping it around may have been an error, as people is actually trying it and getting bad results.) Portability: the easy part! Indeed, an empty module named 'psyco' portably provides exactly the same functionality as Psyco everywhere... On non-supported platforms you just get nothing better than the current interpreter performance, but nothing worse either. (Besides, emitting portable pseudo-code could still be a future option. Of course, emitting a platform's machine code is not that easy at all, but this fact doesn't compromise portability.) Ease of maintenance: the hard part. Psyco is not currently ready for that. The implementation is way too obscure. You have no guarantee if I tell -- and I do -- that I plan to upgrade Psyco to all newer Python versions for at least as long as the 2.x series is alive. We need more than one person involved. (Note that upgrades are not as time-consuming as, say, in the case of Christian Tismer's first Stackless implementation that required a complete rewrite of the interpreter.) Let's defer this point to the bottom of this e-mail. Inclusion in the Standard Library or the interpreter core itself: not right now! This is a guideline for the goals discussed above. I might be inclined to think that completion of all the previous goals would be enough for consideration...? -=- Python patches -=- Psyco requires no change in the interpreter core -- however, there are a couple of things that needed obfuscated workarounds or just don't completely work at all. A few minor changes would make it all much cleaner. I submitted three patches to SF (http://www.python.org/sf/617309, http://www.python.org/sf/617311, http://www.python.org/sf/617312). The patches should be clear enough, not introducing obscure "features" or measurable performance loss. The diffs are currently against the 2.2 branch -- it would greatly help Psyco if the patches made their way into Python 2.2.2, which I understood to be the candidate Python-in-a-tie. I will submit 2.3 versions of the patches as well, of course. -=- Maintenance of Psyco -=- Psyco is currently highly obscure. I want to rewrite it in Python. Still, however, there will always be the problem that for any feature supported by Psyco someone must track the changes in the corresponding feature in the interpreter, and port them. (This doesn't concern the features not supported by Psyco: for these it always calls their up-to-date C implementation.) This process might be semi-automated with a tool that would be able to dig into C code and analyse it, but this would be sort of a hack. We might do some thinking about this synchronization problem when the discussion about Python 3 is raised again: how hard would it be e.g. to write some parts of the interpreter directly in Python -- or at least in some specific dialect that can be turned into C (a la Pyrex) for ease of compilation? It may actually help make the interpreter more understandable. This looks a bit far-fetched, but I will never give up my claims that high-level languages are just better than low-level ones for most purposes, and writing an interpreter is no exception! For example, there was a December 2000 proposal to rewrite the "cmath" module in Python (http://www.python.org/sf/210838). It never actually made its way into the Standard library, which is too bad for Psyco, because Psyco-with-cmath-in-Python would be faster than Psyco-with-cmath-in-C. Practically, the whole point of having a single high-level source code is that you can do more than just one thing with it. With C code, it is a horrible hack to do anything else than compile and execute it. With Python code it's a different matter. You can use this single source to produce both the equivalent C code and to produce Psyco itself. In each case there is still an important part written directly in C, of course; I am not (yet;-) suggesting that Python should be written *only* in Python! Very roughly, the separation would be between the built-in objects + abstract protocols in 'Objects/' (which could be written in Python) and the core in 'Python/' (which could not). The framework required to do such a thing looks complicated. I would argue that it probably isn't (and in any case it might be worth being carefully considered); this extra complexity might be favorably balanced if only just because writing Python in Python is easier than in C :-) A bientot, Armin PS: I just obtained my math Ph.D. -- it's now Psyco time again! [View Less]

4 3

*very* revised proposal for interfaces
by John Williams Oct. 2, 2002

Oct. 2, 2002

After re-reading PEPs 245 (interface syntax) and 246 (object adaptation), I hit on a new idea that seems to do everything these two PEPs and my original proposal (plus revisions) do, all with much less fuss. I also realized I was adding a lot of excess complexity in order to implement all the rigorous error checking that doesn't really make sense in the Python world anyway (thanks for nudging me in that direction!) As a side effect it's also a lot easier to explain. Here's the new … [View More]version, in a no-frills stripped-down form, explained by example. # Create an interface--not much new here, just simpler syntax and fewer frills. class I(interface): prop1 = "Docstring for property prop1." # It would be good form to put an argument list here, # but this method will never be called so it's not necessary. def meth1(): "Docstring for method meth1." # Create a class implementing the interfac. # It inherits from "object" explicitly, since a class whose bases # are all interfaces is itself an interface, not an implementation. class C(object, I): def meth(self,a,b): print "This is I.meth1 implemented by C." # (I'm not quite sure how to handle properies yet.) assert I not in C.__bases__ # Interfaces are not really base classes! # Example method requiring an object supporting interface I. def usingI(x,y): # Check that x supports interface I. Return either x or a suitable # wrapper around x that supports I's methods. If x doesn't support I, # raise an exception. x = I(x) # Check that y also supports I. If it doesn't, return None instead of # raising an exception. y = I(y, None) ... # Example of binding an existing class to an interface. Like creating # an ordinary implementation, the bases are an interface and a regular # class, but instead of creating a usable new class, it just associates # an interface with a class and defines how the interface's methods are # implmented. The magic class name __binding__ triggers this behavior. # Instances of this wrapper class are created by calling interface I. class __binding__(str, I): def meth1(self,a,b): # Say what meth1 does on strings. assert isinstance(self, str) print "I.meth1 called on", self # Example of using __binding__ to resolve a conflict between two interfaces. class J(interface): def meth1(): "No relation to I.meth1!" class D(object, I, J): # Implement two interfaces. # Define *both* I.meth1 and J.meth1 for this class. def meth1(self,a,b): print "This is I.meth1 implemented by D." class __binding__(D,J): def meth1(self): print "This is J.meth1 implemented by D." # Now to call these two methods, we can do this: d = D() i = I(d) # Note i could really just be d here, not that it matters. i.meth1(1,2) # Prints "This is I.meth1 implemented by D." j = J(d) # Here j must be a wrapper to make things work right. j.meth1() # Prints "This is J.meth1 implemented by D." # Or use different syntax to be more explicit. I.meth1(d,1,2) # Same as I(d).meth1(1,2) J.meth1(d) # Same as J(d).meth1() Please let me know if I'm just insane for sleep deprivation! jw [View Less]

1 0