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
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
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 2.6?
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:
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
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
>> app
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 .__d
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
http://mail.python.org/mail
> 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
Vict
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
Que
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
-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).
Just
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 optimi
-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 of
> 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.
Re
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
inl
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 objec
> 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 o
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
-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 W
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 princ
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
Victor Stinner 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
> change anythin
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
marketdickins
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
25 matches
Mail list logo
