Hye-Shik Chang wrote:
If the encoding optimization can be easily done in Walter's approach,
the fastmap codec would be too expensive way for the objective because
we must maintain not only fastmap but also charmap for backward
compatibility.
IMO, whether a new function is added or whether the
At 10:09 PM 10/5/2005 -0700, Neal Norwitz wrote:
I've also been thinking about avoiding tuple creation when calling
python functions. The change I have in mind would probably have to
wait until p3k, but could yield some speed ups.
Warning: half baked idea follows.
Yeah, I've been baking that
M == M.-A. Lemburg [EMAIL PROTECTED] writes:
M From what I've read on the web about the Python Unicode
M implementation we have one of the better ones compared to other
M languages implementations and their choices and design
M decisions.
Yes, indeed!
Neal Norwitz [EMAIL PROTECTED] writes:
On 10/5/05, Phillip J. Eby [EMAIL PROTECTED] wrote:
At 09:50 AM 10/4/2005 +0100, Michael Hudson wrote:
(anyone still thinking about removing the block stack?).
I'm not any more. My thought was that it would be good for performance, by
reducing the
Martin v. Löwis wrote:
Hye-Shik Chang wrote:
If the encoding optimization can be easily done in Walter's approach,
the fastmap codec would be too expensive way for the objective because
we must maintain not only fastmap but also charmap for backward
compatibility.
IMO, whether a new
Hye-Shik Chang wrote:
On 10/6/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Hye-Shik, could you please provide some timeit figures for
the fastmap encoding ?
Thanks for the timings.
(before applying Walter's patch, charmap decoder)
% ./python Lib/timeit.py -s s='a'*53*1024; e='iso8859_10';
On 10/6/05, M.-A. Lemburg [EMAIL PROTECTED] wrote:
Hye-Shik Chang wrote:
(encoding, fastmap codec)
% ./python Lib/timeit.py -s s='a'*53*1024; e='iso8859_10_fc';
u=unicode(s, e) u.encode(e)
1000 loops, best of 3: 536 usec per loop
(encoding, utf-8 codec)
% ./python Lib/timeit.py
I posted this question to python-help, but I think I have a better chance
of getting the answer here.
I'm looking for clarification on when NEWLINE tokens are generated during
lexical analysis of Python source code. In particular, I'm confused about
some of the top-level components in Python's
M.-A. Lemburg wrote:
[...]
Or we could have a function that recreates the dictionary from the string.
Actually, I'd prefer that these operations be done by the
codec generator script, so that we don't have additional
startup time. The dictionaries should then no longer be
generated and
Matthew F. Barnes [EMAIL PROTECTED] writes:
I posted this question to python-help, but I think I have a better chance
of getting the answer here.
I'm looking for clarification on when NEWLINE tokens are generated during
lexical analysis of Python source code. In particular, I'm confused
Just a quick note. Nick convinced me that adding __with__ (without
losing __enter__ and __exit__!) is a good thing, especially for the
decimal context manager. He's got a complete proposal for PEP changes
which he'll post here. After a brief feedback period I'll approve his
changes and he'll check
I think it is a relic from the distant past, when the lexer did
generate NEWLINE for every blank line. I think the only case where you
can still get a NEWLINE by itself is in interactive mode. This code is
extremely convoluted and may be buggy in end cases; this could explain
why you get a
At 07:36 AM 10/6/2005 -0500, Matthew F. Barnes wrote:
I posted this question to python-help, but I think I have a better chance
of getting the answer here.
I'm looking for clarification on when NEWLINE tokens are generated during
lexical analysis of Python source code.
If you're talking about
Nick Coghlan [EMAIL PROTECTED] wrote:
If we kill the branch for now, then anyone that wants to bring up the idea
again can write a PEP first
I still have some (very) small hope that it can be finished. If we
don't get it done soon then I fear that it will never happen. I had
hoped that a SoC
On 10/6/05, Neil Schemenauer [EMAIL PROTECTED] wrote:
Nick Coghlan [EMAIL PROTECTED] wrote:
If we kill the branch for now, then anyone that wants to bring up the idea
again can write a PEP first
I still have some (very) small hope that it can be finished. If we
don't get it done soon then
Jeremy Jones published a blog discussing some of the ideas we've
talked about here:
http://www.oreillynet.com/pub/wlg/8002
Although I hope our conversation isn't done, as he suggests!
At some point when more ideas have been thrown about (and TIJ4 is
done) I hope to summarize what we've talked
Just to add another 2 cents
http://www.erights.org/talks/promises/paper/tgc05.pdf
---
Paolo Invernizzi
Bruce Eckel wrote:
Jeremy Jones published a blog discussing some of the ideas we've
talked about here:
http://www.oreillynet.com/pub/wlg/8002
Although I hope our conversation isn't
On 10/6/05, Guido van Rossum [EMAIL PROTECTED] wrote:
On 10/6/05, Neil Schemenauer [EMAIL PROTECTED] wrote:
Nick Coghlan [EMAIL PROTECTED] wrote:
If we kill the branch for now, then anyone that wants to bring up the idea
again can write a PEP first
I still have some (very) small hope
Hi Bruce,
On Thursday 06 October 2005 18:12, Bruce Eckel wrote:
Although I hope our conversation isn't done, as he suggests!
...
At some point when more ideas have been thrown about (and TIJ4 is
done) I hope to summarize what we've talked about in an article.
I don't know if you saw my
This does look quite fascinating, and I know there's a lot of really
interesting work going on at the BBC now -- looks like some really
pioneering stuff going on with respect to TV show distribution over
the internet, new compression formats, etc.
So yes indeed, this is quite high on my list to
Michael Sparks [EMAIL PROTECTED] wrote:
What I'd be interested in, is hearing how our system doesn't match with
the goals of the hypothetical concurrency system you'd like to see (if it
doesn't). The main reason I'm interested in hearing this, is because the
goals you listed are ones we want
Unless I'm missing something, we would need to merge HEAD to the AST
branch once more to pick up the changes in MAIN since the last merge,
and then make sure everything in the AST branch is passing the test
suite. Otherwise we risk having MAIN broken for awhile following a
merge.
IMO,
On Thursday 06 October 2005 23:15, Josiah Carlson wrote:
[... 6 specific use cases ...]
If Kamaelia is able to handle all of the above mechanisms in both a
blocking and non-blocking fashion, then I would guess it has the basic
requirements for most concurrent applications.
It can. I can easily
[Kurt]
Unless I'm missing something, we would need to merge HEAD to the AST
branch once more to pick up the changes in MAIN since the last merge,
and then make sure everything in the AST branch is passing the test
suite. Otherwise we risk having MAIN broken for awhile following a
merge.
At 07:34 PM 10/6/2005 -0700, Guido van Rossum wrote:
How does this sound to the non-AST-branch developers who have to
suffer the inevitable post-merge instability? I think it's now or
never -- waiting longer isn't going to make this thing easier (not
with several more language changes approved:
On 10/6/05, Guido van Rossum [EMAIL PROTECTED] wrote:
[Kurt]
Unless I'm missing something, we would need to merge HEAD to the AST
branch once more to pick up the changes in MAIN since the last merge,
and then make sure everything in the AST branch is passing the test
suite. Otherwise
Guido van Rossum [EMAIL PROTECTED] writes:
I happen to agree with Kurt that we should first merge the head into
the branch; then the AST team can work on making sure the entire
test suite passes; then they can merge back into the head.
I can be available to do this again. It would involve
27 matches
Mail list logo
