🌐 Mailman 3 December 2008 - Python-list - python.org

Re: Emacs vs. Eclipse vs. Vim
by Paul Rudin Dec. 1, 2008

Dec. 1, 2008

Clay Hobbs <clay(a)lakeserv.net> writes: > It has key commands with key modifiers to do simple tasks (such as > moving the cursor to the left). Err - you move the cursor to the left by pressing the left arrow key (as you do with virtually every other editor), unless you've made some strange key bind customisations.

1 0

Re: incorrect line reported in traceback
by John Machin Dec. 1, 2008

Dec. 1, 2008

On Dec 1, 4:47 pm, "Patrick Stinson" <patrickstinson.li...(a)gmail.com> wrote: > Is there any reason why the last item in the traceback is one frame > below the top of the stack? It would be great to show the real line in > my editor... Maybe your anonymous [HINT!] editor is confused. Do you get the same problem when you run your script at the shell prompt?

2 1

incorrect line reported in traceback
by Patrick Stinson Dec. 1, 2008

Dec. 1, 2008

Is there any reason why the last item in the traceback is one frame below the top of the stack? It would be great to show the real line in my editor...

1 0

Re: Confused about class relationships
by Carl Banks Dec. 1, 2008

Dec. 1, 2008

On Nov 26, 11:20 pm, John O'Hagan <resea...(a)johnohagan.com> wrote: > Apologies if this is a D.Q., I'm still learning to use classes, and this > little problem has proved too specific to find in the tutorials. > > I have two classes with a relationship that I find confusing. > > One is called Engine, and it has a method (bar_builder) which generates > instances of the other class, called Bar (not as in Foo but as in bar of > music; inherits from list). > > Also, Bar takes the generating instance of Engine as an argument to its > __init__ method: > > class Bar(list): > > def __init__(self, a_bar, args, engine): > list.__init__ (self, a_bar) > self[:] = a_bar > self.args = args > self.engine = engine > #more instance attributes... > > #methods... > > class Engine: > > def __init__(self, args): > self.args = args > #more instance attributes... > > def bar_builder(self): > #body of method generates lists... > yield Bar([generated_list], args, self) > > #more methods... > > #(other stuff...) > > def main(args): > > engine = Engine(args) > bars = engine.bar_builder() > for a_bar in bars: > #play the music!... > > While this works (to my surprise!) and solves the problem which motivated it > (i.e. Engine instances need to pass some attributes to Bar instances ), it > seems too convoluted. Should one class inherit the other? No. (I wonder if you meant, "Should one class reference the other?", as in, "Should Engines only reference bars or Bars only reference engines, but not both?", in which case the answer is a non-commital, "It depends.") Inheritance is not something you do because object A wants to access the attributes/properties/etc. of B. Actually, that is something that happens pretty often and when it does, there's a couple things you should think about: 1. How you want A to access the attributes of B. Should you just let A poke around in B, or should you define methods of B for A to call, and those methods access the internals of B? It's a judgment call most of the time. 2. Whether some behavior of B ought to be defined as part of A's class instead, or vice versa. There is sometimes ambiguity over what class a method that uses the attributes of two different objects should belong to. Inheritance isn't something you need to think about here. Inheritance is something you consider when you have two objects, A and B, that should act very similar or the same in certain situations. Engines and Bars don't seem to share any behavior at all. Contrast this to Bars and lists, which do share behavior. x[1] does pretty much the same thing whether x is a Bar or a list, I'd imagine, so there's reason for an inheritance relationship there. > If so, which way > around? Or is it fine as is? One thing you might want to consider is whether Engine instance could be simply passed into the Bar's play method (or whatever other method accesses the Engine attributes), and whether the Engine needs to be involved in generating bars at all. For instance: class Bar(list): def __init__(self, a_bar, args): list.__init__(self, a_bar) self[:] = a_bar self.args = args # etc. def play(self, engine): use(engine.time_signature).somehow() # instead of use(self.engine.time_signature).somehow() def bar_builder(self,args): # plain function, not part of Engine class # or perhaps a method of some other class yield Bar([generated_list],args) def main(): engine = Engine(args) bars = bar_builder(self,args) for a_bar in bars: a_bar.play(engine) One benefit of doing it this way is that you've freed Bars and Engines from each other. Conceivably you could create a second engine object (maybe of a different type altogether), and play the very same Bar objects with that engine instead. > I'm hoping this is a common trap I've fallen into; I just haven't been able to > get my head around it. (I'm a musician...) Well I think it looks pretty good for a musician newbie. There's a few organizational decisions I'd make differently, but overall it's clean and readable and not too complicated how you did it. At least not what you've showed us. :) Carl Banks

