Re: [Python-Dev] To 3.0.2 or not to 3.0.2?
On Tue, Feb 17, 2009 at 00:50, Guido van Rossum <guido@python.org> wrote:
Can you explain the difficulty with porting setuptools in more detail?
Oh, it just exposes a bug in distutils. It probably means I'll have to make a test for python version, and if it is 3.0.1, monkey-patch distutils. I haven't really looked into if there is any other possibilities yet, I'm concentrating to make it run for 3.1 trunk first. -- Lennart Regebro: Pythonista, Barista, Notsotrista. http://regebro.wordpress.com/ +33 661 58 14 64
Le Tuesday 17 February 2009 08:52:20 Lennart Regebro, vous avez écrit :
On Tue, Feb 17, 2009 at 00:50, Guido van Rossum <guido@python.org> wrote:
Can you explain the difficulty with porting setuptools in more detail?
Oh, it just exposes a bug in distutils. It probably means I'll have to make a test for python version, and if it is 3.0.1, monkey-patch distutils. I haven't really looked into if there is any other possibilities yet, I'm concentrating to make it run for 3.1 trunk first.
That's funny, because the failing code does compare versions :-) ... File "c:\Python30\lib\distutils\cygwinccompiler.py", line 314, in __init__ if self.gcc_version <= "2.91.57": File "c:\Python30\lib\distutils\version.py", line 64, in __le__ c = self._cmp(other) File "c:\Python30\lib\distutils\version.py", line 341, in _cmp return cmp(self.version, other.version) NameError: global name 'cmp' is not defined -- Victor Stinner aka haypo http://www.haypocalc.com/blog/
Victor Stinner wrote:
Le Tuesday 17 February 2009 08:52:20 Lennart Regebro, vous avez écrit :
On Tue, Feb 17, 2009 at 00:50, Guido van Rossum <guido@python.org> wrote:
Can you explain the difficulty with porting setuptools in more detail?
Oh, it just exposes a bug in distutils. It probably means I'll have to make a test for python version, and if it is 3.0.1, monkey-patch distutils. I haven't really looked into if there is any other possibilities yet, I'm concentrating to make it run for 3.1 trunk first.
Didn't a test fail because of this? seems the underlying issue is that this part of the stdlib didn't have enough test coverage. It seems that having very good/improving test coverage like is recommended for 3rd-party project wanting to switch would be a good goal for 3.0 evolution too. We know from PyPy experience that while always improving the test suite coverage is quite spotty at times.
On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni <pedronis@openend.se> wrote:
Didn't a test fail because of this? seems the underlying issue is that this part of the stdlib didn't have enough test coverage. It seems that having very good/improving test coverage like is recommended for 3rd-party project wanting to switch would be a good goal for 3.0 evolution too. We know from PyPy experience that while always improving the test suite coverage is quite spotty at times.
No, a test didn't fail. Our new distutils maintainer, Tarek Ziade, though, has been increasing the distutils test coverage greatly. -- Regards, Benjamin
Benjamin Peterson schrieb:
On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni <pedronis@openend.se> wrote:
Didn't a test fail because of this? seems the underlying issue is that this part of the stdlib didn't have enough test coverage. It seems that having very good/improving test coverage like is recommended for 3rd-party project wanting to switch would be a good goal for 3.0 evolution too. We know from PyPy experience that while always improving the test suite coverage is quite spotty at times.
No, a test didn't fail. Our new distutils maintainer, Tarek Ziade, though, has been increasing the distutils test coverage greatly.
In addition to testing, this specific issue could have been found easily by running something like pylint over the stdlib, because undefined globals are one of the things they can detect with 100% accuracy... The hard thing about pylint of course is to get the signal/noise ratio right :) Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Tue, Feb 17, 2009 at 3:02 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Benjamin Peterson schrieb:
On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni <pedronis@openend.se> wrote:
Didn't a test fail because of this? seems the underlying issue is that this part of the stdlib didn't have enough test coverage. It seems that having very good/improving test coverage like is recommended for 3rd-party project wanting to switch would be a good goal for 3.0 evolution too. We know from PyPy experience that while always improving the test suite coverage is quite spotty at times.
No, a test didn't fail. Our new distutils maintainer, Tarek Ziade, though, has been increasing the distutils test coverage greatly.
In addition to testing, this specific issue could have been found easily by running something like pylint over the stdlib, because undefined globals are one of the things they can detect with 100% accuracy...
Oh, does pylint support py3k now?
The hard thing about pylint of course is to get the signal/noise ratio right :)
-- Regards, Benjamin
Benjamin Peterson schrieb:
On Tue, Feb 17, 2009 at 3:02 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Benjamin Peterson schrieb:
On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni <pedronis@openend.se> wrote:
Didn't a test fail because of this? seems the underlying issue is that this part of the stdlib didn't have enough test coverage. It seems that having very good/improving test coverage like is recommended for 3rd-party project wanting to switch would be a good goal for 3.0 evolution too. We know from PyPy experience that while always improving the test suite coverage is quite spotty at times.
No, a test didn't fail. Our new distutils maintainer, Tarek Ziade, though, has been increasing the distutils test coverage greatly.
In addition to testing, this specific issue could have been found easily by running something like pylint over the stdlib, because undefined globals are one of the things they can detect with 100% accuracy...
Oh, does pylint support py3k now?
I think you may have a point there, though I honestly don't know. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
Georg Brandl wrote:
Benjamin Peterson schrieb:
Oh, does pylint support py3k now?
I think you may have a point there, though I honestly don't know.
I think it's a useful point in general - keeping something like pylint or pychecker running correctly against the CPython trunk could be a frustrating exercise on those occasions when we do change something that the static checker then chokes on (mainly thinking syntax changes here - they're obviously by far the minority of changes, but they do happen). Perhaps I'm being overly pessimistic, but my suspicion is that it would end up being tantamount to bringing whichever tool we decided to use into the standard library just to keep our own source tree passing cleanly. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
On Wed, Feb 18, 2009 at 3:06 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
Georg Brandl wrote:
Benjamin Peterson schrieb:
Oh, does pylint support py3k now?
I think you may have a point there, though I honestly don't know.
I think it's a useful point in general - keeping something like pylint or pychecker running correctly against the CPython trunk could be a frustrating exercise on those occasions when we do change something that the static checker then chokes on (mainly thinking syntax changes here - they're obviously by far the minority of changes, but they do happen).
Perhaps I'm being overly pessimistic, but my suspicion is that it would end up being tantamount to bringing whichever tool we decided to use into the standard library just to keep our own source tree passing cleanly.
This prompts a wild idea -- perhaps the framework of 2to3 could be reused to create a new linter? -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Feb 18, 2009 at 9:30 AM, Guido van Rossum <guido@python.org> wrote:
This prompts a wild idea -- perhaps the framework of 2to3 could be reused to create a new linter?
The 2to3 syntax tree is probably two low-level for that. It's good for simple isolated transformations like print, but not so much for the larger scale analysis that a lint tool would require. In addition, we'd have to write some sort of symtable analyzer. High level AST is much nicer to work with that. -- Regards, Benjamin
Le Wednesday 18 February 2009 20:48:17 Benjamin Peterson, vous avez écrit :
On Wed, Feb 18, 2009 at 9:30 AM, Guido van Rossum <guido@python.org> wrote:
This prompts a wild idea -- perhaps the framework of 2to3 could be reused to create a new linter?
The 2to3 syntax tree is probably two low-level for that. It's good for simple isolated transformations like print, but not so much for the larger scale analysis that a lint tool would require. In addition, we'd have to write some sort of symtable analyzer. High level AST is much nicer to work with that.
FYI, we (logilab) are curently working on providing a compatibility layer between _ast and compiler to get pylint working on py3k, py >= 2.6 and py <= 2.5. There are some tree structure incompatibility between them which makes the thing not trivial but I hope we'll get somewhere soon. Of course any help is welcome :) -- Sylvain Thénault LOGILAB, Paris (France) Formations Python, Zope, Plone, Debian: http://www.logilab.fr/formations Développement logiciel sur mesure: http://www.logilab.fr/services Python et calcul scientifique: http://www.logilab.fr/science
2009/2/17 Georg Brandl <g.brandl@gmx.net>:
Benjamin Peterson schrieb:
On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni <pedronis@openend.se> wrote:
Didn't a test fail because of this? seems the underlying issue is that this part of the stdlib didn't have enough test coverage. It seems that having very good/improving test coverage like is recommended for 3rd-party project wanting to switch would be a good goal for 3.0 evolution too. We know from PyPy experience that while always improving the test suite coverage is quite spotty at times.
No, a test didn't fail. Our new distutils maintainer, Tarek Ziade, though, has been increasing the distutils test coverage greatly.
I'll add one in that area. Note that I am also planning to: - remove in the current trunk things like cmp() so the code looks similar in trunk and py3k -> so if you change something in py3k branch in distutils, if you have time please backport it to the trunk right away when appliable - release Distutils at PyPI on its own, (stable releases, and dev releases) following Marc-André suggestion. this will use externals, (see http://svn.python.org/projects/distutils/trunk/) So it should be simpler to work things out between two Python releases Regards Tarek
this will use externals, (see http://svn.python.org/projects/distutils/trunk/)
This I don't understand. There is file named EXTERNALS.txt, but I don't understand its purpose. Regards, Martin
2009/2/18 "Martin v. Löwis" <martin@v.loewis.de>:
this will use externals, (see http://svn.python.org/projects/distutils/trunk/)
This I don't understand. There is file named EXTERNALS.txt, but I don't understand its purpose.
This is how I work with externals. This file is used to store the svn:externals property and have it in a clear human readable text filethat can be seen in any svn viewer. If I need to change the externals I change this file and do: $ svn propset svn:externals -F EXTERNALS.txt $ svn ci . EXTERNALS.txt -m "comment" then, if you do a checkout of http://svn.python.org/projects/distutils/trunk it will grab Python's Lib/distutils. Let me know if this is not wanted. I can drop it it's no big deal. Regards Tarek
Regards, Martin
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
participants (10)
-
"Martin v. Löwis" -
Benjamin Peterson -
Georg Brandl -
Guido van Rossum -
Lennart Regebro -
Nick Coghlan -
Samuele Pedroni -
Sylvain Thénault -
Tarek Ziadé -
Victor Stinner