Python-Dev September 2010

python-dev@python.org

125 participants
120 discussions

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
by "Martin v. Löwis" 27 Sep '10

27 Sep '10

Am 27.09.2010 22:17, schrieb P.J. Eby: > At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: >> All fixed. > > Nope. Indeed. The immediate problem was that genpepindex tried to read pep-0000, and didn't like it. I worked around that in r85041, so that genpepindex now skips over pep-0000.txt. However, if it's really important that the fields in a PEP are in a certain order (why is that important?), then I guess PEP 0 should really comply with its own specification :-) Regards, Martin

1 0

Re: [Python-Dev] Some changes to logging for 3.2
by Chris Withers 27 Sep '10

27 Sep '10

On 24/09/2010 12:06, Vinay Sajip wrote: >> http://plumberjack.blogspot.com/2010/09/improved-queuehandler-queuelistener… >>> >> >> Cool, how can I use it in Python 2.6? :-) > > 1. Copy the top part (imports, QueueHandler and QueueListener classes) from the > Gist linked to in the article - http://gist.github.com/591699 - into a utility > module you can use again and again. Thanks! Although my comment was a light hearted dig from my point of view that the components of the standard library should be separately packaged and a python distribution should just be a "known good set" of these packages... Were that the case, users of Python 2.5, 2.6 *and* 2.7 could benefit from your good work :-) cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

Re: [Python-Dev] Python wiki
by Paul Boddie 27 Sep '10

27 Sep '10

