Re: [Python-Dev] My patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 30, 2008, at 10:22 AM, Eric Smith wrote: Ulrich Eckhardt wrote: On Thursday 30 October 2008, Victor Stinner wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. Yeah, exactly :-) Does anyone already maintain a distributed tree? Mercurial, GIT, anything else? Bazaar. Take a look at the developers' pages on python.org, they mention that a BZR checkout is available. I know that it works (though the initial checkout is glacially slow) but I don't know what "official" support it has or what is planned with it. I'd like to try it out, but the instructions on http://www.python.org/dev/bazaar/ say to get wget http://code.python.org/snapshots/python-bzr-snapshot.tar.bz2 , which is a 404. Anyone know the actual URL? This is fixed now. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ2eDnEjvBPtnXfVAQJf+gP7BvsB7NtENGqbQR7oGMGjie75MrEn362Y hXcgALWn9UkaiSdcrL+b9DFLY8MYppYUvKEJw92gU9jMzIzgcdH57DGBkudx/PHS hkvPhtGewdSX1QY88CkOYjJ7UYnhrhZWUzN67Yea16QKBwPKQFljsC26toqX+08k J+vZDkAsmwE= =Gy0x -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] My patches
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 30, 2008, at 11:04 AM, A.M. Kuchling wrote: On Thu, Oct 30, 2008 at 11:04:42AM +, Barry Warsaw wrote: One of the reasons why I'm very keen on us moving to a distributed version control system is to help break the logjam on core developers. True, your code will still not be able to land in the "official" branch without core developer intervention, but you will be able to share your code, fixes, branches with everyone in a much more live way than patches in a tracker. I don't see how a DVCS will fix anything. The bottleneck is in assessing patches for inclusion in the master tree; not enough people are doing that. We'd just end up with lots of proposed branches waiting to be merged, instead of patches to be applied. I disagree. Dealing with patches is much more painful than dealing with branches. A patch is a dead thing sitting in a tracker. They easily get out of date, are difficult to apply and update, etc. Live branches are much easier to review, update, track changes in the trunk, and share. Yes, it still means we'll have a lot of branches to review, but the overhead of reviewing them and shepherding them to landing will go down. (What a DVCS might enable is making it easier to do larger experiments, like the recent Vmgen work, and publish them in a form that people can download. We could create SVN branches now, but that means people would then have commit access to all of the Python source.) A dvcs means that people can publish their branches in a wide variety of ways. Trusted developers can push their branches to code.python.org. Non-core developers can use one of the free public dvcs branch hosting service. Industrious users can self-publish their branches. Anyone with email can bundle a branch and send it via a smart email package (much different than just-a-patch). This means both large and small experiments are very easy to perform. So are small branches that fix a particular bug or add a small feature. In a good dvcs, branches are very cheap to make and share, regardless of whether you're a core developer or a casual hacker. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ2gLXEjvBPtnXfVAQJlaQQAq8uOlzqCjZbukBOj3Na5CqzUu1xaS4RU 356FpQO2TykQDguNp0dOq40JGJGvypsvDCh89YTT+c32M0KfxftQ/h0cHbC7Vjs5 0pXCdXA+WIAyiCVbql7iBxxvmPB2FfEyhN5TPGdMe2R6c+Cp5zCt4zxL6RAeLZ+F ITJsJt4Suvw= =wK17 -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] Fwd: Removal of GIL through refcounting removal.
On Sun, 02 Nov 2008 10:21:26 +1000, Nick Coghlan wrote: > Maciej Fijalkowski wrote: >>> ... >> >>> We know it is the plan for PyPy to work in this way, and also that >>> Jython and Ironpython works like that (using the host vm's GC), so it >>> seems to be somehow agreeable with the python semantics (perhaps not >>> really with __del__ but they are not really nice anyway). >>> >>> >> PyPy has a semi-advanced generational moving gc these days. It's not as >> well tuned as JVMs one, but it works quite well. Regarding semantic >> changes, there is a couple which as far as I remember are details which >> you should not rely on anyway (At least some of the below applies also >> for Jython/IronPython): >> >> * __del__ methods are not called immediately when object is not in a >> cycle >> >> * all objects are collected, which means objects in cycles are broken >> in arbitrary order (gc.garbage is always empty), but normal ordering is >> preserved. >> >> * id's don't always resemble address of object in memory >> >> * resurrected objects have __del__ called only once in total. > > Yep, I'm pretty those are all even explicitly documented as > implementation details of CPython (PEP 343's with statement was largely > added as a cross-implementation way of guaranteeing prompt cleanup of > resources like file handles without relying on CPython's __del__ > semantics or writing your own try/finally statements everywhere). Though there is a fair difference from "explicitly documented as implementation details" and the real-world code where programmers have learnt to save code lines by relying on the reference-counting semantics. [[ my 0.2: it would be a great loss if we lose reference-counting semantic (eg: objects deallocated as soon as they exit the scope). I would bargain that for a noticable speed increase of course, but my own experience with standard GCs from other languages has been less than stellar. ]] -- Giovanni Bajo Develer S.r.l. http://www.develer.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] buffer function
i am using it postgresql as back-end and HTML as front-end,i want to display 10-10 records at a time which is there in the database using python.so what is function for buffer that we can use it in python?i am able to connect my databse in python,but dont know how to create buffer in python and how to take records from tables which are there in the database?can please provide me any kind of function or code for buffer in python? i have one more doubt that how to call python script in HTML? PLEASE REPLY ___ 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] buffer function
Aditi Meher wrote: > i am using it postgresql as back-end and HTML as front-end,i want to > display 10-10 records at a time which is there in the database using > python.so what is function for buffer that we can use it in python?i > am able to connect my databse in python,but dont know how to create > buffer in python and how to take records from tables which are there > in the database?can please provide me any kind of function or code for > buffer in python? > > i have one more doubt that how to call python script in HTML? > > PLEASE REPLY Please submit this question to the comp.lang.python group (python-list at python dot org). Python-dev is for discussion or the development *of* Python, not development *with* Python. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
Hi, Jesse Noller gmail.com> writes: > If python were to have free threading, courtesy of a lack > of the GIL, it would help those people quite a bit. Sometimes you just > need shared state. Myself? I used multiprocess *and* threads all the > time for various reasons. I think it is important to remind that the GIL doesn't prevent (almost) true multithreading. The only thing it prevents is full use of multi-CPU resources in a single process. But if you are using threads to reduce latencies rather than increase throughput, the GIL isn't really an obstacle (it probably makes things a bit worse than a free-threading scenario, but not that much; and you can tweak sys.setcheckinterval()). Regards Antoine. ___ 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] Fwd: Removal of GIL through refcounting removal.
Michael Foord wrote: > Moving more C extensions to an implementation based on ctypes would be > enormously useful for PyPy, IronPython and Jython, but ctypes is not yet > as portable as Python itself which could be an issue (although one worth > resolving). In the same line, moving more extensions to a high-level language like Cython, instead of writing them in straight C, would make a later switch to a different environment a lot easier, as the extensions could be regenerated with a modified Cython compiler (obviously minus some fixing of premature optimisations and the like). 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] Fwd: Removal of GIL through refcounting removal.
Giovanni Bajo wrote: [[ my 0.2: it would be a great loss if we lose reference-counting semantic (eg: objects deallocated as soon as they exit the scope). I would bargain that for a noticable speed increase of course, but my own experience with standard GCs from other languages has been less than stellar. ]] And my $0.02: I'd gladly trade deterministic destruction (due to reference counting or any other mechanism) for improved performance. I've often thought of creating a mode where destruction didn't happen right away with reference counting, just so I could find places where I'm relying on it. I consider it a bug to rely on reference counting to close files, for example. Maybe I should just run under Jython or IronPython everyone once in a while. ___ 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] Fwd: Removal of GIL through refcounting removal.
On Sun, Nov 2, 2008 at 2:34 PM, Eric Smith <[EMAIL PROTECTED]> wrote: > Giovanni Bajo wrote: >> >> [[ my 0.2: it would be a great loss if we lose reference-counting semantic >> (eg: objects deallocated as soon as they exit the scope). I would bargain >> that for a noticable speed increase of course, but my own experience with >> standard GCs from other languages has been less than stellar. ]] > > And my $0.02: > > I'd gladly trade deterministic destruction (due to reference counting or any > other mechanism) for improved performance. I've often thought of creating a > mode where destruction didn't happen right away with reference counting, > just so I could find places where I'm relying on it. I consider it a bug to > rely on reference counting to close files, for example. Maybe I should just > run under Jython or IronPython everyone once in a while. I've considered making files issue a warning if they've got buffered writes and they're not explicitly closed. Although my feeling is a read-only file should produce the same warning, there's situations where "proper" error handling is very difficult or impossible. -- Adam Olsen, aka Rhamphoryncus ___ 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] Fwd: Removal of GIL through refcounting removal.
Eric Smith wrote: I'd gladly trade deterministic destruction (due to reference counting or any other mechanism) for improved performance. Another thing to consider is that refcounting spreads out the time spent doing GC evenly over the execution of the program, so that you don't get pauses occurring at random times. Sometimes in games I've found that I had to disable cyclic GC in order to get smooth frame rates. With no refcounting I wouldn't have the option of doing that. I'd be disappointed if that meant I could no longer use Python for these kinds of games. -- Greg ___ 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] Fwd: Removal of GIL through refcounting removal.
Antoine> I think it is important to remind that the GIL doesn't prevent Antoine> (almost) true multithreading. The only thing it prevents is Antoine> full use of multi-CPU resources in a single process. I believe everyone here knows that. I believe what most people are clamoring for is to make "full use of their multi-CPU resources in a single process". 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
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
Eric> I consider it a bug to rely on reference counting to close files, We can mostly have our cake and eat it too using the "with" statement. In most cases it should be sufficient I would think. 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] Looking for VCS usage scenarios
I have started the DVCS PEP which can be seen at http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . Not much is there beyond the rationale, usage scenarios I plan to use, and what other sections I plan to write. 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. And just to stave off some emails, I have two comments to make. One, please do not start sending me info on how to fill in the usage scenarios. I want to first solidify what the scenarios are. Plus I want to figure them out on my own to get a feel of the documentation for the tools. Second, as of right now Git is not in the running. Ignoring the fact I dislike the tool (my issues with it are documented in the python-dev archives), there is also the fact that it would be nicer to have Python have as its VCS something written in Python instead of C/Perl. -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] Fwd: Removal of GIL through refcounting removal.
[EMAIL PROTECTED] wrote: Eric> I consider it a bug to rely on reference counting to close files, We can mostly have our cake and eat it too using the "with" statement. In most cases it should be sufficient I would think. True, and I meant to mention that. But unfortunately, my work projects are stuck on 2.4 for the time being, so that doesn't help me much. Eric. ___ 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
Hi Brett, > 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. As an initial disclaimer, I use bzr in my daily routine. That said, I'm sending below a few mostly unbiased high-level ideas, just based on useful ways we explore the DVCS-aspect on our normal daily workflow. == Coordinated development with dependent features == A variation on coordinated development, which is actually one of the main motivators for DVCS. Branch A is evolving out of the mainline, and it depends on a feature that is on branch B which is also not yet integrated. Parallel development of both should be nicely supported. I'm sure all DVCS will do that in a decent form, but figuring how this works may be instructive and worth mentioning. == Centralization of feature-specific development == That's a curious one when we're talking about distributed development, isn't it? :-) Think about the following scenario: 5 people working in parallel on a tricky feature which will take a while to get to the mainline. Each developer works on a specific aspect of the feature for a few hours/days in their own branch, and then merges to and from what's considered as the feature-mainline. In essence, the problem is that it's messy to just go towards the "everyone merges from everyone" route when working in a common problem. We've found that being able to use an svn-like approach for the *feature* mainline (a branch that is shared by all defining the status quo) is a handy way to handle that. I'm sure there are other approaches to solve the same problem, but it's interesting to consider what they are for each tool since in our experience the problem will show up eventually, and supporting it nicely makes a big difference on the outcome. == Attaching of history-carrying diffs == This one may feel weird as well, and I'm guessing some people might react as "just send a URL to a branch". In practice, it is handy many times to just attach something to the bug tracker, for instance. This means that the "branch" is kept in the history of the bug. Also, with something like this, someone external to the development process may very easily provide his changes in the bug or in a mail without having to set up any infrastructure/accounts/whatever at all to provide his branch. That's it for now. If I can think of any other use cases from our routine that might serve as things to explore in such a comparison, I'll let you know. -- Gustavo Niemeyer http://niemeyer.net ___ 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] My patches
On Sun, Nov 2, 2008 at 5:42 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: ... > A dvcs means that people can publish their branches in a wide variety of > ways. Trusted developers can push their branches to code.python.org. > Non-core developers can use one of the free public dvcs branch hosting > service. Industrious users can self-publish their branches. Anyone with BTW, if we go with hg, I recommend bitbucket.org as a "free public (hg) hosting service" of choice -- Jesper (the owner and developer of the site) is friendly and solicitous in his maintenance, the whole site is quite OS-friendly in general (free "professional-level" accounts and support for open-source projects which choose to host there) and Python-friendly in particular (I gather the site's coded in Python), and my experience there has been nothing short of excellent. All it's missing is a simple code review tool like code.google.com's or Rietveld, but Jesper's promised me he would integrate something to that effect... Alex ___ 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 Sun, Nov 2, 2008 at 6:05 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > I have started the DVCS PEP which can be seen at > http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . Not much is there > beyond the rationale, usage scenarios I plan to use, and what other > sections I plan to write. > > 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. I think one very important requirement of Python's VCS is advanced merging support. The trunk and py3k are very special branches because a commit in one should not necessarily find its way into the other. To that end, I think it's critical to have svnmerge.py-like blocking (preferably with unblocking, too) and fine cherry-picking of revisions. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ 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] How to select text of text field in pythonCard
Hi, I need to select a text of text field! Which function is used for selection of text of text field? Sonia, > From: [EMAIL PROTECTED]> Subject: Python-Dev Digest, Vol 64, Issue 4> To: > [email protected]> Date: Mon, 3 Nov 2008 03:10:48 +0100> > Send > Python-Dev mailing list submissions to> [email protected]> > To subscribe > or unsubscribe via the World Wide Web, visit> > http://mail.python.org/mailman/listinfo/python-dev> or, via email, send a > message with subject or body 'help' to> [EMAIL PROTECTED]> > You can reach > the person managing the list at> [EMAIL PROTECTED]> > When replying, please > edit your Subject line so it is more specific> than "Re: Contents of > Python-Dev digest..."> > > Today's Topics:> > 1. Re: Fwd: Removal of GIL > through refcounting removal. (Eric Smith)> 2. Re: Fwd: Removal of GIL through > refcounting removal. (Adam Olsen)> 3. Re: Fwd: Removal of GIL through > refcounting removal. (Greg Ewing)> 4. Re: Fwd: Removal of GIL through > refcounting removal.> ([EMAIL PROTECTED])> 5. Re: Fwd: Removal of GIL through > refcounting removal.> (skip@ pobox.com)> 6. Looking for VCS usage scenarios (Brett Cannon)> 7. Re: Fwd: Removal of GIL through refcounting removal. (Eric Smith)> 8. Re: Looking for VCS usage scenarios (Gustavo Niemeyer)> 9. Re: My patches (Alex Martelli)> > > --> > Message: 1> Date: Sun, 02 Nov 2008 15:34:14 -0500> From: Eric Smith <[EMAIL PROTECTED]>> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: [email protected]> Message-ID: <[EMAIL PROTECTED]>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed> > Giovanni Bajo wrote:> > [[ my 0.2: it would be a great loss if we lose reference-counting > > semantic (eg: objects deallocated as soon as they exit the scope). I > > would bargain that for a noticable speed increase of course, but my own > > experience with standard GCs from other languages has been less than > > stellar. ]]> > And my $0.02:> > I'd gladly trade deterministic de struction (due to reference counting or > any other mechanism) for improved performance. I've often thought of > creating a mode where destruction didn't happen right away with > reference counting, just so I could find places where I'm relying on it. > I consider it a bug to rely on reference counting to close files, for > example. Maybe I should just run under Jython or IronPython everyone > once in a while.> > > --> > Message: 2> Date: Sun, 2 Nov 2008 15:07:45 -0600> From: "Adam Olsen" <[EMAIL PROTECTED]>> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: "Eric Smith" <[EMAIL PROTECTED]>> Cc: [email protected]> Message-ID:> <[EMAIL PROTECTED]>> Content-Type: text/plain; charset=ISO-8859-1> > On Sun, Nov 2, 2008 at 2:34 PM, Eric Smith <[EMAIL PROTECTED]> wrote:> > Giovanni Bajo wrote:> >>> >> [[ my 0.2: it would be a great loss if we lose reference-counting semantic> > > (eg: objects deallocated as soon as they exit the scope). I would bargain> > >> that for a noticable speed increase of course, but my own experience > with> >> standard GCs from other languages has been less than stellar. ]]> > >> > And my $0.02:> >> > I'd gladly trade deterministic destruction (due to > reference counting or any> > other mechanism) for improved performance. I've > often thought of creating a> > mode where destruction didn't happen right > away with reference counting,> > just so I could find places where I'm > relying on it. I consider it a bug to> > rely on reference counting to close > files, for example. Maybe I should just> > run under Jython or IronPython > everyone once in a while.> > I've considered making files issue a warning if > they've got buffered> writes and they're not explicitly closed. Although my > feeling is a> read-only file should produce the same warning, there's > situations> where "proper" error handling is very difficult or impossible.> > > > -- > Adam Ols en, aka Rhamphoryncus> > > --> > Message: 3> Date: Mon, 03 Nov 2008 11:33:11 +1300> From: Greg Ewing <[EMAIL PROTECTED]>> Subject: Re: [Python-Dev] Fwd: Removal of GIL through refcounting> removal.> To: [email protected]> Message-ID: <[EMAIL PROTECTED]>> Content-Type: text/plain; charset=UTF-8; format=flowed> > Eric Smith wrote:> > > I'd gladly trade deterministic destruction (due to reference counting or > > any other mechanism) for improved performance.> > Another thing to consider is that refcounting spreads out the> time spent doing GC evenly over the execution of the program,> so that you don't get pauses occurring at random times.> > Sometimes in games I've found that I had to disable cyclic> GC in order to get smooth frame rates. With no refcounting> I wouldn't have the option of doing that. I'd be disappointed> if that meant I cou
Re: [Python-Dev] How to select text of text field in python Card
2008/11/2 Sonia <[EMAIL PROTECTED]>: > > Hi, > > I need to select a text of text field! Which function is used for selection > of text of text field? Please ask your question on comp.lang.python or the Python card mailing list. This mailing list is for the development of core Python, not developing with Python. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ 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] file open in python interpreter
hi all, i am trying to find out where is the part of the code in the python interpreter that opens up the .py file and parses it. in particular, i am trying to find the file open command in that file. I greped and i just want to make sure this is it: /Python-2.6/Parser/pgenmain.c i am intending to take a hash measurement of the .py file just before i open it to run the script. is the above file the right place to call for the measurement before the file open function? thank you - adrian ___ 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 Mon, Nov 3, 2008 at 1:05 AM, Brett Cannon <[EMAIL PROTECTED]> wrote: > I have started the DVCS PEP which can be seen at > http://docs.google.com/Doc?id=dg7fctr4_40dvjkdg64 . Not much is there > beyond the rationale, usage scenarios I plan to use, and what other > sections I plan to write. > I think you really should not exclude any dvcs based on it's implementation language. I.e. requiring it being written in python for the sake of "eating your own dogfood" is just a very weak argument. git is certainly missing from your list. Regards, - Ralf ___ 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
