This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [python] StdStringPrinter misleading?
- From: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Phil Muldoon <pmuldoon at redhat dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>, archer at sourceware dot org
- Date: Fri, 03 Apr 2009 18:03:43 -0300
- Subject: Re: [python] StdStringPrinter misleading?
- References: <20090328002208.083A33A6BE4@localhost> <m3zlf6qvj8.fsf@fleche.redhat.com> <1238347593.8292.35.camel@localhost.localdomain> <m363hsp5d1.fsf@fleche.redhat.com> <1238367014.7100.21.camel@localhost.localdomain> <m3wsa7ooto.fsf@fleche.redhat.com> <49D65557.1040304@redhat.com> <m3vdpl8sl6.fsf@fleche.redhat.com>
El vie, 03-04-2009 a las 13:06 -0600, Tom Tromey escribiÃ:
> Phil> And an additional len parameter to string:
> Phil> return self.val['_M_dataplus']['_M_p'].string(encoding, len)
>
> I guess you added the new argument between 'encoding' and 'errors'?
>
> Normally I would say great -- as a general rule I think we should
> order positional arguments according to expected frequency of use.
Agreed.
> However in this particular case, there's already Python APIs using the
> "encoding, errors" sorting; so I would tend to put length last, and
> then access it via a keyword argument.
Are we already at a point were we should be cautious about changing the
API because it is already being used out there?
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center