[Ka-Ping Yee]
> In summary, all of the arguments for removing this feature are of the
> form "It won't hurt very much if we remove the feature"; the arguments
> for keeping the feature are of the form "This feature is useful and
> good for the language." Notice the asymmetry: there are no arguments
> that removing it will actually yield a better language, only arguments
> that the harm caused by removing it will be small.
Well said. I agree whole-heartedly; however, Brett did present another
argument beyond "it won't hurt much". I think his root motivation was
that the feature was difficult to implement for some reason or another.
FWIW, I would like the feature to be kept. I've found it useful in that it
documents the function signature more completely when dealing
with arguments that are already pre-packed into tuples (such as records
returned from SQL queries or CSV row readers):
def contact_info_update(timestamp, sequence_number, (name, address, phone,
email), backup=True):
. . .
contact_info_update(now(), seqnum, cursor.fetchone(), backup=False)
I think it is important to make explicit that the function depends on a
specific
layout for
the contact record tuple and have that dependency show-up in tooltips when I
write
the function call.
Another example comes from a spherical navigation module with several tuple
representations for movement (lat_offset, long_offset) versus (dist,
direction).
Raymond
_______________________________________________
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
