2 ms·

The one thing that I have trouble with in Python projects is that it can be very difficult to figure out where the actual object is from that is being imported.

The one thing that I have trouble with in Python projects is that it can be very difficult to figure out where the actual object is from that is being imported. from somedir.somefile import objectX Then when you go to somedir.somefile you find out objectX is nowhere to be found only to figure out later that it is dynamically created and added to that namespace and it can be imported in the file you've been reading because some init function was already called by the module "foo". There are quite a few codebases where I have been hunting for the superclass for example so that I could see if it offered functionality I wanted or how it was structured so I could find out where some function was defined and what EXACTLY it did due to no documentation and it took me a while. I love Python, don't get me wrong. It is by far one of my favourite programming languages, but sometimes it can be very non-obvious where something is coming from and how it is getting there. This may be more of an issue on a project to project basis, but it is an extra complexity that I have found can be rather annoying.

lloeki 14y ago
if an object has not been excessively tampered with, the objects's __module__ attribute will give you where it was created. The inspect module doc page is of great help: http://docs.python.org/library/inspect.html http://docs.python.org/library/inspect.html
revscat 14y ago
I have come to the exact same conclusion about Ruby. Finding the source of given behavior is where I tend to get the most annoyed. This is doubly so for any library which uses method_missing? or other bits of Ruby-dynamism. Yes, it can (and does) lead to terser, elegant code. But it also makes it challenging to analyze root causes, and I have become less enamored of this style as I have had to deal with it over the past few years. In this respect method_missing? is analogous to (over)using C's preprocessors. It seemed like a good idea at the time, but...
- wycats 14y ago
  This isn't directly related to your complaint, but the source_location method in Ruby 1.9 is very useful: > method(:gem).source_location => ["/Users/wycats/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems.rb", 1228]

lloeki 14y ago

if an object has not been excessively tampered with, the objects's __module__ attribute will give you where it was created. The inspect module doc page is of great help: http://docs.python.org/library/inspect.html http://docs.python.org/library/inspect.html

revscat 14y ago

I have come to the exact same conclusion about Ruby. Finding the source of given behavior is where I tend to get the most annoyed. This is doubly so for any library which uses method_missing? or other bits of Ruby-dynamism. Yes, it can (and does) lead to terser, elegant code. But it also makes it challenging to analyze root causes, and I have become less enamored of this style as I have had to deal with it over the past few years. In this respect method_missing? is analogous to (over)using C's preprocessors. It seemed like a good idea at the time, but...

wycats 14y ago
This isn't directly related to your complaint, but the source_location method in Ruby 1.9 is very useful: > method(:gem).source_location => ["/Users/wycats/.rvm/rubies/ruby-1.9.3-p194/lib/ruby/site_ruby/1.9.1/rubygems.rb", 1228]