This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [python] StdStringPrinter misleading?
- From: Tom Tromey <tromey at redhat dot com>
- To: Thiago Jung Bauermann <bauerman at br dot ibm 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 15:53:35 -0600
- 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><1238792623.3236.77.camel@localhost.localdomain>
- Reply-to: Tom Tromey <tromey at redhat dot com>
Tom> However in this particular case, there's already Python APIs using the
Tom> "encoding, errors" sorting; so I would tend to put length last, and
Tom> then access it via a keyword argument.
Thiago> Are we already at a point were we should be cautious about changing the
Thiago> API because it is already being used out there?
I doubt it for this particular API.
I was just arguing that we should keep our API parallel to existing
practice in situations like this.
Tom