Hello, I've been following this thread all week at work, but I thought it might be time to respond to the different remarks in a single response, given that I am involved in editing and maintaining the Wiki on python.org, and I had a strong enough opinion about such things to give a talk about it at EuroPython that some of you attended: http://wiki.europython.eu/Talks/Web_Collaboration_And_Python/Talk Guido van Rossum wrote: > On Thu, Sep 23, 2010 at 3:35 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote: > > There actually is an admin team, and they actually do set ACLs. > > Who are they? > > > IIUC, this is primarily for spam protection, though. > > So would they object against additions to the team? The administrators are generally the people on the following page: http://wiki.python.org/moin/AdminGroup Someone may have special powers, particularly if they have shell access to the machine running the Wiki, but there's no "secret brotherhood". In fact, I recall advocating that Carl Trachte get admin powers given his continuing high-quality contributions, so we can say that people aren't denying others administrative privileges if that person is clearly doing good work and would benefit from being able to have those privileges. [Later on...] Guido van Rossum wrote: > On Fri, Sep 24, 2010 at 3:31 AM, Michael Foord > > <fuzzyman at voidspace.org.uk> wrote: > > Wiki maintenance is discussed, along with other python.org maintenance > > topics, on the pydotorg-www mailing list: > > > > http://mail.python.org/mailman/listinfo/pydotorg-www > > Which has hidden its membership (even to members). Does it really need > to appear that secretive? At least the message archive is open and has > all the usual suspects. As we're now seeing, people don't feel that it's acceptable to publish the subscribers list, and I think that it's a complete distraction to seek to do so, anyway. It's not as if everyone on that list has special privileges and is preventing newcomers from joining it. > > More wiki and website maintainers needed! > > Maybe a prominent wiki page with info about how to join the list and > the responsibilities / needs would help? > > Also, I gotta say that the wiki login process is awkward. MoinMoin supports OpenID, although I did find and report issues with Moin 1.9 in this regard. Something on my now-huge list of things to do is to make Moin authentication better, especially where there might be a choice of authentication methods. Georg Brandl wrote: > Am 23.09.2010 22:25, schrieb anatoly techtonik: > > On Thu, Sep 23, 2010 at 6:57 PM, Barry Warsaw <barry at python.org> wrote: > >> I certainly agree with that. So, how can we solve those problems? > >> Radomir has shell access now so perhaps we can ask him to make the > >> Python wiki theme more visually appealing. What roadblocks do people > >> encounter when they want to help garden or reorganize the wiki? > > > > First of all Wiki is outdated. Correct me, but python.org specific > > customizations are not modules, but patches that makes it hard to > > update the Wiki to latest version or add new customizations. > > That's why we have a Moin core developer on the team. ISTM that Moin 1.x > is notoriously hard to extend -- once you go beyond plugins adding new wiki > macros -- which is part of what the team wants to fix in 2.x. Although I understand the sentiments about "specific customizations", python.org should only have its theme as something that isn't a generic extension to MoinMoin, and that theme should be actively maintained. When python.org switched its architecture a while ago, the special theme presumably came with the deal, but it's been so out of date for so long that I switched to one of the standard themes years ago. Fortunately, Radomir's EuroPython theme is actively maintained, works with recent MoinMoin releases, looks a lot better than the old theme, and is used elsewhere. As for Moin 1.x being "notoriously hard to extend" beyond macros, you can get a long way with macros and actions, although I agree that sometimes it's possible to hit architectural constraints. > > Second - ugly Creole syntax. I am for inter-cooperation between wikis, > > and I understand that for non-developer communities [] symbols > > imposing problems, but as an open source developer I am addicted to > > Trac and Google Code syntax and never had problems with those. > > This isn't Creole syntax, it's Moin wiki syntax. And face it, it's not > going to change. It's also not so much different from Trac wiki syntax. I never agreed with this complaint, anyway. When discussing this previously with Anatoly, I went as far as to ask on #moin where Radomir actually posted a good summary of the syntax differences: http://wiki.python.org/moin/SiteImprovements/WikiSyntaxComparison I invite anyone to justify claims that the old style (which Trac adopted) was better. Complaints about double bracketing are specious: MediaWiki has different bracketing levels and it's really confusing. > > Fourth. GPL license. I personally don't have interest to waste my time > > for the code I won't be able to use in some projects, unless the > > project is either exceptional (Mercurial) or interesting. To make > > python.org MoinMoin interesting - there should be an inviting > > entrypoint (see point three above) and the list of tasks to choose > > form. Something that is better than > > http://wiki.python.org/moin/SiteImprovements > > Yes, that needs to be updated indeed. On the matter of the GPL, Anatoly and I more or less agreed to disagree when we last discussed the Web site. On the matter of site improvements and the page which attempts to document ideas, we could move such things to a tracker (where they will probably get as much attention as the Web site bugs get right now), or we could actually prune a lot of the issues by addressing them with fixes that are readily available (applying to a lot of "xyz doesn't work" complaints). Getting people to accept that things aren't going to change for the sake of it (like the Wiki syntax) is more difficult, but at some point such discussions just have to end. anatoly techtonik wrote: > That's a dead way. Wiki should be open for everyone. Just need more > people subscribed to revert unwelcome changes. That is to make > timeline more visible, because on wiki.python.org it is _not_ > intuitive. It may worth to see how Mercurial wiki is managed - I've > picked up the bookmarks monitoring habit from it. Maybe a design > change will help, but again - there is no entrypoint for people with > design skills to start. The Wiki is generally "open for everyone", but as I noted in my talk you often get people who decide that their opinion is worth more than the cumulative knowledge and experience of everyone who has been maintaining a particular resource [1]. You also have to prevent spamming and vandalism which is quite well taken care of with the TextCha support, although I accept that mechanisms should be in place to promote users to higher levels of privilege after a while - another little project on my long "to do" list - so that they don't have to answer editing questions. As for the Mercurial Wiki, I have some involvement with that, and I don't see how it is significantly differently managed. I've also proposed various changes to that Wiki including a theme that could be deployed straight away, but I suspect that it's more a case of people being too busy to take me up on any such offer than a malicious cabal denying me the chance to improve a particular Internet resource. Some final notes on the matter of Wiki editing: The Wiki has for a long time been a product of many co-existing contributions that occasionally overlap with each other and are tied together as respectfully and gently as possible. Although there is a temptation to overhaul much of the content, respect for the existing structure and content has mostly restrained any cleaning-up attempts. I wouldn't mind a bit of reorganisation, but that brings us to the role of the Wiki. If other resources are meant to provide the bulk of what people consider the "important" content, then the Wiki will always have to be shaped to respect that; if the Wiki is to hold much of that content, then issues such as navigability become even more critical. But what is certain is that tucking the Wiki away in some obscure location (I had to request that a link to it be re-added to the front page of python.org recently, as I recall) and treating it like a playpen will only encourage casual edits with little concern for the resulting quality. Anyone now on the verge of concluding that this is purely a Wiki phenomenon should consult my "common myths" slide: http://wiki.europython.eu/Talks/Web_Collaboration_And_Python/Talk#Some_Comm… High-quality documentation isn't something you get for nothing, nor is it a property of some magic solution or tool: there's always some hard work involved for human beings. Paul [1] One "happy" memory of mine involves someone who decided that their style and terminology edits were so important that they felt the need to tell me "don't modify it again" when it was they who were doing the modifying.

