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
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 cannot
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 would certainly
need
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
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 is write
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
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 decorator
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)
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())
except:
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 messages
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
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 laptop, so it's
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.
Using
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
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 values greater
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. The
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: this is a
[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
tuple
18 matches
Mail list logo
