[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-11-23 - 2012-11-30) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3792 ( -7) closed 24566 (+48) total 28358 (+41) Open issues with patches: 1653 Issues opened (27) == #8824: Improve documentation of exec http://bugs.python.org/issue8824 reopened by mark.dickinson #9400: multiprocessing.pool.AsyncResult.get() messes up exceptions http://bugs.python.org/issue9400 reopened by sbt #15587: IDLE is pixelated on the Macbook Pro with Retina Display http://bugs.python.org/issue15587 reopened by Tyler.Crompton #16541: tk_setPalette doesn't accept keyword parameters http://bugs.python.org/issue16541 opened by HJarausch #16543: improve TypeError messages for missing arguments (meta issue) http://bugs.python.org/issue16543 opened by ezio.melotti #16544: Add external link to ast docs http://bugs.python.org/issue16544 opened by asvetlov #16547: IDLE raises an exception in tkinter after fresh file's text ha http://bugs.python.org/issue16547 opened by ebfe #16550: pickletools.py treats 32bit lengths as signed, but pickle.py a http://bugs.python.org/issue16550 opened by serhiy.storchaka #16551: Cleanup the pure Python pickle implementation http://bugs.python.org/issue16551 opened by serhiy.storchaka #16554: The description of the argument of MAKE_FUNCTION and MAKE_CLOS http://bugs.python.org/issue16554 opened by daniel.urban #16555: Add es_cu to locale aliases http://bugs.python.org/issue16555 opened by Leiser.Fernández.Gallo #16557: PEP 380 isn't reflected in the Functional Programming HOWTO http://bugs.python.org/issue16557 opened by msmhrt #16561: Windows installer doesn't use UAC, then crashes http://bugs.python.org/issue16561 opened by Redoute #16562: Optimize dict equality test http://bugs.python.org/issue16562 opened by rhettinger #16564: email.generator.BytesGenerator fails with bytes payload http://bugs.python.org/issue16564 opened by Alexander.Kruppa #16565: Increase Py_AddPendingCall array size http://bugs.python.org/issue16565 opened by felipecruz #16566: Structure._anonymous_ should not allow strings http://bugs.python.org/issue16566 opened by techtonik #16568: allow constructors to be documented separately from class http://bugs.python.org/issue16568 opened by chris.jerdonek #16569: Preventing errors of simultaneous access in zipfile http://bugs.python.org/issue16569 opened by serhiy.storchaka #16572: Bad multi-inheritance support in some libs like threading or m http://bugs.python.org/issue16572 opened by thomas.chiroux #16574: clarify policy on updates to final peps http://bugs.python.org/issue16574 opened by chris.jerdonek #16575: ctypes: unions as arguments http://bugs.python.org/issue16575 opened by arigo #16576: ctypes: structure with bitfields as argument http://bugs.python.org/issue16576 opened by arigo #16577: Suspect test.test_codeccallbacks.test_mutatingdecodehandler http://bugs.python.org/issue16577 opened by amaury.forgeotdarc #16579: .pyw disturb multiprocessing behavior http://bugs.python.org/issue16579 opened by Alex.stein #16580: Add examples to int.to_bytres and int.from_bytes http://bugs.python.org/issue16580 opened by paddy3118 #16581: define "PEP editor" in PEP 1 http://bugs.python.org/issue16581 opened by chris.jerdonek Most recent 15 issues with no replies (15) == #16581: define "PEP editor" in PEP 1 http://bugs.python.org/issue16581 #16580: Add examples to int.to_bytres and int.from_bytes http://bugs.python.org/issue16580 #16575: ctypes: unions as arguments http://bugs.python.org/issue16575 #16561: Windows installer doesn't use UAC, then crashes http://bugs.python.org/issue16561 #16557: PEP 380 isn't reflected in the Functional Programming HOWTO http://bugs.python.org/issue16557 #16551: Cleanup the pure Python pickle implementation http://bugs.python.org/issue16551 #16550: pickletools.py treats 32bit lengths as signed, but pickle.py a http://bugs.python.org/issue16550 #16516: argparse types (and actions) must be hashable http://bugs.python.org/issue16516 #16509: sqlite3 docs do not explain check_same_thread http://bugs.python.org/issue16509 #16494: Add a method on importlib.SourceLoader for creating bytecode f http://bugs.python.org/issue16494 #16492: Add a load_parents argument to importlib.find_loader() http://bugs.python.org/issue16492 #16486: Add context manager support to aifc module http://bugs.python.org/issue16486 #16463: test_timeout failure on the RHEL buildbot http://bugs.python.org/issue16463 #16450: test_missing_localfile masks problems in urlopen http://bugs.python.org/issue16450 #16429: Emit SyntaxWarning for code that risks UnboundLocalError http://bugs.python.org/issue16429 Most recent 15 issues waiting for review (15) = #1657
Re: [Python-Dev] Summary of Python tracker Issues
Do we have a graph of the historical trend of the number of bugs (or at least the historical details stored somewhere)? I think we have had a net decrease in open bugs the last couple of weeks and it would be neat to see an absolute and relative graph of the overall trend since Python 3.3.0 was released. Also might make a nice motivator to try to close issues faster. =) Otherwise is the code public for this somewhere? I assume it's making an XML-RPC call or something every week to get the results, but if I decide to do a little App Engine app to store historical data and do a graph I would rather not have to figure all of this out from scratch. =) Although I could I guess also parse the email if I wanted to ignore all other emails. ___ 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] type vs. class terminology
On 11/29/2012 11:55 PM, Eli Bendersky wrote: On Sun, Nov 25, 2012 at 9:01 PM, Chris Jerdonek mailto:[email protected]>> wrote: I would like to know when we should use "class" in the Python 3 documentation, and when we should use "type." Are these terms synonymous in Python 3, and do we have a preference for which to use and when? I'm sure this has been discussed before. But if this terminology issue has already been resolved, the resolution doesn't seem to be reflected in the docs. For example, the glossary entries for type and class don't reference each other. Good question, [shameless plug follows, I post this because I truly believe it's very relevant to the discussion] I had the same doubts some months ago, which led to writing this article (relevant to Python 3): http://eli.thegreenplace.net/2012/03/30/python-objects-types-classes-and-instances-a-glossary/ It examines the class vs. type issue, as well as object vs. instance You usage seems to me to be stuck in the now mostly useless Python 1 distinction between built-in types and user-defined classes. In Python 3, all instances of type are classes, whether defined with the C or Python API. Indeed, the existence of a C API to make classes is an implementation detail, not a language feature. The second parameter of isinstance or issubclass is a class or set thereof (implemented as a (homogeneous!) tuple for historical reasons), without distinction of definition mode. When using an imported class, it mostly does not matter how the class was defined. I agree with Guido that it is more useful to use 'class' for the concrete run-time object and 'type' (except when referring to the object of that name) for abstract (and static) types. (From this viewpoint, duck-typing rather than duck-classing *is* the proper term). Consider the quote from the manual. "An object’s type determines the operations that the object supports (e.g., “does it have a length?”)." An object potentially supports len(), and one might say should support it, if and only if it is a 'finite collection'. That is a 'type' (duck type) of object, but not a class in the Python sense. Whether an object actually supports len depends on its run-time class. Similarly, an object 'should' support sqrt if it is a non-negative scalar number or a complex number. Square-root-able is also an abstract type, not a concrete class. I might suggest that types are used to reason about programs while classes are used to execute programs. -- Terry Jan Reedy ___ 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] Summary of Python tracker Issues
On 30.11.12 21:38, Brett Cannon wrote: Also might make a nice motivator to try to close issues faster. =) May be introduce the title of "Issue closer of the month"? ;) ___ 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] Summary of Python tracker Issues
On Fri, 30 Nov 2012 14:38:12 -0500, Brett Cannon wrote: > Do we have a graph of the historical trend of the number of bugs (or at > least the historical details stored somewhere)? I think we have had a net Not really. Ezio made one by hand once, but there is nothing automated. The historical details are stored only in the mailing list archives, as far as I know. In theory I think you could re-calculate them from the Roundup DB, but for various reasons the numbers would probably come out slightly different. Still, getting the data from the DB would be better than parsing the emails, since for one reason and another there are missing Friday reports, and reports that were issued on non-Friday dates. > decrease in open bugs the last couple of weeks and it would be neat to see > an absolute and relative graph of the overall trend since Python 3.3.0 was > released. Also might make a nice motivator to try to close issues faster. =) > > Otherwise is the code public for this somewhere? I assume it's making an Yes. It is in the software repository for our roundup instances: http://hg.python.org/tracker/python-dev/file/default/scripts/roundup-summary (Be warned that that isn't the location from which the script is executed, so it is possible for what is actually running to get out of sync with what is checked in at that location.) > XML-RPC call or something every week to get the results, but if I decide to Nope, it talks directly to the DB. And as you will see, it is more than a bit gnarly. > do a little App Engine app to store historical data and do a graph I would > rather not have to figure all of this out from scratch. =) Although I could > I guess also parse the email if I wanted to ignore all other emails. I'm not sure how one would go about integrating the above with an App Engine app. I suspect that not quite enough information is available through the XML-RPC interface to replicate that script, but maybe you could manage just the open-close counting part of it. I haven't looked at what it would take. --David ___ 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] Summary of Python tracker Issues
On Fri, Nov 30, 2012 at 4:07 PM, R. David Murray wrote: > On Fri, 30 Nov 2012 14:38:12 -0500, Brett Cannon wrote: > > Do we have a graph of the historical trend of the number of bugs (or at > > least the historical details stored somewhere)? I think we have had a net > > Not really. Ezio made one by hand once, but there is nothing automated. > > The historical details are stored only in the mailing list archives, as > far as I know. In theory I think you could re-calculate them from the > Roundup DB, but for various reasons the numbers would probably come out > slightly different. Still, getting the data from the DB would be better > than parsing the emails, since for one reason and another there are > missing Friday reports, and reports that were issued on non-Friday > dates. > > > decrease in open bugs the last couple of weeks and it would be neat to > see > > an absolute and relative graph of the overall trend since Python 3.3.0 > was > > released. Also might make a nice motivator to try to close issues > faster. =) > > > > Otherwise is the code public for this somewhere? I assume it's making an > > Yes. It is in the software repository for our roundup instances: > > > http://hg.python.org/tracker/python-dev/file/default/scripts/roundup-summary > > (Be warned that that isn't the location from which the script is > executed, so it is possible for what is actually running to get out of > sync with what is checked in at that location.) > > > XML-RPC call or something every week to get the results, but if I decide > to > > Nope, it talks directly to the DB. And as you will see, it is more > than a bit gnarly. > > I think I could also download the csv file and parse that to get whatever data I wanted. > > do a little App Engine app to store historical data and do a graph I > would > > rather not have to figure all of this out from scratch. =) Although I > could > > I guess also parse the email if I wanted to ignore all other emails. > > I'm not sure how one would go about integrating the above with an App > Engine app. I suspect that not quite enough information is available > through the XML-RPC interface to replicate that script, but maybe you > could manage just the open-close counting part of it. I haven't > looked at what it would take. > It really depends on what statistics I cared about (e.g. there are less than 4000 bugs while there are less than 25,000 closed bugs). If I just did high-level statistics it wouldn't be bad, but if I try to track every issue independently that might be annoying (and actually cost money for me, although I already personally pay for py3ksupport.appspot.com so I can probably piggyback off of that app's quota). We will see if this ever goes anywhere. =) ___ 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] Summary of Python tracker Issues
Hi, On Fri, Nov 30, 2012 at 11:52 PM, Brett Cannon wrote: > On Fri, Nov 30, 2012 at 4:07 PM, R. David Murray wrote: > >> On Fri, 30 Nov 2012 14:38:12 -0500, Brett Cannon >> wrote: >> > Do we have a graph of the historical trend of the number of bugs (or at >> > least the historical details stored somewhere)? I think we have had a >> net >> >> Not really. Ezio made one by hand once, but there is nothing automated. >> > The one I made can be found here: https://docs.google.com/spreadsheet/ccc?key=0AplyAWXqkvHUdFF0SkVrT3VKcnRBZXNrR1hleHowWnc I now updated it with the latest data. On the Sheet 2 you can find additional graphs that show the releases of Python together with the data. Only final releases are included, alphas, betas and rcs are not included. The spreadsheet is a bit messy because I was experimenting with different kind of graphs and trying to work around some limitations of Google Docs, but it should be good enough. > >> The historical details are stored only in the mailing list archives, as >> far as I know. In theory I think you could re-calculate them from the >> Roundup DB, but for various reasons the numbers would probably come out >> slightly different. Still, getting the data from the DB would be better >> than parsing the emails, since for one reason and another there are >> missing Friday reports, and reports that were issued on non-Friday >> dates. >> > One option I was considering is having the weekly report script append the result on a file and make it available on bugs.python.org, or even use it to generate graphs directly. This is something I considered and planned to implement for a long time, but haven't done it yet. >> > decrease in open bugs the last couple of weeks and it would be neat to >> see >> > an absolute and relative graph of the overall trend since Python 3.3.0 >> was >> > released. Also might make a nice motivator to try to close issues >> faster. =) >> > >> > Otherwise is the code public for this somewhere? I assume it's making an >> >> Yes. It is in the software repository for our roundup instances: >> >> >> http://hg.python.org/tracker/python-dev/file/default/scripts/roundup-summary >> >> (Be warned that that isn't the location from which the script is >> executed, so it is possible for what is actually running to get out of >> sync with what is checked in at that location.) >> >> > XML-RPC call or something every week to get the results, but if I >> decide to >> >> Nope, it talks directly to the DB. And as you will see, it is more >> than a bit gnarly. >> >> > I think I could also download the csv file and parse that to get whatever > data I wanted. > To figure out when an issue was closed you need to access its history, and that's not available through XML-RPC/csv IIRC. You should be able to figure out when the issue got created though. Anyway, it's probably easier to implement something like what I mentioned earlier. > >> > do a little App Engine app to store historical data and do a graph I >> would >> > rather not have to figure all of this out from scratch. =) Although I >> could >> > I guess also parse the email if I wanted to ignore all other emails. >> >> I'm not sure how one would go about integrating the above with an App >> Engine app. I suspect that not quite enough information is available >> through the XML-RPC interface to replicate that script, but maybe you >> could manage just the open-close counting part of it. I haven't >> looked at what it would take. >> > > It really depends on what statistics I cared about (e.g. there are less > than 4000 bugs while there are less than 25,000 closed bugs). If I just did > high-level statistics it wouldn't be bad, but if I try to track every issue > independently that might be annoying (and actually cost money for me, > although I already personally pay for py3ksupport.appspot.com so I can > probably piggyback off of that app's quota). We will see if this ever goes > anywhere. =) > > Another somehow related project/experiment I've been working on is collecting stats about the patches available on the tracker. I put together a temporary page that allows you to enter the name of a module (or any file/path) and get a list of issues with patches that affect the specified module(s): http://wolfprojects.altervista.org/issues.html FTR this is based on the word done by anatoly (see links on the page). I'm planning to eventually integrate this in the tracker too, but lately I don't have too much time, so there's no ETA. Best Regards, Ezio Melotti ___ 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
