Mailman 3 February 2009 - Python-Dev

To 3.0.2 or not to 3.0.2?
by Lennart Regebro Feb. 17, 2009

Feb. 17, 2009

I discovered some remaining cmp() in 3.0.1, 38 minutes after Benjamin fixed them. :) Unfortunately, that means porting setuptools to 3.0.1 will be a bit difficult. So my question is: Will there be a 3.0.2 with those fixes, or should I add workaround code for 3.0.1? -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64

2 1

Anyone want to lead the sprints at PyCon this year?
by Brett Cannon Feb. 17, 2009

Feb. 17, 2009

Or am I doing it again as usual because I was stupid enough to ask this question? -Brett

1 0

Re: [Python-Dev] To 3.0.2 or not to 3.0.2?
by Benjamin Peterson Feb. 17, 2009

Feb. 17, 2009

On Mon, Feb 16, 2009 at 5:50 PM, Guido van Rossum <guido(a)python.org> wrote: > Can you explain the difficulty with porting setuptools in more detail? Basically setuptools invokes a functions in distutils that was still using cmp(). (See the latest messages in issue #1717 for all the details.) -- Regards, Benjamin

1 0

Re: [Python-Dev] To 3.0.2 or not to 3.0.2?
by Guido van Rossum Feb. 17, 2009

Feb. 17, 2009

[Resend, hopefully bag.python.org is fixed now.[ Can you explain the difficulty with porting setuptools in more detail? On Mon, Feb 16, 2009 at 11:08 AM, Lennart Regebro <regebro(a)gmail.com> wrote: > I discovered some remaining cmp() in 3.0.1, 38 minutes after Benjamin > fixed them. :) Unfortunately, that means porting setuptools to 3.0.1 > will be a bit difficult. So my question is: Will there be a 3.0.2 with > those fixes, or should I add workaround code for 3.0.1? -- --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Adding T_SIZET to structmember.h
by Lisandro Dalcin Feb. 16, 2009

Feb. 16, 2009

After a rather long hacking on Cython in order to support 'Py_ssize_t' and 'size_t' the right way, I would like to propose the inclusion of a new T_SIZET in structmember.h in order to suport 'size_t' struct fields with PyMemberDef. Would such addition be accepted for 2.7 and 3.1? -- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594

3 5

Buildbots for 2.6 and 3.0
by Antoine Pitrou Feb. 16, 2009

Feb. 16, 2009

Hello people, Looking at http://www.python.org/dev/buildbot/, we are still missing buildbots for the release26-maint and release30-maint branches. Is someone working on that? Regards Antoine.

5 4

Mark old distutils as deprecated
by Tarek Ziadé Feb. 16, 2009

Feb. 16, 2009

Hello To avoid confusion, as suggested by Akira who works on cleaning the Distutils pages on the python.org website, I would like to move http://svn.python.org/view/distutils/trunk into a branch and add a README.txt in an empty trunk to explain the current status of the package. Any objection ? Regards, Tarek -- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/

3 4

No 2.x->3.x porting documentation?
by skip＠pobox.com Feb. 16, 2009

Feb. 16, 2009

I apologize if this has been discussed here or elsewhere already. I'm offline as I write this so my only source of guidance is what I find in my Subversion checkouts. I'm making a naive stab at converting nose to Python3 so I can hopefully run the lockfile test cases under Python 3. (Again, I'm offline and have no idea at this point if it's been done already.) I ran 2to3 then tried installing. I got an immediate error about the compiler.consts module being missing. (All nose does is import CO_GENERATOR from compiler.consts.) I found that in the inspect module. Then it complained about ClassType being missing from the types module. I found no mention of changes to the types module in Misc/NEWS or Doc/whatsnew/3.0.rst. I didn't find anything which looked like a "porting" document. If neither of these changes could be handled by 2to3 I think it would have been useful to at least document the changes (in whatsnew/3.0.rst?) and maybe offer humans some workaround ideas. If there is a wiki page collecting porting wisdom it should be referenced. If I'm missing something fundamental about how people are expected to approach porting 2.x code to 3.x, please let me know. Thanks, Skip

4 3

Re: [Python-Dev] .Idle.py init file
by Daniel (ajax) Diniz Feb. 15, 2009

Feb. 15, 2009

Mitchell, I can't find the string ".Idle.py" in trunk. If you haven't already, please open a documentation issue for this one. I don't see any obvious downside to this behavior and people might be relying on it by now. Thanks for reporting these IDLE issues! Daniel

1 0

smtplib violates SMTP spec
by Felix Schwarz Feb. 15, 2009

Feb. 15, 2009

Hi, I would like to get attention to issue 4142 [1] which was filed several months ago. This is about a clear bug in smtplib's SMTP implementation which is probably present since (at least) Python 1.5. When re-using an smtplib.SMTP instance for a second connection, smtplib does not send another HELO/EHLO which is a clear violation of the SMTP specification. I built a small patch (changes only 2 lines) but I'm unable to write a unit test for this easily because: * Python's smtpd does not check if HELO/EHLO was received before MAIL FROM * Therefore any extension of test_smtplib would need some patches to check this also. However, the patch is very small so it is very easy to test this manually. Just connect to a real world smtp (Exim is best because it is quite strict when it comes to SMTP verbs). fs [1] http://bugs.python.org/issue4142

2 1