In any sane code base, these method names will only appear in very specific places as part of tightly defined and documented classes, and would include a docstring. In my 8 years of Python, I have used __call__ exactly once, to try and emulate C# delegates, which turned out to be too insane to use in the end anyway.
Please ignore all the new-fangled "Pythonic" (GRRRRRR!) ORMs, template systems, and what have you that wonderfully misrepresent what makes Python nice in the first place (I'm talking about you here, Django).
I'm closely aligned to njs's way of thinking (see comment above). And if you think Python is verbose, you've either never read a line of C++ in your life, or you're reading really bad Python! With a good understanding of the core language (easily accomplished), it's actually pretty hard to write ugly code (__call__ and such) without trying.
It's worth remembering that the alternative to these ugly method names is special syntax, or friendlier method names that the average programmer is likely to overwrite by accident. That's why they are delineated with such brutishness.
Personally, if I was reading a piece of C++ that had "operator()" every 5 lines, I'd reserve my judgement on the language until I found some less crackpiped code.
...and that's about as coherent a comment as I can come up with having been awake 36 hours. :) 'night!
Posted Dec 4, 2008 9:35 UTC (Thu) by niner (subscriber, #26151)
[Link]
> In any sane code base, [...]
> Please ignore all the new-fangled "Pythonic" (GRRRRRR!) ORMs, template systems,
and what have you that wonderfully misrepresent what makes Python nice in the first
place (I'm talking about you here, Django).
> With a good understanding of the core language (easily accomplished), it's actually
pretty hard to write ugly code (__call__ and such) without trying.
Thats _exactly_ _my_ point!
A good programmer will write good, readable and maintainable code in just about any
language. And on the same account, any language can be abused to write horrible
monsters. Because it's not the language, but the one who uses it who decides.
I'm so sick of this "Perl code is unreadable by definition while Python code is always
pure joy to read" crap.
When you listen to American TV, you'd think that the English language is a horrible
monster but actually, there's even very nice poetry in it. It's all about use and abuse.
On the future of Perl 5
Posted Dec 4, 2008 10:38 UTC (Thu) by sbergman27 (guest, #10767)
[Link]
"""
A good programmer will write good, readable and maintainable code in just about any language. And on the same account, any language can be abused to write horrible monsters.
"""
And what you keep leaving out is that average programmers, the common case, will likely write the kind of code that the language encourages them write. All your hand-waving about how its possible to write good, readable structured code in TRS-80 BASIC (which is true) is only trying to distract from the reality that a quirky language that prides itself on its TMTOWTDI anarchy will likely reap (has demonstrably already reaped, actually) what it sews when average programmers get hold of it. And when they leave the project, their replacements, good, bad, or average, have to deal with the mess. That makes languages which encourage writing
unmaintainable code a hazard to all programmers: good, bad, and average.
BTW, I think a couple of us here are still waiting to see the evidence to support your claim that Python's PostgreSQL modules use popen() on psql.
On the future of Perl 5
Posted Dec 4, 2008 11:38 UTC (Thu) by niner (subscriber, #26151)
[Link]
Sorry, but I just can't find a difference between average Python code and average Perl
code. Both are nicely indented, averagely structured and so so readable. I can only
speak from my own experience which is a couple of 100,000 lines of code in each
language. And this experience says: Python aims at forcing people to write readable
code, but it fails. It certainly does not do worse than other languages, but it also doesn't
do better. And yes, there is often more than one way to do anything in Python.
Now internals, that's someting different. As the current maintainer of Perl's Inline::Python
module which is embedding a Python interpreter, I can say that I like Python's internals.
They really are more readable than Perl's though it still takes some source code reading
to fully understand them. The docs just aren't enough.
A funny thing tough: while in Perl you have to explicitly sv2mortal an object when
returning it from a C-function to Perl space, to get the reference count lowered after the
next Perl statement (which could be an assignment), Python implicitly gives this
responsibility to the stack, which is very confusing for the beginner for sure.
On that PostgreSQL thing: you must be confusing me with someone else. I've certainly
never written about anything concerning PostgreSQL and Python. I've not even used this
combination yet.
On the future of Perl 5
Posted Dec 4, 2008 14:35 UTC (Thu) by rfunk (subscriber, #4054)
[Link]
Well, there are other common magic __underscore__ symbols in Python
besides __call__; __init__ is probably the most common one. (Though I
haven't done much with Python in a while.)
Python is certainly much less verbose than C++, but C++ is a lower-level
language. It's more appropriate to compare Python to Perl (the original
topic here) and Ruby than to C++.