[Neal Becker]
> >>I don't know to what extent these kind of optimizations are
available to
> >>cpython. For example, are constant calculations removed from loops?
[Brett Cannon]
> > If you mean ``2+3``, then yes.
[Greg Ewing]
> Actually, no. Constant folding *could* be done, but it currently
i
Brett Cannon wrote:
>>I don't know to what extent these kind of optimizations are available to
>>cpython. For example, are constant calculations removed from loops?
>
> If you mean ``2+3``, then yes.
Actually, no. Constant folding *could* be done, but it currently isn't:
>>> def f():
... re
Trent Mick wrote:
> If this *does* get added (I'm +0) then let's call it "relpath" or
> "relpathto" as in the various implementations out there:
+1 on that, too. Preferably just "relpath".
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury,
On 9/15/05, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> So we'll be cutting the 2.4.2 release candidate on Wednesday the 21st
> (next week). Can people please make sure they are running the test
> suite fully for any checkins between now and then? Also, please
> consider the release24-maint branch
So we'll be cutting the 2.4.2 release candidate on Wednesday the 21st
(next week). Can people please make sure they are running the test
suite fully for any checkins between now and then? Also, please
consider the release24-maint branch closed from UTC/GMT on the
21st - this will remain clo
Hi Neal, Ray,
Neal wrote:
> The binary versions (.pyc and .pyo) are not compatible, their magic
> number is different. I don't know the details, but if you want to
> investigate yourself. Get a CVS version, cd python/dist/src ; cvs
> diff -r r23 -r r24 Python/import.c
>
> That shows the magic
At 05:44 PM 9/15/2005 -0400, Raymond Hettinger wrote:
>[Neal Norwitz]
> > That shows the magic number changing. You will need to read CVS logs
> > to figure out why. It's possible the numbers don't really *need* to
> > change.
>
>The new LIST_APPEND opcode won't run on Py2.3.
The OP asked about
[Neal Norwitz]
> That shows the magic number changing. You will need to read CVS logs
> to figure out why. It's possible the numbers don't really *need* to
> change.
The new LIST_APPEND opcode won't run on Py2.3.
Raymond
___
Python-Dev mailing li
(oops. trying again)
Rich Burridge wrote:
> I'm involved with the team that's working towards installing Python 2.4.x
> as part of a future release of the Solaris O/S.
>
> We currently have Python 2.3.x installed. We are trying to determine just
> how compatible these two release are (at both the
On 9/15/05, Rich Burridge <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'm involved with the team that's working towards installing Python 2.4.x
> as part of a future release of the Solaris O/S.
Cool. I would like to hear more about what you are doing.
> We currently have Python 2.3.x installed. We
Rich Burridge wrote:
> I'm involved with the team that's working towards installing Python 2.4.x
> as part of a future release of the Solaris O/S.
>
> We currently have Python 2.3.x installed. We are trying to determine just
> how compatible these two release are (at both the binary and source lev
Hi,
I'm involved with the team that's working towards installing Python 2.4.x
as part of a future release of the Solaris O/S.
We currently have Python 2.3.x installed. We are trying to determine just
how compatible these two release are (at both the binary and source levels).
In other words, wi
On 9/15/05, Neal Becker <[EMAIL PROTECTED]> wrote:
> I use cpython. I'm accustomed (from c++/gcc) to a style of coding that is
> highly readable, making the assumption that the compiler will do good
> things to optimize the code despite the style in which it's written. For
> example, I assume con
Hi Neal,
I don't believe that cpython currently does any of the optimizations you refer to below. That said, it is very reasonable to adopt "a style of coding that is highly readable, making the assumption that the compiler will do good things" when coding in Python. Python is one of the most h
Raymond requested, and Guido concurred, that the python-checkins mailing
list Reply-To header munging be turned off. I've now done this.
Previously, follow-ups to checkins would be addressed to python-dev.
Now, follow-ups will stay on the python-checkins list and will not
appear here, unless the
[Greg Ewing wrote]
> Nathan Bullock wrote:
> > I find that I quite often want a
> > function that will give me a relative path from path A
> > to path B. I have created such a function, but it
> > would be nice if it was in the standard library.
>
> +1 from me. It's a fairly common thing to want t
On Thu, Sep 15, 2005, Neal Becker wrote:
>
> I use cpython. I'm accustomed (from c++/gcc) to a style of coding
> that is highly readable, making the assumption that the compiler will
> do good things to optimize the code despite the style in which it's
> written. For example, I assume constants a
I use cpython. I'm accustomed (from c++/gcc) to a style of coding that is
highly readable, making the assumption that the compiler will do good
things to optimize the code despite the style in which it's written. For
example, I assume constants are removed from loops. In general, an entity
is de
Corrections:
Now, every thread keeps one n queue of objects to incref and second
queue to decref.
Both can be implemented as array, cause they will be freed at once.
Initially, every thread acquires GIL for "read".
Py_INCREF places a ref into a incref queue of a thread,
Py_DECREF places a ref in
Excuse my English.
I think I know how to remove GIL Obviously I am an idiot.
First about Py_INCREF and Py_DECREF.
We should not remove GIL at all. We should change it.
It must be "one writer-many reader" in a following semantic:
Lock has a "read-counter" and a "write-counter". Initially bo
Phillip J. Eby wrote:
> At 09:12 PM 9/14/2005 +0400, Sokolov Yura wrote:
>
>> We could cash looks by this way:
>> Store with a class its version. Every time after creation when we change
>> a class
>> (add,remove or chage class member, including __base__, __bases__ and
>> mro) ,
>> we increase th
Raymond Hettinger wrote:
> [Reinhold Birkenfeld]
>> This last patch includes a new exception, are you sure that this can
> be
>> safely backported?
>
> Not too worried about it. Better to have the exception reported than
> the silent failure that confused the heck out of everyone who tried to
> f
22 matches
Mail list logo
