Here is a pre-PEP about print that I wrote recently.
Please let me know what is the community's opinion on it.
Cheers,
Marcin
PEP: XXX
Title: Print Without Intervening Space
Version: $Revision: 0.0 $
Author: Marcin Ciura <marcin.ciura at polsl.pl>
Status: Draft
Type: Standards Track
Created: 11-Mar-2005
Post-History: 11-Mar-2005
Abstract
This PEP proposes to extend the syntax of the print statement
so that its space-insertion mechanism can be selectively
disabled by using double instead of single commas.
Rationale
The print statement can write several expressions in one line,
but presently always separates them with spaces. While this
behaviour is often desirable, not uncommon are situations, where
programmers have to use workarounds to achieve a non-spaced
display. This has been recognized as one of "Python Gotchas"
[1]. Even the simplest workaround results in an unnecessarily
complicated code (for the sake of simplicity let us assume that
fn() returns strings):
result = ''
for x in seq:
result += fn(x)
print result
Not to mention it also has a terrible algorithmic complexity.
None of the more efficient solutions is particularly
straightforward, either:
result = []
for x in seq:
result.append(fn(x))
print ''.join(result)
print ''.join([fn(x) for x in seq])
print ''.join(fn(x) for x in seq)
Moreover, all of them require creating one or two temporary
objects to hold the entire result. If the programmers use one of
them without qualms, it is only because their mind is warped by
the limitation of print.
Using write() is not especially appealing either, especially if
the print statements are used elsewhere in the code:
import sys
for x in seq:
sys.stdout.write(fn(x))
print # or sys.stdout.write('\n')
The proposed extension to the print statement is to use two
commas to signal that no space should be written after an
expression:
for x in seq:
print fn(x),,
print
To quote "The Zen of Python" [2]: "Beautiful is better than ugly.
Simple is better than complex. Readability counts."
The proposal applies also to the expressions in the middle of
the print statement. Thus it provides an alternative to string
concatenation and string interpolation, either with the '%'-based
specifiers, or with the '$'-based ones introduced by PEP 292 [3],
not requiring creating a temporary string object:
print 'The phone number is (',,extension,,')', number,,'.'
Note that I do not claim that the above version is any more
readable than
print 'The phone number is (%s) %s.' % (extension, number)
Specification
It is proposed to allow separating the expressions to be printed
by single or double commas, and to allow single or double commas
at the end of the print statement. The two commas shall be
consecutive, i.e. there shall be no whitespace between them.
Non-consecutive commas or any sequence of more than two commas
constitute a syntax error. In the "print chevron" form of the
statement, the name of the file object shall be separated from
the next expression only by a single comma, as it is now.
Formally, the proposed syntax of the extended print statement is
print_stmt: "print"
( [expression (("," | ",,") expression)* ["," | ",,"]]
| ">>" expression [(","
expression (("," | ",,") expression)* ["," | ",,"]]
Implementing the proposed syntax may require introducing a new
type of token: double comma, or a hack in the parser to recognize
two consecutive commas in the context of the print statement.
Two new byte codes, parallel to PRINT_ITEM and PRINT_ITEM_TO, are
needed to implement the semantics of the proposal.
Discussion
Pros:
- The proposed semantics allows avoiding temporary string objects
during the execution of the print statement and often makes for
more readable and explicit source code.
- The proposed syntax is easy to learn for the beginners.
- It breaks no existing Python code.
- Mistakes are unlikely to happen with the proposed syntax,
unless someone has problems with his typing or his keyboard,
in which case any programming is difficult, anyway.
Cons:
- Wrapper functions around print will be unable to mimic its
syntax. It is, however, impossible even now, due to trailing
commas.
- In PEP 259 [4], the BDFL has pronounced that he wants to avoid
any more tinkering with "print".
- PEP 3000 [5] and "Python Regrets" [6] state that the print
statement is to be replaced with a function in Python 3000,
so extending it may be a dead path.
References
[1] Python Gotchas, Steve Ferg: http://www.ferg.org/projects/python_gotchas.html
[2] The Zen of Python, Tim Peters http://www.python.org/doc/Humor.html
[3] PEP 292, Simpler String Substitutions, Barry A. Warsaw: http://www.python.org/peps/pep-0292.html
[4] PEP 259, Omit printing newline after newline,
Guido van Rossum: http://www.python.org/peps/pep-0259.html
[5] PEP 3000, Python 3.0 Plans, A.M. Kuchling, Brett Cannon: http://www.python.org/peps/pep-3000.html
[6] Python Regrets, Guido van Rossum: http://www.python.org/doc/essays/ppt...honRegrets.pdf
Copyright
This document has been placed in the public domain.
...
Local Variables:
mode: indented-text
indent-tabs-mode: nil
sentence-end-double-space: t
fill-column: 70
End: 14 2874
Marcin Ciura wrote: None of the more efficient solutions is particularly straightforward, either:
result = [] for x in seq: result.append(fn(x)) print ''.join(result)
print ''.join([fn(x) for x in seq])
print ''.join(fn(x) for x in seq)
Moreover, all of them require creating one or two temporary objects to hold the entire result. If the programmers use one of them without qualms, it is only because their mind is warped by the limitation of print.
I can't say I lose much sleep over this, but you could add my preferred
workaround to the list (I don't believe it suffers from the same drawbacks
as the options you propose) and say why your comma solution is better than
it:
import sys
def nospace(value, stream=None):
'''Suppress output of space before printing value'''
stream = stream or sys.stdout
stream.softspace = 0
return str(value) print "a", nospace("b")
ab def fn(x):
return "<%s>" % x
for i in range(10):
print nospace(fn(i)),
<0><1><2><3><4><5><6><7><8><9>
Duncan Booth wrote: import sys def nospace(value, stream=None): '''Suppress output of space before printing value''' stream = stream or sys.stdout stream.softspace = 0 return str(value)
I'm teaching Python as the first programming language to non-computer
scientists. Many of the toy programs would be simpler with the double
comma syntax. Presently, having a choice whether to teach my students
the result += fn(x) way or your way, I would still opt for the former.
Best regards,
Marcin
Marcin Ciura wrote: Here is a pre-PEP about print that I wrote recently. Please let me know what is the community's opinion on it.
Cheers, Marcin
PEP: XXX Title: Print Without Intervening Space Version: $Revision: 0.0 $ Author: Marcin Ciura <marcin.ciura at polsl.pl> Status: Draft Type: Standards Track Created: 11-Mar-2005 Post-History: 11-Mar-2005
Abstract
This PEP proposes to extend the syntax of the print statement so that its space-insertion mechanism can be selectively disabled by using double instead of single commas.
Rationale
The print statement can write several expressions in one line, but presently always separates them with spaces. While this behaviour is often desirable, not uncommon are situations, where programmers have to use workarounds to achieve a non-spaced display. This has been recognized as one of "Python Gotchas" [1]. Even the simplest workaround results in an unnecessarily complicated code (for the sake of simplicity let us assume that fn() returns strings):
result = '' for x in seq: result += fn(x) print result
Not to mention it also has a terrible algorithmic complexity. None of the more efficient solutions is particularly straightforward, either:
result = [] for x in seq: result.append(fn(x)) print ''.join(result)
print ''.join([fn(x) for x in seq])
print ''.join(fn(x) for x in seq)
Moreover, all of them require creating one or two temporary objects to hold the entire result. If the programmers use one of them without qualms, it is only because their mind is warped by the limitation of print.
Using write() is not especially appealing either, especially if the print statements are used elsewhere in the code:
import sys for x in seq: sys.stdout.write(fn(x)) print # or sys.stdout.write('\n')
The proposed extension to the print statement is to use two commas to signal that no space should be written after an expression:
for x in seq: print fn(x),, print
To quote "The Zen of Python" [2]: "Beautiful is better than ugly. Simple is better than complex. Readability counts."
The proposal applies also to the expressions in the middle of the print statement. Thus it provides an alternative to string concatenation and string interpolation, either with the '%'-based specifiers, or with the '$'-based ones introduced by PEP 292 [3], not requiring creating a temporary string object:
print 'The phone number is (',,extension,,')', number,,'.'
Note that I do not claim that the above version is any more readable than
print 'The phone number is (%s) %s.' % (extension, number)
Specification
It is proposed to allow separating the expressions to be printed by single or double commas, and to allow single or double commas at the end of the print statement. The two commas shall be consecutive, i.e. there shall be no whitespace between them. Non-consecutive commas or any sequence of more than two commas constitute a syntax error. In the "print chevron" form of the statement, the name of the file object shall be separated from the next expression only by a single comma, as it is now.
Formally, the proposed syntax of the extended print statement is
print_stmt: "print" ( [expression (("," | ",,") expression)* ["," | ",,"]] | ">>" expression [("," expression (("," | ",,") expression)* ["," | ",,"]]
Implementing the proposed syntax may require introducing a new type of token: double comma, or a hack in the parser to recognize two consecutive commas in the context of the print statement.
Two new byte codes, parallel to PRINT_ITEM and PRINT_ITEM_TO, are needed to implement the semantics of the proposal.
Discussion
Pros:
- The proposed semantics allows avoiding temporary string objects during the execution of the print statement and often makes for more readable and explicit source code.
- The proposed syntax is easy to learn for the beginners.
- It breaks no existing Python code.
- Mistakes are unlikely to happen with the proposed syntax, unless someone has problems with his typing or his keyboard, in which case any programming is difficult, anyway.
Cons:
- Wrapper functions around print will be unable to mimic its syntax. It is, however, impossible even now, due to trailing commas.
- In PEP 259 [4], the BDFL has pronounced that he wants to avoid any more tinkering with "print".
- PEP 3000 [5] and "Python Regrets" [6] state that the print statement is to be replaced with a function in Python 3000, so extending it may be a dead path.
References
[1] Python Gotchas, Steve Ferg: http://www.ferg.org/projects/python_gotchas.html
[2] The Zen of Python, Tim Peters http://www.python.org/doc/Humor.html
[3] PEP 292, Simpler String Substitutions, Barry A. Warsaw: http://www.python.org/peps/pep-0292.html
[4] PEP 259, Omit printing newline after newline, Guido van Rossum: http://www.python.org/peps/pep-0259.html
[5] PEP 3000, Python 3.0 Plans, A.M. Kuchling, Brett Cannon: http://www.python.org/peps/pep-3000.html
[6] Python Regrets, Guido van Rossum: http://www.python.org/doc/essays/ppt...honRegrets.pdf
Copyright
This document has been placed in the public domain.
.. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:
I also don't miss a no-space option on print. I've always believed
that print statements with commas in them were for simple output with
little or no regard for formatting (like for debugging statements).
If I want precisely formatted output I use '%' formats or I build
the output line manually with joins or some other mechanism. The
''.join(seq) or ''.join([fn(x) for x in seq]) says exactly what
is being done to create the output string. I fail to see why
your proposed solution of:
for x in seq:
print fn(x),,
print
is clearer than:
print ''.join([fn(x) for x in seq])
Also your statement:
print 'The phone number is (',,extension,,')', number,,'.'
requires three double commas and can already be written
more clearly as:
print 'The phone number is ('+extension+') '+number'.'
or even more clearly (as you stated)
print 'The phone number is (%s) %s' % (extension, number)
Just my 2 cents.
Larry Bates
Larry Bates wrote: I fail to see why your proposed solution of: for x in seq: print fn(x),, print is clearer than: print ''.join([fn(x) for x in seq])
Thank you for your input. The latter form is fine with me personally,
but you just can't explain it to complete novices. My proposal aims
at making programming easier for them.
Also your statement: print 'The phone number is (',,extension,,')', number,,'.' requires three double commas and can already be written more clearly as: print 'The phone number is ('+extension+') '+number'.'
I agree with you in this point (if extension and number are strings).
Best regards,
Marcin
On Fri, 11 Mar 2005 10:00:03 -0600, Larry Bates <lb****@syscononline.com> wrote: I also don't miss a no-space option on print. I've always believed that print statements with commas in them were for simple output with little or no regard for formatting (like for debugging statements). If I want precisely formatted output I use '%' formats or I build the output line manually with joins or some other mechanism. The ''.join(seq) or ''.join([fn(x) for x in seq]) says exactly what is being done to create the output string.
I agree with everything said here. Furthermore, I don't like this PEP
because it introduces magic. When reading code, you just need to
magically know what the double-comma does in a print statement. Yes,
there are bits of magic involved in the solutions that already exist,
but I am opposed to the introduction of more.
Peace
Bill Mill
bill.mill at gmail.com
I'm against further tinkering with Print on a number
of grounds, not least of which is that it's going
away in Python 3.0. It seems like wasted effort.
I don't see much difficulty with the current behavior:
if you want to get rid of the spaces, there are
alternatives.
I don't buy the novice arguement. If you want,
you can always implement your own print
function with a variable number of arguements
and just about any semantics you want.
John Roth
"Marcin Ciura" <ma****************@NOSPAMpolsl.pl> wrote in message
news:39*************@individual.net... Here is a pre-PEP about print that I wrote recently. Please let me know what is the community's opinion on it.
Cheers, Marcin
PEP: XXX Title: Print Without Intervening Space Version: $Revision: 0.0 $ Author: Marcin Ciura <marcin.ciura at polsl.pl> Status: Draft Type: Standards Track Created: 11-Mar-2005 Post-History: 11-Mar-2005
Abstract
This PEP proposes to extend the syntax of the print statement so that its space-insertion mechanism can be selectively disabled by using double instead of single commas.
Rationale
The print statement can write several expressions in one line, but presently always separates them with spaces. While this behaviour is often desirable, not uncommon are situations, where programmers have to use workarounds to achieve a non-spaced display. This has been recognized as one of "Python Gotchas" [1]. Even the simplest workaround results in an unnecessarily complicated code (for the sake of simplicity let us assume that fn() returns strings):
result = '' for x in seq: result += fn(x) print result
Not to mention it also has a terrible algorithmic complexity. None of the more efficient solutions is particularly straightforward, either:
result = [] for x in seq: result.append(fn(x)) print ''.join(result)
print ''.join([fn(x) for x in seq])
print ''.join(fn(x) for x in seq)
Moreover, all of them require creating one or two temporary objects to hold the entire result. If the programmers use one of them without qualms, it is only because their mind is warped by the limitation of print.
Using write() is not especially appealing either, especially if the print statements are used elsewhere in the code:
import sys for x in seq: sys.stdout.write(fn(x)) print # or sys.stdout.write('\n')
The proposed extension to the print statement is to use two commas to signal that no space should be written after an expression:
for x in seq: print fn(x),, print
To quote "The Zen of Python" [2]: "Beautiful is better than ugly. Simple is better than complex. Readability counts."
The proposal applies also to the expressions in the middle of the print statement. Thus it provides an alternative to string concatenation and string interpolation, either with the '%'-based specifiers, or with the '$'-based ones introduced by PEP 292 [3], not requiring creating a temporary string object:
print 'The phone number is (',,extension,,')', number,,'.'
Note that I do not claim that the above version is any more readable than
print 'The phone number is (%s) %s.' % (extension, number)
Specification
It is proposed to allow separating the expressions to be printed by single or double commas, and to allow single or double commas at the end of the print statement. The two commas shall be consecutive, i.e. there shall be no whitespace between them. Non-consecutive commas or any sequence of more than two commas constitute a syntax error. In the "print chevron" form of the statement, the name of the file object shall be separated from the next expression only by a single comma, as it is now.
Formally, the proposed syntax of the extended print statement is
print_stmt: "print" ( [expression (("," | ",,") expression)* ["," | ",,"]] | ">>" expression [("," expression (("," | ",,") expression)* ["," | ",,"]]
Implementing the proposed syntax may require introducing a new type of token: double comma, or a hack in the parser to recognize two consecutive commas in the context of the print statement.
Two new byte codes, parallel to PRINT_ITEM and PRINT_ITEM_TO, are needed to implement the semantics of the proposal.
Discussion
Pros:
- The proposed semantics allows avoiding temporary string objects during the execution of the print statement and often makes for more readable and explicit source code.
- The proposed syntax is easy to learn for the beginners.
- It breaks no existing Python code.
- Mistakes are unlikely to happen with the proposed syntax, unless someone has problems with his typing or his keyboard, in which case any programming is difficult, anyway.
Cons:
- Wrapper functions around print will be unable to mimic its syntax. It is, however, impossible even now, due to trailing commas.
- In PEP 259 [4], the BDFL has pronounced that he wants to avoid any more tinkering with "print".
- PEP 3000 [5] and "Python Regrets" [6] state that the print statement is to be replaced with a function in Python 3000, so extending it may be a dead path.
References
[1] Python Gotchas, Steve Ferg: http://www.ferg.org/projects/python_gotchas.html
[2] The Zen of Python, Tim Peters http://www.python.org/doc/Humor.html
[3] PEP 292, Simpler String Substitutions, Barry A. Warsaw: http://www.python.org/peps/pep-0292.html
[4] PEP 259, Omit printing newline after newline, Guido van Rossum: http://www.python.org/peps/pep-0259.html
[5] PEP 3000, Python 3.0 Plans, A.M. Kuchling, Brett Cannon: http://www.python.org/peps/pep-3000.html
[6] Python Regrets, Guido van Rossum: http://www.python.org/doc/essays/ppt...honRegrets.pdf
Copyright
This document has been placed in the public domain.
.. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 End:
In view of Duncan's response, which invalidates the premises
of my proposal, I announce the end of its short life. I will
add Duncan's solution to my bag of tricks - thank you!
Marcin
Marcin Ciura wrote: Duncan Booth wrote:
import sys def nospace(value, stream=None): '''Suppress output of space before printing value''' stream = stream or sys.stdout stream.softspace = 0 return str(value)
I'm teaching Python as the first programming language to non-computer scientists. Many of the toy programs would be simpler with the double comma syntax. Presently, having a choice whether to teach my students the result += fn(x) way or your way, I would still opt for the former.
Best regards, Marcin
You could think about teaching them the linelist.append(fn(x)) way,
which then gives you the choice of
"".join(linelist) - no gaps
"\n".join(lienlist) - one item per line
" ".join(linelist) - spaces between items.
regards
Steve
--
Steve Holden +1 703 861 4237 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
Python Web Programming http://pydish.holdenweb.com/
On Fri, 11 Mar 2005 10:59:16 -0500, Steve Holden <st***@holdenweb.com> wrote: Marcin Ciura wrote: Duncan Booth wrote:
import sys def nospace(value, stream=None): '''Suppress output of space before printing value''' stream = stream or sys.stdout stream.softspace = 0 return str(value)
I'm teaching Python as the first programming language to non-computer scientists. Many of the toy programs would be simpler with the double comma syntax. Presently, having a choice whether to teach my students the result += fn(x) way or your way, I would still opt for the former.
I guess you are assuming fn(x) returns a string, or result knows how to
do += for whatever you are passing to it?
BTW, what makes you think any self-respecting "scientist" wouldn't be insulted
by the idea of your spoon-feeding them a dumbed-down programming equivalent of
"See Spot run"? IMO, if you were coaching althletes like that, you'd be fired,
because none of your team except the naturals would be able to run the length
of the ball field, and the natural athletes would have no use or respect for you.
Of course, you may be a suffering victim of circumstances, I don't know. Fortunately,
Python is not that hard, and rapidly becomes fun unless the initial experience
is structured against discovering the expressive power that is so enjoyable.
If you want the effect of print x, y, fn(z), etc without spaces, why don't you
just write a function that will let you spell it simply, like
marcinprint(x, y, fn(z), etc)
e.g., import sys def marcinprint(*args):
... sys.stdout.write(''.join(map(str, args)))
... print 1,'two', 0x3, 4.5, fn(6)
1 two 3 4.5
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'fn' is not defined
oops
def fn(x): return 2**x
... print 1,'two', 0x3, 4.5, fn(6)
1 two 3 4.5 64
marcinprint(1,'two', 0x3, 4.5, fn(6))
1two34.564>>>
Might want to put a line ending on that ...
marcinprint(1,'two', 0x3, 4.5, fn(6), '\n')
1two34.564 marcinprint(1,'two', 0x3, 4.5, fn(6)); print
1two34.564
If you are used to C, you can get something familiar using
import sys def printf(fmt, *args):
... sys.stdout.write(fmt %args)
...
Which you can use like
printf('%03d %r %3d %5.2f %5d\n',1,'two', 0x3, 4.5, fn(6))
001 'two' 3 4.50 64 Best regards, Marcin You could think about teaching them the linelist.append(fn(x)) way, which then gives you the choice of
"".join(linelist) - no gaps "\n".join(lienlist) - one item per line " ".join(linelist) - spaces between items.
IMO teachers should lead their students into contact with reality,
not insulate them from it with delusionary simplifications that
they will have to unlearn in order to progress.
Regards,
Bengt Richter
Steve Holden wrote: You could think about teaching them the linelist.append(fn(x)) way, which then gives you the choice of "".join(linelist) - no gaps "\n".join(lienlist) - one item per line " ".join(linelist) - spaces between items.
Sure I will. Next week, when we come to list operations.
..join() they already know. I just couldn't use this approach
at the very beginning. Thanks to all who responded.
Regards,
Marcin
Marcin Ciura wrote: Duncan Booth wrote:
import sys def nospace(value, stream=None): '''Suppress output of space before printing value''' stream = stream or sys.stdout stream.softspace = 0 return str(value)
I'm teaching Python as the first programming language to non-computer scientists. Many of the toy programs would be simpler with the double comma syntax. Presently, having a choice whether to teach my students the result += fn(x) way or your way, I would still opt for the former.
Best regards, Marcin
Since you're teaching python, why not teach the python way instead of
inventing a new way.
print 'The phone number is (%s) %s' % (extension, number)
IMO is by far the superior and clearest way for string concatenation for
any purpose eg. printing or assignment. This would mean you are making
your students lives easier by showing them one good method of doing
string concatenation which can be applied to printing as well.
Huy
Bengt Richter wrote: BTW, what makes you think any self-respecting "scientist" wouldn't be insulted by the idea of your spoon-feeding them a dumbed-down programming equivalent of "See Spot run"?
Am I right thinking that your dream 3 R's curriculum starts with
"Stately, plump Buck Mulligan" and Pólya Enumeration Theorem?
Most of them have no previous programming experience, mind you.
Of course, you may be a suffering victim of circumstances, I don't know.
They're not so bad: I deliver the lectures (1.5 h/week), and there are
also laboratory classes (1.5 h/week). During one semester, most of
Python topics are covered.
Fortunately, Python is not that hard, and rapidly becomes fun unless the initial experience is structured against discovering the expressive power that is so enjoyable.
I wholeheartedly agree with you in this point. I'm sure my students
would appreciate being taught Python instead of Pascal if they had
a chance to compare them.
If you want the effect of print x, y, fn(z), etc without spaces, why don't you just write a function that will let you spell it simply, like
Excellent advice, provided that you already know the concept
of user-defined functions.
IMO teachers should lead their students into contact with reality, not insulate them from it with delusionary simplifications that they will have to unlearn in order to progress.
I'm not sure what you mean by "delusionary simplifications",
but I hope you meant nothing insulting. They already know how to
use string interpolation, and as soon as they learn how to mutate
the contents of a list, I'll tell them to use looped .append()
followed by .join() instead of looped string concatenation,
and explain why.
Best regards,
Marcin
Op 2005-03-11, Marcin Ciura schreef <ma****************@NOSPAMpolsl.pl>: Moreover, all of them require creating one or two temporary objects to hold the entire result. If the programmers use one of them without qualms, it is only because their mind is warped by the limitation of print.
Using write() is not especially appealing either, especially if the print statements are used elsewhere in the code:
Personnaly I think just the reversed. I don't use print anywhere
unless for debugging purposes. I always use write
import sys for x in seq: sys.stdout.write(fn(x)) print # or sys.stdout.write('\n')
The proposed extension to the print statement is to use two commas to signal that no space should be written after an expression:
for x in seq: print fn(x),, print
To quote "The Zen of Python" [2]: "Beautiful is better than ugly. Simple is better than complex. Readability counts."
IMO that favors using always write instead of using print with it
various extentions.
For instance if I do the following
a = 1,
I have assigned a one element tuple to a.
But if I do
print 1,
It doesn't print a one element tuple.
--
Antoon Pardon
Antoon Pardon <ap*****@forel.vub.ac.be> wrote: For instance if I do the following a = 1, I have assigned a one element tuple to a. But if I do print 1, It doesn't print a one element tuple.
And if you do
parrot(1,)
you won't call parrot() with a one-element tuple either. However,
'parrot(1)' and 'parrot(1,)' means exactly the same thing, while
'print 1' and 'print 1,' does not.
--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"Adde parvum parvo magnus acervus erit" ! bellman @ lysator.liu.se
(From The Mythical Man-Month) ! Make Love -- Nicht Wahr! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: GriffithsJ |
last post by:
Hi
I have been given some text that needs to be displayed on a web page. The
text is pre-formatted (includes things like lists etc) and displays okay if
I wrap it using the <pre/> tag. ...
|
by: Porthos |
last post by:
Hi All,
I'm building an XSL document that puts two types of
information in a table dimension: preformatted data and data
extracted from my XML document (see below)
<table>
<tr>
|
by: Alan Illeman |
last post by:
How do I set several different properties for PRE in
a CSS stylesheet, rather than resorting to this:
<BODY>
<PRE STYLE="font-family:monospace;
font-size:0.95em;
width:40%;
border:red 2px...
|
by: Roderik |
last post by:
Hi,
When I use <pre> inside my <td> cells, the text won't flow to a new line
and the table gets to large in width. This will appear in Firefox this
way, Internet Explorer will wrap the lines,...
|
by: Porthos |
last post by:
I'm authoring an XML document and using the <pre> html tag for the
portions that are not dynamically generated. The <pre> text is
displaying in a smaller font size (and I believe different font)...
|
by: R0bert Nev1lle |
last post by:
Here's my next IE challenge (or frustration). It deals with the
overflow attribute. Overflow property was a challenge on my page since
the page emulates position fixed for IE.
The present...
|
by: Jarno Suni not |
last post by:
It seems to be invalid in HTML 4.01, but valid in XHTML 1.0. Why is there the difference? Can that pose a problem when such a XHTML document is served as text/html?
|
by: Rocky Moore |
last post by:
I have a web site called HintsAndTips.com. On this site people post tips
using a very simply webform with a multi line TextBox for inputing the tip
text. This text is encode to HTML so that no...
|
by: Eric Lindsay |
last post by:
I can't figure how to best display little snippets of shell script using
<pre>. I just got around to organising to bulk validate some of my web
pages, and one of the problems occurs with Bash...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |