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 i
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 va
On Sat, 01 Jan 2011 16:07:02 -0500, Terry Reedy 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
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 gmail.com> writes:
>
>
> 2010/12/28 Lukas Lueg 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)
> 3 LO
On Sun, Jan 2, 2011 at 5:50 PM, Alex Gaynor 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 language
semantics sli
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 optimizati
2011/1/1 Ned Batchelder
> 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
> optimizations. I wrote
2011/1/3 Alex Gaynor
> 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 problem only on the co
On Mon, Jan 3, 2011 at 3:36 PM, Terry Reedy 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 assignment t
12 matches
Mail list logo
