Hi,
I just set up a LXR instance for Python CVS for my personal use:
http://pxr.openlook.org/pxr/
If you find it useful, feel free to use the site. :) The source files will
be updated twice a day.
Hye-Shik
___
Python-Dev mailing list
Python-Dev@pytho
...
> -
> Speeding up list append calls
> -
>
> A `comp.lang.python message from Tim Peters`_ prompted Neal Norwitz
> to investigate how the code that Tim posted could be sped up. He
> hacked the code to replace var.append() with the LIST_APP
On 10/21/05, Tony Meyer <[EMAIL PROTECTED]> wrote:
> This is over a month late, sorry, but here it is (Steve did his
> threads ages ago; I've fallen really behind).
Better late than never! These summaries are awesome.
Just one nit:
> --
> Responsiveness of IDLE dev
This is over a month late, sorry, but here it is (Steve did his
threads ages ago; I've fallen really behind). Summaries for the
second half of September and the first half of October will soon
follow. As always, if anyone is able to give this a quick look that
would be great. Feedback to
On 10/21/05, Jim Jewett <[EMAIL PROTECTED]> wrote:
> (In http://mail.python.org/pipermail/python-dev/2005-October/057501.html)
> Neil Schemenauer suggested PEP 267 as an example of something that
> might be easier with the AST compiler.
>
> As written, PEP 267 does propose a slight semantics change
(In http://mail.python.org/pipermail/python-dev/2005-October/057501.html)
Neil Schemenauer suggested PEP 267 as an example of something that
might be easier with the AST compiler.
As written, PEP 267 does propose a slight semantics change -- but it
might be an improvement, if it is acceptable.
To
I've checked in a whole bunch of newly generated codecs
which now make use of the faster charmap decoding variant added
by Walter a short while ago.
Please let me know if you find any problems.
Some codecs (esp. the Mac OS X ones) have minor changes.
These originate from updated mapping files on
Neal Norwitz wrote:
> Jeremy,
>
> There are a bunch of mods from the AST branch that got integrated into
> head. Hopefully, by doing this on python-dev more people will get
> involved. I'll describe high level things first, but there will be a
> ton of details later on. If people don't want to
Jeremy Hylton wrote:
> I would like to keep them separate. The compiler produces code
> objects, but consumers of code objects don't need to know anything
> about the compiler.
Please do keep these separate - the only reason I've ever had to muck with
code objects is to check if a function is a
On 10/21/05, Neil Schemenauer <[EMAIL PROTECTED]> wrote:
> Also, the concrete syntax tree (CST) generated by Python's parser is
> not a convenient data structure to deal with. Anyone who's used the
> 'parser' module probably experienced the pain:
>
> >>> parser.ast2list(parser.suite('a = 1'))
>
Anthony Baxter <[EMAIL PROTECTED]> wrote:
> Could someone involved give a short email laying out what concrete (no
> pun intended) advantages this new compiler gives us?
One advantage is that it decreases the coupling between the parser
and the backend of the compiler. For example, it should be p
On 10/20/05, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 10/20/05, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> > So it looks like the AST branch has landed. Wooo! Well done to all who
> > were involved - it seems like it's been a huge amount of work.
>
> Hear, hear. Great news! Thanks to Jerem
On 10/20/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> On 10/20/05, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> >
> > Could someone involved give a short email laying out what concrete (no
> > pun intended) advantages this new compiler gives us? Does it just
> > allow us to do new and interesting m
At 11:13 AM 10/21/2005 -0400, Jeremy Hylton wrote:
>I don't have a strong sense for how important these changes are. I
>don't think the old behavior was documented, but I can imagine some
>code depending on these implementation details.
I'm pretty sure I've seen code in the field (e.g. recipes in
On 10/21/05, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> On 10/21/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> > This probably is not a big deal, but I was surprised by this change:
> >
> > +++ test_repr.py20 Oct 2005 19:59:24 - 1.20
> > @@ -123,7 +123,7 @@
> >
> > def test_lam
On 10/21/05, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> There are a bunch of mods from the AST branch that got integrated into
> head. Hopefully, by doing this on python-dev more people will get
> involved. I'll describe high level things first, but there will be a
> ton of details later on. If
Guido van Rossum wrote:
> If it weren't for Python's operator overloading, the decimal module
> would have used explicit contexts (like the Java version); but since
> it would be really strange to have such a fundamental numeric type
> without the ability to use the conventional operator notation,
Anthony Baxter wrote:
> So it looks like the AST branch has landed. Wooo! Well done to all who
> were involved - it seems like it's been a huge amount of work.
Congratulations from this quarter, too.
I really liked the structure of the new compiler in the limited time I spent
working with it on
Phillip J. Eby wrote:
> Actually, it's fairly simple to write a generator decorator using
> context.swap() that saves and restores the current execution state
> around next()/send()/throw() calls, if you prefer it to be the
> generator's responsibility to maintain such context.
Yeah, I also rea
Guido van Rossum <[EMAIL PROTECTED]> writes:
> On 10/20/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
>> At 08:57 AM 10/20/2005 -0700, Guido van Rossum wrote:
>> >Whoa, folks! Can I ask the gentlemen to curb their enthusiasm?
>> >
>> >PEP 343 is still (back) on the drawing table, PEP 342 has barel
20 matches
Mail list logo
