Is it better to do:
message = """This is line1.
This is line2
This is line3\n"""
or
message = "This is line1.\n
message = message + "This is line2\n"
message = message + "This is line3\n"
Since the first method does not follow python's clean and easy looking
indentation structure but the second just looks crude and ugly anyway.
If I indent the first version so the text is lined up to match code
indentation then this comes out in the input and isn't aligned there.
21  1313 
Hari Sekhon wrote: Is it better to do:
message = """This is line1.
This is line2
This is line3\n"""
or
message = "This is line1.\n
message = message + "This is line2\n"
message = message + "This is line3\n"
Is there any reason you can't do it in one line?
message = "This is line1.\nThis is line2.\nThis is line3.\n"
Hari Sekhon wrote: Is it better to do:
message = """This is line1.
This is line2
This is line3\n"""
or
message = "This is line1.\n
message = message + "This is line2\n"
message = message + "This is line3\n"
Since the first method does not follow python's clean and easy looking
indentation structure but the second just looks crude and ugly anyway.
If I indent the first version so the text is lined up to match code
indentation then this comes out in the input and isn't aligned there.
How about
message = ("This is line1. "
"This is line2 "
"This is line3\n")
The brackets mean that the lines are automatically treated as
continuous, without the need for the ugly '\' continuation character.
The opening/closing quotes on each line mean that the strings are
contatenated into one long string.
Frank Millman
Frank Millman wrote:
How about
message = ("This is line1. "
"This is line2 "
"This is line3\n")
The brackets mean that the lines are automatically treated as
continuous, without the need for the ugly '\' continuation character.
The opening/closing quotes on each line mean that the strings are
contatenated into one long string.
Frank Millman
Don't know what happened there - Google seems to have messed up my
indentation.
My intention was that each of the three leading quote marks line up
vertically, but when I read it back via Google Groups, the second two
lines were pushed over to the right.
Frank
Hari Sekhon wrote: Is it better to do:
message = """This is line1.
This is line2
This is line3\n"""
or
message = "This is line1.\n
message = message + "This is line2\n"
message = message + "This is line3\n"
Since the first method does not follow python's clean and easy looking
indentation structure but the second just looks crude and ugly anyway.
If I indent the first version so the text is lined up to match code
indentation then this comes out in the input and isn't aligned there.
Hi,
msgs = ['This is line1.','This is line2.','This is line3.']
message = '\n'.join(msgs)
Regards,
Laurent.
Frank Millman wrote: How about
message = ("This is line1. "
"This is line2 "
"This is line3\n")
The brackets mean that the lines are automatically treated as
continuous, without the need for the ugly '\' continuation character.
The opening/closing quotes on each line mean that the strings are
contatenated into one long string.
Don't know what happened there - Google seems to have messed up my
indentation.
My intention was that each of the three leading quote marks line up
vertically, but when I read it back via Google Groups, the second two
lines were pushed over to the right.
assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
no matter what font you're using, you can write:
message = (
"This is line1. "
"This is line2 "
"This is line3\n")
whether this is better than """ depends on the situation.
</F>
Fredrik Lundh wrote: Frank Millman wrote:
How about
message = ("This is line1. "
"This is line2 "
"This is line3\n")
The brackets mean that the lines are automatically treated as
continuous, without the need for the ugly '\' continuation character.
The opening/closing quotes on each line mean that the strings are
contatenated into one long string.
Don't know what happened there - Google seems to have messed up my
indentation.
My intention was that each of the three leading quote marks line up
vertically, but when I read it back via Google Groups, the second two
lines were pushed over to the right.
assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
no matter what font you're using, you can write:
message = (
"This is line1. "
"This is line2 "
"This is line3\n")
whether this is better than """ depends on the situation.
</F>
Obvious, now that you mention it.
Thank you.
Frank
Hari Sekhon wrote: Since the first method does not follow python's clean and easy looking
indentation structure but the second just looks crude and ugly anyway.
If you want indented and pretty is important to you: from textwrap import dedent as D
message = D("""\
This is line1.
This is line2
This is line3
""") message
'This is line1.\nThis is line2\nThis is line3\n'
Usually though I would just make sure that long strings are declared at
module level and not indent them. The backslash after the opening quotes
stops the first line being indented differently:
message = """\
This is line1.
This is line2
This is line3
"""
Hari Sekhon wrote: Is it better to do:
message = """This is line1.
This is line2
This is line3\n"""
or
message = "This is line1.\n
message = message + "This is line2\n"
message = message + "This is line3\n"
Since the first method does not follow python's clean and easy looking
indentation structure but the second just looks crude and ugly anyway.
If I indent the first version so the text is lined up to match code
indentation then this comes out in the input and isn't aligned there.
What about
message = """
This is line 1
This is line 2
This is line 3
"""
When it is necessary to skip first empty line):
message = """
This is line 1
This is line 2
This is line 3
"""[1:]
When necessary to skip first line _and_ indentation:
message = """
This is line 1
This is line 2
This is line 3
""".replace('\n ', '\n')[1:] # adjust here '\n ' to indentation
# ^-- gives 'This is line 1\nThis is line 2\nThis is line 3\n'
?
Claudio
Claudio Grondi wrote:
<<<clever stuff to di indentation>>> When necessary to skip first line _and_ indentation:
message = """
This is line 1
This is line 2
This is line 3
""".replace('\n ', '\n')[1:] # adjust here '\n ' to indentation
Riffing on this idea:
message = """
This is line 1
This is line 2
This is line 3
""".replace("""
""", '\n')[1:]
--Scott David Daniels sc***********@acm.org
Scott David Daniels wrote: Claudio Grondi wrote:
<<<clever stuff to di indentation>>>
When necessary to skip first line _and_ indentation:
message = """
This is line 1
This is line 2
This is line 3
""".replace('\n ', '\n')[1:] # adjust here '\n ' to indentation
Riffing on this idea:
message = """
This is line 1
This is line 2
This is line 3
""".replace("""
""", '\n')[1:]
This was intended as an excercise for the OP in case he likes that kind
of solution ...
Claudio
--Scott David Daniels
sc***********@acm.org
Claudio Grondi wrote: Hari Sekhon wrote: On 26/06/06, *Claudio Grondi* <cl************@freenet.de
<mailto:cl************@freenet.de>> wrote:
Scott David Daniels wrote: > Claudio Grondi wrote:
> <<<clever stuff to di indentation>>>
>
>> When necessary to skip first line _and_ indentation:
>> message = """
>> This is line 1
>> This is line 2
>> This is line 3
>> """.replace('\n ', '\n')[1:] # adjust here '\n ' to
indentation >
>
> Riffing on this idea:
> message = """
> This is line 1
> This is line 2
> This is line 3
> """.replace("""
> """, '\n')[1:]
This was intended as an excercise for the OP in case he likes
that kind
of solution ...
Claudio
>
> --Scott David Daniels
> sc***********@acm.org <mailto:sc***********@acm.org>
--
http://mail.python.org/mailman/listinfo/python-list
I've decided to go with
message = (
"This is line1. "
"This is line2 "
"This is line3\n")
since I'm declaring many different messages inside various functions
I feel it is important to keep the indentaion and code both aligned
properly so the code looks nice and the output looks nice.
It is easier than doing replace and splicing since I want to keep it
as simple and clean as possible, in true pythonic tradition...
Thanks for the input!
-h
Thanks for the reply and the explanation what you finally decided to
go with.
I am so happy to have the triple quotes in Python, that I use them
whenever possible - this has probably something to do with my bias
towards plain text files with human readable content, so as
readability is very important to me (and probably to many other
Pythonistas) I like most the proposed by me triple quote style as the
quotation marks in the style you prefer make the text of the 'message'
less easy to read.
Now we can start a flame war about which style is more 'pythonic' ;-)
Claudio
I already explained that the triple quotes don't work tidily with
indentation, either the code is out of alignment or the printout is.
Either way isn't good.
Triple quotes are best at top level, but since I had to use many
messages inside functions etc, they broke the layout of the code.
I think they're both best depending on where you are putting them. I'm
doing very custom messages for each different result, so it would be
messy to do this at the top level.
-h
On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh <fr*****@pythonware.com> wrote:
.... assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
no matter what font you're using, you can write [...]
Since when? I've always coded, in all languages I've ever used[1], under the
assumption that the reader will view it with a fixed-pitch (or whatever the
proper term is) font. I assumed everyone else did, too. I still assume that,
in fact -- noone has ever come up to me and said "hey, that code you wrote
looks ugly in Comic Sans MS".
(I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
system for C++ code, where identifiers and strings are in Times italic,
operators in Courier, and so on.)
/Jorgen
[1] Too young for punch cards.
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
Jorgen Grahn wrote: assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
no matter what font you're using, you can write [...]
Since when? I've always coded, in all languages I've ever used[1], under the
assumption that the reader will view it with a fixed-pitch (or whatever the
proper term is) font. I assumed everyone else did, too.
that's a popular myth.
(I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
system for C++ code, where identifiers and strings are in Times italic,
operators in Courier, and so on.)
the idea of printing everything in courier (or some other monospace
font) is a rather new idea; if you read seventies stuff, the program
code is often as carefully designed as the rest of the document.
(for an indication that we might be moving back to nicely rendered code,
see Sun's new Fortress language, which provides extraordinarily detailed
control over how identifiers are rendered, including extensive support
for Unicode and math notation. it also mandates the use of proportional
fonts for things like identifiers and comments...)
</F>
Jorgen Grahn wrote: On Mon, 26 Jun 2006 11:47:21 +0200, Fredrik Lundh <fr*****@pythonware.com> wrote:
... assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
no matter what font you're using, you can write [...]
Since when? I've always coded, in all languages I've ever used[1], under the
assumption that the reader will view it with a fixed-pitch ... font. I assumed
everyone else did, too....
I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
system for C++ code, ....
See Knuth on Literate Programming and the "Web" systems (e.g. CWeb).
His goal is to look good typeset with explanation, and extract-to-compile.
--Scott David Daniels sc***********@acm.org
On Thu, 29 Jun 2006 15:31:53 -0700, Scott David Daniels <sc***********@acm.org> wrote:
.... I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
system for C++ code, ....
See Knuth on Literate Programming and the "Web" systems (e.g. CWeb).
His goal is to look good typeset with explanation, and extract-to-compile.
Yes, I'm aware of Knuth's work, and didn't mean to imply that Stroustrup did
something revolutionary -- although his book and Bertrand Meyer's Eiffel
book are the only ones I've read which try do something elegant with the
code typesetting.
I haven't read Knuth until now, so I assumed he typeset the actual code
parts fixed-width. I see in the CWeb manual that that's not the case.
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <fr*****@pythonware.com> wrote: Jorgen Grahn wrote:
assuming fixed-pitch fonts isn't very Pythonic, though; to get reliable indentation
no matter what font you're using, you can write [...]
Since when? I've always coded, in all languages I've ever used[1], under the
assumption that the reader will view it with a fixed-pitch (or whatever the
proper term is) font. I assumed everyone else did, too.
that's a popular myth.
I'm sorry, you will have to come up with some real references to convince me
(a PEP or preferrably something not Python-specific). Or not, because I will
keep assuming a fixed-width font in my programming anyway. Living the myth!
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <fr*****@pythonware.com> wrote: Jorgen Grahn wrote:
.... (I like well-typeset code in print though. Bjarne Stroustrup uses an elegant
system for C++ code, where identifiers and strings are in Times italic,
operators in Courier, and so on.)
the idea of printing everything in courier (or some other monospace
font) is a rather new idea; if you read seventies stuff, the program
code is often as carefully designed as the rest of the document.
Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the
time; these people all programmed using fixed-width fonts, on teletypes or
character-mapped terminals. Hell, even full-screen editors were new and
controversial until the late 1970s!
Program editing and displaying/typesetting can be treated as separate from
each other. Personally, I think they /should/ be -- I prefer troff or LaTeX
to MS Word, after all.
(for an indication that we might be moving back to nicely rendered code,
see Sun's new Fortress language, which provides extraordinarily detailed
control over how identifiers are rendered, including extensive support
for Unicode and math notation. it also mandates the use of proportional
fonts for things like identifiers and comments...)
And Sun apparently think they should not be separate.
To me, it looks like they are planning for this language to fail.
If I wanted to try out this language, I would have to give up most of my
existing toolbox -- which works flawlessly with everything from TI assembly
to Python. And what would people discuss on comp.lang.fortress? Google
destroys Python code well enough ...
/Jorgen
--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.dyndns.org> R'lyeh wgah'nagl fhtagn!
In article <sl***********************@frailea.sa.invalid>,
Jorgen Grahn <gr********@snipabacken.dyndns.org> writes:
|>
|> Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the
|> time; these people all programmed using fixed-width fonts, on teletypes or
|> character-mapped terminals. Hell, even full-screen editors were new and
|> controversial until the late 1970s!
A slight niggle - WYSIWYG wasn't unknown, just both rare and not yet
called that! I have programmed using devices with half-line shifts,
real backspacing and so on - and some languages did mandate that a
character created by overprinting was to be treated as a composite
character.
Also, there were full-screen editors for things like IBM 3270s, though
they were absolutely ghastly for editing text (being designed for form
filling).
I agree with you that neither those days nor gimmicky approaches like
that of Fortress are worth pursuing. One of the main reasons that
'program proving' has never taken off outside its cabal is that it
uses bizarre notations unlike anything else on earth that can't be
edited in a normal fashion.
Regards,
Nick Maclaren.
Jorgen Grahn wrote: On Thu, 29 Jun 2006 23:19:34 +0200, Fredrik Lundh <fr*****@pythonware.com> wrote: Jorgen Grahn wrote:
... (I like well-typeset code in print though....
Possibly true, and definitely for Knuth. But WYSIWYG was unknown at the
time; these people all programmed using fixed-width fonts, on teletypes or
character-mapped terminals. Hell, even full-screen editors were new and
controversial until the late 1970s!
Sorry, I'm old enough to have a few problems with this. WYSIWIG was
indeed well known at the time, and disparaged as WYSIAYG around where I
worked (What You See Is All You Get). We had full screen editors, with
proportional fonts; SAIL (Stanford AI Lab) had the first laser printer
to play with (people wrote incredibly ugly documents with tons of fonts
in them because it was the first they could spec it). All of this was
in the mid seventies or earlier.
--Scott David Daniels sc***********@acm.org
Scott David Daniels <sc***********@acm.orgwrote:
>
SAIL (Stanford AI Lab) had the first laser printer
to play with (people wrote incredibly ugly documents with tons of fonts
in them because it was the first they could spec it).
"Ransom note syndrome." Virtually everyone falls prey to this the first
few times they discover desktop publishing.
>All of this was in the mid seventies or earlier.
Right. It surprises many people to learn that virtually everything we
think of as modern and interesting in computer science was first explored
in the 1960s and early 1970s. GUIs, color, 3D, structured progamming,
networking, interpreters, Unix; the list goes on and on. It was probably
the most exciting time in the history of computers.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Tim Roberts wrote:
It surprises many people to learn that virtually everything we
think of as modern and interesting in computer science was first explored
in the 1960s and early 1970s. GUIs, color, 3D, structured progamming,
networking, interpreters, Unix; the list goes on and on. It was probably
the most exciting time in the history of computers.
Here I think you're wrong, my vote is the 1940s:
First time for tons of stuff, fate of the world hangs in the
balance, no idea if some of this is going to work, ....
Essentially all the crypto push with top secret machines decoding
German traffic, and the desperate attempt to crack the Japanese
Purple system. I expect the efforts at Bletchley Park, Princeton,
numerous unnamed locations, and even Germany and Japan were pulse-
pounding. In the sixties and seventies we were just having immense
fun making things go, at least by comparison.
--Scott David Daniels sc***********@acm.org This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: David MacQuigg |
last post by:
I have what looks like a bug trying to generate new style classes with
a factory function.
class Animal(object): pass
class Mammal(Animal): pass
def newAnimal(bases=(Animal,), dict={}):...
|
by: Christopher Benson-Manica |
last post by:
If you had an unsigned int that needed to be cast to a const myClass*,
would you use
const myClass* a=reinterpret_cast<const myClass*>(my_val);
or
const myClass* a=(const myClass*)myVal;
...
|
by: amerar |
last post by:
Hi All,
I can make a page using a style sheet, no problem there. However, if I
make an email and send it out to my list, Yahoo & Hotmail totally
ignore the style tags. It looks fine in...
|
by: amerar |
last post by:
Hi All,
I posted a question about style sheets, and why certain email clients
were ignoring them. Someone suggested placing them inline. I did
this and get better results, but not what I...
|
by: KvS |
last post by:
Hi all,
I'm pretty new to (wx)Python so plz. don't shoot me if I've missed
something obvious ;). I have a panel inside a frame, on which a Button
and a StaticText is placed:
self.panel =...
|
by: rahul8143 |
last post by:
hello,
what is difference between sizeof("abcd") and strlen("abcd")? why
both functions gives different output when applied to same string
"abcd".
I tried following example for that.
#include...
|
by: jamilur_rahman |
last post by:
What is the BIG difference between checking the "if(expression)" in A
and B ? I'm used to with style A, "if(0==a)", but my peer reviewer
likes style B, how can I defend myself to stay with style A...
|
by: pocmatos |
last post by:
Hi all,
While I was programming 5 minutes ago a recurring issue came up and
this time I'd like to hear some opinions on style. Although they are
usually personal I do think that in this case as...
|
by: Claus Mygind |
last post by:
I want to move some style setting into a javaScript function so I can make them variable but I get "invalid assignment left-hand side" error?
see my question at the bottom of this message.
It...
|
by: MatthewS |
last post by:
I've seen the question raised several times here, but apparently never
answered. Since PyInstance_Check returns False for new-style class
instances, is there a standard procedure for testing this...
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 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 former...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
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: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
| |
