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
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
(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 pre and /pre (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
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
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
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. /F ___ 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
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 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, 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=detailaid=1098749group_id=5470atid=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
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
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 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 ${value:format:more-format}
where value is an identifier (but someday might allow expressions),
and format and more-format 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
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
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 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
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(?:
(?Pescaped%(delim)s) | # An escape sequence of two delimiters, or
(
(\[(?Pformat[^%%]*)\])? # an optional simple format string,
(
(?Pnamed%(id)s) | # and a Python identifier, or
{(?Pbraced%(id)s)} # a braced identifier
)
) |
(?Pinvalid) # 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
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
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 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
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
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 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
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
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 stdin, line 1, in ? File stdin, line 3, in printf File stdin, 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
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
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
Guido == Guido van Rossum [EMAIL PROTECTED] writes: Guido intermezzo 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
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
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
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: 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
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
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
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/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
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
(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: [...] 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
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
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
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, 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
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
[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
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
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
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
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 == 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
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
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)
/F
___
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 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
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 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)! intermezzo 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. /intermezzo 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 everyone likes
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
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 Dumb val=%s % self.val ... d = Dumb(5) d __main__.Dumb instance at 0x11042d8 print d Dumb val=5 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 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
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:
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
[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
[...] 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
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
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))
generator object at 0x00AE71C0
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
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
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
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, 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 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 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 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
[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 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
[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 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
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
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
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
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 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 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 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
Steven Bethard wrote:
- Error and help messages, often with print sys.stderr
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?
/F
___
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
Martin Blais wrote: On 9/2/05, Phillip J. Eby [EMAIL PROTECTED] wrote: At 11:02 AM 9/3/2005 +1000, Nick Coghlan wrote: Printing the items in a sequence also becomes straightforward: print .join(map(str, range(10))) = output(*range(10)) Playing well with generator expressions comes for free, too: print .join(str(x*x) for x in range(10)) = output(*(x*x for x in range(10))) An implementation issue: that generator expression will get expanded into a tuple, so you shouldn't use that for outputting large sequences. Then how about:: output(*(x*x for x in range(10)), iter=1) Illegal in python2.4.(Wrongly ?) And makes the star solution half unuseful. def f(*args,**kwargs): ... pass ... f(*(1,2,3),iter=True) File stdin, line 1 f(*(1,2,3),iter=True) Leaving out what I just asserted in the previous thread :( I suppose you meant output((x*x for x in range(10)), iter=1) f(1,[2,3],(_ for _ in (4,5)),iter=True) Regards Paolino ___ 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, Guido van Rossum [EMAIL PROTECTED] wrote: Wow. With so many people expressing a gut response and not saying what in the proposal they don't like, it's hard to even start a response. Fair point. Is it... - Going from statement to function? I thought this was a major issue, but Nick Coghlan's output() function has persuaded me otherwise. Now, I'd say I was more concerned about going from *one* statement to *six* functions (the number you explicitly referred to in your posting - 3 methods and 3 builtins - but I'd be willing to concede that the exact number needed is vague, not least because the write method already exists...) - Losing the automatically inserted space? This was important to me. - Having to write more to get a newline appended? Not so much more as ugly - the function name writeln reminds me of Pascal (not a good thing!), and an explicit \n obscures the main intent of the code. - Losing the name 'print'? Not a big deal, but it seems gratuitous. Some responses seemed to have missed (or perhaps for stronger rhetorical effect intentionally neglected) that I was proposing builtins in addition to the stream methods, The opposite - to me, that just increases the number of proposed functions, which is one of my objections :-) I'd like to be flexible on all points *except* the syntax -- I really want to get rid of print as a *statement*. OK, how about a *single* builtin, named print, which works something like Nick Coghlan's proposal (I'm happy to fiddle with the details, but the basic principle is that it can do all the variations the print statement can currently do - plus extra, in the case of Nick's code). It should rely solely on a stream having a write method (so there's no change to the file-like object interface, and existing objects don't need to be changed to support the new proposal). If you really want a stream.print method, I can cope, as long as it's clear that it's an *optional* part of the file-like interface - after all, it's a convenience method only. A mixin providing it might work, but I've no idea how you'd do a mixin which file-like objects implemented in C could use... A name other than print for the new builtin has the benefit that it could be introduced now, with Python 3.0 merely removing the print statement in its favour. But there isn't really a name I like as much as print, and at least you *know* that no-one is using variable names that would hide a print builtin :-) 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? No - and if that builtin was what you had proposed, you may not have got such a negative reaction :-) 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/3/05, Nick Coghlan [EMAIL PROTECTED] wrote: [...] Playing well with generator expressions comes for free, too: print .join(str(x*x) for x in range(10)) = output(*(x*x for x in range(10))) Hmm... This prompts a coding question - is it possible to recognise which arguments to a function are generators, so that you could write output(1, 2, [3,4], (c for c in 'abc'), 'def', (5, 6)) and get 1 2 [3, 4] a b c def (5, 6) ? At the simplest level, an explicit check for types.GeneratorType would work, but I'm not sure if there's a more general check that might might work - for example, iter((1,2,3)) may be a candidate for looping over, where (1,2,3) clearly (? :-)) isn't. Maybe iter(arg) is arg is the right check... Of course, there's a completely separate question as to whether magic this subtle is *advisable*... 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/3/05, Paolino [EMAIL PROTECTED] wrote: Martin Blais wrote: Then how about:: output(*(x*x for x in range(10)), iter=1) Illegal in python2.4.(Wrongly ?) And makes the star solution half unuseful. def f(*args,**kwargs): ... pass ... f(*(1,2,3),iter=True) File stdin, line 1 f(*(1,2,3),iter=True) Leaving out what I just asserted in the previous thread :( I suppose you meant output((x*x for x in range(10)), iter=1) f(1,[2,3],(_ for _ in (4,5)),iter=True) Yes, that's right, my bad, I indeed meant your corrected version above (forgot to remove the star) ___ 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
Paul Moore wrote:
Hmm... This prompts a coding question - is it possible to recognise
which arguments to a function are generators, so that you could write
output(1, 2, [3,4], (c for c in 'abc'), 'def', (5, 6))
and get
1 2 [3, 4] a b c def (5, 6)
?
At the simplest level, an explicit check for types.GeneratorType would
work, but I'm not sure if there's a more general check that might
might work - for example, iter((1,2,3)) may be a candidate for looping
over, where (1,2,3) clearly (? :-)) isn't. Maybe iter(arg) is arg is
the right check...
Of course, there's a completely separate question as to whether magic
this subtle is *advisable*...
If an iterator wants to behave like that, the iterator should define the
appropriate __str__ method. Otherwise, just break it up into multiple lines:
write(1, 2, [3,4])
write(*(c for c in 'abc'))
writeln('def', (5, 6))
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
Nick Coghlan wrote:
If an iterator wants to behave like that, the iterator should define the
appropriate __str__ method. Otherwise, just break it up into multiple lines:
write(1, 2, [3,4])
write(*(c for c in 'abc'))
This cannot accept keyword args(I wonder if this is a bug), which makes
it a non compatible solution with the rest of yours.
writeln('def', (5, 6))
Regards Paolino
___
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
Paolino wrote: Nick Coghlan wrote: If an iterator wants to behave like that, the iterator should define the appropriate __str__ method. Otherwise, just break it up into multiple lines: write(1, 2, [3,4]) write(*(c for c in 'abc')) This cannot accept keyword args(I wonder if this is a bug), which makes it a non compatible solution with the rest of yours. Actually, it's an ordering quirk in the parser - the extended call syntax stuff has to come last in the function call, which means we need to put the keyword arguments at the front: Py writeln(sep=', ', *(x*x for x in range(10))) 0, 1, 4, 9, 16, 25, 36, 49, 64, 81 I personally believe keyword arguments should be allowed between *args and **kwds at the call site, and keyword-only arguments after * in the function definition, but the current behaviour has never bothered me enough for me to look into what would be required to change it. 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 Fri, 2005-09-02 at 21:42, Guido van Rossum wrote:
With so many people expressing a gut response and not saying what in
the proposal they don't like, it's hard to even start a response. Is
it...
- Going from statement to function?
So I ignored my visceral reaction against the proposal and actually
converted some code in our commercial app (if I have time I might look
at some code in Mailman) to try to understand why I disliked the
proposal so much.
I do hate having to write two parentheses -- it's more than the extra
keystrokes. It's that I have to use two shifted characters and I have
to be sure to close the construct, which can be a PITA when the start of
the function call is separated from the end by many lines.
What I found is that while this can be a real annoyance for some code,
there are some beneficial trade-offs that make this palatable. I
haven't read all the concrete proposals for the print() function, but
assuming it's something like the logger, it's very nice not to have to
do the %-operation explicitly. A very common case in my code is to have
a format string followed by a bunch of arguments, and including an
output stream. IWBNI could do something like this:
printf(\
ERROR: Failed to import handler %s for function %s in file %s.
Improperly formed foobar string.,
handler, function, file,
to=sys.stderr)
The other use case is where I don't have a format string and there, a
straight translation to
print('WAUUGH! object:', obj, 'refcounts:', sys.getrefcount(obj))
print('Finishing frobnication...', nl=False)
isn't horrible, although this looks kind of goofy to get a blank line:
print()
So for permanent code, I think it's a decent trade-off. We lose
something but we gain something. I'll mourn the syntax highlighting
loss (or end up hacking python-mode) but oh well.
I still suspect that a print function will be less friendly to newbies
and casual programmers. I can't test that, but I would love it if one
of the educators on this list could conduct some usability studies on
the issue.
I also suspect that having to use a function will every-so-slightly
impede the debug-to-console use of print. I haven't played with that
idea much, but I'll try it next time I'm doing something like that.
- Losing the automatically inserted space?
Yes, definitely for the non-format-string variety. The two things I
hate most about Java's way is having to concatenate a string and having
to include the space myself. It's highly error-prone and ugly.
Above all else, /please/ avoid the forehead-welt-tool which is
System.out.println().
- Having to write more to get a newline appended?
Yes, definitely. In everything I've converted, it's much more common to
want the newline than not. I want an easy way to suppress the newline,
but I'm willing to write nl=False to get that.
- Losing the name 'print'?
I'm mixed on this. OT1H, I like print() better than write() but OTOH, I
can imagine that a decade of muscle memory will be hard to overcome.
Some responses seemed to have missed (or perhaps for stronger
rhetorical effect intentionally neglected) that I was proposing
builtins in addition to the stream methods, so that all those debug
prints would be just as easy to add as before. And I don't think I
ever said print was only for newbies!
I know we'll have built-ins, but I disagree that debug prints will be
just as easy. Clearly they won't be, the question is to what degree
they will be harder to write and what benefit you will get in trade. If
those answers are only a little bit and a lot, it will probably be
acceptable.
I'd like to be flexible on all points *except* the syntax -- I really
want to get rid of print as a *statement*.
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?
Probably not, but such an alternative universe is hard to imagine, so
I'm not sure it would have dawned on anyone to suggest it. I think the
right approach is to design and add the replacement for Python 2.x,
encourage people to use it, and then see if it still warrants removal of
the print statement for Python 3.0.
fwiw-ly y'rs,
-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
So, another round.
* Gratuitous breakage: IMO it's not gratuitous. The *extensions* to
the print statement (trailing comma, stream) are ugly, and because
it's all syntax, other extensions are hard to make. Had it been a
function from the start it would have been much easier to add keyword
args, for example.
* Neal brought up the possibility of a conversion tool and wondered
how perfect it could be. Because it's currently syntax, this is a rare
case where the conversion can easily be made perfect (assuming the
tool has a complete Python parser). The only thing that wouldn't
necessarily be translated perfectly would be code manipulating
softspace directly.
* The possibility of future-proofing: I don't believe that this was a
major reason for the negative responses; after all, once we settle on
the function names functionality, we can add the functions to 2.5
and people can start using them at their leisure. (This was actually
why I proposed different names.)
* Don't break it just because it's too much like Basic or ABC? I never
meant it that way. In ABC, WRITE was actually *more* like a procedure
call, because procedure calls in ABC don't use parentheses. I think
the old Basic wasn't such a bad language as its reputation would like
to have it; it was fully interactive, and quite good for teaching. The
problem that the ABC authors were mainly fighting was arbitrary
limitations and lack of structured programming support -- for example,
old Basic implementations often had 1- or 2-char variable names only,
heavily relied on GOTO, and there were no locals. The ABC authors also
made a slogan of getting rid of PEEK and POKE, but ABC never did
provide a replacement for interacting with the environment or
graphics. Basic's WRITE statement (in the version that I remember) had
to be a statement because there were no predefined procedures -- only
a few functions, all other predefined functionality was statements.
Since WRITE was the only game in town, it used some syntax hacks:
separating items with commas caused them to be written as
20-character-wide columns; using semicolons instead caused single
spaces to appear between (it would have made more sense the other way
around, but I guess they were constrained by backward compatibility,
too :-). I guess Python's print statement's trailing comma reminds me
of the latter feature.
* Alas, writing the arguments to the print statement in parentheses is
not enough to future-proof your code, even if we had a print()
function that behaved right; print ('a', 'b') prints something
completely diferent than print 'a', 'b'. (The former prints a tuple
with quoted string literals.) The only thing that could mean the same
would be print(expr) with a single expression argument.
* A lot of discussion has actually focused on getting the semantics of
the replacement function right, and I like a lot of what was written.
Here's my own version:
print() could become a built-in function that behaves roughly like the
current print statement without a trailing comma; it inserts spaces
between items and ends with a newline. A keyword argument (file= or
to=?) can specify an alternate file to write to (default sys.stdout);
all that is used is the file's write() method with one string
argument. The softspace misfeature goes away.
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. If for example you
want the intervening spaces but not the trailing newline, sorry,
you're going to have to write the spaces yourself, which is no big
deal IMO. The new API is still much easier to use than what you have
to do currently for more control (sys.stdout.write()).
If there's demand, we could also introduce printf(), which would work
just like C's printf() except it takes a keyword argument to redirect
the output.
It would be easier from a future-proofing standpoint if the main
function *wasn't* called print; but people seem to react intuitively
to the name change, and there are other approaches available (like a
conversion program or running P2 programs in the P3 VM using a
backwards compatible parser+translator).
Maybe someone can work this into the Wiki?
(http://wiki.python.org/moin/PrintAsFunction)
As I said, I'm flexible on all the details but I really want to get
rid of the statement syntax for this functionality.
Re: [Python-Dev] Replacement for print in Python 3.0
[Barry Warsaw] I think it's best to have two builtins: print(*args, **kws) printf(fmt, *args, **kws) I would also /require/ that any behavior changing keyword arguments /not/ be magically inferred from the positional arguments. So you'd have to explicitly spell 'nl=False' or stream=fp if that's what you wanted. Good improvements. Raymond ___ 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 11:17, 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. 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. Anyway, this is close to what (I think) I'd like to see in the proposed built-ins. I'm out of time for now, so I'll check back later for all the derision and mocking. :) -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 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... 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
On 9/3/05, Barry Warsaw [EMAIL PROTECTED] wrote: On Fri, 2005-09-02 at 21:42, Guido van Rossum wrote: I do hate having to write two parentheses -- it's more than the extra keystrokes. It's that I have to use two shifted characters and I have to be sure to close the construct, which can be a PITA when the start of the function call is separated from the end by many lines. (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) ___ 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:
Steven Bethard wrote:
- Error and help messages, often with print sys.stderr
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 when technically these are
all derivable from read() and write(). This is why I suggested
providing a FileMixin class. In retrospect, I'm surprised we don't
already have one...
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
Guido van Rossum wrote: If there's demand, we could also introduce printf(), which would work just like C's printf() except it takes a keyword argument to redirect the output. I think this is probably unnecessary if string formatting becomes a function instead of the % operator (as has been suggested). I don't think that: write(\ ERROR: Failed to import handler %s for function %s in file %s. Improperly formed foobar string..substitute(handler, function, file), to=sys.stderr) is really any worse than: printf(\ ERROR: Failed to import handler %s for function %s in file %s. Improperly formed foobar string., handler, function, file, to=sys.stderr) 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
On 9/3/05, Nick Coghlan [EMAIL PROTECTED] wrote: Actually, it's an ordering quirk in the parser - the extended call syntax stuff has to come last in the function call, which means we need to put the keyword arguments at the front: Py writeln(sep=', ', *(x*x for x in range(10))) 0, 1, 4, 9, 16, 25, 36, 49, 64, 81 I personally believe keyword arguments should be allowed between *args and **kwds at the call site, and keyword-only arguments after * in the function definition, but the current behaviour has never bothered me enough for me to look into what would be required to change it. Same here. If anyone wants to give it a try, please go ahead! -- --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
