4 ms·

Am I the only one who think Light Table won't work for Python? I mean, look at all those getattr() setattr() stuff. LightTable doesn't stand a chance. Even dea

• gaius 14y ago
  It's certainly an open question, if what you gain from dynamic languages, is more or less than what you lose from having no static analysis. I got into OCaml initially because I wanted a statically-typed, type-inferred Python...
• vibrunazo 14y ago
  Has there been any official answer to this? I've been trying to hold to Hanlon's Razor, but it's been hard :S
• gecko 14y ago
  The first 80% of getting that working is surprisingly easy; the last 80% is surprisingly hard. I programmed in Smalltalk for years. Smalltalk has similar issues: dynamic typing, dynamic method generation/handling via #doesNotUnderstand:, and so on. Yet quite a few Smalltalk environments have accurate and useful autocompletion, on-the-fly documentation, and more. How? You get three freebies that end up covering most situations: 1. Globals (which includes classes) are trivial to detect and centrally stored, making it easy to pick up when a class is used in source code. So we've now got autocomplete for all static methods and class documentation. 2. Most of the time, a variable is only actually assigned to once--or, worst case, from one location. After that, it's merely manipulated. See what class is getting instantiated there (see above), and you've got a great guess on what type you're dealing with. (And, sadly, it's a guess; "Foo new" *probably* gives you a new Foo, but it doesn't have to.) 3. Most methods *either* only get implemented once, *or* specialize a method whose parent calls "self subclassResponsibility". So either you've only got a single place to look-up, or you can hedge your bets and show documentation for the version of the method that calls "self subclassResponsibility" (i.e., the abstract one) and figure it's applicable to the concrete instance. These three rules (which can obviously be combined) end up working a surprisingly large amount of the time, and they're not ridiculous to implement. Granted, Python has a harder time here in some cases (e.g., you have to parse all accessible Python modules to build up a constructor list, and you'll likely have higher method collisions in Python than in Smalltalk due to the lack of keyword-based messaging), but these techniques will go a long way to getting you where you need to go. Past that? Things get really hard. Because Smalltalk's development and execution cycle is blurry, you can actually go further than the above rules by checking what types variables are in instantiated classes and methods, and turning your source-based guesses into statistics-based ones. There's no equivalent mechanism in Python. You could probably do something with an idempotent test suite and some hooks into the Python VM, but the problem gets much more complicated. Doable? Yes. Likely to come from Light Table? I'm not honestly sure, but I am sure that they'd have to be willing to get pretty dirty with Python to get there.
• tonyarkles 14y ago
  I haven't used PyCharm a whole lot, but a friend of mine raves about it constantly. They've apparently added heuristics for Django (and other frameworks), so that it can make assumptions about the layout and behaviour of the code. See a render() call? You can click on the path and have it open the template correctly, even though that normally has to go through the TEMPLATE_LOADERS machinery. You can get a long way by being slightly smart about things, instead of just relying on a naive static analysis. (I mean "naive" in the sense of ... well, not in the insulting sense :P)
  • gaius 14y ago
    We're all computer scientists here, but you're right, using terms like "naive" and "trivial" is often open to misunderstanding.