Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Martin v. Löwis wrote: > 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). Ok. >>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 guess this was a misunderstanding on my part: VA doesn't offer their commercial solution in an ASP-like way. Their product, called SourceForge Enterprise, is a J2EE application which we'd have to install and run. They do mention Subversion as being supported by the Enterprise edition. >>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. For (more or less) simple things like setting up SVN, I'd agree, but for hosting a complete development system, I have my doubts - things start to get rather complicated and integration of various different tools tends to be very time consuming. Sysadmin tasks like doing backups, emergency recovery, etc. also get more complicated once you have to deal with many different ways of data storage deployed by such tools, e.g. many of them require use of special tools to do hot backups. >>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. Ok, I'll drop the idea. >>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. Ok. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 04 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] Exception Reorg PEP checked in
Brett Cannon wrote: > 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). > If/when you add a "Getting there from here" section, it would be worth noting that there are a few basic strategies to be applied: - for new exceptions: - just add them in release 2.x - for name changes: - add the new name as an alias in release 2.x - deprecate the old name in release 2.x - delete the old name in release 2.(x+1) - to switch inheritance to a new exception type: - add the inheritance to the new parent in release 2.x - delete the inheritance from the old parent in release 3.0 - to switch inheritance to an existing exception type: - add the inheritance to the new parent in release 3.0 - delete the inheritance from the old parent in release 3.0 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] Exception Reorg PEP checked in
Nick Coghlan wrote: > If/when you add a "Getting there from here" section, it would be worth noting > that there are a few basic strategies to be applied: Eh, never mind. It's already there ;) 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] Exception Reorg PEP checked in
Brett Cannon wrote (in the PEP): > KeyboardInterrupt inheriting from ControlFlowException > > KeyboardInterrupt has been a contentious point within this hierarchy. Some > view the exception as more control flow being caused by the user. But with > its asynchronous cause thanks to the user being able to trigger the > exception at any point in code it has a more proper place inheriting from > CriticalException. It also keeps the name of the exception from being > "CriticalError". I think this argues against your own hierarchy, since you _did_ call the parent exception CriticalError. By your argument above, that suggests KeyboardInterrupt doesn't belong there ;) In practice, whether KeyboardInterrupt inherits from ControlFlowException or CriticalError shouldn't be a big deal - the important thing is to get it out from under Exception and StandardError. At which point, the naming issue is enough to incline me towards christening it a ControlFlowException. It gets all the 'oddly named' exceptions into one place. Additionally, consider that a hypothetical ThreadExit exception (used to terminate a thread semi-gracefully) would also clearly belong under ControlFlowException. That is, just because something is asynchronous with respect to the currently executing code doesn't necessarily make it an error (yes, I know I argued the opposite point the other day. . .). 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] Exception Reorg PEP checked in
Since I forgot to mention it in the last couple of messages - this version looks very good. The transition strategy section makes it a lot more meaningful. Brett Cannon wrote (in the PEP): > Renamed Exceptions > > Renamed exceptions will directly subclass the new names. When the old > exceptions are instantiated (which occurs when an exception is caught, > either by a try statement or by propagating to the top of the execution > stack), a PendingDeprecationWarning will be raised. Nice trick with figuring out how to raise the deprecation warning :) (That line was going to read 'Why not just create an alias?', but then I worked out what you were doing, and why you were doing it) One case that this doesn't completely address is NameError, as it is the only renamed exception which currently has a subclass. In this case, I think that during the transmition phase, all three of the 'Unbound*Error' exceptions should inherit from NameError, with NameError inheriting from NamespaceError. I believe it should still be possible to get the deprecation warning to work correctly in this case (by not raising the warning when a subclass is instantiated). In the 'just a type' category, WeakReferenceError should still be under StandardError in the hierarchy. 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] Exception Reorg PEP checked in
On Aug 4, 2005, at 7:03 AM, Nick Coghlan wrote: > Additionally, consider that a hypothetical ThreadExit exception > (used to > terminate a thread semi-gracefully) would also clearly belong under > ControlFlowException. That is, just because something is > asynchronous with > respect to the currently executing code doesn't necessarily make it > an error > (yes, I know I argued the opposite point the other day. . .). No. Just because something gets asynchronously raised out from under you *does* make it critical (or maybe "critically fatal"). See my reply to Philip Eby on Aug 2, msgid <[EMAIL PROTECTED]>. 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] Exception Reorg PEP checked in
On 8/4/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > 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. Currently, when the "recursion limit" is reached, a RuntimeError is raised. RuntimeError is in the PEP renamed to UserError. UserError is in the new hierarchy located below StandardError, below Exception. I think that in the new hierarchy this error should be in the same "critical" category as MemoryError. (MemoryError includes general stack overflow.) - Willem ___ 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] Exception Reorg PEP checked in
>+-- NamespaceError (rename of NameError)
>+-- UnboundFreeError (new)
>+-- UnboundGlobalError (new)
>+-- UnboundLocalError
>
What are these new exceptions for? Under what circumstances are they
raised? Why is this necessary or an improvement?
> Renamed Exceptions
>
> Renamed exceptions will directly subclass the new names. When the
> old exceptions are instantiated (which occurs when an exception is
> caught, either by a try statement or by propagating to the top of
> the execution stack), a PendingDeprecationWarning will be raised.
>
> This should properly preserve backwards-compatibility as old usage
> won't change and the new names can be used to also catch exceptions
> using the old name. The warning of the deprecation is also kept
> simple.
This will cause problems when a library raises the exception under
the new name and an app tries to catch the old name. So the standard
lib (or any other lib) cannot raise the new names. Because the stdlib
must raise the old names, people will see the old names, continue
catching the old names, and the new names will never catch on.
Perhaps it'd work out better to have the new names subclass the old
names. Then you have to continue catching the old name as long as
anyone is raising it, but at least you can raise the new name with
impunity. I expect not much code actually raises ReferenceError or
NameError besides that internal to python. Thus it would be
relatively safe to change all code to catch the new names for those
immediately. Lots of code raises RuntimeError, but I bet not very
much code explicitly catches it.
Oh, but if the stdlib starts raising under the new names, that'll
break any code that checks the exact type of the exception against
the old name. Boo.
It'd be better to somehow raise a DeprecationWarning upon access, yet
still result in the same object. Unfortunately I don't think there's
any way to do that in python. This lack of ability to deprecate
module attributes has bit me several times in other projects as well.
Matt Goodall wrote the hack attached at the end in order to move some
whole modules around in Nevow. Amazingly it actually seemed to
work. :) Something like that won't work for __builtins__, of course,
since that's accessed directly with PyDict_Get.
All in all I don't really see a real need for these renamings and I
don't see a way to do them compatibly so I'm -1 to the whole idea of
renaming exceptions.
> Removal of Bare except Clauses
>
> A SemanticsWarning will be raised for all bare except clauses.
Does this mean that bare except clauses change meaning to "except
Exception" immediately? Or (I hope) did you mean that in Py2.5 they
continue doing as they do now, but print a warning to tell you they
will be changing in the future?
James
> import sys
> import types
> import warnings
>
> from twisted.python import reflect
>
> class ModuleWithDeprecations(types.ModuleType):
>
> def __init__(self, original, deprecatedNames):
> self.original = original
> self.deprecatedNames = deprecatedNames
>
> def __getattr__(self, name):
> newName = self.deprecatedNames.get(name, None)
> if newName is not None:
> warnings.warn("nevow.%s is deprecated, please import %s
> instead!"% (name,newName), DeprecationWarning, 2)
> return reflect.namedAny(newName)
> return getattr(self.original, name)
>
> # Evil hack? What evil hack!
> sys.modules['nevow'] = ModuleWithDeprecations(
> sys.modules['nevow'],
> {'formless': 'formless',
> 'freeform': 'formless.webform'
> }
> )
___
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] Exception Reorg PEP checked in
In general the PEP looks really good now! On 8/4/05, Willem Broekema <[EMAIL PROTECTED]> wrote: > On 8/4/05, Brett Cannon <[EMAIL PROTECTED]> wrote: > > 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. > > Currently, when the "recursion limit" is reached, a RuntimeError is > raised. RuntimeError is in the PEP renamed to UserError. UserError is > in the new hierarchy located below StandardError, below Exception. > > I think that in the new hierarchy this error should be in the same > "critical" category as MemoryError. (MemoryError includes general > stack overflow.) No. Usually, a recursion error is a simple bug in the code, no different from a TypeError or NameError etc. This does contradict my earlier claim that Python itself doesn't use RuntimeError; I think I'd be happier if it remained RuntimeError. (I think there are a few more uses of it inside Python itself; I don't think it's worth inventing new exceptions for all these.) -- --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
M.-A. Lemburg wrote: > I guess this was a misunderstanding on my part: VA doesn't offer > their commercial solution in an ASP-like way. Their product, > called SourceForge Enterprise, is a J2EE application which we'd > have to install and run. They do mention Subversion as being > supported by the Enterprise edition. Ah, ok. I don't think I want to operate such a software (and, strictly speaking, this is out of the scope of the PEP). I had the "pleasure" once of having to maintain a SourceForge installation (before SourceForge became closed source), and it was a nightmare to operate. > For (more or less) simple things like setting up SVN, I'd agree, > but for hosting a complete development system, I have my doubts - > things start to get rather complicated and integration of various > different tools tends to be very time consuming. I guess Python's development process is very simple then. We use mailing lists, CVS, newsgroups, web servers, and bug trackers, but these don't have to integrate. Many of these services are already on pydotorg, and I propose to add an additional one (revision control). > Sysadmin tasks like doing backups, emergency recovery, etc. also > get more complicated once you have to deal with many different ways > of data storage deployed by such tools, e.g. many of them > require use of special tools to do hot backups. We are doing quite well here. XS4ALL kindly does disk backup for us, and, in the specific case of Subversion's fsfs, this is all that is needed. For Postgres, we backup to disk, which then gets picked up by the disk backup. 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
[Python-Dev] PEP 342 Implementation
Could someone please make an independent check to verify an issue with the 342 checkin. The test suite passes but when I run IDLE and open a new window (using Control-N), it crashes and burns. The problem does not occur just before the checkin: cvs up -D "2005-08-01 18:00" But emerges immediately after: cvs up -D "2005-08-01 21:00" 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: Migrating the Python CVS to Subversion
Martin v. Löwis wrote: > M.-A. Lemburg wrote: > >>I guess this was a misunderstanding on my part: VA doesn't offer >>their commercial solution in an ASP-like way. Their product, >>called SourceForge Enterprise, is a J2EE application which we'd >>have to install and run. They do mention Subversion as being >>supported by the Enterprise edition. > > > Ah, ok. I don't think I want to operate such a software (and, > strictly speaking, this is out of the scope of the PEP). I had the > "pleasure" once of having to maintain a SourceForge installation > (before SourceForge became closed source), and it was a nightmare > to operate. With J2EE I doubt that things got any easier to maintain... (assuming that you had to run the version of the software which is used on SF.net). >>For (more or less) simple things like setting up SVN, I'd agree, >>but for hosting a complete development system, I have my doubts - >>things start to get rather complicated and integration of various >>different tools tends to be very time consuming. > > > I guess Python's development process is very simple then. We use > mailing lists, CVS, newsgroups, web servers, and bug trackers, > but these don't have to integrate. Many of these services are > already on pydotorg, and I propose to add an additional one > (revision control). > > >>Sysadmin tasks like doing backups, emergency recovery, etc. also >>get more complicated once you have to deal with many different ways >>of data storage deployed by such tools, e.g. many of them >>require use of special tools to do hot backups. > > > We are doing quite well here. XS4ALL kindly does disk backup for > us, and, in the specific case of Subversion's fsfs, this is all > that is needed. For Postgres, we backup to disk, which then > gets picked up by the disk backup. Sounds like you have everything under control, which is good :-) BTW, in one of your replies I read that you had a problem with how cvs2svn handles trunk, branches and tags. In reality, this is no problem at all, since Subversion is very good at handling moves within the repository: you can easily change the repository layout after the import to whatevery layout you see fit - without losing any of the version history. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 04 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/ 2005-07-18: Released mxODBC.Zope.DA for Zope 2.8 ::: 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
At 08:28 PM 8/4/2005 +0200, M.-A. Lemburg wrote: >BTW, in one of your replies I read that you had a problem with >how cvs2svn handles trunk, branches and tags. In reality, this >is no problem at all, since Subversion is very good at handling >moves within the repository: you can easily change the repository >layout after the import to whatevery layout you see fit - without >losing any of the version history. Yeah, in my use of SVN I find that this is more theoretical than actual for certain use cases. You can see the history of a file including the history of any file it was copied from. However, if you want to try to look at the whole layout, you can't easily get to the old locations. This can be a royal pain, whereas at least in CVS you can use viewcvs to show you the "attic". Subversion doesn't have an attic, which makes looking at structural history very difficult. That having been said, I generally like Subversion, I just know that when I moved my projects to it I felt it was worth taking extra care to convert them in a way that didn't require me to reorganize the repository immediately thereafter, because I didn't want a sudden discontinuity, beyond which history would be difficult to follow. Therefore, I'm saying that taking some care with the conversion process to get things the way we like them would be a good idea. ___ 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
Phillip J. Eby wrote: > At 08:28 PM 8/4/2005 +0200, M.-A. Lemburg wrote: > >> BTW, in one of your replies I read that you had a problem with >> how cvs2svn handles trunk, branches and tags. In reality, this >> is no problem at all, since Subversion is very good at handling >> moves within the repository: you can easily change the repository >> layout after the import to whatevery layout you see fit - without >> losing any of the version history. > > > Yeah, in my use of SVN I find that this is more theoretical than actual > for certain use cases. You can see the history of a file including the > history of any file it was copied from. However, if you want to try to > look at the whole layout, you can't easily get to the old locations. > This can be a royal pain, whereas at least in CVS you can use viewcvs to > show you the "attic". Subversion doesn't have an attic, which makes > looking at structural history very difficult. Hmm, I usually create a tag before doing such changes in our Subversion repo. This makes it very easy to look at layouts before a restructuring. And because Subversion doesn't really care whether you do a tag, branch, or some other form of diverting versions into different namespaces (it's all just copying data), you can easily create a directory called "attic" for just this purpose and copy your structural change tags in there :-) > That having been said, I generally like Subversion, I just know that > when I moved my projects to it I felt it was worth taking extra care to > convert them in a way that didn't require me to reorganize the > repository immediately thereafter, because I didn't want a sudden > discontinuity, beyond which history would be difficult to follow. > > Therefore, I'm saying that taking some care with the conversion process > to get things the way we like them would be a good idea. Still very true indeed. The fact that cvs2svn is written in Python should make this even easier. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 04 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/ 2005-07-18: Released mxODBC.Zope.DA for Zope 2.8 ::: 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
[Python-Dev] String exceptions in Python source
/usr/local/src/Python-2.4.1/Lib/SimpleXMLRPCServer.py: raise 'bad method' /usr/local/src/Python-2.4.1/Demo/classes/bitvec.py: raise 'FATAL', '(param, l) = %r' % ((param, l),) /usr/local/src/Python-2.4.1/Lib/plat-mac/FrameWork.py: raise 'Unsupported in MachoPython' /usr/local/src/Python-2.4.1/Lib/plat-mac/FrameWork.py: raise 'Can only delete last item of a menu' /usr/local/src/Python-2.4.1/Lib/plat-mac/MiniAEFrame.py: raise 'Cannot happen: AE callback without handler', (_class, _type) /usr/local/src/Python-2.4.1/Lib/plat-mac/PixMapWrapper.py: raise 'UseErr', "don't assign to .baseAddr -- assign to .data instead" /usr/local/src/Python-2.4.1/Lib/plat-mac/argvemulator.py: raise 'Cannot happen: AE callback without handler', (_class, _type) /usr/local/src/Python-2.4.1/Mac/Modules/waste/wastescan.py: raise 'Error: not found: %s', WASTEDIR /usr/local/src/Python-2.4.1/Mac/Tools/IDE/PyDebugger.py: raise 'spam' (3 times) /usr/local/src/Python-2.4.1/Mac/Tools/macfreeze/macfreeze.py: raise 'unknown gentype', gentype /usr/local/src/Python-2.4.1/Mac/Tools/macfreeze/macfreezegui.py: raise 'Error in gentype', gentype ___ 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
