Re: [Python-Dev] Python Bug Day in October
Éric Araujo wrote: Hi all, The Montreal-Python user group would like to host a bug day on October 27 (to be confirmed) at a partner university in Montreal. It would be cool to do a bug day on IRC like we used to (and in other physical locations if people want to!) to get new contributors and close bugs. What do you think? Sounds good to me. I'm currently gathering a list [1] of easy and easyish issues for the PyCon Finland sprint, because finding things to work on is (in my opinion) the hardest and most time consuming part of bug fixing. I'm going to organize the list in the same way the stdlib documentation [2] is split into sections, so there should be something to work on for everyone, regardless of their interest area. PyCon Finland is on October 22-23, and I expect most of the list remain unused, so maybe it could also be used in the bug day afterwards. What do you think? Petri [1] http://piratepad.net/pyconfi-sprint-issues [2] http://docs.python.org/dev/library/ ___ Python-Dev mailing list Python-Dev@python.org 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 Bug Day in October
Hi, Cool to see the positive response! I’m waiting for confirmation of our venue in Montreal and will follow-up on this list and update the wiki page. Petri, your lists of bugs will definitely be helpful. Thanks all! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3
Georg Brandl ge...@python.org wrote: * A C implementation of the decimal module, with up to 80x speedup for decimal-heavy applications Could you bump up the factor to 120x in the final announcement? There were a couple of performance improvements in the meantime, and this is what I'm consistently measuring now. Thanks, Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-09-21 - 2012-09-28) 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: open3754 (+23) closed 24106 (+61) total 27860 (+84) Open issues with patches: 1662 Issues opened (52) == #16000: test_curses should use unittest http://bugs.python.org/issue16000 opened by chris.jerdonek #16001: small ints: cache string representation http://bugs.python.org/issue16001 opened by haypo #16003: thread_PyThread_start_new_thread fails with a generic error http://bugs.python.org/issue16003 opened by kristjan.jonsson #16004: Add `make touch` to 2.7 Makefile http://bugs.python.org/issue16004 opened by chris.jerdonek #16005: smtplib.SMTP().sendmail() and rset() http://bugs.python.org/issue16005 opened by DDarko #16007: Improved Error message for failing re expressions http://bugs.python.org/issue16007 opened by lingster #16009: Json error messages could provide more information about the e http://bugs.python.org/issue16009 opened by Luka.Rahne #16011: in should be consistent with return value of __contains__ http://bugs.python.org/issue16011 opened by nparikh #16013: small csv reader bug http://bugs.python.org/issue16013 opened by arigo #16023: IDLE freezes on ^5 or ^6 (Un-)Tabify Region with OS X Cocoa Tk http://bugs.python.org/issue16023 opened by szellmeyer #16024: Doc cleanup regarding path=fd, dir_fd, follow_symlinks, etc http://bugs.python.org/issue16024 opened by larry #16025: Minor corrections to the zipfile documentation http://bugs.python.org/issue16025 opened by storchaka #16026: csv.DictReader argument names documented incorrectly http://bugs.python.org/issue16026 opened by petere #16027: pkgutil doesn't support frozen modules http://bugs.python.org/issue16027 opened by lemburg #16029: pickle.dumps(xrange(sys.maxsize)) produces xrange(0) http://bugs.python.org/issue16029 opened by akira #16030: xrange repr broken for large arguments http://bugs.python.org/issue16030 opened by mark.dickinson #16034: bz2 module appears slower in Python 3.x versus Python 2.x http://bugs.python.org/issue16034 opened by victorhooi #16036: simplify int() signature docs http://bugs.python.org/issue16036 opened by chris.jerdonek #16037: httplib: header parsing is not delimited http://bugs.python.org/issue16037 opened by christian.heimes #16038: ftplib: unlimited readline() from connection http://bugs.python.org/issue16038 opened by christian.heimes #16039: imaplib: unlimited readline() from connection http://bugs.python.org/issue16039 opened by christian.heimes #16040: nntplib: unlimited readline() from connection http://bugs.python.org/issue16040 opened by christian.heimes #16041: poplib: unlimited readline() from connection http://bugs.python.org/issue16041 opened by christian.heimes #16042: smtplib: unlimited readline() from connection http://bugs.python.org/issue16042 opened by christian.heimes #16043: xmlrpc: gzip_decode has unlimited read() http://bugs.python.org/issue16043 opened by christian.heimes #16044: xml.etree.ElementTree.Element: append method iterator param is http://bugs.python.org/issue16044 opened by kirpit #16045: add more unit tests for built-in int() http://bugs.python.org/issue16045 opened by chris.jerdonek #16047: Tools/freeze no longer works in Python 3 http://bugs.python.org/issue16047 opened by lemburg #16048: Tutorial-classes-remarks: replace paragragh http://bugs.python.org/issue16048 opened by terry.reedy #16049: Create abstract base classes by inheritance rather than a dire http://bugs.python.org/issue16049 opened by rhettinger #16050: ctypes: callback from C++ to Python fails with Illegal Instruc http://bugs.python.org/issue16050 opened by Opilki_Inside #16053: strict parameter is not documented in csv module http://bugs.python.org/issue16053 opened by storchaka #16055: incorrect error text for int(base=1000, x='1') http://bugs.python.org/issue16055 opened by chris.jerdonek #16056: shadowed test names in std lib regression tests http://bugs.python.org/issue16056 opened by xdegaye #16057: Subclasses of JSONEncoder should not be insturcted to call JSO http://bugs.python.org/issue16057 opened by Justin.Lebar #16058: ConfigParser no longer deepcopy compatible in 2.7 http://bugs.python.org/issue16058 opened by rbcollins #16059: Serialize MD5 computation-state and resume later http://bugs.python.org/issue16059 opened by Ye.Yuan #16061: performance regression in string replace for 3.3 http://bugs.python.org/issue16061 opened by BreamoreBoy #16062: Socket closed prematurely in httplib for https http://bugs.python.org/issue16062 opened by ABR #16063: HMAC trans_5C is a string, causing a TypeError http://bugs.python.org/issue16063 opened by Adam.Glenn #16065: Python/distutils setup.py: passing --prefix / makes --root ign http://bugs.python.org/issue16065 opened
Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3
On Fri, Sep 28, 2012 at 11:40 AM, Stefan Krah ste...@bytereef.org wrote: Georg Brandl ge...@python.org wrote: * A C implementation of the decimal module, with up to 80x speedup for decimal-heavy applications Could you bump up the factor to 120x in the final announcement? There were a couple of performance improvements in the meantime, and this is what I'm consistently measuring now. Is that based on Modules/_decimal/tests/bench.py or some other benchmark? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3
Brett Cannon br...@python.org wrote: Georg Brandl ge...@python.org wrote: * A C implementation of the decimal module, with up to 80x speedup for decimal-heavy applications Could you bump up the factor to 120x in the final announcement? There were a couple of performance improvements in the meantime, and this is what I'm consistently measuring now. Is that based on Modules/_decimal/tests/bench.py or some other benchmark? It's the pi benchmark from bench.py. This is what I'm typically getting on a Core 2 Duo 3.16 GHz: Precision: 9 decimal digits float: result: 3.1415926535897927 time: 0.113188s cdecimal: result: 3.14159265 time: 0.158313s decimal: result: 3.14159265 time: 18.671457s Precision: 19 decimal digits float: result: 3.1415926535897927 time: 0.112874s cdecimal: result: 3.141592653589793236 time: 0.348100s decimal: result: 3.141592653589793236 time: 43.241220s Stefan Krah ___ Python-Dev mailing list Python-Dev@python.org 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 Bug Day in October
On 09/28/2012 12:30 AM, Éric Araujo wrote: Hi all, The Montreal-Python user group would like to host a bug day on October 27 (to be confirmed) at a partner university in Montreal. It would be cool to do a bug day on IRC like we used to (and in other physical locations if people want to!) to get new contributors and close bugs. What do you think? Great idea, I'll talk to Łukasz Langa about possibilities to gather a group of Poles interested in this topic. Łukasz could be the leader of our group. Regards, Maciej ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Deprecating U open mode
Since Python 2.3 many open-like functions supports Universal line mode (PEP 278 [1]). Since 3.0 (and 2.6) PEP 3116 [2] suggests better alternative -- io.TextWrapper. In issue15204 [3] proposed to deprecate U mode in open-like functions. In fact I found only three places where U mode is mentioned in the standard library: * builtin open (io.open) (almost ignored); * fileinput (transparently passed to open); * zipfile (inefficient and inconsistent implementation). Is someone uses U mode and has objections? [1] http://www.python.org/dev/peps/pep-0278/ [2] http://www.python.org/dev/peps/pep-3116/ [3] http://bugs.python.org/issue15204 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3
On 29 September 2012 06:51, Paul Moore p.f.mo...@gmail.com wrote: Wow! I had no idea cdecimal was that close in speed to float. That's seriously impressive. If those numbers are similar in other benchmarks, would it be accurate and/or reasonable to include a statement along the lines of: comparable to float performance - usually no more than 3x for calculations within the range of numbers covered by float or is there not enough evidence to conclude that? Substitute suitable factor for 3x. Obviously ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3
On 29 September 2012 07:50, Tim Delaney timothy.c.dela...@gmail.com wrote: On 29 September 2012 06:51, Paul Moore p.f.mo...@gmail.com wrote: Wow! I had no idea cdecimal was that close in speed to float. That's seriously impressive. If those numbers are similar in other benchmarks, would it be accurate and/or reasonable to include a statement along the lines of: comparable to float performance - usually no more than 3x for calculations within the range of numbers covered by float or is there not enough evidence to conclude that? Substitute suitable factor for 3x. Obviously And I meant to say congratulations - that's a really impressive result. Oh-oh. The PSU (which does not exist) has found me. I must hi Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [RELEASED] Python 3.3.0 release candidate 3
On Fri, 28 Sep 2012 21:51:39 +0100 Paul Moore p.f.mo...@gmail.com wrote: On 28 September 2012 19:19, Stefan Krah ste...@bytereef.org wrote: Brett Cannon br...@python.org wrote: Georg Brandl ge...@python.org wrote: * A C implementation of the decimal module, with up to 80x speedup for decimal-heavy applications Could you bump up the factor to 120x in the final announcement? There were a couple of performance improvements in the meantime, and this is what I'm consistently measuring now. Is that based on Modules/_decimal/tests/bench.py or some other benchmark? It's the pi benchmark from bench.py. This is what I'm typically getting on a Core 2 Duo 3.16 GHz: Precision: 9 decimal digits float: result: 3.1415926535897927 time: 0.113188s cdecimal: result: 3.14159265 time: 0.158313s decimal: result: 3.14159265 time: 18.671457s Precision: 19 decimal digits float: result: 3.1415926535897927 time: 0.112874s cdecimal: result: 3.141592653589793236 time: 0.348100s decimal: result: 3.141592653589793236 time: 43.241220s Wow! I had no idea cdecimal was that close in speed to float. That's seriously impressive. I think this means the performance difference is on the same order of magnitude as the CPython interpretation overhead. Still, it's impressive indeed. Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Deprecating U open mode
On Sat, 29 Sep 2012 00:48:54 +0300 Serhiy Storchaka storch...@gmail.com wrote: Since Python 2.3 many open-like functions supports Universal line mode (PEP 278 [1]). Since 3.0 (and 2.6) PEP 3116 [2] suggests better alternative -- io.TextWrapper. In issue15204 [3] proposed to deprecate U mode in open-like functions. In fact I found only three places where U mode is mentioned in the standard library: * builtin open (io.open) (almost ignored); * fileinput (transparently passed to open); * zipfile (inefficient and inconsistent implementation). I'm ok on the principle, I just think we should minimize disruption (I don't think the U mode adds a lot of complexity to the code). Regards Antoine. -- Software development and contracting: http://pro.pitrou.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] str.format bug again
There's a patch for this bug: http://bugs.python.org/issue12014 that needs reviewed. Petri Lehtinen made some (very minor) comments back in May; otherwise it's been neglected. I've brought this up occasionally here in the past; it would be great if someone could just give it a thumbs up or down (or say what needs to be changed, or whatever). -- Ben Wolfson Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure. [Larousse, Drink entry] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
