Re: [Python-Dev] Using Cython for standard library?
On Tue, Nov 4, 2008 at 9:06 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> The project has made inclusion into Python's stdlib a goal right from the >> beginning. > > Ah, that changes my view of it significantly. If the authors want to > contribute it to Python some day, I'm looking forward to that (assuming > that they then close their official branch, and make the version inside > Python the maintained one). > > That is also independent of whether standard library modules get written > in Cython. I would expect that some may (in particular, if they focus on > wrapping an external library), whereas others might stay what they are > (in particular, when they are in the real core of the interpreter). I think it is also a good idea to write things using pure Python syntax in Cython, so that all other Python implementations, like Jython, Pypy, IronPython can just take it and run it in pure Python mode. Pure Python syntax means that the code runs in Python unmodified, but can also be compiled with Cython. Pure Python syntax was only recently added to Cython, so I guess it should be well tested first. What do you think? Ondrej ___ 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] Looking for VCS usage scenarios
2008/11/5 Stephen J. Turnbull <[EMAIL PROTECTED]>:
> > I see no excuse to let the fact that it's Python make it acceptable
> > to have an application with otherwise unacceptable performance.
>
> Barry and many others obviously find the performance of non-git VCSes
> acceptable. On the other hand, Brett has conceded that git's
> performance has enough fans that it has to be on the table (even
> though he admits to a strong bias against it, that's the major
> concession).
Oy! "Non-git VCSes" indeed! :-)
Barry and others find the performance of *Bazaar* acceptable. I (and
equally many others, I believe) don't. Mercurial is significantly
faster than Bazaar (I don't know how Mercurial speed compares to git
but both are orders of magnitude faster than Bazaar in at least some
cases).
I believe that the performance of Bazaar is still its major
disadvantage, regardless of the Bazaar developers' ongoing work on the
issue and the often-repeated "well, yes, but if you do things this
way, that's much faster" workarounds.
> Performance is *always* a consideration. IMO, now that it has been
> acknowledged that performance varies considerably among VCSes, it's
> more important at this point to figure out what Python development's
> *other* requirements are.
That is a fair point. My instinct is that python-dev's requirements on
a DVCS are likely to be fairly basic (at least initially) and most
DVCSes will be able to satisfy them. At that point, the arguments get
more difficult ("nice to have" extra features which may not actuially
get used in practice, we don't know without experience, versus
immediate performance benefits which could easily change over time).
Paul.
___
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] Looking for VCS usage scenarios
2008/11/3 Brett Cannon <[EMAIL PROTECTED]>: > At this point I am looking for any suggestions for fundamental usage > scenarios that I am missing from the PEP. If you think the few already > listed are missing some core part of a VCS, please let me know. My apologies, I can't check if this is already there (firewall rules from this account :-() but can I suggest the following use case: An average user (ie, not a core developer) finds an issue, and has an idea how to fix it. He raises a tracker item, checks out the Python sources, makes a fix, and wants to upload it to the tracker. Key points here are the initial work needed to grab a development checkout, and the ability to bundle up a fix for upload to the tracker. (I'm specifically thinking of a casual user, not a developer who already has a Python checkout to work on). I'll freely admit a (not very) hidden bias here - the slowness of an initial clone (or going through the "download a shared repo, unpack it, create a branch and update" rigmarole) makes this a nasty test for Bazaar. But I do nevertheless think it's an important use case, as it's all about encouraging casual users to contribute. Paul. ___ 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] test - please ignore
(working on spam system - just hit 'd') ___ 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] Using Cython for standard library?
Terry Reedy wrote: > Stefan Behnel wrote: >> I think the main advantage for stdlib modules is actually the maintenance >> cost. Having a single, easy-to-read code base for extension modules that >> compiles without modification in Py2.6/7 and Py3.0/3.1 (and 2.3, 2.4 and >> 2.5), makes life a lot easier for both maintainers and backporters. > > Do you have any plans to support/use 3.0 type annotations so that one > could develop function-oriented code in 3.0 and then compile efficient C > (for whatever CPython version) without adding Python-incompatible cdefs? That is still an official TODO, but there isn't currently any support for it, nor any effort to implement it (patches obviously welcome). The problem is that it only applies to function parameters, not to local variables or anything else, so the gain is actually very small. On the other hand, the "pure Python mode", as it is currently implemented, is much more powerful and allows you to annotate most things in Cython without loosing the ability to run the code unchanged in plain Python (including Jython and friends, although I never tested that). http://wiki.cython.org/pure One really neat feature is that you can put a .pxd file next to your .py file and let it override the function signatures and classes. So you do not even need Py3 annotations, which have the obvious disadvantage of requiring Py3. Stefan ___ 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] Looking for VCS usage scenarios
On 2008.11.05 11:09:24 +, Paul Moore wrote: > An average user (ie, not a core developer) finds an issue, and has an > idea how to fix it. He raises a tracker item, checks out the Python > sources, makes a fix, and wants to upload it to the tracker. Key > points here are the initial work needed to grab a development > checkout, and the ability to bundle up a fix for upload to the > tracker. (I'm specifically thinking of a casual user, not a developer > who already has a Python checkout to work on). > > I'll freely admit a (not very) hidden bias here - the slowness of an > initial clone (or going through the "download a shared repo, unpack > it, create a branch and update" rigmarole) makes this a nasty test for > Bazaar. But I do nevertheless think it's an important use case, as > it's all about encouraging casual users to contribute. All timings very approximate: Time for average user to check out Python sources with bzr: 10 minutes Time for average user to check out Python sources with git or hg: 1 minute Time for average user's trivial patch to be reviewed and committed: 1 year I love DVCS as much as the next guy, but checkout time is so not the bottleneck for this use case. -- David Ripton[EMAIL PROTECTED] ___ 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] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 5, 2008, at 6:09 AM, Paul Moore wrote: I'll freely admit a (not very) hidden bias here - the slowness of an initial clone (or going through the "download a shared repo, unpack it, create a branch and update" rigmarole) makes this a nasty test for Bazaar. But I do nevertheless think it's an important use case, as it's all about encouraging casual users to contribute. One thing that we're not taking advantage of on code.python.org for Bazaar is "stacked branches". This is basically an indirection technique that doesn't require a full revision history download to get started. Stacked branches greatly improve performance for the initial pull and push, and reduces disk usage on the server. When the new machine is in place, I'll make sure we provide stacked branches for the MvL Experiment. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRGqGHEjvBPtnXfVAQLuSAQAjStZk2nzSsvQN+bDwHryJUVKuutfz9uw ffCjaG9SRiXGaYSfNWs4Ao94fnYiRZVmqYiSHg8NTydR4g54sAF5FKbA1Bgswp9F l52ObdFWKhjwkpfuq1i+IAG2HEqZyiV0naZi4xQmMBKhFd2SFw+qUS9qzGExdCXw PFDYAiS9xKg= =bUlo -END PGP SIGNATURE- ___ 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] Looking for VCS usage scenarios
On Tue, Nov 4, 2008 at 23:19, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > FWIW, I don't consider the current bazaar installation sufficient here. > It does give a useful insight for those of us unfamiliar with that > kind of system, and certainly allows those who want to develop with bzr > already to do so - in the dvcs manner. However, for a complete "demo" > installation, I'd like to see a repository that contains all revisions, > not just selected ones, has post-commit email notifications (or > explains why it can't provide these), etc. > Without a doubt the bazaar branches need a little more loving attention to make them a full working demo, but it's mostly details. The branches *do* contain the whole history, and not just 'select revisions': 3.0% bzr log revno: 37403 committer: martin.v.loewis timestamp: Tue 2008-11-04 20:45:29 + message: Merged revisions 67098 via svnmerge from svn+ssh://[EMAIL PROTECTED]/python/trunk r67098 | martin.v.loewis | 2008-11-04 21:40:09 +0100 (Di, 04 Nov 2008) | 2 l ines Issue #4204: Fixed module build errors on FreeBSD 4. [...] revno: 2 committer: guido timestamp: Thu 1990-08-09 14:25:15 + message: Initial revision revno: 1 committer: timestamp: Thu 1990-08-09 14:25:15 + message: New repository initialized by cvs2svn. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Using Cython for standard library?
Martin v. Löwis wrote: Ah, that changes my view of it significantly. If the authors want to contribute it to Python some day, I'm looking forward to that (assuming that they then close their official branch, and make the version inside Python the maintained one). That is also independent of whether standard library modules get written in Cython. I would expect that some may (in particular, if they focus on wrapping an external library), whereas others might stay what they are (in particular, when they are in the real core of the interpreter). I would personally prefer a Cython integration over a ctypes one, for the standard library (and supported inclusion of ctypes into Python regardless). I agree from the bottom of my heart. In the past I've used Pyrex Cython for wrapping libraries and small snippets of C speedup with great success. The learning curve is smooth and experiments show quick success. Once Cython's development has slowed down and stabilized I like to see its usage for non-critical extension modules. Cython should make it easier to write wrappers for libraries or the IO performance improvement module, Amaury is working on. However I wouldn't want to use it for anything critical to the core of Python. I like to keep that C code of the core as readable as possible. Christian ___ 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] Looking for VCS usage scenarios
2008/11/5 Barry Warsaw <[EMAIL PROTECTED]>: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Nov 5, 2008, at 6:09 AM, Paul Moore wrote: > >> I'll freely admit a (not very) hidden bias here - the slowness of an >> initial clone (or going through the "download a shared repo, unpack >> it, create a branch and update" rigmarole) makes this a nasty test for >> Bazaar. But I do nevertheless think it's an important use case, as >> it's all about encouraging casual users to contribute. > > One thing that we're not taking advantage of on code.python.org for Bazaar > is "stacked branches". This is basically an indirection technique that > doesn't require a full revision history download to get started. Stacked > branches greatly improve performance for the initial pull and push, and > reduces disk usage on the server. While that would be good, my understanding is that stacked branches in Bazaar only work (for history operations) while you're online. So they make Bazaar work a little like a centralised VCS, I guess. Not sure how that's a step forward :-) > When the new machine is in place, I'll make sure we provide stacked branches > for the MvL Experiment. It would certainly be nice to be able to try such things out. Paul. ___ 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] Looking for VCS usage scenarios
2008/11/5 David Ripton <[EMAIL PROTECTED]>: > All timings very approximate: > > Time for average user to check out Python sources with bzr: 10 minutes > > Time for average user to check out Python sources with git or hg: 1 minute > > Time for average user's trivial patch to be reviewed and committed: 1 year > > I love DVCS as much as the next guy, but checkout time is so not the > bottleneck for this use case. :-) That's a fair point. But it's not the point I was trying to make, which is that I'd want whatever DVCS is chosen to make the initial experience of a casual user / newcomer as easy as possible. Why discourage them in the first 10 minutes (which, BTW, is much faster than my experience with bzr last time I tried the Python repo) when we can make them suffer for a whole year? :-) :-) Paul. ___ 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] Looking for VCS usage scenarios
David Ripton wrote: > Time for average user to check out Python sources with bzr: 10 minutes > Time for average user to check out Python sources with git or hg: 1 minute > Time for average user's trivial patch to be reviewed and committed: 1 year > I love DVCS as much as the next guy, but checkout time is so not the > bottleneck for this use case. I think Paul's point is that he wants to support people who have not previously planned to contribute to python. Writing the patch may be a matter of minutes, once they implement the fix for themselves. Downloading a new VCS is a major commitment of time and disk space. (And is there setup, and dealing with proxies?) It doesn't take as long (calendar) as waiting for the review, but it takes long enough (clock) that people may not bother to do it. And if they don't, what was the point of switching to a DCVS? -jJ ___ 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] Using Cython for standard library?
Stefan Behnel wrote: Terry Reedy wrote: Do you have any plans to support/use 3.0 type annotations so that one could develop function-oriented code in 3.0 and then compile efficient C (for whatever CPython version) without adding Python-incompatible cdefs? That is still an official TODO, but there isn't currently any support for it, nor any effort to implement it (patches obviously welcome). The problem is that it only applies to function parameters, not to local I was presuming some type inferencing for locals ;-) variables or anything else, so the gain is actually very small. Why I said 'function-oriented'. > On the other hand, the "pure Python mode", as it is currently implemented, is much more powerful and allows you to annotate most things in Cython without loosing the ability to run the code unchanged in plain Python (including Jython and friends, although I never tested that). http://wiki.cython.org/pure Ah. Missed it. Very interesting and even better. How is one supposed to get there from the main page? http://wiki.cython.org/Cython Perhaps under "*Using early binding techniques to improve speed" you could add "* Early binding in pure Python code." or some such. One really neat feature is that you can put a .pxd file next to your .py file and let it override the function signatures and classes. So you do not even need Py3 annotations, which have the obvious disadvantage of requiring Py3. That is not much of a disadvantage for code intended to be compiled. But the annotation is limited. Support for nested defs and generators is much more critical. Typo? Should 'typedef(cython.p_int)' be 'cython.typedef(cython.p_int)'? Also, the 'enhancement' page has separate misspelled 'seperate' twice. Terry Jan Reedy ___ 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] Looking for VCS usage scenarios
I apologize that I haven't read whatever Brett's written so far, but I just haven't had time, and don't know if there's a PEP yet (and if so, what its number is). I did want to get my questions/confusion on the record though. What DVCS fits my poor brain best? I feel I'm like a dinosaur not being able to figure out how I'm supposed to contribute changes to the system. Do I: * commit my changes to some central branch? * commit my changes locally then create diffs I then submit to the tracker? * commit locally then push them somewhere? * commit locally then ask someone to pull? * Not commit anything anywhere but just submit patches to the tracker? In addition: * Will there be a central repository? * How will I know which of possibly many repos is "authoritative"? * How will I discover other repos? For example, if the safethread stuff is sitting somewhere in a repository can I find it on my own somehow? * Will a DVCS allow simpler operation as if we are still using a centralized system like CVS or Subversion? Thx, Skip ___ 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] Why don't range and xrange threat floats as floats?
Why don't range and xrange threat floats as floats? Is there any good reason range and xrange don't threat floats as floats but as integers? When I enter float arguments in a range, the floats are treated as integers. (+ some warning) This is how I think it should work: >>>range(0, 1, 0.1) [0.0, 0.10001, 0.20001, 0.2, 0.40002, 0.5, 0.59998, 0.69996, 0.80004, 0.90002] I got these results by: >>>[x/10. for x in xrange(10)] I'm not looking for alternatives, just for the reason that it works this way. ___ 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] Looking for VCS usage scenarios
Paul Moore wrote: 2008/11/5 David Ripton <[EMAIL PROTECTED]>: All timings very approximate: Time for average user to check out Python sources with bzr: 10 minutes Time for average user to check out Python sources with git or hg: 1 minute Time for average user's trivial patch to be reviewed and committed: 1 year I love DVCS as much as the next guy, but checkout time is so not the bottleneck for this use case. :-) That's a fair point. But it's not the point I was trying to make, which is that I'd want whatever DVCS is chosen to make the initial experience of a casual user / newcomer as easy as possible. Why discourage them in the first 10 minutes (which, BTW, is much faster than my experience with bzr last time I tried the Python repo) when we can make them suffer for a whole year? :-) :-) It does get to the point that the current bottleneck is code review, to the point that people may not submit patches because it seems nearly useless*. And often, when a patch does get reviewed, the diff is obsolete and needs to be redone versus the changed 'current' trunk. I presume that patches as branches would alleviate this last part. So I think easier review should be a prime consideration for infrastructure improvement. If I go to the tracker now and click on a 'patch', I get a sometime easy, usually difficult, and sometimes impossible to read diff. With a wide-screen monitor, I would like a side-by-side display with differences marked, as with Guido's code review tool and other such displays I have seen here and there. *The current quick review and implementation of doc suggestions and patches, on the other hand, has encouraged more submissions from me and, I believe, others. ___ 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] Why don't range and xrange threat floats as floats?
On Wed, Nov 5, 2008 at 1:26 PM, L V <[EMAIL PROTECTED]> wrote: > Why don't range and xrange threat floats as floats? > Is there any good reason range and xrange don't threat floats as floats but > as integers? > When I enter float arguments in a range, the floats are treated as integers. > (+ some warning) > > This is how I think it should work: range(0, 1, 0.1) > [0.0, 0.10001, 0.20001, 0.2, > 0.40002, 0.5, 0.59998, 0.69996, > 0.80004, 0.90002] > > I got these results by: [x/10. for x in xrange(10)] > > I'm not looking for alternatives, just for the reason that it works this > way. This seems like a question to be asked on python-list, not python-dev. In any case, my best guess is that it's because of what you just showed, that the functionality you want is there already if you use a generator expression. There isn't much reason to make (x)range more complicated by letting it accept floats, when you can just scale the range you actually want up to some integral skip value, call range, and then scale it back down. -- Cheers, Leif ___ 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] Why don't range and xrange threat floats as floats?
On Wed, Nov 5, 2008 at 10:26 AM, L V <[EMAIL PROTECTED]> wrote: > Why don't range and xrange threat floats as floats? > Is there any good reason range and xrange don't threat floats as floats but > as integers? > When I enter float arguments in a range, the floats are treated as integers. > (+ some warning) > > This is how I think it should work: range(0, 1, 0.1) > [0.0, 0.10001, 0.20001, 0.2, > 0.40002, 0.5, 0.59998, 0.69996, > 0.80004, 0.90002] > > I got these results by: [x/10. for x in xrange(10)] > > I'm not looking for alternatives, just for the reason that it works this > way. The reason is that due to the rounding issues inherent to a binary representation of floating point, it is easy to give examples where it's ambiguous whether the end point was meant to be included or not. This could happen e.g. when the binary representation of the end point was rounded up a bit, while the step would be rounded down. -- --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] Why don't range and xrange threat floats as floats?
Thank you very much for your answer. I have wondered about this for a long time. From: Guido van Rossum <[EMAIL PROTECTED]> To: L V <[EMAIL PROTECTED]> Cc: [email protected] Sent: Wednesday, November 5, 2008 7:56:23 PM Subject: Re: [Python-Dev] Why don't range and xrange threat floats as floats? On Wed, Nov 5, 2008 at 10:26 AM, L V <[EMAIL PROTECTED]> wrote: > Why don't range and xrange threat floats as floats? > Is there any good reason range and xrange don't threat floats as floats but > as integers? > When I enter float arguments in a range, the floats are treated as integers. > (+ some warning) > > This is how I think it should work: range(0, 1, 0.1) > [0.0, 0.10001, 0.20001, 0.2, > 0.40002, 0.5, 0.59998, 0.69996, > 0.80004, 0.90002] > > I got these results by: [x/10. for x in xrange(10)] > > I'm not looking for alternatives, just for the reason that it works this > way. The reason is that due to the rounding issues inherent to a binary representation of floating point, it is easy to give examples where it's ambiguous whether the end point was meant to be included or not. This could happen e.g. when the binary representation of the end point was rounded up a bit, while the step would be rounded down. -- --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] Using Cython for standard library?
> I think it is also a good idea to write things using pure Python > syntax in Cython, so that all other Python implementations, like > Jython, Pypy, IronPython can just take it and run it in pure Python > mode. Pure Python syntax means that the code runs in Python > unmodified, but can also be compiled with Cython. Pure Python syntax > was only recently added to Cython, so I guess it should be well tested > first. > > What do you think? I wait. I have never dealt with Cython, and will leave it the time to mature that its authors find necessary. When it is ready, we will see what it can do. 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] Looking for VCS usage scenarios
> Without a doubt the bazaar branches need a little more loving attention > to make them a full working demo, but it's mostly details. The branches > *do* contain the whole history, and not just 'select revisions': But there are dozens of branches which aren't represented, plus all the tags (IIUC). Those would need to get converted also, don't you agree? 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] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 5, 2008, at 2:15 PM, Martin v. Löwis wrote: Without a doubt the bazaar branches need a little more loving attention to make them a full working demo, but it's mostly details. The branches *do* contain the whole history, and not just 'select revisions': But there are dozens of branches which aren't represented, plus all the tags (IIUC). Those would need to get converted also, don't you agree? Yes. My understanding, though I haven't tried it yet, is that newer versions of the bzr-svn plugin do a good job at a full conversion. Basically, every svn branch becomes a bzr branch and all svn tags are converted to bzr tags, which are not separate branches, but actual symbolic names for revisions in other branches. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRH2P3EjvBPtnXfVAQK/UAP+IuE4hOuixfS/YMv/7/8LYIABIkSxX7BT eO/9295aSeKnY57h32IGyBqPnd67fKYaJ58Be8fDdC3P15ks00wCFIsS4Q2v0LKI pDAxAn5GDRKQFoPZUnpMQXvBwEE9S08jEM7a24cyX111JHX0kVmcFy6nzDATQAv/ g8n03TgS1/g= =AC1n -END PGP SIGNATURE- ___ 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] Looking for VCS usage scenarios
> Yes. My understanding, though I haven't tried it yet, is that newer > versions of the bzr-svn plugin do a good job at a full conversion. > Basically, every svn branch becomes a bzr branch and all svn tags are > converted to bzr tags, which are not separate branches, but actual > symbolic names for revisions in other branches. Unless somebody had committed to the tag - right? 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] AST-level type inference optimizations
I wrote a patch to Tom Lee's AST optimization branch, which I have submitted at http://bugs.python.org/issue4264. Here's a brief explanation of what the patch does, followed by a little general discussion of the future. Python bytecode includes at least one operation which is not directly accessible from Python code: LIST_APPEND, which pops a value and a list off the stack and appends the value to the list. This is used in generating code for list comprehensions: [x for x in somelist] generates the following code for the body of the loop: ... LOAD_FAST 1#a local is generated to hold the new list LOAD_FAST 2 #the iteration variable, x LIST_APPEND ... Whereas if you were to try to write the comprehension directly, you would get: LOAD_FAST 1 LOAD_ATTR 0 #an index into the constant table: “append” LOAD_FAST 2 CALL_FUNCTION 1 #remove x and the append function from the top of the stack and push the result of the call POP_TOP This is much slower. In part, it’s the cost of doing the attribute lookup each time, which is why it’s common to see code like a = [] ap = a.append for x in ...: ap(x + ...) return a But the function call is naturally slower than the simpler LIST_APPEND operation. My patch tries to determine statically if a local is all circumstances holds a list, and if so, generates LIST_APPEND whenever user code would call local.append. It also works with the manual optimization mentioned above -- it tracks whether variables hold a method call to append on a list. It’s not perfect — in particular, I could track local types on a more fine-grained level than per-function. Anyway, the patch is a win on microbenchmarks. There's a lot more we could do with function-local type inference. We could eliminate temp variables, and unnecessary stores to variables that are never used again. We could potentially track the types of what goes into lists, and generate special-case code for numbers (using array), or strings (using stringio or something). And there's probably more than I'm not thinking of right now. What do you think? ___ 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] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 5, 2008, at 2:44 PM, Martin v. Löwis wrote: Yes. My understanding, though I haven't tried it yet, is that newer versions of the bzr-svn plugin do a good job at a full conversion. Basically, every svn branch becomes a bzr branch and all svn tags are converted to bzr tags, which are not separate branches, but actual symbolic names for revisions in other branches. Unless somebody had committed to the tag - right? That would be insane, right? :) - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSRH5o3EjvBPtnXfVAQLsYwQAoFSPuMOblPNegZNH63Oz8SrDEG9QMLqO ATvH/HHJAwuQ7Qz4WFiPLJbxf/JWLZZBKM2Idfk5z6icRXr1ynWbPn2SkcTtcAZ6 0G4KCYH/luOPJWTuzuWU+DBLp372Sp3psj2nJXnmmNgaxZyBZospe16pJS+mhpds cIUc6VEGGCI= =cMwI -END PGP SIGNATURE- ___ 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] Looking for VCS usage scenarios
On Wed, Nov 5, 2008 at 20:15, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Without a doubt the bazaar branches need a little more loving attention > > to make them a full working demo, but it's mostly details. The branches > > *do* contain the whole history, and not just 'select revisions': > > But there are dozens of branches which aren't represented, plus all the > tags (IIUC). Those would need to get converted also, don't you agree? > Before we can make the switch to Bazaar, sure -- if we do. But there is only a little history in those branches, compared to the history in the branches we have in bazaar now (trunk, 3.0, 2.6, 2.5), and the "demo" of how it would work is not affected by those other branches at all. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] Using Cython for standard library?
Terry Reedy wrote: > Stefan Behnel wrote: >> One really neat feature is that you can put a .pxd file next to your .py >> file and let it override the function signatures and classes. So you do >> not even need Py3 annotations, which have the obvious disadvantage of >> requiring Py3. > > That is not much of a disadvantage for code intended to be compiled. ... unless you have a reason for caring about a pure Python mode, which usually is because you want it to run in pure Python. :) When Cython becomes part of the stdlib, say, in Py3.1 and/or 2.7, this means that those future Python versions that support annotations will (mostly) also support Cython compilation. Earlier CPython platforms and non-CPython interpreters are the problem here. > Support for nested defs and generators is much more critical. Agreed. Given the current status of the implementation, that's only a question of time, not a technical issue. > Typo? Should 'typedef(cython.p_int)' be 'cython.typedef(cython.p_int)'? > Also, the 'enhancement' page has separate misspelled 'seperate' twice. Thanks for catching those. I also added a link to the Wiki. Stefan ___ 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] Looking for VCS usage scenarios
On Nov 5, 2008, at 12:16 PM, [EMAIL PROTECTED] wrote: I apologize that I haven't read whatever Brett's written so far, but I just haven't had time, and don't know if there's a PEP yet (and if so, what its number is). I did want to get my questions/confusion on the record though. What DVCS fits my poor brain best? I feel I'm like a dinosaur not being able to figure out how I'm supposed to contribute changes to the system. Do I: * commit my changes to some central branch? Not exactly. If you had commit access to the central repository you could commit then push, which would be the DVCS equivalent of committing to a central branch. * commit my changes locally then create diffs I then submit to the tracker? Possible. * commit locally then push them somewhere? If you have commit access this would be the way to get your changes in. * commit locally then ask someone to pull? Often preferred way to submit patches, as you can continue to maintain the patch locally against newer versions of trunk so that the patch is not obsolete by the time people finally get around to it. * Not commit anything anywhere but just submit patches to the tracker? Likely possible, but it's good to have the patch committed locally so you can modify it or continue to build upon it until it gets accepted. In addition: * Will there be a central repository? Generally there should be a central authoritative repository where people can turn to for the official version. * How will I know which of possibly many repos is "authoritative"? The authoritative repo should generally be linked to from the website so that people can easily find it. * How will I discover other repos? For example, if the safethread stuff is sitting somewhere in a repository can I find it on my own somehow? I'm not aware of any decentralized system for discovering repositories. Something like github or bitbucket could be used which help you discover repositories, but a wiki page with a list of alternative repositories and their purpose should suffice. * Will a DVCS allow simpler operation as if we are still using a centralized system like CVS or Subversion? I think commit locally then push (if you have commit access) or email a patch (or upload to tracker, etc) can work almost exactly as the subversion workflow (the only differences being possible slight variations on the command line interface). DVCS should enable more interesting workflows (like working against multiple remote repositories), but it shouldn't prevent the simple uses cases that people are used to from a centralized VCS. - Cosmin ___ 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] Looking for VCS usage scenarios
> Before we can make the switch to Bazaar, sure -- if we do. That is my whole point. Before we switch to whatever DVCS, this system should have a complete installation, with all pieces in place. I was just pointing out that the bazaar installation is not complete in this respect - I was not asking that it be completed, at least not at this point in time. 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] Looking for VCS usage scenarios
On Wed, Nov 5, 2008 at 03:09, Paul Moore <[EMAIL PROTECTED]> wrote: > 2008/11/3 Brett Cannon <[EMAIL PROTECTED]>: >> At this point I am looking for any suggestions for fundamental usage >> scenarios that I am missing from the PEP. If you think the few already >> listed are missing some core part of a VCS, please let me know. > > My apologies, I can't check if this is already there (firewall rules > from this account :-() but can I suggest the following use case: > > An average user (ie, not a core developer) finds an issue, and has an > idea how to fix it. He raises a tracker item, checks out the Python > sources, makes a fix, and wants to upload it to the tracker. Key > points here are the initial work needed to grab a development > checkout, and the ability to bundle up a fix for upload to the > tracker. (I'm specifically thinking of a casual user, not a developer > who already has a Python checkout to work on). > It's the first scenario, so yes, it's covered. -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] Looking for VCS usage scenarios
On Wed, Nov 5, 2008 at 07:35, Paul Moore <[EMAIL PROTECTED]> wrote: > 2008/11/5 David Ripton <[EMAIL PROTECTED]>: >> All timings very approximate: >> >> Time for average user to check out Python sources with bzr: 10 minutes >> >> Time for average user to check out Python sources with git or hg: 1 minute >> >> Time for average user's trivial patch to be reviewed and committed: 1 year >> >> I love DVCS as much as the next guy, but checkout time is so not the >> bottleneck for this use case. > > :-) That's a fair point. But it's not the point I was trying to make, > which is that I'd want whatever DVCS is chosen to make the initial > experience of a casual user / newcomer as easy as possible. Why > discourage them in the first 10 minutes (which, BTW, is much faster > than my experience with bzr last time I tried the Python repo) when we > can make them suffer for a whole year? :-) :-) And improving our tool set and issue workflow is to help with that time lag from patch submission to commit. We have to fix the means to the end in order to improve the end itself. -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] Looking for VCS usage scenarios
On Wed, Nov 5, 2008 at 10:16, <[EMAIL PROTECTED]> wrote: > > I apologize that I haven't read whatever Brett's written so far, but I just > haven't had time, and don't know if there's a PEP yet (and if so, what its > number is). I did want to get my questions/confusion on the record though. > It's currently just a draft on Google Docs: http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . > What DVCS fits my poor brain best? I feel I'm like a dinosaur not being > able to figure out how I'm supposed to contribute changes to the system. I will add an Typical Workflow section to the PEP so people get an idea of what it would most likely be like. -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] Looking for VCS usage scenarios
On Wed, Nov 5, 2008 at 12:45, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: >> Before we can make the switch to Bazaar, sure -- if we do. > > That is my whole point. Before we switch to whatever DVCS, this > system should have a complete installation, with all pieces in > place. > > I was just pointing out that the bazaar installation is not > complete in this respect - I was not asking that it be completed, > at least not at this point in time. > And I agree with Martin we will need a full install, but might as well see if we can eliminate a DVCS from the list first before going to the trouble of getting a full installation going. -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] Looking for VCS usage scenarios
Paul Moore wrote: > 2008/11/5 Barry Warsaw <[EMAIL PROTECTED]>: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On Nov 5, 2008, at 6:09 AM, Paul Moore wrote: >> >>> I'll freely admit a (not very) hidden bias here - the slowness of an >>> initial clone (or going through the "download a shared repo, unpack >>> it, create a branch and update" rigmarole) makes this a nasty test for >>> Bazaar. But I do nevertheless think it's an important use case, as >>> it's all about encouraging casual users to contribute. >> One thing that we're not taking advantage of on code.python.org for Bazaar >> is "stacked branches". This is basically an indirection technique that >> doesn't require a full revision history download to get started. Stacked >> branches greatly improve performance for the initial pull and push, and >> reduces disk usage on the server. > > While that would be good, my understanding is that stacked branches in > Bazaar only work (for history operations) while you're online. So they > make Bazaar work a little like a centralised VCS, I guess. Not sure > how that's a step forward :-) You only need full history in order to ask "how did this code get to this state" type questions. That's something a core dev will occasionally want to know (which is why we would take to the time to setup a full checkout no matter how long it takes), but utterly irrelevant to a casual committer such as the one in your "write and submit a quick patch" scenario. Also, the DVCSs shouldn't be compared just against each other - we need the benchmark numbers against the current SVN repository as well. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ 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] Looking for VCS usage scenarios
2008/11/5 Nick Coghlan <[EMAIL PROTECTED]>: > Paul Moore wrote: >> While that would be good, my understanding is that stacked branches in >> Bazaar only work (for history operations) while you're online. So they >> make Bazaar work a little like a centralised VCS, I guess. Not sure >> how that's a step forward :-) > > You only need full history in order to ask "how did this code get to > this state" type questions. That's something a core dev will > occasionally want to know (which is why we would take to the time to > setup a full checkout no matter how long it takes), but utterly > irrelevant to a casual committer such as the one in your "write and > submit a quick patch" scenario. Agreed. But I'm very hazy on how Bazaar stacked branches work in practice. If I create a nice fast stacked branch on my PC, then go offline, precisely what operations can I no longer do? And will the ones that can't work fully, work "for the first bit" (by which I mean something like bzr log | less, exiting before I page through the lot - that's my normal history search process, because my poor brain is too slow to remember the flags to limit the history :-))? Anyway, this is probably getting too much into details to be useful. Paul. ___ 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] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martin v. Löwis wrote: >> Yes. My understanding, though I haven't tried it yet, is that newer >> versions of the bzr-svn plugin do a good job at a full conversion. >> Basically, every svn branch becomes a bzr branch and all svn tags are >> converted to bzr tags, which are not separate branches, but actual >> symbolic names for revisions in other branches. > > Unless somebody had committed to the tag - right? svn doesn't have any true tags, AFAIK: everything is a branch. Committing to a tag for "housekeeping" is a not-uncommon pattern in some projects (e.g., to avoid making spurious housekeeping commits on the source branch which have to be undone after making the tag). The canonical example would be changing the 'version' argument passed to distutils / setuptools setup(). Under this culture / pattern, one would tag the release, then modify the version on the quasi-tag branch, rather than committing the released version of setup.py to the source branch, only to follow it immediately with another commit reverting the release-specific change. Tres. - -- === Tres Seaver +1 540-429-0999 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJEkAM+gerLs4ltQ4RAoztAKDKP4kACUon4vWNg78eZHg3ZL45CgCgkfn0 yXz5q1bhwWs77u3j/6isgOQ= =oqoH -END PGP SIGNATURE- ___ 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] Looking for VCS usage scenarios
Barry Warsaw writes: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Nov 5, 2008, at 2:44 PM, Martin v. Löwis wrote: > > Unless somebody had committed to the tag - right? > > That would be insane, right? :) AFAIK it's not insane, just impossible. Of course in any system you can use "vc tag --force TAG-TO-OVERWRITE". ___ 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] Looking for VCS usage scenarios
In what follows, caveat IANB (I am not Brett, and neither is Cosmin), but there is some experience with these systems, and my recommendations are based on that. Cosmin Stejerean writes: > On Nov 5, 2008, at 12:16 PM, [EMAIL PROTECTED] wrote: > > What DVCS fits my poor brain best? I feel I'm like a dinosaur > > not being able to figure out how I'm supposed to contribute > > changes to the system. You need not feel that way. It's not you---the flexibility of dVCS means that until the Powers That Be promulgate a Workflow, this will be ambiguous. This is part of the purpose of the PEP. We[1] will be presenting the 5-finger exercises required to accomplish typical (and perhaps some not-so-typical) tasks, as well as benchmarks for the various systems. > > Do I: > > > >* commit my changes to some central branch? Call this the "record && commit to authoritative" workflow. > Not exactly. If you had commit access to the central repository you > could commit then push, which would be the DVCS equivalent of > committing to a central branch. The workflow where general contributors commit directly to the trunk surely won't be used in Python, because of the instability it would cause. It would be possible to have a staging branch for this purpose, but IMO that's not a very effective use of a dVCS.[2] It is useful to avoid the term "commit" here because its semantics vary across systems. As Cosmin points out, in a dVCS, what is accomplished by "vc commit" in CVS is done as "vc commit; vc push". I use the terminology "record" for the action of adding a workspace- based patch or snapshot to a repository. "push" (and "pull") move content between repositories. Unfortunately "commit" is the name of the record command in most dVCSes, so this terminology probably won't catch on. Also, when talking about "where to commit" in terms of communication among developers, you should probably refer to storage locations as "repositories". "Branch" is another term that has varying semantics in different VCSes. In some systems (git) it is reasonable to think of repositories containing more than one branch, and branches as existing in more than one repository (but this isn't quite robust in git because branch names are just names, not first-class objects). In others (Darcs is the extreme) repository == branch == workspace. (I'm trying to get permission to publish a 3rd party's draft document that goes into these issues in detail; here I just want to raise awareness that the intuitions that go with CVS/Subversion usage of various terms is *not* always going to carry over to dVCSes.) > >* commit my changes locally then create diffs I then submit to the > > tracker? "Record && patch" workflow. > Possible. But again not very effective. Under a dVCS I believe these patches will languish in the tracker as they do today, unless tools are written to automatically pull them into a repo somewhere. > >* commit locally then push them somewhere? "Record && push to candidate" workflow. If we go with Bazaar, this is very likely to occur, especially if Canonical's launchpad is the host. This is what Linux kernel does on git.kernel.org as well, if I understand their workflow correctly, and what github helps to support. I imagine Mercurial has an equivalent but I'm not familiar with it. > >* commit locally then ask someone to pull? "Record && request pull" workflow. > Often preferred way to submit patches, as you can continue to maintain > the patch locally against newer versions of trunk so that the patch is > not obsolete by the time people finally get around to it. I disagree. This doesn't scale to Python size. For distributed VC to work, somebody has to maintain a repo 24x7. Python has to do this for the trunk; the additional burden for contributed patches is not great. There is no real advantage to having contributors do so, too.[3] Integrators and interested third parties also must keep track of contributor's repo URLs. (Cf. Skip's question about discovering repos.) Not happy stuff. The "record && push" workflow scales much better for numbers of contributors, as each contributor needs only to maintain one "push" URL, and integrators only one "pull" base URL. > >* Not commit anything anywhere but just submit patches to the > > tracker? "Patch from workspace" workflow. > Likely possible, but it's good to have the patch committed locally so > you can modify it or continue to build upon it until it gets accepted. The same considerations as "record && patch" also apply here. > > In addition: > > > >* Will there be a central repository? > > Generally there should be a central authoritative repository where > people can turn to for the official version. Ie, "yes". There's no point in a PEP unless there's going to be a central repo and a defined workflow for getting contributions into it. Note that you can always maintain your own local repo w
Re: [Python-Dev] Looking for VCS usage scenarios
Tres Seaver writes: > svn doesn't have any true tags, AFAIK: everything is a branch. Yow! I couldn't have imagined that would be true. And didn't ___ 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] DVCS PEP update
On Tue, Nov 4, 2008 at 16:34, Brett Cannon <[EMAIL PROTECTED]> wrote: > OK, I give: git is in the running. But do realize it will take a lot > for it to beat out bzr or hg. > > I have emailed some people who have shown allegiance to a specific > DVCS to seeif they are willing to fill in the usage scenarios for me > along with converting the dev FAQ so that we all have a clear way to > learn how to use the things. If any of the people I emailed turn down > being the leader fo ra specific DVCS I will email here looking for > volunteers. So my first choice for Mercurial fell through. If you would like to represent Mercurial, let me know. -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] Looking for VCS usage scenarios
On Wed, Nov 5, 2008 at 17:36, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > In what follows, caveat IANB (I am not Brett, and neither is > Cosmin), but there is some experience with these systems, and my > recommendations are based on that. > Wow, I'm part of an acronym! That's a first. > Cosmin Stejerean writes: > > On Nov 5, 2008, at 12:16 PM, [EMAIL PROTECTED] wrote: > > > > What DVCS fits my poor brain best? I feel I'm like a dinosaur > > > not being able to figure out how I'm supposed to contribute > > > changes to the system. > > You need not feel that way. It's not you---the flexibility of dVCS > means that until the Powers That Be promulgate a Workflow, this will > be ambiguous. > It also took me quite a while to finally grasp exactly how the typical workflow could go with a DVCS. > This is part of the purpose of the PEP. We[1] will be presenting the > 5-finger exercises required to accomplish typical (and perhaps some > not-so-typical) tasks, as well as benchmarks for the various systems. > > > > Do I: > > > > > >* commit my changes to some central branch? > > Call this the "record && commit to authoritative" workflow. > > > Not exactly. If you had commit access to the central repository you > > could commit then push, which would be the DVCS equivalent of > > committing to a central branch. > > The workflow where general contributors commit directly to the trunk > surely won't be used in Python, because of the instability it would > cause. It would be possible to have a staging branch for this > purpose, but IMO that's not a very effective use of a dVCS.[2] > I assume by "general contributor" you mean "anybody" and not "core developer". > It is useful to avoid the term "commit" here because its semantics > vary across systems. As Cosmin points out, in a dVCS, what is > accomplished by "vc commit" in CVS is done as "vc commit; vc push". I > use the terminology "record" for the action of adding a workspace- > based patch or snapshot to a repository. "push" (and "pull") move > content between repositories. Unfortunately "commit" is the name of > the record command in most dVCSes, so this terminology probably won't > catch on. > This is why there is a Terminology section to the PEP; people have not fully agreed on terms yet. > Also, when talking about "where to commit" in terms of communication > among developers, you should probably refer to storage locations as > "repositories". "Branch" is another term that has varying semantics > in different VCSes. In some systems (git) it is reasonable to think > of repositories containing more than one branch, and branches as > existing in more than one repository (but this isn't quite robust in > git because branch names are just names, not first-class objects). In > others (Darcs is the extreme) repository == branch == workspace. > > (I'm trying to get permission to publish a 3rd party's draft document > that goes into these issues in detail; here I just want to raise > awareness that the intuitions that go with CVS/Subversion usage of > various terms is *not* always going to carry over to dVCSes.) > > > >* commit my changes locally then create diffs I then submit to the > > > tracker? > > "Record && patch" workflow. > > > Possible. > > But again not very effective. Under a dVCS I believe these patches > will languish in the tracker as they do today, unless tools are > written to automatically pull them into a repo somewhere. > > > >* commit locally then push them somewhere? > > "Record && push to candidate" workflow. > > If we go with Bazaar, this is very likely to occur, especially if > Canonical's launchpad is the host. This is what Linux kernel does on > git.kernel.org as well, if I understand their workflow correctly, and > what github helps to support. I imagine Mercurial has an equivalent > but I'm not familiar with it. > http://www.bitbucket.org has free Mercurial hosting for open source projects. As for how git.kernel.org works, I believe that won't work for Python without a cultural shift in how Python development happens. Linus has subsystem maintainers who are in charge of certain subsections of the Linux kernel. They are the ones that accept the various patches from people contributing. I believe Linus then pulls from these people into his tree which is basically the authoritative tree for the kernel. For Python development we don't really have subsystem maintainers. We have unofficial ones (e.g. Georg with the docs), but I honestly think that this has not worked for us over the years as people come and go. I think part of the reason the Linux kernel can get away with the structure it has is because people get paid to help maintain it while we don't. Plus I don't think Guido wants to act as BDFL on every potential patch into Python with his 50% time. > > >* commit locally then ask someone to pull? > > "Record && request pull" workflow. > > > Often preferred way to submit patches,
Re: [Python-Dev] Looking for VCS usage scenarios
Brett Cannon writes:
> > You need not feel that way. It's not you---the flexibility of dVCS
> > means that until the Powers That Be promulgate a Workflow, this will
> > be ambiguous.
>
> It also took me quite a while to finally grasp exactly how the typical
> workflow could go with a DVCS.
I don't think there is a "typical" workflow for DVCS yet. For
example, unreconstructed Archers generally do use a "record && request
pull" (from their local repos) workflow. On the other hand, XEmacs
treats its Mercurial repository as "CVS that can do merges sanely"---
patches are submitted to a mailing list for review, but I don't think
any of the core devs' patches ever get applied any more; rather they
go into the trunk quickly and devs and testers alike pull them from
there. The Bazaar guys have a crazy quilt of "Bundle Buggies" and
"Patch Queue Managers" semi-integrated into Launchpad. The Darcs
people have a surprisingly traditional "record && send patch" workflow.
My opinion is that Python's current workflow is pretty good, and
there's not reason to start anywhere but there.
As has been acerbically mentioned, like most mature projects with a
fairly close-knit group of core devs there are problems with casual
contributors' patches getting neglected. I think that a DVCS can
contribute fairly directly to more efficient reviewing, and it will be
easier to make workflow improvements needed for efficient reviewing
with a DVCS.
Hm ... those require ideas would require the contributor to use the
DVCS. That may be an argument for a Python-based VCS that could be
bundled with the sources, an hg-lite or bzr-lite. ("But git is still
faster!")
> > The workflow where general contributors commit directly to the trunk
> > surely won't be used in Python, because of the instability it would
> > cause.
>
> I assume by "general contributor" you mean "anybody" and not "core
> developer".
That's right. The current workflow where the senior committers "fire
at will", except when the svn repo is frozen for a release, could be
simulated exactly with any of the DVCSes.
It might make sense to have an alternative workflow that restricts the
"next-to-be-released" repo to the release manager, but that is a
discussion for later, not something that should be implemented
immediately (if at all).
> This is why there is a Terminology section to the PEP; people have not
> fully agreed on terms yet.
I forgot to mention that although your terminology is somewhat
different from what I recommend, so far your definitions seem coherent
and your usage accurate. ("Seem" is not a reflection on you, but on
the inherent ambiguity in trying to adapt terms developed for CVS to
DVCSes.)
> As for how git.kernel.org works, I believe that won't work for Python
> without a cultural shift in how Python development happens. Linus has
> subsystem maintainers who are in charge of certain subsections of the
> Linux kernel.
In bringing up git.kernel.org, I'm not referring to the project
workflow, just to the ability to freely create branches and/or
subsidiary repos, and easily browse them on the host. At least for
core devs, and in the case of Launchpad, I believe anyone with a
Launchpad user can create repos.
OTOH, any workflow changes can and IMO should be discussed and
implemented gradually.
> We have http://code.python.org/ for this. And yes, you kind of just
> have to know since any random branches that might be out there will
> not be in the branches/ directory like in svn. But honestly how often
> does anyone just browse the branches/ directory anyway?
I don't know about svn; I find it pretty painful to use for anything
but sequential tasking (update ... hack ... commit ... repeat). But
if you look at http://git.kernel.org/, you'll see a thicket of repos,
each of which probably contains a few to a few hundred[1] branches
(mostly merged to repo mainline or abandoned, of course). I hear
kernel devs *do* browse those to find out what each other are up to,
as do lkml wannabes. I know that even locally, I often abandon tasks
on XEmacs where I've bitten off more than I want to chew at the
moment. When I do free up some time, browsing my stale branches is a
common way to find a project.
Again, this possibility is not an imperative to "be like Linux
kernel", but it is an opportunity to improve the technology for
communication among developers.
Footnotes:
[1] Seriously. git had to develop a packed format for its list of
branches and tags because people use so many of them it was impacting
performance!
___
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] Looking for VCS usage scenarios
> > > Unless somebody had committed to the tag - right? > > > > That would be insane, right? :) > > AFAIK it's not insane, just impossible. IIRC, I did that for the 2.5.2 tag (or some such), correcting the spelling of "2st" to "2nd" for the release date. 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