8 11

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
by P.J. Eby 26 Sep '10

26 Sep '10

Done. The other amendments were never actually made, so I just reverted the Python 3 bit after moving it to the new PEP. I'll make the changes to 3333 instead as soon as I have another time slot free. At 01:56 PM 9/26/2010 -0700, Guido van Rossum wrote: >Since you have commit privileges, just do it. The PEP editor position >mostly exists to assure non-committers are not prevented from >authoring PEPs. > >Please do add a prominent note at the top of PEP 333 pointing to PEP >3333 for further information on Python 3 compliance or some such >words. Add a similar note at the top of PEP 3333 -- maybe mark up the >differences in PEP 3333 so people can easily tell what was added. And >move PEP 333 to Final status. > >--Guido > >On Sun, Sep 26, 2010 at 1:50 PM, P.J. Eby <pje(a)telecommunity.com> wrote: > > At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote: > >> > >> On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw <barry(a)python.org> wrote: > >> > On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote: > >> > > >> >> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote: > >> >>> I'm happy approving Final status for the > >> >>> *original* PEP 333 and I'm happy to approve a new PEP which includes > >> >>> PJE's corrections. > >> >> > >> >> Can we make it PEP 3333, then? ;-) > >> > > >> > That works for me. > >> > >> Go for it. > > > > Shall I just "svn cp" it, then (to preserve edit history), or wait for the > > PEP editor do it? > > > > > > > >-- >--Guido van Rossum (python.org/~guido) >_______________________________________________ >Python-Dev mailing list >Python-Dev(a)python.org >http://mail.python.org/mailman/listinfo/python-dev >Unsubscribe: >http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com

1 0

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
by P.J. Eby 26 Sep '10

26 Sep '10

At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote: >On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw <barry(a)python.org> wrote: > > On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote: > > > >> At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote: > >>> I'm happy approving Final status for the > >>> *original* PEP 333 and I'm happy to approve a new PEP which includes > >>> PJE's corrections. > >> > >> Can we make it PEP 3333, then? ;-) > > > > That works for me. > >Go for it. Shall I just "svn cp" it, then (to preserve edit history), or wait for the PEP editor do it?

3 2

Re: [Python-Dev] WSGI is now Python 3-friendly
by P.J. Eby 26 Sep '10

26 Sep '10

