On 8/30/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
On Wed, Aug 30, 2006 at 08:56:03PM -0700, Bob Ippolito wrote:> > and also based on the cET (and NFS) experiences, it wouldn't surprise me> > if a naive 32-bit text string implementation will, on average, slow things down
> > *more* than any stri
Jack Diederich wrote:
> That said can you guys expand on what polymorphic[1] means here in particular?
> Python wise I can only think of the str/unicode/buffer split. If the
> fraternity of strings doesn't include views (which I haven't needed either)
> what are you considering for the other kin
On 8/30/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Aug 30, 2006, at 5:57 PM, Guido van Rossum wrote:
> > Perhaps a compromise could be to add a keyword parameter to request
> > such an exception? (We could even add three options: truncate, pad,
> > error, with truncate being the default, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 31, 2006, at 11:38 AM, Jim Jewett wrote:
> On 8/30/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
>> What about a keyword argument called 'filler' which can be an n-sized
>> sequence or a callable.
>
> How about a keyword-only argument called fi
>How about a keyword-only argument called finish which is a callable to
>deal with the problem? When any sequence is exhausted, its position
>is filled with StopIteration, and then finish(result) is returned.
>
>
>
How about we resist the urge to complicate the snot out of a basic
looping con
On 8/31/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>
> >How about a keyword-only argument called finish which is a callable to
> >deal with the problem? When any sequence is exhausted, its position
> >is filled with StopIteration, and then finish(result) is returned.
>
> How about we resist
Raymond Hettinger wrote:
>>How about a keyword-only argument called finish which is a callable to
>>deal with the problem? When any sequence is exhausted, its position
>>is filled with StopIteration, and then finish(result) is returned.
>>
>>
>>
>
> How about we resist the urge to complicate th
I thought I felt in the mood for some abuse today, so I'm proposing
something sure to give me plenty of crap, but maybe someone will enjoy
the idea, anyway. This is a step beyond the recently added conditional
expressions. I actually made this up as a joke, explaining at which
point we would have g
On 8/31/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
I thought I felt in the mood for some abuse today, so I'm proposingsomething sure to give me plenty of crap, but maybe someone will enjoythe idea, anyway.Never hurts too much to try, huh? =) Plus it gives me a break from my work.
This is a s
> expr1 except expr2 if exc_type
...
> print letters[7] except "N/A" if IndexError
I sort of like it, though I'm more worried than you about ugly code.
There have been many times when I wanted it so that I could use a list
comprehension (or generator comprehension) instead of a function o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 31, 2006, at 12:12 PM, Raymond Hettinger wrote:
> It is important that zip() be left as dirt simple as possible. In
> the tutorial (section 5.6), we're able to use short, simple
> examples to teach all of the fundamental looping techniques
Jack Diederich wrote:
>>> (in other words, I'm convinced that we need a polymorphic string type. I'm
>>> not
>>> so sure we need views, but if we have the former, we can use that mechanism
>>> to
>>> support the latter)
>> +1 for polymorphic strings.
>>
>> This would give us the best of both wor
On 8/31/06, Talin <[EMAIL PROTECTED]> wrote:
> One way to handle this efficiently would be to only support the
> encodings which have a constant character size: ASCII, Latin-1, UCS-2
> and UTF-32. In other words, if the content of your text is plain ASCII,
> use an 8-bit-per-character string; If th
"Bob Ippolito" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> +1 for polymorphic strings.
A strong +1 here also.
>
> This would give us the best of both worlds: compact representations
> for ASCII and Latin-1, full 32 bit text when needed, and the
> possibility to implement furthe
>The bad news is that I seem to be an anti-channeller, so my interest
>is perhaps not a *good* sign.
>
>
>
QOTW
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org
i haven't been online for the last couple of days, so i'll unify
my replies into one post.
[Talin]
> Right now, a typical
> file handle consists of 3 "layers" - one representing the backing store
> (file, memory, network, etc.), one for adding buffering, and one
> representing the program-level AP
On 8/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> So this feels like the Perl idiom of using die: ``open(file) or die`` (or
> something like that; I have never been a Perl guy so I could be off).
>
> > ...
>
> The problem I have with this whole proposal is that catching exceptions
> should be v
(Adding back py3k list assuming you just forgot it)
On 8/31/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 8/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > > (The difference between UCS-2 and UTF-16 is that UCS-2 is always 2 bytes
> > > per character, and doesn't support the supplement
On 8/31/06, Calvin Spealman <[EMAIL PROTECTED]> wrote:
On 8/31/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> So this feels like the Perl idiom of using die: ``open(file) or die`` (or> something like that; I have never been a Perl guy so I could be off).
>> > ...>> The problem I have with this whole
tomer filiba wrote:
> [...]
> besides, encoding suffers from many issues. suppose you have a
> damaged UTF8 file, which you read char-by-char. when we reach the
> damaged part, you'll never be able to "skip" it, as we'll just keep
> read()ing bytes, hoping to make a character out of it , until we
Calvin Spealman wrote:
> Other example use cases:
>
> # Fallback on an alternative path
>
> # Handle divide-by-zero
or get by with index() instead of find():
s.index("foo") except -1 if IndexError # :-)
> open(filename) except open(filename2) if IOError
One problem is that i
tomer filiba wrote:
> [Talin]
>
>>Well, as far as readline goes: In order to split the text into lines,
>>you have to decode the text first anyway, which is a layer 3 operation.
>>You can't just read bytes until you get a \n, because the file you are
>>reading might be encoded in UCS2 or something
Guido van Rossum wrote:
> On 8/31/06, Talin <[EMAIL PROTECTED]> wrote:
>> One way to handle this efficiently would be to only support the
>> encodings which have a constant character size: ASCII, Latin-1, UCS-2
>> and UTF-32. In other words, if the content of your text is plain ASCII,
>> use an 8-b
On 8/31/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> One problem is that it doesn't seem to chain
> all that well. Suppose you had three files to
> try opening:
>
>open(name1) except (open(name2) except open(name3) if IOError) if IOError
>
> Maybe it would be better if the exception type
> and a
On 8/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
(Adding back py3k list assuming you just forgot it)Yes, thanks. Gmail's UI really optimizes the "Reply To" operation of "Reply To All."
> Plus, it sounds like you're proposing that the encodings of the underlying> data would leak through to
On 8/31/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 8/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > (Adding back py3k list assuming you just forgot it)
>
> Yes, thanks. Gmail's UI really optimizes the "Reply To" operation of "Reply
> To All."
>
> > > Plus, it sounds like you're propos
On 8/31/06, Talin <[EMAIL PROTECTED]> wrote:
> > Here you are effectively voting against polymorphic strings. I believe
> > Fredrik has good reasons to doubt this assertion.
>
> Yes, that is correct. I'm just throwing it out there as a possibility,
> as it is by far the simplest solution. Its a que
On 8/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
On 8/31/06, Paul Prescod <[EMAIL PROTECTED]> wrote:> On 8/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> > (Adding back py3k list assuming you just forgot it)
>> Yes, thanks. Gmail's UI really optimizes the "Reply To" operation of "Reply>
Talin wrote:
> So essentially what I am proposing is this:
"look at me! look at me!"
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3
Guido van Rossum wrote:
> BTW, in some sense Python 2.x *has* polymorphic strings -- str and
> unicde have the same API (99% anyway) but different implementations,
> and there's even a common abstract base class (basestring). But this
> clearly isn't what the ObjectiveC folks want to see!
on the
tjreedy wrote:
> These two similar features would be enough, to me, to make Py3 more than
> just 2.x with cruft removed.
well, it's really only C API issues that keeps us from implementing this
in 2.x... (too much code uses PyString_Check and/or PyUnicode_Check and
then happily digs into the a
Guido van Rossum wrote:
> A way to handle UTF-8 strings and other variable-length encodings
> would be to maintain a small cache of index positions with the string
> object.
I think just delaying decoding would take us most of the way. the big
advantage of storage polymorphism is that you can a
Guido van Rossum wrote:
> I think it would be best to do this as a CPython configuration option
> just like it's done today. You can choose 4-byte or 2-byte Unicode
> (essentially UCS-4 or UTF-16) in order to be compatible with other
> packages on the platform. Yes, 4-byte gives better Unicode sup
33 matches
Mail list logo
