|
Python Annoyances
Development
|
|
|||
| This is a great article and a must-read if you haven't already; transitioning from static-typed languages to dynamic languages is somewhat of an adjustment and I found this article very helpful when I did so. Granted, this article focuses on Java, but a lot of it is applicable to anyone coming from a static-typed language. http://dirtsimple.org/2004/12/python-is-not-java.html I'll selectively address those issues that I can do so quickly  > 2. Files as Modules Try this: put your classes in separate modules/files in a package/dir as you like (ala Java). Then, in the __init__.py of the package, simply "from someclass.py import *". That way, all your classes are in the package namespace. You not longer need need to do "import mypackage.someclass.SomeClass". > 3. Classes Are Weak Au contraire, Python classes are pretty damn powerful. Also, glancing at your code, it looks like _everything_ is a class. Certainly, for game objects, etc this makes sense, but some things/tasks aren't modeled well by OOP. Python's power lies in it's flexibility; you can combine functional-programming (lisp yay! and that's _not_ sarcastic) style with OOP. Use the programming model that best fits the component you're designing. Ask yourself; do configs _really_ need to be classes? Maybe the answer is yes. Dunno, as I am speaking relatively naively. I recommend looking at the Django codebase to get some inspiration in Python classes. Their kung fu, as it were, is strong. |
|||
|
|||
|
Dude, trust me, I do NOT need help "transitioning to a dynamic language." I've been programming in dynamic languages for more years than I can count with my shoes on. My complaint is NOT "Python is a dynamic language;" it's "Python is a dynamic language that offers no facilities to help out when dynamic is the wrong tool." Basically, maintaining larger applications with rigid type requirements is a pain in Python, which is something you'll hear from a lot of people who've used Python for anything more than small ad-hoc projects. (The same goes for quite a few other dynamic languages; many have "seen the light" and added _optional_ facilities to help out with type enforcement.) As I said in the blog post response, it's really unfortunate that people get these silly ideas that a language is either dynamic or static. I don't WANT static typing everywhere -- if I did, I wouldn't have switched to Python in the first place. I do want some facilities for type checking in a number of places, though. I can add this manually with a bunch of assert statements in the beginning of functions, but I'd rather not have to type a ton of extra code like that. I'm lazy. (Hence Python.) I want to type the least amount possible and get the most out of it. That means I want a damn easy way to get type checking where I need it. I will freely admit that I'm not a huge fan of "unconstrained" dynamic typing. I'll probably make another blog post versus going into my ideas on that topic here. I'm also pretty familiar with Django these days. It was my experience with Django that got me to decide to switch to Python in Source MUD, after all. For your module suggestion, I did actually try that. I would get random classes that would just refuse to import from other modules for reasons I couldn't figure out, and decided to not mess with it anymore. One of my _other_ complaints of the module system is that I don't want to break my source into a ton of sub-directories; I just wanted to break it into multiple _files_. Regarding classes, my "weak" comment had to do with enforcement of my structure definition, not with flexibility. Switching away from classes in cases certainly won't help any in that regard. You're right that Config maybe doesn't need to be a class; but then, I don't see a strong reason for it not to be, either. |
||