Run time default arguments
What is the most common way to handle default function arguments that
are set at run time, rather than at compile time? The snippet below is
the current technique that I've been using, but it seems inelegant.
defaults = { 'debug' : false }
def doSomething (debug = None):
debug = debug if debug != None else defaults['debug']
# blah blah blah
Basically, I want to define a set of common defaults at the module and/
or class level but let them be overridden via function arguments. The
simpler, naive approach does not work, because the argument gets set
at compile time, rather than at run time. That is:
def doSomething(debug = defaults['debug'])
ends up being compiled into:
def doSomething(debug = false)
which is not the behavior I want, as I want to evaluate the argument
at run time.
Any better suggestions?
--
// T.Hsu
--
http://mail.python.org/mailman/listinfo/python-list
Re: Run time default arguments
On Aug 25, 10:35 am, Arnaud Delobelle wrote: > You're close to the usual idiom: > > def doSomething(debug=None): > if debug is None: > debug = defaults['debug'] > ... > > Note the use of 'is' rather than '==' > HTH Hmm, from what you are saying, it seems like there's no elegant way to handle run time defaults for function arguments, meaning that I should probably write a sql-esc coalesce function to keep my code cleaner. I take it that most people who run into this situation do this? def coalesce(*args): for a in args: if a is not None: return a return None def doSomething(debug=None): debug = coalesce(debug,defaults['debug']) # blah blah blah -- // T.Hsu -- http://mail.python.org/mailman/listinfo/python-list
Re: is there any principle when writing python function
On Aug 23, 7:59 am, smith jack wrote: > i have heard that function invocation in python is expensive, but make > lots of functions are a good design habit in many other languages, so > is there any principle when writing python function? > for example, how many lines should form a function? My suggestion is to think how you would test the function, in order to get 100% code coverage. The parts of the function that are difficult to test, those are the parts that you want to pull out into their own separate function. For example, a block of code within a conditional statement, where the test condition cannot be passed in, is a prime example of a block of code that should be pulled out into a separate function. Obviously, there are times where this is not practical - exception handling comes to mind - but that should be your rule of thumb. If a block of code is hard to test, pull it out into it's own function, so that it's easier to test. -- // T.Hsu -- http://mail.python.org/mailman/listinfo/python-list
Re: List comprehension timing difference.
On Sep 2, 9:54 am, Bart Kastermans wrote: > if d(a,b) == 1 and a < b: It will probably be faster if you reverse the evaluation order of that expression. if ahttp://mail.python.org/mailman/listinfo/python-list
Re: Doctest failing
On Sep 10, 7:47 am, Peter Otten <[email protected]> wrote: > Tigerstyle wrote: > > I'm strugglin with some homework stuff and am hoping you can help me > > out here. > > > This is the code: > > > small_words = ('into', 'the', 'a', 'of', 'at', 'in', 'for', 'on') > > new_title = [] > > title_split = title.strip().lower().split() > > for word in title_split: > > if title_split[0] in small_words: > > new_title.append(word.title()) > > elif word in small_words: > > new_title.append(word.lower()) > > else: > > new_title.append(word.title()) > > The logic of the for-loop is flawed; the expression > > title_split[0] in small_words > > will always evaluate to True if the first word is a "small word", even when > the loop is already past the first word. You can work around that with a > flag along these lines > > first = True > for word in title_split: > if first: > # special treatment for the first word > first = False > else: > # put checks for all words but the first here > new_title.append(fixed_word) # assuming you have stored the titlecased > # or lowercased word in the fixed_word > # variable Another way to tackle this is to just capitalize the entire sentence before returning it. new_title = [] title_split = title.strip().lower().split() for word in title_split: if word in small_words: new_title.append(word.lower()) else: new_title.append(word.title()) return(''.join(new_title).capitalize()) However, I'm only helping with your homework, because I want to point out that doctest comments should be *readable*. Don't just throw them in, take the extra 10-15 seconds to make them easier on the eyes. In the workplace, months will pass before you review this code again, so you want to make it easier for an older version of yourself to remember it. And it takes very little effort to make it readable. Here's your doctest string, reformatted with just a tiny bit more whitespace. I even cut out a sentence. def book_title(title): """ All words EXCEPT for small words are made title case unless the string starts with a preposition, in which case the word is correctly capitalized. >>> book_title('DIVE Into python') 'Dive into Python' >>> book_title('the great gatsby') 'The Great Gatsby' >>> book_title('the WORKS OF AleXANDer dumas') 'The Works of Alexander Dumas' """ -- // T.Hsu -- http://mail.python.org/mailman/listinfo/python-list
Re: re.sub(): replace longest match instead of leftmost match?
On Dec 16, 11:49 am, John Gordon wrote: > I'm working with IPv6 CIDR strings, and I want to replace the longest > match of "(:|$)+" with ":". But when I use re.sub() it replaces > the leftmost match, even if there is a longer match later in the string. Typically this means that your regular expression is not specific enough. That is, if you get multiple matches, and you need to sort through those matches before performing a replace, it usually means that you should rewrite your expression to get a single match. Invariably this happens when you try to take short cuts. I can't blame you for using a short cut, as sometimes short cuts just work, but once you find that your short cut fails, you need to step back and rethink the problem, rather than try to hack your short cut. I don't know what you are doing, but off the top of my head, I'd check to see if the CIDR string is wrapped in a header message and include the header as part of the search pattern, or if you know the IPv6 strings are interspersed with IPv4 strings, I would rewrite the regex to exclude IPv4 strings. -- // T.Hsu -- http://mail.python.org/mailman/listinfo/python-list
Re: Make a small function thread safe
On Dec 16, 8:21 am, Brad Tilley wrote: > A thread locks the function on entrance and then releases it on exit. > What is the equivalent way to do this in Python? I'm not sure if this applies in your case, but much of the time, you can use thread local storage, rather thread locking, in order to make your code thread safe. You tend to run into far less bottleneck and race condition issues by using thread local storage rather than thread locking, whenever possible. -- // T.Hsu -- http://mail.python.org/mailman/listinfo/python-list
Is there a way to execute shell commands on VMWare server via PyVMomi?
We have some VM running on top of EXSi. We want to be to run some remote arbitrary commands on the VM, anyone has experience with https://github.com/vmware/pyvmomi? which command do i need to call? Thanks -- https://mail.python.org/mailman/listinfo/python-list
