Re: try/except KeyError vs "if name in ..."
Steven D'Aprano scripsit : > If you expect that most of the time the module will be found, the > try...except version will be faster. If you expect that most of the time > the module will not be found, the "if name in" version will be faster. > Ok. In the particular case of __import__, I guess speed is not crucial since I doubt import often happen within a program's inner loop. But I'll remember that point for other cases anyway. >> I'm suspecting that maybe, in multithreaded environments, the second >> option may be subject to a race condition, if another thread removes >> name frome sys.modules between the if and the return, but as I'm not >> very familiar (yet) with Python threads, I'm not sure it is a real >> concern here. > > In practice, no, it would be very unusual for another thread to remove > the name from sys.modules. So don't do that :) > That wasn't my intention. But sometimes other people may be "creative" :) > But in principle, yes, it is a race condition and yes it is a (small) > concern. Since it is so easy to avoid even this tiny risk, why not use > the try...except version and avoid it completely? > Ok. Thanks for your explanations. -- Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/ -- http://mail.python.org/mailman/listinfo/python-list
Re: try/except KeyError vs "if name in ..."
Günther Dietrich scripsit : > Somewhere I read a text regarding 'try:' versus 'if'. If you take the > probabitility into consideration, how many times the test will fail or > succeed, there are two possibilities: [...] Ok, thanks for the details! -- Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/ -- http://mail.python.org/mailman/listinfo/python-list
try/except KeyError vs "if name in ..."
Hi, I was looking at the example found here [1] which begins with: [1] http://docs.python.org/py3k/library/imp.html#examples def __import__(name, globals=None, locals=None, fromlist=None): # Fast path: see if the module has already been imported. try: return sys.modules[name] except KeyError: pass I was wondering if the formulation if name in sys.modules: return sys.modules[name] would be equivalent. IOW, is using try/except here only a matter of style or a necessity? I'm suspecting that maybe, in multithreaded environments, the second option may be subject to a race condition, if another thread removes name frome sys.modules between the if and the return, but as I'm not very familiar (yet) with Python threads, I'm not sure it is a real concern here. And maybe there are other reasons I'm completely missing for prefering EAFP over LBYL here? Thanks in advance for your comments. -- Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/ -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I hide my stack frames in a TestCase subclass?
Peter Otten scripsit : > Manuel Pégourié-Gonnard wrote: > >> Peter Otten scripsit : >> >>> __unittest = True >>> >> Hum, is it documented somewhere? I can't find it in the doc. Also, I'm >> curious to know what kind of magic it's using. > > I took advantage of the fact that Python is open source and had a look into > the source code ;) > Fair enough. However, there was an implied question in the "documented" part: can we rely on it? Isn't it considered an implementation detail (names starting with underscores)? > $ cd /usr/lib/python2.7/unittest > $ grep frame *.py -C2 > ... > result.py- > result.py-def _is_relevant_tb_level(self, tb): > result.py:return '__unittest' in tb.tb_frame.f_globals > result.py- > ... > > $ grep _is_relevant_tb_level *.py -C5 > result.py- > result.py-def _exc_info_to_string(self, err, test): > result.py-"""Converts a sys.exc_info()-style tuple of values into a > string.""" > result.py-exctype, value, tb = err > result.py-# Skip test runner traceback levels > result.py:while tb and self._is_relevant_tb_level(tb): > result.py-tb = tb.tb_next > result.py- > ... > > And so on. I actually used an editor, not grep -- but you get the idea. Sure, thanks. -- Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/ -- http://mail.python.org/mailman/listinfo/python-list
Re: How can I hide my stack frames in a TestCase subclass?
Peter Otten scripsit : > David Banks wrote: > >> Note that the custom assert method causes a stack trace with two frames, >> one inside the method itself, whereas the stock unittest method only has >> one frame, the relevant line in the user's code. How can I apply this >> frame-hiding behaviour to my own method? > > Move MyTestCase in a separate module and define a global variable > > __unittest = True > Hum, is it documented somewhere? I can't find it in the doc. Also, I'm curious to know what kind of magic it's using. -- Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Combinations of lists
Steven D'Aprano scripsit : > On Wed, 03 Oct 2012 16:26:43 +0200, Steen Lysgaard wrote: > >> This is achieved by the code below, this however needs to go through all >> possible combinations (faculty of len(h)) and rule out duplicates as >> they occur and this is too much if for example len(h) is 16. > > I don't understand this requirement. In the example above, you don't rule > out duplicates. Both 'aA' and 'bB' are duplicated. What duplicates are > you ruling out? > I think the requirement is that r[i] != r[j] as soon as i != j, if r is the resulting list of lists. (As opposed to having r[i][j] != r[i][k] for all i and j != k.) -- Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/ -- http://mail.python.org/mailman/listinfo/python-list
Re: Should one always add super().__init__() to the __init__?
Steven D'Aprano scripsit :
> On Sun, 30 Sep 2012 00:08:03 -0600, Ian Kelly wrote:
>
>> On Sat, Sep 29, 2012 at 10:40 PM, Steven D'Aprano
>> wrote:
>>> On Sat, 29 Sep 2012 17:51:29 -0400, Piet van Oostrum wrote:
>>>
>>>> It is not necesarily calling the parent class. It calls the
>>>> initializer of the next class in the MRO order and what class that is
>>>> depends on the actual multiple inheritance structure it is used in,
>>>> which can depend on subclasses that you don't know yet. This makes it
>>>> even worse.
>>>
>>> I don't quite follow you here. It sounds like you are saying that if
>>> you have these classes:
>>>
>>> # pre-existing classes
>>> class A(object): pass
>>> class B(object): pass
>>>
>>> # your class
>>> class C(A, B): pass
>>>
>>> and somebody subclasses A or B, the MRO of C will change. That is not
>>> actually the case as far as I can see.
>>
>> The MRO of C will not change, but the class that follows C may be
>> different in the MRO of a subclass.
>
> To quote a famous line from the movie Cool Hand Luke, "what we have here,
> is a failure to communicate."
>
> What do you mean by one class following another? Which class is it
> that follows C? What subclass are you talking about, and what is it
> subclassing?
>
I think Piet's (and Ian's) point is, you can't assume that
super().__init__, written in a method of C, is always going to refer to
__init__ of the parent class of C, when a subclass of C is instanciated.
For example:
class C:
def __init__(self):
print("C init, calling C's parent init?")
super().__init__() # sic
class NotParentOfC:
def __init__(self):
print("NotParentOfC init")
class Sub(C, NotParentOfC):
pass
spam = Sub()
When Sub is instantiated, the line marked "sic" calls
NotParentOfC.__init, not object.__init__ (as if would if C was
instantiated).
--
Manuel Pégourié-Gonnard - http://people.math.jussieu.fr/~mpg/
--
http://mail.python.org/mailman/listinfo/python-list