At 09:22 PM 9/25/2010 -0400, Jesse Noller wrote: >It seems like it will end up >different enough to be a different specification, closely related to >the original, but different enough to trip up all the people >maintaining current WSGI servers and apps. The only actual *change* to the spec is mandating the use of the 'bytes' type or equivalent for HTTP bodies when using Python 3. Seriously, that's *it*. Everything else that's (planned to be) added is either 100% truly just clarifications (e.g. nothing in the spec *ever* said SERVER_PORT could be an int, but apparently some people somehow interpreted it so), or else best-practice recommendations from people who actually implemented WSGI servers. For example, the readline() size hint is "not supported" in the original spec (meaning clients can't call it and be compliant). The planned modification is "servers should implement it" (best practice), but you can't call an implementation that *doesn't* implement it noncompliant. (This just addresses the fact that most practical implementations *did* in fact support it, and code out there relies on this.) So, no (previously-)compliant implementations were harmed in the making of the updated spec. If they were compliant before, they're compliant now. I'm actually a bit surprised people are bringing this up now, since when I announced the plan to make these changes, I said that nothing would be changed that would break anything... even for what I believe are the only Python 3 WSGI implementations right now (by Graham Dumpleton and Robert Brewer). Indeed, all of the changes (except the bytes thing) are stuff previously discussed endlessly on the Web-SIG (years ago in most cases) and widely agreed on as, "this should have been made clear in the original PEP". And, I also explicitly deferred and/or rejected items that *can't* be done in a 100% backward-compatible way, and would have to be WSGI 1.1 or higher -- indeed, I have a long list of changes from Graham that I've pronounced "can't be done without a 1.1". Indeed, the entire point of the my scope choices were to allow all this to happen *without* a whole new spec. ;-)

6 7

PyObject_GC_UnTrack() no longer reliable in 2.7?
by Tim Peters 26 Sep '10

26 Sep '10

Looks like 2.7 changes introduced to exempt dicts and tuples from cyclic gc if they obviously can't be in cycles has some unintended consequences. Specifically, if an extension module calls PyObject_GC_UnTrack() on a dict it _does not want tracked_, Python can start tracking the dict again. I assume this is unintended because (a) the docs weren't changed to warn about this; and, (b) it's wrong ;-) There are two main reasons an extension module may have been calling PyObject_GC_UnTrack(): 1. For correctness, if the extension is playing games with reference counts Python isn't expecting. 2. For speed, if the extension is creating dicts (or tuples) it knows cannot participate in cycles. This came up when Jim Fulton asked me for advice about assertion failures coming out of cyclic gc in a debug build when running ZODB's tests under 2.7. Turned out to be due to the "#1 reason" above: ZODB hand-rolled its own version of weak references long before Python had them, and has a dict mapping strings ("object IDs") to complex objects where the referenced objects' refcounts intentionally do _not_ account for the references due to this dict. This had been working fine for at least 8 years, thanks to calling PyObject_GC_UnTrack() on this dict right after it's created. But under 2.7, new code in Python apparently decides to track this dict again the first time its __setitem__ is called. Cyclic gc then discovers object references due to this dict that aren't accounted for in the referenced objects' refcounts, and dies early on with an assertion failure (which it should do - the refcounts are nuts as far as Python is concerned). Jim wormed around that for now by calling PyObject_GC_UnTrack() again every time the dict's content changes, but that was relatively easy in this case because the dict is an internal implementation detail all accesses to which are under ZODB's control. Best if no changes had been needed. "Better than nothing" if the docs are changed to warn that the effect of calling PyObject_GC_UnTrack() may be undone by Python a nanosecond later ;-)

6 8

Re: [Python-Dev] WSGI is now Python 3-friendly
by P.J. Eby 26 Sep '10

26 Sep '10

At 07:15 PM 9/25/2010 -0700, Guido van Rossum wrote: >Don't see this as a new spec. See it as a procedural issue. As a procedural issue, PEP 333 is an Informational PEP, in "Draft" status, which I'd like to make Final after these amendments. See http://www.wsgi.org/wsgi/Amendments_1.0, which Graham created in 2007, stating: """This page is intended to collect any ideas related to amendments to the original WSGI 1.0 so that it can be marked as 'Final'.""" IOW, there is no intention to treat the PEP as "mutable" going forward; this is just cleanup so we can mark it Final. After that, it's an ex-parrot. >Clarifications of ambiguous/unspecified behavior can possibly rule as >non-conforming implementations that used to get the benefit of the >doubt. Best-practice recommendations also have the effect of changing >(perceived) compliance. I understand the general principle, but with respect to these *specific* changes, any perceived-compliance arguments that were going to happen, already happened years ago. The changes are merely to officially document the way those arguments already turned out, so the PEP can become Final. Specifically, the changes all fall into one of three categories: 1. Textual clarification (SERVER_PORT is not an int, iteration can stop before all output is consumed) 2. Practical issues with wsgi.input arising from the fact that real-world programs needed its behavior to be more "file-like" than the specification required... and which essentially forced servers that were not using socket.makefile() to make their emulations work like that, anyway (or else be rejected by users). 3. Clarification of behavior that would break HTTP compliance (apps or servers sending more than Content-Length bytes) and is therefore *already a bug* in any implementation that does it. Since in all three categories any implementation that did not end up following the recommendations on its own is going to have been considered buggy by its users (regardless of its formal "compliance"), and because the changes do not actually declare the buggy behaviors in categories 2 and 3 to be non-compliant, I do not see how any of these changes can produce the type of problems you're worried about here. Certainly, if I thought such problems were possible, I wouldn't have accepted these amendments. Likewise, if I thought that changes would continue to be made to the PEP past this point, the goal wouldn't be getting it to Final status.

1 0

Re: [Python-Dev] WSGI is now Python 3-friendly
by P.J. Eby 26 Sep '10

26 Sep '10

At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote: >This is a very laudable initiative and I approve of the changes -- but >I really think it ought to be a separate PEP rather than pretending it >is just a set of textual corrections on the existing PEP 333. With the exception of the bytes change, I ruled out accepting any proposed amendments that would actually alter the protocol. The amendments are all either textual clarifications, clarifications of ambiguous/unspecified areas, or best-practice recommendations by implementors. (i.e., which are generally already implemented in major servers) The full list of things Graham and others have asked for or recommended would indeed require a 1.1 version at minimum, and thus a new PEP. But I really don't want to start down that road right now, and therefore hope that I can talk Graham or some other poor soul into shepherding a 1.1 PEP instead. ;-) (Seriously: through an ironic twist of fate, I have done nearly *zero* Python web programming since around the time I drafted the first spec in 2004, so even if it makes sense for me to finish PEP 333, it makes little sense for me to be starting a *new* one on the topic now!)

2 1

Summary of Python tracker Issues
by Python tracker 26 Sep '10

26 Sep '10

ACTIVITY SUMMARY (2010-09-17 - 2010-09-24) 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 stats: open 2533 (+42) closed 19189 (+57) total 21722 (+53) Open issues with patches: 1061 Issues opened (42) ================== #1763: Winpath module - easy access to Windows directories like My Do http://bugs.python.org/issue1763 reopened by r.david.murray #6627: threading.local() does not work with C-created threads http://bugs.python.org/issue6627 reopened by Nikratio #9441: increase logging handlers test coverage http://bugs.python.org/issue9441 reopened by r.david.murray #9552: ssl build under Windows always rebuilds OpenSSL http://bugs.python.org/issue9552 reopened by ocean-city #9877: Expose sysconfig._get_makefile_filename() in public API http://bugs.python.org/issue9877 reopened by eric.araujo #9889: PyUnicode_FormatV and Py_UNICODE*? http://bugs.python.org/issue9889 opened by mkleehammer #9890: Visual C++ Runtime Library Error is there a fix? http://bugs.python.org/issue9890 opened by Hydro56 #9891: Minor doc typo at datamodel.rst: "list" -> "alist" http://bugs.python.org/issue9891 opened by rbp #9893: Usefulness of the Misc/Vim/ files? http://bugs.python.org/issue9893 opened by pitrou #9896: Introspectable range objects http://bugs.python.org/issue9896 opened by durban #9897: multiprocessing problems http://bugs.python.org/issue9897 opened by hume #9903: test_concurrent_futures writes on stderr http://bugs.python.org/issue9903 opened by pitrou #9904: Cosmetic issues that may warrant a fix in symtable.h/c http://bugs.python.org/issue9904 opened by eli.bendersky #9905: subprocess.Popen fails with stdout=PIPE, stderr=PIPE if standa http://bugs.python.org/issue9905 opened by Thomas.Claveirole #9907: interactive mode TAB does not insert on OS X built with editli http://bugs.python.org/issue9907 opened by ned.deily #9909: request for calendar.dayofyear() function http://bugs.python.org/issue9909 opened by jfinkels #9910: Add Py_SetPath API for embeddint python http://bugs.python.org/issue9910 opened by krisvale #9912: Fail when vsvarsall.bat produces stderr http://bugs.python.org/issue9912 opened by flub #9913: Misc/SpecialBuilds.txt is out of date http://bugs.python.org/issue9913 opened by belopolsky #9914: trace/profile conflict with the use of sys.modules[__name__] http://bugs.python.org/issue9914 opened by belopolsky #9915: speeding up sorting with a key http://bugs.python.org/issue9915 opened by stutzbach #9917: resource max value represented as signed when should be unsign http://bugs.python.org/issue9917 opened by r.david.murray #9919: gdbinit lineno result is one line in excess http://bugs.python.org/issue9919 opened by qpatata #9920: test_cmath on atan fails on AIX http://bugs.python.org/issue9920 opened by sable #9921: os.path.join('x','') behavior http://bugs.python.org/issue9921 opened by rgrig #9922: subprocess.getstatusoutput can fail with utf8 UnicodeDecodeErr http://bugs.python.org/issue9922 opened by debatem1 #9923: mailcap module may not work on non-POSIX platforms if MAILCAPS http://bugs.python.org/issue9923 opened by gnofi #9924: sqlite3 SELECT does not BEGIN a transaction, but should accord http://bugs.python.org/issue9924 opened by zzzeek #9925: Idle doesn't launch http://bugs.python.org/issue9925 opened by Stephan.Bellegy #9926: Wrapped TestSuite subclass does not get __call__ executed http://bugs.python.org/issue9926 opened by loewis #9927: Leak around GetFinalPathNameByHandle (Windows) http://bugs.python.org/issue9927 opened by ocean-city #9929: subprocess.Popen unbuffered not work http://bugs.python.org/issue9929 opened by ocean-city #9931: test_ttk_guionly hangs on XP5 http://bugs.python.org/issue9931 opened by ocean-city #9934: Python Docs Typo http://bugs.python.org/issue9934 opened by Retro #9935: Faster pickling of instances http://bugs.python.org/issue9935 opened by pitrou #9936: trace misreports "missing" lines http://bugs.python.org/issue9936 opened by belopolsky #9937: _winreg.EnumValue causes MemoryError http://bugs.python.org/issue9937 opened by kzmi #9938: Documentation for argparse interactive use http://bugs.python.org/issue9938 opened by jayt #9939: Add a pipe type (FIFO) to the io module http://bugs.python.org/issue9939 opened by pitrou #9940: Strange error reporting with "with" statement http://bugs.python.org/issue9940 opened by pitrou #1724822: provide a shlex.split alternative for Windows shell syntax http://bugs.python.org/issue1724822 reopened by r.david.murray #678250: test_mmap failling on AIX http://bugs.python.org/issue678250 reopened by r.david.murray Most recent 15 issues with no replies (15) ========================================== #9940: Strange error reporting with "with" statement http://bugs.python.org/issue9940 #9938: Documentation for argparse interactive use http://bugs.python.org/issue9938 #9935: Faster pickling of instances http://bugs.python.org/issue9935 #9934: Python Docs Typo http://bugs.python.org/issue9934 #9931: test_ttk_guionly hangs on XP5 http://bugs.python.org/issue9931 #9914: trace/profile conflict with the use of sys.modules[__name__] http://bugs.python.org/issue9914 #9913: Misc/SpecialBuilds.txt is out of date http://bugs.python.org/issue9913 #9909: request for calendar.dayofyear() function http://bugs.python.org/issue9909 #9904: Cosmetic issues that may warrant a fix in symtable.h/c http://bugs.python.org/issue9904 #9903: test_concurrent_futures writes on stderr http://bugs.python.org/issue9903 #9891: Minor doc typo at datamodel.rst: "list" -> "alist" http://bugs.python.org/issue9891 #9889: PyUnicode_FormatV and Py_UNICODE*? http://bugs.python.org/issue9889 #9886: Make operator.itemgetter/attrgetter/methodcaller easier to dis http://bugs.python.org/issue9886 #9883: minidom: AttributeError: DocumentFragment instance has no attr http://bugs.python.org/issue9883 #9861: subprocess module changed exposed attributes http://bugs.python.org/issue9861 Most recent 15 issues waiting for review (15) ============================================= #9936: trace misreports "missing" lines http://bugs.python.org/issue9936 #9935: Faster pickling of instances http://bugs.python.org/issue9935 #9929: subprocess.Popen unbuffered not work http://bugs.python.org/issue9929 #9927: Leak around GetFinalPathNameByHandle (Windows) http://bugs.python.org/issue9927 #9922: subprocess.getstatusoutput can fail with utf8 UnicodeDecodeErr http://bugs.python.org/issue9922 #9919: gdbinit lineno result is one line in excess http://bugs.python.org/issue9919 #9915: speeding up sorting with a key http://bugs.python.org/issue9915 #9912: Fail when vsvarsall.bat produces stderr http://bugs.python.org/issue9912 #9910: Add Py_SetPath API for embeddint python http://bugs.python.org/issue9910 #9909: request for calendar.dayofyear() function http://bugs.python.org/issue9909 #9907: interactive mode TAB does not insert on OS X built with editli http://bugs.python.org/issue9907 #9896: Introspectable range objects http://bugs.python.org/issue9896 #9891: Minor doc typo at datamodel.rst: "list" -> "alist" http://bugs.python.org/issue9891 #9877: Expose sysconfig._get_makefile_filename() in public API http://bugs.python.org/issue9877 #9869: long_subtype_new segfault in pure-Python code http://bugs.python.org/issue9869 Top 10 most discussed issues (10) ================================= #8998: add crypto routines to stdlib http://bugs.python.org/issue8998 39 msgs #9552: ssl build under Windows always rebuilds OpenSSL http://bugs.python.org/issue9552 17 msgs #9630: Reencode filenames when setting the filesystem encoding http://bugs.python.org/issue9630 10 msgs #6627: threading.local() does not work with C-created threads http://bugs.python.org/issue6627 9 msgs #9360: nntplib cleanup http://bugs.python.org/issue9360 8 msgs #9864: email.utils.{parsedate,parsedate_tz} should have better return http://bugs.python.org/issue9864 8 msgs #9939: Add a pipe type (FIFO) to the io module http://bugs.python.org/issue9939 8 msgs #2200: find_executable fails to find .bat files on win32 http://bugs.python.org/issue2200 7 msgs #9583: Document startup option/environment interaction http://bugs.python.org/issue9583 7 msgs #678250: test_mmap failling on AIX http://bugs.python.org/issue678250 7 msgs Issues closed (57) ================== #1142: code sample showing errors reading large files with py 2.5/3.0 http://bugs.python.org/issue1142 closed by amaury.forgeotdarc #1441: Cycles through ob_type aren't freed http://bugs.python.org/issue1441 closed by benjamin.peterson #1458: installer crashes on attempted cancellation http://bugs.python.org/issue1458 closed by BreamoreBoy #1518: Fast globals/builtins access (patch) http://bugs.python.org/issue1518 closed by BreamoreBoy #1532: Refleak run of test_tcl fails http://bugs.python.org/issue1532 closed by BreamoreBoy #1605: Semi autogenerated _types module http://bugs.python.org/issue1605 closed by gvanrossum #1686: string.Template.safe_substitute fail when overriding pattern http://bugs.python.org/issue1686 closed by flox #1794: Hot keys must work in any keyboard layout http://bugs.python.org/issue1794 closed by r.david.murray #1866: const arg for PyInt_FromString http://bugs.python.org/issue1866 closed by ncoghlan #2027: Module containing C implementations of common text algorithms http://bugs.python.org/issue2027 closed by BreamoreBoy #2236: Distutils' mkpath implementation ignoring the "mode" parameter http://bugs.python.org/issue2236 closed by orsenthil #2643: mmap_object_dealloc calls time-consuming msync(), although clo http://bugs.python.org/issue2643 closed by pitrou #8432: buildbot: test_send_signal of test_subprocess failure http://bugs.python.org/issue8432 closed by pitrou #9131: test_set_reprs in test_pprint is fragile http://bugs.python.org/issue9131 closed by stutzbach #9252: PyImport_Import calls __import__ with dummy fromlist http://bugs.python.org/issue9252 closed by brett.cannon #9582: documentation line needs rewording http://bugs.python.org/issue9582 closed by benjamin.peterson #9597: mac: Install 2to3 in /usr/local/bin http://bugs.python.org/issue9597 closed by ned.deily #9786: Native TLS support for pthreads http://bugs.python.org/issue9786 closed by krisvale #9790: ntpath contains imports inside functions http://bugs.python.org/issue9790 closed by brian.curtin #9808: Implement os.getlogin on Windows http://bugs.python.org/issue9808 closed by janglin #9810: bzip2 build sometimes fails (VS8.0) http://bugs.python.org/issue9810 closed by ocean-city #9851: multiprocessing socket timeout will break client http://bugs.python.org/issue9851 closed by jnoller #9865: OrderedDict doesn't implement __sizeof__ http://bugs.python.org/issue9865 closed by rhettinger #9868: test_locale leaves locale changed http://bugs.python.org/issue9868 closed by ocean-city #9875: Garbage output when running setup.py on Windows http://bugs.python.org/issue9875 closed by eric.araujo #9887: distutil's build_scripts doesn't read utf-8 in all locales http://bugs.python.org/issue9887 closed by eric.araujo #9888: int overflow in datetime causes seg fault from datetime.ctime( http://bugs.python.org/issue9888 closed by amaury.forgeotdarc #9892: Event spends less time in wait() than requested http://bugs.python.org/issue9892 closed by pitrou #9894: wrong errno check http://bugs.python.org/issue9894 closed by pitrou #9895: Speed up test_subprocess http://bugs.python.org/issue9895 closed by pitrou #9898: cProfile.runctx doesn't allow sort argument http://bugs.python.org/issue9898 closed by amaury.forgeotdarc #9899: tkinter test_font fails on OS X with Aqua Tk http://bugs.python.org/issue9899 closed by pitrou #9900: Threading Bug or misuse of the api ? http://bugs.python.org/issue9900 closed by Rob.Watson #9901: GIL destruction can fail http://bugs.python.org/issue9901 closed by pitrou #9902: test_undecodable_env failure http://bugs.python.org/issue9902 closed by pitrou #9906: including elementary mathematical functions in default types http://bugs.python.org/issue9906 closed by rhettinger #9908: os.stat() fails on bytes paths under Windows 7 http://bugs.python.org/issue9908 closed by pitrou #9911: doc copyedits http://bugs.python.org/issue9911 closed by georg.brandl #9916: errno module is missing some symbols http://bugs.python.org/issue9916 closed by barry #9918: Installation "make test", two fails if non-ascii path http://bugs.python.org/issue9918 closed by pitrou #9928: weird oddity with bz2 context manager http://bugs.python.org/issue9928 closed by pitrou #9930: Incorrect semantics of __radd__ method for builtin types http://bugs.python.org/issue9930 closed by mark.dickinson #9932: List of sets initialization behavior problems http://bugs.python.org/issue9932 closed by eric.smith #9933: os module does not have the documented EX_NOTFOUND attribute http://bugs.python.org/issue9933 closed by georg.brandl #1672853: Error reading files larger than 4GB http://bugs.python.org/issue1672853 closed by amaury.forgeotdarc #1744752: Newline skipped in "for line in file" for huge file http://bugs.python.org/issue1744752 closed by rhettinger #1327971: HTTPResponse instance has no attribute 'fileno' http://bugs.python.org/issue1327971 closed by orsenthil #1633863: AIX: configure ignores $CC http://bugs.python.org/issue1633863 closed by pitrou #1729930: 2.5.1 latest svn fails test_curses and test_timeout http://bugs.python.org/issue1729930 closed by BreamoreBoy #1739789: Accelerate attr dict lookups http://bugs.python.org/issue1739789 closed by rhettinger #1752919: Exception in HTMLParser for special JavaScript code http://bugs.python.org/issue1752919 closed by BreamoreBoy #1451466: reading very large files http://bugs.python.org/issue1451466 closed by amaury.forgeotdarc #1730136: tkFont.__eq__ gives type error http://bugs.python.org/issue1730136 closed by amaury.forgeotdarc #1706323: Updated ASTVisitor Classes http://bugs.python.org/issue1706323 closed by amaury.forgeotdarc #1732367: Document the constants in the socket module http://bugs.python.org/issue1732367 closed by BreamoreBoy #1675951: Performance for small reads and fix seek problem http://bugs.python.org/issue1675951 closed by pitrou #1708652: Exact matching http://bugs.python.org/issue1708652 closed by rhettinger

7 15

← Newer
1
2
3
4
5
6
7
...
12
Older →

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

Python-Dev September 2010