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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Neal> The only way I could see to fix it was by setting a continue flag
> Neal> and testing it. Does anyone know a better way to fix this
> Neal> problem?
>
> Certainly looks reasonable until we figure out how (if at all) GD
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
[EMAIL PROTECTED] wrote:
> Greg> If a Python function is clearly wrapping a C function, one doesn't
> Greg> expect to be able to pass strings with embedded NULs to it.
>
> Isn't that just floating an implementation detail up to the programmer (who
> may
> well not be POSIX- or Unix-aware)
Neal> The only way I could see to fix it was by setting a continue flag
Neal> and testing it. Does anyone know a better way to fix this
Neal> problem?
Certainly looks reasonable until we figure out how (if at all) GDB's command
language implements a break-like statement.
Skip
Greg> If a Python function is clearly wrapping a C function, one doesn't
Greg> expect to be able to pass strings with embedded NULs to it.
Isn't that just floating an implementation detail up to the programmer (who may
well not be POSIX- or Unix-aware)?
___
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
> Yes. If you think I was arguing the opposite, then I failed to
> communicate clearly and I apologize.
Actually, I didn't interpret your message like that, but as I had
already seen that proposal (to suppress string formatting), I thought it
would be the right time to react ;)
> For instance, t
On Mon, 2005-09-05 at 14:10, François Pinard wrote:
> "The file %(filename)s in directory %(dir)s is read only" % vars()
>
> is already usable. The need being already filled without Template
> strings, it could hardly be presented as a motivation for them. :-)
Except that IME, %(var)s is an e
[Barry Warsaw]
> Actually, this was part of the motivation behind PEP 292 and Template
> strings, because what you really want is named parameters, not
> positional parameters:
> 'The file $filename in directory $dir is read only'
> There are a few techniques for getting full i18n for Template s
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 Monday 2005-09-05 17:07, Antoine Pitrou wrote:
> Le lundi 05 septembre 2005 à 16:52 +0100, Gareth McCaughan a écrit :
> > ... and should add: Of course it's usually seen as being about
> > output more than about formatting, but in fact if you want
> > to do what Python does with "%", C with "sp
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 Mon, 2005-09-05 at 12:07, Antoine Pitrou wrote:
> Uh, what about internationalization (i18n) ?
> In i18n you can't avoid the need for parameterized strings.
> For example I want to write :
> _("The file '%s' is read only") % filename
> not :
> _("The file") + " '" + filename + "' "
Edward C. Jones write:
> Here is an example from the "Python Library Reference", Section 2.1
> "Built-in Functions":
>
> class C(object):
> def getx(self): return self.__x
> def setx(self, value): self.__x = value
> def delx(self): del self.__x
> x = property(getx, setx, delx, "I'm
At 12:04 PM 9/5/2005 -0400, Edward C. Jones wrote:
>Normally I can use any method of a class anywhere in the definition of
>the class.
Not true. You can certainly use any method of a class in any *functions*
or methods defined in the body of the class. But you can't use them in the
body of the
Le lundi 05 septembre 2005 à 16:52 +0100, Gareth McCaughan a écrit :
> ... and should add: Of course it's usually seen as being about
> output more than about formatting, but in fact if you want
> to do what Python does with "%", C with "sprintf" and
> Common Lisp with (format nil ...) then the Rig
Here is an example from the "Python Library Reference", Section 2.1
"Built-in Functions":
class C(object):
def getx(self): return self.__x
def setx(self, value): self.__x = value
def delx(self): del self.__x
x = property(getx, setx, delx, "I'm the 'x' property.")
It works. Bu
I wrote:
> C++'s << operator represents another way to do formatted
> output. I regard it as an object lesson in bad design.
... and should add: Of course it's usually seen as being about
output more than about formatting, but in fact if you want
to do what Python does with "%", C with "sprintf"
> If people know of other languages that have a different approach to
> string formatting, it might be useful to see them.
Common Lisp has something broadly C-like but bigger and hairier.
It includes powerful-but-confusing looping and conditional
features, letting you say things like
(format
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
On 9/4/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> break in gdbinit is apparently does not break a loop, but rather sets
> a break point. I don't know how to hit the break within lineno with a
> simple test case. Debugging pychecker with a C extension (matplotlib)
> triggers it.
>
> The only w
[Fredrik Lundh]
> Am I the only who are getting mails from "iextream at naver.com"
> whenever I post to python-dev, btw?
>
> My Korean (?) isn't that good, so I'm not sure what they want...
Only thing I've seen from them is one post in the archives, on June 13:
http://mail.python.org/pipermai
Am I the only who are getting mails from "iextream at naver.com"
whenever I post to python-dev, btw?
My Korean (?) isn't that good, so I'm not sure what they want...
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
Guido wrote:
> > > They *are* cached and there is no cost to using the functions instead
> > > of the methods unless you have so many regexps in your program that
> > > the cache is cleared (the limit is 100).
> >
> > Sure there is; the cost of looking them up in the cache.
...
> > So in this (hi
Guido van Rossum wrote:
> I also notice that _compile() is needlessly written as a varargs
> function -- all its uses pass it exactly two arguments.
that's because the function uses [1] the argument tuple as the cache key,
and I wanted to make the "cache hit" path as fast as possible.
(but that
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
34 matches
Mail list logo
