> Heh, just today I was wondering if we should kill splitlines:
>
> $ grep splitlines `find Lib -name '*.py'` | egrep -v
> '(difflib|/test/|UserString)' | wc
> 24 1111653
> $ egrep 'split[^l]' `find Lib -name '*.py'` | egrep -v
> '(difflib|/test/|UserString)' | wc
>9164943 63
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 back. :-) I
>
> Heh, just today I was wondering if we should kill splitlines:
And pe
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 back. :-) I
Heh, just today I was wondering if we should kill splitlines:
$ grep splitlines `find Lib -name '*.
On 5/29/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> VT "Vertical Tab" 0B
> >> FF "Form Feed" 0C
> >
> > -1 on making these line-breaking characters by default.
> > I like my ASCII text file lines broken by newline chars
> > and nothing else.
>
> The question, of course, is what a newl
>> VT "Vertical Tab" 0B
>> FF "Form Feed" 0C
>
> -1 on making these line-breaking characters by default.
> I like my ASCII text file lines broken by newline chars
> and nothing else.
The question, of course, is what a newline char is; this
whole mess originates from disagreement about this is
> 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 ASCII-only text" requirement doesn't apply to text containing
NEL.
> Of
Ka-Ping Yee writes:
> Would the display of source code be affected this way as well?
Of course! That's what PEP 3131 proponents *want*. From the draft
you cite: "certain phenomena in this relationship may look strange to
somebody not familiar with bidirectional behavior, but familiar to
users
On Mon, 28 May 2007, Stephen J. Turnbull wrote:
> Now, identifiers are by definition character streams. If an English
> speaker would pronounce the spelling of an English word "A B C", and
> an Arabic speaker an Arabic word as "1 2 3", then *as an identifier*
> the combination English then Arabic
Greg Ewing writes:
> Stephen J. Turnbull wrote:
> > If an English speaker would pronounce the spelling of an English
> > word "A B C", and an Arabic speaker an Arabic word as "1 2 3",
> > then *as an identifier* the combination English then Arabic is
> > spelled "A B C _ 1 2 3".
> But woul
Hi Tim,
I've gone ahead and cooked up a tiny demo patch that uses im_class to
store what you called im_type. Because I don't have the parser changes
ready yet, this requires you to declare a keyword-only arg named
'super'; this triggers special code that set it to super(im_class,
im_self).
http:/
Alexandre Vassalotti wrote:
> The change would extend the line breaking behavior to three other
> ASCII characters:
> NEL "Next Line" 85
That's not an ASCII character.
> VT "Vertical Tab" 0B
> FF "Form Feed" 0C
-1 on making these line-breaking characters by default.
I like my ASCII text f
Stephen J. Turnbull wrote:
> If an English
> speaker would pronounce the spelling of an English word "A B C", and
> an Arabic speaker an Arabic word as "1 2 3", then *as an identifier*
> the combination English then Arabic is spelled "A B C _ 1 2 3".
But would an Arabic speaker pronounce the ident
On 5/28/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Can you or someone supply a patch? Put it in the SourceForge patch
> manager and post here.
I can't promise anything, since I am quite busy my SoC project, but I
could try to supply a patch, if you and the other developers are in
favor for
Can you or someone supply a patch? Put it in the SourceForge patch
manager and post here.
OTOH I don't believe that's how 2.x implements these methods, and
AFAIK nobody's complained. Is in necessary to change? At the very
least I'd be opposed if it changed the behavior of splitting
ASCII-only text
On 5/11/07, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> > Would it be useful if I created an experimental fork of 2.5
> > that replaces array-based lists with BLists,
> > so that the performance penalty (if any) on existing code
> > can be measured?
>
> That would likely be an informative exerc
Hi,
Just wandering. It would be a good idea to make the string methods
split() and splitlines() break lines as specified by the Unicode
Standard (Section 5.8 Newline Guidelines)?
If you don't have a printed copy, you can read the section here:
http://www.unicode.org/versions/Unicode4.0.0/ch05.pdf
16 matches
Mail list logo
