Does Python really follow its philosophy of "Readability counts"?

Mark Wooding mdw at distorted.org.uk
Thu Jan 22 14:10:05 EST 2009


Steven D'Aprano <steve at REMOVE-THIS-cybersource.com.au> writes:

> On Thu, 22 Jan 2009 15:12:31 +0100, Bruno Desthuilliers wrote:
>> Steven D'Aprano a écrit :
>>> But if you have free access to attributes, then *everything* is
>>> interface.
>>
>> Nope.
>
> How could anyone fail to be convinced by an argument that detailed and 
> carefully reasoned?

Well, your claim /was/ just wrong.  But if you want to play dumb: the
interface is what's documented as being the interface.

You can tell that your claim is simply wrong by pushing it the other
way.  If everything you have free access to is interface then all
behaviour observable by messing with the things you have access to is
fair game: you can rely on cmp returning one of {-1, 0, 1} on integer
arguments, for example.

But no: the Library Reference says only that it returns a negative, zero
or positive integer, and /that/ defines the interface.  Everything else
is idiosyncrasy of the implementation, allowed to change at whim.

>>>> from ConfigParser import ConfigParser
>>>> config = ConfigParser({'a':1})

[...]

>   File "/usr/local/lib/python2.6/ConfigParser.py", line 585, in 
> _interpolate
>     if "%(" in value:
> TypeError: argument of type 'int' is not iterable

I'd say that this is a bug.  The Library Reference says (9.2):

: `ConfigParser([defaults])'
:      Derived class of `RawConfigParser' that implements the magical
:      interpolation feature and adds optional arguments to the `get()'
:      and `items()' methods.  The values in DEFAULTS must be
:      appropriate for the `%()s' string interpolation.  Note that
:      __NAME__ is an intrinsic default; its value is the section name,
:      and will override any value provided in DEFAULTS.

The value 1 is certainly appropriate for `%()s' interpolation:

In [5]: '%(foo)s' % {'foo': 1}
Out[5]: '1'

so you've satisfied the documented preconditions.

> In stricter languages, particularly code with static type checking,
> the attitude is "you must only provide input that meets these pre-
> conditions".

You did that.  It failed anyway.  Therefore it's broken.  Report a bug.

-- [mdw]



More information about the Python-list mailing list