In reply to elanthis's post on Advogato,
1. I agree that the documentation could be improved, and we've been working on it. The next release should add a whole bunch of examples. Google is your friend, as is the Python Cookbook.
- Files as modules. What about importing those symbols in the package __init__.py? e.g.
- class MyClass:
- from foo.some.other.package.blah import MyClass
The physical layout is for you, the developer, while the exposed package interface can be pretty much whatever you want.
3. Classes are weak: yes, I guess so, but I don't really know how to address your concerns without adding a lot of syntax. Are you just lusting after variable declarations 'cause that's how you think?
Your take on unit testing seems just plain wrong. I know of no useful language that can prevent the majority of programming errors without some form of actually running the code, a.k.a. "testing". You might think YMMV, but you're almost certainly wrong.
- I agree that the decorator syntax is inelegant and inconsistent.
5. No variable declaration: you'd catch most of these problems with even the most rudimentary of unit tests and code coverage analysis. Shadowing is a concern, though. In practice it's never caused problems for me.
6. There are official recommendations regarding docstrings; see PEP 257. The (new) Python documentation is formatted with Sphinx, which you might like better.
I think you have a good point or two, but I also think you need to spend some more time programming in Python to figure out which of your complaints are actual problems with Python and what is simply a legacy of bad habits garnered from experiences with other languages. Even if you abandon Python for another dynamic language, I think you'll have the same (or stronger) criticisms of those.
Posted by Carlo Cabanilla on 2008-08-01 at 21:25.
(Replying on your blog because the original blog doesn't have comments) Regarding #3, using <em>_slots_</em> makes python classes enforce a rigid set of member variables and makes the class more self documenting. For example: class MyClass(object): <em>_slots_</em> = ('foo', 'bar') c = MyClass() c.foo = 1 # works fine c.baz = 1 # raises AttributeError
Posted by Paddy3118 on 2008-08-01 at 22:03.
Hi Titus, After reading the Post from Elanthis and your reply. I think you did right. I personally don't think that Elanthis is giving Python a chance, for example, his criticism of Docstrings I find more a criticism of the way he writes docstrings, and a lot of what he writes is the old static vs dynamic language arguments. I really wonder what pushes him towards dynamic languages as it seems to show up an inner turmoil of his. - Paddy.
Posted by Titus Brown on 2008-08-01 at 23:15.
Thakns, Paddy! Carlo, <em>_slots_</em> is meant solely as a memory optimization. It's not supposed to be used that way, although I must admit it's tempting sometimes :) --titus
Posted by baoilleach on 2008-08-02 at 16:05.
(A bit off-topic) Do you know if pydoc obeys PEP257 in relation to attribute docstrings? In my hands, I've found that it doesn't extract triply-quoted strings at the top level of a module (where used to document a module-level variable).
Posted by Titus Brown on 2008-08-03 at 09:57.
baoilleach, I don't know about pydoc, but PEP 257 explicitly states that the first line of a docstring should be a summary of the function/class/module/method. That behavior by pydoc sounds buggy.