Re: [Python-Dev] Replacement for print in Python 3.0
On 9/4/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 9/3/05, Bill Janssen <[EMAIL PROTECTED]> wrote: > > Seems pretty weak to me. Are there other args against? > > Sure. I made the mistake of thinking that everybody knew them. Looks like I certainly didn't. These are good points, many of which I had missed. I withdraw my objections to print-as-function. These points should be added to the wiki. If no-one else gets to it, I'll do so this evening. Paul. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Steven Bethard wrote:
>
>> > Use the print() method of sys.stderr:
>> >
>> >sys.stderr.print('error or help message')
>>
>> so who's going to add print methods to all file-like objects?
>
> The same people that added __iter__(), next(), readline(), readlines()
> and writelines() to their file-like objects
who did that?
(you completely missed the point -- today's print mechanism works on *any*
object
that implements a "write" method, no just file objects. saying that "oh, all
you need is
to add a method" or "here's a nice mixin" doesn't give you a print replacement)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revising RE docs
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 was back in the 1.6 days; things have changed a lot since then, so maybe someone should benchmark some alternative ways to do this under 2.4...) 1) well, it used to use it. the code was modified slightly in 2.3 to prepend the type of the pattern string; not sure why, since 8-bit and unicode patterns should be equivalent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revising RE docs
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 (highly artificial toy) application it's about 7.5/2.5 = 3 times
> > faster to use the methods instead of the functions.
>
> Yeah, but the cost is a constant -- it is not related to the cost of
> compiling the re.
True.
> (You should've shown how much it cost if you
> included the compilation in each search.)
Why should I have? I don't dispute that the caching helps -- I bet it
helps a *lot*. I was just observing that it's not true that there's
"no cost to using the functions instead of the methods".
> I haven't looked into this, but I bet the overhead you're measuring is
> actually the extra Python function call, not the cache lookup itself.
Hmm, that's possible. But what matters in practice is how big
the cost of using re.search("...","...") rather than compiling
once and using the RE object's search method is, not where it
comes from.
--
g
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revising RE docs
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Revising RE docs
[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/pipermail/python-dev/2005-June/054204.html Must be a secret admirer. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gdbinit problem
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 way I could see to fix it was by setting a continue flag and > testing it. Does anyone know a better way to fix this problem? A > patch is attached which fixes the problem for me, but I would rather > check in a better solution if one exists. > > Any ideas? Or should I just check in the attached patch. You're probably one of the two users. :-) So don't hesitate. If the other user disagrees you two can fight it out in CVS. :) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/4/05, Stephan Deibel <[EMAIL PROTECTED]> wrote: > On Sun, 4 Sep 2005, Guido van Rossum wrote: > > But more important to me are my own experiences exploring the > > boundaries of print. > > > > - I quite often come to a point in the evolution of a program where I > > need to change all print statements into logging calls, or calls into > > some other I/O or UI library. [...] > > FWIW, this almost always happens to me. Although I've learned to > avoid print in most cases, it was a somewhat painful lesson that seems > quite at odds with how the rest of Python is designed -- usually, > stuff just works and you aren't led into such design traps. Happened to me too. However, there is an easy way out: hijack sys.stdout to forward to your logger system. I've got a web application framework that's setup like that right now, it works great (if you will not need the original print-to-stdout anymore in your program, that is). I print, it goes to the logfile. You just have to be careful where--in time-- you replace sys.stdout. cheers, ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0)
> 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 t "~{~^, ~A~}" 1 2 3 "wombat")
which produces
1, 2, 3, wombat
or -- you may wish to be sitting down before reading further --
(format t "~#[nothing~;~S~;~S and ~S~:;[EMAIL PROTECTED]; and~] ~S~^
,~}~]." 1 2 3 "wombat")
which produces
1, 2, 3, and wombat
and also does the Right Thing with 0, 1 or 2 items. (The first
argument to FORMAT, in case you were wondering, determines where
the output should go. Feeding in T, as here, sends it to stdout.
You can also give it an arbitrary stream, or NIL to return the
formatted result as a string.)
For the impressive and horrifying full story, see
http://www.lisp.org/HyperSpec/Body/sec_22-3.html
Most of the features of CL's formatted output are probably,
shall we say, inappropriate for Python. It might still be worth
a look, to see if there's anything under the rococo exterior
that would fit.
*
Some languages have "picture" formats, where the structure
of the format string more closely mimics that of the desired
output. (This is true, e.g., of some Basics and of one variety
of Perl output.) The trouble with this is that it limits how
much information you can provide about *how* each value is
to be formatted within the available space.
*
C++'s << operator represents another way to do formatted
output. I regard it as an object lesson in bad design.
--
g
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0)
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" and Common Lisp with (format nil ...) then the Right Thing in C++ (in so far as that exists) is usually to use << with a string stream. -- g ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Example for "property" violates "Python is not a one pass compiler"
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. But if I put the property statement first: class C(object): x = property(getx, setx, delx, "I'm the 'x' property.") def getx(self): return self.__x def setx(self, value): self.__x = value def delx(self): del self.__x I get the error: NameError: name 'getx' is not defined Does this violate the principle "Python is not a one pass compiler"? Normally I can use any method of a class anywhere in the definition of the class. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string formatting and i18n
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 Right Thing in C++
> (in so far as that exists) is usually to use << with a string
> stream.
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 + "' " + _("is read only")
because the splitting in the second form will not translate correctly
into other languages. You *have* to supply the whole non-splitted
sentence to the translators.
The bottom line, IMHO, is that there are frequent uses that mandate a
nice and easy to use formatting operator. Python has it, let's not
remove it.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for "property" violates "Python is not a one pass compiler"
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 class before they're defined, any more than you can subclass a class that doesn't exist yet. I'm not sure where you got the "Python is not a one pass compiler" idea; I don't recall having seen this meme anywhere before, and I don't see how it's meaningful anyway. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Example for "property" violates "Python is not a onepass compiler"
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 the 'x' property.") > > It works. But if I put the property statement first: > > class C(object): > x = property(getx, setx, delx, "I'm the 'x' property.") > def getx(self): return self.__x > def setx(self, value): self.__x = value > def delx(self): del self.__x > > I get the error: > NameError: name 'getx' is not defined > > Does this violate the principle "Python is not a one pass compiler"? this has nothing to do with compilation; class objects are created by executing the code inside the class block. that code is only executed once (when the class statement itself is executed). > Normally I can use any method of a class anywhere in the definition of > the class. nope. you can use a method name inside a method that will be *executed* at a *later* time, but you cannot refer to names that hasn't been defined yet. (if you don't intuitively understand this, you need to read up on how namespaces work and how they are populated) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string formatting and i18n
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 + "' " + _("is read only")
>
> because the splitting in the second form will not translate correctly
> into other languages. You *have* to supply the whole non-splitted
> sentence to the translators.
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 strings.
-Barry
signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[email protected]
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string formatting and i18n
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 "sprintf" and
> > Common Lisp with (format nil ...) then the Right Thing in C++
> > (in so far as that exists) is usually to use << with a string
> > stream.
>
> 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 + "' " + _("is read only")
>
> because the splitting in the second form will not translate correctly
> into other languages. You *have* to supply the whole non-splitted
> sentence to the translators.
Yes. If you think I was arguing the opposite, then I failed to
communicate clearly and I apologize.
> The bottom line, IMHO, is that there are frequent uses that mandate a
> nice and easy to use formatting operator. Python has it, let's not
> remove it.
It's clear (I think) that a good way of formatting strings is
necessary. It's less clear what the best way is. Python's % is
pretty good; perhaps it's possible to do even better.
For instance, take your I18N example. Not all languages have the
same word order, as you've observed. When there's more than one
parameter, Python's %-interpolation isn't enough in general;
you'd need something that can reorder the parameters. I don't
know whether this is worth complicating string formatting for,
but it's not obvious that it isn't.
--
g
___
Python-Dev mailing list
[email protected]
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string formatting and i18n
[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 strings. Yet, "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. :-) -- François Pinard http://pinard.progiciels-bpi.ca ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] string formatting and i18n
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 error-prone construct for translators. -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: string formatting and i18n
> 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, take your I18N example. Not all languages have the > same word order, as you've observed. When there's more than one > parameter, Python's %-interpolation isn't enough in general; > you'd need something that can reorder the parameters. I don't > know whether this is worth complicating string formatting for, > but it's not obvious that it isn't. Well, I totally agree. I think it could be nice to both: - introduce positional formatting : "%1", "%2"... - make type specification optional, since Python can figure out the type by itself and use the right method; you would only specify the type when you want to have a different formatting (for example, for floats, you could use "%g2" instead of "%2" which would be equivalent to "%f2") Regards Antoine. -- « On dit que pétrir c'est modeler, Moi je dis que péter c'est démolir. » Stupéflip ___ Python-Dev mailing list [email protected] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/5/05, Kay Schluehr <[EMAIL PROTECTED]> wrote:
> [...] is the most heavyweight solution, but can encapsulate options and is
> reusable:
>
> >>> Writer(sep="//").print("some","text")
> some//text
>
> or
>
> writer = Writer(sep="//", file=sys.stderr)
> writer.print("some","error-text")
> writer.print("another","error text")
I am disappointed to see several proposals plunge into this type of
generality (no matter how cool it is in its application of OO design
patterns) without asking whether there is a need. Look at the example
-- it is completely useless. I only made it up so that I could present
the simpler version; I didn't have a use case myself for arbitrary
delimiters.
My hypothesis is that there are actually only two use cases that
matter enough to be supported directly:
(a) quickly print a bunch of items with spaces in between them and a
trailing newline
(b) print one or more items with precise control over each character
If there are other use cases they can obviously be coded by using (b)
and a modest amount of custom code. (I know there's the use case of
printing sequences; I'll try to give an analysis of this use case in
another post if one of its proponents doesn't do so soon.)
An additional use case that I am willing to entertain because there is
a lot of prior art (like Python's logging package, Bill Janssen's
note(), and of course many other languages) is format-directed
printing. This can of course be reduced to use case (b) using the
str.% operator, but it is common enough to at least *consider*
providing a direct solution which avoids the pitfalls of the %
operator. Call this use case (c).
Interesting, use case (b) can also easily be reduced to use case (c)!
In a different thread I mentioned a design principle for which I have
no catchy name, but which has often helped me design better APIs. One
way to state it is to say that instead of a single "swiss-army-knife"
function with various options that choose different behavior variants,
it's better to have different dedicated functions for each of the
major functionality types. So let's call it the "Swiss Army Knife
(...Not)" API design pattern.
There are a number of reasons why this API design is often better.
These aren't quite the same reasons why a real life Swiss Army knife
is often inferior to individual tools, if you have them available, so
the analogy isn't perfect. (So sue me. :-)
* It reduces the number of parameters, which reduces the cognitive
overhead for the human reader. (It also reduces function call overhead
some; but that's not the main reason.)
* It puts the hint about the specific variant functionality at the
front rather than at the end, so it is less likely overlooked.
* If one variant is much more common than others, it is easier to
learn just that behavior.
* In the (common) case where the options are Booleans, it's often
confusing whether True or False switches a particular behavior on or
off (especially if they are allowed to be specified as positional
parameters).
* A good test to discover that you should have used this pattern is
when you find that the argument specifying a particular option is a
constant at every call site (perhaps excluding API wrappers). This is
a hint that the different variants of the functionality are catering
to different use cases; often you'll find that substituting a
different variant behavior just wouldn't work because the use that is
made of the returned value expects a specific variant.
Some examples of the design pattern in action are str.strip(),
str.lstrip() and str.rstrip(), or str.find() and str.rfind().
A much stronger subcase of this pattern (with fewer exceptions) is
that the return type of a function shouldn't depend on the value of an
argument. I have a feeling that if we were to extend the notion of
type to include invariants, you'd find that the basic pattern is
actually the same -- often the variant behaviors change the key
invariant relationships between input and output.
OK, still with me? This, together with the observation that the only
use cases for the delimiter are space and no space, suggests that we
should have separate printing APIs for each of the use cases (a), (b)
and (c) above, rather than trying to fold (b) into (a) using a way to
parameterize the separator (and the trailing newline, to which the
same argument applies). For example:
(a) print(...)
(b) printraw(...) or printbare(...)
(c) printf(fmt, ...)
Each can take a keyword parameter to specify a different stream than
sys.stdout; but no other options are needed. The names for (a) and (c)
are pretty much fixed by convention (and by the clamoring when I
proposed write() :-). I'm not so sure about the best name for (b), but
I think picking the right name is important.
We could decide not to provide (b) directly, since it is easily
reduced to (c) using an appropriate format string ("%s" times the
number of arguments). But I expect that use case (b) is pretty
important, and not
Re: [Python-Dev] Replacement for print in Python 3.0
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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
Neil> In interactive mode, you are normally interested in the values of Neil> things, not their formatting so it does the right thing. >>> class Dumb: ... def __init__(self, val): ... self.val = val ... def __str__(self): ... return "" % self.val ... >>> d = Dumb(5) >>> d <__main__.Dumb instance at 0x11042d8> >>> print d It's just repr() vs. str(), but the difference can be significant in many circumstances. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String views
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)? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gdbinit problem
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] String views
[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)? As far as I'm concerned it is, yes. Until this thread highlighted it I hadn't really considered this issue. It's a bit ugly that C extensions won't handle the full range of strings that pure python code will, but it's a typically pragmatic Python solution, so I'm not about to start a war about it. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] 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
[email protected]
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Replacement for print in Python 3.0
On 9/5/05, Calvin Spealman <[EMAIL PROTECTED]> wrote: > There is a lot of debate over this issue, obviously. Now, I think > getting rid of the print statement can lead to ugly code, because a > write function would be called as an expression, so where we'd once > have prints on their own lines, that wouldn't be the case anymore, and > things could get ugly. Sounds like FUD to me. Lots of functions/methods exist that *could* be embedded in expressions, and never are. Or if they are, there's actually a good reason, and then being a mere function (instead of a statement) would actually be helpful. Anyway, why would it be important that prints are on their own line where so many other important actions don't have that privilege? > But, print is a little too inflexible. > What about adding a special name __print__, which the print statement > would call? It should be looked up as a local first, then global. > Thus, different parts of a program can define their own __print__, > without changing everyone else's stdout. The Python web people would > love that. Too many underscores; __print__ screams "internal use, don't mess" at you. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] gdbinit problem
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) GDB's command > language implements a break-like statement. Ah. Now you've heard from the other user. :-) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
