Tony Nelson wrote:
> But is there really no way to say this fast in pure Python? The way a
> one-to-one byte mapping can be done with "".translate()?
Well, .translate isn't exactly pure Python. One-to-one between bytes
and Unicode code points simply can't work. Just try all alternatives
yoursel
Tony Nelson wrote:
>>For decoding it should be sufficient to use a unicode string of
>>length 256. u"\ufffd" could be used for "maps to undefined". Or the
>>string might be shorter and byte values greater than the length of
>>the string are treated as "maps to undefined" too.
>
>
> With Unicode u
[Recipient list not trimmed, as my replies must be vetted by a moderator,
which seems to delay them. :]
At 11:48 PM +0200 10/4/05, Walter Dörwald wrote:
>Am 04.10.2005 um 21:50 schrieb Martin v. Löwis:
>
>> Walter Dörwald wrote:
>>
>>> For charmap decoding we might be able to use an array (e.g. a
At 9:37 AM +0200 10/4/05, Walter Dörwald wrote:
>Am 04.10.2005 um 04:25 schrieb [EMAIL PROTECTED]:
>
>>As the OP suggests, decoding with a codec like mac-roman or iso8859-1 is
>>very slow compared to encoding or decoding with utf-8. Here I'm working
>>with 53k of data instead of 53 megs. (Note: thi
Marvin wrote:
> I built pythoncore and python. The resulting python.exe worked fine, but did
> indeed fail when I tried to dynamically load anything (Dialog said: the
> application terminated abnormally)
Not sure what you are trying to do here. In your case, dynamic loading
simply cannot work. Th
Walter Dörwald wrote:
>> This array would have to be sparse, of course.
>
>
> For encoding yes, for decoding no.
[...]
> For decoding it should be sufficient to use a unicode string of length
> 256. u"\ufffd" could be used for "maps to undefined". Or the string
> might be shorter and byte val
Earlier references:
http://mail.python.org/pipermail/python-dev/2004-July/046499.html
I want to be able to create a version of python24.lib that is a static library,
suitable for creating a python.exe or other .exe using python's api.
So I did as the earlier poster suggested, using 2.4.1 sources.
Am 04.10.2005 um 21:50 schrieb Martin v. Löwis:
> Walter Dörwald wrote:
>
>> For charmap decoding we might be able to use an array (e.g. a
>> tuple (or an array.array?) of codepoints instead of dictionary.
>>
>
> This array would have to be sparse, of course.
For encoding yes, for decoding no.
Walter Dörwald wrote:
> Am 04.10.2005 um 04:25 schrieb [EMAIL PROTECTED]:
>
>
>>As the OP suggests, decoding with a codec like mac-roman or
>>iso8859-1 is very
>>slow compared to encoding or decoding with utf-8. Here I'm working
>>with 53k of
>>data instead of 53 megs. (Note: this is a lapt
Walter Dörwald wrote:
> For charmap decoding we might be able to use an array (e.g. a tuple
> (or an array.array?) of codepoints instead of dictionary.
This array would have to be sparse, of course. Using an array.array
would be more efficient, I guess - but we would need a C API for arrays
(to
On 10/4/05, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> Right after I sent the preceding message I got a funny feeling I'm
> wasting everybody's time here. I apologize. Guido's original concern
> about speedy C implementation for locks stands. I don't see a good
> way around it.
OK. Our messag
On 10/4/05, Jason Orendorff <[EMAIL PROTECTED]> wrote:
> This:
>
> with EXPR as VAR:
> BLOCK
>
> expands to this under PEP 342:
>
> _cm = contextmanager(EXPR)
> VAR = _cm.next()
> try:
> BLOCK
> except:
> try:
> _cm.throw(*sys.exc_info())
>
Right after I sent the preceding message I got a funny feeling I'm
wasting everybody's time here. I apologize. Guido's original concern
about speedy C implementation for locks stands. I don't see a good
way around it.
By the way, my expansion of 'with' using coroutines (in previous
message) was
The argument I am going to try to make is that Python coroutines need
a more usable API.
> Try to explain the semantics of the with statement without referring to the
> __enter__ and __exit__ methods, and then see if you still think they're
> superfluous ;)
>
> The @contextmanager generator decora
On 10/4/05, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> I was planning on looking at your patch too, but I was waiting for an answer
> from Guido about the fate of the ast-branch for Python 2.5. Given that we have
> patches for PEP 342 and PEP 343 against the trunk, but ast-branch still isn't
> even
Jason Orendorff wrote:
> Phillip J. Eby writes:
>
>>You didn't offer any reasons why this would be useful and/or good.
>
>
> It makes it dramatically easier to write Python classes that correctly
> support 'with'. I don't see any simple way to do this under PEP 343;
> the only sane thing to do
Michael Hudson wrote:
> I think 'as big as new-style classes' is probably an exaggeration, but
> I'm glad my troll caught a few people :)
I was planning on looking at your patch too, but I was waiting for an answer
from Guido about the fate of the ast-branch for Python 2.5. Given that we have
pa
"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
> At 07:02 PM 10/3/2005 +0100, Michael Hudson wrote:
>>"Phillip J. Eby" <[EMAIL PROTECTED]> writes:
>>
>> > Since the PEP is accepted and has patches for both its implementation
>> and a
>> > good part of its documentation, a major change like this wou
James Y Knight wrote:
> Your point would be much easier to stomach if the "str" type could
> *only* hold 7-bit ASCII.
why? strings are not mutable, so it's not like an ASCII string will suddenly
sprout
non-ASCII characters. what ends up in a string is defined by the string
source. if
you can
Am 04.10.2005 um 04:25 schrieb [EMAIL PROTECTED]:
> As the OP suggests, decoding with a codec like mac-roman or
> iso8859-1 is very
> slow compared to encoding or decoding with utf-8. Here I'm working
> with 53k of
> data instead of 53 megs. (Note: this is a laptop, so it's possible
> that
20 matches
Mail list logo
