Slashdot Mirror
Python Moving into the Enterprise
Qa1 writes "Seems that Python is moving into the enterprise. At the recent PyCon it has become apparent that it's not just Google, GIS, Nokia or even Microsoft anymore. The article points out that Python is increasingly becoming a perfectly viable and even preferred choice for the enterprise. More and more companies are looking at Python as a good alternative to past favorites like Java. Will we finally be able to code for living in a language that's not painful? Exciting times!"
I work at an Application Service Provider startup with 16 employees (5 developers) using Python (30K lines+).
I have 6 years of Perl development plus another 8 in C. So, a newcomer to Python (about 2 months now), I have several reactions shaded by that experience:
* Nice syntax: Not perfect, but very passable overall.
* Love the no-brackets: Indentation as a means of delineating code blocks is great; there's no debate over where to put squiggly braces (the 'if test { statement; } stuff;
* Immature toolsets: there are very few mature toolsets yet. We're using SQLObject, which is in version 0.6, as an object-relational-mapper. It's got some limitations and is admittedly not 'enterprise ready'. it's hard to compare to the Perl DBI because the dbi just is an interface and doesn't do mapping.
* Lack of CPAN: the single most fantastic "tool" I've found in my programming career (15 years) has been CPAN. Got a problem? Someone has probably already seen it and started a solution. I know this is in the works for Python but the tools are not all there yet.
* Syntax (bad): Lack of a requirement to declare vars before use. I really would like the ability to require that all vars are explicitly declared before being assigned to. it would help coding reliability.
Just my 5 cents.
-- Kevin
Unitarian Church: Freethinkers Congregate!
Do yourself a favor and sacrifice 3 months of your life learning Zope & Plone. If you're into web development, it will pay off big at the end.
It's like: why build your own search engine, security engine, your own membership system, html form engine, templating system, cache engine, skin system, content types & custom types, etc, when you can just use zope & plone and get a complete framework with open source products and addons on which thousands already develop at the highest profesional level?
I admit that Plone and zope suffer from some documentation problem, but it's possible to overcome that. There are free books, available online (Zope book and The Definitive Guide to Plone) that can get you through. The documentation on Plone.org is getting very good. There are several code repositories (collective is one of them and some on zope.org) that have example products. Also, read the sources, they're not that hard to understand.
And before any of you jump and shout Booo!! ZODB, let me remind you that you can use just as well a reqular sql server to store your content information.
I'll do the stupid thing first and then you shy people follow...
I don't find Java as a language painful.
It's the output of Java programmers that turns my stomach.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
That being said I am enjoying it. I recently found I was writing a perl program that became unweidly in its comlpexity and impossible to maintain. So I converted to python. My reason for doing so was the existience of a nice matlab packages that allowed me the ability to recycle matlab code and make nice graphs. The syntax in python is cleaner with lets me do more complex array manipulations in the scientific envirnoment.
On the other hand I note that this syntactic sugar is simply a coating. FOr example, python implementes obects via an underlying hash just the same way perl does. But it hides it from view. Thus you get less flexibility in objects than perl and no real ability to optimize their speed since the access method is frozen in the syntax.
other things that trouble me are its seeming incompleteness of many of its metafors. For example, variables do spring into existence upon assignment but they dont auto initialize. Thus simmple things like counting the occurence frequency words in a file becomes a hassle since you have to either explicitly initialize every hashkey value to zero, or use one of the slow accessor methods (like .get()) that introduce huge perofrmance penalties. And the method of doing this is different for arrays, hashes, and scalars. auto-instantiation is somewhat dangerous too since a typo can now become an error without some means of declaring a variable name was meant to exist (e.g. the perl "my" statement).
Related to the lack of auto-initialization is the tendency to rely on the crutch of throwing exception rather than returning default values or signals that allow the progammer to decide if it's worth throwing an exception. I find I end up wrapping too many inner loop clauses in "try" statements. If operations that failed simply returned "None" or zero as appros many things could be simplified without any loss of ability to use exceptions properly.
other incomplete features are a lack of consistency on when an intrinsic operation is done in-place or returns the result. for example .sort() is done in place while .ltrim() is not. While one might wish to argue that space issues can require in-place operations, it woul dbe better to detect when an operation can be done in place from the syntax: a = a.sort() should be done inplace. b = a.sort() should not modify "a".
typcasting also seems to be incomplete as well. Take for example the casting of strings to integers. try this: i= int(45.3); i = int('45') ; i = int('45.3'). The first two casts work. the last one is an error. Why? I note .atoi() also fails in the same way.
My final lament about unfinshed python is the screaming lack of a decent syntax chekcer. Too many of its errors occur at runtime. It's weird that its the low level syntax of python that seems so unbaked. The high level imports are luxurious indeed and are a major attraction of the language. Having a conveinent operation like "shelve" for persistence takes enormous pain out of coding (now if 'shelve' could just use objects rather than olny strings for keys it would be complete).
My hope is that someday python will take advantage of the syntactic sugar to imlpement objects in a faster way under the hood.
all in all I do like python because it's a lot simpler to get the job done than Java or C++. If you know perl then python is useless as a scrpting language (sadly pathetic really) but if you dont know perl then python must seem like a fantastic scripting language if you are coming from C++.
Some drink at the fountain of knowledge. Others just gargle.
One thing I've never been able to grasp is why Python proponents always mention the fact that whitespace is significant as a good thing.
Whitespace (or more specifically, indentation) significance forces you to make the visual structure of your code match its semantic structure.
Having used both, I'd say that Python is quite a bit terser than Java, which is very good in itself. Java is a bit pickier at compile time, which usually is a good thing.
Probably the biggest difference is that there are no checked exceptions in Python. Java has both checked exception and non-checked ("runtime") exceptions, but the normal type of exception used in practice is checked. A checked exception is compulsory for the caller to handle or to pass up.
In theory, a programmer using an API with checked exceptions has to consider all the things that could possibly go wrong. In reality, the idea you can catch every error before you get to testing is a pipe dream. You often don't know what you want to do with it until you have some empirical experience with your basic design. So you do one of two things -- either handle the exception in a half-assed but temporary manner (hoping you'll remember to come back and fix it later), or you pass the buck.
Since the best of these two alternative practices (passing the buck upward) is the better, that means that it is a lot of work to get traction -- you can create a facade layer to orchestrate all kinds of low level stuff, but there is a tendency for that low level stuff to bleed through your facade. Modern Java practice (within the last couple of years) has rediscoverd the runtime exception -- which works exactly like the Python exception. Hibernate 3, for example, uses runtime exceptions. Personally, I'll rip bleeding strips off flesh of one of my guys who does something stupid with an exception -- because it's so easy to just wrap it in a runtime exception (we have a wrapper class for this) and rethrow it. Throwing an exception in a tester's face leads to quicker fault discovery than papering it over.
I think the remaining difference between Python is that it's concept of collections are built-in, whereas the Java language only has generic objects and containers are built using this low level stuff. The resutl is that Python gets a big win when it comes to providing terse, convenient and easy to read syntax for processing all the elements in a collection. In programming terms, this task is about as common as dirt on a farm, and is a major win for Python.
I think Groovy may be more the way to go for Java shops looking for a productivity boost. Python has its own set of gotchas. Which is not to say it isn't quite good, but I'm not a big fan of the idea of combining Java and Python.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
One of the benefits is in things like duck typing. Often you don't care what kind of object something is so long as it has some certain method. To put it in a practical way I work with zope which is a python based app server which has an object database as part of it. Often I will run queries and get objects back. Most of the time I don't care if it is a file, picture, dtml document, or any of the many other types in the db all I care is that it has an id and it is willing to draw its url. Those are the conditions I have for working with the object.
So you work with objects by interface rather then by type. The interface also does not have to be a complete interface. You can implement as much of the interface as you need for something. I have some objects that are not lists and can not be used as lists however I have implemented some methods that make it so you can iterate over them like lists and slice them like lists.
This makes many tasks far simpler and encourages more regularity in usage.
How do you check if a substring is in a string, an item in a sequence, a key in dictionary etc? How do you iterate over them? In python it is all the same. if substing in string, if item in seq, if key in dict and the for character in string, for item in seq, for key in dict, for line in file, etc etc etc.
Types are nice but the types the static compilers have are not the types my apps use. The static type systems just end up costing me more time to develop working apps with then the dynamic typing systems and you have to test the product anyways.
Computer modeling for biotech drug manufacturing is HARD!