Re: [Python-Dev] Pre-PEP: Exception Reorganization for Python 3.0
Brett Cannon wrote: > On 8/2/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: >>It seems to me that multiple inheritance is definitely the right idea, >>though. That way, we can get the hierarchy we really want with only a >>minimum of boilerplate in pre-3.0 to make it actually work. > > Yeah. I think name aliasing and multiple inheritance will take us a > long way. Warnings should be able to take us the rest of the way. > > -Brett (who is still waiting for a number; Barry, David, you out there?) And it will let us get rid of some of the ugliness in my v 0.1 proposal, too (like Error being a child of StandardError, instead of the other way around). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
Phillip J. Eby wrote: > +1. The main things that need fixing, IMO, are the need for critical and > control flow exceptions to be distinguished from "normal" errors. The rest > is mostly too abstract for me to care about in 2.x. I guess, before we figure out "where would we like to go?", we really need to know "what's wrong with where we are right now?" Like you, the only real problem I have with the current hierarchy is that "except Exception:" is just as bad as a bare except in terms of catching exceptions it shouldn't (like SystemExit). I find everything else about the hierarchy is pretty workable (mainly because it *is* fairly flat - if I want to catch a couple of different exception types, which is fairly rare, I can just list them). I like James's suggestion that instead of trying to switch people to using something other than "except Exception:", we just aim to adjust the hierarchy so that "except Exception" becomes the right thing to do. Changing the inheritance structure a bit is far easier than trying to shift several years of accumulated user experience. . . Anyway, with the hierarchy below, "except Exception:" still overreaches, but can be corrected by preceding it with "except (ControlFlow, CriticalError): raise". "except Exception:" stops overreaching once the links from Exception to StopIteration and SystemExit, and the links from StandardError to KeyboardInterrupt, SystemError and MemoryError are removed (probably difficult to do before Py3k but not impossible). This hierarchy also means that inheriting application and library errors from Exception can continue to be recommended practice. Adapting the language to fit the users rather than the other way around seems to be a pretty good call on this point. . . The only changes from the Python 2.4 hierarchy are: New exceptions: - Raisable (new base) - ControlFlow (inherits from Raisable) - CriticalError (inherits from Raisable) - GeneratorExit (inherits from ControlFlow) Added inheritance: - Exception from Raisable - StopIteration, SystemExit, KeyboardInterrupt from ControlFlow - SystemError, MemoryError from CriticalError Python 2.4 Compatible Improved Exception Hierarchy v 0.2 [1] Raisable (new) +-- ControlFlow (new) +-- GeneratorExit (new) +-- StopIteration (inheritance new) +-- SystemExit (inheritance new) +-- KeyboardInterrupt (inheritance new) +-- CriticalError (new) +-- MemoryError (inheritance new) +-- SystemError (inheritance new) +-- Exception (inheritance new) +-- StopIteration +-- SystemExit +-- StandardError +-- KeyboardInterrupt +-- MemoryError +-- SystemError +-- AssertionError +-- AttributeError +-- EOFError +-- ImportError +-- TypeError +-- ReferenceError +-- ArithmeticError +-- FloatingPointError +-- DivideByZeroError +-- OverflowError +-- EnvironmentError +-- OSError +-- WindowsError +-- IOError +-- LookupError +-- IndexError +-- KeyError +-- NameError +-- UnboundLocalError +-- RuntimeError +-- NotImplementedError +-- SyntaxError +-- IndentationError +-- TabError +-- ValueError +-- UnicodeError +-- UnicodeDecodeError +-- UnicodeEncodeError +-- UnicodeTranslateError +-- Warning +-- DeprecationWarning +-- FutureWarning +-- PendingDeprecationWarning +-- RuntimeWarning +-- SyntaxWarning +-- UserWarning Cheers, Nick. [1] I've started putting version numbers on these suggestions, since someone referred to "Nick's exception hierarchy" in one of the threads, and I had no idea which of my suggestions they meant. I think I'm up to three or four different variants by now. . . -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
At 11:10 PM 8/3/2005 +1000, Nick Coghlan wrote: > New exceptions: > - Raisable (new base) > - ControlFlow (inherits from Raisable) > - CriticalError (inherits from Raisable) > - GeneratorExit (inherits from ControlFlow) > Added inheritance: > - Exception from Raisable > - StopIteration, SystemExit, KeyboardInterrupt from ControlFlow > - SystemError, MemoryError from CriticalError +1 I'd also like to see a "Reraisable" or something like that to cover both CriticalError and ControlFlow, but it could be a tuple of those two bases rather than a class. But that's just a "would be nice" feature. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
Nick Coghlan wrote: > Phillip J. Eby wrote: > >>+1. The main things that need fixing, IMO, are the need for critical and >>control flow exceptions to be distinguished from "normal" errors. The rest >>is mostly too abstract for me to care about in 2.x. > > > I guess, before we figure out "where would we like to go?", we really need to > know "what's wrong with where we are right now?" > > Like you, the only real problem I have with the current hierarchy is that > "except Exception:" is just as bad as a bare except in terms of catching > exceptions it shouldn't (like SystemExit). I find everything else about the > hierarchy is pretty workable (mainly because it *is* fairly flat - if I want > to catch a couple of different exception types, which is fairly rare, I can > just list them). More often than not, 9 out 10 times, when ever I use "except Exception:" or a bare except:, what I am doing is the equivalent to: try: # will either fail or not except: pass else: Usually I end up using "if hasattr():" or some other way to pre test the statement if possible as I find "except: pass" to be ugly. And putting both the statement that may fail together with the depending statements in the try:, catches too much. Finding subtle errors hidden by a try block can be rather difficult at times. Could inverse exceptions be an option? Exceptions don't work this way so it would probably need to be sugar for "except :pass; else:". Possibly? try: except not : "except None:" as an option? Ok, this isn't exactly clear, and probably a -2 for several reasons. The exception tree organization should also take into account inverse relationships as well. Exceptions used for control flow are often of the type "if not exception: do something". Cheers, Ron ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/2/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > The Py3.0 PEPs are a bit disconcerting. Without 3.0 actively in > development, it is difficult to get the participation, interest, and > seriousness of thought that we apply to the current release. The PEPs > may have the effect of prematurely finalizing discussions on something > that still has an ethereal if not pie-in-the-sky quality to it. I would > hate for 3.0 development to start with constraints that got set in stone > before the project became a reality. > I don't view this PEP (nor any other PYthon 3000 PEP) as set in stone until we are one or two versions away from Python 3.0 . I view these PEPs as just provoking discussion and getting the ball rolling now instead of rushing to get it done when it does come time to start thinking about these things. Even if we get everyone to agree on this PEP I still won't consider it finalized until there is one more round of discussion just before we start implementing for Python 3.0 . > With respect to exception re-organization, the conversation has been > thought provoking but a little too much of a design-from-scratch > quality. Each proposed change needs to be rooted in a specific problem > with the current hierarchy (i.e. what use cases cannot currently be > dealt with under the existing tree). Setting a high threshold for > change will increase the likelihood that old code can be easily ported > and decrease the likelihood of either throwing away previous good > decisions or adopting new ideas that later prove unworkable. IOW, > unless the current tree is thought to be really bad, then the new tree > ought to be very close to what we have now. > So are you saying that the renaming is bad, or the whole reorg? It seems everyone agrees with the moving of the control flow exceptions and CriticalException, although the renamings might just me wishing for it. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
So here's a radical proposal (hear the scratching of the finglernail on the blackboard? :-). Start with Brett's latest proposal. Goal: keep bare "except:" but change it to catch only the part of the hierarchy rooted at StandardError. - Call the root of the hierarchy Raisable. - Rename CriticalException to CriticalError (this should happen anyway). - Rename ControlFlowException to ControlFlowRaisable (anything except Error or Exception). - Rename StandardError to Exception. - Make Warning a subclass of Exception. I'd want the latter point even if the rest of this idea is rejected; when a Warning is raised (as opposed to just printing a message or being suppressed altogether) it should be treated just like any other normal exception, i.e. StandardError. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Phillip J. Eby wrote: > > +1. The main things that need fixing, IMO, are the need for critical and > > control flow exceptions to be distinguished from "normal" errors. The rest > > is mostly too abstract for me to care about in 2.x. > > I guess, before we figure out "where would we like to go?", we really need to > know "what's wrong with where we are right now?" > > Like you, the only real problem I have with the current hierarchy is that > "except Exception:" is just as bad as a bare except in terms of catching > exceptions it shouldn't (like SystemExit). I find everything else about the > hierarchy is pretty workable (mainly because it *is* fairly flat - if I want > to catch a couple of different exception types, which is fairly rare, I can > just list them). > Does no one else feel some of the names could be improved upon? While we might all have gotten used to them I still don't believe newbies necessarily grasp what they are all for based on their names. Then again, if this PEP is viewed more as handling macro issues with the currnt hierarchy and name changes can be done when we get closer to Python 3.0 I am happy to drop renaming until we are closer to actual implementation with a section just listing suggested name changes and stating that they are just being considered possibl renaming which will not be finalized until we are closer to Python 3.0 . > I like James's suggestion that instead of trying to switch people to using > something other than "except Exception:", we just aim to adjust the hierarchy > so that "except Exception" becomes the right thing to do. Changing the > inheritance structure a bit is far easier than trying to shift several years > of accumulated user experience. . . > > Anyway, with the hierarchy below, "except Exception:" still overreaches, but > can be corrected by preceding it with "except (ControlFlow, CriticalError): > raise". > > "except Exception:" stops overreaching once the links from Exception to > StopIteration and SystemExit, and the links from StandardError to > KeyboardInterrupt, SystemError and MemoryError are removed (probably difficult > to do before Py3k but not impossible). > > This hierarchy also means that inheriting application and library errors from > Exception can continue to be recommended practice. Adapting the language to > fit the users rather than the other way around seems to be a pretty good call > on this point. . . > Well, then StandardError becomes kind of stupid. The only use it would serve is a superclass for all non-critical, non-control-flow built-in exceptions. I really don't know how often that is going to be needed. I do realize it keeps inheritance working for existing code, though. I guess that would just have to be a trade-off for backwards-compatibility. OK, I am convinced; I will revert back to Raisable/Exception instead of Exception/StandardError. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Phillip J. Eby <[EMAIL PROTECTED]> wrote: > At 11:10 PM 8/3/2005 +1000, Nick Coghlan wrote: > > New exceptions: > > - Raisable (new base) > > - ControlFlow (inherits from Raisable) > > - CriticalError (inherits from Raisable) > > - GeneratorExit (inherits from ControlFlow) > > Added inheritance: > > - Exception from Raisable > > - StopIteration, SystemExit, KeyboardInterrupt from ControlFlow > > - SystemError, MemoryError from CriticalError > > +1 > > I'd also like to see a "Reraisable" or something like that to cover both > CriticalError and ControlFlow, but it could be a tuple of those two bases > rather than a class. But that's just a "would be nice" feature. Eh, I am not so hot on this idea. I see your argument, Phillip, but I just don't think it will be useful enough to warrant its introduction. Could add to the exceptions module, though. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > So here's a radical proposal (hear the scratching of the finglernail > on the blackboard? :-). > > Start with Brett's latest proposal. Including renaming (I want to know if you support the renamings at all, if I should make them more of an idea to be considered when we get closer to Python 3.0, or just drop them) and the new exceptions? > Goal: keep bare "except:" but > change it to catch only the part of the hierarchy rooted at > StandardError. > Why the change of heart? Backwards-compatibility? Way to keep newbies from choosing Raisable or such as what to catch? > - Call the root of the hierarchy Raisable. Fine by me. Will change it before I check in the PEP tonight. > - Rename CriticalException to CriticalError > (this should happen anyway). I thought I changed that in the latest version. I will change it. > - Rename ControlFlowException to ControlFlowRaisable > (anything except Error or Exception). No objection from me. > - Rename StandardError to Exception. So just ditch StandardError, which is fine by me, or go with Nick's v2 proposal and have all pre-existing exceptions inherit from it? I assume the latter since you said you wanted bare 'except' clauses to catch StandardError. > - Make Warning a subclass of Exception. > > I'd want the latter point even if the rest of this idea is rejected; > when a Warning is raised (as opposed to just printing a message or > being suppressed altogether) it should be treated just like any other > normal exception, i.e. StandardError. > Since warnings only become raised if the warnings filter lists it as an error I can see how this is a reasonable suggestion. And if bare 'except' clauses catch StandardError and not Exception they will still propagate to the top unless people explicitly catch Exception or lower which seems fair. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > So here's a radical proposal (hear the scratching of the finglernail > > on the blackboard? :-). > > > > Start with Brett's latest proposal. > > Including renaming (I want to know if you support the renamings at > all, if I should make them more of an idea to be considered when we > get closer to Python 3.0, or just drop them) and the new exceptions? Most of the renamings sound fine to me. > > Goal: keep bare "except:" but > > change it to catch only the part of the hierarchy rooted at > > StandardError. > > Why the change of heart? Backwards-compatibility? Way to keep > newbies from choosing Raisable or such as what to catch? The proposal accepts that there's a need to catch "all errors that are reasonable to catch": that's why it separates StandardError from the root exception class. So now we're going to recommend that everyone who was using bare 'except:' write 'except StandardError:' instead. So why not have a default? Because of EIBTI? Seems a weak argument; we have defaults for lots of things. > > - Call the root of the hierarchy Raisable. > > Fine by me. Will change it before I check in the PEP tonight. > > > - Rename CriticalException to CriticalError > > (this should happen anyway). > > I thought I changed that in the latest version. I will change it. I may have missed the change. > > - Rename ControlFlowException to ControlFlowRaisable > > (anything except Error or Exception). > > No objection from me. I actually find it ugly; but it's not an error and it would be weird if there was an xxxException that didn't derive from Exception. > > - Rename StandardError to Exception. > > So just ditch StandardError, which is fine by me, or go with Nick's v2 > proposal and have all pre-existing exceptions inherit from it? I > assume the latter since you said you wanted bare 'except' clauses to > catch StandardError. What do you think? Of course the critical and control flow ones should *not* inherit from it. [...brain hums...] OK, I'm changing my mind again about the names again. Exception as the root and StandardError can stay; the only new proposal would then be to make bare 'except:' call StandardError. > > - Make Warning a subclass of Exception. > > > > I'd want the latter point even if the rest of this idea is rejected; > > when a Warning is raised (as opposed to just printing a message or > > being suppressed altogether) it should be treated just like any other > > normal exception, i.e. StandardError. > > Since warnings only become raised if the warnings filter lists it as > an error I can see how this is a reasonable suggestion. And if bare > 'except' clauses catch StandardError and not Exception they will still > propagate to the top unless people explicitly catch Exception or lower > which seems fair. Unclear what you mean; I want bare except; to catch Warnings! IOW I want Warning to inherit from whatever the thing is that bare except: catches (if we keep it) and that is the start of all the "normal" exceptions excluding critical and control flow exceptions. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>True, but if we never ask, we'll never know :-) >> >>My question was: Would asking a professional hosting company >>be a reasonable approach ? > > It would be an option, yes, of course. It's not an approach that > *I* would be willing to implement, though. Fair enough. >>>From the answers, I take it that there's not much trust in these >>offers, so I guess there's not much desire to PSF money into this. > > I haven't received any offers to make a qualified statement. I only > know that I would oppose an approach to ask somebody but our > volunteers to do it for free, and I also know that I don't want to > spend my time researching commercial alternatives (although I > wouldn't mind if you spent your time). I don't quite understand what you meant here: are you opposing spending PSF money on a hosting company if and only if volunteers who take on the job don't get paid ? I've done a bit of research on the subject and so far only found CollabNet and VA offering commercial services in this area. VA hosts SourceForge so that's a non-option, I guess :-) I know that Greg Stein worked for CollabNet, so thought it might be a good idea to ask him about the idea to move things to CollabNet. Of course, before taking this route, I wanted to get a feeling for the general attitude towards a commercial approach, which is why I tossed in the idea. Other non-commercial alternatives are Berlios and Savannah, but I'm not sure whether they'd offer Subversion support. BTW, have you considered using Trac as issue tracker on svn.python.org ? They have a very good subversion integration, it's easy to use, comes with a wiki and looks great. Oh, and it's written in Python :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 03 2005) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On 8/2/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > George V. Neville-Neil wrote: > > Since Python is Open Source are you looking at Per Force which you can > > use for free and seems to be a happy medium between something like CVS > > and something horrific like Clear Case? > > No. The PEP is only about Subversion. Why should we be looking at Per > Force? Only because Python is Open Source? Perforce is a commercial product, but it can be had for free for verified Open Source projects, which Python shouldn't have any problem with. There are other problems, like you have to renew the agreement every year, but it might be worth considering, given the fact that it's an excellent system. > I think anything but Subversion is ruled out because: > - there is no offer to host that anywhere (for subversion, there is > already svn.python.org) We could host a Perforce repository just as easily, I would think. > - there is no support for converting a CVS repository (for subversion, > there is cvs2svn) I'd put $20 on the fact that cvs2svn will *not* work out of the box for converting the python repository. Just call it a hunch. In any case, the Perforce-supplied cvs2p4 should work at least as well. -- Nick ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
M.-A. Lemburg wrote: >>I haven't received any offers to make a qualified statement. I only >>know that I would oppose an approach to ask somebody but our >>volunteers to do it for free, and I also know that I don't want to >>spend my time researching commercial alternatives (although I >>wouldn't mind if you spent your time). > > > I don't quite understand what you meant here: are you opposing > spending PSF money on a hosting company if and only if volunteers > who take on the job don't get paid ? No. I'm opposed to approaching somebody to do it for free, except the somebody are the pydotorg volunteers (IOW, I won't take gifts from anybody else in this matter). > I've done a bit of research on the subject and so far only found > CollabNet and VA offering commercial services in this area. VA hosts > SourceForge so that's a non-option, I guess :-) It's not that I dislike VA - I personally think they are doing a great job with SourceForge, and I like SourceForge a lot. There are just some issues with it (like that they offer no Subversion). The question would be: what precisely is the commercial offering from VA: does it provide subversion? how is the user management done? etc. > I know that Greg Stein worked for CollabNet, so thought it might be a > good idea to ask him about the idea to move things to CollabNet. > Of course, before taking this route, I wanted to get a feeling > for the general attitude towards a commercial approach, which > is why I tossed in the idea. Ok - I expect that the project might be *done* before we even have a single commercial offer, with a precise service description, and a precise price tag. That makes commercial offers so difficult: that it is so time expensive to use them, that you might spend less time doing it yourself. > Other non-commercial alternatives are Berlios and Savannah, but > I'm not sure whether they'd offer Subversion support. For me, they fall into the "I won't take gifts" category. > BTW, have you considered using Trac as issue tracker on > svn.python.org ? You mean, me personally? I quite like the Subversion tracker, and don't want to trade it for anything else. I know Guido wants to use Roundup (which is also written in Python), and obviously so does Richard Jones. The main questions are the same as with this PEP: how to do the migration from SF (without losing data), and how to do the ongoing maintenance. It's just that finding answers to these questions is so much harder, therefore, this PEP is *only* about CVS. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On Wednesday 03 August 2005 15:01, M.-A. Lemburg wrote: > Other non-commercial alternatives are Berlios and Savannah, but > I'm not sure whether they'd offer Subversion support. Berlios does offer Subversion; the docutils project is using the Berlios Subversion and SourceForge for everything else. I don't know whether Savannah is offering Subversion right now, but the last time I looked at it, it appeared nearly un-maintained. But that may just be the understated nature of that community. :-) -Fred -- Fred L. Drake, Jr. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On 8/3/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > > On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > > So here's a radical proposal (hear the scratching of the finglernail > > > on the blackboard? :-). > > > > > > Start with Brett's latest proposal. > > > > Including renaming (I want to know if you support the renamings at > > all, if I should make them more of an idea to be considered when we > > get closer to Python 3.0, or just drop them) and the new exceptions? > > Most of the renamings sound fine to me. > OK, great. I will leave in the new names and the new exceptions. > > > Goal: keep bare "except:" but > > > change it to catch only the part of the hierarchy rooted at > > > StandardError. > > > > Why the change of heart? Backwards-compatibility? Way to keep > > newbies from choosing Raisable or such as what to catch? > > The proposal accepts that there's a need to catch "all errors that are > reasonable to catch": that's why it separates StandardError from the > root exception class. > > So now we're going to recommend that everyone who was using bare > 'except:' write 'except StandardError:' instead. > > So why not have a default? > Because you can easily write it without a default. > Because of EIBTI? > Don't know the acronym (and neither does acronymfinder.com). > Seems a weak argument; we have defaults for lots of things. > OK. I was fine with bare 'except' clauses to begin with so this is not a huge point of contention for me personally. [SNIP] > > So just ditch StandardError, which is fine by me, or go with Nick's v2 > > proposal and have all pre-existing exceptions inherit from it? I > > assume the latter since you said you wanted bare 'except' clauses to > > catch StandardError. > > What do you think? Of course the critical and control flow ones should > *not* inherit from it. > Well, Nick and Jame's point of tweaking the names so that they more reflect what people expect instead of what they are meant to actually be is interesting. But, in terms of backwards-compatibility, Exception/StandardError is most exacting in terms of matching what already exists. But with renamings I don't know how critical this kind of low-level backwards-compatibility is critical. Personally I just prefer the names Exception/StandardError for unexplained aesthetic reasons. > [...brain hums...] > > OK, I'm changing my mind again about the names again. > > Exception as the root and StandardError can stay; the only new > proposal would then be to make bare 'except:' call StandardError. > OK. I will then also leave ControlFlowException as-is. > > > - Make Warning a subclass of Exception. > > > > > > I'd want the latter point even if the rest of this idea is rejected; > > > when a Warning is raised (as opposed to just printing a message or > > > being suppressed altogether) it should be treated just like any other > > > normal exception, i.e. StandardError. > > > > Since warnings only become raised if the warnings filter lists it as > > an error I can see how this is a reasonable suggestion. And if bare > > 'except' clauses catch StandardError and not Exception they will still > > propagate to the top unless people explicitly catch Exception or lower > > which seems fair. > > Unclear what you mean; I want bare except; to catch Warnings! IOW I > want Warning to inherit from whatever the thing is that bare except: > catches (if we keep it) and that is the start of all the "normal" > exceptions excluding critical and control flow exceptions. > OK, that squares that one away. And it makes sense since you can view Warnings as even less critical exceptions than the non-control and non-critical exceptions and thus should be caught by a default `except' clause. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
Guido van Rossum <[EMAIL PROTECTED]> writes: > So here's a radical proposal (hear the scratching of the finglernail > on the blackboard? :-). > > Start with Brett's latest proposal. Goal: keep bare "except:" but > change it to catch only the part of the hierarchy rooted at > StandardError. > > - Call the root of the hierarchy Raisable. > - Rename CriticalException to CriticalError > (this should happen anyway). > - Rename ControlFlowException to ControlFlowRaisable > (anything except Error or Exception). > - Rename StandardError to Exception. > - Make Warning a subclass of Exception. > > I'd want the latter point even if the rest of this idea is rejected; > when a Warning is raised (as opposed to just printing a message or > being suppressed altogether) it should be treated just like any other > normal exception, i.e. StandardError. In the above you need to ensure that all raised exceptions inherit from Raisable, because sometimes you really do want to catch almost anything (e.g. code.py). Has anyone thought about the C side of this? There are a few slightly-careless calls to PyErr_Clear() in the codebase, and they can cause just as much (more!) heartache as bare except: clauses. I'll note in passing that I'm not sure that any reorganization of the exception hierachy will make this kind of catching-too-much bug go away. The issue is just thorny, and each case is different. I'm also still not convinced that the backwards compatibility breaking Python 3.0 will ever actually happen, but I guess that's a different consideration... Cheers, mwh -- Haha! You had a *really* weak argument! -- Moshe Zadka, comp.lang.python ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Michael Hudson <[EMAIL PROTECTED]> wrote: > Guido van Rossum <[EMAIL PROTECTED]> writes: > > > So here's a radical proposal (hear the scratching of the finglernail > > on the blackboard? :-). > > > > Start with Brett's latest proposal. Goal: keep bare "except:" but > > change it to catch only the part of the hierarchy rooted at > > StandardError. > > > > - Call the root of the hierarchy Raisable. > > - Rename CriticalException to CriticalError > > (this should happen anyway). > > - Rename ControlFlowException to ControlFlowRaisable > > (anything except Error or Exception). > > - Rename StandardError to Exception. > > - Make Warning a subclass of Exception. > > > > I'd want the latter point even if the rest of this idea is rejected; > > when a Warning is raised (as opposed to just printing a message or > > being suppressed altogether) it should be treated just like any other > > normal exception, i.e. StandardError. > > In the above you need to ensure that all raised exceptions inherit > from Raisable, because sometimes you really do want to catch almost > anything (e.g. code.py). > That's part of the PEP. > Has anyone thought about the C side of this? I have thought about it somewhat, but I have not dived in to try to write a patch. > There are a few > slightly-careless calls to PyErr_Clear() in the codebase, and they can > cause just as much (more!) heartache as bare except: clauses. > I fail to see how clearing the exception state has any effect on the implementation for the PEP. > I'll note in passing that I'm not sure that any reorganization of the > exception hierachy will make this kind of catching-too-much bug go > away. The issue is just thorny, and each case is different. > It will never go away as long as catching exceptions based on inheritance exists. Don't know if any language has ever solved it. Best we can do is try to minimize it. > I'm also still not convinced that the backwards compatibility breaking > Python 3.0 will ever actually happen, but I guess that's a different > consideration... Perhaps not. Might end up doing so much of a slow transition that it will just be a bigger codebase change from 2.9 (or whatever the end of the 2.x branch is) to 3.0 . > -- > Haha! You had a *really* weak argument! > -- Moshe Zadka, comp.lang.python Hopefully I don't. =) -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
In article <[EMAIL PROTECTED]>, Brett Cannon <[EMAIL PROTECTED]> wrote: > New Hierarchy > = > > Exception > +-- CriticalException (new) > +-- KeyboardInterrupt > +-- MemoryError > +-- SystemError > +-- ControlFlowException (new) > +-- StopIteration > +-- GeneratorExit > +-- SystemExit > +-- StandardError > +-- AssertionError > +-- SyntaxError > +-- IndentationError > +-- TabError > +-- UserException (rename of RuntimeError) > +-- ArithmeticError > +-- FloatingPointError > +-- DivideByZeroError > +-- OverflowError > +-- UnicodeError > +-- UnicodeDecodeError > +-- UnicodeEncodeError > +-- UnicodeTranslateError > +-- LookupError > +-- IndexError > +-- KeyError > +-- TypeError > +-- AttributeError > +-- EnvironmentError > +-- OSError > +-- IOError > +-- EOFError (new inheritance) > +-- ImportError > +-- NotImplementedError (new inheritance) > +-- NamespaceError (rename of NameError) > +-- UnboundGlobalError (new) > +-- UnboundLocalError > +-- UnboundFreeError (new) > +-- WeakReferenceError (rename of ReferenceError) > +-- ValueError > +-- Warning > +-- UserWarning > +-- AnyDeprecationWarning (new) > +-- PendingDeprecationWarning > +-- DeprecationWarning > +-- SyntaxWarning > +-- SemanticsWarning (rename of RuntimeWarning) > +-- FutureWarning I am wondering why OSError and IOError are not under StandardError? This seems a serious misfeature to me (perhaps the posting was just misformatted?). Having one class for "normal" errors (not exceptions whose sole purpose is to halt the program and not so critical that any continuation is hopeless) sure would make it easier to write code that output a traceback and tried to continue. I'd love it. -- Russell ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
> > Because of EIBTI? > > Don't know the acronym (and neither does acronymfinder.com). Sorry. Explicit is Better than Implicit. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Russell E. Owen <[EMAIL PROTECTED]> wrote: > In article <[EMAIL PROTECTED]>, > Brett Cannon <[EMAIL PROTECTED]> wrote: > > > New Hierarchy > > = > > > > Exception [SNIP] > > +-- StandardError [SNIP] > > +-- EnvironmentError > > +-- OSError > > +-- IOError > > +-- EOFError (new inheritance) [SNIP] > > I am wondering why OSError and IOError are not under StandardError? This > seems a serious misfeature to me (perhaps the posting was just > misformatted?). > Look again; they are with an inheritance for both of (OS|IO)Error <- EnvironmentError <- StandardError <- Exception. > Having one class for "normal" errors (not exceptions whose sole purpose > is to halt the program and not so critical that any continuation is > hopeless) sure would make it easier to write code that output a > traceback and tried to continue. I'd love it. > That is what StandardError is for. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote: > [...brain hums...] > > OK, I'm changing my mind again about the names again. > > Exception as the root and StandardError can stay; the only new > proposal would then be to make bare 'except:' call StandardError. I don't see how that can work. Any solution that is expected to result in a usable hierarchy this century must preserve "Exception" as the object that user exceptions should derive from (and therefore that users should generally catch, as well). There is way too much momentum behind that to change it. James ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, James Y Knight <[EMAIL PROTECTED]> wrote: > On Aug 3, 2005, at 3:00 PM, Guido van Rossum wrote: > > [...brain hums...] > > > > OK, I'm changing my mind again about the names again. > > > > Exception as the root and StandardError can stay; the only new > > proposal would then be to make bare 'except:' call StandardError. > > I don't see how that can work. Any solution that is expected to > result in a usable hierarchy this century must preserve "Exception" > as the object that user exceptions should derive from (and therefore > that users should generally catch, as well). There is way too much > momentum behind that to change it. > Oh, I bet Guido can make them change. =) Look at it this way; going with the Raisable/Exception change and having bare 'except's catch Exception will still lead to a semantic change since CriticalError and ControlFlowException will not be caught. Breakage is going to happen, so why not just do a more thorough change that leads to more breakage? Obviously you are saying to minimize it while Guido is saying to go for a more thorough change. So how much more code is going to crap out with this change? Everything under our control will be fine since we can change it. User-defined exceptions might need to be changed if they inherit directly from Exception instead of StandardError, which is probably the common case, but changing a superclass is not hard. That kind of breakage is not bad since you can easily systematically change superclasses of exceptions from Exception to StandardError without much effort thanks to regexes. I honestly think the requirement of inheriting from a specific superclass will lead to more breakage since you can't grep for exceptions that don't at least inherit from *some* exception universally. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
[Guido van Rossum] > > OK, I'm changing my mind again about the names again. > > > > Exception as the root and StandardError can stay; the only new > > proposal would then be to make bare 'except:' call StandardError. [James Y Knight] > I don't see how that can work. Any solution that is expected to > result in a usable hierarchy this century must preserve "Exception" > as the object that user exceptions should derive from (and therefore > that users should generally catch, as well). There is way too much > momentum behind that to change it. This is actually a good point, and what I was thinking when I first responded to Brett. Sorry for the waivering -- being at OSCON always is a serious attack on my system. I'm still searching for a solution that lets us call everything in the hierarchy "exception" and *yet* has Exception at the mid-point in that hierarchy where Brett has StandardException. The problem with Raisable is that it doesn't contain the word exception; perhaps we can call it BaseException? We've got a few more things called base-such-and-such, e.g. basestring (not that I like that one all that much). BTW I just noticed UserException -- shouldn't this be UserError? Also... We should have a guideline for when to use "...Exception" and when to use "...Error". Maybe we can use ...Exception for the first two levels of the hierarchy, ...Error for errors, and other endings for things that aren't errors (like SystemExit)? Then the top of the tree would look like this: BaseException (or RootException?) +-- CriticalException +-- ControlFlowException +-- Exception +-- (all regular exceptions start here) +-- Warning All common errors and warnings derive from Exception; bare 'except:' would be the same as 'except Exception:'. (I like that particularly because I've been writing that in lots of code already. :-) A refinement might be to introduce something called Error, which would change the last part of the avove hierarchy as follows: (first three lines same as above) +-- Exception +-- Error +-- (all regular ...Error exceptions start here) +-- Warning +-- (all warnings start here) This has a nice symmetry between Error and Warning. Downside is that this "breaks" all user code that currently tries to be correct by declaring exceptions as deriving from Exception, which is pretty common; they would have to derive from Error to be politically correct. I don't immediately see what's best -- maybe Exception and Error should be two names for the same object??? But that's ugly too as a long-term solution. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
> The problem with Raisable > is that it doesn't contain the word exception; perhaps we can call it > BaseException? +1 > A refinement might be to introduce something called Error, which would > change the last part of the avove hierarchy as follows: . . . > This has a nice symmetry between Error and Warning. > > Downside is that this "breaks" all user code that currently tries to > be correct by declaring exceptions as deriving from Exception, which > is pretty common; they would have to derive from Error to be > politically correct. > > I don't immediately see what's best -- maybe Exception and Error > should be two names for the same object??? But that's ugly too as a > long-term solution. -1 Who really cares about the distinction? Besides, the correct choice may depend on your point of view or specific application (i.e. a case could be made that NotImplementedError is sometimes just a regular exception that can be expected to arise and be handled in the normal course of business). Unless we can point to real problems that people are having today, then these kind of changes are likely unwarranted. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP, take 2: Exception Reorganization for Python 3.0
On 8/3/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > [Guido van Rossum] > > > OK, I'm changing my mind again about the names again. > > > > > > Exception as the root and StandardError can stay; the only new > > > proposal would then be to make bare 'except:' call StandardError. > > [James Y Knight] > > I don't see how that can work. Any solution that is expected to > > result in a usable hierarchy this century must preserve "Exception" > > as the object that user exceptions should derive from (and therefore > > that users should generally catch, as well). There is way too much > > momentum behind that to change it. > > This is actually a good point, and what I was thinking when I first > responded to Brett. > > Sorry for the waivering -- being at OSCON always is a serious attack > on my system. > As long as you don't change your mind again on bare 'except's I won't feel like strangling you. =) > I'm still searching for a solution that lets us call everything in the > hierarchy "exception" and *yet* has Exception at the mid-point in that > hierarchy where Brett has StandardException. The problem with Raisable > is that it doesn't contain the word exception; perhaps we can call it > BaseException? We've got a few more things called base-such-and-such, > e.g. basestring (not that I like that one all that much). > BaseException is what comes to mind initially. You also mention RootException below. PureException seems too cutesy. SuperclassException might work. SuperException doesn't sound right. Co-worker suggested UhOh, but I don't think that will work either. =) > BTW I just noticed UserException -- shouldn't this be UserError? > Yep, and I already changed it in my personal copy. > Also... We should have a guideline for when to use "...Exception" and > when to use "...Error". Maybe we can use ...Exception for the first > two levels of the hierarchy, ...Error for errors, and other endings > for things that aren't errors (like SystemExit)? Then the top of the > tree would look like this: > That makes the most sense. Error for actual errors, exception when another suffix (e.g., Exit, Iteration) does not fit. > BaseException (or RootException?) > +-- CriticalException > +-- ControlFlowException > +-- Exception > +-- (all regular exceptions start here) > +-- Warning > > All common errors and warnings derive from Exception; bare 'except:' > would be the same as 'except Exception:'. (I like that particularly > because I've been writing that in lots of code already. :-) > > A refinement might be to introduce something called Error, which would > change the last part of the avove hierarchy as follows: > > (first three lines same as above) > +-- Exception > +-- Error > +-- (all regular ...Error exceptions start here) > +-- Warning > +-- (all warnings start here) > > This has a nice symmetry between Error and Warning. > > Downside is that this "breaks" all user code that currently tries to > be correct by declaring exceptions as deriving from Exception, which > is pretty common; they would have to derive from Error to be > politically correct. > > I don't immediately see what's best -- maybe Exception and Error > should be two names for the same object??? But that's ugly too as a > long-term solution. Yuck. I say introduce Error (or StandardError or BaseError) and just live with the fact that older code will not necessarily follow the proper naming scheme. We can provide a script that will change source directly for any class that inherits from Exception to some other class, namely Error. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
On Wed, Aug 03, 2005, Nicholas Bastin wrote: > > I'd put $20 on the fact that cvs2svn will *not* work out of the box > for converting the python repository. Just call it a hunch. In any > case, the Perforce-supplied cvs2p4 should work at least as well. Maybe. OTOH, I went to a CVS->SVN talk today at OSCON, and I'd be suspicious of claims that Python's repository is more difficult to convert than others that have successfully made the switch (such as KDE). I'd rather not rely on licensing of a closed-source system; one of the points made during the talk was that the Linux project had to scramble when they lost their Bitkeeper license (but they didn't switch to SVN because they wanted a distributed model -- one of things I appreciated about this talk was the lack of One True Way-ism). -- Aahz ([EMAIL PROTECTED]) <*> http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
> "aahz" == aahz <[EMAIL PROTECTED]> writes: aahz> I'd rather not rely on licensing of a closed-source system; aahz> one of the points made during the talk was that the Linux aahz> project had to scramble when they lost their Bitkeeper aahz> license Python is unlikely to throw away its license in the same way, I should think. For additional security, you could try to negotiate a perpetual license on a particular version, or a license that required substantial notice (say, six months) for termination. I would imagine you could get them; the only reason for the vendor not to give them would be spite. The problem with both of those options is the one that Martin already pointed out: negotiation takes effort. There are several good open source alternatives, one of which (svn) is well-established and gets excellent reviews for those goals it sets itself, which happen to be solving the problems (as opposed to missing features) of CVS. Why spend effort on negotiating licenses and preparing for potential vendor relationship problems, unless there's acknowledged need for features svn doesn't provide? -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Exception Reorg PEP checked in
OK, once the cron job comes around and is run, http://www.python.org/peps/pep-0348.html will not be a 404 but be the latest version of the PEP. Differences since my last public version is that it has BaseException/Exception as the naming hierarchy, Warning inherits from Exception, UserException is UserError, and StandardError inherits from Exception. I also added better annotations on the tree for noticing where inheritance changed and whether it become broader (and thus had a new exception in its MRO) or more restrictive (and thus lost an exception). Basically everything that Guido has brought up today (08-03). I may have made some mistakes changing over to BaseException/Exception thanks to their names being so similar and tossing back in StandardError so if people catch what seems like odd sentences that is why (obviously let me know of the mistake). -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
> "M" == "M.-A. Lemburg" <[EMAIL PROTECTED]> writes: M> Other non-commercial alternatives are Berlios and Savannah, but M> I'm not sure whether they'd offer Subversion support. Savannah doesn't offer great reliability or support, at least to judge by the frequency with which the GNU Emacs and GNU Arch projects have been unable to access various services on Savannah, including mailing lists and CVS. I also wonder if Savannah poses security risks. They've been successfully cracked (ISTR more than once) in the last couple of years, and took 6-10 weeks to get back to normal. This makes them reluctant to make minor variations in their established procedures for the convenience of projects. For example, it took a couple of months for GNU Arch to arrange sftp access so that they could host the Arch project in an Arch repository (Arch can use sftp but not plain ssh as a transport). SunSITE.dk does provide reliable service and timely support. XEmacs has been very happy with it. But Martin v. Loewis apparently hasn't had the same good experience with negotiating with them, and at least some negotiation and relationship maintenance is necessary---it's a closer, more personal relationship than with SF or Savannah. In particular for Subversion support (I was told they allow it on a case by case basis, and once success is demonstrated they plan to offer it in general). As I say, we've been happy with SunSITE, but the amount of effort is basically the same as if we ran our own repository, just directed more toward "vendor relations" and away from "sys admin" (which suits us). FWIW, XEmacs has moved or reorganized CVS repositories five times since 1999. Although it's not all in the PEP, if you add the discussion on this list Martin has covered the important issues we encountered or worried about. -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Nicholas Bastin wrote: >>No. The PEP is only about Subversion. Why should we be looking at Per >>Force? Only because Python is Open Source? > > > Perforce is a commercial product, but it can be had for free for > verified Open Source projects, which Python shouldn't have any problem > with. There are other problems, like you have to renew the agreement > every year, but it might be worth considering, given the fact that > it's an excellent system. So we should consider it because it is an excellent system... I don't know what that means, in precise, day-to-day usage terms (i.e. what precisely would it do for us that, say, Subversion can't do). >>I think anything but Subversion is ruled out because: >>- there is no offer to host that anywhere (for subversion, there is >> already svn.python.org) > > > We could host a Perforce repository just as easily, I would think. Interesting offer. I'll add this to the PEP - who is "we" in this context? >>- there is no support for converting a CVS repository (for subversion, >> there is cvs2svn) > > > I'd put $20 on the fact that cvs2svn will *not* work out of the box > for converting the python repository. Just call it a hunch. You could have read the PEP before losing that money :-) It did work out of the box. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
