Re: [Python-Dev] [Python-checkins] (2.7): Use simpler assert in basic example.

On 11/03/2011 4.45, Nick Coghlan wrote: On Thu, Mar 10, 2011 at 4:36 PM, ezio.melotti wrote: http://hg.python.org/cpython/rev/9adc4792db9a changeset: 68356:9adc4792db9a branch: 2.7 user:Ezio Melotti date:Thu Mar 10 23:35:39 2011 +0200 summary: Use simpler assert in bas

Re: [Python-Dev] [Python-checkins] (2.6): Issue #11424: Fix bug in determining child loggers.

On Thu, Mar 10, 2011 at 18:47, Nick Coghlan wrote: > On Thu, Mar 10, 2011 at 5:41 PM, Vinay Sajip > wrote: > > - Original Message > > > >> From: Éric Araujo > >> > From what I understand, we're supposed to forward-port in Mercurial, > >> Correct, but only in maintained branches, not s

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2011-03-04 - 2011-03-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open2709 (+18) closed 20540 (+53) total 23249 (+71) Open issues wit

[Python-Dev] Callable, non-descriptor class attributes.

One of the things brought up at the language summit (and I believe at the VM summit, although I wasn't there) was the unpredictable behaviour of callables turning into methods when they're class attributes. Specifically, things that are CFunctions in CPython (builtin functions, which are not descri

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On Wed, 09 Mar 2011 07:15:07 +0100 Stefan Behnel wrote: > > Actually, why not put up a web page of "upcoming changes" somewhere, that > lists major decisions with user impact that were taken on python-dev? > Including a link to the relevant discussion and decision. Often enough, > decisions ar

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/11/2011 03:24 PM, Antoine Pitrou wrote: > On Wed, 09 Mar 2011 07:15:07 +0100 > Stefan Behnel wrote: >> >> Actually, why not put up a web page of "upcoming changes" somewhere, that >> lists major decisions with user impact that were taken on pyt

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann wrote: > > On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: > >> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel wrote: >>> Actually, why not put up a web page of "upcoming changes" somewhere, that >>> lists major decisions with user impact that were taken o

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On Fri, 11 Mar 2011 15:53:03 -0500 Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 03/11/2011 03:24 PM, Antoine Pitrou wrote: > > On Wed, 09 Mar 2011 07:15:07 +0100 > > Stefan Behnel wrote: > >> > >> Actually, why not put up a web page of "upcoming changes" somewhere,

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On Wed, 9 Mar 2011 15:40:56 -0500 Doug Hellmann wrote: > > The original request from the board was for the communications team to write > the messages, but I think it is more appropriate for the people doing the > work to talk about it. [...] > > I asked Michael to add this topic to the agenda

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On Mar 11, 2011 4:52 PM, "Guido van Rossum" wrote: > > On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann wrote: > > > > On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: > > > >> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel wrote: > >>> Actually, why not put up a web page of "upcoming changes" somewhere,

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On Fri, 11 Mar 2011 22:56:49 +0100 Antoine Pitrou wrote: > On Fri, 11 Mar 2011 15:53:03 -0500 > Tres Seaver wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA1 > > > > On 03/11/2011 03:24 PM, Antoine Pitrou wrote: > > > On Wed, 09 Mar 2011 07:15:07 +0100 > > > Stefan Behnel wrote: > >

Re: [Python-Dev] [Python-checkins] devguide: Suggest using mpatch in the FAQ

On 03/11/2011 06:03 PM, antoine.pitrou wrote: If you want to try out or review a patch generated using Mercurial, do:: - hg import --no-commit somework.patch + patch -p1< somework.patch This will apply the changes in your working copy without committing them. If the patch was not cre

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On Fri, Mar 11, 2011 at 5:05 PM, Brian Curtin wrote: > > On Mar 11, 2011 4:52 PM, "Guido van Rossum" wrote: >> >> On Wed, Mar 9, 2011 at 3:40 PM, Doug Hellmann >> wrote: >> > >> > On Mar 9, 2011, at 9:50 AM, Tim Lesher wrote: >> > >> >> On Wed, Mar 9, 2011 at 01:15, Stefan Behnel >> >> wrote: >

Re: [Python-Dev] Callable, non-descriptor class attributes.

Thomas Wouters wrote: 2. Make CFunctions turn into methods in CPython (after a period of warning about the impending change, obviously.) The actual *usecase* for this is hard to envision While not necessary for the case being discussed here, this would be a big help for Pyrex and Cython, whe

Re: [Python-Dev] Callable, non-descriptor class attributes.

On Fri, Mar 11, 2011 at 6:49 PM, Greg Ewing wrote: > Thomas Wouters wrote: > >>  2. Make CFunctions turn into methods in CPython (after a period of >> warning about the impending change, obviously.) The actual *usecase* for >> this is hard to envision > > While not necessary for the case being dis

Re: [Python-Dev] public visibility of python-dev decisions "before it's too late" (was: PyCObject_AsVoidPtr removed from python 3.2 - is this documented?)

On 11 March 2011 23:24, Guido van Rossum wrote: >> I'm interested in the task and I guess I'll follow-up with Doug Hellman. I >> don't follow -ideas close enough to summarize it, but I'd contribute to a >> -dev blog. > > Awesome! (And we don't need to stop at one blogger. Many hands make light >

[Python-Dev] The purpose of SETUP_LOOP, BREAK_LOOP, CONTINUE_LOOP

Hello, What is the purpose of SETUP_LOOP instruction? From a quick look it seems like it just pushes the size of the loop into blocks stack; that size is only used by BREAK_LOOP instruction. BREAK_LOOP could just contain the target address directly, like CONTINUE_LOOP does. This would avoid SETUP_

[Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

Today, there was a significant check-in to the peephole optimizer that I think should be reverted: http://hg.python.org/cpython/rev/14205d0fee45/ The peephole optimizer pre-dated the introduction of the abstract syntax tree. Now that we have an AST, the preferred way to implement

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

On Fri, Mar 11, 2011 at 9:28 PM, Raymond Hettinger wrote: > Today, there was a significant check-in to the peephole optimizer that I > think should be reverted: >                http://hg.python.org/cpython/rev/14205d0fee45/ +1 I was going to comment on the corresponding issue #11244 more or les

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

2011/3/11 Raymond Hettinger : > Today, there was a significant check-in to the peephole optimizer that I > think should be reverted: >                http://hg.python.org/cpython/rev/14205d0fee45/ > The peephole optimizer pre-dated the introduction of the abstract syntax > tree.  Now that we have a

Re: [Python-Dev] Callable, non-descriptor class attributes.

Thomas Wouters wrote: One of the things brought up at the language summit (and I believe at the VM summit, although I wasn't there) was the unpredictable behaviour of callables turning into methods when they're class attributes. [...] 1. Make staticmethod a callable object directly (it isn't,

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

I recall several occasions where the peephole optimizer was subtly buggy -- on one occasion the bug remained undetected for at least a whole release cycle. (Sorry, I can't recall the details.) In fact, the bug reported in http://bugs.python.org/issue11244 is another example of how subtle the peepho

Re: [Python-Dev] Callable, non-descriptor class attributes.

On Fri, Mar 11, 2011 at 10:09 PM, Steven D'Aprano wrote: > Thomas Wouters wrote: >> >> One of the things brought up at the language summit (and I believe at the >> VM >> summit, although I wasn't there) was the unpredictable behaviour of >> callables turning into methods when they're class attribu

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

Experience shows that optimizations are always error prone, no matter what framework or internal representation you use. I don't think we should assume that simply rewriting all optimizations to work on AST will make them bug free once and for all. On the contrary, I think such a rewrite will intro

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

On Mar 11, 2011, at 11:11 PM, Eugene Toder wrote: > Experience shows that optimizations are always error prone, no matter > what framework or internal representation you use. On that basis, I believe that we ought to declare peephole.c as being somewhat off-limits for further development (except

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

>> Experience shows that optimizations are always error prone, no matter >> what framework or internal representation you use. > > On that basis, I believe that we ought to declare peephole.c as being > somewhat off-limits for further development (except for small > adaptations if the underlying op

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

2011/3/12 Benjamin Peterson > 2011/3/11 Raymond Hettinger : > > Today, there was a significant check-in to the peephole optimizer that I > > think should be reverted: > >http://hg.python.org/cpython/rev/14205d0fee45/ > > The peephole optimizer pre-dated the introduction of the abs

Re: [Python-Dev] Callable, non-descriptor class attributes.

On Fri, Mar 11, 2011 at 10:48 PM, Guido van Rossum wrote: >> +1 on making staticmethods callable. I would have found that useful in the >> past. > > IIUC Thomas found that this breaks some current use of staticmethod. >From his first post, I understood the compatibility issue to more be the fact

Re: [Python-Dev] Callable, non-descriptor class attributes.

Guido van Rossum wrote: +1 on making staticmethods callable. I would have found that useful in the past. IIUC Thomas found that this breaks some current use of staticmethod. As I understand it, Thomas found that having staticmethod callable AND have staticmethod.__get__ return self breaks

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

> One note on the patch: it allocates an extra stack which is dynamically grown; > but there is no unittest to exercise the stack-growing code. Isn't this doing it? 1.20 +# Long tuples should be folded too. 1.21 +asm = dis_single(repr(tuple(range(1 1.22 +# One LOAD

Re: [Python-Dev] Suggest reverting today's checkin (recursive constant folding in the peephole optimizer)

Cesare Di Mauro wrote: Also, optimizations can be done not only for numbers, but even for tuples, lists, dictionaries, and... slices (pag. 22). See pages 21-24 of this For the record, constant-folding

[Python-Dev] forward-porting from 3.1 to 3.2 to 3.3

The devguide's recommendation is to "forward-port" changes withing a major release line, i.e. if I need something in all 3.[123], then start with 3.1 and forward-port (by "hg merge ") to 3.2 and then 3.3 Just to clarify - does this mean that all changesets that are applied to 3.2 eventually get to