Re: [Python-Dev] Python 3.0rc2: problem with exec()ing files
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 -- that's the only way we have of tracking things. -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ "It is easier to optimize correct code than to correct optimized code." --Bill Harlan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.3: call for patches
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 release will include all changes that are already on > the release25-maint branch in subversion [1]. If you think that specific > changes should be considered, please create an issue in the bug tracker > [2], and label it with the 2.5.3 version. Backports of changes that > are already released in Python 2.6 but may apply to 2.5 are of > particular interest. 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 Matthias ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3.0rc2: problem with exec()ing files
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 code object. [...] If it is
an open file, the file is parsed until EOF and executed.
--- 8< ---
However, at least on Python 3.0rc2 [2], this does not seem to work.
Please consider the following example:
1) First, let's prepare a source file which will contain a single line
of Python code (it is assumed here that it is safe to save the file in
the current working path):
>>> f = open("exectest.py", mode="wt", encoding="utf-8")
>>> f.write("print('Hello world!')\n")
22
>>> f.close()
2) Then, try executing that newly created file with the exec() function.
What I get is this:
>>> f = open("exectest.py", mode="rb")
>>> exec(f)
Traceback (most recent call last):
File "", line 1, in
exec(f)
TypeError: exec() arg 1 must be a string, bytes or code object
>>> f
* * *
So, am I seeing this behavior because...
a) I've misinterpreted the available documentation
b) The documentation does not agree with the current development goals
c) It is a bug or a yet-to-be-implemented feature of the built-in exec()
function?
_
[1]
[2] Python 3.0rc2 (r30rc2:67141, Nov 7 2008, 11:43:46) [MSC v.1500 32
bit (Intel)] on win32, to be exact.
--
znark
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.3: call for patches
-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 or OSX) will >> be provided anymore (from python.org). >> >> In principle, the release will include all changes that are already on >> the release25-maint branch in subversion [1]. If you think that specific >> changes should be considered, please create an issue in the bug tracker >> [2], and label it with the 2.5.3 version. Backports of changes that >> are already released in Python 2.6 but may apply to 2.5 are of >> particular interest. > > 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 +1 from a non-core developer who still has to keep sites using 2.4 up and running. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJGboU+gerLs4ltQ4RAmdLAJ9VDv8GpnhnNYI9tK0Sn9ClAbzg/wCbBxDD aKXYjnK50Cbeb8fp/QL/kaE= =cUE7 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.5.3: call for patches
> 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 (trunk revisions) CVE-2007-4965: r65880 CVE-2008-1721: r62235, issue2586 CVE-2008-3144: issue2588, issue2589, r63734, r63728. CVE-2008-1887: issue2587, r62261, r62271 CVE-2008-4864: r66689 So what about CVE-2008-1679: claimed to be issue1179 in the CVE, but that says it fixes CVE-2007-4965 only? CVE-2008-2315 In principle, this is fine with me, so go ahead. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0rc2: problem with exec()ing files
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 of all, please file a bug report -- that's the only way > we have of tracking things. Third of all, make it a doc bug -- the feature is gone and isn't coming back. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.0rc2: problem with exec()ing files
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 all, this discussion should probably go on the python-3000 >> list. But first of all, please file a bug report -- that's the only way >> we have of tracking things. > > Third of all, make it a doc bug -- the feature is gone and isn't coming back. No need now! Fixed in r67188. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python long integers
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 anything. Pybench is better it is also inaccurate to benchmark > operations on integers. > > That's I started to write a *basic* benchmark tool to compare the different > patches: see file bench_int.py of the issue #4294. If you want to benchmark arithmetic on large integers, you may try out the pidigits test from the Computer Language Shootout : http://shootout.alioth.debian.org/u64/benchmark.php?test=pidigits&lang=python&id=1 cheers Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Optimize Python long integers
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 marketdickinson: Use 30-bit digits instead of 15-bit digits for integers http://bugs.python.org/issue4258 pernici: faster long multiplication http://bugs.python.org/issue3944 haypo: Victor Stinner's GMP patch for longs http://bugs.python.org/issue1814 fredrikj: Asymptotically faster divmod and str(long) http://bugs.python.org/issue3451 See also: fredrikj: create a numbits() method for int and long types http://bugs.python.org/issue3439 Benchmark = 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 anything. Pybench is better it is also inaccurate to benchmark operations on integers. That's I started to write a *basic* benchmark tool to compare the different patches: see file bench_int.py of the issue #4294. Benchmark on a 64 bits CPU @2.5 GHz : --- original : 896.5 ms + macros: 891.0 ms (+0.6%) | ++ optimize : 884.3 ms (+1.4%) |-- issue #4294 +++ shift : 880.8 ms (+1.7%) | fast long: 746.8 ms (+16%) -- issue #3944 GMP : 700.9 ms (+22%) -- issue #1814 30 bits : 659.9 ms (+26%) -- issue #4258 --- Benchmark on a 32 bits CPU @3.0 GHz : --- original : 1564.3 ms fast long : 1591.7 ms (-2%) GMP : 1564.4 ms (=) 30 bits : 1497.3 ms (+4%) --- Don't trust the benchmark results since my tool is young and may also be inaccurate, but it's a good start to compare the patches. Notes: - my macro patch doesn't want to optimize anything, it's just a preparation for new patches; but I also attached "optimization" patches which are useless (only +1.7% with all patches). - 30 bits is always faster - GMP is faster on 64 bits or at same speed on 32 bits - fast long is slower on a 32 bits CPU Python integers === I tried to understand why the "30 bits" patch is not as fast as I expected. I introduced statistics in the long type: see long_stat.patch of the issue #4258. Summary (on a 32 bits CPU): - PyLong_FromLong(), long_add() and long_compare() are the 3 most common operations on integers. - Most integers are in range [-255; 255], large integers are rare. With make and pystone programs, largest integer has 1321 bits, but there is just one such integer. Another is 33 bits, but all other integers fits in 32 bits (without the sign, so 33 bits with the sign). I saw that the symbol table use memory address in a dictionary key (so 32 bits on a 32 bits CPU and 64 bits on a 32 bits CPU). => we have to focus on small integers - pystone is inaccurate to benchmark integers: it only uses a big integer (more than 1 digit in base 2^30) on 1.000.000 integers => don't use pystone! I don't have a solution working on any CPU with all numbers, this email is just a summary of the interesting integer patches. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python long integers
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 inlining through pointer tagging trickery. In Python 2.6 it costs 2-4% overall performance but increases integer arithmetic (in the range [-0x4000, 0x4000) only) by 10-20% according to my rough measurements (I haven't tried your benchmark yet.) I haven't ported it to 3.0 but it should provide a bigger win there. It also breaks API compatibility in a few ways: Py_TYPE(o) and Py_REFCNT(o) are no longer valid lvalues, and they and Py_INCREF(o) and Py_DECREF(o) may all evaluate 'o' twice. And, worst of all, it exposes the tagged pointers to third-party extensions, so anything not doing typechecks with Py_TYPE(o) will likely cause buserrors. In retrospect, perhaps this is too controversial to be added to the list ;-) I don't really expect this to be something CPython would want to use as-is, although there may be use for tagged pointers in more controlled environments (like function locals.) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python long integers
> 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. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python long integers
-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 these applied to 2.6? No! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRoa1nEjvBPtnXfVAQKwwgP/YvkcFbFc+RDV3VSJ6EHWuBVOdG9YFEGq Riq2GAst7kBMrteMfMHSv0Vb3elngLPRCKxTndUIV9B/ksfVQEHNbz9l1z7HRxmZ 0jVeYCkXCj923bsZ48Gq1MmcZ1d07TERfSVCDXnKooQgj8GlNqT70ru/0+eMFk8d wKLL6cpdak0= =cNoh -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python long integers
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 optimisations patches are long and may introduce new regressions. It's better to wait for 2.7/3.1. But it would be nice to get numbits() method (or property?) in Python 3.0(.1) and/or Python 2.6.1. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python long integers
-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 trying to clarify the focus: would you like to see any of these applied to 2.6? All optimisations patches are long and may introduce new regressions. It's better to wait for 2.7/3.1. But it would be nice to get numbits() method (or property?) in Python 3.0(.1) and/or Python 2.6.1. Anyone remember the bool debacle? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRodJHEjvBPtnXfVAQK0VwP/f2vyfahYxhRh/ug+ekMp63rhVvy2iMTn VXndnaKqJtJovjuM3YAGQk9/8l6tD4w0DklAi4e175aBvwzRkWb4RwMHGMO2/jn1 mNjloHqku6qIg6+p7jS5ytwsH6sGndgAjARY7jFE8OgYoYPrxtTabgXpr9HM631K a2j8FUmCVQ8= =yirj -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python 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 should be applied to 2.6.1 and 3.0.1 (not worth it for 3.0). I'll try to put together a separate patch containing these. They're mostly either missing casts or places where int should have been changed to Py_ssize_t. numbits shouldn't go into 2.6 or 3.0. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] n.numbits: method or property?
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 Question for python-dev: if numbits were to be added, should it be a property or a method? (Or something else entirely?) More generally, what are the guidelines for determining when it's appropriate to make something a property rather than a method? In favour of numbits being a (read-only, of course) property: - it looks nicer that way - it's a fast O(1) method, so is comparable to an attribute access in terms of efficiency - it can reasonably be thought of as a fundamental property of a binary integer - there are precedents, as Raymond points out in the issue discussion: e.g. z.real, z.imag Thoughts? Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] n.numbits: method or property?
> 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] n.numbits: method or property?
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 [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] n.numbits: method or property?
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 .__doc__ I'd suggest a third alternative, which is a standalone function in math: from math import numbits: numbits(1) -Mike ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python long integers
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? > > All optimisations patches are long and may introduce new regressions. It's > better to wait for 2.7/3.1. > > But it would be nice to get numbits() method (or property?) in Python 3.0(.1) > and/or Python 2.6.1. > > But that would be new functionality in a micro-release, which is verboten. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A statistic for Python tickets
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 following numbers for *still open* tickets: - How many tickets are open since: less than one week, between one week and two months, between two months and a year, more than a year. - How many tickets don't have any comment in the same periods. - How many tickets per keyword. - How many tickets per version. 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 the last weeks. But those opened more than two months ago just increase. Looking at this information, and applying some experience with the tickets, my conclusion is that when a ticket is fresh, is easier to handle it, but when a ticket starts to getting older, it just stalls. I can think now two reasons for this behaviour: the first is that in some tickets when a discussion arises, sometimes it gets to a dead point, from where it's very difficult to get out. The second is that in a lot of cases more info is needed from the OP, and the older the ticket, the less responsive is the OP. In general, I think that a lot of older tickets drain a lot of effort from developers, but I don't know which is the best way to handle this, :( Note: the "jump" that appears in the numbers at the beginning was an import of old SourceForge tickets to the new system, IIRC. Regards, [0] http://www.taniquetil.com.ar/cgi-bin/pytickets.py [1] http://www.taniquetil.com.ar/facundo/stathist.png -- .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] n.numbits: method or property?
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: (1).__doc__ 1 .__doc__ I'd suggest a third alternative, which is a standalone function in math: from math import numbits: numbits(1) Math is pretty much float, not int functions. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optimize Python long integers
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? All optimisations patches are long and may introduce new regressions. It's better to wait for 2.7/3.1. But it would be nice to get numbits() method (or property?) in Python 3.0(.1) and/or Python 2.6.1. Try something on Pypi if you want to distribute to non-svn users sooner than 2.7/3.1. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] n.numbits: method or property?
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, necessitating brackets or a > space before the dot: > > (1).__doc__ > 1 .__doc__ It's only awkward on constants, which should be pretty rare for a numbits property. The expected use case is on a variable. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A statistic for Python tickets
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 the > last weeks. > > But those opened more than two months ago just increase. I think you are finding the answer you want in the data. If I am not mistaken, by definition those tickets that are over a week old (and still open) get moved from the "week old" category (decrease) and into the "two month old" category (increase). The same being true of "two month old" -> "year" and "year" -> "older". So you really cannot say with any sort of certainty why "week", "two_month", or "year" decrease at all. I think you really have just roughly taken a moving average of the number of tickets opened with different window sizes. What you really want to know is how many tickets that are up to X days old are newly resolved (the ticket-resolution rate). Then, I think you could make the statements you just made. BTW, I'm not necessarily disagreeing with your insights into ticket pathology. -Scott -- Scott Dial [EMAIL PROTECTED] [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
