Andy,<div><br></div><div>Thanks so much.</div><div><br></div><div>-Nick<br><br><div class="gmail_quote">On Tue, Oct 5, 2010 at 11:33 PM, Andy Wiggin <span dir="ltr"><<a href="mailto:andywiggin@gmail.com">andywiggin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Right. I couldn't get past that part either, at least based on what I<br>
know about coding in pure python. When we did this in C of course we<br>
used macros to wrap the standard return-on-error-of-child behavior and<br>
every now and then wrote something more sophisticated (oh! Just like<br>
an exception, except with extra text obscuring the code). So short of<br>
using a macro-preprocessor to generate your python files, you can at<br>
least standardize and condense the one-liner after each function call.<br>
Here's what I came up with:<br>
<br>
<br>
class FuncStatus:<br>
def __init__(self, success, payload):<br>
self.success = success<br>
self.payload = payload<br>
def err(self):<br>
return not self.success<br>
<br>
def sub_test(v):<br>
if v > 0:<br>
return FuncStatus(True, "a b c")<br>
else:<br>
return FuncStatus(False, ["d", "e", "f"])<br>
<br>
def main():<br>
#if (s = sub_test(-2)).err() return s<br>
s = sub_test(2)<br>
if s.err(): return s<br>
print "Hey 1", s.payload<br>
<br>
s = sub_test(-2)<br>
if s.err(): return s<br>
print "Hey 2", s.payload<br>
<br>
main()<br>
<font color="#888888"><br>
-Andy<br>
</font><div><div></div><div class="h5"><br>
On Tue, Oct 5, 2010 at 10:32 PM, Nick S Kanakakorn <<a href="mailto:bbdada@gmail.com">bbdada@gmail.com</a>> wrote:<br>
> Hi Andy,<br>
> Thanks for your comment. I could wrap this in a class but I'm not so sure<br>
> how it would save me to have to do something like this.<br>
> class ReturnWrapper(object):<br>
> def __init__(error_code, error_message, real_return_result)<br>
> ....<br>
> def f1(arg):<br>
> try<br>
> x = some_function()<br>
> except IndexError, e<br>
> return ReturnWrapper(-1,'some error message' , None)<br>
> # all good here<br>
> return ReturnWrapper(0, None, 'some good value')<br>
> def f1caller()<br>
> obj = f1(param1)<br>
> if (obj.error_code < 0):<br>
> # handle some error or just return obj<br>
> return obj<br>
> foo....<br>
> obj = f1(param2)<br>
> if (obj.error_code < 0):<br>
> # handle some error or just return obj<br>
> return obj<br>
> bar....<br>
><br>
> I still have to use this pattern if (obj.error_code < 0): ....<br>
> It does not really make my code smaller than using tuple.<br>
> I used to code C similar to what you said I did not expect to have to do<br>
> the<br>
> same thing in python<br>
> Thanks,<br>
> On Tue, Oct 5, 2010 at 9:42 PM, Andy Wiggin <<a href="mailto:andywiggin@gmail.com">andywiggin@gmail.com</a>> wrote:<br>
>><br>
>> I must agree with the "it's an unmitigated disaster" comments already<br>
>> posted. But it does remind me of a C coding convention that was the<br>
>> standard at a company worked at a long time ago. Here, the return<br>
>> value from a function was always a coded int value where part of the<br>
>> int told you the boolean pass/fail info, part encoded the severity,<br>
>> part the product id, and part the specific message that could be<br>
>> looked up to print. All packed into 32 bits. The analogy I can think<br>
>> of is that you might want to return an instance of a standard class<br>
>> instead of a raw tuple. It could have pass/fail info, perhaps more<br>
>> extended info, plus a generic "payload" that would carry whatever the<br>
>> function was really trying to return. This would at least save you<br>
>> from interpreting ad hoc tuples everywhere, and might be a basis for<br>
>> building something a bit more elegant.<br>
>><br>
>> -Andy<br>
>><br>
>> On Tue, Oct 5, 2010 at 9:16 PM, Nick S Kanakakorn <<a href="mailto:bbdada@gmail.com">bbdada@gmail.com</a>><br>
>> wrote:<br>
>> > I don't want to do this. There is someone that against throwing<br>
>> > exception<br>
>> > and that person has more seniority than me. He put in a guideline. I<br>
>> > lost<br>
>> > in the debate. There is no proper research done and all the decisions<br>
>> > were<br>
>> > made in less than 1 day.<br>
>> ><br>
>> > On Tue, Oct 5, 2010 at 9:03 PM, Tung Wai Yip <<a href="mailto:tungwaiyip@yahoo.com">tungwaiyip@yahoo.com</a>><br>
>> > wrote:<br>
>> >><br>
>> >> Why do you want to do this? Is this just an internal coding guideline?<br>
>> >> Or<br>
>> >> is it done for interfacing to another language or running on<br>
>> >> non-standard<br>
>> >> VM? Is this apply to new code only or do you want to update existing<br>
>> >> code as<br>
>> >> well?<br>
>> >><br>
>> >> There is no equivalent of C macro in Python. Just apply every code<br>
>> >> change<br>
>> >> as you describe it. Build a tuple every time you return something.<br>
>> >> Change<br>
>> >> raise into returning tuple. And change ever function call to expecting<br>
>> >> a<br>
>> >> tuple return value. I can't think of anything smarter. it looks like a<br>
>> >> complete disaster anyway.<br>
>> >><br>
>> >> Wai yip<br>
>> >><br>
>> >><br>
>> >><br>
>> >>> Let's skip the rationale discussion although I feel better for your<br>
>> >>> sympathy. One non python solution I can think of is Macro (C/C++) or<br>
>> >>> add<br>
>> >>> a<br>
>> >>> new command which could work in any stack frame (TCL).<br>
>> >>> However, I'm quite new to python so I'm not so sure if there are some<br>
>> >>> ways<br>
>> >>> around this.<br>
>> >>><br>
>> >>> Can we have something similar to macro in python ?<br>
>> >>><br>
>> >>> On Tue, Oct 5, 2010 at 7:27 PM, Glen Jarvis <<a href="mailto:glen@glenjarvis.com">glen@glenjarvis.com</a>><br>
>> >>> wrote:<br>
>> >>><br>
>> >>>><br>
>> >>>> > My work place has imposed a rules for no use of exception (catching<br>
>> >>>> > is<br>
>> >>>> allowed).<br>
>> >>>><br>
>> >>>> What?!?<br>
>> >>>><br>
>> >>>> Forgive my reaction, I'm just very surprised. Why has your workplace<br>
>> >>>> implemented this policy? Has anyone else on BayPIGgies seen a policy<br>
>> >>>> like<br>
>> >>>> this? What's the rationale? Am I a Luddite for not hearing on this?<br>
>> >>>><br>
>> >>>> I'm sorry. I know you asked a genuine question and I haven't answered<br>
>> >>>> it. I<br>
>> >>>> just found this very odd and am first getting my head around the<br>
>> >>>> question.<br>
>> >>>><br>
>> >>>> Cheers,<br>
>> >>>><br>
>> >>>><br>
>> >>>> Glen<br>
>> >>>><br>
>> >>>><br>
>> >>><br>
>> >>><br>
>> >><br>
>> >><br>
>> >> --<br>
>> >> Using Opera's revolutionary e-mail client: <a href="http://www.opera.com/mail/" target="_blank">http://www.opera.com/mail/</a><br>
>> >> _______________________________________________<br>
>> >> Baypiggies mailing list<br>
>> >> <a href="mailto:Baypiggies@python.org">Baypiggies@python.org</a><br>
>> >> To change your subscription options or unsubscribe:<br>
>> >> <a href="http://mail.python.org/mailman/listinfo/baypiggies" target="_blank">http://mail.python.org/mailman/listinfo/baypiggies</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > --<br>
>> > -Nick Kanakakorn<br>
>> ><br>
>> > _______________________________________________<br>
>> > Baypiggies mailing list<br>
>> > <a href="mailto:Baypiggies@python.org">Baypiggies@python.org</a><br>
>> > To change your subscription options or unsubscribe:<br>
>> > <a href="http://mail.python.org/mailman/listinfo/baypiggies" target="_blank">http://mail.python.org/mailman/listinfo/baypiggies</a><br>
>> ><br>
><br>
><br>
><br>
> --<br>
> -Nick Kanakakorn<br>
><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>-Nick Kanakakorn<br>
</div>