Re: [Python-Dev] lifting of prohibition against readlines inside a "for line in file" in Py3?
On Wed, Feb 18, 2009 at 6:38 PM, wrote: > On Wed, 18 Feb 2009 at 21:25, Antoine Pitrou wrote: >> >> Nick Coghlan gmail.com> writes: >>> >>> I *think* the 2.x system had an internal buffer that was used by the >>> file iterator, but not by the file methods. With the new IO stack for >>> 3.0, there is now a common buffer shared by all the file operations >>> (including iteration). >>> >>> However, given that the lifting of the restriction is currently >>> undocumented, I wouldn't want to see a commitment to keeping it lifted >>> until we know that it won't cause any problems for the io-in-c rewrite >>> for 3.1 (hopefully someone with more direct involvement with that >>> rewrite will chime in, since they'll know a lot more about it than I do). >> >> As you said, there is no special buffering for the file iterator in 3.x, >> which >> means the restriction could be lifted (actually there is nothing relying >> on this >> restriction in the current code, except perhaps the "telling" flag in >> TextIOWrapper). > > Currently I have python (2.x) code that uses 'readline' instead of 'for > x in myfile' in order to avoid the 'for' buffering (ie: be presented > with the next line as soon as it is written to the other end of a pipe, > instead of waiting for the buffer to fill). Does "no special buffering" > mean that 'for' doesn't use a read-ahead buffer in p3k, or that readline > does use such a buffer, because the latter could make my code break > unexpectedly when porting to p3k. Have a look at the code in io.py (class TextIOWrapper): http://svn.python.org/view/python/branches/py3k/Lib/io.py?view=log I believe it doesn't force reading ahead more than necessary. If a single low-level read() returns enough data to satisfy the __next__() or readline() (or it can be satisfied from data already buffered) then it won't force reading more. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ 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] lifting of prohibition against readlines inside a "for line in file" in Py3?
On Wed, 18 Feb 2009 at 21:25, Antoine Pitrou wrote: Nick Coghlan gmail.com> writes: I *think* the 2.x system had an internal buffer that was used by the file iterator, but not by the file methods. With the new IO stack for 3.0, there is now a common buffer shared by all the file operations (including iteration). However, given that the lifting of the restriction is currently undocumented, I wouldn't want to see a commitment to keeping it lifted until we know that it won't cause any problems for the io-in-c rewrite for 3.1 (hopefully someone with more direct involvement with that rewrite will chime in, since they'll know a lot more about it than I do). As you said, there is no special buffering for the file iterator in 3.x, which means the restriction could be lifted (actually there is nothing relying on this restriction in the current code, except perhaps the "telling" flag in TextIOWrapper). Currently I have python (2.x) code that uses 'readline' instead of 'for x in myfile' in order to avoid the 'for' buffering (ie: be presented with the next line as soon as it is written to the other end of a pipe, instead of waiting for the buffer to fill). Does "no special buffering" mean that 'for' doesn't use a read-ahead buffer in p3k, or that readline does use such a buffer, because the latter could make my code break unexpectedly when porting to p3k. --RDM ___ 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] [Tracker-discuss] Tracker cleanup roadmap
Hi there, this is just a little note / reminder to try to submit Roundup patches and enhancements that you may have accumulated while working on the bugs.python.org tracker. A couple of weeks ago I moved the Roundup project's own tracker close to where bugs.python.org is hosted, and am now actively developing Roundup again (at least for a while). So this is a good time to get in touch to merge things upstream. :-) (See http://www.roundup-tracker.org.) Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin... ___ 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] a nicer looking dir()
Someone has implemented a version of dir() which is much nicer for human consumption. The difference is striking enough that I thought it would be bringing to python-dev's attention. http://github.com/inky/see/tree/master >>> pencil_case = [] >>> dir(pencil_case) ['__add__', '__class__', '__contains__', '__delattr__', '__delitem__', '__delsli ce__', '__doc__', '__eq__', '__ge__', '__getattribute__', '__getitem__', '__gets lice__', '__gt__', '__hash__', '__iadd__', '__imul__', '__init__', '__iter__', ' __le__', '__len__', '__lt__', '__mul__', '__ne__', '__new__', '__reduce__', '__r educe_ex__', '__repr__', '__reversed__', '__rmul__', '__setattr__', '__setitem__ ', '__setslice__', '__str__', 'append', 'count', 'extend', 'index', 'insert', 'p op', 'remove', 'reverse', 'sort'] >>> see(pencil_case) ? [] for in + * += *= < <= == != > >= len() .append() .count() .extend() .index() .insert() .pop() .remove() .reverse() .sort() I'm not sure that this type of functionality merits a new built-in, but it might be useful as part of help()'s output. -Mike ___ 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] Duck-typing self
Christian Heimes wrote: In 2.x a class objects wrap their functions in a method wrapper. The method wrapper does the type check. You can get around the type check by using the im_func attribute of the method wrapper. You could probably also create a decorator that gives you something behaving like an unbound method but without the type check (implementation details left to the reader). -- Greg ___ 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] Duck-typing self
Sebastian Rittau wrote: Is it a design decision that duck-typing self does not work or is there a technical reason? There's no technical reason as far as user-defined classes are concerned. I think it was introduced to help catch errors due to making inherited method calls to the wrong class, which can easily happen if you change the base class of a class and forget to update all of the inherited calls to match. I believe this type check has been removed in 3.0, so duck-typing of self is possible there. -- Greg ___ 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] Duck-typing self
Steven Bethard wrote: >> Is it a design decision that duck-typing self does not work or is there a >> technical reason? From a practical standpoint it seems that being able to >> duck-type self has merit, for example in unit testing complex classes. > > Works for me in 3.0: It works in 3.0 because we have lifted some restrictions (and increased speed as a neat side effect). In Python 2.x the type checking speed with negligible, but Python 3's abc system with the new __instancecheck__() and __subclasscheck__() hooks are a real speed drain. In 2.x a class objects wrap their functions in a method wrapper. The method wrapper does the type check. You can get around the type check by using the im_func attribute of the method wrapper. Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Foo(object): ... def bar(self): ... print(self.attr) ... >>> Foo.bar >>> class Duck(object): ... attr = "python" ... >>> Foo.bar(Duck()) Traceback (most recent call last): File "", line 1, in TypeError: unbound method bar() must be called with Foo instance as first argument (got Duck instance instead) >>> Foo.bar.im_func >>> Foo.bar.im_func(Duck()) python In 3.0 the unbound method wrapper is gone and class objects return the pure function. Without the type checking of the unbound method wrapper the restriction is gone. Python 3.0.1 (r301:69655, Feb 15 2009, 23:28:13) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> class Foo(object): ... def bar(self): ... print(self.attr) ... >>> Foo.bar >>> class Duck(object): ... attr = "python" ... >>> Foo.bar(Duck()) python HTH Christian ___ 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] Duck-typing self
On Wed, Feb 18, 2009 at 2:32 PM, Sebastian Rittau wrote: > Hi! > > I am curious why the following will not work in Python: > > class foo(object): > def bar(self): > print self.attr > > class duck(object): > attr = 3.14 > > foo.bar(duck()) > > Is it a design decision that duck-typing self does not work or is there a > technical reason? From a practical standpoint it seems that being able to > duck-type self has merit, for example in unit testing complex classes. Works for me in 3.0: Python 3.1a0 (py3k:69082, Jan 28 2009, 19:22:10) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class Foo(object): ... def bar(self): ... print(self.attr) ... >>> class Duck(object): ... attr = 3.14 ... >>> Foo.bar(Duck()) 3.14 Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ 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] Duck-typing self
Hi! I am curious why the following will not work in Python: class foo(object): def bar(self): print self.attr class duck(object): attr = 3.14 foo.bar(duck()) Is it a design decision that duck-typing self does not work or is there a technical reason? From a practical standpoint it seems that being able to duck-type self has merit, for example in unit testing complex classes. - Sebastian ___ 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] Tracker cleanup roadmap
Hi Venkatraman, Venkatraman S wrote: > > On Tue, Feb 17, 2009 at 1:45 PM, "Martin v. Löwis" wrote: >> >> Don't expect too much >> help from other people - I have been waiting for volunteers to show up >> helping with the tracker for more than a year now. > > I have been mostly a silent spectator around and would like to chip in. Great! Thanks for joining us :) What would you like to help with? Anyway, let's move this thread to tracker-discuss :) > Need some initial throttle(help) for the full-fledged attack :) Well, I'm currently updating the TrackerDevelopment[1] article and trying to make the initial setup easier. These should help a bit, but I'd be glad to (try to) answer any questions you have. Please let me know (or mail tracker-discuss[2]) if something on the guide isn't clear (you can, of course, edit it directly). "Martin v. Löwis" wrote: > Please take a look at the meta tracker. It has various open issues, many > open for many months now. Please tackle one that can be fixed through > patches to the tracker instance preferably; changes to roundup are also > acceptable in principle. Agreed, if you want to get to know the code and at the same time work on something useful, taking a look at the meta tracker[3] is a great first step. Welcome aboard! Daniel [1] http://wiki.python.org/moin/TrackerDevelopment [2] http://mail.python.org/mailman/listinfo/tracker-discuss [3] http://psf.upfronthosting.co.za/roundup/meta/ :) ___ 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] To 3.0.2 or not to 3.0.2?
> Let me know if this is not wanted. I can drop it it's no big deal. That is fine with me. I was worried that you might have made Lib/distutils external, which I would not have liked. Regards, Martin ___ 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] To 3.0.2 or not to 3.0.2?
2009/2/18 "Martin v. Löwis" : >> 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/ ___ 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] To 3.0.2 or not to 3.0.2?
> 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 ___ 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] Tracker cleanup roadmap
> I have been mostly a silent spectator around and would like to chip in. > Need some initial throttle(help) for the full-fledged attack :) Please take a look at the meta tracker. It has various open issues, many open for many months now. Please tackle one that can be fixed through patches to the tracker instance preferably; changes to roundup are also acceptable in principle. If some changes require some admin activity, discuss on tracker-discuss what actions would be required. Regards, Martin ___ 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] lifting of prohibition against readlines inside a "for line in file" in Py3?
Mitchell L Model wrote: In Digest Vol. 67, Issue 52 (13 Feb 2009) I pointed out that Python 2's prohibition against performing readlines on a file being iterated over appears to have been lifted in Python 3. I asked if this was intentional and whether it should be add to the "What's New" documentation. I also expressed muy surprise that "for line in fil"'s can be nested using the same fil in both Python 2 and 3. I presented an example for each point and some and further comments. If I understand, you are asking whether the new behavior is an undocumented new feature that you can use or an error that may be reverted. It is possible that it is an accident and there is no answer yet decided. I suspect your original query got lost in the shuffle. If you do not get an answer this time, file an issue on the tracker bugs.python.org but do not select whether it is a behavior or doc issue. At least, it will stay open until resolved. tjr ___ 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] lifting of prohibition against readlines inside a "for line in file" in Py3?
Hello, Nick Coghlan gmail.com> writes: > > I *think* the 2.x system had an internal buffer that was used by the > file iterator, but not by the file methods. With the new IO stack for > 3.0, there is now a common buffer shared by all the file operations > (including iteration). > > However, given that the lifting of the restriction is currently > undocumented, I wouldn't want to see a commitment to keeping it lifted > until we know that it won't cause any problems for the io-in-c rewrite > for 3.1 (hopefully someone with more direct involvement with that > rewrite will chime in, since they'll know a lot more about it than I do). As you said, there is no special buffering for the file iterator in 3.x, which means the restriction could be lifted (actually there is nothing relying on this restriction in the current code, except perhaps the "telling" flag in TextIOWrapper). Regards Antoine. ___ 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] lifting of prohibition against readlines inside a "for line in file" in Py3?
Mitchell L Model wrote: > I didn't get any response. Is this the wrong list for the question? Did > appropriate responders assume another would respond? Probably the latter (I know I left it to those that had more to do with the IO stack rewrite). This is definitely the right list for the question. > I want to reraise > this because lifting of that prohibition is a quite significant change > in the behavior from Python 2. Even if it ws a bug in Python 2, or the > side effect of other changes in Python 3, it should at least be > documented prominently. True, no-one's code will be affected by lifting > a prohibition against something their code couldn't have done, but the > new behavior offers significant flexibility in writing "for line in fil" > iterations in that it allows recognizing the beginning of a sequence of > lines that should be considered a unified "chunk" and allows the loop to > do readlines to handle the rest of the chunk. Some of these can be > handled by just nesting a second "for line in fil" inside a conditional > inside the outer iteration but some are better handled by individual > readlines. > > I'd appreciate comments -- especially a redirection to a different list, > if this one isn't appropriate for my query. I *think* the 2.x system had an internal buffer that was used by the file iterator, but not by the file methods. With the new IO stack for 3.0, there is now a common buffer shared by all the file operations (including iteration). However, given that the lifting of the restriction is currently undocumented, I wouldn't want to see a commitment to keeping it lifted until we know that it won't cause any problems for the io-in-c rewrite for 3.1 (hopefully someone with more direct involvement with that rewrite will chime in, since they'll know a lot more about it than I do). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] To 3.0.2 or not to 3.0.2?
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 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 ___ 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] To 3.0.2 or not to 3.0.2?
On Wed, Feb 18, 2009 at 9:30 AM, Guido van Rossum 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 ___ 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] lifting of prohibition against readlines inside a "for line in file" in Py3?
On Wed, Feb 18, 2009 at 12:42 PM, Mitchell L Model wrote: > I'd appreciate comments -- especially a redirection to a different list, if > this one isn't appropriate for my query. It seems as though you have the right list, but perhaps whoever knows about the change is busy, or maybe several people that don't know about the change are trying to find it. If there's something in particular that you need answered in a specific timeframe, I don't know what to tell you, but if it's like it seems, and you're just raising the issue, I think you can trust that someone will get to it eventually. -- Cheers, Leif ___ 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] lifting of prohibition against readlines inside a "for line in file" in Py3?
In Digest Vol. 67, Issue 52 (13 Feb 2009) I pointed out that Python 2's prohibition against performing readlines on a file being iterated over appears to have been lifted in Python 3. I asked if this was intentional and whether it should be add to the "What's New" documentation. I also expressed muy surprise that "for line in fil"'s can be nested using the same fil in both Python 2 and 3. I presented an example for each point and some and further comments. I didn't get any response. Is this the wrong list for the question? Did appropriate responders assume another would respond? I want to reraise this because lifting of that prohibition is a quite significant change in the behavior from Python 2. Even if it ws a bug in Python 2, or the side effect of other changes in Python 3, it should at least be documented prominently. True, no-one's code will be affected by lifting a prohibition against something their code couldn't have done, but the new behavior offers significant flexibility in writing "for line in fil" iterations in that it allows recognizing the beginning of a sequence of lines that should be considered a unified "chunk" and allows the loop to do readlines to handle the rest of the chunk. Some of these can be handled by just nesting a second "for line in fil" inside a conditional inside the outer iteration but some are better handled by individual readlines. I'd appreciate comments -- especially a redirection to a different list, if this one isn't appropriate for my query. ___ 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] To 3.0.2 or not to 3.0.2?
2009/2/17 Georg Brandl : > Benjamin Peterson schrieb: >> On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni 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 ___ 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] To 3.0.2 or not to 3.0.2?
On Wed, Feb 18, 2009 at 3:06 AM, Nick Coghlan 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/) ___ 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 2.6.2 and 3.0.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 18, 2009, at 1:49 AM, Brett Cannon wrote: If there are really enough fixes to warrant it, sure. Otherwise would it be worth more to just wait until after PyCon where there is a bigger chance of fixed issues? Good point. Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSZvw6nEjvBPtnXfVAQLIegP/evDYDpH981WjgjPJJbY6Up2NRHAAScM6 V8l1CZbQxjqjokz3xRi8X65nn7Qx8acWN51wn5tG3u9YmCDci4u3Geu0NtV5uEOK 7aZ4WxkGGXUTPaeVS1NCPo37UPN/px24TpYLvIy0v6ngv7EzL5lIsBLS7V8lsh4v qzi3LuhbV0o= =CaLE -END PGP SIGNATURE- ___ 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] To 3.0.2 or not to 3.0.2?
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 | ncogh...@gmail.com | Brisbane, Australia --- ___ 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] To 3.0.2 or not to 3.0.2?
Benjamin Peterson schrieb: > On Tue, Feb 17, 2009 at 3:02 PM, Georg Brandl wrote: >> Benjamin Peterson schrieb: >>> On Tue, Feb 17, 2009 at 5:25 AM, Samuele Pedroni >>> 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. ___ 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] Tracker cleanup roadmap
On Tue, Feb 17, 2009 at 1:45 PM, "Martin v. Löwis" wrote: > Don't expect too much > help from other people - I have been waiting for volunteers to show up > helping with the tracker for more than a year now. > I have been mostly a silent spectator around and would like to chip in. Need some initial throttle(help) for the full-fledged attack :) -V- ___ 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
