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-
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 p
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, +-
(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
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 cur
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
Un
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!
Wel
Fredrik Lundh wrote:
> Greg Ewing wrote:
>
>
>>Maybe backquotes could be repurposed in Py3k for interpolated
>>string literals?
>
>
> backquotes are a PITA to type on many non-US keyboards.
Not to mention the annoyingly large number of fonts that make '`' and ''' look
virtually identical :(
"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
___
Greg Ewing wrote:
> Maybe backquotes could be repurposed in Py3k for interpolated
> string literals?
backquotes are a PITA to type on many non-US keyboards.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
> "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 thi
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
Michael Chermside wrote:
> In my opinion, YES -- it's worth seriously considering it. A single,
> well-designed solution for string interpolation (with syntactic support
> if needed to make it very easy to use) is FAR better than having one
> good solution and another legacy solution.
Maybe backq
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
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 s
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 expre
> "Antoine" == Antoine Pitrou <[EMAIL PROTECTED]> writes:
Antoine> Le jeudi 08 septembre 2005 à 19:12 +0900, Stephen
Antoine> J. Turnbull a écrit :
>> It would be nice to be able to lose the "_()" calls to
>> gettext(). The function would look to see if a message catalog
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 th
Barry Warsaw wrote:
> On Wed, 2005-09-07 at 08:55, Nick Coghlan wrote:
>
>
>>The leading 'p' (for 'positional') is necessary to get around the fact that
>>$1
>>is currently an illegal identifier in a Template
>
>
> That should be fixable. Ideally, $1 is better than $p1.
Oh, I know. I just di
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 a
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. W
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 digitall
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 stri
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 so
> "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 mini
> "Guido" == Guido van Rossum <[EMAIL PROTECTED]> writes:
Guido>
Guido> In a different thread I mentioned a design principle for
Guido> which I have no catchy name, but which has often helped me
Guido> design better APIs. One way to state it is to say that
Guido> instead
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 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 i
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(*
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
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 e
> "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 i1
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 librari
> "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 appl
> 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 anythin
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
> 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:/
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
Guido van Rossum wrote:
> On 9/6/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
>>printf('$1 forgot to frobnicate the $2!\n', username, file.name,
>> to=sys.stderr)
>>
>>While that's a little less self-descriptive for a translator to deal
>>with (who would only see the string, not the call si
Guido,
I think this is a very nice summary of the arguments for removing
print. Let's change the link in PEP 3000 to point to this message.
Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubs
Please bear with me if this has already been stated, or if I ought to
be directing this to the wiki instead of to python-dev at this point.
I've been trying to follow this whole discussion but have only gotten
as far as last Saturday.
Two things: First of all, I wanted to encourage Guido. There ha
[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
Kay Schluehr wrote:
> In the context of my proposal it seems to imply some variation of
> Einsteins famous sentence: "Make everything as general as possible but
> not more general" or "Make everything as powerfull as possible but not
> more powerfull".
I prefer McGrath's variation:
"Things s
putting on my "on the other hand" hat for a moment...
:::
Guido van Rossum wrote:
> 1. It's always been there
> 2. We don't want to type parentheses
> 3. We use it a lot
> 4. We don't want to change our code
there's also:
5. A reserved word makes it easy to grep for (e.g. to weed out
debugging
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 i
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 "writ
> > 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 whic
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/)
___
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
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
(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 f
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
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 nic
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 Pyth
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 dir
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
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/mail
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 elimi
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
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 qu
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
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, tha
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
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
Neil> In interactive mode, you are normally interested in the values of
Neil> things, not their formatting so it does the right thing.
>>> class Dumb:
... def __init__(self, val):
... self.val = val
... def __str__(self):
... return "" % self.val
...
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
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")
> writ
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
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 n
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,
On 9/4/05, Stephan Deibel <[EMAIL PROTECTED]> wrote:
> On Sun, 4 Sep 2005, Guido van Rossum wrote:
> > But more important to me are my own experiences exploring the
> > boundaries of print.
> >
> > - I quite often come to a point in the evolution of a program where I
> > need to change all print st
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-l
On 9/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/3/05, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > Seems pretty weak to me. Are there other args against?
>
> Sure. I made the mistake of thinking that everybody knew them.
Looks like I certainly didn't. These are good points, many of
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
On 9/4/05, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> You can definitely argue about keeping formatting and print separate,
> but I think Guido and others have explained the problems with %.
To reiterate, "%s" % x is unsafe if you aren't sure that x can't be a
tuple -- you'd have to write "%s" % (x
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
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
_
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 accept
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 bogu
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 t
"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
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 U
Let me correct two typos (I had to leave in a rush).
[François Pinard]
> [...] Let's consider that `print' (or whatever) is a Python function,
> not negotiable. It should likely be.
The "It" refers to `print' being a Python function, not the negotiability.
> Logo and a few others also have par
Raymond Hettinger wrote:
> [Barry]
>
>>Actually, we probably only /need/ printf(), and certainly for C
>>programmers (are there any of us left? ;), I think that would be a
>
> small
>
>>conceptual leap. The motivation for keeping a non-formatting version
>
> is
>
>>for simple cases, and begin
[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 (q
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
[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
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 gr
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 time
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
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
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 disap
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 statemen
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 i
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'
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
[...]
> 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 prop
[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.
Bill Janssen wrote:
> I think what Nick really is asking for is a better print statement --
> and there's no particularly good reason to move to a function to
> attain that end.
Well one reason (you can judge for yourself whether it's "good" or
not) is that adding more syntax to the print statemen
Nick Coghlan wrote:
> Nick Coghlan wrote:
>
>>I agree with this point actually. There should be an "iterable" formatting
>>code that looks something like "%[sep]i"
>>
>>Then "%i" % (my_seq,) would be the equivalent of "".join(my_seq), only
>>allowing it to be easily embedded inside a larger form
1 - 100 of 224 matches
Mail list logo
