Guido van Rossum <[EMAIL PROTECTED]> writes:
> 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: wi
Michael Sparks <[EMAIL PROTECTED]> wrote:
>
> 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
> > requiremen
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 involv
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
> > > sui
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:
[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
>
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 easi
> 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, m
Jeremy Hylton <[EMAIL PROTECTED]> writes:
> On 10/6/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> The only alternative to abandoning it that I see is to merge it back
>> into main NOW, using the time that remains us until the 2.5 release to
>> make it robust. That way, everybody can help out
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
> Date: Wed, 05 Oct 2005 00:21:20 +0200
> From: "Martin v. L?wis" <[EMAIL PROTECTED]>
> Subject: Re: [Python-Dev] Static builds on Windows (continued)
> Cc: python-dev@python.org
> Message-ID: <[EMAIL PROTECTED]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> Marvin wrote:
>
>>
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 re
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 pre
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
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
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 abou
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 don
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
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 abou
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 continua
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
"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 conf
At 8:36 AM +0200 10/5/05, Martin v. Löwis wrote:
>Tony Nelson wrote:
...
>> Encoding can be made fast using a simple hash table with external chaining.
>> There are max 256 codepoints to encode, and they will normally be well
>> distributed in their lower 8 bits. Hash on the low 8 bits (just mask
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
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 gr
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)
> >
> > %
[Brett]
> To answer Nick's email here, I didn't respond to that initial email
> because it seemed specifically directed at Guido and not me.
Fair enough. I think I was actually misrembering the sequence of events
leading up to 2.4a1, so the question was less appropriate for Guido than I
thought
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='
Walter Dörwald wrote:
> 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
>>>
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, whethe
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
>> r
> "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!
Speaking-as-
Martin v. Löwis wrote:
> Walter Dörwald wrote:
>
>> OK, here's a patch that implements this enhancement to
>> PyUnicode_DecodeCharmap(): http://www.python.org/sf/1313939
>
> Looks nice!
>
>> Creating the decoding_map as a string should probably be done by
>> gencodec.py directly. This way the
Neal Norwitz wrote:
> My thoughts are to dynamically allocate the Python stack memory (e.g.,
> void *stack = malloc(128MB)). Then all calls within each thread uses
> its own stack. So things would be pushed onto the stack like they are
> currently, but we wouldn't need to do create a tuple to pas
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 th
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
36 matches
Mail list logo
