Re: [Python-Dev] Replacement for print in Python 3.0
On 9/9/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > While I laugh at the naive view of people who write things like > "Interface equality and neutrality would be a good thing in the > language" and seriously (? I didn't see a smiley) use this argument to > plead for not making print() a built-in, I do think that avoiding the > 'print' name would be a good thing if it could be done without ticking > off the old-timers. Oh, no! I've been misrepresented! I can be a little unclear sometimes, and for that I apologize. What I was saying is that there are essential to ends to the spectrum: you either elevate text console IO to a status above other forms of interface with the applications written in the language, or you don't build any interface mechanisms into the lanuage at all. Python currently is at the former end of that spectrum, and the current discussions seem to be pushing towards the later. My disagreement is more with consistancy than where it actually stands in that spectrum. So, I'm saying if it has to be in the language directly, keep a statement for it. If if really shouldn't be a statement, then make me import it first. Yes, I know that no one wants to import a module just to output text, but I don't see how or why it is any different than importing GUI modules. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > My hypothesis is that there are actually only two use cases that > matter enough to be supported directly: > > (a) quickly print a bunch of items with spaces in between them and a > trailing newline > > (b) print one or more items with precise control over each character Doesn't the write() method of file-like objects already cover (b), except that it only takes a single argument? If the need to print multiple arguments without any separator is so common, could the write() method be extended to take multiple arguments and just write them all out? It'd certainly be backward compatible with old code that called the write() method... Andrew. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Nick Coghlan wrote: > Not to mention the annoyingly large number of fonts that make '`' and ''' > look > virtually identical :( Well, you need to be careful about choice of font for programming anyway, for 0/O, 1/l, etc. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
(Maybe someone else has already raised this point. I'm a bit behind.) Martin> Here goes something: for applications targeted to the web, where Martin> newlines don't matter, the line breaks in _()'ed strings are Martin> superfluous. How will you know you're generating output that goes between and (where newlines do matter)? Skip ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/8/05, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > Hi, > > Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit : > > > It would be > > nice to be able to lose the "_()" calls to gettext(). The function > > would look to see if a message catalog was available for the current > > output stream, and if not, do no translation. > > That doesn't sound right to me. > 1. You still need to do automatic extraction of these strings (gettext > has tools for that, which rely on the use of the "_()" function - or any > other dedicated function (*)). > 2. You can't assume that all strings must be i18n'ed. For example if I'm > interfacing with the user via a text-based network protocol which has a > field named "Length", I don't want that "Length" field to be replaced > with the Japanese translation of the word "Length". > > For i18n, "explicit is better than implicit" ;) The beauty of "_()" is > that it's at the same time explicit, easily recognizable, and very short > to type and read (it doesn't clutter the source code). If I dare say, > the "%" operator has the same qualities. > > (*) of course more automatization of what gettext does could be a nice > improvement too! Here goes something: for applications targeted to the web, where newlines don't matter, the line breaks in _()'ed strings are superfluous. In order to avoid the problem of not being able to "fix" my strings when reindenting the source, and to avoid the need in general to have newlines in the po files, I added an option to pygettext that allows it to flatten the strings in a single line. This does not break the old functionality, just allows you more flexbility in the input source (you can break strings on multiple lines) and the strings in the catalogs are nicer too (no newlines clutter). I submitted a patch on 2005-01-08, nobody has had time to review/integrate it yet. If you're interested, see [ 1098749 ] Single-line option to pygettext.py http://sourceforge.net/tracker/index.php?func=detail&aid=1098749&group_id=5470&atid=305470 cheers, ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Fredrik> backquotes are a PITA to type on many non-US keyboards. Interesting. On US keyboards they are often easier to type than parens... Skip ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/8/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > Could be. For me, the name "print" is associated with a long history > of magical behavior that only a human could possibly feel comfortable > with. One of the great sins of Pascal was tarring the name "write" > with the same brush! Well, apart from your personal history, and in the light of future developments, for most people who aren't programmers using dinosaur languages, "print" will probably mean "convert a document to bits of ink on paper" or perhaps by extension into the third dimension "produce a physical object from a virtual one". (I've seen some amazing demos of the latter at foocamp, even though the equipment is still a bit big to fit in a typical kitchen. :) While I laugh at the naive view of people who write things like "Interface equality and neutrality would be a good thing in the language" and seriously (? I didn't see a smiley) use this argument to plead for not making print() a built-in, I do think that avoiding the 'print' name would be a good thing if it could be done without ticking off the old-timers. On the third hand, I notice that Java uses read()/write() and class names ending in Stream for a byte-oriented API, and print()/println() with class names ending in Reader/Writer for a text/character-based API. (Some classes provide both print() and write() methods and there the distinction is clearest.) Since Python 3000 is heading in the same direction, I wouldn't mind having some API distinction so it's clearer to the reader whether we are writing binary or or text data. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Fredrik Lundh wrote: > Greg Ewing wrote: > > >>Maybe backquotes could be repurposed in Py3k for interpolated >>string literals? > > > backquotes are a PITA to type on many non-US keyboards. Not to mention the annoyingly large number of fonts that make '`' and ''' look virtually identical :( Besides, backquotes don't give you a way to supply the values to feed into the interpolated literal the way string.Template does, or a 'format' builtin would. This does make me think of the interesting prospect of an internationalised string literal, though (e.g., _"This an il8n string"). I'm not sure it would be enough of a win over the status quo though, since doing the language conversion at compile time could make it interesting to try and switch languages at run time. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
"Fredrik Lundh" <[EMAIL PROTECTED]> writes: > Greg Ewing wrote: > >> Maybe backquotes could be repurposed in Py3k for interpolated >> string literals? > > backquotes are a PITA to type on many non-US keyboards. Even more since they are especially broken in Windows XEmacs. Thomas ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Greg Ewing wrote: > Maybe backquotes could be repurposed in Py3k for interpolated > string literals? backquotes are a PITA to type on many non-US keyboards. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
> "Greg" == Greg Ewing <[EMAIL PROTECTED]> writes: Greg> Stephen J. Turnbull wrote: >> IMO strings that are being printf'd can probably be assumed to >> be human readable, and therefore candidates for translation. >> This Greg> That's a dangerous assumption to make, I think. Could be. For me, the name "print" is associated with a long history of magical behavior that only a human could possibly feel comfortable with. One of the great sins of Pascal was tarring the name "write" with the same brush! Greg> I'd be uncomfortable with having some strings in my program Greg> translated automatically and others not. EIBTI here, I Greg> feel. If printf is going to be part of a magical family of print* functions that do things like insert interword spacing and EOLs, I have no problem with documenting that among the other magical things that printf does, it translates strings. This is no less explicit than any other function that bundles several more primitive functions. If instead, we come up with a sufficiently excellent set of formatting and interpolation notations that printf isn't magic at all, simply a function that interprets a precisely defined set of explicit notations, then i18n should have its own notation, too. On reviewing the thread, the latter seems to be the direction things are going. Although several people have defended print's magical behaviors, most of them (and several others) seem at least as excited about a printf with a more economical yet powerful set of operators. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Stephen J. Turnbull wrote: > IMO strings that are being printf'd can probably be assumed to be > human readable, and therefore candidates for translation. This That's a dangerous assumption to make, I think. I'd be uncomfortable with having some strings in my program translated automatically and others not. EIBTI here, I feel. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Michael Chermside wrote: > In my opinion, YES -- it's worth seriously considering it. A single, > well-designed solution for string interpolation (with syntactic support > if needed to make it very easy to use) is FAR better than having one > good solution and another legacy solution. Maybe backquotes could be repurposed in Py3k for interpolated string literals? -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sep 8, 2005, at 5:42 AM, Barry Warsaw wrote: > On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote: > > >> I was also able to easily automate the process of extracting strings >> to create that spreadsheet. I wrote a simple script that parsed the >> Python modules and looked for function calls of "_" whose only >> argument was a constant string. Worked great, and it was easy to >> write. >> > > I don't think enough people know about Tools/i18n/pygettext. It does > all the extractions for you, producing a GNU gettext compatible .pot > file. You can even teach it to recognize extraction keywords other > than > the default _(). printf() should be easy to recognize, although we > might have to make a slight modification since IIRC, pygettext will > only > extract strings from keyword functions with exactly one argument. > That > should be easy to fix. You're right, I think Tools is probably a bad place for anything. If it's not part of the stdlib, I'll likely never find it. -bob ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Michael Chermside writes: | Guido writes: | > Is it worth doing this and completely dropping the %-based formats in | > Py3k? (Just asking -- it might be if we can get people to get over the | > shock of $ becoming first class ;-). | | In my opinion, YES -- it's worth seriously considering it. A single, | well-designed solution for string interpolation (with syntactic support | if needed to make it very easy to use) is FAR better than having one | good solution and another legacy solution. Just the awkwardness of the | trailing s in "%(foo)s" is enough to motivate a search for something | better. hey folks, I managed to lose a few days worth of python-dev mail so I'm late to this discussion, but I thought I'd toss in a few (possibly outlying) data points form the visual effects/3d animation world. here at ILM we use python as the expression langauge in a number of 3d applications, and we usually end up adding a front-end parser so users can reference variable values inline via $ sytanx. they're still essentially writing python code, but with the extra added suger of $ references. I have first-hand information that the engineers at Pixar chose tcl over python a few years back as the expression language in their commercial shader editor "slim" for exactly this reason as well (i.e tcl already had $ refs, and they didn't want to present their own python-but-not language like we do here). so if replacing '' % () formatting with $ refs is an option in py3k, allow me to offer a +1000 vote for that :) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/5/05, Calvin Spealman <[EMAIL PROTECTED]> wrote: > > There is a lot of debate over this issue, obviously. Now, I think > > getting rid of the print statement can lead to ugly code, because a > > write function would be called as an expression, so where we'd once > > have prints on their own lines, that wouldn't be the case anymore, and > > things could get ugly. > > Sounds like FUD to me. Lots of functions/methods exist that *could* be > embedded in expressions, and never are. Or if they are, there's > actually a good reason, and then being a mere function (instead of a > statement) would actually be helpful. Anyway, why would it be > important that prints are on their own line where so many other > important actions don't have that privilege? For the same reason any statement is not an expression. Python doesn't allow assignments as expression, even though it has been implemented. Nor imports or function and class definitions. Readability is key. On the other hand, I actually don't like there being a print statement at all. We don't live in the days were console software rules and any other form of interface is an after thought. First-class printing to standard out seems to make a statement (no pun intended) that the language is intended for Unix-emulating operating systems (even Windows does, to some extent) and that anything you don't pipe through stdout or pull from stdin is something extra tossed in for a special crowd. Interface equality and neutrality would be a good thing in the language. But, I guess what I'm getting at is that if you do give special case to anything, give it special case properly. If text console IO is going to be only through functions and not directly in the language syntax, should it even be a built-in? Bring it to the level of any other interface API or keep it at its own status, but any middle ground seems half-hearted. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
> "Antoine" == Antoine Pitrou <[EMAIL PROTECTED]> writes: Antoine> Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen Antoine> J. Turnbull a écrit : >> It would be nice to be able to lose the "_()" calls to >> gettext(). The function would look to see if a message catalog >> was available for the current output stream, and if not, do no >> translation. I should have been more explicit. I meant only in the context of printf. You're right, gettext (and aliases) are still needed. Antoine> That doesn't sound right to me. 1. You still need to do Antoine> automatic extraction of these strings (gettext has tools Antoine> for that, which rely on the use of the "_()" function - Antoine> or any other dedicated function (*)). I think printf is an excellent candidate for such a function. Antoine> 2. You can't assume that all strings must be i18n'ed. IMO strings that are being printf'd can probably be assumed to be human readable, and therefore candidates for translation. This assumption does impose runtime overhead on non-i18n users, but I suspect it's smaller than that of caching regexps which has been determined to be acceptable. It would also make printf more hazardous for use in implementing protocol messages, but I think that's already pretty hazardous with the print statement. Although Guido has been very firm about not imposing overhead on _all_ users for the sake of i18n, implementing protocols is a similar minority activity, and there might be an acceptable tradeoff there. Antoine> As I said Python needs an operator or function that does Antoine> string formatting using a simple template, *without* Antoine> doing output at the same time. The current syntax is the Antoine> '%' operator, it could change, but it shouldn't be Antoine> removed in favor of an inflexible print-with-formatting Antoine> approach. AFAICT, that is the consensus view. Is there something concrete you're worried about here? Cheers, -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Barry Warsaw wrote: > On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote: > > >>The leading 'p' (for 'positional') is necessary to get around the fact that >>$1 >>is currently an illegal identifier in a Template > > > That should be fixable. Ideally, $1 is better than $p1. I also looked into the idea of adding formatting support to the string.Template syntax. Given a reimplementation of string.Template with the following pattern: pattern = r""" %(delim)s(?: (?P%(delim)s) | # An escape sequence of two delimiters, or ( (\[(?P[^%%]*)\])? # an optional simple format string, ( (?P%(id)s) | # and a Python identifier, or {(?P%(id)s)} # a braced identifier ) ) | (?P) # An ill-formed delimiter expr ) """ And "convert" functions modified to use "fmt" where "'%s'" is currently used, with "fmt" defined via: fmt = mo.group('format') if fmt is None: fmt = '%s' # Default to simple string format else: fmt = '%' + fmt The following works: Py> t = format.Template("$item: $[0.2f]quantity") Py> t.format(quantity=0.5, item='Bees') 'Bees: 0.50' Combining with a 'format' function similar to the one in my previous message, and an id pattern modified to permit numbers as identifiers: Py> format("$1: $[0.2f]2", 'Bees', 0.5) 'Bees: 0.50' Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Barry Warsaw wrote: > On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote: > > >>The leading 'p' (for 'positional') is necessary to get around the fact that >>$1 >>is currently an illegal identifier in a Template > > > That should be fixable. Ideally, $1 is better than $p1. Oh, I know. I just didn't feel like cranking my brain up to the point of figuring out the necessary change to the string.Template regex. It turns out the one required change to the pattern is truly trivial though (I guess the grief we gave PEP 292 about easy customisation was actually worthwhile): from string import Template class fmtTemplate(Template): idpattern = '[_a-z0-9]*' def format(*args, **kwds): if kwds and (len(args) > 1): raise ValueError("Cannot use both keyword and positional arguments") fmt = fmtTemplate(args[0]) kwds.update(((str(idx), arg) for idx, arg in enumerate(args))) return fmt.substitute(**kwds) Py> format("$1: $2", "Num bees", 0.5) 'Num bees: 0.5' Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Thu, 2005-09-08 at 07:48, Antoine Pitrou wrote: > As I said Python needs an operator or function that does string > formatting using a simple template, *without* doing output at the same > time. The current syntax is the '%' operator, it could change, but it > shouldn't be removed in favor of an inflexible print-with-formatting > approach. I believe we already have that in the constituent parts of stream.write() and Template.substitute(). I don't have any problem with the built-in print() function (or printf()) combining the two for convenience. After all, print's entire purpose is convenience. -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
Re: [Python-Dev] Replacement for print in Python 3.0
On Wed, 2005-09-07 at 15:07, Bob Ippolito wrote: > I was also able to easily automate the process of extracting strings > to create that spreadsheet. I wrote a simple script that parsed the > Python modules and looked for function calls of "_" whose only > argument was a constant string. Worked great, and it was easy to write. I don't think enough people know about Tools/i18n/pygettext. It does all the extractions for you, producing a GNU gettext compatible .pot file. You can even teach it to recognize extraction keywords other than the default _(). printf() should be easy to recognize, although we might have to make a slight modification since IIRC, pygettext will only extract strings from keyword functions with exactly one argument. That should be easy to fix. -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
Re: [Python-Dev] Replacement for print in Python 3.0
On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote: > The leading 'p' (for 'positional') is necessary to get around the fact that > $1 > is currently an illegal identifier in a Template That should be fixable. Ideally, $1 is better than $p1. -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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido writes: > Is it worth doing this and completely dropping the %-based formats in > Py3k? (Just asking -- it might be if we can get people to get over the > shock of $ becoming first class ;-). In my opinion, YES -- it's worth seriously considering it. A single, well-designed solution for string interpolation (with syntactic support if needed to make it very easy to use) is FAR better than having one good solution and another legacy solution. Just the awkwardness of the trailing s in "%(foo)s" is enough to motivate a search for something better. But this presuposes that there IS a single well-designed solution. PEP 292 templates are an excellent start, but they are not that solution. The largest problem is the lack of a means for formatting numbers. People should think hard about good solutions. He continues: > I proposed ${varname%fmt} earlier but it prevents you to extend the > varname syntax to arbitrary expressions, which I think is an extension > that will get lots of requests. I certainly agree that we should keep open the syntactic possibility to allow arbitrary Python expressions between "${" and "}" in an interpolation string even though it may not be supported today. I favor idea (Barry's?) of using "${::}" where is an identifier (but someday might allow expressions), and and behave like the % interpolation modifiers today. I would have suggested it myself, but somehow I failed to realize that slice literals are allowed only within subscripts and thus do not conflict with this use. -- Michael Chermside ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Hi, Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen J. Turnbull a écrit : > It would be > nice to be able to lose the "_()" calls to gettext(). The function > would look to see if a message catalog was available for the current > output stream, and if not, do no translation. That doesn't sound right to me. 1. You still need to do automatic extraction of these strings (gettext has tools for that, which rely on the use of the "_()" function - or any other dedicated function (*)). 2. You can't assume that all strings must be i18n'ed. For example if I'm interfacing with the user via a text-based network protocol which has a field named "Length", I don't want that "Length" field to be replaced with the Japanese translation of the word "Length". For i18n, "explicit is better than implicit" ;) The beauty of "_()" is that it's at the same time explicit, easily recognizable, and very short to type and read (it doesn't clutter the source code). If I dare say, the "%" operator has the same qualities. (*) of course more automatization of what gettext does could be a nice improvement too! > But so far, I don't see > any reason why your proposal for the $1 positional syntax in printf() > hinders any of the above. As I said Python needs an operator or function that does string formatting using a simple template, *without* doing output at the same time. The current syntax is the '%' operator, it could change, but it shouldn't be removed in favor of an inflexible print-with-formatting approach. Regards Antoine. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> I certainly didn't mean to rule that out. Speaking for myself, that's all I really wanted to hear at this time. As Bob Ippolito said, currently it's straightforward to internationalize an application, and well worth the minimal overhead if it's at all serious. It's just that it would be nice if quick and dirty additions for i18n programs could be done as easily and with the same facility as for mono-Euro-lingual programs. I also think that at present Python is to the point where it's natural to write in a style where i18n is nearly costless (I use unicode strings habitually, and prefer %(var)s to positional %s anyway, because I find it easier to read). It would be a shame to regress from that! Why "mono-Euro-lingual"? Well, in teaching Python in Japan, one thing that is really annoying about the current print statement is that automatic spacing. Japanese doesn't use spaces to separate words, so you basically have to start with the '%' operator when teaching Japanese students output using variables. Several of them have said "oh, another typical American software that breaks Japanese". Dunno what to do about that, though, setting that based on the POSIX locale would break my personal usage (when things are broken, I want to see the debug output in English!) Guido> But I doubt that the only text to be i18n'd will occur in Guido> printf format strings. (In fact, I expect that few apps Guido> requiring i18n will be so primitive as to use *any* printf Guido> calls at all.) Personally I don't write complex applications in native Python, I write them for Zope or something like that. Then I don't have to worry about generic Python facilities; I have to use whatever the substrate is using. However, I do write simple CGIs that need to produce English and Japanese pages (at least), and it's often enough to write something like (this is from memory): def addressWarningPage (formDict) simplePageHeader (_("Address Warning")) print _("""\ I'm sorry, %(user)s, but the address you submitted is %(address)s, which appears to be a mobile phone address. Please use a real email address, because the mailing list for %(course)s distributes large attachments.""") % formDict simplePageFooter () where the simplePageFunctions themselves have been inherited from old code that simply 'print'ed to stdout, and formDict is constructed by the underlying CGI handler, so it's always available. I write a fair number of these pages, there are always new ways to go wrong This is very similar to what Bob Ippolito describes, and it's easy enough to do. However, my translators _do_ confuse the "s" for "string argument" with English pluralization (they're not native English speakers, usually). It would be nice (for me) if we could use notation that doesn't use stray format characters. It would be nice to be able to lose the "_()" calls to gettext(). The function would look to see if a message catalog was available for the current output stream, and if not, do no translation. (I'm not sure this can work, because it might conflict with things done automatically based on environment settings of POSIX locale.) It would be nice if a single function could support format strings with positional arguments and those with named variable substitution. (Not at the same time, though, that should be an error, I think.) If not, a separate function would be easy enough to support in a conversion script. All that's still pretty abstract, I guess. But so far, I don't see any reason why your proposal for the $1 positional syntax in printf() hinders any of the above. I just wanted to make sure that asking for them is OK. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> Guido> In a different thread I mentioned a design principle for Guido> which I have no catchy name, but which has often helped me Guido> design better APIs. One way to state it is to say that Guido> instead of a single "swiss-army-knife" function with Guido> various options that choose different behavior variants, Guido> it's better to have different dedicated functions for each Guido> of the major functionality types. So let's call it the Guido> "Swiss Army Knife (...Not)" API design pattern. I call the idea the 80/20 Split, or 'Convenience Functions'. You have a powerful, highly generalized function that can do most anything, and has an interface to prove it. Then, a collection of 'Convenience Functions' to constrain that "Swiss Army Knife" to handle 80% of the use-cases, while still letting Ye Power User dig a little deeper. The challenge is to keep the Convenience Function population low, so that you don't arrive at 8,020 different functions in the interface. Go, Python! Chris ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sep 7, 2005, at 7:11 AM, Guido van Rossum wrote: > On 9/7/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > >> On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote: >> >> >>> But print-ng looks >>> like becoming the OOWTDI for a lot of applications. IMO it's >>> just too >>> early to give up on print-ng becoming the one obvious way to do >>> it for >>> a lot of i18n apps, too. >>> >> >> +1. I have a gut feeling that we can make it easy for >> monolinguists to >> use printng without caring or even knowing about i18n, but also >> make it >> relatively painless to integrate i18n into an application or library. >> However I haven't had time to really explore that idea. >> > > I certainly didn't mean to rule that out. But I doubt that the only > text to be i18n'd will occur in printf format strings. (In fact, I > expect that few apps requiring i18n will be so primitive as to use > *any* printf calls at all.) In my experience, implementing i18n with *existing* Python (2.3 at the time) features was not a big deal. We used a translation company to translate all of the strings, and they had no problem with normal Python %(format)s strings. We gave it to them in an excel spreadsheet, and converted it to Apple ".strings" style files (which we parse directly in the Windows version). Granted, we highlighted all of the "%(format)s" in the spreadsheet so it was clear what should be preserved. It worked like this: def _(stringToBeLocalized): return anAppropriateString and all formatted strings in the code looked like this: _('default english string %(variable)s') % someDict from real world production code: _(u'Installing this software requires %(requiredSpace)s of space.\n \nYou have selected to install this software on the iPod "%(podName) s" (%(totalFree)s available)') % { u'requiredSpace': self.installer.getRequiredFreeDiskSpace(), u'podName': self.podName, u'totalFree': space, } I was also able to easily automate the process of extracting strings to create that spreadsheet. I wrote a simple script that parsed the Python modules and looked for function calls of "_" whose only argument was a constant string. Worked great, and it was easy to write. -bob ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/7/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote: > > > But print-ng looks > > like becoming the OOWTDI for a lot of applications. IMO it's just too > > early to give up on print-ng becoming the one obvious way to do it for > > a lot of i18n apps, too. > > +1. I have a gut feeling that we can make it easy for monolinguists to > use printng without caring or even knowing about i18n, but also make it > relatively painless to integrate i18n into an application or library. > However I haven't had time to really explore that idea. I certainly didn't mean to rule that out. But I doubt that the only text to be i18n'd will occur in printf format strings. (In fact, I expect that few apps requiring i18n will be so primitive as to use *any* printf calls at all.) Anyway, let us hear what you had in mind rather than arguing over some abstract principle. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Nick Coghlan wrote: > I found the following to be an interesting experiment: > > - > from string import Template > > def format(*args, **kwds): > fmt = args[0] > kwds.update(("p%s" % idx, arg) for idx, arg in enumerate(args)) > return Template(fmt).substitute(**kwds) I forgot to add the following concept: - def printf(*args, **kwds): to = kwds.pop("to", sys.stdout) to.write(format(*args, **kwds)) Py> printf("$p1: $p2\n", 1, 2) 1: 2 Py> printf("$p1: $p2\n", 1, 2, to=sys.stderr) 1: 2 Py> printf("$p1: $p2$to\n", 1, 2, to=sys.stderr) Traceback (most recent call last): File "", line 1, in ? File "", line 3, in printf File "", line 4, in format File "C:\Python24\lib\string.py", line 172, in substitute return self.pattern.sub(convert, self.template) File "C:\Python24\lib\string.py", line 162, in convert val = mapping[named] KeyError: 'to' - If you're dealing with an existing template that uses the 'to' keyword, then it is possible to fall back to using: - def printraw(*args, **kwds): to = kwds.pop("to", sys.stdout) for arg in args: to.write(arg) Py> printraw(format("$p1: $p2$to\n", 1, 2, to="There"), to=sys.stderr) 1: 2There - Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Barry Warsaw wrote: > On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote: > > >>But print-ng looks >>like becoming the OOWTDI for a lot of applications. IMO it's just too >>early to give up on print-ng becoming the one obvious way to do it for >>a lot of i18n apps, too. > > > +1. I have a gut feeling that we can make it easy for monolinguists to > use printng without caring or even knowing about i18n, but also make it > relatively painless to integrate i18n into an application or library. > However I haven't had time to really explore that idea. I found the following to be an interesting experiment: - from string import Template def format(*args, **kwds): fmt = args[0] kwds.update(("p%s" % idx, arg) for idx, arg in enumerate(args)) return Template(fmt).substitute(**kwds) Py> format("$p1: $p2", "Bee count", 0.5) 'Bee count: 0.5' - The leading 'p' (for 'positional') is necessary to get around the fact that $1 is currently an illegal identifier in a Template. If we actually did something like this, I would advocate adding the support for positional arguments directly to string.Template. For il8n output, you would be pulling the format string from somewhere else, so you would stick with the current idiom of using keyword arguments: - Py> fmt = "$item: $count" Py> format(fmt, item="Bee count", count=0.5) 'Bee count: 0.5' - There's also the cute-and-kinda-useless-but-it-also-justifies-the-1-based-indexing: - Py> format("Kinda cute: $p0") 'Kinda cute: Kinda cute: $p0' - Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Wed, 2005-09-07 at 05:23, Stephen J. Turnbull wrote: > But print-ng looks > like becoming the OOWTDI for a lot of applications. IMO it's just too > early to give up on print-ng becoming the one obvious way to do it for > a lot of i18n apps, too. +1. I have a gut feeling that we can make it easy for monolinguists to use printng without caring or even knowing about i18n, but also make it relatively painless to integrate i18n into an application or library. However I haven't had time to really explore that idea. -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
Re: [Python-Dev] Replacement for print in Python 3.0
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> Sure, we must provide good i18n support. But the burden on Guido> users who don't need i18n should be negligeable; they Guido> shouldn't have to type or know extra stuff that only exists Guido> for the needs of i18n. Agreed. That's best for i18n, too, if we can arrange a batteries- included approach to i18n at the same time. >> You're talking about Python 3.0; I don't know if it can be done >> within a reasonable amount of effort (and if not, too bad), but >> in that planning horizon it is surely worth some effort to find >> a solution. Guido> There seem to be many people interested in finding this Guido> solution; I see it as my task (among others) to make sure Guido> that their solution doesn't negatively affect the life of Guido> the majority of users who don't need it. Convenient as a Python optimized for i18n would be for me personally, I agree with that, too. But you wrote, "I'm not at all convinced that we should attempt to find a solution that handles both use cases; most Python code never needs i18n." And now, "That's too bad, [those who need i18n] will have to apply some global transformation to their code." It sounds to me like you have already decided that i18n applications will have to use a different way. But print-ng looks like becoming the OOWTDI for a lot of applications. IMO it's just too early to give up on print-ng becoming the one obvious way to do it for a lot of i18n apps, too. I realize that maybe it won't be solved for Python 3.0. Just, please don't close the door on it yet! Guido> Remember YAGNI! For-values-of-Y=I-A=am-ly y'rs, -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > It's true that the majority of Python applications never need i18n, > because they're only used in one language. But Python applications > are mostly assembled from a large and growing set of Python-standard > and other well-known libraries. It would be very useful to keep the > barriers to i18n-ization as low as possible to make those libraries as > broadly applicable as possible. Sure, we must provide good i18n support. But the burden on users who don't need i18n should be negligeable; they shouldn't have to type or know extra stuff that only exists for the needs of i18n. The same is true for many other needs of library authors and programming-in-the-large: programming-in-the-small should come first and foremost. We don't need another J2EE. > You're talking about Python 3.0; I don't know if it can be done within > a reasonable amount of effort (and if not, too bad), but in that > planning horizon it is surely worth some effort to find a solution. There seem to be many people interested in finding this solution; I see it as my task (among others) to make sure that their solution doesn't negatively affect the life of the majority of users who don't need it. Even if there's a class of users who think they don't need it and in the end find they do. That's too bad, they will have to apply some global transformation to their code. I hope that making print a function will help make that transformation easier. I've seen a couple of responses claiming that with good planning there won't be a need for such transformation (and consequently they don't need the changes I'm proposing). Well duh! I've never had perfect foresight. If you always plan ahead for what you might need, you inevitably end up writing an overly heavy framework. Remember YAGNI! -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes: Guido> I'm not at all convinced that we should attempt to find a Guido> solution that handles both use cases [print replacement Guido> and i18n]; most Python code never needs i18n. It's true that the majority of Python applications never need i18n, because they're only used in one language. But Python applications are mostly assembled from a large and growing set of Python-standard and other well-known libraries. It would be very useful to keep the barriers to i18n-ization as low as possible to make those libraries as broadly applicable as possible. You're talking about Python 3.0; I don't know if it can be done within a reasonable amount of effort (and if not, too bad), but in that planning horizon it is surely worth some effort to find a solution. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
> In the end the process is not democratic. Which may make it easier: rather than having to convince 50%+ of the people, one only has to convince a single person... > I don't think there's anything that can change my mind > about dropping the statement. As long as "I don't think there's anything" isn't "There isn't anything", there is still hope, and the potential that the one person's opinion that matters can be changed. However, when I wrote the email, I assumed you wouldn't read it (because you said you were leaving the discussion until there was a PEP). What I wanted to know was what the best way of putting together succinct, clear, reasons why you should change your mind would be, so that could be done. Even if you didn't change your mind, at least it would be (judging from previous decision reversals) the best shot. =Tony.Meyer ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum wrote: > So let's call it the "Swiss Army Knife > (...Not)" API design pattern. IIRC, this is one of the design principles which inspired Lisp mixins. The idea was that different interfaces should be separated into different classes. If you needed a class which combined them, you'd just mix two superclasses together. Bill ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
> LOL! That's a great solution for the 5 of us dinosaurs still using the > One True Editor. :) And who also still program in C now and then :-). I think there are more than 5 of us, though. Bill ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Michael Chermside wrote: > We could satisfy both people if in Python 2.x we introduced a > built-in function named "print30" (for Python 3.0) with the intended > new behavior. People could start coding now using the "print30" > builtin. When Python 3.0 was released, 'print' would no longer be > a keyword, and both 'print' and 'print30' would be built-ins that > both refered to the same function. -1000 It's ugly, and it doesn't help the transition whatsoever IMO. We *definitely* don't want a print30 function hanging around in Python 3.0 for backwards compatibility with the miniscule number of people who used it in Python 2.x. The simplest solution is (as already stated):: from __future__ import __print_function__ Tim Delaney ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum wrote: > On 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > >>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. > > > Is it worth doing this and completely dropping the %-based formats in > Py3k? (Just asking -- it might be if we can get people to get over the > shock of $ becoming first class ;-). > > >>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. > > > +1 > > I proposed ${varname%fmt} earlier but it prevents you to extend the > varname syntax to arbitrary expressions, which I think is an extension > that will get lots of requests. > I would anticipate security issues with allowing general expressions: you are effectively allowing access to eval(). If a naiive programmer were to use unverified input as a format string unpleasant things could happen ... your call, but it seems dangerous to me. Remember C's printf has been the source of some very dangerous errors. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido, I think this is a very nice summary of the arguments for removing print. Let's change the link in PEP 3000 to point to this message. Bill ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Please bear with me if this has already been stated, or if I ought to be directing this to the wiki instead of to python-dev at this point. I've been trying to follow this whole discussion but have only gotten as far as last Saturday. Two things: First of all, I wanted to encourage Guido. There have been lots of people objecting to "fixing" the print statement, but I for one agree that it's a wart which should be addressed if it can be done elegantly. I'm just not speaking up because others (particularly Guido) have already said most of what I am thinking and I don't want to clutter the discussion with "me too!"'s. And one thing which (as far as I've read) _IS_ a new suggestion. I agree that a new built-in function ought to be named 'print'. This poses problems for those who want to write code NOW that runs in Python 2.x (for large values of x) which will also run in 3.0. We could satisfy both people if in Python 2.x we introduced a built-in function named "print30" (for Python 3.0) with the intended new behavior. People could start coding now using the "print30" builtin. When Python 3.0 was released, 'print' would no longer be a keyword, and both 'print' and 'print30' would be built-ins that both refered to the same function. Sure, it's a tiny bit of backward compatibility cruft to have a second name for the builtin, but it may be worth it because the ability to write in the "Python 3.0 style" (all new-style classes, only raise proper exceptions, etc) in the 2.x series is a VERY useful feature. We want to handle the transition better than Perl. -- Michael Chermside ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
[Barry Warsaw wrote] > Also, we already have precedence in format+print in the logging > package. I actually think the logging provides a nice, fairly to use > interface that print-ng can be modeled on. The main reason for doing that in the logging package is for performance: processing the args into the format string can be deferred until the logging system knows that the log message will actually be used. I'm not saying that the separation of 'fmt' and args in the logging methods doesn't have the other benefit of clarity: log.debug("%s %s %s %s ...", arg1, arg2, arg3, really_really_long_arg4,) # nicer log.debug("%s %s %s %s ..." % (arg1, arg2, arg3, really_really_long_arg4)) # icky but the performance reason doesn't apply to the printf()/write() discussion here. Trent -- Trent Mick [EMAIL PROTECTED] ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Kay Schluehr wrote: > In the context of my proposal it seems to imply some variation of > Einsteins famous sentence: "Make everything as general as possible but > not more general" or "Make everything as powerfull as possible but not > more powerfull". I prefer McGrath's variation: "Things should be as complex as necessary but not more complex." ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
putting on my "on the other hand" hat for a moment... ::: Guido van Rossum wrote: > 1. It's always been there > 2. We don't want to type parentheses > 3. We use it a lot > 4. We don't want to change our code there's also: 5. A reserved word makes it easy to grep for (e.g. to weed out debugging prints before release). 6. It does the right thing under the hood: converts things to their string representation, calls write repeatedly instead of allocating a buffer large enough to hold all components, doesn't print un- necessary trailing spaces, etc. 7. Using a statement syntax makes it possible to use a readable syntax for redirection (and other possible extensions); it's obvious that this isn't printing to stdout: print >>file, bacon(ham), spam, "=", eggs(number=count) while print(bacon(ham), spam, "=", eggs(number=count), to=file) is a lot harder to parse, especially if you add more elements and print lines (how fast can you answer the question "do all these redirect to the same place" ?). 8. It can print to anything that implements a "write" method, no matter what it is or what other methods it implements. (etc) ::: and my "on the other hand" gloves... > - I quite often come to a point in the evolution of a program where I > need to change all print statements into logging calls, or calls into > some other I/O or UI library. never happens to me -- in my experience, good logging requires some basic design up front, so you might as well log via functions right from the start. print is reserved for debugging, tracing during development, and console-oriented scripts. I cannot recall ever having converted one of the latter to a component that needed logging. > - Having special syntax puts up a much larger barrier for evolution of > a feature. on the other hand, having special syntax gives you a lot more flexibility in coming up with readable, grokkable solutions. not everything fits into the callable paren list of comma separated stuff some of it with equal signs in it end paren pattern. > - There is a distinct non-linearity in print's ease of use once you > decide that you don't want to have spaces between items in practice, % is a great way to deal with this. > - If it were a function, it would be much easier to replace it within > one module (just def print(*args):...) or even throughout a program > (e.g. by putting a different function in __builtin__.print). if that's an important feature, what keeps us from adding a hook (along the lines of __import__) ? one could even argue that making it easier to override it locally may make it harder to override it globally; consider this local override: def print(fmt, *args): sys.stdout.write("MY MODULE SAYS " + fmt % args) print("blabla") with this in place, changing __builtin__.print will override everything except the prints in "MY MODULE"... so you end up doing a stdout redirect, just as in today's python. (etc) ::: ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Nick Coghlan wrote: > Greg Ewing wrote: > >>Guido van Rossum wrote: >> >> >>>So let's call it the "Swiss Army Knife >>>(...Not)" API design pattern. >> >> >>Aha! Maybe this is the long-lost 20th principle from >>the Zen of Python? > > > It also sounds like one of the reasons why the ultimates in programming swiss > army knives (that is, Lisp macros and Ruby blocks) are unlikely to make an > appearance in Python in their full, unconstrained 'glory'. . . In the context of my proposal it seems to imply some variation of Einsteins famous sentence: "Make everything as general as possible but not more general" or "Make everything as powerfull as possible but not more powerfull". The measure of possibility in this context may be serious community requirements. That's why I might have the impression that the language doesn't get any *deeper* but it is still very close to my actual work and highly usable. On the other hand I have to admit that I'm not really glad about 3 functions in favour for one statement. Introducing of a Writer object is just a different way of factoring and handling special cases and defaults. But I don't believe in an absolute truth about that. I'm not an OO stalinist. > There's an interesting comparison with UI design though - having a couple of > different tools in the interface with sensible default behaviour is generally > easier to use than a single tool where you have to tell it which behaviour > you > want all the time (or pick one as the default, and have to remember to tell > the application when you want the other behaviour). Hmm.. Guido cited strip, rstrip and lstrip for a good factoring into different functions. To me this is a limit case. It can become annoying soon and an API design antipattern. May I remember about C's vprintf, vfprintf, vsprintf, vsnprintf or the beauty of execl, execle, execlp, execlpe, execv, execve, execvp, execvpe? That's so grotesque that I feel deeply connected to Xah Lees crusade against UNIX in sudden moments ;) Kay ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Gareth McCaughan <[EMAIL PROTECTED]> wrote: > So borrow a trick from Common Lisp and use a destination of None > to mean "return the formatted text as a string". [...] > Or is that too cryptic? Yes. To my mind, formatting (returning a string) and output are separate operations. A "write formatted output" operation is a useful convenience method, but it's not the basic operation. Paul. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
> > On 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > > printf('$1 forgot to frobnicate the $2!\n', username, file.name, > > >to=sys.stderr) ... > For me, the problem with that proposal is not the precise format syntax, > but the fact that formatting is tied to a specific function which _also_ > outputs stuff to screen. So borrow a trick from Common Lisp and use a destination of None to mean "return the formatted text as a string". >>> x = printf("$2 $1", 123,321) 321 123 >>> print x None >>> x = printf("$2 $1", 123,321, to=None) >>> print x 321 123 Or is that too cryptic? -- g ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > Gnyagh, couldn't you have *started* the thread with that post? :) I hadn't anticipated so many great minds rusted shut. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum <[EMAIL PROTECTED]> writes: > On 9/3/05, Bill Janssen <[EMAIL PROTECTED]> wrote: >> So here's the summary of the arguments against: two style points >> (trailing comma and >>stream) (from the man who approved the current >> decorator syntax!), and it's hard to extend. (By the way, I agree that >> the ">>" syntax is ugly, and IMO a bad idea in general. Shame the "@" >> wasn't used instead. :-) >> >> Seems pretty weak to me. Are there other args against? > > Sure. I made the mistake of thinking that everybody knew them. [...] > But more important to me are my own experiences exploring the > boundaries of print. [...] Gnyagh, couldn't you have *started* the thread with that post? :) Cheers, mwh -- Get out your salt shakers folks, this one's going to take more than one grain. -- Ator in an Ars Technica news item ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum <[EMAIL PROTECTED]> wrote: [...] > OK, still with me? This, together with the observation that the only > use cases for the delimiter are space and no space, suggests that we > should have separate printing APIs for each of the use cases (a), (b) > and (c) above, rather than trying to fold (b) into (a) using a way to > parameterize the separator (and the trailing newline, to which the > same argument applies). For example: > > (a) print(...) > (b) printraw(...) or printbare(...) > (c) printf(fmt, ...) > > Each can take a keyword parameter to specify a different stream than > sys.stdout; but no other options are needed. The names for (a) and (c) > are pretty much fixed by convention (and by the clamoring when I > proposed write() :-). I'm not so sure about the best name for (b), but > I think picking the right name is important. Applying the same reasoning as above, why not remove the last remaining keyword parameter by adding fprint(ftobj,...) fprintraw( ftobj,...) and fprintf(ftobj,fmt,...) functions? -- rzed ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
(just my 2 cents) Le mardi 06 septembre 2005 à 07:23 -0700, Guido van Rossum a écrit : > On 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > > printf('$1 forgot to frobnicate the $2!\n', username, file.name, > >to=sys.stderr) > Is it worth doing this and completely dropping the %-based formats in > Py3k? (Just asking -- it might be if we can get people to get over the > shock of $ becoming first class ;-). For me, the problem with that proposal is not the precise format syntax, but the fact that formatting is tied to a specific function which _also_ outputs stuff to screen. There are really use cases where you want formatting without using a "print" function in conjunction. Web pages, sending notification e-mails, changing labels in GUI apps... anything that talks to the user in a different way than using stdout. IMO, printing and formatting must be distinct (*). And formatting should be convenient and i18n-friendly (i18n is more and more important in today's apps). (*) they should be treated separately in the discussion, anyway Regards Antoine. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum <[EMAIL PROTECTED]> wrote : > On 9/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Whenever the template definition and its use are not directly > > adjacent, the template is that much harder to understand (i.e., This `i.e.` should have read `e.g.` :-( > > in the context of translation, one wouldn't see the arguments > > passed to the template). > > The operative word being *whenever*. You're thinking of the i18n use > case, where the format string is separated from the arguments. I'm > thinking of the non-i18n use case, where the format isalmost always a > string *literal* adjacent to the arguments. I'm not at all convinced > that we should attempt to find a solution that handles both use cases; > most Python code never needs i18n. I often put format strings into class variables (to be overriden) or pass them around as arguments, which has nothing to do with i18n. And i18n is going to be more and more important (says this german speaker who always tries to get away with English programs :-) I'm all for allowing positional arguments but would badly miss named arguments. -- Christian Tanzerhttp://www.c-tanzer.at/ ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > 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. Is it worth doing this and completely dropping the %-based formats in Py3k? (Just asking -- it might be if we can get people to get over the shock of $ becoming first class ;-). > 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. +1 I proposed ${varname%fmt} earlier but it prevents you to extend the varname syntax to arbitrary expressions, which I think is an extension that will get lots of requests. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/6/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > I did a fair bit of tinkering with that on the weekend. Printing a sequence of > strings is fine - it's the call to "map(str, seq)" that makes printing a > sequence of non-strings uglier than it should be. Doing it that way also > breaks the Python idiom of letting unicode remain as unicode. Only of you insist on doing it in a single call. With an explicit for loop all is well. > However, one thing I eventually remembered was a discussion about a year ago > regarding the possibility of allowing str.join and unicode.join to accept > non-strings [1]. > > That discussion ended up leaving the join methods alone, because it is damn > hard to do it without slowing down the common case where the sequence is all > strings. > > I'm currently considering proposing a "joinany" method for str and unicode > which accepts a sequence of arbitrary objects (I have a patch, but it needs > unit tests and docs, and I'm uncomfortable with the amount of code duplication > between the join and joinany methods). Why not take an idea that Fredrik Lundh mentioned earlier, and have a built-in *function* named join() which takes a sequence and a string? joinany() is an ugly name. But what's still missing is a use case analysis where you prove that the use case is common enough to require explicit support. > This becomes especially clear once "sorted" and "list.sort" are given as > examples where the various keyword arguments do not change the basic invariant > properties of the sorting operations - you start with a sequence, and you end > up with essentially the same sequence, only in a different order. The keyword > arguments simply control the precise meaning of "different order". Thanks -- a very good example! > 'printraw' is good - it makes it clear it is part of the same family as > 'print' and 'printf', and explains succintly how it differs from the normal > print function. (Except that 'raw' could mean anything.) > Additionally, doing 'printraw' with 'printf' is a little tricky - the best > I've come up with is "printf('%s'*3, a, b, c)". Yeah, but often the real code you need to do is already written as print("x =", x, "y =", y, "z =", z) and that becomes more readable when you transform it to printf("x = %s y = %s z = %s\n", x, y, z) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/5/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Positional arguments remove too much meaning from the template. > > Compare: > > '$user forgot to frobnicate the $file!\n' > > with > > '$1 forgot to frobnicate the $2!\n' > > Whenever the template definition and its use are not directly > adjacent, the template is that much harder to understand (i.e., > in the context of translation, one wouldn't see the arguments > passed to the template). The operative word being *whenever*. You're thinking of the i18n use case, where the format string is separated from the arguments. I'm thinking of the non-i18n use case, where the format isalmost always a string *literal* adjacent to the arguments. I'm not at all convinced that we should attempt to find a solution that handles both use cases; most Python code never needs i18n. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Greg Ewing wrote: > Guido van Rossum wrote: > >>So let's call it the "Swiss Army Knife >>(...Not)" API design pattern. > > > Aha! Maybe this is the long-lost 20th principle from > the Zen of Python? It also sounds like one of the reasons why the ultimates in programming swiss army knives (that is, Lisp macros and Ruby blocks) are unlikely to make an appearance in Python in their full, unconstrained 'glory'. . . There's an interesting comparison with UI design though - having a couple of different tools in the interface with sensible default behaviour is generally easier to use than a single tool where you have to tell it which behaviour you want all the time (or pick one as the default, and have to remember to tell the application when you want the other behaviour). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum wrote: > So let's call it the "Swiss Army Knife > (...Not)" API design pattern. Aha! Maybe this is the long-lost 20th principle from the Zen of Python? Greg ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum wrote: > If there are other use cases they can obviously be coded by using (b) > and a modest amount of custom code. (I know there's the use case of > printing sequences; I'll try to give an analysis of this use case in > another post if one of its proponents doesn't do so soon.) I did a fair bit of tinkering with that on the weekend. Printing a sequence of strings is fine - it's the call to "map(str, seq)" that makes printing a sequence of non-strings uglier than it should be. Doing it that way also breaks the Python idiom of letting unicode remain as unicode. However, one thing I eventually remembered was a discussion about a year ago regarding the possibility of allowing str.join and unicode.join to accept non-strings [1]. That discussion ended up leaving the join methods alone, because it is damn hard to do it without slowing down the common case where the sequence is all strings. I'm currently considering proposing a "joinany" method for str and unicode which accepts a sequence of arbitrary objects (I have a patch, but it needs unit tests and docs, and I'm uncomfortable with the amount of code duplication between the join and joinany methods). [1] http://mail.python.org/pipermail/python-dev/2004-August/048516.html > Some examples of the design pattern in action are str.strip(), > str.lstrip() and str.rstrip(), or str.find() and str.rfind(). > > A much stronger subcase of this pattern (with fewer exceptions) is > that the return type of a function shouldn't depend on the value of an > argument. I have a feeling that if we were to extend the notion of > type to include invariants, you'd find that the basic pattern is > actually the same -- often the variant behaviors change the key > invariant relationships between input and output. This becomes especially clear once "sorted" and "list.sort" are given as examples where the various keyword arguments do not change the basic invariant properties of the sorting operations - you start with a sequence, and you end up with essentially the same sequence, only in a different order. The keyword arguments simply control the precise meaning of "different order". > (a) print(...) > (b) printraw(...) or printbare(...) > (c) printf(fmt, ...) Hmm, I like those names better than anything else that has come up so far. > Each can take a keyword parameter to specify a different stream than > sys.stdout; but no other options are needed. The names for (a) and (c) > are pretty much fixed by convention (and by the clamoring when I > proposed write() :-). I'm not so sure about the best name for (b), but > I think picking the right name is important. 'printraw' is good - it makes it clear it is part of the same family as 'print' and 'printf', and explains succintly how it differs from the normal print function. > We could decide not to provide (b) directly, since it is easily > reduced to (c) using an appropriate format string ("%s" times the > number of arguments). But I expect that use case (b) is pretty > important, and not everyone likes having to use format strings. This > could be reduced to a special case of the Swiss Army Knife (...Not) > rule. Additionally, doing 'printraw' with 'printf' is a little tricky - the best I've come up with is "printf('%s'*3, a, b, c)". > BTW we could use "from __future__ import printing" to disable the > recognition of 'print' as a keyword in a particular module -- this > would provide adequate future-proofing. Gah, sometimes I miss the most obvious of solutions. . . Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum <[EMAIL PROTECTED]> wrote: > 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). Positional arguments remove too much meaning from the template. Compare: '$user forgot to frobnicate the $file!\n' with '$1 forgot to frobnicate the $2!\n' Whenever the template definition and its use are not directly adjacent, the template is that much harder to understand (i.e., in the context of translation, one wouldn't see the arguments passed to the template). -- Christian Tanzerhttp://www.c-tanzer.at/ ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
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". 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. 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().) 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). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/5/05, Calvin Spealman <[EMAIL PROTECTED]> wrote: > There is a lot of debate over this issue, obviously. Now, I think > getting rid of the print statement can lead to ugly code, because a > write function would be called as an expression, so where we'd once > have prints on their own lines, that wouldn't be the case anymore, and > things could get ugly. Sounds like FUD to me. Lots of functions/methods exist that *could* be embedded in expressions, and never are. Or if they are, there's actually a good reason, and then being a mere function (instead of a statement) would actually be helpful. Anyway, why would it be important that prints are on their own line where so many other important actions don't have that privilege? > But, print is a little too inflexible. > What about adding a special name __print__, which the print statement > would call? It should be looked up as a local first, then global. > Thus, different parts of a program can define their own __print__, > without changing everyone else's stdout. The Python web people would > love that. Too many underscores; __print__ screams "internal use, don't mess" at you. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/1/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > [Charles Cazabon] > > >> Perhaps py3k could have a py2compat module. Importing it could have the > > >> effect of (for instance) putting compile, id, and intern into the global > > >> namespace, making print an alias for writeln, > > [Greg Ewing] > > > There's no way importing a module could add something that > > > works like the old print statement, unless some serious > > > magic is going on... > > [Reinhold Birkenfeld] > > You'd have to enclose print arguments in parentheses. Of course, the > > "trailing > > comma" form would be lost. > > And good riddance! The print statement harks back to ABC and even > (unvisual) Basic. Out with it! > > A transitional strategy could be to start designing the new API and > introduce it in Python 2.x. Here's my strawman: > > (1) Add two new methods the the stream (file) API and extend write(): > stream.write(a1, a2, ...) -- equivalent to map(stream.write, map(str, > [a1, a2, ...])) > stream.writeln(a1, a2, ...) -- equivalent to stream.write(a1, a2, ..., "\n") > stream.writef(fmt, a1, a2, ...) -- equivalent to stream.write(fmt % > (a1, a2, ...)) > > (2) Add builtin functions write(), writeln(), writef() that call the > corresponding method on sys.stdout. (Note: these should not just be > the bound methods; assignment to sys.stdout should immediately affect > those, just like for print. There's an important use case for this.) > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) There is a lot of debate over this issue, obviously. Now, I think getting rid of the print statement can lead to ugly code, because a write function would be called as an expression, so where we'd once have prints on their own lines, that wouldn't be the case anymore, and things could get ugly. But, print is a little too inflexible. What about adding a special name __print__, which the print statement would call? It should be looked up as a local first, then global. Thus, different parts of a program can define their own __print__, without changing everyone else's stdout. The Python web people would love that. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/5/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote: > > > We could decide not to provide (b) directly, since it is easily > > reduced to (c) using an appropriate format string ("%s" times the > > number of arguments). But I expect that use case (b) is pretty > > important, and not everyone likes having to use format strings. This > > could be reduced to a special case of the Swiss Army Knife (...Not) > > rule. > > I'm not sure. I do agree with your design principles (though I might > call it "Sometime's a Spoon's Just a Spoon" ;) but thinking about my own > uses of print, I think we could easily get away with just (a) and (c). > I think someone else felt the same way in an earlier response to my > strawman, pointing out that the inline Separator instances wasn't really > any more usable than just degenerating to the format string version. > There's no doubt that the format string approach gives you direct > control over every character. > > 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) > If I something stupid, I apologize; I have been swamped with orientation stuff while this entire discussion has been going on and so I am sure I have missed some of the finer details. I like the way the above works, but ``print(username, "forgot to frobicate the", file.name)`` just seems nicer for simple output. I do agree that there is a need for simple and formatted versions of print and that controlled output of numbers is important. And I also like the $ formatting so I wished there was a way to take what Barry did above but be able to do formatting, like ``${num:0.6f}`` or something and have that be the formatting version and just have the default be a call on str() for the substitution. > > BTW we could use "from __future__ import printing" to disable the > > recognition of 'print' as a keyword in a particular module -- this > > would provide adequate future-proofing. > > +1 +1 from me as well. -Brett ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Neil> In interactive mode, you are normally interested in the values of Neil> things, not their formatting so it does the right thing. >>> class Dumb: ... def __init__(self, val): ... self.val = val ... def __str__(self): ... return "" % self.val ... >>> d = Dumb(5) >>> d <__main__.Dumb instance at 0x11042d8> >>> print d It's just repr() vs. str(), but the difference can be significant in many circumstances. Skip ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Mon, 2005-09-05 at 20:52, Guido van Rossum wrote: > We could decide not to provide (b) directly, since it is easily > reduced to (c) using an appropriate format string ("%s" times the > number of arguments). But I expect that use case (b) is pretty > important, and not everyone likes having to use format strings. This > could be reduced to a special case of the Swiss Army Knife (...Not) > rule. I'm not sure. I do agree with your design principles (though I might call it "Sometime's a Spoon's Just a Spoon" ;) but thinking about my own uses of print, I think we could easily get away with just (a) and (c). I think someone else felt the same way in an earlier response to my strawman, pointing out that the inline Separator instances wasn't really any more usable than just degenerating to the format string version. There's no doubt that the format string approach gives you direct control over every character. 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) > BTW we could use "from __future__ import printing" to disable the > recognition of 'print' as a keyword in a particular module -- this > would provide adequate future-proofing. +1 -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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/5/05, Kay Schluehr <[EMAIL PROTECTED]> wrote: > [...] is the most heavyweight solution, but can encapsulate options and is > reusable: > > >>> Writer(sep="//").print("some","text") > some//text > > or > > writer = Writer(sep="//", file=sys.stderr) > writer.print("some","error-text") > writer.print("another","error text") I am disappointed to see several proposals plunge into this type of generality (no matter how cool it is in its application of OO design patterns) without asking whether there is a need. Look at the example -- it is completely useless. I only made it up so that I could present the simpler version; I didn't have a use case myself for arbitrary delimiters. My hypothesis is that there are actually only two use cases that matter enough to be supported directly: (a) quickly print a bunch of items with spaces in between them and a trailing newline (b) print one or more items with precise control over each character If there are other use cases they can obviously be coded by using (b) and a modest amount of custom code. (I know there's the use case of printing sequences; I'll try to give an analysis of this use case in another post if one of its proponents doesn't do so soon.) An additional use case that I am willing to entertain because there is a lot of prior art (like Python's logging package, Bill Janssen's note(), and of course many other languages) is format-directed printing. This can of course be reduced to use case (b) using the str.% operator, but it is common enough to at least *consider* providing a direct solution which avoids the pitfalls of the % operator. Call this use case (c). Interesting, use case (b) can also easily be reduced to use case (c)! In a different thread I mentioned a design principle for which I have no catchy name, but which has often helped me design better APIs. One way to state it is to say that instead of a single "swiss-army-knife" function with various options that choose different behavior variants, it's better to have different dedicated functions for each of the major functionality types. So let's call it the "Swiss Army Knife (...Not)" API design pattern. There are a number of reasons why this API design is often better. These aren't quite the same reasons why a real life Swiss Army knife is often inferior to individual tools, if you have them available, so the analogy isn't perfect. (So sue me. :-) * It reduces the number of parameters, which reduces the cognitive overhead for the human reader. (It also reduces function call overhead some; but that's not the main reason.) * It puts the hint about the specific variant functionality at the front rather than at the end, so it is less likely overlooked. * If one variant is much more common than others, it is easier to learn just that behavior. * In the (common) case where the options are Booleans, it's often confusing whether True or False switches a particular behavior on or off (especially if they are allowed to be specified as positional parameters). * A good test to discover that you should have used this pattern is when you find that the argument specifying a particular option is a constant at every call site (perhaps excluding API wrappers). This is a hint that the different variants of the functionality are catering to different use cases; often you'll find that substituting a different variant behavior just wouldn't work because the use that is made of the returned value expects a specific variant. Some examples of the design pattern in action are str.strip(), str.lstrip() and str.rstrip(), or str.find() and str.rfind(). A much stronger subcase of this pattern (with fewer exceptions) is that the return type of a function shouldn't depend on the value of an argument. I have a feeling that if we were to extend the notion of type to include invariants, you'd find that the basic pattern is actually the same -- often the variant behaviors change the key invariant relationships between input and output. OK, still with me? This, together with the observation that the only use cases for the delimiter are space and no space, suggests that we should have separate printing APIs for each of the use cases (a), (b) and (c) above, rather than trying to fold (b) into (a) using a way to parameterize the separator (and the trailing newline, to which the same argument applies). For example: (a) print(...) (b) printraw(...) or printbare(...) (c) printf(fmt, ...) Each can take a keyword parameter to specify a different stream than sys.stdout; but no other options are needed. The names for (a) and (c) are pretty much fixed by convention (and by the clamoring when I proposed write() :-). I'm not so sure about the best name for (b), but I think picking the right name is important. We could decide not to provide (b) directly, since it is easily reduced to (c) using an appropriate format string ("%s" times the number of arguments). But I expect that use case (b) is pretty important, and not
Re: [Python-Dev] Replacement for print in Python 3.0
Guido van Rossum wrote: > I see two different ways to support the two most-called-for additional > requirements: (a) an option to avoid the trailing newline, (b) an > option to avoid the space between items. > > One way would be to give the print() call additional keyword > arguments. For example, sep="//" would print double slashes between > the items, and sep="" would concatenate the items directly. And > end="\r\n" could be used to change the newline delimiter to CRLF, > while end="" would mean to suppress the newline altogther. > > But to me that API becomes rather klunky; I'd rather have a separate > function (printbare() or write()?) that just writes its arguments as > strings to sys.stdout (or to the file given with a keyword argument) > without intervening spaces or trailing newline. I guess there are three options: a) keyword arguments b) distributing similar functionality over several functions c) using an object for configuration In case a) I miss some visual clue. That's mostly because an arbitrary string is passed to print(). For this reason I like the current print statement in it's simplicity. b) maybe the least extendable solution but can be mixed with a) if necessary. c) is the most heavyweight solution, but can encapsulate options and is reusable: >>> Writer(sep="//").print("some","text") some//text or writer = Writer(sep="//", file=sys.stderr) writer.print("some","error-text") writer.print("another","error text") A bare print() can be considered as a call to some default_writer. Substituting the default_writer by some custom Writer object may replace the default configuration, which should be easily resetable: >>> Writer.default_writer = Writer(sep="//") >>> print("some","error-text") some//error_text >>> Writer.reset() >>> print("some","error-text") some error-text I think that reduces the weight of the object solution and enables all kind of configurations as user defined default. A lightweight print() is still possible: The print() function would be implemented like this: def print(*args): Writer.default_writer.print(*args) I appreciate very much functions that are just shortcuts for certain methods. For consistency reasons the function write() may be a better name choice then print(), but also a different name for Writer() would be an option in case of c). Kay ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 5 sep 2005, at 18.56, Stephan Deibel wrote: > On Mon, 5 Sep 2005, Martin Blais wrote: > >> However, there is an easy way out: hijack sys.stdout to forward to >> your logger system. >> I've got a web application framework that's setup like that right >> now, >> it works great (if you will not need the original print-to-stdout >> anymore in your program, that is). I print, it goes to the logfile. >> You just have to be careful where--in time-- you replace sys.stdout. >> > > Sure, and indeed I've done that often enough but it's kind of ugly and > doesn't help if you merge bodies of code where some stuff should go to > a log, some to stdout, some elsewhere. > > Hmm, maybe I'd end up avoiding the builtin print() as well, or at > least need to pass around the stream where I want output. The general > problem of not tying code to a particular output stream is what I'm > reacting to. Easy, just always print to a file-like object when you think you might have to switch destination later, and control the output from there: class Out: def write(self, text): # switch to logging here, or something sys.stdout.write(text) out = Out() print >>out, "I won't have to change this statement at all!" Print being a statement or a function doesn't matter in this case. Search- replacing is a bitch either way. //Simon ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Mon, 5 Sep 2005, Martin Blais wrote: > However, there is an easy way out: hijack sys.stdout to forward to > your logger system. > I've got a web application framework that's setup like that right now, > it works great (if you will not need the original print-to-stdout > anymore in your program, that is). I print, it goes to the logfile. > You just have to be careful where--in time-- you replace sys.stdout. Sure, and indeed I've done that often enough but it's kind of ugly and doesn't help if you merge bodies of code where some stuff should go to a log, some to stdout, some elsewhere. Hmm, maybe I'd end up avoiding the builtin print() as well, or at least need to pass around the stream where I want output. The general problem of not tying code to a particular output stream is what I'm reacting to. - Stephan ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/4/05, Stephan Deibel <[EMAIL PROTECTED]> wrote: > On Sun, 4 Sep 2005, Guido van Rossum wrote: > > But more important to me are my own experiences exploring the > > boundaries of print. > > > > - I quite often come to a point in the evolution of a program where I > > need to change all print statements into logging calls, or calls into > > some other I/O or UI library. [...] > > FWIW, this almost always happens to me. Although I've learned to > avoid print in most cases, it was a somewhat painful lesson that seems > quite at odds with how the rest of Python is designed -- usually, > stuff just works and you aren't led into such design traps. Happened to me too. However, there is an easy way out: hijack sys.stdout to forward to your logger system. I've got a web application framework that's setup like that right now, it works great (if you will not need the original print-to-stdout anymore in your program, that is). I print, it goes to the logfile. You just have to be careful where--in time-- you replace sys.stdout. cheers, ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Steven Bethard wrote: > >> > Use the print() method of sys.stderr: >> > >> >sys.stderr.print('error or help message') >> >> so who's going to add print methods to all file-like objects? > > The same people that added __iter__(), next(), readline(), readlines() > and writelines() to their file-like objects who did that? (you completely missed the point -- today's print mechanism works on *any* object that implements a "write" method, no just file objects. saying that "oh, all you need is to add a method" or "here's a nice mixin" doesn't give you a print replacement) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/3/05, Bill Janssen <[EMAIL PROTECTED]> wrote: > > Seems pretty weak to me. Are there other args against? > > Sure. I made the mistake of thinking that everybody knew them. Looks like I certainly didn't. These are good points, many of which I had missed. I withdraw my objections to print-as-function. These points should be added to the wiki. If no-one else gets to it, I'll do so this evening. Paul. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sun, 2005-09-04 at 22:32, Guido van Rossum wrote: > Right. I just have one additional suggestion for the logging package > (not sure if it should apply to printf as well): if there's a problem > with the format operator, fall back to printing the format string > followed by the argument values (if any) without any formatting -- > when logging, that's a much better thing to do than dying with an > exception. As I said, not sure if printf() should have the same > behavior; it's wort a try though. Cool idea, definitely worth a try. -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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/4/05, Barry Warsaw <[EMAIL PROTECTED]> wrote: > You can definitely argue about keeping formatting and print separate, > but I think Guido and others have explained the problems with %. To reiterate, "%s" % x is unsafe if you aren't sure that x can't be a tuple -- you'd have to write "%s" % (x,) if it can be one. Also, print("%s %s" % (a, b)) looks a bit ugly with the irregular punctuation. While I'm not going so far as to want a statement dedicated to printing, I'm not against having some redundancy for such an important piece of functionality. > Also, > we already have precedence in format+print in the logging package. I > actually think the logging provides a nice, fairly to use interface that > print-ng can be modeled on. Right. I just have one additional suggestion for the logging package (not sure if it should apply to printf as well): if there's a problem with the format operator, fall back to printing the format string followed by the argument values (if any) without any formatting -- when logging, that's a much better thing to do than dying with an exception. As I said, not sure if printf() should have the same behavior; it's wort a try though. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sun, 2005-09-04 at 22:06, James Y Knight wrote: > No, we certainly don't /need/ printf(), as is well proven by its > current absence. Having the operation of printing and the operation > of string formatting be separated is good, because it means you can > easily do either one without the other. I don't understand why you > want to combine these two operations. If it's % you object to, then > propose a fix for the actual problem: e.g. a "fmt" function for > formatting strings. (Which I would also object to, because I don't > believe % is a problem). But proposing "printf" just adds > complication for no purpose. It leaves % as a "problem" and adds a > new builtin which duplicates existing functionality. You can definitely argue about keeping formatting and print separate, but I think Guido and others have explained the problems with %. Also, we already have precedence in format+print in the logging package. I actually think the logging provides a nice, fairly to use interface that print-ng can be modeled on. -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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sun, 2005-09-04 at 11:59, Guido van Rossum wrote: > I agree that those are strong arguments, so please hear me out. Thanks Guido, I think your arguments are powerful too. -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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sat, 2005-09-03 at 22:08, Nick Coghlan wrote: > > See a (very quick and very dirty ;) strawman that I just posted to the > > wiki. I think this has some interesting semantics, including the > > ability to control the separator inline in a C++-like fashion. The > > writef() version also accepts string.Templates or %s-strings as its > > first argument. I'm not sure I like reserving 'to' and 'nl' keyword > > arguments, and not having the ability to print Separator instances > > directly, but OTOH maybe those aren't big deals. > > The latter problem is easily solved by calling str() at the point of the call > so that write() never sees the actual Separator object. Good point. > However, this 'inline' > behaviour modification has always annoyed me in C++ - if you want this kind of > control over the formatting, a format string is significantly clearer. You're probably right about that. > Separating the formatting out into a separate functions like this addresses > your concern with the namespace conflict for 'to' and 'nl', and also makes the > 'format' builtin more generally useful, as it can be used for cases other than > direct output to a stream. The downside being that you have to type more to get the behavior you want. It does have the advantage of solving the namespace problem. -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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sep 4, 2005, at 12:51 PM, Barry Warsaw wrote: > On Sat, 2005-09-03 at 12:51, James Y Knight wrote: > >> On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote: >> >> >>> So I think it's best to have two builtins: >>> >>> print(*args, **kws) >>> printf(fmt, *args, **kws) >>> >> >> It seems pretty bogus to me to add a second builtin just to apply the >> % operator for you. I've always really liked that Python doesn't have >> separate xyzf functions, because formatting is an operation you can >> do directly on the string and pass that to any function you like. >> It's much cleaner... >> > > Actually, we probably only /need/ printf(), and certainly for C > programmers (are there any of us left? ;), I think that would be a > small > conceptual leap. The motivation for keeping a non-formatting > version is > for simple cases, and beginners -- both of which use cases should > not be > dismissed. No, we certainly don't /need/ printf(), as is well proven by its current absence. Having the operation of printing and the operation of string formatting be separated is good, because it means you can easily do either one without the other. I don't understand why you want to combine these two operations. If it's % you object to, then propose a fix for the actual problem: e.g. a "fmt" function for formatting strings. (Which I would also object to, because I don't believe % is a problem). But proposing "printf" just adds complication for no purpose. It leaves % as a "problem" and adds a new builtin which duplicates existing functionality. James ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Meyer, Tony wrote: > "print" is the best example I can think of for "practicality beats purity". > > Writing to stdout is as common in the code I write as loops - it's worth > keeping such basic functionality as elegant, simple, easy to understand, > and easy to use as possible. If writing to stdout easily were the only goal, it could be achieved by making stdout a builtin and using stdout.write(...). -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Summarizing, my main problems with print as a statement are the > transformations -- when print doesn't cut it, you have to switch to > something entirely different. If it were a function the switch would > feel much smoother. I find that important: things that are > conceptually related should be syntactically related (within the realm > of common sense, as always). Letting go of my attachment to the status quo, I see a couple of reasons to make print syntactically a function that I had not noticed before. 1. In C, for instance, *all* I/O is done with functions. In Python, *almost all* I/O constructs are functions, but with one exception. This makes the language slightly harder to learn. Many newbies expect uniformity and many have posted code treating print as a function by adding the currently unneeded parentheses. They have to be taught the exception. 2. I/O constructs carry with them assumptions about the environment or peripherals of the computatonal entity. Print, in particular, assumes the presence of a special default character display device (ok, a stdout char stream). Making print a syntax contruct builds that assumption into the syntax. That violates separation of concern principles and makes Python slightly harder to port to systems for which that assumption is not true and for which 'print' might even be meaningless. So I disagree that printing lines of text is fundamental to computation as such. It is certainly no more fundamental than input. And I notice that no one has suggested that (raw)input should be turned into a statement ;-). Terry J. Reedy ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sun, 4 Sep 2005, Guido van Rossum wrote: > But more important to me are my own experiences exploring the > boundaries of print. > > - I quite often come to a point in the evolution of a program where I > need to change all print statements into logging calls, or calls into > some other I/O or UI library. [...] FWIW, this almost always happens to me. Although I've learned to avoid print in most cases, it was a somewhat painful lesson that seems quite at odds with how the rest of Python is designed -- usually, stuff just works and you aren't led into such design traps. - Stephan ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Let me correct two typos (I had to leave in a rush). [François Pinard] > [...] Let's consider that `print' (or whatever) is a Python function, > not negotiable. It should likely be. The "It" refers to `print' being a Python function, not the negotiability. > Logo and a few others also have parentheses-less function > calls, yet they may be week at handling functions as first-class > objects. s/week/weak/ -- François Pinard http://pinard.progiciels-bpi.ca ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Raymond Hettinger wrote: > [Barry] > >>Actually, we probably only /need/ printf(), and certainly for C >>programmers (are there any of us left? ;), I think that would be a > > small > >>conceptual leap. The motivation for keeping a non-formatting version > > is > >>for simple cases, and beginners -- both of which use cases should not > > be > >>dismissed. > > > +1 on Barry's proposal for two functions, one formatted and one plain. +1 There is ... >>> '%r+%r = %r'.__mod__((1,2,3)) '1+2 = 3' Ok, not exactly what he proposed. ;-) Is there a better named method that str.__mod__() calls? > However, I take issue with the premise that beginners do not need > formatting. Almost anyone, beginner or not, needs formatting when they > are working on a real application. My experience is that finance people > immediately try to format their output (habits from Excel). Most are > astonished at how non-trivial it is to add commas, dollar signs, > brackets, and a fixed number of decimal places. So, I think beginners > should be considered a key constituent for output formatting and that > their needs should be accommodated as simply and broadly as possible. I agree, and the next thing programmers with previous experience look for is formatted input. Ok, not the very next thing. :-) Cheers, Ron ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
[Guido van Rossum] > [...] print is the only application-level functionality that has a > statement dedicated to it. Within Python's world, syntax is generally > used as a last resort, when something *can't* be done without help > from the compiler. Print doesn't qualify for such an exception (quite > the opposite actually). As I much liked Pascal in its time, `write()' and `writeln()' are nothing awkward to me, yet in Pascal, neither was a "regular" function, and the Pascal compiler had special code for parsing these two. Python functions are designed in such a way that `write()' and `writeln()' in Python could be just functions, with no special compiler stunt, and consequently, they fit even better for Python than they did for Pascal. Let's consider that `print' (or whatever) is a Python function, not negotiable. It should likely be. If people resent the parentheses that a new `print' would impose, then it might mean they would like that there is to be some way so Python functions could be be callable without parentheses in a more general way. It would represent quite a change in the syntax, and pull with it its own flurry of problems; but nevertheless, a seek for such a change might be presented as the only way for introducing `print' in Python 3K without a need for parentheses. Perl, going from version 4 to version 5, was subject to a cleanup between operators and functions which could be seen as similarly encompassing. Logo and a few others also have parentheses-less function calls, yet they may be week at handling functions as first-class objects. (And besides, I'm far from overly liking them! :-). -- François Pinard http://pinard.progiciels-bpi.ca ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/4/05, Tony Meyer <[EMAIL PROTECTED]> wrote: > > Yes. If it didn't have the redirect stuff; I would like it more if it also > didn't have the trailing comma magic. "print" is a fundamental; it deserves > to be a statement :) I don't know exactly what you mean by "fundamental", in opposition to your statement, I just see it as oft-used application-level code that should not live in "the language" (the set of statements that defines control flow and basic data structures) per-se, but in a library. ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
[Barry] > Actually, we probably only /need/ printf(), and certainly for C > programmers (are there any of us left? ;), I think that would be a small > conceptual leap. The motivation for keeping a non-formatting version is > for simple cases, and beginners -- both of which use cases should not be > dismissed. +1 on Barry's proposal for two functions, one formatted and one plain. However, I take issue with the premise that beginners do not need formatting. Almost anyone, beginner or not, needs formatting when they are working on a real application. My experience is that finance people immediately try to format their output (habits from Excel). Most are astonished at how non-trivial it is to add commas, dollar signs, brackets, and a fixed number of decimal places. So, I think beginners should be considered a key constituent for output formatting and that their needs should be accommodated as simply and broadly as possible. Raymond Finance Guy ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sat, 2005-09-03 at 13:12, Martin Blais wrote: > (defun python-abbrev-print () > "Help me change old habits." > (insert "print()") (backward-char 1) t) > (put 'python-abbrev-print 'no-self-insert t) > (define-abbrev python-mode-abbrev-table "print" "" 'python-abbrev-print) LOL! That's a great solution for the 5 of us dinosaurs still using the One True Editor. :) -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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sat, 2005-09-03 at 14:42, Paul Moore wrote: > I have to agree. While I accept that Barry has genuine use cases for > the printf form, I don't quite see why %-formatting isn't enough. Is > the print-plus-% form so much less readable and/or maintainable? IMO, yes. I can't tell you how many times I've typo'd logger messages by switching commands and percents. -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
Re: [Python-Dev] Replacement for print in Python 3.0
On Sat, 2005-09-03 at 12:51, James Y Knight wrote: > On Sep 3, 2005, at 11:32 AM, Barry Warsaw wrote: > > > So I think it's best to have two builtins: > > > > print(*args, **kws) > > printf(fmt, *args, **kws) > > It seems pretty bogus to me to add a second builtin just to apply the > % operator for you. I've always really liked that Python doesn't have > separate xyzf functions, because formatting is an operation you can > do directly on the string and pass that to any function you like. > It's much cleaner... Actually, we probably only /need/ printf(), and certainly for C programmers (are there any of us left? ;), I think that would be a small conceptual leap. The motivation for keeping a non-formatting version is for simple cases, and beginners -- both of which use cases should not be dismissed. The reason I proposed two versions is because I'd really dislike putting the format string in any position other than the first positional argument, and I can't think of a way to definitively distinguish between whether a first arg string is or is not a format string. One possible way out is to define a string literal that creates Template strings, and then make the Template string syntax rich enough to cover today's %-substitutions. Then if the first argument is a Template, you do printf()-like output otherwise you do print()-output. -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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/3/05, Bill Janssen <[EMAIL PROTECTED]> wrote: > So here's the summary of the arguments against: two style points > (trailing comma and >>stream) (from the man who approved the current > decorator syntax!), and it's hard to extend. (By the way, I agree that > the ">>" syntax is ugly, and IMO a bad idea in general. Shame the "@" > wasn't used instead. :-) > > Seems pretty weak to me. Are there other args against? Sure. I made the mistake of thinking that everybody knew them. But let me first summarize the arguments I've heard for keeping print as a statement: 1. It's always been there 2. We don't want to type parentheses 3. We use it a lot 4. We don't want to change our code I agree that those are strong arguments, so please hear me out. There is a theoretical argument: print is the only application-level functionality that has a statement dedicated to it. Within Python's world, syntax is generally used as a last resort, when something *can't* be done without help from the compiler. Print doesn't qualify for such an exception (quite the opposite actually). But more important to me are my own experiences exploring the boundaries of print. - I quite often come to a point in the evolution of a program where I need to change all print statements into logging calls, or calls into some other I/O or UI library. If print were a function, this would be a straightforward string replacement; as it is, finding where to add the parentheses is often a pain (the end isn't always on the same line as the start). It's even worse if there are already ">>stream" options present. Trailing commas also make this more complicated than it needs to be. - Having special syntax puts up a much larger barrier for evolution of a feature. For examle, adding printf (or changing print to printf) is a much bigger deal now that print is a statement than if it had been a built-in function: trial implementations are much more work, there are only a few people who know how to modify Python's bytecode compiler, etc. (Having printf() be a function and print remain a statement is of course a possibility, but only adds more confusion and makes printf() a second-class citizen, thereby proving my point.) - There is a distinct non-linearity in print's ease of use once you decide that you don't want to have spaces between items; you either have to switch to using sys.stdout.write(), or you have to collect all items in a string. This is not a simple transformation, consider what it takes to get rid of the spaces before the commas in this simple example: print "x =", x, ", y =", y, ", z =", z If it was a built-in function, having a built-in companion function that did a similar thing without inserting spaces and adding a newline would be the logical thing to do (or adding keyword parameters to control that behavior; but I prefer a second function); but with only print as it currently stands, you'd have to switch to something like print "x = " + str(x) + ", y = " + str(x) + ", z = " + str(z) or print "x = %s, y = %s, z = %s" % (x, y, z) neither of which is very attractive. (And don't tell me that the spaces are no big deal -- they aren't in *this* example, but they are in other situations.) - If it were a function, it would be much easier to replace it within one module (just def print(*args):...) or even throughout a program (e.g. by putting a different function in __builtin__.print). As it is, you can do this by writing a class with a write( ) method and assigning that to sys.stdout -- that's not bad, but definitely a much larger conceptual leap, and it works at a different level than print. Summarizing, my main problems with print as a statement are the transformations -- when print doesn't cut it, you have to switch to something entirely different. If it were a function the switch would feel much smoother. I find that important: things that are conceptually related should be syntactically related (within the realm of common sense, as always). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Keeping print as a statement is certainly one of the options I'm considering, > so I don't think a counter-PEP is warranted just yet. There isn't even a PEP > to be a counter to - it's all still on the Wiki at the moment. I am so far a bit disappointed by the wiki contents; I'm hoping on more of a summary of the argumentation and use cases; instead, I found wild proposals that have zero chance of making it. > The more I play with it, the more I believe the part I have a problem with is > a weakness in the string formatting for iterables. I've noticed. I think you should cool down a bit about this. Automatically consuming iterables can have serious side effects (like reading a file to the end!), which you generally want to avoid. Putting complex syntax in %xyz format strings for iterators seems like a poor choice of tool -- it is already complex and brittle. All *my* sequence printing needs are generally met by a simple for loop or ",".join(...). If that's still too much typing for you, and you really think that the use case of printing all items in an iterable is common enough to warrant standard library support, I'd suggest something along these lines: def printseq(seq, sep=" ", to=None): if to is None: to = sys.stdout # dynamic default firsttime = True for item in seq: if firsttime: firsttime = False else: printbare(sep, to=to) printbare(item, to=to) # printbare() is just a suggestion; I'm not too happy with the name. > The point about not needing parentheses for conditionals where a lot of other > languages require them is a good one - I'm sure I write print statements > nearly as often as I write conditionals. I'm sad to see that all the good software engineering habits are dropped the moment people have to type a pair of extra parentheses. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/3/05, Tony Meyer <[EMAIL PROTECTED]> wrote: > If there are two competing proposals, then the two groups write a PEP and > counter-PEP and the PEPs duke it out. Is this still the case if proposal B > is very nearly the status quo? No. The primary argument is between keeping the print statement and doing something else; only when "doing something else" is rejected we should concentrate on smaller improvements to the statement. The possibility of improving the statement isn't going to sway me. > IOW, would writing a "Future of the print statement in Python 3.0" counter > PEP that kept print as a statement be appropriate? If not, other than > python-dev posting (tiring out the poor summary guys <0.5 wink>), what is > the thing to do? In the end the process is not democratic. I don't think there's anything that can change my mind about dropping the statement. I have my preferences about the replacement too, but that's where I need others to weigh in so we make sure all the important use cases are covered. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Gareth McCaughan: > >Interactive use is its own mode and works differently to the base > > language. To print the value of something, just type an expression. > > Doesn't do the same thing. In interactive mode, you are normally interested in the values of things, not their formatting so it does the right thing. If you need particular formatting or interpretation, you can always achieve this. > Do you have any suggestion that's as practically usable > as "print"? The print function proposal is already as usable as the print statement. When I write a print statement, I'd like to be able to redirect that to a log or GUI easily. If print is a function then its interface can be reimplemented but users can't add new statements to Python. Creation of strings containing values could be simplified as that would be applicable in many cases. I actually like being able to append to strings in Java with the second operand being stringified. Perhaps a stringify and catenate operator could be included in Python. Like this: MessageBox("a=" ° a ° "pos=" ° x°","°y) Neil ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Tony Meyer wrote: > [Nick Coghlan] > >>"Print as statement" => printing sequences nicely is a pain > > > What's wrong with this? > > print range(10) > > [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] > print tuple("string") > > ('s', 't', 'r', 'i', 'n', 'g') > > This is a serious question - that's how I would expect a print function to > work anyway. Py> print (x*x for x in range(10)) Oh, wait, this is what I actually meant: Py> print " ".join(map(str, (x*x for x in range(10 0 1 4 9 16 25 36 49 64 81 Printing the contents of an arbitrary iterable is harder than it should be. Many iterables (including the builtin ones) have a reasonable default display, but a non-default display (e.g. linefeed separated instead of comma separated) isn't the most obvious thing to express. I thought making print a function solved that problem, but it doesn't really. So I'm currently exploring a different approach involving string formatting. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Tony Meyer wrote: > [...] > >>maybe a few folks can go off and write up a PEP for a >>print-replacement. > > [...] > >>I'm pulling out of the >>discussion until I see a draft PEP. > > > If there are two competing proposals, then the two groups write a PEP and > counter-PEP and the PEPs duke it out. Is this still the case if proposal B > is very nearly the status quo? > > IOW, would writing a "Future of the print statement in Python 3.0" counter > PEP that kept print as a statement be appropriate? If not, other than > python-dev posting (tiring out the poor summary guys <0.5 wink>), what is > the thing to do? Keeping print as a statement is certainly one of the options I'm considering, so I don't think a counter-PEP is warranted just yet. There isn't even a PEP to be a counter to - it's all still on the Wiki at the moment. The more I play with it, the more I believe the part I have a problem with is a weakness in the string formatting for iterables. The point about not needing parentheses for conditionals where a lot of other languages require them is a good one - I'm sure I write print statements nearly as often as I write conditionals. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
[...] > maybe a few folks can go off and write up a PEP for a > print-replacement. [...] > I'm pulling out of the > discussion until I see a draft PEP. If there are two competing proposals, then the two groups write a PEP and counter-PEP and the PEPs duke it out. Is this still the case if proposal B is very nearly the status quo? IOW, would writing a "Future of the print statement in Python 3.0" counter PEP that kept print as a statement be appropriate? If not, other than python-dev posting (tiring out the poor summary guys <0.5 wink>), what is the thing to do? =Tony.Meyer ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
[Nick Coghlan] > "Print as statement" => printing sequences nicely is a pain What's wrong with this? >>> print range(10) [0, 1, 2, 3, 4, 5, 6, 7, 8, 9] >>> print tuple("string") ('s', 't', 'r', 'i', 'n', 'g') This is a serious question - that's how I would expect a print function to work anyway. > "Print as statement" => can't easily change the separator [etc] To me, the point of the builtin print is that it's simple. If you want to control what separator is used, or if there is a newline at the end, or print to something that isn't sys.stdout, or some other magic, then use sys.stdout.write(). If you want to get the contents of __unicode__/__str__ of an object to stdout, which there has been overwhelming evidence is a very common task, then print is a fantastically simple and straightforward way to do that. [Terry Reedy] > For quickly adding debug prints, two extra ()s are a small burden, > but if the function were called 'out', then there would still be just five > keystrokes. But seven keypresses (assuming one is using a keyboard where you use shift to get '(' and ')'). It sounds trivial, but a print statement (i.e. no ()) looks clean and concise. I like this: while True: pass More than: while (true) {} For the same reason. This is a big plus of Python vs. C. [Guido] > Consider this: if Python *didn't* have a print statement, but > it had a built-in function with the same functionality > (including, say, keyword parameters to suppress the trailing > newline or the space between items); would anyone support a > proposal to make it a statement instead? Yes. If it didn't have the redirect stuff; I would like it more if it also didn't have the trailing comma magic. "print" is a fundamental; it deserves to be a statement :) =Tony.Meyer ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Bill Janssen wrote: > I think what Nick really is asking for is a better print statement -- > and there's no particularly good reason to move to a function to > attain that end. Well one reason (you can judge for yourself whether it's "good" or not) is that adding more syntax to the print statement will make Python's parser more complex, while converting the print statement to a function should make Python's parser simpler. STeVe -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy ___ 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
Re: [Python-Dev] Replacement for print in Python 3.0
Nick Coghlan wrote: > Nick Coghlan wrote: > >>I agree with this point actually. There should be an "iterable" formatting >>code that looks something like "%[sep]i" >> >>Then "%i" % (my_seq,) would be the equivalent of "".join(my_seq), only >>allowing it to be easily embedded inside a larger format string. >> >>Some other examples: >>("% i" % my_seq) => " ".join(my_seq) >>("%, i" % my_seq) => ", ".join(my_seq) >> >>I see this as being similar to the way that "%.2f" controls the way that a >>floating point value is displayed. > > > A correction to this - such a formatting operator would need to automatically > invoke str on the items in the iterable: > > ("%i" % (my_seq,)) => "".join(map(str, my_seq)) > ("% i" % (my_seq,)) => " ".join(map(str, my_seq)) > ("%, i" % (my_seq,)) => ", ".join(map(str, my_seq)) > ("%(seq), i" % dict(seq=my_seq)) => ", ".join(map(str, my_seq)) Hmm, 'i' is already taken. I think I'll use 'j for join' while working on a patch. The full specification of the number formatting operations is impressive, though (this is the first time I've actually read the full description of the string formatting behaviour). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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