Forgot your password?
typodupeerror
Programming IT Technology

Python Moving into the Enterprise 818

Posted by timothy
from the slither dept.
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!"
This discussion has been archived. No new comments can be posted.

Python Moving into the Enterprise

Comments Filter:
  • by Anonymous Coward on Sunday April 03, 2005 @08:59AM (#12125843)
    TOS or TNG?
  • Jython? (Score:4, Interesting)

    by Crono (62230) on Sunday April 03, 2005 @08:59AM (#12125844)
    Aren't some of them using Jython, which is really just Python on top of Java anyway.
    • Re:Jython? (Score:5, Insightful)

      by pogofish (514289) on Sunday April 03, 2005 @09:04AM (#12125864) Homepage
      The Jython language is still (essentially) an older version of Python. Just because it runs in a Java VM and can integrate with Java classes doesn't moot the point about doing enterprise work by "coding in a language that isn't painful."
      • Re:Jython? (Score:5, Informative)

        by hey! (33014) on Sunday April 03, 2005 @10:10AM (#12126095) Homepage Journal
        I don't find Java as a language painful.

        It's the output of Java programmers that turns my stomach.
  • Advantages? (Score:4, Interesting)

    by voss, sometimes... (873034) on Sunday April 03, 2005 @09:02AM (#12125857)
    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?
    • Re:Advantages? (Score:2, Interesting)

      by m50d (797211)
      http://netpub.cstudies.ubc.ca/oleary/images/python _java_comparison.gif [cstudies.ubc.ca] may give you an idea. Quite simply it's easier to program in, and you're more productive using it.
      • Re:Advantages? (Score:3, Insightful)

        by aldoman (670791)
        I agree -- Python is fantastic for quickly building small apps, or even much larger ones.

        The problem arises in Python's web programming support. The documentation is pretty much non-existent and you can soon get module-overload when you are importing more and more modules to do fairly simple stuff in web apps.

        Sometimes I just think while Python is most certainly a far better designed language, PHP/ASP.NET (C#) seems much more 'pratical', and it's definitely much easier to quickly build web apps in.

        Is the
        • Re:Advantages? (Score:4, Informative)

          by BasilBrush (643681) on Sunday April 03, 2005 @09:28AM (#12125932)
          If you haven't already, you want to get hold of a copy of
          Foundations of Python Network Programming [amazon.com].

          My only experience of web progamming in Python is the client end, for web-scraping scripts, and its great for that. The one problem I have is that once in every few hours urllib2 locks up whilst trying to get a page from a particular site.
        • Re:Advantages? (Score:3, Interesting)

          by platypus (18156)
          Really, try Zope [zope.org].
          Yes, it's a little bit of a learning courve, but (and I did all of them for a living) it be beats Java/Tomcat/Struts and PHP hands down in productivity/maintainability once you get a grip on it.

        • Re:Advantages? (Score:5, Informative)

          by afd8856 (700296) on Sunday April 03, 2005 @09:53AM (#12126002) Homepage
          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.
      • Good point, but bad example.
        If you take out comments, which one is more easier to read?

        I have nothing personal against Python, actually I can say that I am a fan of python, but let's use a right tool for a right job.
      • Re:Advantages? (Score:5, Insightful)

        by NeoBeans (591740) on Sunday April 03, 2005 @09:26AM (#12125920) Homepage Journal
        Amsing site, but... it didn't answer the original question. It just shows a comparison of two "Hello World" programs.

        The one thing that Java has going for it are "standard" APIs you can bank on. Is there a standard set of enterprise APIs for Python akin to J2EE?

        And all of this isn't to say that one can't leverage both technologies [bea.com] where appropriate, even in commercial products...

      • Re:Advantages? (Score:3, Insightful)

        by Vengeance (46019)
        Yes, well, if your biggest problems with software development are an inability to deal with brackets or declare variables, you probably shouldn't be coding at all.

        What a silly picture.
    • Re:Advantages? (Score:5, Informative)

      by hey! (33014) on Sunday April 03, 2005 @11:29AM (#12126447) Homepage Journal
      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.
  • Good: (Score:5, Funny)

    by TeleoMan (529859) on Sunday April 03, 2005 @09:03AM (#12125862)
    Maybe it'll eat Archer's stupid little dog.
  • by RicardoStaudt (848723) on Sunday April 03, 2005 @09:04AM (#12125866)
    "Will we finally be able to code for living in a language that's not painful?"

    Dude, programming for the enterprise without the pain is like the Passion of the Christ without the crucifiction... It's Impossible.
    In that case, Perl should fit perfectly.
  • python performance (Score:4, Interesting)

    by khuber (5664) on Sunday April 03, 2005 @09:04AM (#12125867)
    Python is a nice language, but it's excruciatingly slow. It's below Tcl on The Computer Language Shootout [debian.org], which is telling.
    • by Sweetshark (696449) on Sunday April 03, 2005 @09:24AM (#12125915)
      The Computer Language Shootout is pretty useless - often there is a reference implementation in C and the task is to code the *same* algorithm in other language. This ignores the fact that there might be better ways to solve the problem in the other languages. Or in almost all languages. Just take a look at the fibonacci test - it a stupid useage of recursion, if your compiler doesnt optimize out all the duplication. Ok, that would be a nice feature, but it just shows "This language/compiler is good at optimizing bad written code".

      Also you can make the shootout say almost anything, for example if you also calculate the code lines in and weight pidigits with a 4 multiplier, Python comes up as the best of the "serverside languages" (Perl, Python, Java, PHP ..)
    • by The Famous Brett Wat (12688) on Sunday April 03, 2005 @09:31AM (#12125937) Homepage Journal
      I think that Python is supposed to be better in benchmarks not listed on that page, such as "mean time to correctly add a feature to unfamiliar code, written by someone who has since left the company".
    • by arevos (659374) on Sunday April 03, 2005 @09:39AM (#12125960) Homepage
      I've never had any problems with Python's speed. It's fast enough for web applications. It's fast enough to use GUI toolkits. It's even fast enough for simple OpenGL demos [monkeyengines.co.uk] (a shameless plug, I know, but it seemed relevant).

      If you come across a situation where Python is too slow for what you want to do, then Python can work happily enough with libraries programmed in C. If that's still not fast enough, then use a different language. But I suspect that for 95% of all programming tasks, Python is fast enough.
    • Computers are cheap.

      People are expensive.

      Writing in powerful languages like Python makes your people more effective. And most enterprise apps are not CPU limited anyway.
      • by Bob9113 (14996)
        And most enterprise apps are not CPU limited anyway.

        Say what? You must be living in a very different world than I. If it's an enterprise app, then it has a few thousand internal users. Multiply a few seconds by a few thousand people by a few times an hour by a few dollars per hour. Performance matters. Middle of last year my company pulled two people off their primary project to add a feature that saved our primary users two mouse clicks. Those 4,000 users now save 3 seconds, 10 times an hour, 8 hours a d
        • Those 4,000 users now save 3 seconds, 10 times an hour, 8 hours a day. It's like getting an extra 33 employees for free.

          Did a consultant compute that number? [tripod.com]
        • by Bob9113 (14996) on Sunday April 03, 2005 @02:46PM (#12127538) Homepage
          Clearly everyone missed my point, so I'll clarify.

          I was using an example from the real world to point out why 3 seconds matters. In any significant application there will be some processes that are sufficiently complicated that the choice of algorithm or choice of language will lead to a 3 second delta one way or another. There will also be places where adding a UI shortcut will save 3 seconds.

          The real world example talks about UI shortcuts that can save those 3 seconds, and Python makes it easier (according to the common wisdom) to add features. Other languages are more performance centric, and make it easy to save those 3 seconds in operation intensive sections of the code.

          I wasn't arguing that Python is bad because it's not as performant. I was saying that both CPU performance and UI friendliness are important, so choosing between Python, Ruby, C#, Java, C++, C or any other language on the spectrum is a question of weighing values.

          Ferfucksake people, stop trying to be argumentative and start trying to understand what people are saying. We all claim to be so smart, is our only ability with our intelligence to pick nits? Or can we use our intelligence to seek mutual understanding?

          I mean, I can see why the media is turning into a bunch of ranting extremists - they're just a mirror reflecting our own horrible image.

          Feh.
    • by goombah99 (560566) on Sunday April 03, 2005 @11:03AM (#12126324)
      Yes python falls in this weird crack between a scripting language and a high performance programming language. combines the slowness of perl with the inconvnience of structured programming. Its too structured and takes too many steps to be a good scritping language and too slow to be a programming language.

      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++.

      • by zorander (85178) on Sunday April 03, 2005 @01:33PM (#12127123) Homepage Journal
        I agree with a lot of what you are saying, though it doesn't tend to stop me from using python.

        If you want a language that's consistently unsurprising and surprisingly efficient, then try ruby. Performance is not a dream, but that's what compiled languages are for. It lacks most of python's inconsistencies and is really quite pleasant to work with. in ruby there are two sort methods, sort and sort!. One does it in place and one returns a new list. (the ! suffix for mutation and ? suffix for predicates is a gem. I'm pretty sure it was stolen from scheme. It really, really helps make your code clearer)

        I still find python more practical for large projects, though, because of the large library and potential for rapid development. I generally use python (possibly with C underpinnings) for larger apps and ruby (with its perl heritage) for scripting. Blocks are the greates when you're dealing with ssh sessions, opening and closing files/database connections, etc. As for per,l I've generally avoided after a few bad experiences trying to decipher six month old code. I really don't think it has a place when ruby has most of its features and enough of it's syntax along with the slickest object system around short of smalltalk.
  • by The Amazing Fish Boy (863897) on Sunday April 03, 2005 @09:05AM (#12125869) Homepage Journal
    I don't know whether to be happy or afraid.
    • by m50d (797211)
      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.
  • by lxt (724570) on Sunday April 03, 2005 @09:06AM (#12125871) Journal
    ...Monty Python was merging with Enterprise? Now there's a show I'd like to see... :)
  • Toolsets (Score:5, Informative)

    by justanyone (308934) on Sunday April 03, 2005 @09:10AM (#12125878) Homepage Journal
    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
    • Re:Toolsets (Score:3, Insightful)

      by Xrikcus (207545)
      You may not have arguments between programmers with indentation based delimitation. However it only takes one contributer to accidentally use tabs rather than spaces to indent, or vice versa, and the code can actually look fine but suddenly fail to execute correctly as the interpreter becomes unsure what the indentation levels are. Then of course how do you automate a fix? At least with bracketing one can run indent over the codebase to make it all consistent.
    • Re:Toolsets (Score:5, Informative)

      by Ursus Maximus (540370) on Sunday April 03, 2005 @11:13AM (#12126362) Homepage
      Kevin wrote:
      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.

      Actually, Guido von Rossum (the Creator of Python) is working on optional declaration of variables for a future version of Python. Although some Pythonistas are annoyed, it may give folks like you, Kevin, the best of both worlds. There is discussion on comp.lang.python about this from time to time, but it certainly appears as though Guido may take action soon;-))).

      Ron Stephens
      Python Learning Foundation
      http://www.awaretek.com/plf.html [awaretek.com]
  • by paRcat (50146) on Sunday April 03, 2005 @09:17AM (#12125893)
    The first dozen replies are all trolls, so I'll add my experiences for posterity's sake.

    I've been using python for pretty much anything in my company that isn't web based, and things couldn't be better. There's talk about python being slower, which it is, but most libraries that do important things are just C wrappers anyway, so the speed decrease is negligible as python is just holding the logic. Tk is nice enough, I guess, but I tend to use wxPython. Either way, it gives you cross platform GUIs, which is always a nice thing. Using pyexe allows you to even 'compile' scripts into exe files with win32 machines.

    To be absolutely honest though, I can't think of an easier language to learn (I even teach >40 yo women now and then!) or a quicker language to code in. Once you're accustomed to it, the code just flows out, and I've seldom been disappointed by the results. The formatting requirement helps to ensure that your code isn't a disgusting mess that no one can figure out, YMMV.

  • by thammoud (193905) on Sunday April 03, 2005 @09:25AM (#12125919)
    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.
    • by jimicus (737525) on Sunday April 03, 2005 @09:36AM (#12125951)
      Had you done the same test 8 years ago but searched for Java versus C/C++, you'd probably have seen the exact same results.
    • Alot of us never thought PHP could make a Dent in perl , but it did.
      if you had checked for python jobs just 2 years ago i would be amazed if you could find any .312 is a dent although a small one , and yes i do expect it to do what .Net has failed to do this as .NET has no real advantages over Java in the enterprise market , and the dependance on MS OSs is a real disadvantage in a market where Solaris etc still play a sizable part
      (mono is not an option right now).
      Python is able to run on all of these syst
  • by bblazer (757395) * on Sunday April 03, 2005 @09:26AM (#12125921) Homepage Journal
    While I agree wholeheartedly that python is a wonderful language to code in, I think that it lacks a sting GUI system. Yes wxPython is cross-platform, but without getting overly detailed here, it definately lacks the detail and robustness of SWT or even Swing. Until wxPython can stand up to those, I think the movement to it for more broad based use with be a bit slow. As far as apeed goes, who cares? We are not programming for 286 machines anymore!
    • by costas (38724) on Sunday April 03, 2005 @10:42AM (#12126243) Homepage
      Agreed on wxPy, but you do know that SWT and Swing are scriptable from python thru Jython (or the Python-Java bridge project, forget the name right now)? IIRC there has also been an effort to wrap the native SWT widgets in python w/o going thru Java, which would be awesome.

      But overall, I completely agree: the std python distro needs to standardize on wx, get rid of Tk and at least incorporate the win32all distribution in the win32 version (it just too nice to leave out).

      My biggest peeve as a long-time pythonista (the newsbot in my sig is 25k+ LOC of pure Python) is the standard library: I can live w/o a CPAN-like repository (although that would rock), but for a language that used to boast that it comes "with batteries included" the std lib has gone downhill in the last few versions: too many overlapping or competing modules (why, why do we need httplib, httplib2 and urllib?? or getopt and optparse? and what are the differences between them?) and not enough attention into polishing the library into the fantastic toolkit that was around the 1.5 or early 2.1 series.

      Someone, probably the BDFL, needs to stand up and take obsolete modules *out* of the standard library, so that the better ones can be improved even more, instead of having various tweaks and improvements going into overlapping modules. That's the point of having a *standard* library after all...

      I'd rather have a good std lib than function decorators and other exotic language constructs...
      • by idlake (850372) on Sunday April 03, 2005 @01:30PM (#12127098)
        The profusion of library modules with overlapping functionality is a real concern. The confusion over a standard window system (wxPython, Tk, ...) is actually just another example of that.

        The sys/os split, logical as it may seem to the experienced Python programmer, also confuses Python newbies, as does the fact that string needs to be imported and that re is yet another separate module.

        I think Python would do well with a major library cleanup, removing rarely used and duplicated functionality, and improving the quality of the library code that is there.

        Furthermore, I think it would help for common string, I/O, OS, and regular expression functionality to be importable either via a single import statement (without name conflicts), or to be simply present in the default namespace.
      • I wouldn't recommend taking modules out of the standard library, but merely marking them as deprecated and possibly removing their documentation from the new versions of python. That way, we won't break old programs, but we could prevent people from starting to use them.
  • by blackhedd (412389) on Sunday April 03, 2005 @09:50AM (#12125987)
    1) The twenty minute problem
    Many programmers, including top ones like Eric Raymond http://www.linuxjournal.com/article/3882 [linuxjournal.com], are so put off by Python's use of whitespace as a block delimiter that they swear never to touch the language. In my case, this lasted for two years. You need to spend twenty minutes learning the language, after which the whitespace stops being a problem and starts looking like one of the many great ideas in the language. The challenge is getting people past their initial disgust enough to try it.
    2) Misperceptions about typing
    Many people think agile languages like Python and Ruby are not strongly typed and therefore present scalability problems and can't be used reliably by large teams. But Python and Ruby are strongly typed (unlike Perl)- you don't get type conversions you don't ask for. The real distinction is that the agile languages are dynamically typed rather than statically typed like Java/C++. To truly grasp the notions of "duck-typing" and lazy evaluation of types is as much a stretch as it was to "get" objects for those of us who were around 15 years ago- it's a basic change in how you think. You'll know when you're there, because you'll see in a flash that Java's static type declarations are not only redundant and painful, but they are also in themselves a key source of brittleness in large programs over time.
    3) The youngsters' problem
    This is probably the biggest barrier: university CS departments have become nothing but Java training courses. In trying to better prepare grads for actual careers, they have added a lot of basic business teaching, which is good. But they no longer bother to give students a real understanding of actual computer science, sticking instead to a cookbook approach using Java. So young people arrive in enterprise IT shops knowing nothing but Java and thinking they know everything, so they are not open to anything requiring a different intellectual approach.
    • 2) Misperceptions about typing
      Many people think agile languages like Python and Ruby are not strongly typed and therefore present scalability problems and can't be used reliably by large teams. But Python and Ruby are strongly typed (unlike Perl)- you don't get type conversions you don't ask for. The real distinction is that the agile languages are dynamically typed rather than statically typed like Java/C++. To truly grasp the notions of "duck-typing" and lazy evaluation of types is as much a stretch as it
      • The value of strictly typed languages is in compile time type checking. It's good to have languages that are not type checked, and it's good to have languages that are.

        You appear to be confusing static vs dynamic type checking with strong vs weak type checking.

        Static type checking occurs at compile time, whether or not the language is strongly or weakly typed. Dynamic type checking occurs at run time, regardless of whether or not the language is strongly or weakly typed.

        Disagreement still exists about w

  • by codepunk (167897) on Sunday April 03, 2005 @09:59AM (#12126036)
    Soon as the qt windows free version starts shipping I think we will see alot of renewed development of gui stuff in python. Currently wxwindows exists but it is a little funky to program in if you ask me. A good industrial strength redily available qt is going to move alot of things.

    It is a great language we use it for everything, web services, linux / win integration, nt services, automation etc.
  • by Nelson (1275) on Sunday April 03, 2005 @10:08AM (#12126087)
    I think that the database connectivity could be standardized a little more, perhaps with an ORM. It's not bad now but as a postgresql user, I'm not really happy, the "best" connector needs some janked up mx library, there are a few dead connectors. It seems like python.org could take this over or some kind of packager could.


    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.

  • by OblongPlatypus (233746) on Sunday April 03, 2005 @10:09AM (#12126088)
    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. I guess it could be argued that at least it's not a bad thing, in which case it boils down to a matter of personal taste, but everyone seems to be saying it makes reading unfamiliar Python code so much easier.

    Well, with any other language, if I get a piece of unfamiliar code and have problems reading it due to weird indentation, I just run it through Emacs' indent-region. Can anyone explain to me why this is not just as viable as mandating the indentation policy by embedding it in the language's syntax?
    • I find it reduces clutter in my code. For instance:

      if (x == 2) {
      printf("Blah blah");
      }

      As opposed to:

      if x == 2:
      print "Blah blah"

      The question is not so much why one should have a language with whitespace significance, but why one should not. Since the vast majority of well-written programs use whitespacing in this manner already, it makes some sense to do away with braces and semi-colons when they're not really needed.

    • by krumms (613921) on Sunday April 03, 2005 @11:13AM (#12126358) Journal
      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.
      • No, actually... it doesn't. I've seen python code that uses *only* the indentation rule - there was no other extra whitespace or comments anywhere. Not between functions, not between class declarations, not between loops, nowhere. Not only was this code unreadable, but it proved to me that you can't make someone a good programmer by enforcing semantic rules in the language. While we're at it, why not build a language that enforces javadoc-style comments at a rate of 40% or more to code? How about one t
  • by linuxbaby (124641) * on Sunday April 03, 2005 @10:31AM (#12126190)
    This article confirms it...
    • Ruby is the new Python
    • Python is the new Java
    • Java is the new COBOL

    :-)
    (found many places online...)

  • by CoderDevo (30602) <coderdevo@hotmail.com> on Sunday April 03, 2005 @11:55AM (#12126579) Homepage

    Dr. McCoy - - Captain, I wish to register a complaint... Hello? Miss?
    Capt. Kirk - - What do you mean, miss?
    Dr. McCoy - - Sorry Captain, I have a cold. I wish to make a complaint.
    Capt. Kirk - - Not now Bones, we're closing for launch.
    Dr. McCoy - - Never mind that, I wish to make a complaint about this tribble that I purchased not half an hour ago from this very bridge.
    Capt. Kirk - - Oh yes, the Bajoran Blue. What's wrong with it?
    Dr. McCoy - - I'll tell you what's wrong with it. It's dead, Jim, that's what wrong with it.
  • by Cajal (154122) on Sunday April 03, 2005 @12:12PM (#12126672)

    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 [evanjones.ca]. And for many tasks, CPython is still effectively single-threaded due to its global interpreter lock [python.org]. 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 [python.org] on CPython's memory management. The author is developing some patches to let CPython return unused memory to the OS [python.org] 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 [python.org] it looks like these patches haven't yet been accepted.

    • I've always be told that in C, free() doesn't (usually) return the memory to the operating system.
      The memory is only available to other programs after the program exits.

      As a result of this, most daemons will re-exec themselves to free up memory for the rest of the system.

      At least, that's what I've always heard. Maybe newer versions of the linux kernel are much smarter...
  • by hagbard5235 (152810) on Sunday April 03, 2005 @12:21PM (#12126726)
    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.
  • by quantum bit (225091) on Sunday April 03, 2005 @12:47PM (#12126867) Journal
    I really like Python. It's an incredibly powerful language -- what other languages give you the power to redefine what "is" means? For example, you can override the '.' operator (and getattr) and create whole sets of virtual objects that don't really exist. Things like object proxies for RPC or external resources like Zope become possible.

    Its main two faults in my mind are:

    1. Speed (but this is being worked on, see the Parrot JIT compiler)
    2. Memory usage. wxPython especially is an excellent toolkit but a memory HOG.

    As far as Java goes, I don't particularly like Java all that much, but one area where it has a definite advantage over Python at the moment is libraries. Not just the standard library, but what add-on libraries are available. Python has a lot, but Java has pretty much everything and the kitchen sink.

    For example, I recently worked on a project that needed to display and manipulate SVG graphics. The two requirements are that it be cross-platform, and be done quickly (in just a couple weeks). I originally wanted to use Python but was unable to find a cross-platform SVG rendering library for Python. I came across the Apache Batik [apache.org] toolkit for Java and found that it was exactly what I needed.

    Batik is pretty sweet -- you get a swing component that you can plop into an app in about 10 lines of code and boom -- you have one of the most compliant SVG renderers that I've seen to date. Plus it even gives you a DOM interface that will update the graphical view in real-time. As much as I dislike Java in general (even more bloated than Python :), the third-party libraries certainly made this project a breeze.

It's time to boot, do your boot ROMs know where your disk controllers are?

Working...