On Tue, Nov 11, 2008, Jukka Aho wrote:
The current Py3k documentation [1] states that the built-in exec()
function should be able to execute code from open file objects:
Second of all, this discussion should probably go on the python-3000
list. But first of all, please file a bug report --
Martin v. Löwis schrieb:
Within a few weeks, we will release Python 2.5.3. This will be the last
bug fix release of Python 2.5, afterwards, future releases of 2.5 will
only include security fixes, and no binaries (for Windows or OSX) will
be provided anymore (from python.org).
In principle,
The current Py3k documentation [1] states that the built-in exec()
function should be able to execute code from open file objects:
--- 8 ---
exec(object[, globals[, locals]])
This function supports dynamic execution of Python code. object must be
either a string, an open file object, or a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Matthias Klose wrote:
Martin v. Löwis schrieb:
Within a few weeks, we will release Python 2.5.3. This will be the last
bug fix release of Python 2.5, afterwards, future releases of 2.5 will
only include security fixes, and no binaries (for Windows
I would like to apply fixes for some CVE's which are addressed in 2.5 but not
yet in 2.4. this would include
CVE-2007-4965
CVE-2008-1679
CVE-2008-1721
CVE-2008-2315
CVE-2008-3144
CVE-2008-1887
CVE-2008-4864
Can you identify the revisions that would need backporting?
I could only find
2008/11/11 Aahz [EMAIL PROTECTED]:
On Tue, Nov 11, 2008, Jukka Aho wrote:
The current Py3k documentation [1] states that the built-in exec()
function should be able to execute code from open file objects:
Second of all, this discussion should probably go on the python-3000
list. But first
On Tue, Nov 11, 2008 at 11:09 AM, Guido van Rossum [EMAIL PROTECTED] wrote:
2008/11/11 Aahz [EMAIL PROTECTED]:
On Tue, Nov 11, 2008, Jukka Aho wrote:
The current Py3k documentation [1] states that the built-in exec()
function should be able to execute code from open file objects:
Second of
Victor Stinner victor.stinner at haypocalc.com writes:
I tried to do benchmark on all these patches using pystone or pybench, but
the
results are inaccurate. Pystone results change with +/- 20% with the same
code on different runs. I tried more loops (pystone 25), but it doesn't
Hi,
Patches
===
There are some very interesting propositions (with patches!) to optimize
Python int and long types (especially the long integers).
haypo: Macros for PyLong: sign, number of digits, fits in an int
http://bugs.python.org/issue4294
On Tue, Nov 11, 2008 at 14:25, Victor Stinner
[EMAIL PROTECTED]wrote:
There are some very interesting propositions (with patches!) to optimize
Python int and long types (especially the long integers).
Here's another one:
http://code.python.org/loggerhead/users/twouters/intopt-- integer
There are some very interesting propositions (with patches!) to optimize
Python int and long types (especially the long integers).
Just trying to clarify the focus: would you like to see any of these
applied to 2.6? To me, it's clear that they are out of scope now, as
they don't fix bugs.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 11, 2008, at 6:14 PM, Martin v. Löwis wrote:
There are some very interesting propositions (with patches!) to
optimize
Python int and long types (especially the long integers).
Just trying to clarify the focus: would you like to see any
Le Wednesday 12 November 2008 00:14:40, vous avez écrit :
There are some very interesting propositions (with patches!) to optimize
Python int and long types (especially the long integers).
Just trying to clarify the focus: would you like to see any of these
applied to 2.6?
All
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Nov 11, 2008, at 6:56 PM, Victor Stinner wrote:
Le Wednesday 12 November 2008 00:14:40, vous avez écrit :
There are some very interesting propositions (with patches!) to
optimize
Python int and long types (especially the long integers).
On Tue, Nov 11, 2008 at 11:14 PM, Martin v. Löwis [EMAIL PROTECTED] wrote:
Just trying to clarify the focus: would you like to see any of these
applied to 2.6? To me, it's clear that they are out of scope now, as
they don't fix bugs.
There are some minor bugs in longobject.c that I think
As Victor Stinner mentioned in a recent thread, there's a patch in
the works to add a numbits ... um ... gadget to integers, returning
the number of bits needed to represent the integer (or more
precisely, the ceiling of the log to base 2 of the integer). See
http://bugs.python.org/issue3439
n.numbits: method or property?
Fredrik Johansson and me agree to use a property.
My last patch (numbits-4.patch) implement numbits as a property. Examples:
(1023).numbits
10
x=1023L; x.numbits
10L
x=2**(2**10); x.numbits
1025L
x=2**(2**10); x.numbits.numbits # combo!
11L
Victor
On Wed, Nov 12, 2008 at 12:16 AM, Mark Dickinson [EMAIL PROTECTED] wrote:
precisely, the ceiling of the log to base 2 of the integer). See
D'oh. s/ceiling/1+floor/
Mark
___
Python-Dev mailing list
Python-Dev@python.org
On 11-Nov-08, at 4:16 PM, Mark Dickinson wrote:
More generally, what are the guidelines for determining
when it's appropriate to make something a property rather
than a method?
Both are awkward on numeric types in python, necessitating brackets or
a space before the dot:
(1).__doc__
1
Victor Stinner wrote:
Le Wednesday 12 November 2008 00:14:40, vous avez écrit :
There are some very interesting propositions (with patches!) to optimize
Python int and long types (especially the long integers).
Just trying to clarify the focus: would you like to see any of these
applied to
Hi all! I generated this info for other list, thought that it could be
valuable to share it here...
I've been collecting some statistics since January, as I'm concerned
about the issue of tickets quantity just getting higher.
I've been saving twice a day (everytime I generate this [0] info), the
Mike Klaas wrote:
On 11-Nov-08, at 4:16 PM, Mark Dickinson wrote:
More generally, what are the guidelines for determining
when it's appropriate to make something a property rather
than a method?
Both are awkward on numeric types in python, necessitating brackets or a
space before the dot:
Victor Stinner wrote:
Le Wednesday 12 November 2008 00:14:40, vous avez écrit :
There are some very interesting propositions (with patches!) to optimize
Python int and long types (especially the long integers).
Just trying to clarify the focus: would you like to see any of these
applied to
On Tue, Nov 11, 2008 at 6:59 PM, Mike Klaas [EMAIL PROTECTED] wrote:
On 11-Nov-08, at 4:16 PM, Mark Dickinson wrote:
More generally, what are the guidelines for determining
when it's appropriate to make something a property rather
than a method?
Both are awkward on numeric types in python,
Facundo Batista wrote:
I just graphed the first number how many tickets are open since
the different periods. As you can see here [1], the tickets that are
open since less than a week remain more or less constant. Those opened
between a week and two months even seem to go down a little in
25 matches
Mail list logo
