Re: [Python-Dev] rationale for the no-new-features approach
On Fri, Mar 11, 2005 at 06:47:11PM -0500, Bob Ippolito wrote: On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote: Bob try: Bob set Bob except NameError: Bob from sets import Set as set Bob You don't need the rest. Sure, but then pychecker bitches about a statement that appears to have no effect. ;-) Well then fix PyChecker to look for this pattern :) -bob or make it even uglier to hide from pychecker by writing that as: exec( try: set except NameError: from sets import Set as set ) ___ 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] rationale for the no-new-features approach
[Bob Ippolito] try: set except NameError: from sets import Set as set You don't need the rest. [Skip Montanaro] Sure, but then pychecker bitches about a statement that appears to have no effect. ;-) [Bob Ippolito] Well then fix PyChecker to look for this pattern :) +1. [Gregory P. Smith] or make it even uglier to hide from pychecker by writing that as: exec( try: set except NameError: from sets import Set as set ) I presume that was somewhat tongue-in-cheek, but if it wasn't, please reconsider. Modulefinder isn't able to realise that set (or sets.Set) is needed with the latter (a problem of this very nature was just fixed with bsddb), which causes trouble for people later on. =Tony.Meyer ___ 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] rationale for the no-new-features approach
[Gregory P. Smith] or make it even uglier to hide from pychecker by writing that as: exec( try: set except NameError: from sets import Set as set ) I presume that was somewhat tongue-in-cheek, but if it wasn't, please reconsider. Modulefinder isn't able to realise that set (or sets.Set) is needed with the latter (a problem of this very nature was just fixed with bsddb), which causes trouble for people later on. =Tony.Meyer hehe yes sorry, i left off the :P ___ 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] rationale for the no-new-features approach
On Thu, 2005-03-10 at 23:46, Glyph Lefkowitz wrote: That way instead of multi-line except NameError tests all over the place you can simply have one-liner boilerplate for every module in your project: 'from py24compat import *' Easy to grep/sed for when you're ready to stop supporting old versions, too, for those of you without a copy of the refactoring editor from the 2009 release of PyDev/Eclipse. I do something very similar, both for Mailman and for the commercial products I'm working on. There are lots of ways to handle this kind of thing, and there might be some value in a community effort to work together and standardize this. IWBNI there were some common idioms and packages that people could use. Having said that... The only problem with this idea is that the 2.3 - 2.4 transition has been extremely smooth for me - there are no new features I desperately want to use, and there are no old features that were deprecated or altered (that I've found yet - knock on wood). Still, future incompatibilties are inevitable. ...I agree. We just upgraded to 2.4 internally and it went embarrassingly smoothly. Had to find something else to do with the four days (cough - warsaw's first law - cough) we'd scheduled for that. -Barry signature.asc Description: This is a digitally signed message part ___ 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] rationale for the no-new-features approach
Bob try: Bob set Bob except NameError: Bob from sets import Set as set Bob You don't need the rest. Sure, but then pychecker bitches about a statement that appears to have no effect. ;-) Skip ___ 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] rationale for the no-new-features approach
On Mar 11, 2005, at 2:26 PM, Skip Montanaro wrote: Bob try: Bob set Bob except NameError: Bob from sets import Set as set Bob You don't need the rest. Sure, but then pychecker bitches about a statement that appears to have no effect. ;-) Well then fix PyChecker to look for this pattern :) -bob ___ 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] rationale for the no-new-features approach
Anthony Goal 4: Try and prevent something like Anthony try: Anthony True, False Anthony except NameError: Anthony True, False = 1, 0 Anthony from ever ever happening again. I will point out that in the transition from 2.3 to 2.4 our code that uses sets has try: x = set except NameError: from sets import Set as set else: del x Rather ugly. I suppose I could just put the necessary incantation in sitecustomize to dump the set name in builtins, but it would be kinda nice if this sort of thing could be avoided in the future. Skip ___ 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] rationale for the no-new-features approach
On Mar 9, 2005, at 8:03 AM, Skip Montanaro wrote: Anthony Goal 4: Try and prevent something like Anthony try: Anthony True, False Anthony except NameError: Anthony True, False = 1, 0 Anthony from ever ever happening again. I will point out that in the transition from 2.3 to 2.4 our code that uses sets has try: x = set except NameError: from sets import Set as set else: del x Rather ugly. I suppose I could just put the necessary incantation in sitecustomize to dump the set name in builtins, but it would be kinda nice if this sort of thing could be avoided in the future. try: set except NameError: from sets import Set as set You don't need the rest. -bob ___ 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] rationale for the no-new-features approach
On Wed, 2005-03-09 at 07:17, Anthony Baxter wrote: So it's only fair that I write down my rationale for why I'm being anal about the no-new-features approach. Comments are more than welcome - ideally, after discussion, I'll put some more words in the bugfix PEP. I applaud your strictness Anthony (I was going to use a different phrase using some words from your original message, but then I thought better of that. :). I think we learned our lesson from the 2.2 True/False fiasco. It's a natural instinct to want to get those new features in earlier than the minor release lifecycle, but resisting that temptation demonstrates our maturity as a community, IMO. Having to wait for those new features in the mainline Python releases is the cost of our batteries included approach. If the users of a package want a shorter lifecycle, then the package maintainer will just have to make independent releases, sync'ing up with Python development in the latter's trunk. I've had to do this occasionally with the email package, for example. -Barry signature.asc Description: This is a digitally signed message part ___ 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] rationale for the no-new-features approach
My google-fu returned, and I found the piece I was looking for earlier. This discusses (from an internal Sun perspective) some of the problems with Java. They make quite a big deal about the problem of changing code across minor releases. I recall (re)reading this at some point and it helped me clarify some ideas floating around in my head. http://www.internalmemos.com/memos/memodetails.php?memo_id=1321 On Thursday 10 March 2005 03:01, Guido van Rossum wrote: For those who only remember bool(), Python 1.5.2 was probably the worst offender here (it had nothing to do with 1.5.1). Mea culpa etcetera. That was a heck of a long time ago, and Python was a heck of a lot younger then. Hell, I can still remember the interpreter-prints-all-return-values-to-stdout being turned off sometime during the 0.9.x series (best minor-release-change ever!). And while the True/False issue was a complete pain, it at least serves as a good example (in the http://www.despair.com/demotivators/mis24x30prin.html sense of the word wink) Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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
