[Python-3000] PEP 3113 (Removal of Tuple Parameter Unpacking)

Bob Ippolito bob at redivi.com
Sun Mar 4 22:50:15 CET 2007


On 3/4/07, Raymond Hettinger <python at rcn.com> wrote:
> [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).

This is a feature I use pretty often. I do a lot of data processing
(e.g. CSV or SQL) and it comes up all of the time. It would be
annoying to lose it.

FWIW Erlang does tuple and record unpacking, but that programming
model pretty much requires it.

-bob


More information about the Python-3000 mailing list