Re: preemptive OOP?
* Kent Johnson wrote (on 10/4/2006 10:04 AM): > Mark Elston wrote: >> ... >> Without this prior planning, any expansion (not to mention bug fixing) >> becomes more difficult and makes the resulting code more brittle. While >> not all planning for the future requires OO, this is one mechanism that >> can be employed effectively *because* it is generally well understood >> and can be readily grasped *if* it is planned and documented well. > > Unfortunately prior planning is an attempt to predict the future. > Correctly planning for future requirements is difficult. It is possible > to expand code without making it brittle. > Hmmm I work in an environment where we plan our 'feature' implementation several revisions in the future. We know where we are going because we have a backlog of end user requests for new features and a limited pool of people to implement them. Knowing what will have to change in the future makes this kind of planning *much* simpler. However, I still find it a lot easier to plan for change even without explicit requests than you seem to indicate. I have worked in the field for over 10 years now and I have a pretty good idea of the kinds of things our users will need. I also have a pretty good idea of the kinds of things we can introduce that users will find useful. Planning for the introduction of these things is pretty useful when we have short turn-around time between revisions and have to implement any number of new features during these iterations. And adding new features and handling new requests in a well thought out manner helps us to keep the system from being brittle. BTW, the kind of SW we develop is for large pieces of test equipment used in semiconductor test. This SW covers the range from embedded and driver level supporting custom hardware to end-user applications. There is simply no way we could survive if we tried to develop software in any kind of an ad hoc manner. > Robert Martin has a great rule of thumb - first, do the simplest thing > that meets the current requirements. When the requirements change, > change the code so it will accommodate future changes of the same type. > Rather than try to anticipate all future changes, make the code easy to > change. > In our case the requirements don't really change. They do get augmented, however. That is, the users will want to continue to do the things they already can - in pretty much the same ways. However, they will also want to do additional things. Robert's rule of thumb is applied here as well. We may have a pretty good idea of where we are going, but we can get by for now implementing a minimal subset. However, if we don't anticipate where we are going to be in the next revision or two it is very likely to entail some substantial rewrite of existing code when we get there. That results in an unacceptable cost of development - both in terms of $$ and time. Not only is the code obsoleted, but so are all the components that depend on the rewritten code and all of the tests (unit and integration) for all the affected components. >> >> There is certainly a *lot* of 'Gratuitous OOP' (GOOP?) out there. This >> isn't a good thing. However, that doesn't mean that the use of OOP in >> any given project is bad. It may be inappropriate. > > In my experience a lot of GOOP results exactly from trying to anticipate > future requirements, thus introducing unneeded interfaces, factories, etc. While we do our best to avoid this, it *does* sometimes happen. However, it is not as much of a problem as the reverse. If an interface is developed that turns out not to be very useful, we can always remove it with very little cost. If we have to *replace* or substantially modify an existing mechanism to support a new feature the ripple effect can cripple our schedule for several release iterations. OTOH, your point is a good one: If we really didn't know where we wanted to be in the future then making a wild guess and heading off in some random direction isn't likely to be very beneficial either. In fact it is likely to be more costly in the long run. That strikes me as "Crap Shoot Development" (a relative of POOP? :) ). Mark -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan of C -- http://mail.python.org/mailman/listinfo/python-list
Re: preemptive OOP?
* John Salerno wrote (on 10/4/2006 10:18 AM): > Kent Johnson wrote: > >>> There is certainly a *lot* of 'Gratuitous OOP' (GOOP?) out there. >> >> In my experience a lot of GOOP results > > LOL. Good thing we didn't go with the acronym from my phrase "preemptive > OOP" ;) Oops. I couldn't resist. See my previous post. Mark -- "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." -- Brian Kernighan of C -- http://mail.python.org/mailman/listinfo/python-list
Re: Adding Worksheets to an Excel Workbook
I expect this doesn't help him much. I get the impression he is looking more for a recipe. Just doing a Google search of python + excel I got the following which make some good starting points: http://www.markcarter.me.uk/computing/python/excel.html http://mail.python.org/pipermail/python-list/2003-September/183367.html http://mathieu.fenniak.net/plotting-in-excel-through-pythoncom/ There are lots of others. Mark * John Machin wrote (on 10/10/2006 2:59 PM): > [EMAIL PROTECTED] wrote: >> All >> >> I'm a Python newbie, and I'm just getting to the wonders of COM >> programming. I am trying to programmatically do the following: >> >> 1. Activate Excel >> 2. Add a Workbook >> 3. Add a Worksheet >> 4. Populate the new Worksheet >> 5. Repeat steps 3,4 while there is data. >> >> How do you add a Worksheet to a Workbook? > > To find out how to do things, you can: > > (1) use the VBA help in Excel. > > You would find (eventually): > """ > Add method as it applies to the Sheets and Worksheets objects. > > Creates a new worksheet, chart, or macro sheet. The new worksheet > becomes the active sheet. > > expression.Add(Before, After, Count, Type) > expressionRequired. An expression that returns one of the above > objects. > > Before Optional Variant. An object that specifies the sheet before > which the new sheet is added. > > After Optional Variant. An object that specifies the sheet after > which the new sheet is added. > > Count Optional Variant. The number of sheets to be added. The default > value is one. > > Type Optional Variant. Specifies the sheet type. Can be one of the > following XlSheetType constants: xlWorksheet, xlChart, > xlExcel4MacroSheet, or xlExcel4IntlMacroSheet. If you are inserting a > sheet based on an existing template, specify the path to the template. > The default value is xlWorksheet. > > Remarks > If Before and After are both omitted, the new sheet is inserted before > the active sheet. > """ > so, > your_handle.Worksheets.Add() > looks like what you need. > > (2) Again in Excel, use the "record a macro" facility: turn on > recording, do your thing, stop recording, inspect the generated macro. > > In this case, this gave > Sheets.Add > which you translate to > your_handle.Sheets.Add() > > What's the difference between Sheets and Worksheets? I dunno. Try both. > Look in the Excel VBA help. > > HTH, > John > -- http://mail.python.org/mailman/listinfo/python-list
Re: How to execute a linux command by python?
* [EMAIL PROTECTED] wrote (on 10/18/2006 11:32 AM): > Fredrik Lundh wrote: >> haishan chang wrote: >> >>> How to execute a linux command by python? >>> for example: execute "ls" or "useradd oracle" >>> Who can help me? >> start here: >> >> http://www.python.org/doc/lib/ >> >> > > After reading the matl. pointed to by the many links listed here, > you can try pexpect. Provided for more control and interactivity. > More at: http://pexpect.sourceforge.net/ > > /venkat > BTW, is there a version of pexpect that works with Windows? This package requires pty and termios which isn't supported on Windows. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Komodo
* SpreadTooThin wrote (on 10/19/2006 8:47 AM): > Why is it that (On MAC OS X) in Komodo 3.5 Professional, if I try to > find something in my script, > I am unable to change the text it is searching for? > Perhaps Emacs might work better ... :) Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: enumerate improvement proposal
* James Stroud wrote (on 10/30/2006 4:39 PM): > Steve Holden wrote: >> How could you end up marrying someone who counts from one and not >> zero? ;-) > > She's the only other person I've ever met who used vi key binding at the > command line. > > James > > Well, there's your problem. You need to C-x C-f a new mate. :) Mark (Emacs rules) -- http://mail.python.org/mailman/listinfo/python-list
Re: Writing to Registry
Note: this is untested (since I don't like screwing around in the registry...) Have you tried using REG_DWORD? Mark * Samantha wrote (on 11/16/2006 3:48 PM): > I am working with this recipes: > http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/66011 > > The problem I am having is setting a hex value. > This line --- SetValueEx(aKey,"MyNewKey",0, REG_SZ, > r"c:\winnt\explorer.exe") > I want something Like -- SetValueEx(aKey,"MyNewSize",0, REG_SZ, 120 or > some value) > Help would be appreciated. > S > > -- http://mail.python.org/mailman/listinfo/python-list
Re: preemptive OOP?
* Kent Johnson wrote (on 9/30/2006 2:04 PM): > John Salerno wrote: >> So my question in general is, is it a good idea to default to an OOP >> design like my second example when you aren't even sure you will need >> it? I know it won't hurt, and is probably smart to do sometimes, but >> maybe it also just adds unnecessary code to the program. > > In general, no. I'm a strong believer in You Aren't Going to Need It > (YAGNI): > http://c2.com/xp/YouArentGonnaNeedIt.html > > because it *does* hurt > - you have to write the code in the first place > - every time you see a reference to MyNotebook you have to remind > yourself that it's just a wx.Notebook > - anyone else looking at the code has to figure out that MyNotebook is > just wx.Notebook, and then wonder if they are missing something subtle > because you must have had a reason to create a new class... > > and so on...Putting in extra complexity because you think you will need > it later leads to code bloat. It's usually a bad idea. > > Possible exceptions are > - If you are really, really, really sure you are going to need it > really, really soon and it would be much, much easier to add it now then > after the next three features go in, then you might consider adding it > now. But are you really that good at predicting the future? > - When you are working in a domain that you are very familiar with and > the last six times you did this job, you needed this code, and you have > no reason to think this time is any different. > > You struck a nerve here, I have seen so clearly at work the difference > between projects that practice YAGNI and those that are designed to meet > any possible contingency. It's the difference between running with > running shoes on or wet, muddy boots. > > Kent I have only caught the tail of this thread so far so I may have missed some important info. However, Kent's response is, I think, a bit of an oversimplification. The answer to the original question, as quoted above, is ... it depends. On several things, actually. If this is a 'one-shot' program or simple library to accomplish a limited goal then the added complexity of OO is probably overkill. Many scripts fall into this category. You can go to a lot of trouble to generate an OO solution to a simple problem and not get much payoff for your effort. Simple problems are often solved best with simple solutions. However, when an application (or library) is designed to provide a more 'general purpose' solution to one or more problems and is likely to have a lifetime beyond the 'short term' (whatever that may mean to you), then OO can start to pay off. In these kinds of applications you see the need for future maintenance and a likely need to expand on the existing solution to add new features or cover new ground. This is made easier when the mechanism for this expansion is planned for in advance. Without this prior planning, any expansion (not to mention bug fixing) becomes more difficult and makes the resulting code more brittle. While not all planning for the future requires OO, this is one mechanism that can be employed effectively *because* it is generally well understood and can be readily grasped *if* it is planned and documented well. There is certainly a *lot* of 'Gratuitous OOP' (GOOP?) out there. This isn't a good thing. However, that doesn't mean that the use of OOP in any given project is bad. It may be inappropriate. OO is a simply a way of dealing with complexity in SW development. If a problem is complex then the solution will have to deal with that complexity. If OO can be used to make a complex solution less complex then it is appropriate. If the use of OO makes a simple solution *more* complex then it is being used inappropriately. It is not only necessary to have the correct tools for the job but, also, to be skilled in their use. Part of the skill of a SW developer is in picking the correct tool for the job - and then using it correctly. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: What is proper way to require a method to be overridden?
* Paddy wrote (on 1/4/2007 10:20 PM): > belinda thom wrote: > >> On Jan 4, 2007, at 9:28 PM, Carl Banks wrote: >> >>> jeremito wrote: I am writing a class that is intended to be subclassed. What is the proper way to indicate that a sub class must override a method? >>> You can't (easily). >>> >>> If your subclass doesn't override a method, then you'll get a big fat >>> AttributeError when someone tries to call it. But this doesn't stop >>> someone from defining a subclass that fails to override the method. >>> Only when it's called will the error show up. You can, as others have >>> noted, define a method that raises NotImplementedError. But this >>> still >>> doesn't stop someone from defining a subclass that fails to override >>> the method. The error still only occurs when the method is called. >>> >>> There are some advantages to using NotImplementedError: >>> >>> 1. It documents the fact that a method needs to be overridden >>> 2. It lets tools such as pylint know that this is an abstract method >>> 3. It results in a more informative error message >>> >>> But, in the end, if someone wants to define a class that defiantly >>> refuses to declare a method, you can't stop them. >> This is the con of a dynamic language... > In a language that has statements to force the user to over-ride a > method when a class is sub-classed, what is to stop the lazy > sub-classer from doing the equivalent of: > > define override_me(self, ...): > pass > > And so get code through the compiler,, allowing them to 'meet their > targets'? > And this *could* be perfectly suitable if the class really doesn't make use of the method. (I have seen this in poorly designed super classes and interface classes - sigh.) > - Paddy. > -- http://mail.python.org/mailman/listinfo/python-list
Re: strange for loop construct
* Gabriel Genellina wrote (on 1/5/2007 12:49 PM): > At Friday 5/1/2007 17:39, [EMAIL PROTECTED] wrote: > >> wordfreq = [wordlist.count(p) for p in wordlist] >> >> I would expect >> >> for p in wordlist: >> wordfreq.append(wordlist.count(p)) >> >> >> I didn't know you could have an expression in the same line. > > That's known as a "list comprehension" and is roughly equivalent to your > code. Section 5 of the tutorial covers them. > http://docs.python.org/tut/node7.html > > If you have a Python installation you should be able to find the "Whats New" section of the docs. List comprehensions are described pretty well in the "What's new in Python 2.0?" section. This gives some simple examples as well as the rationale behind them. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: Exiting from python shell
* James Stroud wrote (on 7/18/2007 4:27 PM): > Tobiah wrote: >> For years now, I've been exiting the shell by typing 'exit\n', >> being chid by the shell, and then typing ^D. I can't >> remember a time that I typed the ^D the first time. Call >> me an idiot if you must, but since someone took the trouble >> to catch the command 'exit' in a special way, would it have >> been so awful to just let it be a way to exit when the shell? >> >> Thanks, >> >> Toby >> > > Yes, this would have required a ground-up approach to redesigning the > python language, transmuting it to something like a cross between lisp > and COBOL and would have rendered it impossible to author with C because > of the way C implements pointers--hardcoding in assembly would likely be > required. Beyond that, exiting an interpreter is not known in computer > science and has been shown impossible by Goedel himself in a series of > monographs on the topic. Thus, to exit python via a keyword would > require also reformulating mathematics as we know it. Furthermore, such > a change would propagate itself, via the observer effect, to the > behavior of sub atomic particles via ill-defined quantum-mechanical > affects and would likely result in the reversal of the Second Law of > Thermodynamics, wherein your refrigerator would end up heating its > contents and milk would spontaneously spoil, among other anomalies. > > For these reasons, you might propose a "quit" keyword. > > James > You know, some answers simply *must* be saved for posterity Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: convert non-delimited to delimited
* RyanL wrote (on 8/27/2007 10:59 AM): > I'm a newbie! I have a non-delimited data file that I'd like to > convert to delimited. > > Example... > Line in non-delimited file: > 01397256359210100534+42050-102800FM-15+1198KAIA > > Should be: > 0139,725635,9,2000,01,01,00,53,4,+42050,-102800,FM-15,+1198,KAIA > > What is the best way to go about this? I've looked all over for > examples, help, suggestions, but have not found much. CSV module > doesn't seem to do exactly what I want. Maybe I'm just missing > something or not using the correct terminology in my searches. Any > assistance is greatly appreaciated! Using Python 2.4 > Since you have to know, a priori, how to break the input string I assume that these fields are of fixed length. You can use the following to do what you want: >>> a="01397256359210100534+42050-102800FM-15+1198KAIA" >>> print "%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s,%s" % (a[0:4],a[4:10],a[10:15],a[15:19],a[19:21],a[21:23],a[23:25], a[25:27],a[27],a[28:34],a[34:41],a[41:46],a[46:51],a[51:]) which results in the following output: 0139,725635,9,2000,01,01,00,53,4,+42050,-102800,FM-15,+1198,KAIA Mark -- http://mail.python.org/mailman/listinfo/python-list
About Eggs
This is probably a *really* stupid question but... I have looked at all the documentation I have for 2.4.3 and all the docs I can download for 2.5 and I simply cannot find anything, anywhere that documents what egg files are. I have read posts referring to them and have been able to deduce that they are some form of zip file for the distribution of modules but beyond that I cannot find *any* docs for them anywhere. Where are they documented and how do I take advantage of them? Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: About Eggs
* Rob Wolfe wrote (on 4/10/2007 1:38 PM): > Mark Elston <[EMAIL PROTECTED]> writes: > >> This is probably a *really* stupid question but... >> I have looked at all the documentation I have for 2.4.3 >> and all the docs I can download for 2.5 and I simply cannot >> find anything, anywhere that documents what egg files are. >> >> I have read posts referring to them and have been able to >> deduce that they are some form of zip file for the distribution >> of modules but beyond that I cannot find *any* docs for them >> anywhere. > > Start here: > http://peak.telecommunity.com/DevCenter/setuptools > Thanks to Rob and Mike for their answers. I will bookmark these pages immediately. Mark -- http://mail.python.org/mailman/listinfo/python-list
Re: python at command prompt
* [EMAIL PROTECTED] wrote (on 11/1/2007 9:58 AM): > [snip] >> Sounds like your path isn't set correctly. See the first section >> here[1] on "Finding python.exe" >> >> -tkc >> >> [1]http://www.imladris.com/Scripts/PythonForWindows.html > > Thanks Tim, > I set the pythonpath to where the python interpreter is located C: > \Python24 > However I still get the same error message. Is there something else > that must be configured? > thanks. > It's not the PYTHONPATH environment variable that you need to set. You need to set the PATH environment variable to include C:\Python24. That is where the Python executable is locate. Mark -- http://mail.python.org/mailman/listinfo/python-list
