>>/ msg = textwrap.dedent('''\
>/>/ IDLE's subprocess can't connect to %s:%d. This may be due \
>/>/ to your personal firewall configuration. It is safe to \
>/>/ allow this internal connection because no data is visible on \
>/>/ external ports.''' % address)
On 11/19/05, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > You are missing an important point here: There are intentionally no line
> > breaks in this string; it must be a single line, or else showerror will
> > break it in funny ways. So converting it to a multi-line string would
> > break it, ded
On 11/18/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
> > I just wanted to add another use case: long messages. Consider those
> > lines from idlelib/run.py:133
> >
> > msg = "IDLE's subprocess can't connect to %s:%d. This may be due "\
> > "to your
Noam Raphael wrote:
> I just wanted to add another use case: long messages. Consider those
> lines from idlelib/run.py:133
>
> msg = "IDLE's subprocess can't connect to %s:%d. This may be due "\
> "to your personal firewall configuration. It is safe to "\
> "a
Thanks for your examples. I understand tham sometimes it's a good idea
not to write the HTML inside the function (although it may be nice to
sometimes write it just before the function - and if it's a method,
then we get the same indentation problem.)
However, as you said, sometimes it is desired
Greg Ewing <[EMAIL PROTECTED]> writes:
> James Y Knight wrote:
>
>> ITYM you mean "If only python were lisp". (macros, or even reader macros)
>
> No, I mean it would be more satisfying if there
> were a syntax for expressing multiline string
> literals that didn't force it to be at the left
> mar
James Y Knight wrote:
> ITYM you mean "If only python were lisp". (macros, or even reader macros)
No, I mean it would be more satisfying if there
were a syntax for expressing multiline string
literals that didn't force it to be at the left
margin. The lack of such in such an otherwise
indentatio
Noam Raphael wrote:
> There's no reason why multilined strings that are used only once
> should be defined at the beginning of a program (think about a simple
> CGI script, which prints HTML parts in a function.)
I find that simple CGI scripts are precisely the example *for* putting
multi-line str
On 11/14/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> so is putting the string constant in a global variable, outside the scope
> you're in, like you'd do with any other constant.
Usually when I use a constant a single time, I write it where I use
it, and don't give it a name. I don't do:
messa
Noam Raphael wrote:
> That's a theoretical argument. In practice, if you do it in the
> parser, you have two options:
>
> 1. Automatically dedent all strings.
> 2. Add a 'd' or some other letter before the string.
>
> Option 1 breaks backwards compatibility, and makes the parser do
> unexpected th
Just two additional notes:
On 9/15/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> -1
>
> Let it continue to live in textwrap where the existing pure python code
> adequately serves all string-like objects. It's not worth losing the
> duck typing by attaching new methods to str, unicode, Use
On 11/14/05, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> We have to draw a line somewhere - otherwise you could
> just as well add all functions that accept single
> string arguments as methods to the basestring
> sub-classes.
Please read my first post in this thread - I think there's more reason
f
Gareth McCaughan wrote:
> On Sunday 2005-11-13 17:43, Marc-Andre Lemburg wrote:
>
> [Noam Raphael:]
>
>>>The idea is to add a method called "dedent" to strings. It would do
>>>exactly what the current textwrap.indent function does.
>
>
> [Marc-Andre:]
>
>>You are missing a point here: string
On Sunday 2005-11-13 17:43, Marc-Andre Lemburg wrote:
[Noam Raphael:]
> > The idea is to add a method called "dedent" to strings. It would do
> > exactly what the current textwrap.indent function does.
[Marc-Andre:]
> You are missing a point here: string methods were introduced
> to make switchi
On Nov 13, 2005, at 8:07 PM, Greg Ewing wrote:
> Ian Bicking wrote:
>
>
>> I think a better argument for this is that dedenting a literal
>> string is
>> more of a syntactic operation than a functional one. You don't think
>> "oh, I bet I'll need to do some dedenting on line 200 of this
>> m
Ian Bicking wrote:
> I think a better argument for this is that dedenting a literal string is
> more of a syntactic operation than a functional one. You don't think
> "oh, I bet I'll need to do some dedenting on line 200 of this module, I
> better import textwrap".
And regardless of the need to
> You are missing a point here: string methods were introduced
> to make switching from plain 8-bit strings to Unicode easier.
Is it the only purpose ?
I agree with the OP that using string methods is much nicer and more
convenient than having to import separate modules.
Especially, it is nice to
Noam Raphael wrote:
> Following Avi's suggestion, can I raise this thread up again? I think
> that Reinhold's .dedent() method can be a good idea after all.
>
> The idea is to add a method called "dedent" to strings. It would do
> exactly what the current textwrap.indent function does.
You are m
Raymond Hettinger wrote:
> That is somewhat misleading. We already have that ability. What is
> being proposed is moving existing code to a different namespace. So the
> motivation is really something like:
>
>I want to write
>s = s.dedent()
>because it is too painful to write
Noam Raphael wrote:
> Sorry, I didn't mean to mislead. I wrote "easily" - I guess using the
> current textwrap.dedent isn't really hard, but still, writing:
>
> import textwrap
> ...
>
> r = some_func(textwrap.dedent('''\
> line1
>
On 11/12/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > The motivation
> > is to be able to write multilined strings easily without damaging the
> > visual indentation of the source code
>
> That is somewhat misleading. We already have that ability. What is
> being proposed is moving existi
> The motivation
> is to be able to write multilined strings easily without damaging the
> visual indentation of the source code
That is somewhat misleading. We already have that ability. What is
being proposed is moving existing code to a different namespace. So the
motivation is really someth
Following Avi's suggestion, can I raise this thread up again? I think
that Reinhold's .dedent() method can be a good idea after all.
The idea is to add a method called "dedent" to strings. It would do
exactly what the current textwrap.indent function does. The motivation
is to be able to write mul
Okay. I consider it rejected.
Reinhold
Guido van Rossum wrote:
>>From the sound of it, it's probably not worth endowing every string
> object with this method and hardcoding its implementation forever in C
> code. There are so many corner cases and variations on the
> functionality of "dedenting"
> some time ago, I proposed a string method "dedent" (which currently is
in
> the
> textwrap module). The RFE is at http://python.org/sf/1237680.
>
> Any opinions? If I don't get positive comments, I'll reject it.
-1
Let it continue to live in textwrap where the existing pure python code
adequat
>From the sound of it, it's probably not worth endowing every string
object with this method and hardcoding its implementation forever in C
code. There are so many corner cases and variations on the
functionality of "dedenting" a block that it's better to keep it as
Python source code.
On 9/14/05,
Hi,
some time ago, I proposed a string method "dedent" (which currently is in the
textwrap module). The RFE is at http://python.org/sf/1237680.
Any opinions? If I don't get positive comments, I'll reject it.
Reinhold
--
Mail address is perfectly valid!
27 matches
Mail list logo