2 1

Beautiful soup tag attributes - Dictionary?
by killsto Dec. 1, 2008

Dec. 1, 2008

The documentation says I can find attributes of tags by using it as a dictionary. Ex: product = p.findAll('dd') print product['id'] However, when I try that python thinks I am slicing it. When I print product, it works but is a list. I am pretty sure I have the latest version. Any ideas? Reference: http://www.crummy.com/software/BeautifulSoup/documentation.html#The%20attri…

2 1

how to find help/doc files ?
by Stef Mientki Dec. 1, 2008

Dec. 1, 2008

hello, For an IDE, I want to find the installed help files, either in the form of chm or html files. I'm specially interested in the files for: - python - wxpython - vpython but I fact I want link to all installed docs. Is there a general way to find (by code) these docs ? If not, are there standard ways to find the docs for the above programs, or is it pure random where these files are located ? thanks, Stef Mientki

2 1

Re: end of print = lower productivity ?
by Tim Roberts Dec. 1, 2008

Dec. 1, 2008

Lie Ryan <lie.1296(a)gmail.com> wrote: >On Sat, 2008-11-29 at 17:51 -0600, Tim Chase wrote: >> >> It's not so much "ridiculous" as a failure of your editor to >> >> assist you. In Vim (my editor-of-choice), I'd do something >> >> like >> > >> > seriously, I don't think anyone in Windows uses vim >> >> Are you just guessing, or do you have any sort of facts to >> back this up? > >I know vim is available in windows, but I know nobody but those that >comes from unix-like world that use vim instead of Notepad, Notepad2, >Notepad++, NoteTab, Programmer's Notepad, and multitude other Windows >text editors/Notepad replacement. You are falling into the very common trap of believing that everyone must be exactly like yourself. You are wrong. I don't claim that vim is the most popular Windows editor (I have to believe that Visual Studio is), but the vim community in Windows is strong, active, and well-populated. I suspect this is especially true in the Python world. Many Python devotees spend time in multiple operating systems, where vim and emacs proficiency is essential. -- Tim Roberts, timr(a)probo.com Providenza & Boekelheide, Inc.

1 0

Do more imported objects affect performance
by Filip Gruszczyński Dec. 1, 2008

Dec. 1, 2008

I have following question: if I use from module import * instead from module import Class am I affecting performance of my program? I believe, that all those names must be stored somewhere, when they are imported and then browsed when one of them is called. So am I putting a lot of "garbage" to this storage and make those searches longer? -- Filip Gruszczyński

2 1

Re: Project structure - Best practices
by Aaron Watters Dec. 1, 2008

Dec. 1, 2008

On Nov 30, 11:55 am, "Filip Gruszczyński" <grusz...(a)gmail.com> wrote: > >http://jcalderone.livejournal.com/39794.html > > That's exactly what I have read before posting here ;-) > > -- > Filip Gruszczyński I too would like to see a meatier discussion of best practices for python packagizing. I particularly object to jcalderone's suggestion that all tests should be within the package. Often my test cases are 100 times the size of the code, if you include sample data -- it doesn't make sense to install it, I think. Lately I tend to have something like root/ setup.py README.txt packagename/ main source modules submodules... test/ test code and submodules doc/ scripts/ testdata/ demos/ etcetera... I have no real idea if this is a good way to do it, but it works for me in isolation. I'm completely confused about any implications related to integrated system testing or "easyinstall"... Wise, pragmatic advice would be appreciated. (But if we could avoid the "buzzillion directories" approach prevalent in the java alternative universe, that would be nice.) -- Aaron Watters === Now we see the violence inherent in the system! Help! Help! I'm being repressed!

2 1