Re: Clean way to not get object back from instantiation attempt gone bad
tobiah wrote:
Suppose I do:
myfoo = Foo('grapes', 'oranges')
And in the __init__() of Foo, there is
a real problem with the consumption of fruit.
Is there a clean way to ensure that myfoo
will be None after the call? Would the
__init__() just do del(self), or is there
a better way to think about this?
There is a way, of course, that results in myfoo
being None in case of an error, but it is not a one-liner and
I'd not recommend it.
If something goes wrong, raising an exception is the best thing to do.
Georg
--
http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
tobiah wrote:
Suppose I do:
myfoo = Foo('grapes', 'oranges')
And in the __init__() of Foo, there is
a real problem with the consumption of fruit.
Is there a clean way to ensure that myfoo
will be None after the call? Would the
__init__() just do del(self), or is there
a better way to think about this?
Thanks,
Toby
As others have said, just raise an exception. You can hide
instantiation inside a factory function to simulate the behaviour
you're specifically talking about:
class Foo:
def __init__(self, *args):
for arg in args:
if is_fruit(arg):
raise RuntimeError(I don't like fruit)
def FooFactory(*args):
try:
return Foo(*args)
except RuntimeError:
return None
-Grant
--
http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
John Machin wrote: Simon Forman wrote: | class f: ... def __init__(self): ... del self Of course nothing happens. Args are local variables. 'self' is is a vanilla arg of a vanilla function. I know. ... | e = f() | e __main__.f instance at 0xb7dd91ec | class f: ... def __init__(self): ... return None Of course nothing different happens. There is always an implicit return None when control falls off the end of a function. Making it explicit changes nothing. I know ... | e = f() | e __main__.f instance at 0xb7dd934c The whole idea of del self or return None is not a goer. self is a reference to the (mutable) newly created object. After __init__ has finished mutating it, the constructor will return the object to the constructor's caller. I know that too. The whole idea that None should be returned in the event of error is ... well, let's just say it leaves me speechless. Tell me about it. But you could raise an exception and check for it: | class f: ... def __init__(self, flag=True): ... if not flag: ... raise Please read the manual. A lone raise does *not* raise an anonymous exception; it re-raises an exception that has just been trapped. If there are none, it raises None, which causes (as documented) a TypeError. I know ... | def f_factory(flag): ... try: ... e = f(flag) ... except: Blanket exception catching is *never* a good idea. In this case the exception being caught is an artifact of your use of the unadorned raise. I know If you inserted here: ... import sys ... x, y = sys.exc_info()[:2] ... print x, y you would get: exceptions.TypeError exceptions must be classes, instances, or strings (deprecated), not NoneType Yep. ... e = None ... return e ... | foo = f_factory(True) | foo __main__.f instance at 0xb7dd944c | foo = f_factory(False) | foo | print foo None HTH, John The entire post was meant as a pedantic exercise illustrating what not to do (and how easy it is to figure that out with an interactive session,) and sketching how to raise and check for an error instead. In the three seconds I spent thinking about it, I couldn't decide what exception to raise, so I used the wicked bare raise and except. I'm certainly not advocating their use, but perhaps I should've made that plain in a post intended to be educational. In any event, with your comments it's out there now, and the educational value of this entire thread has been improved. Thanks John. Peace, ~Simon -- http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
Simon Forman wrote: The entire post was meant as a pedantic exercise illustrating what not to do (and how easy it is to figure that out with an interactive session,) and sketching how to raise and check for an error instead. Lessons usually start with the teacher asserting authority and stating the objective of the lesson, especially if the main content is a list of things the students should *not* do. Otherwise, casual observers can only apply duck-typing :-) Peace, et pax vobiscum ... -- http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
I should have made it more clear that Foo is a class:
class Foo:
def __init__(self, *args):
for arg in args:
if is_fruit(arg):
del(self)
tobiah wrote:
Suppose I do:
myfoo = Foo('grapes', 'oranges')
And in the __init__() of Foo, there is
a real problem with the consumption of fruit.
Is there a clean way to ensure that myfoo
will be None after the call? Would the
__init__() just do del(self), or is there
a better way to think about this?
Thanks,
Toby
--
Posted via a free Usenet account from http://www.teranews.com
--
http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
tobiah wrote:
I should have made it more clear that Foo is a class:
class Foo:
def __init__(self, *args):
for arg in args:
if is_fruit(arg):
del(self)
tobiah wrote:
Suppose I do:
myfoo = Foo('grapes', 'oranges')
And in the __init__() of Foo, there is
a real problem with the consumption of fruit.
Is there a clean way to ensure that myfoo
will be None after the call? Would the
__init__() just do del(self), or is there
a better way to think about this?
Thanks,
Toby
I don't think there is a way to do this (but I could be wrong):
| class f:
... def __init__(self):
... del self
...
| e = f()
| e
__main__.f instance at 0xb7dd91ec
| class f:
... def __init__(self):
... return None
...
| e = f()
| e
__main__.f instance at 0xb7dd934c
But you could raise an exception and check for it:
| class f:
... def __init__(self, flag=True):
... if not flag:
... raise
...
| def f_factory(flag):
... try:
... e = f(flag)
... except:
... e = None
... return e
...
| foo = f_factory(True)
| foo
__main__.f instance at 0xb7dd944c
| foo = f_factory(False)
| foo
| print foo
None
There might be a way using __new__(), but I don't know what or how.
Also, del is a statement, not a function. You don't need to use
()'s.
HTH,
~Simon
--
http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
tobiah wrote:
I should have made it more clear that Foo is a class:
class Foo:
def __init__(self, *args):
for arg in args:
if is_fruit(arg):
del(self)
tobiah wrote:
Suppose I do:
-* myfoo = Foo('grapes', 'oranges')
And in the __init__() of Foo, there is
a real problem with the consumption of fruit.
Is there a clean way to ensure that myfoo
will be None after the call? Would the
__init__() just do del(self), or is there
a better way to think about this?
Yes. Raise an exception, with details of what the problem is -- which
arg? what (out of multiple possible problems) is wrong with it?
if self.is_fruit(arg):
raise FooError(I don't eat fruit: %r % arg)
if self.some_other_problem(arg):
raise FooError(Some other problem: %r % arg)
HTH,
John
--
http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
tobiah [EMAIL PROTECTED] writes:
myfoo = Foo('grapes', 'oranges')
And in the __init__() of Foo, there is a real problem with the
consumption of fruit. Is there a clean way to ensure that myfoo
will be None after the call? Would the __init__() just do
del(self), or is there a better way to think about this?
I'm not sure I understand your goal, but it seems that you want to
handle two cases: one where Foo can be properly initialised, and one
where it can't -- an error condition.
That sounds like a job for exceptions.
class ConsumptionError(ValueError):
... Exception thrown from bad consumption
...
class Foo(object):
... def __init__(self, left_thing, right_thing):
... if left_thing == 'grapes':
... raise ConsumptionError(Problem with consumption of fruit)
...
myfoo = Foo('zucchini', 'spam')
print myfoo
__main__.Foo object at 0x401e446c
myfoo = Foo('grapes', 'oranges')
Traceback (most recent call last):
File stdin, line 1, in ?
File stdin, line 4, in __init__
__main__.ConsumptionError: Problem with consumption of fruit
try:
... myfoo = Foo('grapes', 'oranges')
... except ConsumptionError, e:
... myfoo = None
...
print myfoo
None
--
\ Rommel: Don't move, or I'll turn the key on this can of Spam! |
`\ -- The Goon Show, _Rommel's Treasure_ |
_o__) |
Ben Finney
--
http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
tobiah wrote:
Suppose I do:
myfoo = Foo('grapes', 'oranges')
And in the __init__() of Foo, there is
a real problem with the consumption of fruit.
Is there a clean way to ensure that myfoo
will be None after the call? Would the
__init__() just do del(self), or is there
a better way to think about this?
There's no way that the __init__() method can change the object of which
it's a method, since self is a variable local to the method (so changing
it won't change the object) and the method is required to return None.
regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden
--
http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
Simon Forman wrote: | class f: ... def __init__(self): ... del self Of course nothing happens. Args are local variables. 'self' is is a vanilla arg of a vanilla function. ... | e = f() | e __main__.f instance at 0xb7dd91ec | class f: ... def __init__(self): ... return None Of course nothing different happens. There is always an implicit return None when control falls off the end of a function. Making it explicit changes nothing. ... | e = f() | e __main__.f instance at 0xb7dd934c The whole idea of del self or return None is not a goer. self is a reference to the (mutable) newly created object. After __init__ has finished mutating it, the constructor will return the object to the constructor's caller. The whole idea that None should be returned in the event of error is ... well, let's just say it leaves me speechless. But you could raise an exception and check for it: | class f: ... def __init__(self, flag=True): ... if not flag: ... raise Please read the manual. A lone raise does *not* raise an anonymous exception; it re-raises an exception that has just been trapped. If there are none, it raises None, which causes (as documented) a TypeError. ... | def f_factory(flag): ... try: ... e = f(flag) ... except: Blanket exception catching is *never* a good idea. In this case the exception being caught is an artifact of your use of the unadorned raise. If you inserted here: ... import sys ... x, y = sys.exc_info()[:2] ... print x, y you would get: exceptions.TypeError exceptions must be classes, instances, or strings (deprecated), not NoneType ... e = None ... return e ... | foo = f_factory(True) | foo __main__.f instance at 0xb7dd944c | foo = f_factory(False) | foo | print foo None HTH, John -- http://mail.python.org/mailman/listinfo/python-list
Re: Clean way to not get object back from instantiation attempt gone bad
On Tue, 15 Aug 2006 16:04:12 -0700, tobiah wrote:
Suppose I do:
myfoo = Foo('grapes', 'oranges')
And in the __init__() of Foo, there is
a real problem with the consumption of fruit.
Is there a clean way to ensure that myfoo
will be None after the call?
I don't believe so.
Generally, in the event of an error, you should raise an exception:
class Foo():
def __init__(self, *fruits):
if grapes in fruits:
raise AllergyError(I'm allergic to grapes)
# process fruits
Then handle the exception:
try:
myfoo = Foo('grapes', 'oranges')
except AllergyError:
# recover gracefully
handle_failed_instance()
If you wish, you can wrap it in a function:
def safe_foo(*fruits):
try:
return Foo(*fruits)
except AllergyError:
return None
myfoo = safe_foo('grapes', 'oranges')
The disadvantage of this is now your code has to be sprinkled with a
million tests if myfoo is not None: process(myfoo).
Would the
__init__() just do del(self), or is there
a better way to think about this?
An alternative is to use a propagating not a Foo Foo object, like NaNs
and INFs in floating point.
class Foo():
def __init__(self, *fruits):
if grapes in fruits:
self._state = failed # NaNs use special bit patterns
else:
# process fruits
self._state = okay
def method(self, *args):
if self._state != failed:
# process instance
else:
pass # do nothing
def __add__(self, other):
if self._state == failed:
return self
elif other._state == failed:
return other
else:
# process Foo addition
return something
Now you can call Foo methods regardless of whether the instance is valid
or not, errors will propagate cleanly, and you only need to check whether
the instance is valid at the very end of your code.
However, unless there is a clear advantage of doing this, you're creating
a fair bit of extra work for yourself.
--
Steven D'Aprano
--
http://mail.python.org/mailman/listinfo/python-list
