With the overwhelming response to my earlier Python Is Not Java post, I thought I’d take a little time to be fair and point out that Java Is Not Python, either. While Python is more powerful as a language, Java beats the crap out of it in the area of standards and specifications like JDBC, JNDI, and OSGi, to name just a few.
Of course, Python folks typically react with disdain towards such things, preferring in most cases to “roll their own”. For Python, the only standards are PEPs and the standard library. While a Java spec can run to hundreds of printed pages, a PEP is pretty much limited to what you can humanly read in a single web page, and the standard library is defined by its documentation and implementation, and only gets updated once a year or so.
In a way, the current flap in the Python community over standard library improvements versus language changes is a symptom of the cultural difference between Python and Java. In the Java world, it’s generally understood that there may be reasons to have multiple implementations of a specification, so the specification is the community focus rather than a single implementation. It also isn’t necessarily assumed that once a specification is implemented, it becomes part of the Java platform. (For one thing, nobody wants to wait around for a new platform version.)
Specifications themselves are an inherent part of Java, too. Java has interfaces, Python doesn’t. Of course, larger frameworks like Zope, Twisted, and PEAK all have interfaces, but since they’re not part of the language or standard library, for most Python developers it’s as if they don’t exist. The existence of interfaces in Java means that the body of a specification can talk about named and rigorously defined kinds of objects, for whatever the specification is about. Python specifications, by contrast, are often characterized by handwavy notions of the “protocols” that objects implement, or are merely documentation for an implementation.
As long as one is dealing with libraries, this can perhaps suffice. But to create frameworks and platforms, it isn’t enough to specify what one implementation does. You have to be able to talk about what implementations in general are supposed to do, because some of the users of a framework or platform will be creating their own implementations of needed functionality.
Consider OSGi, for example. OSGi is the Open Services Gateway Initiative, and they’ve defined a standard service platform for component-oriented, networked services. Basically, an OSGi platform implementation lets you install software “bundles”. Bundles can import classes from other bundles, or export them, with managed version dependencies. They can be started or stopped, offer services to other bundles, and dynamically access services provided by other bundles. This allows you to create customized applications, such as a web server bundle that is dynamically notified when any bundles offer servlets that it should serve.
OSGi is used in a variety of products and systems, including “smart home” applications, vehicle electronics, and service provisioning systems. It’s also used as the basis of the Eclipse IDE platform’s “plug-in” system. Currently, the Python world has nothing like it. By comparison, Zope 2’s Products and Chandler’s Parcels are crude toys.
By the very nature of what something like OSGi does, it has to be specified in terms of interfaces. There are multiple platform implementations that load bundles, and of course there are many, many bundles, and services offered by those bundles. Without interfaces, there would be “no there there” – nothing to exist or document.
And many Python developers would say, “So what? We don’ need no stinkin’ standards.” Maybe especially not 600-page Java standards like OSGi. Arguably, only a handful of application platforms in the Python world are complex enough to truly need something like OSGi anyway: mainly IDEs, application servers, and extensible application platforms (like Chandler).
But, in the Java world, you don’t have to “truly need” something in order to be able to benefit from it. If you use functionality of that kind, the sensible thing to do is to follow the standard, either by dropping in an existing implementation, or using your own mocked-up subset of the standard until you need a more sophisticated implementation. Either way, you have an established model to follow.
In this way, a savvy Java developer can avoid much of the head-scratching and prototyping that a Python developer would be doing in order to flesh out their needs in a given application area. Instead of reinventing the concept of the wheel, the Java developer just writes an IWheel implementation.
Of course, individual Python developers can and do pilfer from Java specs. I myself make it a particular point to examine the state-of-the-art in Java before undertaking the design of any complex facility for Python. I then have to go through a fairly lengthy process of “Pythonification”, often involving multiple rewrites, to get the API truly Pythonic.
But when I’m done, my implementation and interfaces are still not a standard in the Python world. Nobody is going to know about what I did, and the next guy over is going to either do the same thing I did, or throw together their own little thing. Individually, perhaps, we are all productive, but our collective productivity is lower in the Python community, because we are all forced to reinvent ‘IWheel’, up until there’s a ‘Wheel’ implementation in the standard library.
And of course that implementation will have to be all things to all people, or odds are good that it won’t actually get into the standard library. And, by a curious coincidence, a surprising number of modules adopted by the standard library are in fact derived from equivalent Java interfaces or implementations! For example the ‘logging’ module comes from log4j, the ‘threading’ module mimics Java thread classes, and ‘unitttest’ is a JUnit clone.
So, does something about the Java language inherently inspire better specifications? Could it be that this is a byproduct of having, and consistently using, interfaces? Maybe the fact that Java forces you to think about interfaces (at least a little), encourages Java architects to design better frameworks? More to the point, is there any way we can leverage this characteristic in Python, such that we’re not always begging scraps from Java’s table?
Maybe that will never happen, perhaps because the Python community simply doesn’t have the critical mass needed to have enough of the right people to design such specs. Or maybe kneejerk reactions against interfaces as “creeping static-ism” will keep the community from adopting the current de-facto standards for interfaces that exist in Zope, Twisted and PEAK.
Who can say? As for me, I’ll just keep on picking my scraps of Java where I can find them, and working towards the day when Python won’t have to rely on interfaces defined by ad-hoc description, and specifications defined by their implementation.
I think a big part of Java’s separation of specification and implementation has to do with the proprietary influences as well. A proprietary implementation makes a really poor specification. Also, even if their is a catagory-killer implementation, if that implementation is proprietary it won’t be universal. This isn’t a difference in languages so much as culture.
That doesn’t mean specs and interfaces aren’t useful, but in Python they are really only useful someplace where interoperability is useful, when there’s a real reason for multiple implementations. And even then, not all cases where there are multiple implementations would make sense. For instance, Cheetah and ZPT could share an interface, but ZPT and Nevow couldn’t — though they solve the same problem, their differences effect the interface too greatly.
There is an issue with trivially incompatible interfaces, which is something adapters could handle nicely. But that’s something we can do now, but mostly don’t. Zope 3 people adapt Zope 3 objects, Twisted people adapt Twisted objects, etc. As a non-Zope, non-PEAK, non-Twisted developer I’m not going to save time at this point using interfaces, and it’s not clear that my non-interface-using code will be cleaner when interfaces are partially introduced. I haven’t had luck so far; I haven’t tried that much, but it’ll be more compelling when the returns are immediate.
I think there’s something important in interfaces and increased formality, but it’s not clear what the “Pythonic” approach will be (acknowledging that the Pythonic approach here must be synthesized). We have to build, as individuals and a community, an intuition about how these things work. That’s hard. And it’s moving forward slowly — even as development continues with Zope, Twisted, and PEAK, I worry that the development only makes things worse, increasing the gap that has to be bridged by people new to interfaces.
“””As a non-Zope, non-PEAK, non-Twisted developer I’m not going to save time at this point using interfaces”””
You hit the nail precisely on the head. Interfaces aren’t for a *individual developer*, in the same way that individual developers sometimes eschew the use of revision control and/or unit tests. The benefit of interfaces is only viscerally perceptible once *multiple* developers are involved.
However, once you perceive the benefit, there’s no going back, any more than people who become “CVS infected” or “test infected” ever go back, even if they go back to working on their own. And of course, in an open source project, you’re never *really* working “on your own” anyway. One thing in common between Zope and Twisted is that they have large development communities; my involvement in the Zope community was more than enough to “interface infect” me from there on out.
Also, note that as long as you know how to *read* interfaces, then you benefit from the existence of an interface standard when other projects publish *their* interfaces. Although relatively few people ever write books, this should not be construed to mean that having a standard alphabet is a bad idea! 🙂
As to the right “approach” for interfaces, what is most needed is acceptance of a paradigm for the standard library and for PEPs as to how to *document* interfaces, coupled with a trivial mechanism for unambiguously *identifying* an interface. This could be as simple as:
class ISomething: pass
and for some time, Twisted got by just fine with an interface implementation that wasn’t much more complicated than that.
Really, there isn’t anything complex about interfaces at this basic level. Their main function is *documentation*; adaptation and other facilities can reasonably considered advanced usage. (On the other hand, the defacto standard of ‘IFoo(bar)’ seems to me no more difficult to grasp than say ‘int(bar)’ or ‘str(bar)’, or a cast in C or Java.)
“””Cheetah and ZPT could share an interface, but ZPT and Nevow couldn’t”””
Perhaps not; but Nevow could offer the Cheetah/ZPT interface (or be adapted to it), in addition to offering its own, more powerful interface. This type of incremental compatibility is useful because it allows people to use a new tool with tools they already have.
There’s a couple things I want to comment on here. First, I’m convinced that Java people create these 600+ page specifications to ensure jobs for themselves. I’ve never run into so many people with so many 4-letter acronyms (all starting or having ‘J’ in them somewhere) splattered like so much mental JO on their resume. Many of the specs do solve huge complex problems in huge complex ways, thereby assuring that simple problems are nearly impossible to solve.
Second, these huge entrenched specs often are mental straight-jackets that stiffle creativity for a couple reasons. First they don’t want upset the resume cart, but also they do not want to “re invent the wheel.” When the wheel is 600 feet in diameter and made out of cast iron, who would?
Python people seem to be more focused on “getting it done,” and resolving the architecture over iteration (much like what I learned in Smalltalk), where-as Java people create huge “architectures” that are immutable once they’re done.
This to me is best testified by the fact that many “Java developers” (as opposed to people who are developers and might work in Java) often seem to have a spec for every problem. That they have no idea what the underlying need is seems irelevent to which spec they’ll toss out as the silver bullet—witness the proliferation of J2EE.
Yes, I forgot about documentation. Interfaces are a pretty compact way to document an object, it’s not much longer than any other documentation you could come up with, except inline docstrings. Though then you probably lose inline docstrings. Hrm.
If I go writing interfaces willy nilly for my projects that have public objects, am I likely to get something wrong? There’s an asymmetry there, if I’m producing something that I’m not also consuming. Realistically, will those interfaces be of much use beyond documentation? The mechanics are straight forward enough, it’s making intelligent and productive use of interfaces that feels like the barrier. I’ve already tried making unproductive use of interfaces, which was successful but unsatisfying.
…and sometimes a spec is the right thing, because the application area really *is* complex. You seem to be ignoring the fact that there exist Python programmers (me, for one) who happen to *like* some of those Java specs, because they actually address real business software development issues. I’ve actually re-implemented the JNDI spec in Python — then evolved it over a few iterations to make it more Pythonic. (You can see the results in the ‘peak.naming’ package.)
JNDI is a good example of a hidden gem in Java: 90% of Java developers I’ve met have heard of JNDI, but really have no idea what it’s good for. It’s another one of those things that (like interfaces in Python) don’t make a whole lot of sense unless you’ve experienced an environment where the need for it is palpable. Then, you wonder how you got along without it, and quickly get tired of trying to explain it to people who haven’t “gotten” it yet. (For a partial introduction to peak.naming and JNDI, check out this brief intro to naming concepts, which also compares peak.naming and JNDI.)
For all the failings of J2EE, the leading edge of the Java community has mostly moved to post-J2EE concepts, such as lightweight containers, Hibernate instead of bean persistence, and so on. Some of these systems are open source and developed in just as evolutionary a fashion as the typical Python package. So, the Java community isn’t spec-bound, or lacking in innovation. Remember: a lot of innovative systems end up in Python as clones of Java packages!
So, as much as you may dislike specifications, the requirement for interoperability is what drives the need for specifications. If you work alone, and your work is used by no one, and you build everything yourself, well, then you certainly have no need of specifications! However, you will forever be inventing your own wheels that won’t fit on anybody else’s axles, or vice versa.
Don’t believe me? Just consider the dozens of Python web frameworks that don’t interoperate with more than one or two web server environments.
In the Java world, the existence of specifications is what allows the community to collaborate on much larger projects than are currently practical in the Python world.
“””If I go writing interfaces willy nilly for my projects that have public objects, am I likely to get something wrong?”””
*shrug*. Any documentation can be wrong. If you’re worried about this, though, the Zope interface package has some facilities for verifying that a class implements an interface as described, at least in terms of having all the described methods, with correct signatures.
As for errors that go the other way, i.e., failing to document that something’s part of an interface, that’s a bit more difficult. However, if it’s an interface on things that you *publish* (i.e., you are the implementer of the interface), then this is “safe” in that the user doesn’t get to use the thing you forgot to mention. If it’s an interface on something that you *require*, then you’ll get a bug report when a user implements the interface and their object still doesn’t work with your package.
In other words, it’s like any other documentation; if there’s a problem, either your users will figure it out or report the problem, or both.
(btw, my previous comment was directed at the anonymous comment preceding yours; I wasn’t expecting another comment to be added while I was writing that one.)
Those modules borrowed from Java (logging, unittest) are highly unpythonic and they’re looking alien compared to other parts of standard library. Therefore many people doesn’t like them and create their own solutions from scratch.
Eugene
As much as I adore Python, you have to look at things like JDBC and the Servlet API in Java and realize how much better off you are in the Java world trying to solve those sorts of problems. Those solutions wouldn’t exist without interfaces.
People are indeed recreating, refactoring, or otherwise Pythonizing (can I get away with that verb? 🙂 things like unittest, logging and so on. Something to keep in mind, though, is that Python needed those facilities badly enough to put them in the standard library in their current, un-Pythonic, Java-derived form.
Likewise, the WSGI initiative has gained the momentum it has because Pythonistas have seen the success Java has had with the various servlet and JSP specifications, particularly the container specifications. There is value is these specifications, in that they (typically) specify *components*, rather than merely classes. By specifying at the component level, an individual developer can interchange implementations (relatively) easily. Also, the specification presents a reasonably-well-thought-out set of best practices for implementing components that fulfill certain purposes and functionality. Yes, EJBs were over-hyped and misused, but that’s the exception that proves the rule. Furthermore, there are places where EJBs are very appropriate.
Personally, I can’t wait to see the time when Python-the-platform has matured enough to spawn useful component-level specifications. For one thing, that will be the day that enough people are doing large enough projects in Python to need them.
It seems to me that Java is just better for large projects. Python will let you do what you need to do very elegantly, very quickly as compared to Java (e.g. print ‘hello world’), but there’s a tradeoff in being able to do what you want without jumping through fifty-thousand hoops vs. having the machine tell you that you’re doing something wrong. You can build on top of Python to make the machine say “hey, you’re not implementing the whole interface” or “you’re binding a new variable on that object”, but I wouldn’t ever expect it to become part of Python.
Maybe it should, if Python’s going to become a language used for gigantic multi-enterprise wide applications … but I doubt if the use of interfaces will ever become pervasive, and unless their use were transparent to all the 50 line scripts in the world, I for one wouldn’t want them to.
Me either. But Guido has made it plain that any type checking additions to Python will be optional, so we’re quite safe on that count. I wouldn’t worry about it.
Interfaces, like static typing, are structures (in the sociological sense, though formal in their implementation). They define boundaries, and as they do so, they limit. The boundaries are arbitrary even as they are distinct. This is a safety net: You cannot move without the boundaries. This is also just a net that you’re caught in.
The way the concept of Interfaces is defined they deal less with interfaces or protocols in their informal sense and more with declaration. Implementing an Interface isn’t the same as implementating an interface. The former is a declaration of following a specification while the latter is just following it.
The problem to me seems mainly to be that the limits or boundaries created by using Interfaces will easily become a restriction rather than a help. To deal with that restriction even more complex structures are created (adaptors, etc.), and with them more Interfaces to bind.
It isn’t so much the formal specification that is the problem in reality, it is the forced-upon manifestation inherent in Interfaces or static typing. The trivial example of course being how a function accepting a file object to read from would accept any object having a read method. The specification neccessary is which attributes are neccessary (does it need both read and readlines, does it need to be iterable, etc.), but the formal Interface would mean an arbitrary limit. Should there be a Readable interface? or should there just be a File interface? or a ReadWrite interface? Then there must also be an Iterator interface, of course, and so on. The form the Interface defines creates a forced-upon manifestation. The more general the Interface is, the larger the burden to implement it fully (if this is actually enforced), the more specific the Interface is, the more Interfaces to know about, and the more to implement.
Formal Interfaces have always been and continue to be unpleasant.
In that respect, interfaces are like any other docs. Nobody likes writing ’em, but everybody would prefer the systems they use to have them. 🙂
More seriously, *not* pinning down precisely what methods you do or don’t use is a big problem in Python. What methods *do* I need to have on that “file-like” object? Do I need softspace? isatty? The code either uses them or it doesn’t. Talking about file-like objects and not formally pinning down what you mean wastes other people’s time, by forcing them to read the code in addition to your documentation. For simple things that might work, but it doesn’t scale to any kind of large systems… which is why the largest systems written in Python tend to use interfaces.
May be interfaces in python should be something like assert statement or should work like doctest module do?
PS. Enlish is not my naitive language, so i hope this post is sufficiently readible… Sorry if it is not.
Oh, by the way, with respect to the “file-like object” example, there’s actually a way to spell arbitrary method subsets in PyProtocols, courtesy of this idea from Samuele Pedroni:
IBidirectionalStream = protocolForType(file, [‘read’,’write’,’close’])
specifies an object that implements the ‘read’, ‘write’ and ‘close’ methods of a ‘file’ object. ‘file’ instances and subclasses will automatically match this protocol, as will objects that explicitly declare they support this, or a more complete protocol (i.e. another ‘file’-based protocol with more methods). Also, this version:
IBidirectionalStream = protocolForType(file, [‘read’,’write’,’close’], implicit=True)
will also match any object that has those three attributes, whether there’s been any explicit declaration or not.
These are still pretty decent pieces of formal documentation regarding what a function requires, and they’re certainly no more obtrusive than documenting the needed methods in any other form. The mere existence of interfaces and the ability to check them, does not mean it intrudes on coding any more than having to have separate classes does. Imagine if somebody said, “I don’t see why we have to have different classes. Why don’t we just use dictionaries and put whatever values in them we want, and just use functions instead of methods?” Because the result would be chaos once you get beyond a certain program size, that’s why. And the same is true for interfaces.
“””May be interfaces in python should be something like assert statement or should work like doctest module do?”””
How would you assert a function or method’s calling signature?
Perhaps I’m misunderstanding you, but I don’t see how asserts or doctests could be used in a modular way.
For example, in a given framework, there might be dozens of methods that have a parameter that must implement a particular interface, so if an interface was defined by assertions, you’d need some way to modularly specify that, so you could use it in those places. That would mean putting it into a class or function, at which point you might as well use the techniques that Python frameworks use now.
Read This: http://www.cavendishscience.org/phys/brucelee.htm
I find many parallels with the Java versus Python divide.
This is the paradox of programming. The need for form and structure pitted against the need for a fluid solution. Python fits well because it can be manipulated to meet the needs of the project.
Python programmers are rightly afraid of creating artificial form. Most times they’re already limited enough by the nature of the problem. In some sense, they are much like the craftsman. Approaching each problem with a practiced hand, making a solution that is perfect in its own way.
Java programmers revel in the joy and power of the industrialist. Taking artificial form to its highest form, they proliferate standard interfaces. When you have enough parts that fit together, you can do almost anything. The industrial solution is often large and unwieldy, but it works, works well, and can be relied upon as a tried and true method.
The best programs I have seen have been a merging of the two methods that most people can’t appreciate. A “no-form” of programming. Essentially, the art of crafting an interface that describes–that fits–the problem so snugly, that there is no need for any other interface.
I would say that about 2/3rds of both the Java and Python worlds don’t get this. These are the Pythoneer’s that don’t understand interfaces, unittests, and revision control–and can generate fiendishly difficult code. These are the Javans that write horrible disposible interfaces, persist data willy nilly, and generally mobilize Java to create atrocities that lack design in a grotesque, almost Lovecraftian way.
I guess I’m just reiterating what a lot of people have already said–but I find the unified perspective very significant. Knowing when to use (and not to use) the above is not something that can be learned without having achieved mastery.
Only time will tell if Python acquires interfaces. I, for one, would welcome them–but I see no need of them as a language constraint. People often think of interfaces in terms of the Java implementation. To all Javans and Pythoneers alike–Java interfaces only exist because that’s how they must be expressed in the framework of Java. They are static and heavy with declaration because they need to be. There’s nothing wrong with that. Interfaces achieve something that is good, regardless of the language that implements them.
Take a real, hard look at PEAK or Twisted or Zope 3 Interfaces. The Python world need only settle on an implementation. But we do need an implementation. I would like to see one of them in the standard library. I quite like the Twisted implementation myself. Achieving this could forever change the future of Python. I think for the better. We don’t need interfaces to be part of Python linguistically. We do need to agree on a blessed, minimal implementation, or we may only ever have frameworks written in Python, rather than have the framework BE Python. That is the almost intoxicating part of Java–it IS the framework.
My thoughts about this issue:
1.- Of course well defined interfaces are great, but the article naively supposes “standard” Java interfaces are well defined. That’s not the case in my own experience. You just need to take a look at J2EE, JMX, JNDI or JSF. From my point of view they are worst than no interfaces at all. They are complex, bad-designed and far away from universal solving. Usually its desing is constrained by the time-limit impossed by commercial interests. And many of them are just Java implementations of something already existent (J2EE is just a -pitfall- reimplementation of the many frameworks available, JMX is no more java-flavorish SNMP with some non-usefull stupid abstractions, etc…
2.- “As long as one is dealing with libraries, this can perhaps suffice. But to create frameworks and platforms, it isn’t enough to specify what one implementation does.”
Correct me if am wrong, but were not the TCP/IP protocol and HTML specifications of a first working-implementation?. I think that’s the way to go. Probe it works, and after that make an specification. Not the opposite (J2EE beeing the best example: make the specification , cheat bussiness CEOs, make them waste thousand of millions and then probe it doesn’t works 😉 -all that supported by an stupid 1500 pages specification -). When I was young my teachers told me that science was the process of “1º:Observing the nature,2º:Extracting conclusions and 3º: Testing them experimentally”. It looks that process get inverted with Java (and .Net):
“1º:Extracting conclusions -specs-, 2º:don’t worry about testing them and 3º:Observing the nature -if it has nothing to do with your conclusions -specs- don’t worry, maybe you are already rich after a 10 million contract-“.
3.- “we are all forced to reinvent ‘IWheel’, up until there’s a ‘Wheel’implementation in the standard library.”
Sorry, but again I think that’s the way to go. Don’t qualify anything as “standard” before beeing completly sure it can be called “standard”. Python standard API’s are usually carefully thought, JAVA (or .NET) APIs not.
APIs must be to programming as theorems to mathematics, they have to be carefully studied and accepted only when proved valid and universally valid. I don’t think is casuallity that Python is headed by some working in a (knowledge driven) University while Java (or .NET) is headed by people working for private (proffit-driven) companies.
4.- “And of course that implementation will have to be all things to all people, or odds are
good that it won’t actually get into the standard library.”
Again, that was basic programming theory tell us. ¿Do you mean Java (.Net) standard library is not all things to all people? It’s scares me just thinking about the opposite.
5.- “Maybe the fact that Java forces you to think about interfaces (at least a little), encourages Java architects to design better frameworks?”
¿Better frameworks? Probe it!. After many years using Java I’m still trying to find those “better frameworks”, (for now all I have found translate in bloated servers that takes minutes to start in a 3 Ghz PIV after which I’m less productive than I was with my tiny perl scripts) ¿Wouldn’t it be much more correct to say “Maybe the desires Sun, Oracle, IBM, BEA and others have on obtaining big goverments contrats make the write 600-pages toy-specification and bloated frameworks.”?
Regards!
“””I quite like the Twisted implementation myself.”””
Apparently, the Twisted developers didn’t, because they switched to using zope.interfaces. So, there are now actually only two interface implementations out there: zope.interface and PyProtocols. PyProtocols’ API subsumes that of zope.interface, and it adapts zope.interface objects to its own interfaces as well. The two packages both implement PEP 246, and both packages have some special hooks specifically to enable interoperation with the other.
“””You just need to take a look at J2EE, JMX, JNDI or JSF”””
I like JNDI, myself. In fact, I liked it so much that I wrote a Python version of the same concept (peak.naming).
But, it should be noted that what I liked was the *idea* and the *specification*. I have never once written any JNDI code for Java, so for all I know it’s tedious and sucky to use it in Java. My Python version is lightweight, easy to use, and virtually boilerplate free.
Meanwhile, most of the rest of your comments seem to be directed at the process used for producing specifications, which I’m not arguing with. For example, the WSGI spec (PEP 333) was created *after* I had a prototype implementation that worked well for PEAK. So I’m certainly not arguing for specifications as a substitute for understanding a problem domain. I’m merely suggesting that having a formal way to denote interfaces would be useful in writing Python specifications, making it easier to create specs that deal with complex subjects.
Certainly, they would’ve helped in writing the WSGI spec; for example I could have defined “IWSGIServer” and then not had to keep referring to “a server, gateway, or middleware” throughout the text. Being able to denote formalisms and then refer back to them is a useful thing in specifications, which is why people number their theorems and use Greek symbols in math or science papers: it lets them denote formalisms and refer back to them.
Also, under the heading of “better frameworks”, one such framework I’d suggest would be Eclipse. Certainly, it’s one of the better-performing non-trivial Java applications I’ve seen, and the plugin architecture is outstanding. I’ve learned a lot from studying Eclipse’s internal architecture as well.
Finally, with regard to all-things-to-all-people, I would have to ask, is there only one TCP/IP stack implementation? One HTTP server implementation? No? I guess one implementation for everybody isn’t an achievable goal, and sometimes maybe not even a desirable one.
I can’t agree at all on any arguing you do.
You argue under a good assumption that java is not python, and put forth negative points of the python community in terms of standards, for which the java community itself is infamous. That’s an odd reasoning to start with. But even ignoring that, it’s still invalid as rigorous standardization as you mention it, is only a dire need where you’ve got complex interwoven environments, business cases, pressure, specialists, obfuscators, suits and lot’s of booring overtime.
On any account that’s why I use python, and when I use python in a suit environment I usually tend to baffle them how I acomplish tasks faster without all the paper trail any of them “java experts” runs trough the floors, and in a fraction of the time.
“””rigorous standardization as you mention it, is only a dire need where you’ve got complex interwoven environments, business cases, pressure, specialists, obfuscators, suits and lot’s of booring overtime.”””
Maybe some of us would like to be able to use Python in such contexts. For example, I’ve spent nearly seven years using Python in an environment much like what you describe above, and having to fight anti-Python and pro-Java prejudice every step of the way. And lack of standards didn’t make it easy. I don’t like having to answer questions like, “what do you mean that this Python app won’t run in this Python server?”
In a business context, some of Python’s missing standards are frankly embarassing. If I wasn’t able to run rings around the competition *in spite of* these flaws, they would have had my head on a platter. (And they ultimately did, anyway.)
But just because we are able to work miracles with Python *despite* its shortcomings, does not mean we are achieving them *because* of its shortcomings. That’s the illogic that I seem to keep seeing here.
Meanwhile, business does what benefits business, which is not the same thing as what benefits us techies. We may not like it, but we will never change it.
“But just because we are able to work miracles with Python *despite* its shortcomings, does not mean we are achieving them *because* of its shortcomings. That’s the illogic that I seem to keep seeing here.”
Everything has two sides, every weakness bears strengths, it’s not different with python. And I’d argue that the strength flowing from the philosphoy of keeping things simple rather outweights the advantages of a lot of gackheads and a heavy paper-trail, and I don’t say that this isn’t a disadvantage at times, but maybe rather seldomly for the majority of the pythoniacs.
And from expirience I know that suits tend to close their zipper when confronted with either having me doing the stuff how I like it, or having a horde of gackheads doing half the job for double the price, maybe I’m just lucky.
I agree totally with PJE’s statment above. A thing that has always struck med with the Python world is that there seems to be a lot of NIH sentiments around. I have heard a lot of pythoneers talk about how un-cool Perl is because “there is more than one way to do it”, “it” being whatever.
In the python world, unfortunately the sentiment “there should be only one way to do it” seems to apply only to the language itself. 🙂
Standardization, agreed-upon protocols, specifications, etc. It is all good – to a certain extent, of course; and in a business context, it is necessary to have more of it than when hacking on your own projects. Interfaces, however, it seems to me, is to an extent a different issue.
I don’t know, maybe it all comes from my dislike of inheritance-based programming. I believe that Interfaces, like static typing, promises more than it can deliver. What it promises, ultimately, is a semantically correct process (or execution of that process) based on manifestation of a protocol. But it’s a lie.
I sincerely hope that there is a better way to achieve what Interfaces fail to achieve, but programatical structurization by building in arbitrary limits in a system is not the solution.
“””What it promises, ultimately, is a semantically correct process (or execution of that process) based on manifestation of a protocol”””
The Python projects that use interfaces would disagree with you. Interfaces are used for documentation, adaptation, and introspection. Sure, Zope has some tools to do “lint” or “pychecker”-style sanity checks, but that’s about it.
Relax, nobody wants forced static typing. We just want to be able to document certain formalisms. Pythonic interfaces are for “consenting adults” – if an object says it implements the interface, then that’s good enough for its consumers.
If you want another dynamic language as a guide, look at Smalltalk. There, interfaces consist of an “isFoo” method, that you stick on “object” to return False, and on anything that implements it, you return True.
But in Python, we can’t modify “object” to add new routines like that, so an interface basically consists of a dictionary containing types that implement the interface. (Or in PyProtocols’ case, a dictionary mapping types to the adapters that will supply the interface on behalf of that type, if applicable.)
Python interfaces are not Java interfaces, in other words. (Hmmm… sounds like I need to write a new article…)
“””I’d argue that the strength flowing from the philosphoy of keeping things simple rather outweights the advantages of a lot of gackheads and a heavy paper-trail”””
I’d say that this is a false dichotomy; complexity is a continuum, not either-or.
The use of interfaces isn’t what makes Twisted complex; it just does complex things. The interfaces only make it better documented. The more complex a framework is, the more it needs such documentation.
Zope X3 is a framework with far greater scope than Twisted; ergo, it has more interfaces than Twisted. Again, it’s documenting the relative complexity.
In particular, note that neither Zope nor Twisted would become simpler by removing the interfaces. At best, they would simply become less documented. At worst, they would grow dozens of ad hoc introspection or typechecking schemes, and become less flexible in the process.
If interfaces did not exist, it would be necessary to invent them — and so Zope did. Zope 2 didn’t start with interfaces, and people bitched about it being hellish to understand, and impossible to extend, due to its inheritance-based approach. Moving to interfaces over time has made it more and more fluid and dynamic — not less.
So the irony is, if you want to gain the true flexibility of a dynamic language for *users of a framework*, you need more interfaces, not less.
Indeed, current computer science, by way of the Dependency Inversion Principle, tells us that the way to a robust architecture is to depend only on abstractions, not concrete classes. And how do you represent an abstraction? Why, with an interface, of course.
I think lots of java programmers like frame works, and python programmers like libraries. If you like libraries, then interfaces are not really needed as much.
Libraries to a simple job well. They aren’t made to be extended to be very generic. A coder uses a library.
Frameworks on the other hand are made to be generic, not very usable right away. A coder modifies a framework(through inheritence or interfaces etc).
I really like the idea of evolving code. Through multiple uses. Once the code has proven itself as high quality, reusable code, that does not change much in a number of seperate applications or libraries, then I put it into a common library. Otherwise I leave it with the program that it was written for.
I see this evolving code as very similar to the idea of stable vs unstable code. Unfortunately lots of frameworks(more so than libraries) mix the unstable/unproven code with the stable/proven code.
Another thing I see with frameworks is they do not make parts of the framework reusable outside of it. The code is often tightly coupled with the rest of the frame work. Even though the code need not require the rest of the framework.
It is interesting to note the python web frameworks made by java people: twisted, PEAK, Zope.
The End.
— illume.
“””It is interesting to note the python web frameworks made by java people: twisted, PEAK, Zope.”””
Wha? I can’t speak for Glyph or Jim or their contributor communities, but PEAK certainly isn’t written by “java people”.
Also, none of the systems you mentioned are “web frameworks”. Twisted is a collection of asynchronous communications frameworks, PEAK is a collection of general-purpose application frameworks, and Zope is a collection of application server and content-management frameworks.
“””they do not make parts of the framework reusable outside of it. The code is often tightly coupled with the rest of the frame work. Even though the code need not require the rest of the framework”””
I’m not sure what frameworks you’re talking about here. However, a well designed framework allows you to replace collaborators, and use more than one of a particular kind of thing.
However, by definition you can’t take *part* of an individual framework. That would be like taking part of the framing of a house; it wouldn’t stay standing.
In practice, Twisted, PEAK and Zope are actually *collections* of frameworks, some of which are built on other frameworks within the same collection. The “leaf” frameworks in such a package aren’t usable without the “trunk” frameworks, but the “trunk” frameworks don’t depend on the “leaves”.
“””Wha? I can’t speak for Glyph or Jim or their contributor communities, but PEAK certainly isn’t written by “java people”.”””
By that I meant that they are all influenced by java to some extent. Ie they all came from a java background beforehand. That is ‘python is not java’. It is understandable that certain techniques, and ideas have come through.
“””Also, none of the systems you mentioned are “web frameworks”. Twisted is a collection of asynchronous communications frameworks, PEAK is a collection of general-purpose application frameworks, and Zope is a collection of application server and content-management frameworks.”””
They all have something to do with the web. Each of the user communities uses the frameworks for web stuff.
From the PEAK webpage: ‘At this point, it’s more of a proof-of-concept than a working web framework, since it only includes features aimed at creating static sites and dynamic read-only sites (e.g. from databases). ‘
“””I’m not sure what frameworks you’re talking about here. However, a well designed framework allows you to replace collaborators, and use more than one of a particular kind of thing.”””
Can you use part of one framework inside of another easily? No. Which is why interfaces are defined for frameworks.
“””However, by definition you can’t take *part* of an individual framework. That would be like taking part of the framing of a house; it wouldn’t stay standing.”””
My point exactly. Frameworks often require other parts of the framework. That is they are tightly coupled to other parts of the framework. Most houses can have their walls, floors, framing, or roofs taken apart with a risk of the rest falling down(but each can be removed if you are careful:). Some parts of the house are a lot more modular than others. If a couch was made in a framework manner it would be stuck into a wall. Luckily couches are more modular 🙂
“””In practice, Twisted, PEAK and Zope are actually *collections* of frameworks, some of which are built on other frameworks within the same collection. The “leaf” frameworks in such a package aren’t usable without the “trunk” frameworks, but the “trunk” frameworks don’t depend on the “leaves”.”””
I think this is why interfaces, and specifications are needed in framework land. If you want to use parts of the framework elsewhere(like in other frameworks/applications) then it is hard because they are tightly coupled.
“””By that I meant that they are all influenced by java to some extent. Ie they all came from a java background beforehand.”””
Again, I can’t speak for Glyph or Jim, but I learned Python years before Java. I’ve written a sum total of three Java classes in my life. And they were an extension for Jython that I wrote three years ago and never used. So, I don’t know what this “Java background” you speak of is.
“””From the PEAK webpage: ‘At this point, it’s more of a proof-of-concept than a working web framework,…”””
Right; that’s the peak.web framework, which is probably the single most “alpha” framework in PEAK. If you look at the Wiki, you’ll see there are at least a dozen other frameworks available in PEAK – most of them far more comprehensive and stable than peak.web.
“””Can you use part of one framework inside of another easily?”””
If both are based on PEP 246-compatible interfaces, absolutely. Just write an adapter class that maps one framework’s interface to the other. It’s frameworks that don’t have interfaces, that are more difficult to connect.
“””My point exactly. Frameworks often require other parts of the framework. That is they are tightly coupled to other parts of the framework.”””
You miss what I’m saying. A framework that is defined in terms of interfaces depends on abstractions. You have to have an implementation of the requisite abstractions, but they don’t have to be the ones the framework provides. That’s the whole point of having interfaces — to describe the requirements for each part of a framework, such that it can *be* replaced. It’s like saying, you need a beam that can hold thus-and-such weight, and here’s one you can use if you like. If you have other requirements, you can subsitute your own beam here, as long as it can support this weight.
“””If you want to use parts of the framework elsewhere(like in other frameworks/applications) then it is hard because they are tightly coupled.”””
Obviously, you haven’t used any frameworks written by people with a grasp of the Dependency Inversion Principle. People use parts of PEAK with Twisted, or parts of Twisted with PEAK all the time. Even though the two frameworks have completely different ideas of what an event loop looks like (including how many you can have), *because both frameworks rely on interfaces rather than implementations*, it’s possible to write adapters between the two of them. Heck, PEAK and Twisted don’t even use the same *implementation of interfaces*. If that’s not loosely coupled, I don’t know what the heck is.
This comment has been removed by a blog administrator.
This comment has been removed by a blog administrator.
It’s great that you can implement interfaces in Python where they help your project.
I personally have never seen any evidence to suggest that interfaces are the only way to develop “enterprise” applications.
If interfaces are that important to you as a developer, just go with the best and use Java.
You can implement interfaces in Python, but the community and culture of Python has decided that interfaces aren’t very useful and not very Pythonic.
Inheritance, metaclasses, and introspection facilities are all the interface I’ve needed for my large projects. If I ever need interfaces, it’s good to know that the facilities exist for them. However, I don’t think interfaces are used so regularly or are clearly a default for any project that they should be included in the core language and should shape the development of Python-the-language nor Python-the-community.
I know this post is somewhat old, but just in case it flew under your radar, Enthough has develop an OSGi inspired framework (I don't to which point though):
http://code.enthought.com/projects/envisage/
That said, I get that was not your point and that OSGi was just an example.
The powerful think about Java is not interfaces as you said PJE, but it is about the community and how Java evolved during the all past years and still evolving. It is about the process governed by certain rules, which one is more important about them that is to be open and adopted by the community so no single entity is in control of the specs. This is the main powerful think about Java technology.
From thet PoV Python can do the same thing, if we started to think about Python as a platform that we program to with Python and that this platform is providing developers with some facilities and functionalities and that it can be extended by adding new facilities and functionalities so we can adopt specs from what ever place. IMO specs specified by the JCP.org is not only for Java language neither JVM only I look at them as specs defined using an object oriented modeling language in that case it is the Java language itself so out of this vision we can, the Python community, adopt such specs and implement them the way suitable to Python technology. But again adoption the community the key not the language, so pushing towards making a process to govern the adoption of new specs or technologies to be added to the Python platform or to be available as separate modules/features and used upon requirement just the same way happened with JDBC and XML Java API(s) before.
Well the point in here is that Java have a lot of interfaces like the JNDI interface that you mention, and some of them are unknown for a large amount of developers and if a interface is unknown to a large extent of developers, why it exists? Isn't it better to have a small set of interfaces in the standard library and the rest externally so that every developer knows the base library, and only the people that use the other external libraries have to known about them.
Second, about the OSGI framework, one of the objectives of it is to improve the module handling of java, but if that is really one big flaw of the language and that is noticed in the real world, why not just fix the language, in a way that the existing functionality get rearranged in order to fulfill the reality? And I'm also one developer of java that has learned python and started to love it.
Hi Fact Cat 🙂
I agree with you, but the point in general is technologies specified in Java language is not necessarily for Java only, as long as it targets a technology that other people – like Python people – can get benefit from, there is no problem of looking at this Java specs as a sort of technical specs and start implementing it in Python, not necessarily in the Python platform itself but can be as a separate library as you suggested, and as I said before the "Java" word does not mean the "Java Language" to me anymore, it is more related to being a technology and even being expressed in Java does not limit it to Java.