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
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
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
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
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
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 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;
> 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
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
> =
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
>
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
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
12 matches
Mail list logo
