Re: I love assert
On Tue, Nov 11, 2014 at 12:57 PM, TP wrote: > On Tue, Nov 11, 2014 at 11:40 AM, Peter Cacioppi > wrote: > >> I think one needs to take care with some basic assert coding - it's not a >> substitute for unit tests, it doesn't absolve you of normal exception >> responsibilities, and, most of all, it should be used for passive >> inspection and not action. But given these guidelines, I still find it very >> useful as "active comments". > > > I first came across asserts when using Wing IDE. See "Helping Wing Analyze > Code" [1] explains why using assert and isinstance will let Wing IDE > autocomplete things it otherwise couldn't. > > PyCharm uses docstrings to accomplish the same task [2] but can also use > asserts/isinstance [3]. > > [1] https://wingware.com/doc/edit/helping-wing-analyze-code > > [2] https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html > <https://www.jetbrains.com/pycharm/webhelp/type-hinting-in-pycharm.html#d232466e456> > > [3] > http://stackoverflow.com/questions/9040387/is-there-a-way-to-explicitly-tell-pycharm-what-class-an-attribute-is-an-instance > > I use PyCharm. Thanks for [2], it's a keeper -- https://mail.python.org/mailman/listinfo/python-list
I love assert
I get the impression that most Pythonistas aren't as habituated with assert statements as I am. Is that just a misimpression on my part? If not, is there a good reason to assert less with Python than other languages? As far as I can tell, Python supports assert perfectly well. When run with the optimization flagging, the asserts are truly removed. I think one needs to take care with some basic assert coding - it's not a substitute for unit tests, it doesn't absolve you of normal exception responsibilities, and, most of all, it should be used for passive inspection and not action. But given these guidelines, I still find it very useful as "active comments". -- https://mail.python.org/mailman/listinfo/python-list
Re: my favorite line of py code so far
Chris said : "Absolutely! The unfortunate truth, though, is that idioms that resonate with you _and nobody else_ are just as big a problem as bugs, because they're unmaintainable. So hopefully what you're doing will make sense to other people too! " There is some truth in what you say ... but in this case we're talking about an algorithmically trivial portion of a project for which I am basically BDFL. So as long as I'm not totally in left field, I'm going with what feels truthy to me. Also, lambda c : lambda x : c(*x) would make a sweet tattoo. Much better than some Kanji that might as well translate into "dumb white guy" for all I know ;) -- https://mail.python.org/mailman/listinfo/python-list
Re: my favorite line of py code so far
Sorry, typo, meant to say To be clear, I was never really intending to keep the _ = lambda c : lambda x : c(*x) map(_(P), zip([1,2,3], [6, 5, 4])) code snippets in my final work product. The purpose of this thread was too fish around for ideas on what to replace it with... -- https://mail.python.org/mailman/listinfo/python-list
Re: my favorite line of py code so far
Chris said : "I think map is fine if you can use a named function, but if you can't come up with a descriptive name for what you're doing, a comprehension is probably better (as it'll have the code right there). Mapping _ across everything tells you nothing about what it's actually doing" OK, this makes a lot of sense. (Any my apologies to Peter Otten if my previous post was overly snarky). How about this? I put the following in my catchall_utility.py module # the oneArg combinator takes a multi-argument calleable # and returns the equivalent single argument calleable oneArg = lambda c: lambda x : c(*x) With example code map(oneArg(P), zip([1,2,3], [6, 5, 4])) To my mind the idea that oneArg(P) is a calleble that behaves exactly like P, with the only difference being oneArg(P) accepts P's arguments packed into a single iterable, is very intuitive. I actually find the oneArg version more readable than the comprehension that unpacks explicitly using *. At this point I probably have equal experience coding Lisp and Py, with the latter more recent, so I don't think this bias can be chalked up to "experienced functional programmer, beginner py programmer". To be clear, I was never really intending to keep the _ = lambda c : lambda x : c(*x) map(oneArg(P), zip([1,2,3], [6, 5, 4])) code snippets in my final work product. The purpose of this thread was too fish around for ideas on what to replace it with when I execute the "use the unit tests to facilitate refactoring for better names and more professional idioms" step. (We never, ever, skip that step, right?) Although it is unlikely you will convince me to use the comprehension in this sort of situation, it's possible someone could convince me to use starmap with P instead of map with oneArg(P). Those two techniques are fully equivalent. But, to my mind, the latter just feels right, and I find that I write fewer bugs when I use idioms that resonate. Thanks again, good thread for me -- https://mail.python.org/mailman/listinfo/python-list
Re: my favorite line of py code so far
Peter Otten said: ">>> _ = lambda c: lambda x: c(*x) >>> list(map(_(P), zip([1,2,3], [6, 5, 4]))) [Point(x=1, y=6), Point(x=2, y=5), Point(x=3, y=4)] ? While the obvious approach would be >>> [P(*args) for args in zip([1,2,3], [6, 5, 4])] [Point(x=1, y=6), Point(x=2, y=5), Point(x=3, y=4)] " I would have coded >>> map(_(P), zip([1,2,3], [6, 5, 4])) Which is very concise and (to me) quite clear. Forgive me for having a bias for fewer characters. Are you saying it's always preferable to avoid map? Is map going to be deprecated? I sometimes use map, sometimes comprehensions. I suspect other people do the same, that's why the language supports map and comprehensions. "there is also itertools.starmap(): " Thanks, that's a bit closer to what I am doing. To me the pure combinator is more appealing than starmap, but the presence of starmap explains why the library wouldn't need the combinator. -- https://mail.python.org/mailman/listinfo/python-list
Re: my favorite line of py code so far
Chris said: "So... for any given class, it returns a tweaked version that unpacks an iterable of its arguments instead of taking separate args. " It works with any calleable (not just any class), but otherwise your summary is spot on. "Interesting, perhaps, but not something that'll be needed in the stdlib." Fair enough. In the interest of self promotion, I'm calling it the Cacioppi combinator. The tattoo apt is for Tues. -- https://mail.python.org/mailman/listinfo/python-list
my favorite line of py code so far
my fav so far is this _ = lambda c : lambda x : c(*x) c can be any calleable and x any iterable, but I tend to use it with a class, and then map _(class) over the result of a zip. It must be in the library somewhere, but I haven't found it. I'm never sure what to call it, so I just reroll it into _ as needed. It's pretty easy for me to remember, but I'll probably tattoo it on my chest just in case. -- https://mail.python.org/mailman/listinfo/python-list
Re: Slicing with negative strides
On Monday, October 28, 2013 10:22:00 PM UTC-7, Steven D'Aprano wrote: > Does anyone here use slices (or range/xrange) with negative strides other > > than -1? > Non default positive strides are very handy, but negative strides seem weird to me. Not the negative striding exactly, but the way fenceposts and negative strides interact. For example, this poster seems to posit a canonical WTF with negative strides. http://stackoverflow.com/questions/5798136/python-reverse-stride-slicing I can almost picture Picard saying "WTF do you need to omit the end index to get the zero element??!!" Readability counts, no? Just reverse it and use positive strides. -- https://mail.python.org/mailman/listinfo/python-list
Re: zero argument member functions versus properties
Ian said : "Since the compiler generally can't predict what the types of objects will be, the bytecode that it generates can't depend on those types." very nice, the py is strong with you. Thanks, Pete -- https://mail.python.org/mailman/listinfo/python-list
Re: zero argument member functions versus properties
Ian said : " Whereas in Python, an attribute access is just compiled as an attribute access no matter what the underlying implementation of that access may end up being at run-time. " Really? Very nice. Have a good link handy for that? I'm compiling a codex of "why py is better?". -- https://mail.python.org/mailman/listinfo/python-list
Re: zero argument member functions versus properties
Steve said: "(This isn't Java or Ruby, where data-hiding is compulsory :-) " At the risk of striking a sessile equine, when the attribute shouldn't be modified directly by client code, then you hide it and use a property to allow client code access. It is the idiom of allowing client code to edit read-write data directly via attributes that is pythonic, even though discouraged (somewhat) in other languages. Actually C# is mature enough for this idiom. C# and Python both support getter/setter methods that present as direct attribute access to client code, and thus allow you to refactor the class without breaking backwards compatibility. -- https://mail.python.org/mailman/listinfo/python-list
Re: zero argument member functions versus properties
Steve said: "(This isn't Java or Ruby, where data-hiding is compulsory :-) " (You could add C++ and C# to this list). This is golden nugget for me. The old synapses are pretty well grooved to think of data hiding as good hygiene. Even though I've read a fair bit of Python text I still need to be reminded of the little idiomatic differences between Py and all the languages made obsolete by Py ;) Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: zero argument member functions versus properties
I just said "1-> the zero argument function is sort of factory-like. It potentially has non-trivial run time, or it substitutes calling a class constructor when building certain objects. 2-> it simply retrieves a stored value (perhaps lazily evaluating it first) so 1 should clearly be a zero argument member function. 2 should be a method. " typo. Obviously, 2 should be a property. -- https://mail.python.org/mailman/listinfo/python-list
zero argument member functions versus properties
Python makes it very easy to turn a zero argument member function into a property (hooray!) by simply adding the @property decorator. (Meme for well thought py feature - "Guido was here") But the ease with which you can do this makes the "zero argument member function or property" discussion trickier for me. Generally my sense here is there are two extremes 1-> the zero argument function is sort of factory-like. It potentially has non-trivial run time, or it substitutes calling a class constructor when building certain objects. 2-> it simply retrieves a stored value (perhaps lazily evaluating it first) so 1 should clearly be a zero argument member function. 2 should be a method. Other than that, I say "when in doubt, go with zero argument method". In particular something in my gut says that if the thing I'm returning is itself a function, than don't go with property. In other words foo.bar()(x) self documents that bar returns a function whereas foo.bar(x) looks like bar is a one argument member function of foo, as opposed to a property that returns a 1 argument function I also think that foo.size() implies that foo performs a count every time it's called, and foo.size implies that the run time will amortize to O(1) somehow (usually with lazy eval). So the implementation should drive the property or not decision. Sound a bit right? Seems like some of the energetic posters will have fun with this one, re:less. -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
Mark said : "The White Flag before this also escalates out of control. " This word "before" ... I don't think it means what you think it means. This thread has been off the rails for days. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python wart
Chris said : "It does look cool on paper. " Sure, I'll buy that Bjarne designed something intellectually pretty that just doesn't flow very well in practice. Most of his C++ worked very well both in theory and practice, so I can forgive him one nerdy overreach, if that's what it was. Python is impressive for it's lack of such constructions. Things are pretty to think about, and handy to use. What is it the French say? "Sure it works in practice, but does it work on paper?" ;) I can joke, I once had many very smart French colleagues. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python wart
Chris said : " I almost exclusively use C-style formatted strings, even sometimes going to the extent of using fopen() just so I can use fprintf() rather than fstream. Also, I often create a class something like this: " Ditto all that, to include the special class I cooked up to handle printf issues in an object based way. In general, I liked all the C++ additions a lot. I really liked the STL. But I don't know what Bjarne was thinking with the streams. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python wart
Mark said : "so I can get an extremely large pair of pliers with which I can extract my tongue from my cheek :) " OK fair enough, and my post was in the same spirit. Chris said : "Maybe, but it's supported by so many languages that it is of value. " Sure, I suppose someone should make a module that gets you as close as possible within the as-is language definition. I can't really comment on whether Py is close enough currently, as I always thought printf was sort of crappy. I thought the C++ << business even worse. Like I said, Python seems fine to me in this area. I use the str(), round() and ljust(), rjust() functions and concatenate what I need together. The result seems more readable than the old printf crap I used to write (not exactly clearing a sky high bar). Just one man-child's opinion. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python wart
Mark said : "Do I have to raise a PEP to get this stupid language changed so that it dynamically recognises what I want it to do and acts accordingly?" The printf syntax in C isn't any wonderful thing, and there is no obligation to provide some Python version of it. I have to say, there were a few things that twerked me when getting up to speed on Py, but formatting strings wasn't one of them. I'd be surprised if Guido prioritizes a fix for this part of his "stupid language". Just sayin -- https://mail.python.org/mailman/listinfo/python-list
Re: how to avoid checking the same condition repeatedly ?
Chris said : "Want some examples of what costs no clarity to reimplement in another language? Check out the Python standard library. Some of that is implemented in C (in CPython) and some in Python, and you can't tell and needn't care which." To ME (a consumer of the CPython library) there is zero cost to clarity. To the angels that maintain/develop this library and need to go inside the black box regularly there is a non-zero cost to clarity. Right? (I'd rather run the risk of stating the obvious than missing something clever, that's why I keep hitting this sessile equine). -- https://mail.python.org/mailman/listinfo/python-list
Re: how to avoid checking the same condition repeatedly ?
Chris said " If you actually profile and find that something-or-other is a bottleneck, chances are you can break it out into a function with minimal loss of clarity, and then reimplement that function in C (maybe wielding Cython for the main work). That doesn't compromise clarity. " Well, I'm not going to go back and forth saying "does too, does not" with you. I have a 7 year old for those sorts of arguments. And I think we are saying more or less the same thing. I agree that isolating your bottleneck to the tightest possible subroutine usually doesn't compromise clarity. But once you are re-implementing the bottleneck in a different language esp a language notorious for high performance nuggets of opaqueness... that does compromise clarity, to some extent. (Does not, does too, does not, does too, ok we're done with that part) But this sort of bottleneck refactoring can be done in a careful way that minimizes the damage to readability. And a strength of py is it tends to encourage this "as pretty as possible" approach to bottleneck refactoring. This is what you're saying, right? -- https://mail.python.org/mailman/listinfo/python-list
Re: how to avoid checking the same condition repeatedly ?
Nobody (yes, his name is Nobody) said: "If you're sufficiently concerned about performance that you're willing to trade clarity for it, you shouldn't be using Python in the first place." I think the correct thing to say here is, IF you know this subroutine is a bottleneck, THEN probably this subroutine (or even the module it lives within) should be recoding in a language closer to the metal (like C). I don't think it's correct to imply that people very concerned about performance should not use Python. (And I agree, Nobody implied that ;) But sometimes performance concerns require the bottleneck(s) be recoded in a manner that sacrifices readability for performance, to include a different language. Python generally plays well with other languages, no? So code it in Py, profile it, refactor the bottlenecks as needed. -- https://mail.python.org/mailman/listinfo/python-list
Re: Function for the path of the script?
Steven said "Isn't freedom of choice wonderful?" Didn't somebody once say "we're all adults here". I forget who said that. Eddard Stark? The guy always did keep his head in a crisis. -- https://mail.python.org/mailman/listinfo/python-list
Re: Function for the path of the script?
Ben Finney asked "What workflow requires you to know the filename of the module, within the module? " So what I have is a project utility script in my scripts directory. I have a distinct file structure that holds my .py source, my test.py unit tests, and the file based data associated with the unit tests. Each test.py is in a dedicated directory. My utility script can be easily tweaked to do a variety of useful things, one of which is leave the interactive session with a variable that points to a testing directory whose unit test failed. It relies on each test.py having a same named function that knows its directory. It sounds like there is a more pythonic way to do what I am doing, but also that I am not completely out to lunch. Sounds about par for my python code at this point. As my code used to be almost exclusively out to lunch, I think I am improving (thanks guys!). -- https://mail.python.org/mailman/listinfo/python-list
Function for the path of the script?
Am I the only one who finds this function super useful? def _code_file() : return os.path.abspath(inspect.getsourcefile(_code_file)) I've got one in every script. It's the only one I have to copy around. For my workflow ... so handy. I've got os.path.dirname aliased to dn, so its dn(_code_file()) that I find myself reaching for fairly often... -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
Rusi said : "Please do! If I were in charge I would say "Patches welcome!" Well, I don't really know what the GG best practice ought to be here. What I am doing now (manually copying whatever I need to quote to give some context) seems to be tolerable to law enforcement (I guess). But I'm minimizing the PIA not with some clever GG usage but by exploiting two monitors and the way I have "open in new browser" configured. It isn't something I'd care to document and it doesn't really scale to general usage. And, for all I know, the goons are still grinding their teeth, they're just more quiet now. -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
Rusi said: "Users of GG are requested to read and follow these instructions https://wiki.python.org/moin/GoogleGroupsPython " Yes, I read those instructions and found them fairly opaque. If you want to instruct "children" (odd that I find myself categorized that way on a CS forum, but whatever) then you use pictures. Seriously, it's not exactly clear what protocol GG users are expected follow to make posts hygenic. The standards I've used when creating this sort of content is to use screen shots with arrows and circles drawn in. If you're going to make an instruction page for some nuanced client feature, spend an extra 10 minutes and make it fully idiot proof. With re: the snark ... I am shocked, shocked to find snarky comments on the internet. (eyeroll) There was plenty of snark in this joint before I posted, good luck policing that. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
Paul Rubin said: "FYI, there is real though imprecise garbage collection for C. Web search for "Boehm garbage collection" should find more info" Very interesting. This wasn't around the last time I launched a C/C++ project from scratch. Thanks for the tip. I have to admit, off the top of my head I can't quite grok how it could possibly work which means I will learn something from studying it. But not right now. Thanks! Some great CS minds on this forum. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
Steven said - "In a very real sense, Python is "just" a convenience wrapper around a bunch of C functions to provide OOP idioms, garbage collection, dynamic typing, runtime introspection, exceptions, and similar. " I can't really disagree with you in a factual sense, but somehow it doesn't really convey the right flavor. The success or failure of a project (or an entire company) can rest on the correct choice of programming language. Whether you failed because you were pursuing an impossible task or merely a very, very, very hard one is sort of semantics, and cold comfort to the those affected. Maybe I'm biased because I'm walking away from a six figure job coding Java and C for a large company to write Python for a tiny non-profit. -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
Dave said : "Include a quote from whomever you're responding to, and we might actually take you seriously. And of course, make sure you don't delete the attribution. " This forum is working for me. One of the more frequent and sophisticated posters emailed me saying he appreciates my contributions. I'm sorry I'm putting in a bustle in your hedgerow (just a little bit sorry) but I've got 20 balls in the air right now and I haven't got around to configuring a proper client for this feed. The default Google Group client is notoriously cruddy with quotes attribution. Some readers can discern context from the previous posts. That's sort of what the word context means. But I understand this skill isn't universal. If it makes you feel better, I'm mostly lurking/learning and just posting on areas where I have expertise. Thanks for letting me off with a warning officer, I'll do better next time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On Monday, October 21, 2013 9:29:34 PM UTC-5, Steven D'Aprano wrote: > On Mon, 21 Oct 2013 01:43:52 -0700, Peter Cacioppi wrote: > > Challenge: give some examples of things which you can do in Python, but > cannot do *at all* in C, C++, C#, Java? Please. No exceptions is huge. No garbage collection is huge. But you can do anything with a Turing machine. You can do anything in assembly. The point is to pick the appropriate tool for the job. I can build a house without a nail gun. I can probably even build a house without a hammer. But it's a waste of time to build things with the wrong tools. -- https://mail.python.org/mailman/listinfo/python-list
Re: Re-raising a RuntimeError - good practice?
I'm surprised no-one is mentioning what seems the obvious pattern here - exception wrapping. So you define your exception class as containing the root exception. Then your specific job routines wrap the exceptions they encounter in your personal exception class. This is where you go add in specific information re: the circumstances under which the exception occurred. Then you throw your exception, which is captured at the appropriate level, and logged appropriately. The nice thing here is that you to tend to write all the exception logging in one place, instead of scattered all around. Your code looks very close to this pattern. Just raise an exception that can wrap the low level exception. -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
Angelico said: "Which is why I mentioned those helpful __future__ directives," OK, thanks, I'll study the __future__. I will port to 3.x in less than 60 months, or my name isn't Cacioppi. (So, in the worst case, I might have to backport a change to my name). -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
Chris The Angel said : "I won't flame you, but I will disagree with you :)" good, that's why I'm here ;) " but there are plenty of things you won't get - and the gap will widen with very Python release." Yes I skimmed that laundry list before deciding. I still think I made the right decision. I'll port it someday. I'll own the iPhone 5s (or whatever the latest one is) someday. I'm not an early adopter kind of person. I'd like to think my project (which looks like it is getting funding, hooray!) will advance the glory of Pythonistan simply by doing cool stuff with 2.7. I'll port it someday (unless it flops, which won't happen, because I won't let it). Good discussion though, thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
I said "Even Bill F*ng Gates was reluctant to break back compatibility," Reluctant to do so with his own stuff. Obviously he "embraced and extended" other peoples work. Don't get me started, Gates is Bizarro Guido. Good work with vaccines though. -- https://mail.python.org/mailman/listinfo/python-list
Re: Will Python 3.x ever become the actual standard?
It's an interesting issue. Back compatibility was broken with 3.x, which is always a risky move. Even Bill F*ng Gates was reluctant to break back compatibility, and he basically ruled the world (for about 20 minutes or so, but still). Moreover, you get a lot of the good stuff with 2.7. Along with more library support. So the smart decision is to code your project 2.7, even though the best thing for Pythonistan would be for us all to voluntarily migrate to 3.x. At least that's my read on it. Feel free to flame if I'm out of my depth here, it wouldn't be the first time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
rusi said : "You continue to not attribute quotes. " Sorry, I'll try to be better about this all-important aspect of sharing knowledge. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
"but it's "ugly", by which I mean it is hard to use, error prone, and not easily maintained." OK, I see the problem. What you call "ugly" is really just objectively bad. Ugliness and beauty are subjective qualities that can't really be debated on a deep level. Like I mentioned in other post, I find the lazy-evaluation idiom that avoids __init__ initialization of the stored value to be pretty, so I code it that way (in C#, in Java, in Python, even though the syntax is slightly different in each one). But I wouldn't say that using the __init__ (or the constructor) to initialize the lazy variable is "hard to use, error prone, not easily maintained". I would say it's ugly (or less pretty), and that it does seem to have some minor functional drawbacks. But I wouldn't make a big deal out of it if a colleague wanted to code it that way. Looking at Fortran, C, C++, C#, Java and Python (the languages I have done large bodies of work in, and, not coincidentally, some of the most popular languages ever, since I like to get paid and that requires going with the flow a little) it's easy to see that a lot of cosmetic things are maintained (i.e. foo.bar(), k += 1, etc) but some important, conceptual things are improved in profound ways. So a colleague that was advocating coding a project in C when Python would work ... yeah, that's a deal breaker, we're going to lock horns over that. I wasn't going to ramble on like this but I think you, Stephen, were the one encouraging me to step into the flames. -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
Just because the CPython implementation does something doesn't mean that thing is something other than risky/tricky/to-be-avoided-if-possible. Python (and it's implementations) exist so that ordinary people can avoid doing risky stuff. I'm not critiquing the CPython implementation here, I'm pointing out that some languages are just better than others for most projects. Working in a higher level where gotos aren't needed is the right call most of the time. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
Specifically the following seems so misguided as to be deliberate trolling. "One of the reasons multiple languages exist is because people find that useful programming idioms and styles are *hard to use* or "ugly" in some languages, so they create new languages with different syntax to make those useful patterns easier to use." This is just profoundly wrong. If anything, different languages strive to maintain common syntax. You can see foo.bar() as legal syntax meaning essentially the same thing in C++, C#, Java and Python (and likely quite a few other languages). There is NOT a deliberate effort to create new syntax just for aesthetics, there is the exact opposite. There is a deliberate effort to maintain consistency with the syntax of pre-existing languages. Languages sprout up for a variety of reasons. C++ has very significant functionality that doesn't exist in C. Java/C# can say the same thing to C++, and Python to all of the others. Please lets not pretend that it's all just ballpark equivalent facades plastered on top of a Turing machine. New languages pop up to automate boring and repetitive tasks that chew up your time in older languages. That's the trend - abstractions automating repetitious and error-prone tasks. Not "hey, this syntax isn't too my taste, I'm going to toodle it up". -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
I've written a fair bit of code in pure C, C++, C#, Java and now getting there in Python. The difference between C# and Java is fairly minor. The others have large and significant differences between them. Garbage collectors or not is huge. Exceptions or not is huge. Dynamic or static typing is huge. Language support for polymorphism or not is huge. C code invokes a very meaningful overhead of memory management. The task of insuring that memory doesn't leak here is far larger than in garbage collected languages, and much more difficult than C++ (which can guarantee stack based destruction). This is just one language feature. I could go on and on. The idea that the differences between these languages is just syntactic sugar and aesthetics is so profoundly misguided that I can only assume that this misconception was proposed as a bizarre form of trolling. -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
That sound you hear is Roy Smith hitting the nail on the head. -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
That sound you here is Roy Smith hitting the nail on the head re: C++ and Scott Meyers. -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
At the risk of sounding like a fogey, I actually think I did, at one time, know the distinctions between "our projects protocol" and "the language proper" for C++. I read Scott Meyers books on C++ and STL a couple of times each and helped design the protocol that kept us reasonably safe. But this was all a long time ago, and those parts of my RAM are now storing Breaking Bad plot twists and the nuances of the Federer or Nadal debate. -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
> You certainly don't have to write a constructor for a subclass in C++. Ahh, this message board is so collectively well informed (once you get past the trolls) The C++ project I worked on was religious about always overwriting parent class constructors. I had assumed this was because the language proper forbid it, but apparently it was just project protocol. Thanks again! -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
> Why not simply have one, and use it to initialize your attributes, > even if it is to None? Think about it this way. None here really means "not yet initialized". It is a value that cannot occur naturally and thus functions as a not-initialized flag. But for different contexts, this value could be almost anything. It might even be truthy. So this, somewhat arbitrary, context sensitive value should be isolated as much as possible. You don't want it popping up hither and yon, you want to type as infrequently as possible and localized it to as few methods as possible. For example, look at this version of the idiom class Foo (Bar) : def foo(self, x) : if (getattr(self, "_lazy", -1) < 0 ) : self._lazy = self._count_something(x) assert (self._lazy >= 0) # a negative count is a bug not a bad data entry def count_something(self, x) : # if it's really counting something, it will return a natural number Now you really want that -1 in an __init__ method instead of the foo method? Isn't that asking for trouble when somebody copies this and rewrites it? They could change the boolean expressions in foo (i.e. < 0 means compute it, >= sanity checks the result) but fail to change the proper flag for not-yet-computed (-1) if these things are in two different methods. My way, it's all in one place. Good little idiom to ponder though. I like fussing over these things. Any good gambler develops clean habits to improve his odds, even if each act of hygiene changes the odds but slightly. I wouldn't complain if a co-worker coded this your way, but I still think it is cleaner my way. -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
>The use of getattr here seems unfortunate Unfortunate how? It's a perfect for what I want here ... remember the context is such that the lazily stored value is always truthy (I assert this elsewhere). > I'm not sure why you want to avoid an __init__ method. Why do you want to keep it? The more code you write the more bugs you write. Who knows, maybe I screw up the argument pass to the super __init__. Maybe I screw up the super reference. Didn't Einstein say make it as simple as possible, but no simpler? Personally, I find the ability of Python to subclass without overriding the constructor very elegant. I don't believe the other languages I've worked in can do this (C++, C#, Java)... or if there is a way it's a bit scary and discouraged. Whereas skipping the __init__ seems to be a standard part of the Python OO development process. Again, this is just the lazy eval pattern. In C#, for example, I'd write my constructors but refer to _lazy only in the foo function and in it's declaration line (which would explicitly default initialize it). At any rate, the second idiom is very pretty to me, I'm keeping it unless a compelling argument is presented. Thanks for the kibbutzing though, the first idiom was poor form, as I suspected. -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
To be clear, my original post had a goof. So my original, de-goofed, idiom was class Foo (object) : _lazy = None def foo(self, x) : self._lazy = self._lazy or self.get_something(x) def get_something(self, x) : # doesn't really matter, so long as it returns truthy result and the new, improved idiom is class Foo (object) : def foo(self, x) : self._lazy = getattr(self, "_lazy", None) or self._get_something(x) def _get_something(self, x) : # doesn't really matter, so long as it returns truthy result I was laboring under some misconception that there was Python magic that allowed __init__ and only __init__ to add class attributes by setting their values. Good to know this piece of magic isn't part of Python, and thus lazy eval can be handled more cleanly than I originally thought. In other words, "Guido was here". Thanks again -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
Yes, I see the light now. My idiom works, but Steven has shown me the droids I am looking for. Thanks! -- https://mail.python.org/mailman/listinfo/python-list
Re: skipping __init__ and using exploiting a class member instead
On Saturday, October 19, 2013 2:44:55 PM UTC-7, Peter Cacioppi wrote: > Is the following considered poor Python form? > > > > class Foo (object) : > > _lazy = None > > def foo(self, x) : > > _lazy = _lazy or self.get_something(x) > > def get_something(self, x) : > > # doesn't really matter > > > > I like this idiom for certain situations, just wondering if it will raise the > hackles of other Pythonistas. > > > > I use this idiom sparingly, but sometimes it just fits the task at hand, I > hear Guidos voice saying "use the Force" in my ear, etc. To be clear, I use this when I'm subclassing something and don't need to do anything with the _lazy other than set it to None in the __init__. I like this idiom because it removes the risk of miscalling the parent __init__, and it's also quick and easy to code. Yes there is a class member I am creating, but each instance has a distinct member. (In other words, I'm an adult, I tested it and it works, but I couldn't find anything in the Google indicating what the collective reaction would be from Pythonistan) -- https://mail.python.org/mailman/listinfo/python-list
skipping __init__ and using exploiting a class member instead
Is the following considered poor Python form? class Foo (object) : _lazy = None def foo(self, x) : _lazy = _lazy or self.get_something(x) def get_something(self, x) : # doesn't really matter I like this idiom for certain situations, just wondering if it will raise the hackles of other Pythonistas. I use this idiom sparingly, but sometimes it just fits the task at hand, I hear Guidos voice saying "use the Force" in my ear, etc. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
> give me practicality beats purity any day of the week :) Without some notion of theory you will end up with php instead of python (see how I looped the thread back around on track ... you're welcome). If you think php is no worse than python for building reliable, readable code bases than god love you. Readability is huge for allowing efficient team development of larger projects, and readability flows from these sort of discussions. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
> I think the author goes a little too far to claim that "strong" > "weak" are meaningless terms when it comes to type systems I can live with that, actually. The important language classifications are more along the lines of static vs. dynamic typing, procedural vs. functional, no objects vs. object based vs. true OO. That probably starts another flame war, but this thread is already running around with its hair on fire. I still say that object-based is a distinct and meaningful subset of object-oriented programming. The former can be implemented elegantly in a wide range of languages without much in the way of specific language support, the latter needs to designed into the language to allow a modicum of polymorhpic readability. It's an important distinction, because a project that is constrained to C should (IMHO) target an object-based design pattern but not an object-oriented one. That said, I'm open to disputation-by-example on this point, provided the example is reasonably small and pretty. (If the only polymorphic C code is ugly and non-small, it sort of proves my point). -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
yes it was a joke, apparently not a good one On Thu, Oct 17, 2013 at 5:39 PM, Skip Montanaro wrote: > > On Oct 17, 2013 6:59 PM, "Peter Cacioppi" > wrote: > > > > You know, I'd heard somewhere that Goto was considered harmful > trying to remember exactly where > > I can't tell if you were kidding or not... Just in case: > > http://en.m.wikipedia.org/wiki/Considered_harmful > > (can't grab the [2] & [3] links on my phone) > > Skip > -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
Cmon, Skip, assuming everyone gets the "considered harmful" reference falls under the "we're all adults here" rubric. -- https://mail.python.org/mailman/listinfo/python-list
Re: Possibly better loop construct, also labels+goto important and on the fly compiler idea.
You know, I'd heard somewhere that Goto was considered harmful trying to remember exactly where -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
My bad, Python is dynamically typed, but also strongly typed. But I still say it has language features that specifically support polymorphism, which is why true OO can be developed in Python in a readable way. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
> The first C++ compilers were just preprocessors that translated into > pure C code ... I agree with this. > the C code was reasonably clear, not really convoluted, so you would have > been able to write it yourself. I disagree with this. My sense of C is that IF you are relying on preprocessors to do sophisticated things, THEN you are not writing clear C code. The implementations I've seen of polymorphism-of-structs in C are quite ugly to my eyes, and make me grateful C++ was invented. OTOH, I've seen object-based C development projects (I.e. where you could tell what function was being called at compile time) that are quite readable. It requires coding discipline (as does readability in any language). We might just be arguing over the definition of "readable" here. I have been told that my standards of readable are unreasonable, so perhaps I'm in the wrong here. That said, I'm just glad true OO languages exist, especially Python. All hail Guido. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
> What you've said here is that "without polymorphism, you can't have > polymorphism". :) Respectfully, no. I refer to the distinction between object based and object oriented programming. Wikipedia's entry is consistent with my understanding (not to argue by wiki-authority, but the terminology here isn't my personal invention). Your example of "polymorphism in a non OO" language makes my tired head hurt. Do you have a clean little example of polymorphism being mocked in a reasonable way with pure C? There are many nice object-based C projects floating around, but real polymorphism? I think you can't do it without some bizarre work-arounds, but I'd be happy to be shown otherwise. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
I don't know if I want to step into the flames here, but my understanding has always been that in the absence of polymorphism the best you can do is "object based" programming instead of "object oriented" programming. Object based programming is a powerful step forward. The insight that by associating data structures and methods together you can significantly improve readability and robustness. Object oriented programming takes things further, most significantly by introducing the idea that the object reference you are referencing might be a run time dependent sub-class. Even Python, which isn't strongly typed, manages polymorphism by allowing the self argument to a sub-class of the method class. There are many wonderful examples of object based programming in C. I believe VB (not VB.net, the older VBA language) is object based but not object oriented. True object oriented programming seems to require proper support from the language itself, because the run-time resolution of the "this/self" reference needs specific constructs in the language. Bear in mind that my usual disclaimer when wading into the flames like this is to quote Randy Newman ... "I may be wrong but I don't think so!!" -- https://mail.python.org/mailman/listinfo/python-list
Re: How pickle helps in reading huge files?
On Tuesday, October 15, 2013 11:55:26 PM UTC-7, Harsh Jha wrote: > I've a huge csv file and I want to read stuff from it again and again. Is it > useful to pickle it and keep and then unpickle it whenever I need to use that > data? Is it faster that accessing that file simply by opening it again and > again? Please explain, why? > > > > Thank you. Surprising no-one else mentioned a fairly typical pattern for this sort of situation - the compromise between "read from disk" and "read from memory" is "implement a cache". I've had lots of good experiences hand rolling simple caches, especially if there is an application specific access pattern. Python has nice implementations of things like tuple and dictionary which make caching fairly easy compared to other languages. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
> only I'm focusing on the importance of design rather than deifying > the person who designed it. I'm cool with deification here. I'll happily get on my knees and bow towards Holland while chanting "Guido ... I'm not worthy" 5 times a day, if that's part of the cult. Want an odd and ranty thread this one turned into. I think Python is awesome. For me, it literally inspires awe. If you don't agree, and yet you're working in Python anyway, I kind of feel bad for you, just a little. Cheers and thanks again. -- https://mail.python.org/mailman/listinfo/python-list
when to use __new__, when to use __init__
I've dome some reading on the difference between __new__ and __init__, and never really groked it. I just followed the advice that you should almost always use __init__. I recently came across a task that required using __new__ and not __init__. I was a bit intimidated at first, but it was quick and easy. This simple programming exercise really cleared a lot of things up for me. Not to be immodest, but I think something like this ought to be the canonical example for explaining when/how to override __new__. The task? I want to make a class that behaves exactly like a tuple, except changing the constructor argument signature and adding some extra methods. An example should clarify what I needed. > x = ParetoTuple(1, 2, 0) > x[1] >> 2 > len(x) >> 3 > 2 in x >> True > -1 in x >> False > x.dominates(ParetoTuple(1, 3, 0)) >> True > x.equivalent(ParetoTuple(1, 2 + 1e-5, 0)) >> True etc. Since I want the constructor to take an (almost) arbitrary number of arguments, each of which will be elements of the resulting ParetoTuple, I need to override __new__. I don't need to overwrite __init__, because the tuple.__new__ will populate it's data when the arguments are properly formatted. Also, since the world of Pareto comparisons makes sense only with 2 or more goals, I want my specialized constructor to take at least 2 arguments in a natural way. Here is the code class ParetoTuple(tuple) : def __new__ (cls, obj1, obj2, *rest): return super(ParetoTuple, cls).__new__(cls, (obj1, obj2) + rest) # nothing special about the dominates, equivalents methods... # no __init__ needed I understand some people argue in favor of using a factory pattern for this sort of situation, but I disagree. I think the cognitive overhead of factories requires a more complicated task than re-signaturing the constructor method. At any rate, hope it helps others like it helped me. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python was designed (was Re: Multi-threading in Python vs Java)
On Saturday, October 12, 2013 3:37:58 PM UTC-7, Chris Angelico wrote:
> On Sat, Oct 12, 2013 at 7:10 AM, Peter Cacioppi
>
> wrote:
>
> > Along with "batteries included" and "we're all adults", I think Python
> > needs a pithy phrase summarizing how well thought out it is. That is to
> > say, the major design decisions were all carefully considered, and as a
> > result things that might appear to be problematic are actually not barriers
> > in practice. My suggestion for this phrase is "Guido was here".
>
>
>
> "Designed".
>
>
>
> You simply can't get a good clean design if you just let it grow by
>
> itself, one feature at a time. You'll end up with something where you
>
> can do the same sort of thing in three different ways, and they all
>
> have slightly different names:
>
>
>
> http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/#general
>
>
>
> (Note, I'm not here to say that PHP is awful and Python is awesome
>
> (they are, but I'm not here to say it). It's just that I can point to
>
> a blog post that shows what I'm saying.)
>
>
>
> Design is why, for instance, Python's builtin types all behave the
>
> same way with regard to in-place mutator methods: they don't return
>
> self. I personally happen to quite like the "return self" style, as it
>
> allows code like this:
>
>
>
> GTK2.MenuBar()
>
> ->add(GTK2.MenuItem("_File")->set_submenu(GTK2.Menu()
>
> ->add(menuitem("_New Tab",addtab)->add_accelerator(...))
>
> ->add(menuitem("Close tab",closetab)->add_accelerator(...))
>
> ... etc ...
>
> ))
>
> ->add(GTK2.MenuItem("_Options")->set_submenu(GTK2.Menu()
>
> ->add(menuitem("_Font",fontdlg))
>
> ... etc ...
>
> ))
>
> ... etc ...
>
>
>
> It's a single expression (this is from Pike, semantically similar to
>
> Python) that creates and sets up the whole menu bar. Most of Pike's
>
> object methods will return this (aka self) if it's believed to be of
>
> use. The Python equivalent, since the .add() method on GTK objects
>
> returns None, is a pile of code with temporary names. But that's a
>
> smallish point of utility against a large point of consistency;
>
> newbies can trust that a line like:
>
>
>
> lst = lst.sort()
>
>
>
> will trip them up immediately (since lst is now None), rather than
>
> surprise them later when they try to make a sorted copy of the list:
>
>
>
> sorted_lst = lst.sort()
>
>
>
> which, if list.sort returned self, would leave you with sorted_lst is
>
> lst, almost certainly not what the programmer intended.
>
>
>
> Oh, and the use of exceptions everywhere is a sign of design, too.
>
> Something went wrong that means you can't return a plausible value?
>
> Raise.
>
>
>
> >>> json.loads("{")
>
> ValueError: Expecting object: line 1 column 0 (char 0)
>
>
>
> >>> pickle.loads(b"\x80")
>
> EOFError
>
>
>
> Etcetera. PHP borrows from C in having piles and piles of "was there
>
> an error" functions; there's no consistency in naming, nor (in many
>
> cases) in the return values. Pike generally raises exceptions, but I/O
>
> failure usually results in a zero return and the file object's errno
>
> attribute set; but at least they're consistent error codes.
>
>
>
> This is design. Python has a king (Guido). It wasn't built by a
>
> committee. Maybe you won't like some aspect of Python's design, but it
>
> has one, it's not just sloppily slapped together.
>
>
>
> ChrisA
So Python was designed reasonably well, with a minimum of hacky-screw-ups. This
happened because Python's growth was effectively managed by an individual who
was well suited to the task. In other words, "Guido was here".
Good thread, I learned a lot from it, thanks.
--
https://mail.python.org/mailman/listinfo/python-list
Re: closure = decorator?
On Thursday, October 10, 2013 6:51:21 AM UTC-7, Tim wrote: > I've read a couple of articles about this, but still not sure. > > When someone talks about a closure in another language (I'm learning Lua on > the side), is that the same concept as a decorator in Python? > > > > It sure looks like it. > > thanks, > > --Tim In the proper lambda calculus, you don't have side effects. So Terry's balance example is helpful for Python, but perhaps it might be better think of it as a Pythonic extension to the lambda calculus closure. In other words, Python's closure handles cases that don't present themselves in the lambda calculus. When you are taught about closures in a purely formal setting the example will not include a side effect nor any need for a statement like "nonlocal balance". The closed variable (here it is balance) simply remains part of the scope of the inner function and can referenced appropriately. This might distract the original questioner, I only mention that "closure" probably means different things to different people. -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-threading in Python vs Java
On Thursday, October 10, 2013 11:01:25 PM UTC-7, Peter Cacioppi wrote: > Could someone give me a brief thumbnail sketch of the difference between > multi-threaded programming in Java. > > > > I have a fairly sophisticated algorithm that I developed as both a single > threaded and multi-threaded Java application. The multi-threading port was > fairly simple, partly because Java has a rich library of thread safe data > structures (Atomic Integer, Blocking Queue, Priority Blocking Queue, etc). > > > > There is quite a significant performance improvement when multithreading here. > > > > I'd like to port the project to Python, partly because Python is a better > language (IMHO) and partly because Python plays well with Amazon Web > Services. > > > > But I'm a little leery that things like the Global Interpret Lock will block > the multithreading efficiency, or that a relative lack of concurrent off the > shelf data structures will make things much harder. > > > > Any advice much appreciated. Thanks. "Sounds like Python will serve you just fine! Check out the threading module, knock together a quick test, and spin it up!" Thanks, that was my assessment as well, just wanted a double check. At the time of posting I was mentally blocked on how to set up a quick proof of concept, but of course writing the post cleared that up ;) Along with "batteries included" and "we're all adults", I think Python needs a pithy phrase summarizing how well thought out it is. That is to say, the major design decisions were all carefully considered, and as a result things that might appear to be problematic are actually not barriers in practice. My suggestion for this phrase is "Guido was here". So in this case, I thought the GIL would be a fly in the ointment, but on reflection it turned out not to be the case. Guido was here. -- https://mail.python.org/mailman/listinfo/python-list
Re: Multi-threading in Python vs Java
On Thursday, October 10, 2013 11:01:25 PM UTC-7, Peter Cacioppi wrote: > Could someone give me a brief thumbnail sketch of the difference between > multi-threaded programming in Java. > > > > I have a fairly sophisticated algorithm that I developed as both a single > threaded and multi-threaded Java application. The multi-threading port was > fairly simple, partly because Java has a rich library of thread safe data > structures (Atomic Integer, Blocking Queue, Priority Blocking Queue, etc). > > > > There is quite a significant performance improvement when multithreading here. > > > > I'd like to port the project to Python, partly because Python is a better > language (IMHO) and partly because Python plays well with Amazon Web > Services. > > > > But I'm a little leery that things like the Global Interpret Lock will block > the multithreading efficiency, or that a relative lack of concurrent off the > shelf data structures will make things much harder. > > > > Any advice much appreciated. Thanks. I should add that the computational heavy lifting is done in a third party library. So a worker thread looks roughly like this (there is a subtle race condition I'm glossing over). while len(jobs) : job = jobs.pop() model = Model(job) # Model is py interface for a lib written in C newJobs = model.solve() # This will take a long time for each newJob in newJobs : jobs.add(newJob) Here jobs is a thread safe object that is shared across each worker thread. It holds a priority queue of jobs that can be solved in parallel. Model is a py class that provides the API to a 3rd party library written in C.I know model.solve() will be the bottleneck operation for all but trivial problems. So, my hope is that the GIL restrictions won't be problematic here. That is to say, I don't need **Python** code to ever run concurrently. I just need Python to allow a different Python worker thread to execute when all the other worker threads are blocking on the model.solve() task. Once the algorithm is in full swing, it is typical for all the worker threads should be blocking on model.Solve() at the same time. It's a nice algorithm for high level languages. Java worked well here, I'm hoping py can be nearly as fast with a much more elegant and readable code. -- https://mail.python.org/mailman/listinfo/python-list
Multi-threading in Python vs Java
Could someone give me a brief thumbnail sketch of the difference between multi-threaded programming in Java. I have a fairly sophisticated algorithm that I developed as both a single threaded and multi-threaded Java application. The multi-threading port was fairly simple, partly because Java has a rich library of thread safe data structures (Atomic Integer, Blocking Queue, Priority Blocking Queue, etc). There is quite a significant performance improvement when multithreading here. I'd like to port the project to Python, partly because Python is a better language (IMHO) and partly because Python plays well with Amazon Web Services. But I'm a little leery that things like the Global Interpret Lock will block the multithreading efficiency, or that a relative lack of concurrent off the shelf data structures will make things much harder. Any advice much appreciated. Thanks. -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's and and Pythons or
On Wednesday, October 9, 2013 4:54:03 PM UTC-7, Peter Cacioppi wrote: > I really like the logic that Pythons "or" is not only short-circuit but > non-typed. > > > > So I can say > > > > y = override or default > > > > and y won't necc be True or False. If override boolean evaluates to True > (which, for most classes, means not None) than y will be equal to override. > Otherwise it will be equal to default. > > > > I have two questions > > --> Is there a handy name for this type of conditional (something as catchy > as "short circuit or") > > > > and > > > > --> Is there a common idiom for taking advantage of the similar behavior of > "and". The "override or default" just makes me grin every time I use it. > > > > Thanks So you can wrap it all up in one big example y = (overrideprovider and overrideprovdider() ) or default echo-argument and/or is a beautiful thing -- https://mail.python.org/mailman/listinfo/python-list
Re: Python's and and Pythons or
On Wednesday, October 9, 2013 4:54:03 PM UTC-7, Peter Cacioppi wrote: > I really like the logic that Pythons "or" is not only short-circuit but > non-typed. > > > > So I can say > > > > y = override or default > > > > and y won't necc be True or False. If override boolean evaluates to True > (which, for most classes, means not None) than y will be equal to override. > Otherwise it will be equal to default. > > > > I have two questions > > --> Is there a handy name for this type of conditional (something as catchy > as "short circuit or") > > > > and > > > > --> Is there a common idiom for taking advantage of the similar behavior of > "and". The "override or default" just makes me grin every time I use it. > > > > Thanks ok, since someone asked, I suggest we call the "return it's arguments" behavior "echo-argument". That is to say, the reason we can write y = override or default is because Python implements echo-argument or. That is to say, "or" doesn't necc return True or False, "or" returns the first "truthy" argument it encounters. "and" behaves similarly, in that it returns the first "falsey" argument it encounters. I'm trying to think of a good example usage of echo-argument and. Maybe something like possible = foo and foo.allowsit() if (possible is None) : print "foo not provided" if (possible is False) : print "foo doesn't allow it" A bit awkward, echo-argument or is more naturally useful to me then echo-argument and. -- https://mail.python.org/mailman/listinfo/python-list
Python's and and Pythons or
I really like the logic that Pythons "or" is not only short-circuit but non-typed. So I can say y = override or default and y won't necc be True or False. If override boolean evaluates to True (which, for most classes, means not None) than y will be equal to override. Otherwise it will be equal to default. I have two questions --> Is there a handy name for this type of conditional (something as catchy as "short circuit or") and --> Is there a common idiom for taking advantage of the similar behavior of "and". The "override or default" just makes me grin every time I use it. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Variable arguments (*args, **kwargs): seeking elegance
On Saturday, October 5, 2013 9:04:25 PM UTC-7, John Ladasky wrote: > Hi folks, > > > > I'm trying to make some of Python class definitions behave like the ones I > find in professional packages, such as Matplotlib. A Matplotlib class can > often have a very large number of arguments -- some of which may be optional, > some of which will assume default values if the user does not override them, > etc. > > > > I have working code which does this kind of thing. I define required > arguments and their default values as a class attribute, in an OrderedDict, > so that I can match up defaults, in order, with *args. I'm using > set.issuperset() to see if an argument passed in **kwargs conflicts with one > which was passed in *args. I use set.isdisjoint() to look for arguments in > **kwargs which are not expected by the class definition, raising an error if > such arguments are found. > > > > Even though my code works, I'm finding it to be a bit clunky. And now, I'm > writing a new class which has subclasses, and so actually keeps the "extra" > kwargs instead of raising an error... This is causing me to re-evaluate my > original code. > > > > It also leads me to ask: is there a CLEAN and BROADLY-APPLICABLE way for > handling the *args/**kwargs/default values shuffle that I can study? Or is > this sort of thing too idiosyncratic for there to be a general method? > > > > Thanks for any pointers! "One thought -- often, people turn to subclassing as the only tool in their toolbox. Have you considered that it may be easier/better to work with delegation and composition instead? " Double like. Subclassing is awesome when it is used properly ... which usually means used cautiously. Delegation/composition just doesn't result in the some sort of weird gotchas. -- https://mail.python.org/mailman/listinfo/python-list
Re: Variable arguments (*args, **kwargs): seeking elegance
On Saturday, October 5, 2013 9:04:25 PM UTC-7, John Ladasky wrote: > Hi folks, > > > > I'm trying to make some of Python class definitions behave like the ones I > find in professional packages, such as Matplotlib. A Matplotlib class can > often have a very large number of arguments -- some of which may be optional, > some of which will assume default values if the user does not override them, > etc. > > > > I have working code which does this kind of thing. I define required > arguments and their default values as a class attribute, in an OrderedDict, > so that I can match up defaults, in order, with *args. I'm using > set.issuperset() to see if an argument passed in **kwargs conflicts with one > which was passed in *args. I use set.isdisjoint() to look for arguments in > **kwargs which are not expected by the class definition, raising an error if > such arguments are found. > > > > Even though my code works, I'm finding it to be a bit clunky. And now, I'm > writing a new class which has subclasses, and so actually keeps the "extra" > kwargs instead of raising an error... This is causing me to re-evaluate my > original code. > > > > It also leads me to ask: is there a CLEAN and BROADLY-APPLICABLE way for > handling the *args/**kwargs/default values shuffle that I can study? Or is > this sort of thing too idiosyncratic for there to be a general method? > > > > Thanks for any pointers! "Subclassing ndarray can get a bit complicated" Another software pattern idea is "encapsulate don't inherit". When a class is really messy to subclass, start fresh with a new class that wraps the messy class. Create redirect methods for whatever is needed, then subclass from the class you created. In fact, I'd go so far as to say you should only subclass from classes that were designed with subclassing in mind. If you find yourself bending over backwards to make subclassing work, it means you should be wrapping and redirecting instead. This is perhaps more true in C#/Java than Python, but still something to think about. -- https://mail.python.org/mailman/listinfo/python-list
Re: Variable arguments (*args, **kwargs): seeking elegance
On Saturday, October 5, 2013 9:04:25 PM UTC-7, John Ladasky wrote: > Hi folks, > > > > I'm trying to make some of Python class definitions behave like the ones I > find in professional packages, such as Matplotlib. A Matplotlib class can > often have a very large number of arguments -- some of which may be optional, > some of which will assume default values if the user does not override them, > etc. > > > > I have working code which does this kind of thing. I define required > arguments and their default values as a class attribute, in an OrderedDict, > so that I can match up defaults, in order, with *args. I'm using > set.issuperset() to see if an argument passed in **kwargs conflicts with one > which was passed in *args. I use set.isdisjoint() to look for arguments in > **kwargs which are not expected by the class definition, raising an error if > such arguments are found. > > > > Even though my code works, I'm finding it to be a bit clunky. And now, I'm > writing a new class which has subclasses, and so actually keeps the "extra" > kwargs instead of raising an error... This is causing me to re-evaluate my > original code. > > > > It also leads me to ask: is there a CLEAN and BROADLY-APPLICABLE way for > handling the *args/**kwargs/default values shuffle that I can study? Or is > this sort of thing too idiosyncratic for there to be a general method? > > > > Thanks for any pointers! Elegance is a matter of taste, but here is one pattern. I tend to think that a very long argument lists are either the result of poor design or an indication that readability would benefit from some sort of dedicated, featherweight "parameter" or "builder" object. The builder object is mutable and copied by any functions that consume it. To my mind, a nice pattern can be as follows. --> Class A is a worker class --> Class B is a worker-builder (or worker-parameter). --> You build B first -->--> usually by first calling a constructor with few to no arguments and then by setting specific properties of B. --> You pass B to the constructor of A, which copies the data over to control the mutability of A. --> A has a getter code that returns a copy of it's saved, private B data, so that you can "remember" later on how it was built. The other point, perhaps more Pythonic, idea here is to exploit this language feature of Python 3 to force argument naming. This would be nice if typical usage involved many possible arguments but only a small number of passed arguments in the typical usage. http://stackoverflow.com/questions/2965271/forced-naming-of-parameters-in-python -- https://mail.python.org/mailman/listinfo/python-list
Re: Understanding how is a function evaluated using recursion
On Thursday, September 26, 2013 7:23:47 AM UTC-7, Neil Cerutti wrote: > On 2013-09-26, Neil Cerutti wrote: > > > def flatten(seq): > > > > > > [1] http://en.wiktionary.org/wiki/bikeshed > > > > In that spirit, it occurs to me that given current Python > > nomenclature, 'flattened' would be a better name. > > > > -- > > Neil Cerutti The example presented here is simple enough for someone who is confident with recursion and somewhat new to Python. So perhaps a refresher on recursion would help. The way to grok recursion for the first time is (a) to read some general info about it (Wikipedia has some decent stuff here, but there are many other sources) and (b) find a simple recursion example and play around with it in the debugger. Python has some decent debugger solutions - I like using ipdb with iPython. The factorial function is a good one to play around with if you're new to recursion. The Fibonacci sequence is also good. Find a .py example, or, better yet, write your own based on psuedo code. If you're a recursion expert already, then I don't know what to tell you other than Python seems to have implemented recursion faithfully and there are no gotchas that I can see. -- https://mail.python.org/mailman/listinfo/python-list
Re: reload and work flow suggestions
On Saturday, September 21, 2013 2:43:13 PM UTC-7, Peter Cacioppi wrote: > This is an idea brought over from another post. > > > > When I write Python code I generally have 2 or 3 windows open simultaneously. > > > > 1) An editor for the actual code. > > 2) The interactive interpreter. > > 3) An editor for the unit tests. (Sometimes skipped for quick one-off scripts) > > > > My work flow tends to involve using 2 to debug the issues that come up with 1 > and 3. I'll write some new code in 1, play around with it in 2, then solidify > the tests in 3. Or a test in 3 fails and I dig around with it using 2. > > > > My problem is that I tend to use reload() quite a bit. I want to call > functions and construct objects that are inside the guts of 1 and pass them > arguments that are stored as variables in 2. If I restart my session for 2 I > lose these variables (iPython does mitigate the pain here somewhat). Hence, I > reload() modules into 2 when they are changed. > > > > I use ipdb a lot in 2. I usually don't feel comfortable with virgin code or a > debug fix that hasn't been stepped through with the debugger. > > > > Is there something wrong with this work flow? I understand most python > experts avoid reload(). So what are they doing that I'm not? I love the > ability of Python to quickly let you dive deep into your code and set up a > difficult case with 2, it's hard to imagine giving this up, and it's hard to > imagine using it without reload(). > > > > Thanks for any tips. So when I say I exploit the intellisense of iPython, it's simply this. I have a "working on X" script that has some handy variables and runs whatever is currently of interest in the functional code or the units tests. It even launches into the ipdb debugger, if needed. The "working on X" is kept in the scripts directory of iPython. The older "working on Y" scripts are renamed to "not working on Y", so that there is only one script in that particular directory that starts with "wo". When iPython launches, I just type run wo [tab] and it completes the file name. So the whole "proxy for reload" process is actually pretty quick. For me it's faster than what I used to do with reload(), plus the "working on" script keeps a nice record of where I was in a debugging/experiment process. iPython makes it easy to create history dumps which can then be selectively copied over to the "working on" if I forget what was useful. At any rate, it sounds like emacs plays very well with python and iPython, not disparaging the utility of emacs kung fu. But if you want to use a different editor (I use idle for editing), and also use iPython for interactivity (which is very slick), this workflow works nice for me and might be helpful to you. Cheers -- https://mail.python.org/mailman/listinfo/python-list
Re: reload and work flow suggestions
On Saturday, September 21, 2013 2:43:13 PM UTC-7, Peter Cacioppi wrote: > This is an idea brought over from another post. > > > > When I write Python code I generally have 2 or 3 windows open simultaneously. > > > > 1) An editor for the actual code. > > 2) The interactive interpreter. > > 3) An editor for the unit tests. (Sometimes skipped for quick one-off scripts) > > > > My work flow tends to involve using 2 to debug the issues that come up with 1 > and 3. I'll write some new code in 1, play around with it in 2, then solidify > the tests in 3. Or a test in 3 fails and I dig around with it using 2. > > > > My problem is that I tend to use reload() quite a bit. I want to call > functions and construct objects that are inside the guts of 1 and pass them > arguments that are stored as variables in 2. If I restart my session for 2 I > lose these variables (iPython does mitigate the pain here somewhat). Hence, I > reload() modules into 2 when they are changed. > > > > I use ipdb a lot in 2. I usually don't feel comfortable with virgin code or a > debug fix that hasn't been stepped through with the debugger. > > > > Is there something wrong with this work flow? I understand most python > experts avoid reload(). So what are they doing that I'm not? I love the > ability of Python to quickly let you dive deep into your code and set up a > difficult case with 2, it's hard to imagine giving this up, and it's hard to > imagine using it without reload(). > > > > Thanks for any tips. Thanks for the tips guys. One thing re: editors and interactive environments. I'm not a huge emacs fan (ducking) and I really like iPython. In order to avoid calling reload, I've changed my workflow to the following. 1) The "real" code 2) The unit tests 3) A scratch script Then, I launch iPython, which can intellisense launch 3 easily. Then I make whatever changes I need to 1-3 to make a baby step forward, close iPython, and repeat. This seems to preserve the easy-to-dive-into, play-around-with-it fun that is Python without forcing me to call reload(). I suspect I'm now a bit more close to what the "experts" are doing. Thanks again, I love kibbutzing about work-flow, toys, etc. -- https://mail.python.org/mailman/listinfo/python-list
reload and work flow suggestions
This is an idea brought over from another post. When I write Python code I generally have 2 or 3 windows open simultaneously. 1) An editor for the actual code. 2) The interactive interpreter. 3) An editor for the unit tests. (Sometimes skipped for quick one-off scripts) My work flow tends to involve using 2 to debug the issues that come up with 1 and 3. I'll write some new code in 1, play around with it in 2, then solidify the tests in 3. Or a test in 3 fails and I dig around with it using 2. My problem is that I tend to use reload() quite a bit. I want to call functions and construct objects that are inside the guts of 1 and pass them arguments that are stored as variables in 2. If I restart my session for 2 I lose these variables (iPython does mitigate the pain here somewhat). Hence, I reload() modules into 2 when they are changed. I use ipdb a lot in 2. I usually don't feel comfortable with virgin code or a debug fix that hasn't been stepped through with the debugger. Is there something wrong with this work flow? I understand most python experts avoid reload(). So what are they doing that I'm not? I love the ability of Python to quickly let you dive deep into your code and set up a difficult case with 2, it's hard to imagine giving this up, and it's hard to imagine using it without reload(). Thanks for any tips. -- https://mail.python.org/mailman/listinfo/python-list
Re: mutlifile inheritance problem
On Thursday, March 21, 2002 2:03:23 PM UTC-7, Marc wrote: > I have classes defined in different files and would like to inherit > from a class in file A.py for a class in file B.py but am running into > problems. I'm using Python 1.5.2 on Windows NT > > Here's a specific example: > > > file cbase01.py: > > class CBase: > > def __init__(self): > self.cclass = None > print "cbase" > > class CImStream(CBase): > > def __init(self): > CBase.__init__(self) > print "CImStream" > > * > in file wrappers_A01.py: > > import cbase01 > reload(cbase01) > > class ImStream_SavedBitmaps(cbase01.CImStream): > > def __init__(self): > cbase.CImStream.__init__(self) > print "SavedBitmaps" > > ** > in file sequencer01.py > > import cbase01# the offending lines, program works > reload(cbase01) # if I comment these out. > > class Sequencer: > > def Append(self, item): > pass > > * > in test02.py > > import wrappers_A01 > reload(wrappers_A01) > > import sequencer01 > reload(sequencer01) > > x0 = wrappers_A01.ImStream_SavedBitmaps() > *** > > If I run test02 I get the traceback > > Traceback (innermost last): > File "", line 1, in ? > File "D:\PythonCode\pna\eyeTracking\tests\test02.py", line 15, in ? > x0 = wrappers_A01.ImStream_SavedBitmaps() > File "D:\PythonCode\pna\eyeTracking\tests\wrappers_A01.py", line 21, > in __init__ > cbase.CImStream.__init__(self) > TypeError: unbound method must be called with class instance 1st > argument > > > Any ideas what I am doing wrong? > > Thanks, > Marc Yes my post has a mistake re: polymorphism. It seems self.__class__, whether called directly or indirectly, is always going to refer to the parent of the instance class. My code works only if there are no grandparents. Bummer, but glad to learn something new. It's too bad, I really lean on reload(). It appears to be incompatible with inheritance more than one level deep. -- https://mail.python.org/mailman/listinfo/python-list
Re: mutlifile inheritance problem
One more comment - my trick has some utility with multiple inheritance, but you really need to understand super() to and method resolution ordering in that case (as, I suppose, you ought to whenever you cross the Rubicon beyond single inheritance). So it's a nice trick but YMMV On Wednesday, September 18, 2013 4:54:00 PM UTC-7, Peter Cacioppi wrote: > This is a very old topic, but here is a trick for single inheritance. (The > problem you allude to isn't restricted to multiple inheritance). > > > > Any class with a single parent simply defines this function. > > > > > > def mySuper(self) : > > return super(self.__class__, self) > > > > And then any parent function be referenced like > > self.mySuper().foo() > > > > This includes __init__. > > > > You can read more here. > > > > http://atlee.ca/blog/posts/blog20081121python-reload-danger-here-be-dragons.html > > > > > > On Thursday, March 21, 2002 2:03:23 PM UTC-7, Marc wrote: > > > I have classes defined in different files and would like to inherit > > > from a class in file A.py for a class in file B.py but am running into > > > problems. I'm using Python 1.5.2 on Windows NT > > > > > > Here's a specific example: > > > > > > > > > file cbase01.py: > > > > > > class CBase: > > > > > > def __init__(self): > > > self.cclass = None > > > print "cbase" > > > > > > class CImStream(CBase): > > > > > > def __init(self): > > > CBase.__init__(self) > > > print "CImStream" > > > > > > * > > > in file wrappers_A01.py: > > > > > > import cbase01 > > > reload(cbase01) > > > > > > class ImStream_SavedBitmaps(cbase01.CImStream): > > > > > > def __init__(self): > > > cbase.CImStream.__init__(self) > > > print "SavedBitmaps" > > > > > > ** > > > in file sequencer01.py > > > > > > import cbase01# the offending lines, program works > > > reload(cbase01) # if I comment these out. > > > > > > class Sequencer: > > > > > > def Append(self, item): > > > pass > > > > > > * > > > in test02.py > > > > > > import wrappers_A01 > > > reload(wrappers_A01) > > > > > > import sequencer01 > > > reload(sequencer01) > > > > > > x0 = wrappers_A01.ImStream_SavedBitmaps() > > > *** > > > > > > If I run test02 I get the traceback > > > > > > Traceback (innermost last): > > > File "", line 1, in ? > > > File "D:\PythonCode\pna\eyeTracking\tests\test02.py", line 15, in ? > > > x0 = wrappers_A01.ImStream_SavedBitmaps() > > > File "D:\PythonCode\pna\eyeTracking\tests\wrappers_A01.py", line 21, > > > in __init__ > > > cbase.CImStream.__init__(self) > > > TypeError: unbound method must be called with class instance 1st > > > argument > > > > > > > > > Any ideas what I am doing wrong? > > > > > > Thanks, > > > Marc -- https://mail.python.org/mailman/listinfo/python-list
Re: mutlifile inheritance problem
This is a very old topic, but here is a trick for single inheritance. (The problem you allude to isn't restricted to multiple inheritance). Any class with a single parent simply defines this function. def mySuper(self) : return super(self.__class__, self) And then any parent function be referenced like self.mySuper().foo() This includes __init__. You can read more here. http://atlee.ca/blog/posts/blog20081121python-reload-danger-here-be-dragons.html On Thursday, March 21, 2002 2:03:23 PM UTC-7, Marc wrote: > I have classes defined in different files and would like to inherit > from a class in file A.py for a class in file B.py but am running into > problems. I'm using Python 1.5.2 on Windows NT > > Here's a specific example: > > > file cbase01.py: > > class CBase: > > def __init__(self): > self.cclass = None > print "cbase" > > class CImStream(CBase): > > def __init(self): > CBase.__init__(self) > print "CImStream" > > * > in file wrappers_A01.py: > > import cbase01 > reload(cbase01) > > class ImStream_SavedBitmaps(cbase01.CImStream): > > def __init__(self): > cbase.CImStream.__init__(self) > print "SavedBitmaps" > > ** > in file sequencer01.py > > import cbase01# the offending lines, program works > reload(cbase01) # if I comment these out. > > class Sequencer: > > def Append(self, item): > pass > > * > in test02.py > > import wrappers_A01 > reload(wrappers_A01) > > import sequencer01 > reload(sequencer01) > > x0 = wrappers_A01.ImStream_SavedBitmaps() > *** > > If I run test02 I get the traceback > > Traceback (innermost last): > File "", line 1, in ? > File "D:\PythonCode\pna\eyeTracking\tests\test02.py", line 15, in ? > x0 = wrappers_A01.ImStream_SavedBitmaps() > File "D:\PythonCode\pna\eyeTracking\tests\wrappers_A01.py", line 21, > in __init__ > cbase.CImStream.__init__(self) > TypeError: unbound method must be called with class instance 1st > argument > > > Any ideas what I am doing wrong? > > Thanks, > Marc -- https://mail.python.org/mailman/listinfo/python-list
