Dreaming of new generation IDE
robert.kern at gmail.com
Wed Feb 3 23:38:21 CET 2010
On 2010-02-03 15:37 PM, Steven D'Aprano wrote:
> On Wed, 03 Feb 2010 08:18:40 -0500, Adam Tauno Williams wrote:
>> On Wed, 2010-02-03 at 14:10 +0300, Vladimir Ignatov wrote:
>>> I am sitting here for quite some time, but usually keep silent ;-) I
>>> use Python since 2003 both "professionally" and for my hobby projects
>>> and love it a much.
>>> I notice however, that "maintaining" existing/older python code is may
>>> be not so enjoyable task. It may be even harder than supporting old
>>> code written in some type of "static" languages (like Java or C++).
>>> Surely "dynamic" nature of python comes with price.
>> Yes, it certainly does. Not that you'll get many Pythonistas to confess
>> to that fact. Somehow those who brag about the readability and
>> expressiveness of source code just cannot admit that:
>> class.method(sting name, int count)
>> - is *obviously* more expressive than -
>> class.method(name, count)
> Obviously? I don't know about that. Being told that "count" is an int
> doesn't really help me -- it's obvious just from the name. In a well-
> written API, what else could it be?
A bool. As in telling the method whether or not it should count something.
That said, I agree with your later point that this kind of information is better
provided by the docstring, not the call signature. Not least because the "type"
may be something wishy-washy and ad-hoc like "sequence" or "string or list of
strings". I do wish that people would document their parameters with this
information a little more consistently, though.
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the Python-list