Komodo 4.0 First impressions

I upgraded to Komodo 4.0 last night and I'm quite happy.

It imported my current projects flawlessly, picked up all my settings no problemo.

So far it seems faster/smoother, the new project view of files is better, as it highlights files that don't exist so I could easily clean up my project as a number of files had been deleted in the last 3 months. The auto complete is better for python, but as always is hampered/frustrated by the nature of the language (more on this some other day)

Some of the new features look interesting: HTTP Inspector, JavaScript Debugging, VI Emulation and DOM viewer. I still use VI a lot, and as nice as using a graphical editor, every once and a while having VI commands would come in very handy, so hopefully no more editor swapping.

The "Find in files" feature is much improved, they now start giving results back quickly as opposed to the monolithic find all the files first and then search of 3.5.

They've improved the "find all files" bug I and many others reported in 3.5, but there are still problems, bug ID: 45636

5 Comments

  1. Trent says:

    The auto complete is better for python, but as always is hampered/frustrated by the nature of the language (more on this some other day)

    Hi, I'm (mostly) responsible for the Python completion in Komodo. Thanks for the commentary. I'd be interested in what you think of Python's nature hampers completion?

  2. techdetails says:

    Trent,

    The dynamic nature of the languages prevents auto completion in a variety of situations.

    For instance:

    object = GetSomeObject( parm1, …)

    In python and Komodo for that matter you don't know what object will be returned until run time, you might be able to guess, but unless you run the code you just don't know. Therefore you can't use the benefit of auto-completion, unlike a statically typed language. I wasn't being critical of Komodo, but I was being critical of python, but the reality is, python is what it is and that's unlikely to change. Dynamic languages make things hard for tool writers that work directly with the language in my opinion, and python compounds this problem by the syntactical style of tab/spaced blocking for instance.

    A simple test for python is take a moderately complicated function remove all the leading spaces and see if you can put it back together as before, having not seen the original in the first place, this is pretty hard and I would say it's not possible programmatically, unlike Java, C, etc. that have slightly more conventional syntactic block structure.

    BTW, are you responsible for the bug I mentioned above? I was thinking of doing a screen cast to demonstrate the behaviour which may be more effective than my last comment in the bug report.

    As a final disclaimer, I really like Komodo, I think of it as Intellij for Python. I just haven't drank the python koolaide yet.

  3. Trent says:

    You are right, the dynamic nature of all the languages that we work with make autocomplete a challenge. My experience so far with doing autocomplete support for Perl, Python, Ruby, PHP and JavaScript is that they all have their little pecadillos that make it interesting. In subsequent versions of Komodo I hope to start adding support for light static type hinting in your code to help Komodo provide good completion.

    For example, recognize:

        assert isinstance(foo, SomeClass)

    in Python code. We already do a little bit of that by picking up on javadoc-type comment markup for our PHP (phpdoc tags) and JavaScript support.

    Regarding drinking the Python cool-aid. (I'm mostly a Python guy so perhaps biased.) The indentation thing is a redherring. Eventually I bet you'll come the love it. One thing about Python that tends to help over the other dynamic languages is that it generally requires (in some instances) and otherwise encourages explicitness is coding:

        from foo import bar
        bar() # we know where 'bar' comes from

    as opposed to some other languages:

        # Ruby
        require 'foo'
        Bar::bar()  # did Bar come from foo.rb?
        # Perl
        use LWP;
        print $HTTP::Request::VERSION;  # LWP.pm loaded HTTP::Request

    Sure you can be subtle in Python too, but my impression is that typically too much subtleness is discouraged (by both the language and the community) while the other languages often revel in it.

    Regarding the find bugs: Yes, I did the "find in files" improvements. We haven't yet fixed the other one (45636).

    Cheers.

  4. techdetails says:

    I've been doing Python for 2 years now (full time) coming from about 7 years of Java and more than that of C/C++. I didn't want to get into the whole tab thing, since it's been argued about so heavily everywhere else, it's mostly an issue with my brain, I like the symmetry of Java/C/… and Python's asymmetry really grates on my nerves from time to time (mostly when I'm using VI, Komodo makes it much easier to work with) so it's simply a personal quirk of mine.

    Thanks for the great job on search, I just did a file count and we have 25,046 files in 6200 directories for our source tree, the very source tree that drives this site, and it is very fast now compared to 3.5. Mind you it's not all .py files, my source is also mounted via Samba on a Linux box which adds to some of the slowness, plus the fact that symbolic links confuse the hell out of Windows.

  5. Tony says:

    Hmmm, great state. Thanks.

Leave a Reply