Of course that would be: > foo = lambda condition: MyClass() if condition else None
2011/3/3 Izz ad-Din Ruhulessin <izzaddin.ruhules...@gmail.com> > Maybe: > > foo = lambda x: MyClass() if condition else None > > > 2011/3/3 David <bouncingc...@gmail.com> > > Another classic case of trying something not the best way, due to >> inexperience. >> But it has been a good process: I learned something new from >> setting myself the initial puzzle and then finding a solution,and then >> learned more from the great tutoring here. Thanks very much for all >> the replies. >> >> On 2 March 2011 03:31, Alan Gauld <alan.ga...@btinternet.com> wrote: >> > >> >> class MyClass_2(object): >> >> def __new__(self, condition): >> >> if condition: >> >> return object.__new__(self) >> >> else: >> >> return None >> > >> > Thats pretty much how I'd do it. >> >> Thanks for reviewing my code. >> >> On 2 March 2011 03:35, Alan Gauld <alan.ga...@btinternet.com> wrote: >> > >> > Oops, sent too soon. >> > >> > I meant to add that you should realize that the implication of your >> > design is that the user of the class now has to check each object >> > to see if it is a valid reference or None. You could raise an exception >> > instead of returning None which allows a try/except style... >> > >> > This extra overhead is one reason these kinds of "clever" tricks >> > are usually avoided. A valid object with null content is often >> > preferrable, or a singleton style pattern. But occasionally your >> > style is needed, just be aware of the extra overhead you >> > introduce by using it. >> >> Spot on. It would require two "if" tests, one inside __new__() and >> another in the code. >> >> I found your mention of try/except there especially helpful, because >> it was a pertinent reminder that I was not thinking in "ask forgiveness >> not permission" mode. This (newbie mistake) occurred because I >> wanted my application to continue, not abort with an exception, but >> after your prompt I recalled that "except" doesn't have to raise >> exceptions >> it can do other things. >> >> So I went in the direction you suggested and I am happy with the results. >> Basically my application is interpreting binary file data by instantiating >> a >> structured object for each file in a fixed list of binary files, and I >> was looking >> for a neat way to ignore any errors on files that might not be present >> (failed to open). So, after feedback here my solution now is to use >> try/except in the class __init__() to create a valid object with null >> content, >> and then use "if" tests in the rest of the code that processes the objects >> to >> just ignore them if they are null, which is a nice clear way to do it. >> >> On 2 March 2011 20:44, Steven D'Aprano <st...@pearwood.info> wrote: >> > >> > By convention, the name of the first argument to __new__ is cls, not >> self, >> > because it is bound to the class object itself (MyClass_2 in this >> example) >> > rather than the instance. The instance doesn't yet exist, so that's not >> > surprising! >> >> Thanks for pointing that out. In 2.6 Language Reference 3.4.3 they used >> "mcs" (metaclass?) which I didn't comprehend at all at the time (the >> mindset >> of just wanting to get some code working to fix a problem is not the most >> helpful mindset for decoding a large body of new information), so I just >> used >> "self" when getting their example code to work for me. In Section 3.4.1 >> they >> use "cls" which I now see clearly and understand thanks. >> >> On 3 March 2011 03:03, Knacktus <knack...@googlemail.com> wrote: >> > >> > I think that's too clever ;-). >> >> I agree now .. but it was a useful experiment. Thanks for the tute. >> _______________________________________________ >> Tutor maillist - Tutor@python.org >> To unsubscribe or change subscription options: >> http://mail.python.org/mailman/listinfo/tutor >> > >
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor