[Nick Coghlan]
Print as statement = printing sequences nicely is a pain
What's wrong with this?
print range(10)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
print tuple(string)
('s', 't', 'r', 'i', 'n', 'g')
This is a serious question - that's how I would expect a print function to
work anyway.
Print as
[...]
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
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;
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
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
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. ;-)
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
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
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
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
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
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
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
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.
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
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
[Barry]
Actually, we probably only /need/ printf(), and certainly for C
programmers (are there any of us left? ;), I think that would be a
small
conceptual leap. The motivation for keeping a non-formatting version
is
for simple cases, and beginners -- both of which use cases should not
be
On 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
[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
[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
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
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:
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
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
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
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
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, ...]
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
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
On Sun, 2005-09-04 at 11:59, Guido van Rossum wrote:
I agree that those are strong arguments, so please hear me out.
Thanks Guido, I think your arguments are powerful too.
-Barry
signature.asc
Description: This is a digitally signed message part
On 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
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
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
33 matches
Mail list logo
