On Tue, 2005-09-06 at 00:56, Guido van Rossum wrote: > On 9/5/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > Eliminating the newline argument from print() would reduce the number of > > reserved keyword arguments in my strawman by half. Maybe we could even > > rename 'to' to '__to__' (!) to eliminate the other namespace wart. Is > > this really too horrible: > > > > print('$user forgot to frobnicate the $file!\n', > > user=username, file=file.name, __to__=sys.stderr) > > Yes, it is too horrible. As I said in another post, __xyzzy__ screams > "special internal use, don't mess with this".
Fair enough -- it looked pretty icky to me too. > I don't think the namespace wart is really a problem though; it's > simple enough *not* to use 'to' as a variable name in the format. True. > Didn't you mean printf()? (Though I think if the format string doesn't > roughly follow C's format string conventions the function shouldn't be > called printf().) Yep, I meant printf(). > What do you think of the trick (that I wasn't aware of before) used in > Java and .net of putting an optional position specifier in the format, > and using positional arguments? It would be a little less verbose and > with sensible defaults wouldn't quite punish everybody as much for the > needs of i18n. Formats with more than 3 or 4 variables should be rare > in any case (these are not the days of Fortran formatted output). It's definitely an interesting idea, and would solve the namespace thing too. The above /might/ look like (warning: pre-coffee thought follows): printf('$1 forgot to frobnicate the $2!\n', username, file.name, to=sys.stderr) While that's a little less self-descriptive for a translator to deal with (who would only see the string, not the call site), it certainly looks nicer for a non-i18n application, and could certainly work for an i18n app too. It's a neat idea worth exploring. Also, I think you posted in a separate article a syntactic proposal for including detailed formating in $-vars. ${varname:fmt} where 'varname' could be an identifier a la PEP 292 or possibly a positional argument. -Barry
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com