After further searching, I finally ran across a very well-written article that attempts to explain Python decorators from a very basic level. While it hasn't brought to mind any situations in which I would want to use decorators in my code, I at least have a handle on what exactly they are and how they work.
To clarify my earlier post, one of main things that (at first) didn't click for me with regard to decorators was how exactly they allowed the programmer to effectively modify a function after it was written. Sure, I'd learned that you could assign a function to a variable and pass it around like any other piece of data, but even in that context I saw the function itself as essentially static. If I passed a function as an argument, I only expected the target function to call the function I passed as-is. I never thought about the possibility that a target function could actually do something else with/to the function I had passed.
As with other things I've unearthed in the process of learning Python, I have a hunch that this would've been easier to learn if I had a more formal background in computer science, and that's probably the biggest frustration that still crops up as I dig through Python documentation. Bits of programming terminology are often casually thrown around with the assumption that the average reader knows what they mean. One example is the term "first-class objects" that can be found at the head of the article linked above. I've seen that term used in several places, but even though the sentence immediately following the phrase in the above article is related to the phrase's definition, I still had no idea what it meant until I dug it up via a Google search. The way it was phrased in that article, it felt like the status of Python functions as first-class objects was a separate concept from that which immediately followed it, so I was left thinking, "Okay...so what are first-class objects?"
That's probably not the best example of my frustration, though. I guess the point is that it feels like there's a gap somewhere. At one end there's good introductory material, such as the tutorial by Guido von Rossum that covers a lot of ground-level topics. At the other end there is very nice reference material that covers the individual modules in the standard library, the data types that the language offers, etc. However, between Guido's tutorial and the other reference material there's a bit of a void, because some of the reference material makes reference to programming concepts that aren't explained in Guido's tut. I'm not necessarily implying that they should be covered by Guido's tutorial, but it's a gap all the same, and one that many in the Python community seem to ignore. Perhaps that is an inaccurate observation, and I'd be more than happy to be shown evidence to the contrary. However, from my observations, many experienced Python programmers seem to assume that you're either a newbie learning the basics, or you're a fellow pro. The folks in the middle who aren't totally new but aren't full-on professional programmers seem to get overlooked.
The most frustrating part is that I feel like I'm square in that gap. Yeah, I've been scripting/programming since I was about 12, but sadly that doesn't necessarily mean that I have a complete understanding of modern programming terminology and concepts. I've taken very few formal programming courses, and those few took place a long time ago. Everything else I know has been the result of self-study and on-the-job experience. However, the farther I delve into this stuff, the more I feel like self-study (at least what I'm currently doing) isn't cutting it.
So here comes the million-dollar question: do I stick with self-study and see how far it gets me, or do I go back to school? I've been around enough self-taught animators to know that it's possible to get to the very top of that game without formal instruction, but I don't know if the same holds true for the world of programming.
1 comment:
I wanted to respond to this yesterday but didn't get a chance.
It's not that you're coming up against a lack of knowledge on the subject. In general, the lexicon isn't required to learn, and you pick up things as you go. (I just recently figured out what a "delegate" is in Cocoa.) Most of the time, you do end up searching for breadcrumbs and when you're lucky you find the right one that leads you down the path.
Most of the time, if I don't understand what someone's talking about I take the second-language learner approach: I ignore it, or take a guess based on context. I'd say that 75% of the time, things like decorators are cute time-savers for things you can pull off with slightly more code or with a workaround.
So while I understood what "first class object" meant in that sentence because of experience, the important thing to learn from the article is that you can return functions, that functions are objects as in ActionScript 3. Personally I don't see much of a use for decorators outside of refactoring (or hacking someone else's code when you don't have access to the source).
I wouldn't bother going back to school. For one they'll probably have you spend most of your time learning code patterns. For another, depending on the teacher you'll end up being forced into specific paradigms that may or may not be beneficial, like having to name functions using Hungarian notation or making every function less than twenty lines, for little good reason.
Likely more helpful would be a coding mentor. You're right that there's a large gap between "newbie" and "advanced user," but I think that the thing both you and I have problems with in regards to the documentation is that the docs are usually written by engineers.
Anyway, in the end there's what works in Python, and what works. Last week I found out Maya's definition of "what works" is very different from Python's. I don't do the "syntactic sugar" tricks too much because they're harder for others to read and because stuff like that is where Maya starts choking. ^_^;
I think I rambled here... But hey, there's at least one guy out there who's gone through / is going through the same things.
Post a Comment