Re: [Python-Dev] Fwd: Distributed RCS
Martin v. Löwis wrote: > [EMAIL PROTECTED] wrote: >>Granted. What is the cost of waiting a bit longer to see if it (or >>something else) gets more usable and would hit the mark better than svn? > > It depends on what "a bit" is. Waiting a month would be fine; waiting > two years might be pointless. This might be too convoluted to consider, but I thought I might throw it out there. We use svn for our repositories, but I've taken to also using bzr so I can do local commits and reversions (within a particular svn reversion). I can imagine expanding that usage to sharing branches and such via bzr (or mercurial, which looks great), but keeping the trunk in svn. -- Benji York ___ 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] string_join overrides TypeError exception thrown in generator
Stephen Thorne wrote: > I can't see an obvious solution, but perhaps generators should get > special treatment regardless. Reading over this code it looks like the > generator is exhausted all at once, instead of incrementally.. Indeed - str.join uses a multipass approach to build the final string, so it needs to ensure it has a reiterable to play with. PySequence_Fast achieves that, at the cost of dumping a generator into a sequence rather than building a string from it directly. Unicode.join uses PySequence_Fast too, and has the same problem with masking the TypeError from the generator. The calling code simply can't tell if the NULL return was set directly by PySequence_Fast, or was relayed by PySequence_List (which got it from _PyList_Extend, which got it from listextend, which got it from iternext, etc). This is the kind of problem that PEP 344 is designed to solve :) This also shows that argument validation is one of the cases where using an iterable instead of a generator is a good thing, since errors get raised where the generator is created, instead of where it is first used: class gen(object): def __init__(self): raise TypeError, "I am a TypeError" def __iter__(self): yield 1 def one(): return ''.join( x for x in gen() ) def two(): return ''.join([x for x in gen()]) for x in one, two: try: x() except TypeError, e: print e Hmm, makes me think of a neat little decorator: def step_on_creation(gen): def start_gen(*args, **kwds): g = gen(*args, **kwds) g.next() return g start_gen.__name__ = gen.__name__ start_gen.__doc__ = gen.__doc__ start_gen.__dict__ = gen.__dict__ return start_gen @step_on_creation def gen(): # Setup executed at creation time raise TypeError, "I am a TypeError" yield None # The actual iteration steps yield 1 Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 348 (exception reorg) revised again
[Brett] > This obviously goes against what Guido last said he > wanted, but I hope I can convince him to get rid of bare 'except's. -1 on eliminating bare excepts. This unnecessarily breaks tons of code without offering ANY compensating benefits. There are valid use cases for this construct. It is completely Pythonic to have bare keywords apply a useful default as an aid to readability and ease of coding. +1 on the new BaseException +1 on moving NotImplementedError, SystemExit, and KeyboardInterrupt. -1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except TerminatingException". 1) Grepping existing code bases shows that these two are almost never caught together so it is a bit silly to introduce a second way to do it. 2) Efforts to keep the builtin namespace compact argue against adding a new builtin that will almost never be used. 3) The change unnecessarily sacrifices flatness, making the language more difficult to learn. 4) The "self-documenting" rationale is weak -- if needed, a two-word comment would suffice. Existing code almost never has had to comment on catching multiple exceptions -- the exception tuple itself has been sufficiently obvious and explicit. This rationale assumes that code readers aren't smart enough to infer that SystemExit has something to do with termination. Raymond ___ 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] PEP 348 (exception reorg) revised again
On Mon, Aug 15, 2005 at 09:16:47AM -0400, Raymond Hettinger wrote: > It is completely Pythonic to have bare keywords > apply a useful default as an aid to readability and ease of coding. Bare "while:" was rejected because of "while WHAT?!". Bare "except:" does not cause "except WHAT?!" reaction. Isn't it funny?! (-: Oleg. -- Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED] Programmers don't die, they just GOSUB without RETURN. ___ 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] PEP 348 (exception reorg) revised again
> > It is completely Pythonic to have bare keywords > > apply a useful default as an aid to readability and ease of coding. [Oleg] >Bare "while:" was rejected because of "while WHAT?!". Bare "except:" > does not cause "except WHAT?!" reaction. Isn't it funny?! (-: It's both funny and interesting. It raises the question of what makes the two different -- why is one instantly recognizable and why does the other trigger a gag reflex. My thought is that bare excepts occur in a context that makes their meaning clear: try: block() except SpecificException: se_handler() except: handle_everything_else() The pattern of use is similar to a "default" in a switch-case construct. Viewed out-of-context, one would ask "default WHAT". Viewed after a series of case statements, the meaning is vividly clear. Raymond ___ 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] PEP 348 (exception reorg) revised again
On Monday 15 August 2005 14:16, Raymond Hettinger wrote: > -1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except > TerminatingException". The rationale for including TerminatingException in the PEP would also be satisfied by having a TerminatingExceptions tuple (in the exceptions module?). It makes sense to express the classification of exceptions that are intended to terminate the interpreter, but we dont need to express that classification as inheritence. -- Toby Dickenson ___ 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] PEP: Migrating the Python CVS to Subversion
On 8/8/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Nicholas Bastin wrote: > > It's a mature product. I would hope that that would count for > > something. > > Sure. But so is subversion. I will then assume that you and I have different ideas of what 'mature' means. > So I should then remove your offer to host a perforce installation, > as you never made such an offer, right? Correct. . > Yes. That's what this PEP is for. So I guess you are -1 on the > PEP. Not completely. More like -0 at the moment. We need a better system, but I think we shouldn't just pick a system because it's the one the PEP writer preferred - there should be some sort of effort to test a few systems (including bug trackers). I know this is work, but this isn't just something we can change easily again later. -- Nick ___ 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] build problems on macosx (CVS HEAD)
On 14-aug-2005, at 23:43, Martin v. Löwis wrote: > Ronald Oussoren wrote: > >> I'm trying to build CVS HEAD on OSX 10.4.2 (Xcode 2.1), with a >> checkout that is less than two hours old. I'm building a standard >> unix tree (no framework install): >> > > I just committed what I think is a bugfix for the recent st_gen > support. > Unfortunately, I can't try the code, since I don't have access to > BSD/OSX at the moment. > > So please report whether there is any change in behaviour. Your change has fixed this issue. Thanks for the quick response, Ronald > > Regards, > Martin > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/ > ronaldoussoren%40mac.com > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 348 (exception reorg) revised again
I'm with Raymond here. On 8/15/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > [Brett] > > This obviously goes against what Guido last said he > > wanted, but I hope I can convince him to get rid of bare 'except's. > > -1 on eliminating bare excepts. This unnecessarily breaks tons of code > without offering ANY compensating benefits. There are valid use cases > for this construct. It is completely Pythonic to have bare keywords > apply a useful default as an aid to readability and ease of coding. > > +1 on the new BaseException > > +1 on moving NotImplementedError, SystemExit, and KeyboardInterrupt. > > -1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except > TerminatingException". 1) Grepping existing code bases shows that these > two are almost never caught together so it is a bit silly to introduce a > second way to do it. 2) Efforts to keep the builtin namespace compact > argue against adding a new builtin that will almost never be used. 3) > The change unnecessarily sacrifices flatness, making the language more > difficult to learn. 4) The "self-documenting" rationale is weak -- if > needed, a two-word comment would suffice. Existing code almost never > has had to comment on catching multiple exceptions -- the exception > tuple itself has been sufficiently obvious and explicit. This rationale > assumes that code readers aren't smart enough to infer that SystemExit > has something to do with termination. > > > > Raymond > > ___ > 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/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
(1) Please use the SF patch manager.
(2) Please don't propose adding more bare "except:" clauses to the
standard library.
(3) I think a better patch is to use str(word)[:n] instead of word[:n].
On 8/14/05, Michael Krasnyk <[EMAIL PROTECTED]> wrote:
> Hello all,
>
> Recently I've found that rlcompleter does not work correctly with SWIG
> generated classes.
> In some cases dir(object) containes not only strings, but also type of
> the object, smth like .
> And condition "word[:n] == attr" throws an exception.
> Is it possible to solve this problem with following path?
>
> --- cut ---
> --- rlcompleter.py.org 2005-08-14 13:02:02.0 +0200
> +++ rlcompleter.py 2005-08-14 13:18:59.0 +0200
> @@ -136,8 +136,11 @@
> matches = []
> n = len(attr)
> for word in words:
> -if word[:n] == attr and word != "__builtins__":
> -matches.append("%s.%s" % (expr, word))
> +try:
> +if word[:n] == attr and word != "__builtins__":
> +matches.append("%s.%s" % (expr, word))
> +except:
> +pass
> return matches
>
> def get_class_members(klass):
> --- cut ---
>
> Thanks in advance,
> Michael Krasnyk
>
> ___
> 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/guido%40python.org
>
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 348 (exception reorg) revised again
OK, I will take this as BDFL pronouncement that ditching bare 'except's is just not going to happen. Had to try. =) And I will strip out the TerminatingException proposal. -Brett On 8/15/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I'm with Raymond here. > > On 8/15/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > > [Brett] > > > This obviously goes against what Guido last said he > > > wanted, but I hope I can convince him to get rid of bare 'except's. > > > > -1 on eliminating bare excepts. This unnecessarily breaks tons of code > > without offering ANY compensating benefits. There are valid use cases > > for this construct. It is completely Pythonic to have bare keywords > > apply a useful default as an aid to readability and ease of coding. > > > > +1 on the new BaseException > > > > +1 on moving NotImplementedError, SystemExit, and KeyboardInterrupt. > > > > -1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except > > TerminatingException". 1) Grepping existing code bases shows that these > > two are almost never caught together so it is a bit silly to introduce a > > second way to do it. 2) Efforts to keep the builtin namespace compact > > argue against adding a new builtin that will almost never be used. 3) > > The change unnecessarily sacrifices flatness, making the language more > > difficult to learn. 4) The "self-documenting" rationale is weak -- if > > needed, a two-word comment would suffice. Existing code almost never > > has had to comment on catching multiple exceptions -- the exception > > tuple itself has been sufficiently obvious and explicit. This rationale > > assumes that code readers aren't smart enough to infer that SystemExit > > has something to do with termination. > > > > > > > > Raymond > > > > ___ > > 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/guido%40python.org > > > > > -- > --Guido van Rossum (home page: http://www.python.org/~guido/) > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ 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] PEP 348 (exception reorg) revised again
On 8/15/05, Toby Dickenson <[EMAIL PROTECTED]> wrote: > On Monday 15 August 2005 14:16, Raymond Hettinger wrote: > > > -1 on replacing "except (KeyboardInterrupt, SystemExit)" with "except > > TerminatingException". > > The rationale for including TerminatingException in the PEP would also be > satisfied by having a TerminatingExceptions tuple (in the exceptions > module?). It makes sense to express the classification of exceptions that are > intended to terminate the interpreter, but we dont need to express that > classification as inheritence. > While the idea is fine, I just know that the point is going to be brought up that the addition should not be done until experience with the new hierarchy is had. I will add a comment that tuples can be added to the module after enough experience is had, but I am not going to try pushing for this right now. Of course I could be surprised and everyone could support the idea. =) -Brett ___ 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] PEP: Migrating the Python CVS to Subversion
On Mon, 2005-08-15 at 12:27 -0400, Nicholas Bastin wrote: > On 8/8/05, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Nicholas Bastin wrote: > > > It's a mature product. I would hope that that would count for > > > something. > > > > Sure. But so is subversion. > > I will then assume that you and I have different ideas of what 'mature' means. Bigger projects than Python use it and consider it mature for real use (All the Apache projects, all of KDE, GNOME is planning on switching soon, etc). I've never seen a corrupted FSFS repo, only corrupted BDB repos, and I will happily grant that using BDB ended up being a big mistake for Subversion. Not one that could have easily been foreseen at the time, but such is life. But this is why FSFS is the default for 1.2+ I've never seen you post about a corrupted repository to svn-users or svn-dev or file a bug, so i can't say why you see corrupted repositories if they are FSFS ones. --Dan ___ 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] PEP 348 (exception reorg) revised again
Toby Dickenson wrote: > On Monday 15 August 2005 14:16, Raymond Hettinger wrote: > > The rationale for including TerminatingException in the PEP would also be > satisfied by having a TerminatingExceptions tuple (in the exceptions > module?). It makes sense to express the classification of exceptions that are > intended to terminate the interpreter, but we dont need to express that > classification as inheritence. > An argument _for_ TerminatingException as a class is that I can define my own subclasses of TerminatingException without forcing it to being a subclass of KeyboardInterrupt or SystemExit. -- Scott David Daniels [EMAIL PROTECTED] ___ 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] PEP 348 (exception reorg) revised again
On 8/15/05, Scott David Daniels <[EMAIL PROTECTED]> wrote: > An argument _for_ TerminatingException as a class is that I can > define my own subclasses of TerminatingException without forcing > it to being a subclass of KeyboardInterrupt or SystemExit. And how would that help you? Would your own exceptions be more like SystemExit or more like KeyboardInterrupt, or neither? If you mean them to be excluded by base "except:", you can always subclass BaseException, which exists for this purpose. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP: Migrating the Python CVS to Subversion
Nicholas Bastin wrote:
> Not completely. More like -0 at the moment. We need a better system,
> but I think we shouldn't just pick a system because it's the one the
> PEP writer preferred - there should be some sort of effort to test a
> few systems (including bug trackers).
But that's how the PEP process works: the PEP author is supposed to
collect feedback from the community in a fair way, but he is not
required to implement every suggestion that the community makes.
People who strongly disagree that the entire approach should be taken
should write an alternative ("counter") PEP, proposing their strategy.
In the end, the BDFL will pronounce which approach (if any) should
be implemented.
In the specific case, I'm personally not willing to discuss every
SCM system out there. If somebody manages to make me curious (as
Guido did with the bazaar posts), I will try it out, if I can find
an easy way to do so. Your comments about (what was the name again)
did not make me curious.
As for bug trackers: this PEP is specifically *not* about bug
trackers at all. If you think the SourceForge bugtracker should
be replaced with something else, write a PEP. I really don't
see a reasonable alternative to the SF bugtracker.
> I know this is work, but this
> isn't just something we can change easily again later.
I don't bother asking who "we" is, here: apparently not you.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] SWIG and rlcompleter
Guido van Rossum wrote: > (1) Please use the SF patch manager. > > (2) Please don't propose adding more bare "except:" clauses to the > standard library. > > (3) I think a better patch is to use str(word)[:n] instead of word[:n]. Sorry to jump in, but this same patch was proposed for ipython, and my reply was that it appeared to me as a SWIG bug. From: http://www.python.org/doc/2.4.1/lib/built-in-funcs.html the docs for dir() seem to suggest that dir() should only return strings (I am inferring that from things like 'The resulting list is sorted alphabetically'). The docs are not fully explicit on this, though. Am I interpreting the docs correctly, case in which this should be considered a SWIG bug? Or is it OK for objects to stuff non-strings in __dict__, case in which SWIG is OK and then rlcompleter (and the corresponding system in ipython) do need to protect against this situation. I'd appreciate a clarification here, so I can close my own ipython bug report as well. Thanks, f ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] On distributed vs centralised SCM for Python
Pardon me for coming a little late to the SCM discussion, but I thought I would throw a few comments in. A little background: I've used Perforce, CVS, Subversion and BitKeeper for a number of years. Currently, I hack on Mercurial http://www.selenic.com/mercurial>. However, I'm not here to try and specifically push Mercurial, but rather to bring up a few points that I haven't seen made in the earlier discussions. The biggest distinguishing factor between centralised and decentralised SCMs is the kinds of interaction they permit between the core developer community and outsiders. The centralised SCM tools all create a wall between core developers (i.e. people with commit access to the central repository) and people who are on the fringes. Outsiders may be able to get anonymous read-only access, but they are left up to their own devices if they want to make changes that they would like to contribute back to the project. With centralised tools, any revision control that outsiders do must be ad-hoc in nature, and they cannot share their changes in a natural way (i.e. preserving revision history) with anyone else. I do not follow Python development closely, so I have no idea how open Python typically is to contributions from people outside the core CVS committers. However, it's worth pointing out that with a distributed SCM - it doesn't really matter which one you use - it is simple to put together a workflow that operates in the same way as a centralised SCM. You lose nothing in the translation. What you gain is several-fold: * Outsiders get to work according to the same terms, and with the same tools, as core developers. * Everyone can perform whatever work they want (branch, commit, diff, undo, etc) without being connected to the main repository in any way. * Peer-level sharing of changes, for testing or evaluation, is easy and doesn't clutter up the central server with short-lived branches. * Speculative branching: it is cheap to create a local private branch that contains some half-baked changes. If they work out, fold them back and commit them to the main repository. If not, blow the branch away and forget about it. Regardless of what you may think of the Linux development model, it is teling that there have been about 80 people able to commit changes to Python since 1990 (I just checked the cvsroot tarball), whereas my estimate is that about ten times as many used BitKeeper to contribute changes to the Linux kernel just since the 2.5 tree began in 2002. (The total number of users who contributed changes was about 1600, 1300 of whom used BK, while the remainder emailed plain old patches that someone applied.) It is, of course, not possible for me to tell which CVS commits were really patches that originated with someone else, but my intent is to show how the choice of tools affects the ability of people to contribute in "natural" ways. How much of the difference in numbers is due to the respective popularity or accessibility of the projects is anyone's guess. With any luck, there's some food for thought above. Regards, ___ 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] On distributed vs centralised SCM for Python
On Aug 15, 2005, at 5:04 PM, Bryan O'Sullivan wrote: > The centralised SCM tools all create a wall between core developers > (i.e. people with commit access to the central repository) and people > who are on the fringes. Outsiders may be able to get anonymous > read-only access, but they are left up to their own devices if they > want > to make changes that they would like to contribute back to the > project. But, if python is using svn, outside developers can seamlessly use svk (http://svk.elixus.org/) to do their own branches if they wish, no? Sure, that is "their own devices", but it seems a fairly workable solution to me as the two are so closely related. Now, I've never tried this, so I'm just judging from the "marketing material" on the svk website. James ___ 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] On distributed vs centralised SCM for Python
Bryan O'Sullivan wrote: > However, it's worth pointing out that with a distributed SCM - it > doesn't really matter which one you use - it is simple to put together a > workflow that operates in the same way as a centralised SCM. You lose > nothing in the translation. What you gain is several-fold: That may be off-topic for python-dev, but can you please explain how this works? > * Outsiders get to work according to the same terms, and with the > same tools, as core developers. I'm using git on the kernel level. In what way am I at the same level as the core developers? They can write to the kernel.org repository, I cannot. They use commit, I send diffs. > * Everyone can perform whatever work they want (branch, commit, > diff, undo, etc) without being connected to the main repository > in any way. So what? If I want to branch, I create a new sandbox. I have to do that anyway, since independent projects should not influence each other. I can also easily diff, whether I have write access or not (in svn, even simpler so than in CVS). There is no easy way to undo parts of the changes, that's true. > * Peer-level sharing of changes, for testing or evaluation, is > easy and doesn't clutter up the central server with short-lived > branches. So how does that work? If I commit the changes to my local version of the repository, how do they get peer-level-shared? I turn off my machine when I leave the house, and I don't have a permanent IP, anyway, to host a web server or some such. > * Speculative branching: it is cheap to create a local private > branch that contains some half-baked changes. If they work out, > fold them back and commit them to the main repository. If not, > blow the branch away and forget about it. I do that with separate sandboxes right now. cp -a py2.5 py-64bit gives me a new sandbox, in which I can do my speculative project. > Regardless of what you may think of the Linux development model, it is > teling that there have been about 80 people able to commit changes to > Python since 1990 (I just checked the cvsroot tarball), whereas my > estimate is that about ten times as many used BitKeeper to contribute > changes to the Linux kernel just since the 2.5 tree began in 2002. (The > total number of users who contributed changes was about 1600, 1300 of > whom used BK, while the remainder emailed plain old patches that someone > applied.) Hmm. The changes of these 800 people had to be approved by some core developers, or perhaps even all approved by Linus Torvalds, right? This is really the same for Python: A partial list of contributors is in Misc/ACKS (663 lines at the moment), and this doesn't list all the people who contributed trivial changes. So I guess Python has the same number of contributors per line as the Linux kernel. > It is, of course, not possible for me to tell which CVS commits were > really patches that originated with someone else, but my intent is to > show how the choice of tools affects the ability of people to contribute > in "natural" ways. I hear that, but I have a hard time believing it. People find the "cvs diff -u, send diff file for discussion to patches tracker" cycle quite natural. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] On distributed vs centralised SCM for Python
On Mon, 2005-08-15 at 23:29 +0200, "Martin v. Löwis" wrote: > That may be off-topic for python-dev, but can you please explain how > this works? It's simple enough. In place of a central server that hosts a set of repositories and a number of branches, and to which only a few people have access, you use a central server that hosts a number of repositories, and you get the idea. But the difference lies in the way you use it. In the centralised model, there's only one server, and only one repository, anywhere. In the distributed model, each developer has one or more repositories that they keep in sync with the central ones they are interested in, pulling and pushing changes as necessary. The difference is that they get to share changes horizontally if they wish, without going through the central server. > I'm using git on the kernel level. In what way am I at the same level > as the core developers? You can use the same tools to do the same things they can. You can communicate with them in terms of commits. You may each have access to different sets of servers from which other people can pull changes, but if they want to take changes from you, you have the option of giving them complete history of all the edits and merges you've done, with no information loss. > So how does that work? If I commit the changes to my local version of > the repository, how do they get peer-level-shared? You have to do something to share them, but it's a lot simpler than sending diffs to a mailing list, or attaching them to a bug tracking system note. > Hmm. The changes of these 800 people had to be approved by some core > developers, or perhaps even all approved by Linus Torvalds, right? True. > I hear that, but I have a hard time believing it. People find the > "cvs diff -u, send diff file for discussion to patches tracker" > cycle quite natural. People will find doing the same of anything, over and over for fifteen years, quite natural :-) ___ 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] On distributed vs centralised SCM for Python
[Bryan O'Sullivan] > > The centralised SCM tools all create a wall between core developers > > (i.e. people with commit access to the central repository) and people > > who are on the fringes. Outsiders may be able to get anonymous > > read-only access, but they are left up to their own devices if they > > want > > to make changes that they would like to contribute back to the > > project. [James Y Knight] > But, if python is using svn, outside developers can seamlessly use > svk (http://svk.elixus.org/) to do their own branches if they wish, > no? Sure, that is "their own devices", but it seems a fairly workable > solution to me as the two are so closely related. +1 This seems to be the most flexible and sensible idea so far. The svn system has had many accolades; Martin knows how to convert it; and it presents only a small learning curve to cvs users. Optionally adding svk to the mix allows us to get the benefits of a distributed system without any additional migration or support issues. Very nice. Raymond ___ 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] PEP 347: Migration to Subversion
[Martin v. Löwis] > I have placed a new version of the PEP on > > http://www.python.org/peps/pep-0347.html ... +1 from me. But, I don't think my vote should count much, and (sorry) Guido's even less: what do the people who frequently check in want? That means people like you (Martin), Michael, Raymond, Walter, Fred. ... plus the release manager(s). BTW, a stumbling block in Zope's conversion to SVN was that the conversion script initially never set svn:eol-style on any file. This caused weeks of problems, as people on Windows got Linux line ends, and people checking in from Windows forced Windows line ends on Linuxheads (CVS defaults to assuming files are text; SVN binary). The peculiar workaround at Zope is that we're all encouraged to add something like this to our SVN config file: """ [auto-props] # Setting eol-style to native on all files is a trick: if svn # believes a new file is binary, it won't honor the eol-style # auto-prop. However, svn considers the request to set eol-style # to be an error then, and if adding multiple files with one # svn "add" cmd, svn will stop adding files after the first # such error. A future release of svn will probably consider # this to be a warning instead (and continue adding files). * = svn:eol-style=native """ It would be best if svn:eol-style were set to native during initial conversion from CVS, on all files not marked binary in CVS. ___ 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] SWIG and rlcompleter
You don't need something like a buggy SWIG to put non-strings in dir(). >>> class C: pass ... >>> C.__dict__[3] = "bad wolf" >>> dir(C) [3, '__doc__', '__module__'] This is likely to happen "legitimately", for instance in a class that allows x.y and x['y'] to mean the same thing. (if the user assigns to x[3]) Jeff pgppqGM432Wx4.pgp Description: PGP signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cvs to bzr?
On Sun, 14 Aug 2005 21:39:41 -0500, skip wrote: > Lalo> You can, however, convert from CVS to baz (arch), and from there > Lalo> to bzr. > > Would this be with cscvs? According to the cscvs wiki page at > > http://wiki.gnuarch.org/cscvs > > cscvs is current unmaintained and can't handle repositories with branches. > In addition, it appears that to do a one-time convertsion from cvs to bzr I > will need to also install arch and baz as well as any other packages they > depend on. Canonical has had an ongoing project to pull many cvs trees into baz, for the benefit of our Ubuntu distribution people amongst other things. There are some people working on imports using (I think) a hacked version of cscvs, and I have asked them to get Python in as a high priority. Apparently there is something in the cvs history which makes a precise import hard. The cvs->baz->bzr process is unfortunate. As Mark said, we're going to be moving away from the Arch-based code and so trying to make that process simpler. -- Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Distributed RCS
On Mon, 2005-08-15 at 04:30, Benji York wrote: > Martin v. Löwis wrote: > > [EMAIL PROTECTED] wrote: > >>Granted. What is the cost of waiting a bit longer to see if it (or > >>something else) gets more usable and would hit the mark better than svn? > > > > It depends on what "a bit" is. Waiting a month would be fine; waiting > > two years might be pointless. > > This might be too convoluted to consider, but I thought I might throw it > out there. We use svn for our repositories, but I've taken to also > using bzr so I can do local commits and reversions (within a particular > svn reversion). I can imagine expanding that usage to sharing branches > and such via bzr (or mercurial, which looks great), but keeping the > trunk in svn. Not too convoluted at all; I already do exactly this with many upstream CVS and SVN repositorys, using a local PRCS for my own branches. I'm considering switching to a distributed RCS for my own branches because it would make it easier for others to share them. I think this probably is the best solution; it gives a reliable(?) centralised RCS for the trunk, but allows distributed development. -- Donovan Baarda <[EMAIL PROTECTED]> ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] rev. 1.9 of PEP 348: Raymond tested, Guido approved
OK, TerminatingException and the removal of bare 'except' clauses are now out. I also stripped out the transition plan to basically just add BaseException in Python 2.5, tweak docs to recommend future-proof practices, and then change everything in Python 3.0 . This will prevent any nasty performance hit from what was being previously suggested to try to make it all backwards-compatible. -Brett ___ 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] PEP 347: Migration to Subversion
Tim Peters wrote: > It would be best if svn:eol-style were set to native during initial > conversion from CVS, on all files not marked binary in CVS. Ok, I'll add that to the PEP. Not sure how to implement it, yet... Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
