[Python-Dev] bug in urlparse
Hello, I'm using the module urlparse and I think I've found a bug in the urlparse module. When you merge an url and a link like"../../../page.html" with urljoin, the new url created keep some "../" in it. Here is an example : >>> import urlparse >>> begin = "http://www.example.com/folder/page.html"; >>> end = "../../../otherpage.html" >>> urlparse.urljoin(begin, end) 'http://www.example.com/../../otherpage.html' I would more expect the following url : http://www.example.com/otherpage.html It's what is done in most web browser. So I would like to know if it's a bug or not. If it is, I would try to code and to submit a patch. -- Fabien SCHWOB ___ 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
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 [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
Tony Meyer wrote:
> [Nick Coghlan]
>
>>"Print as statement" => printing sequences nicely is a pain
>
>
> What's wrong with this?
>
>
print range(10)
>
> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
>
print tuple("string")
>
> ('s', 't', 'r', 'i', 'n', 'g')
>
> This is a serious question - that's how I would expect a print function to
> work anyway.
Py> print (x*x for x in range(10))
Oh, wait, this is what I actually meant:
Py> print " ".join(map(str, (x*x for x in range(10
0 1 4 9 16 25 36 49 64 81
Printing the contents of an arbitrary iterable is harder than it should be.
Many iterables (including the builtin ones) have a reasonable default display,
but a non-default display (e.g. linefeed separated instead of comma separated)
isn't the most obvious thing to express.
I thought making print a function solved that problem, but it doesn't really.
So I'm currently exploring a different approach involving string formatting.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://boredomandlaziness.blogspot.com
___
Python-Dev mailing list
[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] Weekly Python Patch/Bug Summary
"Kurt B. Kaiser" <[EMAIL PROTECTED]> writes: > Patch / Bug Summary > ___ > > Patches : 903 open (+551) / 5222 closed (+2324) / 6125 total (+2875) Err ... ? Cheers, mwh -- LaTeX, pah. Don't be silly. I'm using a homebrew markup system that I wrote in Common Lisp. ;-) -- Peter Seibel, comp.lang.lisp, talking about his book "Practical Lisp" ___ 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
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
[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] Asynchronous use of Traceback objects
Christopher Armstrong <[EMAIL PROTECTED]> writes: > I had the idea to create a fake Traceback object in Python that > doesn't hold references to any frame objects, but is still able to be > passed to 'raise' and formatted as tracebacks are, etc. Unfortunately, > raise does a type check on its third argument and, besides, it seems > the traceback formatting functions are very reliant on the internal > structure of traceback objects, so that didn't work. An option you may not have considered is to ditch the C code that formats tracebacks and always use traceback.py (this has a few obvious problems -- what do you do if traceback.py fails to import, what if formatting the traceback raises an error -- but nothing too horrendous, I think). Less duplication and less C code are always good things (IMHO, at least). > It does seem that I would be able to construct a passable fake > Traceback object from C code -- one that had references to fake > frames. These fake objects would only remember the original line > numbers, filenames and so forth so that traceback printing could still > work. I can try implementing this soon, but I'd just like to make sure > I'm on the right track. For example, perhaps a better idea would be to > change the traceback-printing functions to use Python attribute lookup > instead of internal structure lookup, My suggestion above would obviously acheive this bit :) > and then change raise to accept arbitrary Python objects as its > third argument, as long as it matches the traceback interface. That > would probably mean much more work, though. > > One concern is that I really don't like requiring C modules to use > Twisted; all of the ones currently in there are optional. Well, presumably this is optional too -- you only need it if you want informative tracebacks... > What's the likelihood of such a traceback-constructor getting its > way into CPython if I do implement it? I'd support more flexibility in this area. I'm not sure what the best approach is, though. Cheers, mwh -- I have *both* hands clapping, but I'm still not sure it's a sound. When I tried deciding if it were a sound while clapping only one hand, I fell off my chair. -- Peter Hansen, Zen master, comp.lang.python ___ 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/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 [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, 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 [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] bug in urlparse
On 9/4/05, Fabien Schwob <[EMAIL PROTECTED]> wrote: > Hello, > > I'm using the module urlparse and I think I've found a bug in the > urlparse module. When you merge an url and a link > like"../../../page.html" with urljoin, the new url created keep some > "../" in it. Here is an example : > > >>> import urlparse > >>> begin = "http://www.example.com/folder/page.html"; > >>> end = "../../../otherpage.html" > >>> urlparse.urljoin(begin, end) > 'http://www.example.com/../../otherpage.html' You seem to be typing this from memory; the example actually gives a single set of "../", not two. > I would more expect the following url : > http://www.example.com/otherpage.html > > It's what is done in most web browser. > > So I would like to know if it's a bug or not. If it is, I would try to > code and to submit a patch. You shouldn't be giving more "../" sequences than are possible. I find the current behavior acceptable. -- --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] bug in urlparse
>> >>> import urlparse >> >>> begin = "http://www.example.com/folder/page.html"; >> >>> end = "../../../otherpage.html" >> >>> urlparse.urljoin(begin, end) >>'http://www.example.com/../../otherpage.html' > You seem to be typing this from memory; the example actually gives a > single set of "../", not two. No, it's a copy of an interactive session using Python 2.4.1. >>I would more expect the following url : >>http://www.example.com/otherpage.html >> >>It's what is done in most web browser. >> >>So I would like to know if it's a bug or not. If it is, I would try to >>code and to submit a patch. > You shouldn't be giving more "../" sequences than are possible. I find > the current behavior acceptable. Ok, so I would try do dev my own fonction. Mainly because on some web pages that I manipulate (for example [1]) there are more "../" than possible. [1] http://linuxfr.org/~pterjan/19252.html -- Fabien SCHWOB ___ 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/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 [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 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 [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 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 [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 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 [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
[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 [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, 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 [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] > [...] 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 [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
Raymond Hettinger wrote: > [Barry] > >>Actually, we probably only /need/ printf(), and certainly for C >>programmers (are there any of us left? ;), I think that would be a > > small > >>conceptual leap. The motivation for keeping a non-formatting version > > is > >>for simple cases, and beginners -- both of which use cases should not > > be > >>dismissed. > > > +1 on Barry's proposal for two functions, one formatted and one plain. +1 There is ... >>> '%r+%r = %r'.__mod__((1,2,3)) '1+2 = 3' Ok, not exactly what he proposed. ;-) Is there a better named method that str.__mod__() calls? > However, I take issue with the premise that beginners do not need > formatting. Almost anyone, beginner or not, needs formatting when they > are working on a real application. My experience is that finance people > immediately try to format their output (habits from Excel). Most are > astonished at how non-trivial it is to add commas, dollar signs, > brackets, and a fixed number of decimal places. So, I think beginners > should be considered a key constituent for output formatting and that > their needs should be accommodated as simply and broadly as possible. I agree, and the next thing programmers with previous experience look for is formatted input. Ok, not the very next thing. :-) Cheers, Ron ___ Python-Dev mailing list [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
Let me correct two typos (I had to leave in a rush). [François Pinard] > [...] Let's consider that `print' (or whatever) is a Python function, > not negotiable. It should likely be. The "It" refers to `print' being a Python function, not the negotiability. > Logo and a few others also have parentheses-less function > calls, yet they may be week at handling functions as first-class > objects. s/week/weak/ -- François Pinard http://pinard.progiciels-bpi.ca ___ Python-Dev mailing list [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] string formatting options and removing basestring.__mod__ (WAS: Replacement for print in Python 3.0)
[Raymond Hettinger]
> Actually, formatting needs to become a function. The overloading of the
> arithmetic mod operator has proven to be unfortunate (if only because of
> precedence issues).
[Guido van Rossum]
> For me, it's not so much the precedence, but the fact that "%s" % x
> doesn't work as expected if x is a tuple; you'd have to write "%s" %
> (x,) which is tedious.
[Raymond Hettinger]
> Also, the format coding scheme itself needs to be revisited. There is
> no shortage of people who have taken issue with the trailing s in
> %(myvar)s.
[snip[]
> string.Template is a bit too simplified. But perhaps it can be adapted.
> We still want some way to express %r, %6.2f, etc.Since string
> formatting has been around since Tim was in diapers, we should probably
> start by looking at the solutions used by other languages.
I was curious about what kind of options there were, so I googled
around a bit. Here's what I found:
Java[1] uses syntax like:
%[argument_index$][flags][width][.precision]conversion
which is basically the same as that of C, with positional argument
specifiers. Some examples:
String.format("Duke's Birthday: %1$tm %1$te,%1$tY", c);
System.out.format("Local time: %tT", Calendar.getInstance());
formatter.format("%4$2s %3$2s %2$2s %1$2s", "a", "b", "c", "d")
Classes can customize formatting for the 's' specifier by implementing
the Formattable interface, which provides a method:
formatTo(Formatter fmt, int f, int width, int precision)
You can get formatted objects by calling:
* The format() methods on Formatter objects
* The format() methods on Strings
* The format() methods on System.out, System.err, etc.
.Net[2] uses syntax like:
{index[,alignment][:formatString]}
with examples like:
String.Format("{0: }", DateTime.Now)
Console.WriteLine("{0:C}", MyInt)
String.Format("Name = {0}, hours = {1:hh}, minutes = {1:mm}",
myName, DateTime.Now)
Classes can customize formatting for any specifier by implementing the
ICustomFormatter interface:
Format(string format, object arg, IFormatProvider formatProvider);
or the IFormattable interface:
ToString(string format, IFormatProvider formatProvider);
You can get formatted objects by calling:
* The ToString method of an IFormattable instance
* The Format on Strings
* The Write and WriteLine methods of Console, TextWriter,
StreamWriter, etc. objects
I also briefly looked at Tcl/Tk[3], Common Dylan[4], OCaml[5] and
Ruby[6][7], which all appear to use C-style (or similar) formatting.
I believe that Ruby, in addition to having printf and sprintf, also
uses the % operator like Python does.
This was a pretty small sample of languages (just the first few that
showed up in google), and I didn't really look at any of them other
than Java and .Net in much depth, so I've may have misunderstood some
of it. That said, I think it's probably pretty reasonable to conclude
that C-style formatting is the choice of a lot of other languages.
(Not to imply that it therefore needs to be the choice of Python.)
I understand one of the complaints about string formatting in Python
is having to write the "s" on things like "%(key)s". I was hoping to
get some ideas for alternatives here, but I wasn't able to find any
dict-style insertion like in Python. There were a few languages
(Java, Tcl) with the N$ positional-style insertion, but I don't think
that helps us much.
People have also been discussing a builtin format() function to
replace the current % operator. Translating into Python the location
of the formatting operations in the languages above suggests the
following possibilities:
* Have all __str__() methods take additonal formatting arguments
* Add a format() builtin
* Add format() methods on str and unicode objects
* Add format() methods on all Python streams (files, sys.stdin, etc.)
Of course, these possibilities aren't mutually exclusive, but TOOWTDI
suggests that we probably shouldn't have too many of them.
If people know of other languages that have a different approach to
string formatting, it might be useful to see them. BTW, I
intentionally didn't go into Perl's string formatting because I don't
know it that well, and figured there are people on this list much more
qualified than myself to present it.
[1]http://java.sun.com/j2se/1.5.0/docs/api/java/util/Formatter.html
[2]http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconFormattingOverview.asp
[3]http://www.tcl.tk/man/tcl8.0/TclCmd/format.htm
[4]http://gauss.gwydiondylan.org/books/drm/drm_57.html
[5]http://caml.inria.fr/pub/docs/manual-ocaml/libref/Printf.html
[6]http://www.rubycentral.com/book/ref_c_string.html#String._pc
[7]http://www.rubycentral.com/book/ref_m_kernel.html#Kernel.sprintf
Steve
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/l
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 [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] New Wiki page - PrintAsFunction
Hello,
This is my first post here.
I like python a lot: great job people!
Thank you!
Alle 10:28, sabato 03 settembre 2005, Ron Adam ha scritto:
> Nick Coghlan wrote:
> > All,
> >
> > I put up a Wiki page for the idea of replacing the print statement with
> > an easier to use builtin:
> >
> > http://wiki.python.org/moin/PrintAsFunction
> >
> > Cheers,
> > Nick.
>
> Looks like a good start, much better than just expressing opinions. :-)
>
>
> How about making it a class?
I like the object idea, really a lot!
>
> There are several advantages such as persistent separators and being
> able to have several different instances active at once.
>
> Cheers,
> Ron
>
>
I think savesep is unusefull.
import sys
class Print(object):
newline = '\n'
sep = ' '
def __init__(self, out=sys.stdout, println=""):
self.out = out
self._print=self.printNOln
def __call__(self, *args, **kwds):
self._print(*args, **kwds)
def printNOln(self, *args, **kwds):
try:
sep = kwds['sep']
except KeyError:
sep = self.sep
for arg in args[:1]:
self.out.write(str(arg))
for arg in args[1:]:
self.out.write(sep)
self.out.write(str(arg))
def println(self, *args, **kwds):
self.printNOln(*args, **kwds)
self.out.write(self.newline)
> # default "builtin" instance
> write = Print() # could be print in place of write in python 3k.
>
>
write._print=write.println
>
> # standard printing
write(1, 2, 3)
>
> # print without spaces
write(1, 2, 3, sep='')
>
> # print comma separated
write(1, 2, 3, sep=', ')
>
> # or
> write.sep = ', '# remain until changed
> write(1, 2, 3)
> write(4, 5, 6)
> write.sep = ' '
>
> # print without trailing newline
write._print=write.printNOln
> write(1, 2, 3)
>
> # print to a different stream
> printerr = Print(sys.stderr)
printerr._print=write.println
printerr(1, 2, 3)
>
> # print a simple sequence
write._print=write.println
write(*range(10))
>
> # Print a generator expression
write(*(x*x for x in range(10)))
>
> # print to file
> f = open('printout.txt','w')
> fileprint = Print(f)
> fileprint("hello world\n")
> f.close()
Does this look good?
Ciao
Vincenzo
>
>
>
>
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/hawk78_it%40yahoo.it
___
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
___
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 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 [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] bug in urlparse
According to RFC 2396[1] section 5.2:
g) If the resulting buffer string still begins with one or more
complete path segments of "..", then the reference is
considered to be in error. Implementations may handle this
error by retaining these components in the resolved path (i.e.,
treating them as part of the final URI), by removing them from
the resolved path (i.e., discarding relative levels above the
root), or by avoiding traversal of the reference.
If I read this right, it explicitly allows the urlparse.urljoin behavior
("handle this error by retaining these components in the resolved path").
Also see C.2. Abnormal Examples.
In practice, some implementations strip leading relative symbolic
elements (".", "..") after applying a relative URI calculation, based
on the theory that compensating for obvious author errors is better
than allowing the request to fail. Thus, the above two references
will be interpreted as "http://a/g"; by some implementations.
Jeff
[1] http://www.faqs.org/rfcs/rfc2396.html
pgpepLuYWWdL4.pgp
Description: PGP signature
___
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] Asynchronous use of Traceback objects
On 9/4/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > Christopher Armstrong <[EMAIL PROTECTED]> writes: > > > I had the idea to create a fake Traceback object in Python that > > doesn't hold references to any frame objects, but is still able to be > > passed to 'raise' and formatted as tracebacks are, etc. Unfortunately, > > raise does a type check on its third argument and, besides, it seems > > the traceback formatting functions are very reliant on the internal > > structure of traceback objects, so that didn't work. > > An option you may not have considered is to ditch the C code that > formats tracebacks and always use traceback.py (this has a few obvious > problems -- what do you do if traceback.py fails to import, what if > formatting the traceback raises an error -- but nothing too > horrendous, I think). > > Less duplication and less C code are always good things (IMHO, at > least). The problem is, I can't tell Python to use traceback.py to format specifically these tracebacks. Or are you suggesting replacing all of Python's internal traceback printing stuff with traceback.py? I think that's a great idea, and it's what I assumed happened before I found these C-coded printing routines. On the other hand, that has the same problem that the "change to python attribute access" has, specifically that it *requires* a change to CPython itself, and can't be done in an extension module. But that's a purely selfish concern. :) I'm pretty close to getting the extension module that constructs frames, but I'm dealing with segfaults now. Man, PyFrame_New does some weird stuff. :) I may try for another day to get the extension module working, then perhaps give up and try on one of the hacking-CPython strategy. > > One concern is that I really don't like requiring C modules to use > > Twisted; all of the ones currently in there are optional. > > Well, presumably this is optional too -- you only need it if you want > informative tracebacks... Yes, that's true. -- Twisted | Christopher Armstrong: International Man of Twistery Radix|-- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// |-- http://twistedmatrix.com |o O|| wvw-+ ___ 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
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 [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
Steve Holden wrote: > Since Python strings *can* contain embedded NULs, doesn't that rather > poo on the idea of passing pointers to their data to C functions as > things stand? If a Python function is clearly wrapping a C function, one doesn't expect to be able to pass strings with embedded NULs to it. Just because a Python string can contain embedded NULs doesn't mean it makes sense to use such strings in all circumstances. -- 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 [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] Pascaloid print substitute (Replacement for print in Python 3.0)
Here's a non-statement print substitute that provides
space insertion and newline suppression, and as a bonus
it allows Pascal-style numeric formatting.
Usage examples:
Print["The answer is", 42]
Print["Tons of spam:", n:6]
Print[x:5:2, "squared is", x*x:10:4]
Print["One", "Two", ...]
Print["Buckle my shoe"]
#
import sys
class PasFormat(object):
def __init__(self, f):
self.f = f
def __getitem__(self, arg):
#print "PasFormat.__getitem__:", arg
if isinstance(arg, tuple):
space = ""
for item in arg:
self.f.write(space)
if item is Ellipsis:
break
self._do(item)
space = " "
else:
self.f.write("\n")
else:
self._do(arg)
self.f.write("\n")
def _do(self, item):
if isinstance(item, slice):
value = item.start
width = item.stop or 0
decimals = item.step
else:
value = item
width = 0
decimals = None
if decimals is not None:
chars = "%*.*f" % (width, decimals, value)
else:
chars = "%*s" % (width, value)
self.f.write(chars)
Print = PasFormat(sys.stdout)
if __name__ == "__main__":
n = 666
x = 3.1415
Print["The answer is", 42]
Print["Tons of spam:", n:6]
Print[x:5:2, "squared is", x*x:10:4]
Print["One", "Two", ...]
Print["Buckle my shoe"]
#
--
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
[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 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 [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 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 [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 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 [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 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 [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, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> You can definitely argue about keeping formatting and print separate,
> but I think Guido and others have explained the problems with %.
To reiterate, "%s" % x is unsafe if you aren't sure that x can't be a
tuple -- you'd have to write "%s" % (x,) if it can be one. Also,
print("%s %s" % (a, b)) looks a bit ugly with the irregular
punctuation. While I'm not going so far as to want a statement
dedicated to printing, I'm not against having some redundancy for such
an important piece of functionality.
> Also,
> we already have precedence in format+print in the logging package. I
> actually think the logging provides a nice, fairly to use interface that
> print-ng can be modeled on.
Right. I just have one additional suggestion for the logging package
(not sure if it should apply to printf as well): if there's a problem
with the format operator, fall back to printing the format string
followed by the argument values (if any) without any formatting --
when logging, that's a much better thing to do than dying with an
exception. As I said, not sure if printf() should have the same
behavior; it's wort a try though.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
[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] Pascaloid print substitute (Replacement for print inPython 3.0)
>Print["One", "Two", ...] >Print["Buckle my shoe"] The ellipsis was a nice touch. Raymond ___ 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] gdbinit problem
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. n -- more gory details. after the patch, i get the expected results: (gdb) pystack ./pychecker/checker.py (573): _initModule ./pychecker/checker.py (537): load ./pychecker/checker.py (517): addModule ./pychecker/checker.py (574): _initModule ./pychecker/checker.py (537): load ./pychecker/checker.py (517): addModule ./pychecker/checker.py (574): _initModule ./pychecker/checker.py (540): load ./pychecker/checker.py (668): processFiles ./pychecker/checker.py (721): main ./pychecker/checker.py (741): ? before the patch, i get this: (gdb) pystack ./pychecker/checker.py (Breakpoint 1 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 2 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 3 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 4 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 5 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 6 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 7 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 8 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 9 at 0x455372: file Objects/typeobject.c, line 2012. 584): _initModule ./pychecker/checker.py (Breakpoint 10 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 11 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 12 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 13 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 14 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 15 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 16 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 17 at 0x455372: file Objects/typeobject.c, line 2012. 545): load ./pychecker/checker.py (Breakpoint 18 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 19 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 20 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 21 at 0x455372: file Objects/typeobject.c, line 2012. 521): addModule ./pychecker/checker.py (Breakpoint 22 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 23 at 0x455372: file Objects/typeobject.c, line 2012. ---Type to continue, or q to quit--- Breakpoint 24 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 25 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 26 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 27 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 28 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 29 at 0x455372: file Objects/typeobject.c, line 2012. 584): _initModule ./pychecker/checker.py (Breakpoint 30 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 31 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 32 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 33 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 34 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 35 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 36 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 37 at 0x455372: file Objects/typeobject.c, line 2012. 545): load ./pychecker/checker.py (Breakpoint 38 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 39 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 40 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 41 at 0x455372: file Objects/typeobject.c, line 2012. 521): addModule ./pychecker/checker.py (Breakpoint 42 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 43 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 44 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 45 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 46 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 47 at 0x455372: file Objects/typeobject.c, line 2012. ---Type to continue, or q to quit--- Breakpoint 48 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 49 at 0x455372: file Objects/typeobject.c, line 2012. 584): _initModule ./pychecker/checker.py (Breakpoint 50 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 51 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 52 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 53 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 54 at 0x455372: file Objects/typeobject.c, line 2012. Breakpoint 55 at 0x455372: file Ob
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
