"Martin v. Löwis" writes:
> Alexandre Vassalotti writes:
> > The change would extend the line breaking behavior to three other
> > ASCII characters:
> > NEL "Next Line" 85
> > VT "Vertical Tab" 0B
> > FF "Form Feed" 0C
> > Of course, it is not really necessary to change, but I think
What would that do?
On 5/29/07, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Neal Norwitz schrieb:
> > On 5/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >>
> >> Well, I would have complained about that too, except I was too busy
> >> when splitlines() was snuck into the language behind my bac
Guido van Rossum wrote:
> What would that do?
It would split on all separators in the tuple, so
x.split(("\r", "\n"))
would do the same thing that x.splitlines() does now.
--
Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D
___
Python-3000 maili
On Tue, 29 May 2007, [UTF-8] Ivan Krsti?^G wrote:
> Guido van Rossum wrote:
> > What would that do?
>
> It would split on all separators in the tuple, so
>
> x.split(("\r", "\n"))
>
> would do the same thing that x.splitlines() does now.
Hmm... would it? Or should two split points with nothin
Stephen J. Turnbull wrote:
> Ie, we proponents want to allow programs
> that look familiar to native speakers of various languages, but do not
> look familiar to monolingual speakers of American English.
That characterization is overly narrow. I speak and write at least three
languages including E
Ka-Ping Yee wrote:
> Hmm... would it? Or should two split points with nothing between
> them produce empty strings, i.e. you would have to do
> x.split(('\r\n', '\r', '\n'))
> to get the behaviour of x.splitlines()?
Right, Georg's example would be unintuitive given the current behavior
of str
Ka-Ping Yee schrieb:
> On Tue, 29 May 2007, [UTF-8] Ivan Krsti�^G wrote:
>> Guido van Rossum wrote:
>> > What would that do?
>>
>> It would split on all separators in the tuple, so
Exactly, just like .startswith() with a tuple tries all of the elements.
>> x.split(("\r", "\n"))
>>
>> would d
On 5/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > The change would extend the line breaking behavior to three other
> > ASCII characters:
> > NEL "Next Line" 85
> > VT "Vertical Tab" 0B
> > FF "Form Feed" 0C
>
> Of these, NEL is not an ASCII character, so Guido's "no change
> for A
On Tue, May 29, 2007, Ivan Krsti?? wrote:
>
> Perl bypasses the issue by having split
> (http://perldoc.perl.org/functions/split.html) take a regex; I've only
> rarely used this for complex matches, though.
Then perhaps we should just point people at re.split()...
--
Aahz ([EMAIL PROTECTED])
On Tue, May 29, 2007, Ivan Krsti?? wrote:
>
> I haven't had time to participate in this discussion though I've been
> following it; FWIW, I'm a loud -1 on Unicode identifiers by default for
> just about the exact reasons that Ping enumerated.
Considering that OLPC is given as an argument in favor
I just thought about something. Would making readline(s) not glob the
line breaking character be a too radical idea? I think that is what
most people are expecting from a readline function, anyway. I often
see things like [line.strip() for line in open(file).readlines()],
which is not so elegant IM
Martin v. Löwis wrote:
> For example, .splitlines considers carriage-return (CR)
> characters as well, and you don't seem to complain about
> that.
That doesn't bother me so much because \r as a line
boundary is a well-established convention on some
platforms. But I've *never* heard of FF or VT b
Guido van Rossum wrote:
> Well, I would have complained about that too, except I was too busy
> when splitlines() was snuck into the language behind my back. :-) I
> should add that it has never caused me grief even though it is
> flagrant disagreement with Python's general concept of line endings
Alexandre Vassalotti wrote:
> I often
> see things like [line.strip() for line in open(file).readlines()],
If readline() stripped newlines, there would be no way
to distinguish between an empty line and EOF.
--
Greg
___
Python-3000 mailing list
Python-3
Greg Ewing writes:
> That doesn't bother me so much because \r as a line boundary is a
> well-established convention on some platforms. But I've *never*
> heard of FF or VT being used as line delimiters.
The Unicode newline recommendation is all about making the use of
characters match their p
15 matches
Mail list logo
