Le jeudi 30 décembre 2010 à 17:05 +0100, Martin v. Löwis a écrit :
I really don't think it is our job to maintain a list of OS/versions
which work and don't work.
Of course not. I would propose a dynamic test: check how many POSIX
semaphores the installation supports, and fail if it's less
Le mercredi 29 décembre 2010 à 14:20 +0100, Martin v. Löwis a écrit :
Am 28.12.2010 18:08, schrieb Lukas Lueg:
Also, the
load_fast in lne 22 to reference x could be taken out of the loop as x
will always point to the same object
That's not true; a debugger may change the value of x.
On Sat, 01 Jan 2011 16:07:02 -0500, Terry Reedy tjre...@udel.edu wrote:
On 1/1/2011 5:07 AM, georg.brandl wrote:
Author: georg.brandl
Date: Sat Jan 1 11:07:30 2011
New Revision: 87603
Log:
Fix issue references.
(add '#' to issue numbers). Whoops, two of those are mine. I am still
Am 30.12.2010 15:55, schrieb martin.v.loewis:
Author: martin.v.loewis
Date: Thu Dec 30 15:55:47 2010
New Revision: 87577
Log:
Build and install libpython3.so.
Modified: python/branches/py3k/configure.in
==
---
I added informations about FreeBSD, NetBSD, Darwin and OpenBSD to the
issue #10348:
http://bugs.python.org/issue10348#msg125042
The maximum number of POSIX semaphores can be read with sysctl:
- FreeBSD: p1003_1b.sem_nsems_max
- NetBSD: kern.posix.semmax
- Darwin: kern.posix.sem.max
-
On 1/2/2011 8:17 AM, Victor Stinner wrote:
Le mercredi 29 décembre 2010 à 14:20 +0100, Martin v. Löwis a écrit :
Am 28.12.2010 18:08, schrieb Lukas Lueg:
Also, the
load_fast in lne 22 to reference x could be taken out of the loop as x
will always point to the same object
That's not true;
Cesare Di Mauro cesare.di.mauro at gmail.com writes:
2010/12/28 Lukas Lueg lukas.lueg at googlemail.com
Consider the following code:
def foobar(x):
for i in range(5):
x[i] = i
The bytecode in python 2.7 is the following:
2 0 SETUP_LOOP 30 (to 33)
On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor alex.gay...@gmail.com wrote:
No, it's singularly impossible to prove that any global load will be any given
value at compile time. Any optimization based on this premise is wrong.
True.
My proposed way out of this conundrum has been to change the
On 1/2/2011 10:18 PM, Guido van Rossum wrote:
My proposed way out of this conundrum has been to change the language
semantics slightly so that global names which (a) coincide with a
builtin, and (b) have no explicit assignment to them in the current
module, would be fair game for such
2011/1/1 Ned Batchelder n...@nedbatchelder.com
On 12/31/2010 12:51 PM, Cesare Di Mauro wrote:
Aggressive optimizations can be enabled with explicit options, in order
to leave normal debugger-prone code.
I wish the Python compiler would adopt a strategy of being able to disable
2011/1/3 Alex Gaynor alex.gay...@gmail.com
No, it's singularly impossible to prove that any global load will be any
given
value at compile time. Any optimization based on this premise is wrong.
Alex
That's your opinion, but I have very different ideas.
Of course we can't leave the
On Mon, Jan 3, 2011 at 3:36 PM, Terry Reedy tjre...@udel.edu wrote:
I believe this amounts to saying
1) Python code executes in three scopes (rather than two): global builtin,
modular (misleadingly call global), and local. This much is a possible
viewpoint today.
2) A name that is not an
12 matches
Mail list logo
