[Python-3000] [Python-Dev] dict.items as attributes [Was: The bytes type]

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jan 17, 2007, at 8:38 AM, Greg Falcon wrote:

> After a bit of mulling it over, the best objection I can come up with
> is this: views aren't "attributes" or "properties" of a dict object in
> the plain-English sense of the term.  This might simply be a flawed
> appeal to an overloaded word, but I think it captures my gut feeling
> well.  A dictionary object contains keys and values, and those
> *contents* can be said to be attributes of a dictionary.  Views are
> just wrapper objects that expose those contents in interesting ways.

> A second objection: Although this is a clever way of adding
> forwards-compatibility to 2.6, the side effect that views are callable
> is odd.  It's especially unintuitive that v() is synonymous with
> list(v).  The existing stateless, sequence-proxying objects (like
> xrange) don't behave that way, and it would be strange if they did.
>
> Part of me suspects that if Python builtin types or library types made
> bigger use of attributes, this proposal wouldn't seem so weird.  There
> are many opportunities in the library to replace zero-arg, cheap,
> side-effect-free methods with read-only attributes, but that hasn't
> happened.  This sort of thing still isn't really idiomatic, and just
> because Python 3 is a major version bump doesn't mean we *should*
> change the idioms.

You make some good points, though I tend to think that the fact that  
these have always been methods may be the largest factor in why  
making them attributes looks weird.

As for the idioms that we tend to use, I've definitely come full  
circle on that.  The API for our product started out using a  
functional (everything methods) interface both for getting and  
setting.  But it just seemed so verbose and frankly unreadable.  Then  
we turned all zero-arg, side-effect-free accessor methods into  
attributes and it make everything so much cleaner and more readable.   
Most of these attributes were read-only so it made clearer sense to  
do this, but there are a few that were read/write and some of those  
were made into attributes.  For others, we kept the setter methods  
mostly because the setters often took additional arguments.  It still  
came down to a case-by-case basis but with the emphasis toward  
readability, attributes seemed more natural.

I do think that as we update the stdlib for py3k, we should think  
about whether setters/getters can be turned into attributes.

- -Barry

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iQCVAwUBRa5SRXEjvBPtnXfVAQKxkgQAlTFO+HARcC73BlcvEfB3z2qB2NuIpYv/
dPHwiLVWkuTC9fjft/2rbEeV5jfOYVaQCrlq9cPGSeQ/H/GkD1JeI1AoBY/U4EZY
yiPW6Opac5FEWCJtSjs5p4Av6Uoq3076lyq6MFqa2ogRSGq8/lw9WVuCjXNIcT8N
w0TWfji15qg=
=rlBy
-----END PGP SIGNATURE-----