[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
figure-out what caused the OP's problem.
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
figure-out
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 the version
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 both
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
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 are
[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 to do.
If
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
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
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,
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
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 are
(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
[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 list
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
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
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
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
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,
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():
... return 2+3
[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
isn't:
21 matches
Mail list logo
