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!"
Aren't some of them using Jython, which is really just Python on top of Java anyway.
Im not a coder my self, altough I hahe programmed in Java and in python, but I fail to see Python's advantages comparing to Java in an enterprise environment.
Besides... wasn't Star Trek cancelled?
Python is a nice language, but it's excruciatingly slow. It's below Tcl on The Computer Language Shootout, which is telling.
Happy. It's open, and could be a sign that MS is actually "getting it". Besides, it's already possible to do python under java, but IronPython looks better, and MS is employing the guy who does it.
I am trolling
for Python jobs. It returned 312 jobs. Java returned 9196. I don't think Python will ever dent Java's dominance in the enterprise. Do you really expect Python to do what .NET has failed to do? Not a chance. It is a cute scripting language. No more and no less. Python competes with Perl and Ruby.
It seems Google is using Python for a good deal of stuff... And I thought google was enteprise
Assembling etherkillers for fun an profit
Then the newer pythons allow you to import from a zip. That needs polish, there should be a standard way to package a whole app in a zip (just to make it harder to screw up the file distribution. Having a single unit that contains all the needed code is a huge positive; it's just that much harder to screw stuff up.
Then there are people working on compiler speed, really it isn't as bad as you might think from some of the benchmarks. It can use some improvment though and people are working on it.
Typical Example Mr. Golfplayer. Found a great little OSS application, needs compiling, uses Perl, running make, opps need to use CPAN, "Oh crap, company firewall blocks FTP", "No problem, I'll download the packages one at a time.", followed by individual downloads, packages added only to find out a package requires another package!
Bzzzt! Wrong!
Interdependencies of packages on CPAN are a clusterfuck. All the hack work is paid for by us compilers.
You tell me to make a backup of CPAN or what? You can't call these packages easily, it's crap work you have to make a offline mirror of CPAN. No. No. No. CPAN is the plague. You customize your Perl env and build and start using non-standard hack libs just because you can and you quote CPAN!
Python might not have so many libraries OR a so-called package repository but the standard libraries accomplish as much as the fancy CPAN calling Perl code.
So, instead of Java we could use perl, pyton, php (remember that?) .net and I am sure someone will come up with many more.
They all are simple, fast, exciting, new, wonderful... etc.
I am beginning to think that this is a plot of Microsoft to dilute the only alternative to .net (.net is a clone of java, but of course -SARCASM- much better, faster, newer, more portable etc. -/SARCASM- )
It was Caesar that used the method to conquer an empire, and it did work.
Python has PYPI which is growing. Python also comes with a pile of standard modules. I'll admit something closer to CPAN would be helpful. On the other hand, I haven't had any issues finding modules. Sometimes all you need to do is google or ask on one of the python lists.
Does exist in Python. Guido, last I heard, believed firmly that tabs stops should always be 8 characters apart. Almost every other programmer likes 4 or 3, but some like 2 or even 1. Some have their editors set to use and save tabs, some have their editors set to get rid of all the worthless tab characters. You've got to enforce some kind of standard on a shop of multiple python programmers to make this work at all.
I'm a big fan of Python. I used it almost exclusively before taking my current job. But let's be honest, Python and Java just aren't intended for the same type of applications.
Python's standard library just doesn't have the breadth of Java's. For small apps, the CPython VM is lighter than Sun's JVM, but CPython's VM is lacking several capabilities that I'd consider pretty essential -- chief among them is the ability to return unused memory back to the OS. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock. Java has never suffered from either of these problems. These aren't trivial issues or the result of nitpicking -- they're rather severe limits (which make me seriously question the suitably of Python for enterprise apps, eg. Zope). Of course, once CPython does get decent threading, it's likely that it's GC subsystem will need to be totally rewritten. I apologize if it sounds like I'm beating up on Python. That's not my intent here. I love Python, and I only wish I could stop more people from using Perl :)
In fairness, it does look like the Python community is trying to address some of these problems. I just read a paper presented last week at PyCon 2005 on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS for most object types (except for Number, List and Dictionary). The memory manager still can't defragment its heap, so this isn't a perfect solution. As of a few weeks ago it looks like these patches haven't yet been accepted.
I love python. It's by far my prefered language for development, but it has one major impediment that makes it very hard to take seriously in many rolls in an enterprise: the GIL (global interpreter lock).
You see Python has quite good support for threads, but there are a number of operations in the interpreter that are hacked into being thread safe by providing a global lock on the whole interpreter. One of them is reference counts on objects. So everytime I do an assignment, I have to queue for the GIL. This effectively means that I only really run one thread at a time, even if I have multiple CPUs in the box (or soon, multiple cores).
As more and more applications start shifting to multicpu (or multicore boxes) this problem becomes a much more noticable issue.
Kill the GIL.
My issue with using indentation as a block delimiter is in the time it takes to do it. When programming in Tcl (my language of choice), I just hit tab and the code is indented to where it should be. If I add an open or close curly, the indentation knows where to go next (in order to be the most readable to me). How do Python programmers handle having to indent every line? I assume tab will (generaly) indent to whereever you were last indented to. Do you need to backspace/space mutliple times each time you switch to a new block level?
C may be old-fashioned, but please don't lump C++ in with it. Chances are you haven't even seen modern C++ source code, which in practice has little to do with C source other than that you can link to C libraries easily.
That said, I'm all for programming in higher-order languages (e.g. Python) and I prefer to do so, but some problems are better solved in C++ or even C. It doesn't even have to be about efficiency; things like static type checking can be essential in large programs when it's hard to test all code paths.
There are a lot of things wrong with what you are saying. It looks like while you learned the language, you have a lot of trouble adapting to some of the "paradigms".
Asking for functions to return None instead of raising exceptions on errors ruins a fundamental concept of "focus on what the program should do" which makes exceptions useful. A significant percentage of C code is "if - else" statements dealing with such return codes.
In C or Perl, writing a file is a painful operation, along these lines:
open file for writing()
if open failed {
handle error
} else {
while not finished {
retvalue = write content to file
if retvalue not good {
handle error
}
}
close file
if close failed {
handle error
}
}
Note how inline error checking not only makes the bulk of the code, but also makes it less obvious what the code does. In Python, you'd do something along these lines:
try:
open file for writing
while not finished:
write to file
close file
except open failed or write failed or close failed:
handle error
That is even assuming we want to handle the error and not let it propagate up, which is made possible by the exception mechanism, and would be made difficult if all those functions would return on error.
Last week I realised I needed some way of generating a bunch of stuff on the fly as prep work for a current project.
It had been mentioned in my hearing that Python was acceptable within the constraints for the overall program.
Figuring it was at least worth a look, I spent a day playing with Python basically putting together the things I needed to to do the task. In spite of a couple of disruptions, my code was fully functional and more or less ready for primetime by COB Friday.
I wouldn't use it for the real-time parts of what I'm doing if only because the framework being used is suitable as it stands ( C++/C/FORTRAN ) but for most other things it rocks.
I plan to push for making Python the standard glue language at the office.
That's where i'll desagree with whateverparent who said that high level "so called scripting languages" should only be used for prototyping/testing and should be cast aside for final app:
It's well known that ~10% of an application's codebase consumes ~90% of the application's resource needs (source: my ass), high level modular languages with easy ASM/C/C++ integration such as Python therefore allow you to:
- Develop the whole application in a fraction of the time you'd need to develop C/C++ version
- Using it as a "proof of concept" of the app's viability
- Fully test both application and test-cases (including unit tests
- Identify performances "roadblocks" modules/parts
- Recode these modules in a more efficient language using the already perfect testing tools
You'll use maybe 10% of the "full C/C++ approach" coding time to code the initial java/python/ruby/whatever high-level language you prefer version, 5% or maybe 10% top to recode the performance-critical modules in low-level languages, and you'll get... 99% of the low level version performances for under 20% of the dev time (with less chances of memory leaks and better portability to boot)The stupid part is that most people don't even realise the ease of embedding low level modules into modern high level languages, and therefore use a "all or nothing approach", either full high level or full low...
Learn how to use your tools guys, low level compiled and high level interpreted language do not oppose themselves, they're complementary and both are necessary to get the best out of your dev teams
"The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
The problem is that actually, it hasn't, although it surely should have been a long, long time ago. Alas, the bulk of the software development industry is so driven by marketing hype and buzzwords that it has collectively failed to develop a new language that is a serious choice as a general purpose programming language spanning many problem domains.
A lot of newer languages imitate C++'s approach in terms of design tools, most obviously Java, C# and now Visual basic.Net. However, the beauty is only skin-deep; these languages often lack the solid, underlying framework and reasoned design decisions that have gone into C++, with the result that most of the time they are lucky to be as good, never mind an improvement. The addition of generics to Java several years later is an obvious demonstration of what happens when you go for buzzwords and you meet someone who went for solid design principles.
Many other languages have something valuable to offer developers, but then go and spoil it in some other way, ultimately winding up with something that might fit certain niches, but isn't suitable for major development projects across a wide range of areas. Some common examples come immediately to mind:
Java Pro: emphasises safety, readability, and portability; con: sacrifices low-level control (and with it performance) and only supports a limited number of programming techniques, encouraging over-engineered, component-based designs Perl Pro: quick, flexible, useful for rapid development of useful tools; con: terrible scalability and unfriendly (to both programmers and tools) syntax restrict it almost exclusively to quick-and-dirty projects Haskell Pro: elegant and powerful syntax, serious support for powerful programming tools like higher-order functions; con: overly academic community, and puts purity above pragmatism, making it hard to use in real-world projects where things like UIs are involvedThe list goes on, but the important point is that while each of these has good applications, they all have obvious flaws as well. Java is the closest to a serious general purpose language, but even today most of the serious Java code is restricted to server-side back-ends driving databases or some thinly disguised variant on that theme.
C++, for all its sins, remains a pragmatic, balanced choice for a general purpose language that can be effectively adapted to a diverse range of applications. Is it a perfect language? Of course not. It has gaping flaws in any number of areas. The problem is that no-one has yet produced an alternative that beats it on all of them without significant compensating weaknesses.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I benched the two pieces of code: (note the slashdot ecode tag removes the proper indentation, but this should be obvious in context)
and then using your suggestion:timing these shows the try clause almoist QUADRUPLES the time: the first runs in 0.62 seconds and the latter runs in 2.4 seconds!!!
Now here is the is the point I was making in my original post: if you try this without using the get its almost 6 times faster than using the .get format and 24 times faster than doing it with the try statement!!!!!!!
To show this consider the following example: In this special problem we know ahead of time what the keys will be. In general we would probably not know this if we were say parsing a file. But since we know them its cheap to write a loop to initialize them first. then we dont have use the get() statement or the try. then we can see how much speed we are losing to the get() statement.
this runs in 0.11 seconds. Which is about 24 times slower than using the try.your information about how to replace autointialization appears to be seriously mistaken.
Some drink at the fountain of knowledge. Others just gargle.