Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
On Sun, Nov 2, 2008 at 4:33 PM, Greg Ewing <[EMAIL PROTECTED]> wrote: > 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. I consider realtime games to be an essential use case and will be pursuing incremental GC with my experiments. -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file open in python interpreter
On Mon, Nov 3, 2008 at 1:04 AM, adrian golding <[EMAIL PROTECTED]> wrote: > 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? You want Parser/tokenizer.c. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file open in python interpreter
On Mon, Nov 3, 2008 at 7:25 AM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Mon, Nov 3, 2008 at 1:04 AM, adrian golding <[EMAIL PROTECTED]> wrote: >> 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? > > You want Parser/tokenizer.c. Sorry, that's not correct. opening of modules happens in Python/import.c. There's also a case in Modules/main.c. > > > > -- > Cheers, > Benjamin Peterson > "There's nothing quite as beautiful as an oboe... except a chicken > stuck in a vacuum cleaner." > -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for standard library?
On Mon, Nov 3, 2008 at 6:29 AM, Gerhard Häring <[EMAIL PROTECTED]> wrote: > Stefan Behnel wrote: >> >> 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). > > Is using Cython for anything in Modules/ really an option? In my limited > experiments with it, I did like it. > > But using it for Python standard library stuff doesn't look quite right to > me: > > - Option 1: distribute Cython with Python and integrate into build process > -- Ouch! Can you be a bit more descriptive? > - Option 2: only distribute generated source files > -- developers still need to have Cython installed > -- you have to trust Cython; who will really review the generated code? Who reviews the machine code from gcc? I would love to see the option to write the lower levels in something other than C, but obviously any choice would have to be a good one. Otherwise, we end up stuck or with lots of different languages all being used and making understanding the full codebase harder. For example, I've wondered if RPython would ever reach the point it could be considered in the same way, but I don't think it would be wise to consider both. So, the question I see isn't if Cython should be allowed for standard library modules, but if the landscape of such solutions is at a point that any of them is ready to be committed to. -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] file open in python interpreter
Benjamin Peterson wrote: > On Mon, Nov 3, 2008 at 7:25 AM, Benjamin Peterson > <[EMAIL PROTECTED]> wrote: >> On Mon, Nov 3, 2008 at 1:04 AM, adrian golding <[EMAIL PROTECTED]> wrote: >>> 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? >> You want Parser/tokenizer.c. > > Sorry, that's not correct. opening of modules happens in > Python/import.c. There's also a case in Modules/main.c. And some indirect ones from runpy.py (via pkgutils) if you use the -m switch, or are executing a zipfile or directory. But for the specific case of an exact filename being provided on the command line, then main.c is the one the original poster will want to look at (line 567 to be exact). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for standard library?
Calvin Spealman wrote:
On Mon, Nov 3, 2008 at 6:29 AM, Gerhard Häring <[EMAIL PROTECTED]> wrote:
Stefan Behnel wrote:
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).
Is using Cython for anything in Modules/ really an option? In my limited
experiments with it, I did like it.
But using it for Python standard library stuff doesn't look quite right to
me:
- Option 1: distribute Cython with Python and integrate into build process
-- Ouch!
Can you be a bit more descriptive?
Cython is still being worked on (intensively, it seems). Bundling it
with Python means deciding on a particular version probably for an
entire major release lifecycle (use Cython x.y.{newest} for Python 2.7,
for example).
- Option 2: only distribute generated source files
-- developers still need to have Cython installed
-- you have to trust Cython; who will really review the generated code?
Who reviews the machine code from gcc?
That's comparing apples and eggs :-P But it may be that I'm a little
paranoid here.
I would love to see the option to write the lower levels in something
other than C,
Absolutely. That's why I tried to reimplement pysqlite in something
easier to maintain than handwritten Python C API. There's a ctypes-based
version in its Mercurial repository that's good enough to be used from
PyPy now. And a started Cython-based one.
but obviously any choice would have to be a good one.
[...] So, the question I see isn't if Cython should be
allowed for standard library modules, but if the landscape of such
solutions is at a point that any of them is ready to be committed to.
ACK.
-- Gerhard
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for standard library?
>>> - Option 2: only distribute generated source files >>> -- developers still need to have Cython installed >>> -- you have to trust Cython; who will really review the generated code? >> >> Who reviews the machine code from gcc? Gerhard> That's comparing apples and eggs :-P But it may be that I'm a Gerhard> little paranoid here. Agreed. When Cython is as widely used as gcc and has as comprehensive a set of test cases (who knows? it may well already be comprehensive enough) and supports all the compilers which Python supports then we can probably skip the output code review step. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Using Cython for standard library?
Stefan Behnel wrote: 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). Is using Cython for anything in Modules/ really an option? In my limited experiments with it, I did like it. But using it for Python standard library stuff doesn't look quite right to me: - Option 1: distribute Cython with Python and integrate into build process -- Ouch! - Option 2: only distribute generated source files -- developers still need to have Cython installed -- you have to trust Cython; who will really review the generated code? -- Gerhard ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 2:46 AM, Ralf Schmitt wrote: 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. Sticking with a dvcs implemented in Python makes the best sense, especially when you consider the plugin architecture. When we selected a new tracker, we didn't make implementation in Python a requirement, but instead a high hurdle. Meaning, if a tracker wasn't written in Python it had to be way better than those written in Python. As for dvcs, I think git would have to show overwhelming advantage over bzr or hg to be considered. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ7emXEjvBPtnXfVAQLbogP/RKxjGVs1STW8ghF/99JeRv8fVhwrHQxw d2WyeuOC4wfU1iicEsbjCgTIKQOKmlnzZ1EO/D9DYc565Vv/+pVGJjSMMCmxS0/V w2MXhGUJp9RKjCZEbUKc6aVszvUIAmQNp1GGWTeEZqzaRm/srSJH3XMsyn4/xMjO qdsl1sQgAj0= =ejCl -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, 2008-11-03 at 08:46 +0100, Ralf Schmitt wrote: > 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. It does certainly miss from the list, but the argument might be more "favor your users"; call it nepotism if you like. If I understand it clearly, it is not a requirement, but more a good point. If it does "taste like dog food" in places, then it might be easier to: - make informed statements about what might be the reason (on an implementation standpoint - regarding features, that's an other story) - have the cook more receptive to comments L. > Regards, > - Ralf > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/lgautier%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Packaging the PyPI version of the SSL module for Debian
As some of you know, I've provided a PyPI version of the 2.6/3.x "ssl" module, for use with older versions of Python. I've received this request to tweak it for Debian, and I thought I'd ask those of you who may have already done it for advice on the various issues Cyril raises here. I'm not Debian-knowledgable, myself. Bill -- Forwarded message -- From: Cyril Brulebois <[EMAIL PROTECTED]> Date: Mon, Jul 14, 2008 at 11:37 AM Subject: Packaging (python-)ssl for Debian To: [EMAIL PROTECTED] Hi, I've noticed the following Request For Packaging [1], and it turned out that it was exactly what I was looking for (a real ssl module, not just read/write on a socket). So I started packaging it for Debian, and here are a few comments, and some points that I'd like you to address, so that I can upload it into the archive. 1. http://bugs.debian.org/453101 The main concern currently is the license, since "Python (MIT-like)" is quite vague. One has no clue which Python version is concerned, since as far as I can tell, there are at least 2.4.2 and 2.5.2 [2,3] out with (slightly but still) different licenses. So, pointing to the precise version would really help people. At least the URL to the license would be needed, but it would be even better to include it into the source package, so that there's no possible doubt, and so that one isn't dependent from being online to actually read it. 2. http://www.python.org/download/releases/2.4.2/license/ 3. http://www.python.org/download/releases/2.5.2/license/ I'd suggest including it in a LICENSE file, and then point to it using something like "LICENSE: Python x.y.z (MIT-like), see LICENSE file". It's then up to you to choose whether to state clearly in each file "This file is licensed under the terms of the Python x.y.z license, see LICENSE file." (which I encourage you to do), or to state at the very beginning of this LICENSE file that "the whole (python-)ssl package is licensed under the following terms (Python x.y.z license):" and then quote your favourite license. Also, you're listing the contributors in various places, PKG-INFO and setup.py. That's nice, but it might be a better idea to point to a single AUTHORS file, where you would keep a single list of the contributors. It's not a problem per se, but you may want to consider this. Related to authorship is copyright assignment, and that one is a blocker for the inclusion into Debian. Every file should include copyright information so that one can know who is holding the copyrights on this or that file. Having a very quick look, the following files would need it: *.py, *.h, *.c. PKG-INFO could eventually list all copyright lines, but I'm not sure it's a widely-used practice in the Python world, just tell me ;-); the Makefile might deserve (c) info as well; MANIFEST and *.pem files don't need it. Just for the records, one specifies copyrights in the following manner: Copyright 2008 Some Author Copyright 2004, 2007 Another One Copyright 2004-2008 Yet Another One "Copr." or "(c)" can be used instead of "Copyright". "(C)" can be added (it's harmless) but has no legal meaning, so can't be used alone. No need to list everyone having ever contributed a single patch, it's sufficient to list people having done the real work and worthy modifications to it. Adding people to copyright holders is usally a matter of project policy. If you don't feel like listing the copyright holders in PKG-INFO, you could decide for using something like: ,---[ AUTHORS ]--- | | Main developers: | Copyright 2004 John Doe | Copyright 2004-2008 Alice Wonderland | | Contributors: | Peter Pan | Foo Bar | `--- This way, you just have to do the following to keep your software uptodate WRT legalese things: - Add/update a Copyright line at the top of .c/.h/… file when a significant modification is included. - Add/update the Copyright line in the AUTHORS file accordingly. - Or add/update the Contributors list if that doesn't warrant a Copyright line. So that there's no need to update every file (like PKG-INFO and setup.py), you only have to make them point to AUTHORS for authorship information. Once that is done, I should be able to upload it to Debian, where the first upload will be double-check by ftpmasters, whose role is to make sure that no obvious packaging error is made, but mainly to make sure that the archive is kept OK from a legal point of view. That's why I'm starting with this quite boring mail, and I'm sorry for that. :) Mraw, KiBi. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh7quoACgkQeGfVPHR5Nd1LQwCaAＤ艊�볁ᜆ뻈働� 2Y0AnitpaRf3zybMhNxstnDrKaJc8K3/ =eriZ -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkh7quoACgkQeGfVPHR5Nd1LQwCaA+/ySCStiNvMEXBr7IUM0ltE 2Y0AnitpaRf3zybMhNxstnDrKaJc8K3/ =eriZ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@py
Re: [Python-Dev] hg branch gone?
On Fri, Oct 31, 2008 at 11:25, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Oct 31, 2008, at 03:50 AM, Eric Smith wrote: > > >I posted this yesterday about using bzr: > > > > >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? > > Looks like this is fixed now too. > > Aside: Now that Python 2.6 isn't on the trunk, we need to add a bzr mirror > for > python26-maint. FWIW, I put one up this weekend, and it seems to be intact and OK. (bzr+ssh://[EMAIL PROTECTED]/python/2.6/ or http://code.python.org/python/2.6/ ) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for standard library?
>> - Option 1: distribute Cython with Python and integrate into build process >> -- Ouch! > > Can you be a bit more descriptive? Gerhard's elaboration (of us creating a fork of Cython then) is convincing; there is also the issue of changes to the API to consider. When we change the API now, we have to find the 20..50 places that need to get adjusted. If we change the API then, we need to change the generator - which complicates the evolution. For a Cython outside of Python, we might not be able to change the API at all. In addition, there is also the bootstrapping problem. Cython imports a number of builtin modules - if they are written in Cython, we have the bootstrapping problem. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using Cython for standard library?
-> I would love to see the option to write the lower levels in something -> other than C, but obviously any choice would have to be a good one. -> Otherwise, we end up stuck or with lots of different languages all -> being used and making understanding the full codebase harder. For -> example, I've wondered if RPython would ever reach the point it could -> be considered in the same way, but I don't think it would be wise to -> consider both. So, the question I see isn't if Cython should be -> allowed for standard library modules, but if the landscape of such -> solutions is at a point that any of them is ready to be committed to. What is the situation twixt Pyrex and Cython? As I understand it, Cython is a non-backwards-compatible fork of Pyrex, forked for the usual reasons [0]. Have many or most people switched to Cython, or is there still a respectable community using Pyrex, or ...? I'm involved in a project that depends on Pyrex and there was no clear reason for us to switch to Cython. I've also seen criticisms of Cython's maturity level (which presumably also apply to Pyrex). I'd be interested in hearing about that... ...or is switching to Cython/Pyrex/foo a non-starter? cheers, --titus [0] Which is to say: a variety of reasons, many of which are obviously arguable, otherwise the Pyrex maintainer would have quit maintaining Pyrex :). But let's not go into them! -- C. Titus Brown, [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Sun, Nov 2, 2008 at 17:08, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote: > 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. > Since I have never seen that come up during Python's development I am going to leave it out. But I do see the benefit and how it might help with future work. > == 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. > This one is covered already. > == 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. As I mentioned in the doc, the first example allows for whatever the DVCS does for diffs, whether that is a full-on branch or not. > > > 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. Thanks, Gustavo! -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-> Sticking with a dvcs implemented in Python makes the best sense, -> especially when you consider the plugin architecture. When we -> selected a new tracker, we didn't make implementation in Python a -> requirement, but instead a high hurdle. Meaning, if a tracker wasn't -> written in Python it had to be way better than those written in Python. I worry about the idea of hacking in any way, shape or form, on the version control system used to maintain the Python source code. I place VCSes at the compiler- or OS-level of the toolchain, because you have the option of fundamentally screwing up the entire project by playing with them. So from that perspective it's better to keep it *out* of Python to remove the temptation to hack :) -> As for dvcs, I think git would have to show overwhelming advantage -> over bzr or hg to be considered. I personally have found git very, very powerful and good, albeit difficult to learn. It is guaranteed to scale (unless Python gets to be significantly bigger and more active than Linux, at any rate) and it has a large, very technically capable, and supported user community already. I think there are reasons why git should be at least strongly considered. --titus -- C. Titus Brown, [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Hi Brett, Brett Cannon python.org> writes: > > 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'm not sure that's the kind of feedback you want, but it isn't clear what you mean with "checkout". Is it just a working copy (then it would be better to use this term)? Is it some kind of shallow clone containing only part of the history? Or anything else? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 09:58, C. Titus Brown <[EMAIL PROTECTED]> wrote: > -> Sticking with a dvcs implemented in Python makes the best sense, > -> especially when you consider the plugin architecture. When we > -> selected a new tracker, we didn't make implementation in Python a > -> requirement, but instead a high hurdle. Meaning, if a tracker wasn't > -> written in Python it had to be way better than those written in Python. > > I worry about the idea of hacking in any way, shape or form, on the > version control system used to maintain the Python source code. I place > VCSes at the compiler- or OS-level of the toolchain, because you have > the option of fundamentally screwing up the entire project by playing > with them. > > So from that perspective it's better to keep it *out* of Python to > remove the temptation to hack :) > I don't expect us to hack on the VCS itself. I am thinking more like plug-ins commit hooks, etc.; the infrastructure around the VCS. > -> As for dvcs, I think git would have to show overwhelming advantage > -> over bzr or hg to be considered. > > I personally have found git very, very powerful and good, albeit > difficult to learn You can say that again. And that is a worry to me. Python gets patches from people of all skill levels where ease of use for the VCS needs to be considered. The Linux kernel probably doesn't get as many patches from newbies as the barrier of entry is higher to contribute. I have yet to have met anyone who thinks git is great while having used another DVCS as extensively (and I mean I have never found someone who has used two DVCSs extensively). >. It is guaranteed to scale (unless Python gets to be > significantly bigger and more active than Linux, at any rate) and it has > a large, very technically capable, and supported user community already. > I think any of the DVCSs will scale. But I will be taking some performance numbers so scalability will be taken into consideration. > I think there are reasons why git should be at least strongly > considered. Well, we will see, but as of right now my use of git has left a nasty taste in my mouth that will take a lot of proverbial mouthwash to get rid of and allow it to be considered in this PEP. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 09:57, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > > Hi Brett, > > Brett Cannon python.org> writes: >> >> 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'm not sure that's the kind of feedback you want, but it isn't clear what you > mean with "checkout". Is it just a working copy (then it would be better to > use > this term)? Is it some kind of shallow clone containing only part of the > history? Or anything else? > A working copy. That's why I mentioned Subversion as the example in the definition. I have updated it. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 03, 2008 at 10:05:15AM -0800, Brett Cannon wrote: -> I have yet to have met anyone who thinks git is great while having -> used another DVCS as extensively (and I mean I have never found -> someone who has used two DVCSs extensively). git is great! I'm switching to it from darcs for all my future projects. (darcs, of course, is kind of a low bar: it has some scalability issues, and it is feature-poor relative to hg and bzr in patch cherry-picking, esp.) :) --titus -- C. Titus Brown, [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 7:05 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: > I have yet to have met anyone who thinks git is great while having > used another DVCS as extensively (and I mean I have never found > someone who has used two DVCSs extensively). I have used mercurial extensively (before having used git) and I think git is great. It gives you much more freedom to work with your source code than mercurial. - Ralf ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Brett Cannon python.org> writes: > > 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. You might want to refine the "patch review" scenario with a variant using Rietveld and its upload script. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 12:58 PM, C. Titus Brown wrote: -> Sticking with a dvcs implemented in Python makes the best sense, -> especially when you consider the plugin architecture. When we -> selected a new tracker, we didn't make implementation in Python a -> requirement, but instead a high hurdle. Meaning, if a tracker wasn't -> written in Python it had to be way better than those written in Python. I worry about the idea of hacking in any way, shape or form, on the version control system used to maintain the Python source code. I place VCSes at the compiler- or OS-level of the toolchain, because you have the option of fundamentally screwing up the entire project by playing with them. So from that perspective it's better to keep it *out* of Python to remove the temptation to hack :) :) But actually more interesting is whether we want to add plugins that assist Python dev workflow. For example, let's say we wanted to have a 'fixes' command that automatically updated the Roundup tracker with the branch information. I'd personally much rather write 10 lines of Python to add such a plugin than any amount of C or Perl, or whatever else. :) -> As for dvcs, I think git would have to show overwhelming advantage -> over bzr or hg to be considered. I personally have found git very, very powerful and good, albeit difficult to learn. It is guaranteed to scale (unless Python gets to be significantly bigger and more active than Linux, at any rate) and it has a large, very technically capable, and supported user community already. I think there are reasons why git should be at least strongly considered. Powerful, scalable, active development and user community would certainly apply to the Python-based dvcses. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ9ERHEjvBPtnXfVAQLGEgP/VTjZLo4FJQ3oUGZp5eGHJdvkhOkmJPX+ bKhw09eoR6yuKbcRcPkqjqU9z8T4+gCdrOsiyNE98/Cr14xtAr2tYq2zEj0iFb/L snjVaZuelrlzHV3V6avAs3n8ua+X/rb4tG3r7vc8djH4qeAFw3aMYqYDkodL3BoO /x8NVlfPj7o= =z3TI -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 18:57, Brett Cannon <[EMAIL PROTECTED]> wrote: > On Sun, Nov 2, 2008 at 17:08, Gustavo Niemeyer <[EMAIL PROTECTED]> > wrote: > > 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. > > > > Since I have never seen that come up during Python's development I am > going to leave it out. But I do see the benefit and how it might help > with future work. Euhm, wut? It hasn't come up during Python's development because Python is being developed in a VCS with very limited branches :) I'm partial to VCS's with proper branching (as you know) and I've been using that mode of development for many years. I've done development and maintenance of multi-developer projects using both the CVS/SVN nonbranching approach and the typical DVCS branch-often approach using BitKeeper, Bazaar and Mercurial (as well as the sort-of one-off-branch Perforce approach where you can easily 'wrap' a single change but can't really do dependant changes) -- and whenever possible I use the branch-often approach with dependant branches all over the place, especially when working on large, complicated changes. Building them up out of separate 'components' requires a little more administration (you have to remember which branch to submit to) but it makes debugging, piecemeal discussion and batchwise integration a *lot* easier. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 1:13 PM, Ralf Schmitt wrote: I have used mercurial extensively (before having used git) and I think git is great. It gives you much more freedom to work with your source code than mercurial. Ralf, can you describe what you mean in more detail? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ9EnHEjvBPtnXfVAQLAQgP9HFGmvq3dq60oUryeiVXI2sgWQvUXbYzk 6Nhg796sPyGwzuO8PoLq6CvxNzqvah25KMznjOxx0MpMzhSKEgJPJwxkBLpIYJUy Enz3JrLt+r3do0pNLvgkAz9gENh90QLWt1amVvvt2c8ahua2hGpxPN4Y0YUFbeIf bbxP7bcvD+U= =aPaJ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 4:34 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > :) But actually more interesting is whether we want to add plugins that > assist Python dev workflow. For example, let's say we wanted to have a > 'fixes' command that automatically updated the Roundup tracker with the > branch information. I'd personally much rather write 10 lines of Python to > add such a plugin than any amount of C or Perl, or whatever else. :) (Which, btw, is already supported by the "--fixes" option on bzr's commit :) just-giving-my-R$0.02-ly yours, -- Eduardo de Oliveira Padoan http://djangopeople.net/edcrypt/ "Distrust those in whom the desire to punish is strong." -- Goethe, Nietzsche, Dostoevsky ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 12:41 PM, Eduardo O. Padoan <[EMAIL PROTECTED]> wrote: > On Mon, Nov 3, 2008 at 4:34 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> :) But actually more interesting is whether we want to add plugins that >> assist Python dev workflow. For example, let's say we wanted to have a >> 'fixes' command that automatically updated the Roundup tracker with the >> branch information. I'd personally much rather write 10 lines of Python to >> add such a plugin than any amount of C or Perl, or whatever else. :) > > (Which, btw, is already supported by the "--fixes" option on bzr's commit :) The --fixes option allows you to note where a bug is fixed in your repo. I think what Barry is envisioning is a tool that would automatically close the issue on Roundup. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 1:05 PM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Mon, Nov 3, 2008 at 09:58, C. Titus Brown <[EMAIL PROTECTED]> wrote:
>> -> Sticking with a dvcs implemented in Python makes the best sense,
>> -> especially when you consider the plugin architecture. When we
>> -> selected a new tracker, we didn't make implementation in Python a
>> -> requirement, but instead a high hurdle. Meaning, if a tracker wasn't
>> -> written in Python it had to be way better than those written in Python.
>>
>> I worry about the idea of hacking in any way, shape or form, on the
>> version control system used to maintain the Python source code. I place
>> VCSes at the compiler- or OS-level of the toolchain, because you have
>> the option of fundamentally screwing up the entire project by playing
>> with them.
>>
>> So from that perspective it's better to keep it *out* of Python to
>> remove the temptation to hack :)
>>
>
> I don't expect us to hack on the VCS itself. I am thinking more like
> plug-ins commit hooks, etc.; the infrastructure around the VCS.
>
>> -> As for dvcs, I think git would have to show overwhelming advantage
>> -> over bzr or hg to be considered.
>>
>> I personally have found git very, very powerful and good, albeit
>> difficult to learn
>
> You can say that again. And that is a worry to me. Python gets patches
> from people of all skill levels where ease of use for the VCS needs to
> be considered. The Linux kernel probably doesn't get as many patches
> from newbies as the barrier of entry is higher to contribute.
>
> I have yet to have met anyone who thinks git is great while having
> used another DVCS as extensively (and I mean I have never found
> someone who has used two DVCSs extensively).
>
>>. It is guaranteed to scale (unless Python gets to be
>> significantly bigger and more active than Linux, at any rate) and it has
>> a large, very technically capable, and supported user community already.
>>
>
> I think any of the DVCSs will scale. But I will be taking some
> performance numbers so scalability will be taken into consideration.
>
>> I think there are reasons why git should be at least strongly
>> considered.
>
> Well, we will see, but as of right now my use of git has left a nasty
> taste in my mouth that will take a lot of proverbial mouthwash to get
> rid of and allow it to be considered in this PEP.
>
I don't see how git can be considered given poor windows support -
compilation on OS/X can be a bear too.
And I echo the need/want to be able to customize the workflow and
integration with the tracker/etc with something a bit more flexible.
The bzr plugin system is nice.
Also the ability to completely nuke the local-work-copies commit
history ("cleaning it up") worries me, but I'm also paranoid.
-jesse
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 12:34 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Nov 3, 2008, at 12:58 PM, C. Titus Brown wrote: > > -> Sticking with a dvcs implemented in Python makes the best sense, >> -> especially when you consider the plugin architecture. When we >> -> selected a new tracker, we didn't make implementation in Python a >> -> requirement, but instead a high hurdle. Meaning, if a tracker wasn't >> -> written in Python it had to be way better than those written in Python. >> >> I worry about the idea of hacking in any way, shape or form, on the >> version control system used to maintain the Python source code. I place >> VCSes at the compiler- or OS-level of the toolchain, because you have >> the option of fundamentally screwing up the entire project by playing >> with them. >> >> So from that perspective it's better to keep it *out* of Python to >> remove the temptation to hack :) >> > > :) But actually more interesting is whether we want to add plugins that > assist Python dev workflow. For example, let's say we wanted to have a > 'fixes' command that automatically updated the Roundup tracker with the > branch information. I'd personally much rather write 10 lines of Python to > add such a plugin than any amount of C or Perl, or whatever else. :) > There is no reason you can't develop such a tool on top of git using Python. In the true spirit of Unix command line utilities you can write tools that combine or extend the functionality of existing tools in whatever language you feel comfortable. For example take a look at the repo tool used by Android to interact with the git repository. http://source.android.com/download I've never felt the need to add plugins to my version control system and have to learn it's API. I've been satisfied with creating a collection of python scripts or shell scripts to add whatever functionality I needed. -- Cosmin Stejerean http://www.offbytwo.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Hi, On Mon, Nov 3, 2008 at 20:45, Jesse Noller <[EMAIL PROTECTED]> wrote: [...] > I don't see how git can be considered given poor windows support - > compilation on OS/X can be a bear too. I use git on Linux/Mac/Windows day to day, see http://code.google.com/p/git-osx-installer/ http://code.google.com/p/msysgit/ Regards, ismail ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
On Sun, Nov 2, 2008 at 3:51 PM, <[EMAIL PROTECTED]> wrote: > >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". > Which is, arguably, silly. As we've seen in the last 2 months with Chrome, multiple processes for a single "program" is actually a pretty good idea. With the multiprocessing module in the standard library offering a threading-like interface, people no longer have any excuses for not fully exploiting their multiple cores in Python. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 4:43 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Mon, Nov 3, 2008 at 12:41 PM, Eduardo O. Padoan > <[EMAIL PROTECTED]> wrote: >> On Mon, Nov 3, 2008 at 4:34 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >>> :) But actually more interesting is whether we want to add plugins that >>> assist Python dev workflow. For example, let's say we wanted to have a >>> 'fixes' command that automatically updated the Roundup tracker with the >>> branch information. I'd personally much rather write 10 lines of Python to >>> add such a plugin than any amount of C or Perl, or whatever else. :) >> >> (Which, btw, is already supported by the "--fixes" option on bzr's commit :) > > The --fixes option allows you to note where a bug is fixed in your > repo. I think what Barry is envisioning is a tool that would > automatically close the issue on Roundup. Ouch, sure. I agree, it should be easy to do with a plugin. I couldn't dedicate enough yet to write a plugin, but as far as I have seen, the bzr API is quite pythonic. > -- > Cheers, > Benjamin Peterson > "There's nothing quite as beautiful as an oboe... except a chicken > stuck in a vacuum cleaner." > -- Eduardo de Oliveira Padoan http://djangopeople.net/edcrypt/ "Distrust those in whom the desire to punish is strong." -- Goethe, Nietzsche, Dostoevsky ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
On Mon, Nov 3, 2008 at 11:50 AM, Josiah Carlson <[EMAIL PROTECTED]>wrote: > On Sun, Nov 2, 2008 at 3:51 PM, <[EMAIL PROTECTED]> wrote: > >> >>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". >> > > Which is, arguably, silly. As we've seen in the last 2 months with Chrome, > multiple processes for a single "program" is actually a pretty good idea. > With the multiprocessing module in the standard library offering a > threading-like interface, people no longer have any excuses for not fully > exploiting their multiple cores in Python. > There is no shortage of algorithms (such as matrix multiplication) that are parallelizable but not particularly good candidates for an IPC-based multiprocessing paradigm. -- Curt Hagenlocher [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Sun, Nov 2, 2008 at 19:03, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > 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. > Add the blocking to the backport scenario. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
On Mon, Nov 3, 2008 at 11:56 AM, Paul Miller <[EMAIL PROTECTED]> wrote: > I've read some of the past discussion about including GMP into the > python core and understand the reasons for not doing so. Rather than > that, what about patching Python's long implementation to use GMP if > it's available, and the default implementation if not? Are there any > philosophical or technical objections to this? If not, I would consider > drafting a patch. The main objection is that GMP is licensed under LGPL which I believe conflicts with Python's very open license. Also, there would incompatibilities between versions of Python that had GMP enabled and those that didn't with regards to floating points. > > Thanks, > > Paul -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Optionally using GMP to implement long if available
I've read some of the past discussion about including GMP into the python core and understand the reasons for not doing so. Rather than that, what about patching Python's long implementation to use GMP if it's available, and the default implementation if not? Are there any philosophical or technical objections to this? If not, I would consider drafting a patch. Thanks, Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
2008/11/3 İsmail Dönmez <[EMAIL PROTECTED]>: > On Mon, Nov 3, 2008 at 20:45, Jesse Noller <[EMAIL PROTECTED]> wrote: > [...] >> I don't see how git can be considered given poor windows support - >> compilation on OS/X can be a bear too. I would say that strong support of all of Python's key platforms would be a requirement (sorry, I haven't had time to read the PEP yet to see if it already says this). That means Unix (specifically, Linux and OS/X, and probably a few other Unix variants) and Windows. > > I use git on Linux/Mac/Windows day to day, see > > http://code.google.com/p/git-osx-installer/ > http://code.google.com/p/msysgit/ I find the fact that msysgit is a separate project, rather than a part of core git, is a significant point. Personally, I have dabbled with git on Windows and it certainly doesn't feel as well-supported as Bazaar or Mercurial. It's certainly getting closer, but I don't think even the Git project themselves would say it's there yet (the Git homepage points to msysgit for binaries, and that page explicitly says that Windows is only "officially" supported under cygwin). (I could go on, but I won't - suffice it to say that git doesn't yet feel "native" on Windows). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
> Since I have never seen that come up during Python's development I am > going to leave it out. But I do see the benefit and how it might help > with future work. Of course, that's entirely up to you. But it strikes me as an odd approach to the selection of scenarios for a tool whose intention is precisely to support new usage scenarios. > As I mentioned in the doc, the first example allows for whatever the > DVCS does for diffs, whether that is a full-on branch or not. Are you looking for new scenarios or for the validation of your document? :-) I'm talking about history-carrying diffs which can be attached and sent via mail, not about viewing plain diffs, which every VCS tool in the world can do since version 0.0. Anyway, I guess you already have what you want. Good luck picking the right choice! -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
Hi, Le Monday 03 November 2008 18:56:37 Paul Miller, vous avez écrit : > I've read some of the past discussion about including GMP into the > python core and understand the reasons for not doing so. Please, check this issue: http://bugs.python.org/issue1814 I patched Python3 to use GMP because I thaugh that GMP is much faster than Python for integer computation. The "problem" is that GMP target are integers much bigger than 10**100. As I remember, GMP has a special hack for very small integer: integer which can be stored in one CPU word, but it's not enough to speed up Python. With my last patch, with GMP, Python is 2% *slower*. My patch can be improved, but I expected +20% to +100% to no -2% :-/ And there is also the license issue... -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
>> 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". Josiah> Which is, arguably, silly. As we've seen in the last 2 months Josiah> with Chrome, multiple processes for a single "program" is Josiah> actually a pretty good idea. I have no idea what Chrome is. Is it a CPU-intensive algorithm which can be parallelized? Josiah> With the multiprocessing module in the standard library offering Josiah> a threading-like interface, people no longer have any excuses Josiah> for not fully exploiting their multiple cores in Python. Except for communication overhead caused by replacing shared memory with I/O? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
2008/11/3 <[EMAIL PROTECTED]>: > >>> 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". > >Josiah> Which is, arguably, silly. As we've seen in the last 2 months >Josiah> with Chrome, multiple processes for a single "program" is >Josiah> actually a pretty good idea. > > I have no idea what Chrome is. Is it a CPU-intensive algorithm which can be > parallelized? It's Google webbrowser ;) Matthieu Brucher >Josiah> With the multiprocessing module in the standard library offering >Josiah> a threading-like interface, people no longer have any excuses >Josiah> for not fully exploiting their multiple cores in Python. > > Except for communication overhead caused by replacing shared memory with > I/O? > > Skip > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/matthieu.brucher%40gmail.com > -- Information System Engineer, Ph.D. Website: http://matthieu-brucher.developpez.com/ Blogs: http://matt.eifelle.com and http://blog.developpez.com/?blog=92 LinkedIn: http://www.linkedin.com/in/matthieubrucher ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
Benjamin> The main objection is that GMP is licensed under LGPL which I Benjamin> believe conflicts with Python's very open license. If GMP itself isn't included with Python how can there be a licensing issue? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg branch gone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 31, 2008, at 6:28 AM, [EMAIL PROTECTED] wrote: Martin> I have now restored the original URL structure, and moved the Martin> loggerhead installation to Martin> http://code.python.org/loggerhead/ A couple nits. Leaving off the trailing / yields a 404. This should be fixed now via a RedirectPermanent. (No big deal though). More importantly, there seem to be no images, e.g.: http://code.python.org/static/images/ico_folder.gif Looks like it should be http://code.python.org/loggerhead/static/images/ico_folder.gif I think Martin fixed these; at least I don't see this problem any more. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ9ogHEjvBPtnXfVAQKSiAP/Y30HaPDs54GaeB1P+e2CIpQANUlsEm5d ePdfPvSKKXbKGjlYI6jsHdT75oT2q0BVo5DDGN6YcU3oISIIZF6X9AP86LXCqLeI FPU1JEsR+Deds3iALxvd2r306c9gzTFz3j30mjvNUF8HinTheE8lG3j0qCnYSVQI aqClcXudv5s= =Adh8 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg branch gone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 11:54 AM, Thomas Wouters wrote: FWIW, I put one up this weekend, and it seems to be intact and OK. (bzr+ssh://[EMAIL PROTECTED]/python/2.6/ or http://code.python.org/python/2.6/ ) Excellent, thanks! This is getting mirrored with updates, right? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ9p2nEjvBPtnXfVAQJoVgP+JLJHK9FRK0xsLtiMSW2BrrnYuCjwhidX yRdNK6oE/hiUKGCjO8G+IptqsDJl5MxFKYZ7RAhK9HjCsjoLW/aQc3zAJuwb+dyX fowpwrBV1pPRTB2IP840ImEATfufb8Mwzo5H8G9k+dx1BTHjY4o5JLQXFREBUNuu jUKSPMOr9NU= =wur0 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg branch gone?
>> (No big deal >> though). More importantly, there seem to be no images, e.g.: > >>http://code.python.org/static/images/ico_folder.gif > >> Looks like it should be > >>http://code.python.org/loggerhead/static/images/ico_folder.gif > > I think Martin fixed these; at least I don't see this problem any more. Right - but only so through a --prefix option to serve-branches. If you make it a reboot-safe service, be sure to copy this option. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg branch gone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 4:39 PM, Martin v. Löwis wrote: (No big deal though). More importantly, there seem to be no images, e.g.: http://code.python.org/static/images/ico_folder.gif Looks like it should be http://code.python.org/loggerhead/static/images/ico_folder.gif I think Martin fixed these; at least I don't see this problem any more. Right - but only so through a --prefix option to serve-branches. If you make it a reboot-safe service, be sure to copy this option. Will do, thanks. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ9w9HEjvBPtnXfVAQKaFwP/ZnHhz39R52yUFGc9vgJTISFXgTkXk9AS CPeG+FGWuJVdAHHNdIZ7zv8s1Nbl4KoDnHzJdvL2AQjCspJjjibnh/ss39BlGxZe Qq4FFsbKX59NWL0lbBAyKrHRBT2eX1EIbGgrBvGgNUSHRecoJC30UpIxz/DC/cur xdSg7kK/jm8= =cwwj -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 10:19, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > Brett Cannon python.org> writes: >> >> 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. > > You might want to refine the "patch review" scenario with a variant using > Rietveld and its upload script. Well, I don't want to propose new scenarios that are not widely used yet. But I will cover support by patch review tools in the Platform/Tools Support section. Thanks for the suggestion, Antoine. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
[EMAIL PROTECTED] wrote: > Benjamin> The main objection is that GMP is licensed under LGPL which I > Benjamin> believe conflicts with Python's very open license. > > If GMP itself isn't included with Python how can there be a licensing issue? On Windows, the GMP binaries would be incorporated into pythonxy.dll. This would force anybody providing a copy of pythonxy.dll to also provide the sources of GMP. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 10:35, Thomas Wouters <[EMAIL PROTECTED]> wrote: > > > On Mon, Nov 3, 2008 at 18:57, Brett Cannon <[EMAIL PROTECTED]> wrote: >> >> On Sun, Nov 2, 2008 at 17:08, Gustavo Niemeyer <[EMAIL PROTECTED]> >> wrote: >> > 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. >> > >> >> Since I have never seen that come up during Python's development I am >> going to leave it out. But I do see the benefit and how it might help >> with future work. > > Euhm, wut? It hasn't come up during Python's development because Python is > being developed in a VCS with very limited branches :) I'm partial to VCS's > with proper branching (as you know) and I've been using that mode of > development for many years. I've done development and maintenance of > multi-developer projects using both the CVS/SVN nonbranching approach and > the typical DVCS branch-often approach using BitKeeper, Bazaar and Mercurial > (as well as the sort-of one-off-branch Perforce approach where you can > easily 'wrap' a single change but can't really do dependant changes) -- and > whenever possible I use the branch-often approach with dependant branches > all over the place, especially when working on large, complicated changes. > Building them up out of separate 'components' requires a little more > administration (you have to remember which branch to submit to) but it makes > debugging, piecemeal discussion and batchwise integration a *lot* easier. > I know it isn't used because of what VCSs we have used, which is why I have no experience with it and feel uncomfortable using it as a necessary usage scenario to evaluate whether a DVCS is better than svn, and if so which one. But then again, having one scenario that shows svn's weakness directly wouldn't hurt. I could see a scenario where I start to fix something in branch A, realize that a deeper issue needs to be fixed, leading to branch B, and then have branch A depend on branch B. Is that possible? Or is injecting branch dependencies like that not workable? If it doesn't work, then a branch A/B that a branch C is dependent on would also work as a scenario (e.g. reworking the testing framework where you are doing a bunch of different things at once that are culminating in a single new testing branch that collects everything). Those sound like what you are getting after? -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 11:57, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote: >> Since I have never seen that come up during Python's development I am >> going to leave it out. But I do see the benefit and how it might help >> with future work. > > Of course, that's entirely up to you. But it strikes me as an odd > approach to the selection of scenarios for a tool whose intention is > precisely to support new usage scenarios. > >> As I mentioned in the doc, the first example allows for whatever the >> DVCS does for diffs, whether that is a full-on branch or not. > > Are you looking for new scenarios or for the validation of your document? :-) > Both. First and foremost I am looking for any scenarios people are using now for svn that I didn't cover. After that I can probably add some DVCS-specific things. But the problem with that is my DVCS experience is limited and thus I don't want to add a scenario that seems whizbang cool but in real life is never used; premature optimization and all that. > I'm talking about history-carrying diffs which can be attached and > sent via mail, not about viewing plain diffs, which every VCS tool in > the world can do since version 0.0. > As I said, one of the scenarios already says patches can be whatever the DVCS supports the best; plain diffs, branches, etc. And the comments for that scenario will point out any perks from that feature. As for the "via mail" feature, I use Gmail so it doesn't mean anything to me. =) > Anyway, I guess you already have what you want. Good luck picking the > right choice! Oh, there won't be a right choice (except in my mind), there will just be the best choice that could be made based on the circumstances. Working on the issue tracker taught me that lesson. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] New "stage" field in the tracker
Martin added a new "stage" field in the tracker so that issues can now be more clearly identified in terms of what is needed to move them forward. For now it is probably best to continue to use both keywords and stage values (i.e. the "patch" keyword is implied when the stage of an issue goes beyond "needs patch" and the need for a "patch review" is covered by the "commit review" stage). Once the use of the stage gets far enough along we can discussed ditching the keywords. Anyway, cheers to our first step in improving our workflow! -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Brett Cannon wrote: > But then again, having one scenario that shows svn's weakness directly > wouldn't hurt. I could see a scenario where I start to fix something > in branch A, realize that a deeper issue needs to be fixed, leading to > branch B, and then have branch A depend on branch B. Is that possible? > Or is injecting branch dependencies like that not workable? If it > doesn't work, then a branch A/B that a branch C is dependent on would > also work as a scenario (e.g. reworking the testing framework where > you are doing a bunch of different things at once that are culminating > in a single new testing branch that collects everything). > > Those sound like what you are getting after? Hmm, perhaps your concrete example of this could be a case where someone was working on an object capabilities security model and then realised they needed a more flexible implementation of the import system before their security mechanism was going to work ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg branch gone?
On Mon, Nov 3, 2008 at 22:15, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Nov 3, 2008, at 11:54 AM, Thomas Wouters wrote: > > FWIW, I put one up this weekend, and it seems to be intact and OK. >> (bzr+ssh://[EMAIL PROTECTED]/python/2.6/ or >> http://code.python.org/python/2.6/ ) >> > > Excellent, thanks! This is getting mirrored with updates, right? > Exactly the same way 2.5, trunk and 3.0 are, yes. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
On Mon, Nov 3, 2008 at 12:41 PM, Victor Stinner <[EMAIL PROTECTED]> wrote: > Hi, > > Le Monday 03 November 2008 18:56:37 Paul Miller, vous avez écrit : >> I've read some of the past discussion about including GMP into the >> python core and understand the reasons for not doing so. > > Please, check this issue: http://bugs.python.org/issue1814 > > I patched Python3 to use GMP because I thaugh that GMP is much faster than > Python for integer computation. The "problem" is that GMP target are integers > much bigger than 10**100. As I remember, GMP has a special hack for very > small integer: integer which can be stored in one CPU word, but it's not > enough to speed up Python. > > With my last patch, with GMP, Python is 2% *slower*. > > My patch can be improved, but I expected +20% to +100% to no -2% :-/ One optimization that could be done to the existing Python longobject code is to allow it to use larger digits. Currently it is hardcoded to use 15bit digits. The most common desktop+server CPUs in the world (x86) all support efficient 32bit*32bit -> 64bit multiply so there is no good reason to limit python itself to 15bit digits when on either x86 or x86_64. 30 or 31bit digits would be more efficient as more numbers would then be a single digit shortcutting their computations and the number of digits for others would be half. The ability to use 15bit digits is good for other cpus but is wasteful when the hardware supports more (32bit x86 and all 64bit archs). > > And there is also the license issue... > > -- > Victor Stinner aka haypo > http://www.haypocalc.com/blog/ > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] hg branch gone?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 5:22 PM, Thomas Wouters wrote: Exactly the same way 2.5, trunk and 3.0 are, yes. Beauty, thanks. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ98J3EjvBPtnXfVAQLD0AQAhvDoJ85HtO0o/KxeU//kRjid7j0SVIJA OaKnMA/om71Ft5733ZIJYE1jQ1+WFr8TZggiD5NG6d3Af8f8Q0Ep2ujBpOYjKhcQ 85DEmeY2WkoeYqMZXFhEa76BrrPHQtOzEzagRTGIvLnw3W5DbKzTawg8D4z4qmG3 vtQkzEg7Lfw= =cGIL -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 22:56, Brett Cannon <[EMAIL PROTECTED]> wrote: > But then again, having one scenario that shows svn's weakness directly > wouldn't hurt. I could see a scenario where I start to fix something > in branch A, realize that a deeper issue needs to be fixed, leading to > branch B, and then have branch A depend on branch B. Is that possible? > Or is injecting branch dependencies like that not workable? If it > doesn't work, then a branch A/B that a branch C is dependent on would > also work as a scenario (e.g. reworking the testing framework where > you are doing a bunch of different things at once that are culminating > in a single new testing branch that collects everything). Here's a real-life Python example: http://bugs.python.org/issue2292. I actually developed that in two separate branches, one depending on the other: one branch for *just* the changes to functioncalls, to generalize *- and **-unpacking in that context, and one branch to add *- and **-unpacking in other contexts, which was a much more contentious proposal. The division means that the first part can be committed without the second part *without any extra effort from anyone*. I wouldn't have to undo changes, I wouldn't have to reapply diffs or do a painful manual merge were the first branch to be merged into the trunk. It would be completely straightforward and effortless. Of course, that's just a small-scale example. I've done much larger of these in the past, but not on Python. You can easily dream up more examples, though: a branch for the gforth generated ceval loop, with separate branches off of that branch with different approaches to the superinstructions. The right one could be picked at a later time, or branches could be merged, or they could all be omitted. The generated ceval loop could be backported to 2.7 without including the superinstructions that were merged into 3.0. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
> Both. First and foremost I am looking for any scenarios people are > using now for svn that I didn't cover. After that I can probably add > some DVCS-specific things. But the problem with that is my DVCS > experience is limited and thus I don't want to add a scenario that So try to listen to people that actually use these tools and are trying to help you. > seems whizbang cool but in real life is never used; premature > optimization and all that. As I mentioned early in my mail, all the scenarios I described were specifically meant to expose common situations that we go through in our workflow. I'm not picking weird things to try favoring any specific tool, even because I believe all tools should support these very basic desires. > As I said, one of the scenarios already says patches can be whatever > the DVCS supports the best; plain diffs, branches, etc. And the > comments for that scenario will point out any perks from that feature. """ This scenario to meant to represent the steps required for a non-core developer who has a one-off patch they want to create from a read-only checkout. """ Ok, so would you mind to expand that to describe that the tool should send the history of the "one-off patch", and what it means to not send it? Otherwise you're really comparing oranges and apples. If I send you "svn diff" or "bzr diff", you get a plain diff. Merging this will not carry the history of who made the chances, what were the incremental steps, and will handle conflicts without context, which may be way more boring to perform than when you actually have full history information. That's not the same as using "bzr send". Again, that's a real world situation, not something I'm making up to favor bzr. I'm pretty sure hg should have something similar too (and git does for sure). > As for the "via mail" feature, I use Gmail so it doesn't mean anything to me. > =) Please ask Tim to teach you how the "mail" word got in "Gmail". ;-) -- Gustavo Niemeyer http://niemeyer.net ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 4:56 PM, Brett Cannon wrote: But then again, having one scenario that shows svn's weakness directly wouldn't hurt. I could see a scenario where I start to fix something in branch A, realize that a deeper issue needs to be fixed, leading to branch B, and then have branch A depend on branch B. Is that possible? This is something I do all the time with bzr. A related workflow is one where you're developing several inter-related dependent branches. In those scenarios, I personally find Bazaar looms indispensable. I'm told that bzr looms are similar to hg quilt. Until I started using looms I had no idea of their power and transformative effect on my code development. This is one of the problems of coming up with scenarios: you don't know what you're missing. Or is injecting branch dependencies like that not workable? If it doesn't work, then a branch A/B that a branch C is dependent on would also work as a scenario (e.g. reworking the testing framework where you are doing a bunch of different things at once that are culminating in a single new testing branch that collects everything). Those sound like what you are getting after? Let me try to describe a scenario and see if it fits what you're looking for. I'm fixing a bug in urllib2.py when I realize there's a lower-level bug in base64.py. I'd like to cleanly suspend my work on urllib2.py, then "push my stack" to start working on the fix for base64.py. Half way through that I realize there's also a bug in binascii that I need to fix. I'd now like to "push my stack" once more to fix the binascii problem. Now that binascii is fixed, I'd like to pop my stack to complete the base64 fix, but without losing all the changes I made to binascii. Similarly, when I've fixed base64, I want to retain those fixes and pop my stack back up to urllib2. I've now got three related fixes. Do I get each reviewed independently or together? Do I land them independently or together? Can my dvcs help me manage all these inter-dependent branches? For bzr, the answer is "yes" and my own workflow to handle this uses looms, which you can think of as a kind of "stacked branches" approach. Each layer in the stack is called a "thread" and I can easily create new threads in the stack. So I might approach the above scenario like so: bzr branch trunk issue1234 cd issue1234 bzr loomify --nick trunk bzr create-thread urllib2-fix # hack hack hack, oops! gotta fix the bug in base64 bzr commit -m'Fixes to urllib2 so far' bzr down-thread bzr create-thread base64-fix # hack hack hack, oops! gotta fix binascii bzr commit -m'Fixes to base64 so far' bzr down-thread bzr create-thread binascii-fix # hack hack hack. ah, all is good bzr commit -m'Fixes to binascii' bzr up-thread # At this point, all my binascii-fix changes are merged in # resolve any conflicts that arose and commit, then finish # hacking on base64 bzr commit -m'Fixes to base64' bzr up-thread # At this point all my binascii-fix and base64-fix changes # are merged in. resolve any conflicts that arose and commit # then finish hacking on urllib2 bzr commit -m'Fixes to urllib2' Here's what's even cooler. Let say, while I was working on all this, someone landed a change to trunk that I want in my branch. I can 'bzr down-thread' to the lowest thread (i.e. trunk), pull in those changes, and then using 'bzr up-thread' merge them into all the threads above. Then I go back to hacking. There are all kinds of scenarios based on this one, and I hope the above makes sense. It's things like this (and 'bzr shelve') which make using a dvcs like Bazaar so nice. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ+BNHEjvBPtnXfVAQLLrwP/aJuetZxYI0S0SvT5QXJG6wARI2K9vdc5 zpUMHofCkxAq4tv/2Ni7g46jUNTayH4A94sAUqjE0QPM3SFl22/TNjga4ZgaHdjt 7Ma9iX7+s5OJenvV0kd3ReN6KvcKQhcQZ+P4DkWBJu0KDxGptUk/WGer3aDdQNzV jn88QaHpEBk= =fPRR -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 5:03 PM, Brett Cannon wrote: As I said, one of the scenarios already says patches can be whatever the DVCS supports the best; plain diffs, branches, etc. And the comments for that scenario will point out any perks from that feature. It's actually a profound improvement not to have to deal with traditional patch files as much. The feel... dead somehow, compared to a live branch which can track changes to the trunk, etc. As for the "via mail" feature, I use Gmail so it doesn't mean anything to me. =) It should though. In Bazaar, a bundle is essentially the revisions in your branch that are packaged to transport over RFC 2821 and 2822. :) That opens up some really cool abilities, such as sending a bundle to a buildbot or patch queue manager for automated testing. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ+CGXEjvBPtnXfVAQKOnAQAs/cr+g091KyjteQaY/quBBIJ53PUoilC MLK9fNLz4jq0eDtl+Rw49rmAFmhKJQaJqx91dZszPEc4FyP9lZByqTbNoCLFhPJP asmxWS263hjx8tXL+RfX+C0Atk9OWzy7j45oa3/J9aBui4ihyI5Yh8/9l8KiCude 6TajzeRcIWs= =6euF -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 5:39 PM, Thomas Wouters wrote: Here's a real-life Python example: http://bugs.python.org/issue2292. I actually developed that in two separate branches, one depending on the other: one branch for *just* the changes to functioncalls, to generalize *- and **-unpacking in that context, and one branch to add *- and **- unpacking in other contexts, which was a much more contentious proposal. The division means that the first part can be committed without the second part *without any extra effort from anyone*. I wouldn't have to undo changes, I wouldn't have to reapply diffs or do a painful manual merge were the first branch to be merged into the trunk. It would be completely straightforward and effortless. Great example. The looms scenario I posted earlier would be perfect for this. I do this all the time with larger feature development. I can have 4 or 5 threads in a typical loom, though I know of people who use many more. It makes developing depending features actually manageable. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ+Cm3EjvBPtnXfVAQJkMwQAg3r/JFAOE3RlxbrtPl48QOyjS3PhN7xg +wOoVz+FgLTkx2187xbSqBjy8K69uC3R3Y/1Foc7OmhUEtTGMfmStwoWdjB3f2zi BOgYDPcEaDHC5opfDWtbWpYOJzVcfRJJxhAbevHlKeUSX0/bFd39UY58DXgwR9aI BAjTj4Gt66U= =nbTw -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
> One optimization that could be done to the existing Python longobject > code is to allow it to use larger digits. Currently it is hardcoded > to use 15bit digits. > > The most common desktop+server CPUs in the world (x86) all support > efficient 32bit*32bit -> 64bit multiply so there is no good reason to > limit python itself to 15bit digits when on either x86 or x86_64. Perhaps Tim Peters should also comment here - but if you can come up with a patch that does that in a portable way, I would be in favor. The challenge, ISTM, is to make it still compile on all systems (regardless of how inefficient it might be on minor platforms). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] XXX do we need a new policy?
Grepping through Python's sources tells me that we have over 2,000 "XXX" comments. The thing that irks me about them is that the have a very slow rate of being resolved, since they usually act more as "notes to self" rather than easily attainable tasks. So, I propose that we adopt a policy similar to Twisted's: All "XXX" comments must have an issue in the tracker and an accompanying link with the source code. That way we'll have a forum for discussing the changes and deciding whether they are reasonable enough to implemented. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XXX do we need a new policy?
On Mon, Nov 3, 2008 at 3:39 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > Grepping through Python's sources tells me that we have over 2,000 > "XXX" comments. The thing that irks me about them is that the have a > very slow rate of being resolved, since they usually act more as > "notes to self" rather than easily attainable tasks. > > So, I propose that we adopt a policy similar to Twisted's: All "XXX" > comments must have an issue in the tracker and an accompanying link > with the source code. That way we'll have a forum for discussing the > changes and deciding whether they are reasonable enough to > implemented. That seems excessively draconian. Even at Google we don't have a rule like that, and we're sure big on process and interlinked tools. If you want to, you could add a different magic keyword, but personally, I don't see XXX comments necessarily as "to be resolved" -- merely as flags for someone perusing the code looking to change it or digging for the cause of some problem to pay special attention. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XXX do we need a new policy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Nov 3, 2008, at 6:39 PM, Benjamin Peterson wrote: Grepping through Python's sources tells me that we have over 2,000 "XXX" comments. The thing that irks me about them is that the have a very slow rate of being resolved, since they usually act more as "notes to self" rather than easily attainable tasks. So, I propose that we adopt a policy similar to Twisted's: All "XXX" comments must have an issue in the tracker and an accompanying link with the source code. That way we'll have a forum for discussing the changes and deciding whether they are reasonable enough to implemented. We have a very similar policy here at work. Sadly I don't think it does much on actually resolving the issues. XXX bugs tend to be pretty minor in the scheme of things and they're almost always lower on the priority list than everything else. That being said, we recognize that XXX bugs incur "technical debt" and reducing that debt is something we're devoting Real Time to doing. I see that Guido is not keen on the idea, and I'm not sure my observations help sway things one way or the other. OTOH, it would be nice if at least we always add our own identifier (initials, nick, email address) and a date to the XXX so we at least know who was talking about what. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSQ+N8HEjvBPtnXfVAQLSPAP/ZKHOTaPxNPySfxPwGmbLSTXjSst+z4/f 1SkhkKjOq8/pjjftZW8n6AWb4WSIWXcyCPJ3FGOAXaP141px2yMfRQnXXbdyH6vQ 6sW12e4ZC2J8UPUyzOxiFJb5F8/HhmIMVifzV1vkEf60QYo9lCD614rBdiW30q9v pWudrLQUMEM= =1USW -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XXX do we need a new policy?
On Mon, Nov 3, 2008 at 3:49 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: > On Nov 3, 2008, at 6:39 PM, Benjamin Peterson wrote: > >> Grepping through Python's sources tells me that we have over 2,000 >> "XXX" comments. The thing that irks me about them is that the have a >> very slow rate of being resolved, since they usually act more as >> "notes to self" rather than easily attainable tasks. >> >> So, I propose that we adopt a policy similar to Twisted's: All "XXX" >> comments must have an issue in the tracker and an accompanying link >> with the source code. That way we'll have a forum for discussing the >> changes and deciding whether they are reasonable enough to >> implemented. > > We have a very similar policy here at work. Sadly I don't think it does > much on actually resolving the issues. XXX bugs tend to be pretty minor in > the scheme of things and they're almost always lower on the priority list > than everything else. > > That being said, we recognize that XXX bugs incur "technical debt" and > reducing that debt is something we're devoting Real Time to doing. > > I see that Guido is not keen on the idea, and I'm not sure my observations > help sway things one way or the other. OTOH, it would be nice if at least > we always add our own identifier (initials, nick, email address) and a date > to the XXX so we at least know who was talking about what. At Google we use TODO(): Blah, blah. I don't think ading a date would help much but I wouldn't be opposed to this. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
Benjamin> The main objection is that GMP is licensed under LGPL which I Benjamin> believe conflicts with Python's very open license. >> If GMP itself isn't included with Python how can there be a licensing >> issue? Martin> On Windows, the GMP binaries would be incorporated into Martin> pythonxy.dll. This would force anybody providing a copy of Martin> pythonxy.dll to also provide the sources of GMP. As I understand it the proposal was to allow people to substitute GMP for Python's long implementation. Just deliver binaries with the Python long version if you don't want to distribute the GMP source. OTOH, it should be no big deal to drop a zip archive of the GMP sources which correspond to the code bound into the DLL. OTOOH, doesn't Windows support dynamic linking? Can't pythonxy.dll dynamically link to a gmpMN.dll? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
On Tue, Nov 4, 2008 at 01:37, <[EMAIL PROTECTED]> wrote: > >Benjamin> The main objection is that GMP is licensed under LGPL which I >Benjamin> believe conflicts with Python's very open license. > >>> If GMP itself isn't included with Python how can there be a licensing >>> issue? > > Martin> On Windows, the GMP binaries would be incorporated into >Martin> pythonxy.dll. This would force anybody providing a copy of >Martin> pythonxy.dll to also provide the sources of GMP. > > As I understand it the proposal was to allow people to substitute GMP for > Python's long implementation. Just deliver binaries with the Python long > version if you don't want to distribute the GMP source. OTOH, it should be > no big deal to drop a zip archive of the GMP sources which correspond to > the > code bound into the DLL. OTOOH, doesn't Windows support dynamic linking? > Can't pythonxy.dll dynamically link to a gmpMN.dll? > Neither of those (shipping sources or dynamically linking to GMP) would solve the LGPL issue. People who distribute that build of Python would still be held by the LGPL -- such as shipping any sources that they embed that Python into. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python2.5 _sre deepcopy regression?
I posted this week ago, but haven't seen any comments. Issue
416670 is probably the most relevent ticket.
The buggy changeset I mention, 38430 on the release24-maint branch is
one that had been forward and back-ported for a while. I haven't found
the motivation for that change, but it hasn't been applied to any version
of Python later than 2.4.
>In version of Python prior to 2.5, it would appear that deepcopying
>compiled regular expressions worked by accident:
>
>2.4:
>
>>>> copy.deepcopy(re.compile(''))
><_sre.SRE_Pattern object at 0xb7d53ef0>
>
>2.5:
>
>>>> copy.deepcopy(re.compile(''))
>Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python2.5/copy.py", line 173, in deepcopy
>y = copier(memo)
>TypeError: cannot deepcopy this pattern object
>
>I say "by accident", since the SRE_Pattern object in 2.4 has
>a __deepcopy__ method which raises the "cannot deepcopy this pattern
>object" TypeError, however this method isn't found by copy.deepcopy()
>in 2.4, and copy.deepcopy() falls back to using the pickle logic.
>
>The _sre source has #ifdef-out support for __deepcopy__, issue 416670
>has the gory details:
>
>http://bugs.python.org/issue416670
>
>Changeset 38430 on the release24-maint branch introduced the changes
>that stopped SRE_Pattern.__deepcopy__ being found. r38430 was a patch
>forward ported from 2.3, but never ported to the trunk (probably a good
>thing, too).
>
>Thoughts?
--
Andrew McNamara, Senior Developer, Object Craft
http://www.object-craft.com.au/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
Thomas Wouters writes: > Neither of those (shipping sources or dynamically linking to GMP) would > solve the LGPL issue. People who distribute that build of Python would still > be held by the LGPL -- such as shipping any sources that they embed that > Python into. No, that's exactly what the "L" in "LGPL" means. You only have to ship the sources to any object module (library or program) actually containing GMP code, including any modifications you make to them. So if GMP is kept entirely in a separate library and you don't borrow any code from it, the rest of your code is not affected by the LGPL. This includes any marshalling code that does nothing but load the GMP library and connect it up to Python's internal API; that need not be LGPL unless you add it to the GMP library. The "problem" with the LGPL is the administrative burden of tracking which sources need to be distributed under what conditions, not that it insinuates itself into your own code. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fwd: Removal of GIL through refcounting removal.
On Mon, Nov 3, 2008 at 10:59 AM, Curt Hagenlocher <[EMAIL PROTECTED]>wrote: > On Mon, Nov 3, 2008 at 11:50 AM, Josiah Carlson <[EMAIL PROTECTED]>wrote: > >> On Sun, Nov 2, 2008 at 3:51 PM, <[EMAIL PROTECTED]> wrote: >> >>> >>>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". >>> >> >> Which is, arguably, silly. As we've seen in the last 2 months with >> Chrome, multiple processes for a single "program" is actually a pretty good >> idea. With the multiprocessing module in the standard library offering a >> threading-like interface, people no longer have any excuses for not fully >> exploiting their multiple cores in Python. >> > > There is no shortage of algorithms (such as matrix multiplication) that are > parallelizable but not particularly good candidates for an IPC-based > multiprocessing paradigm. > Ahh, but those algorithms aren't going to be written in Python; they are going to be written in C, and are going to manipulate memory directly. With such things, you can use standard Python threads, call into your C runtime, and release the GIL. Alternatively, you can use the mmap module to store your data, shared across multiple processes, using the same direct-memory access as you would with multiple threads and GIL release. Also, most local-only communications primitives (named pipes, anonymous pipes, unix domain sockets, ...) use zero/one copy implementations, so as long as your RPC isn't slow, you can do pretty well even on the Python side (especially if you pre-allocate your receive buffer, and fill in the data as you receive it; this is pretty much what mutablebytes was created for, now we just need a proper memoryview). So again, I claim that not using multiple processes for your multi-core machine in order to use your multiple cores to their full extent is silly. As an aside, Python array.array() instances have a char* and length, so if you are careful, you can create an array.array object from an mmap pointer, and get fairly decent performance even in Python with shared memory. Someone should probably look into allowing array.array() to take a read/readwrite memoryview as an argument to support such things, as well as allowing mmaps to be passed via multiprocessing (if they aren't already supported). - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Jesse Noller writes:
> I don't see how git can be considered given poor windows support -
> compilation on OS/X can be a bear too.
I can't speak to the "poor Windows support", but I've been compiling
both in MacPorts (pretty much every MacPorts release, which is like
weekly) and from the kernel.org repo (intermittently, 1-3 months
apart) on Mac OS X since git 0.99 and the only trouble is with the
documentation (and the never-ending stream of bugs in port and/or the
Portfile, of course). I doubt this is a problem on Mac OS X any more,
if it ever was.
> Also the ability to completely nuke the local-work-copies commit
> history ("cleaning it up") worries me, but I'm also paranoid.
bzr and hg both offer a similar feature. They just make it less
convenient and possibly more dangerous to use (because the operation
that cleans up history also destroys it, where in git cleaning up
history creates garbage). People who dislike merge turds will use it
and there is nothing you can really do about that.
git is at least as safe in this respect as any other dVCS, because it
allows you to get the unwanted history out of your face, but it then
becomes garbage remains in the repository until you actually do a
git-gc --prune. It's easy to collect dangling heads and check whether
you need them. Again, some people will throw them away, but there's
nothing you can do about that. You don't have to throw away your own
history, though.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 14:58, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On Nov 3, 2008, at 5:03 PM, Brett Cannon wrote: > >> As I said, one of the scenarios already says patches can be whatever >> the DVCS supports the best; plain diffs, branches, etc. And the >> comments for that scenario will point out any perks from that feature. > > It's actually a profound improvement not to have to deal with traditional > patch files as much. The feel... dead somehow, compared to a live branch > which can track changes to the trunk, etc. > Which I am sure will be pointed out in the scenario. I just want some file I can attach to an issue, period. After that the perks of what that file contains in terms of history, etc., can be enumerated. >> As for the "via mail" feature, I use Gmail so it doesn't mean anything to >> me. =) > > It should though. In Bazaar, a bundle is essentially the revisions in your > branch that are packaged to transport over RFC 2821 and 2822. :) That opens > up some really cool abilities, such as sending a bundle to a buildbot or > patch queue manager for automated testing. But this just smells of premature optimization to me. For instance, as of this exact moment Martin is basically the only person staying on top of the tracker. He also is typically the buildbot person as well. And this is not from a lack of trying to get help with the tracker multiple times. It's just people just don't stick around, as you know. Trying to expand our buildbot infrastructure to accept patches to test out or some patch queue manager might be nice, but I want to be realistic with what we have now. That's why I am not worrying about this email feature; until I know that we will actually use it and have the manpower to implement it I consider it a perk that might never be used. It's all great to dream about the future and what could be, but that is far beyond just trying to get us to switch to a DVCS and is just icing on the cake. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XXX do we need a new policy?
On Mon, Nov 3, 2008 at 6:04 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Mon, Nov 3, 2008 at 3:49 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >> On Nov 3, 2008, at 6:39 PM, Benjamin Peterson wrote: >> >>> Grepping through Python's sources tells me that we have over 2,000 >>> "XXX" comments. The thing that irks me about them is that the have a >>> very slow rate of being resolved, since they usually act more as >>> "notes to self" rather than easily attainable tasks. >>> >>> So, I propose that we adopt a policy similar to Twisted's: All "XXX" >>> comments must have an issue in the tracker and an accompanying link >>> with the source code. That way we'll have a forum for discussing the >>> changes and deciding whether they are reasonable enough to >>> implemented. >> >> We have a very similar policy here at work. Sadly I don't think it does >> much on actually resolving the issues. XXX bugs tend to be pretty minor in >> the scheme of things and they're almost always lower on the priority list >> than everything else. >> >> That being said, we recognize that XXX bugs incur "technical debt" and >> reducing that debt is something we're devoting Real Time to doing. >> >> I see that Guido is not keen on the idea, and I'm not sure my observations >> help sway things one way or the other. OTOH, it would be nice if at least >> we always add our own identifier (initials, nick, email address) and a date >> to the XXX so we at least know who was talking about what. > > At Google we use TODO(): Blah, blah. I don't think ading a > date would help much but I wouldn't be opposed to this. That reminds me of the other problem with XXX. They get out of date without being removed. I've even seen an XXX comment followed by another asking, "Is this still valid?". You're probably right that adding a date would help much unless we agreed to remove old comments with little value after a year or so. -- Cheers, Benjamin Peterson "There's nothing quite as beautiful as an oboe... except a chicken stuck in a vacuum cleaner." ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 17:59, Stephen J. Turnbull <[EMAIL PROTECTED]> wrote: > Jesse Noller writes: > > > I don't see how git can be considered given poor windows support - > > compilation on OS/X can be a bear too. > > I can't speak to the "poor Windows support", but I've been compiling > both in MacPorts (pretty much every MacPorts release, which is like > weekly) and from the kernel.org repo (intermittently, 1-3 months > apart) on Mac OS X since git 0.99 and the only trouble is with the > documentation (and the never-ending stream of bugs in port and/or the > Portfile, of course). I doubt this is a problem on Mac OS X any more, > if it ever was. > Well, when I decided to compile git from scratch on OS X when Neil posted the git mirror it took bloody forever thanks to the docs having an insane build requirement. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
[Gregory P. Smith] >> One optimization that could be done to the existing Python longobject >> code is to allow it to use larger digits. Currently it is hardcoded >> to use 15bit digits. >> >> The most common desktop+server CPUs in the world (x86) all support >> efficient 32bit*32bit -> 64bit multiply so there is no good reason to >> limit python itself to 15bit digits when on either x86 or x86_64. [Martin v. Löwis] > Perhaps Tim Peters should also comment here - but if you can come up > with a patch that does that in a portable way, I would be in favor. > The challenge, ISTM, is to make it still compile on all systems > (regardless of how inefficient it might be on minor platforms). Eh -- the strong points of Python's long implementation have always been reliability and portability. Both are greatly aided by sticking to operations spellable in standard C89, and by avoiding platform-specific trickery & #ifdef'ery. So, no, I'm not keen on this. Note that while 32x32->64 multiply is supported by x86 HW, that doesn't mean there's a uniform way to get at this HW capability across C compilers. In contrast, (at least) efficient HW 15x15->30 multiply is universally spelled in C via "i*j" :-) A similar gripe applies to schemes to replace the long implementation by GMP (optionally or not): it adds complexity to the code. I like GMP myself, but am happy using one of the Python GMP wrappers when I /want/ GMP (as timings in other messages show, using GMP is a speed loser before ints grow "really big"). Indeed, if I had it to do over again, I would balk even at adding Karatsuba multiplication to Python (it added extra complexity with no real payback, given that those who care about the speed of very long int multiplication are far better off using a GMP wrapper anyway). grouchily y'rs - tim ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
On Mon, Nov 3, 2008 at 14:38, Gustavo Niemeyer <[EMAIL PROTECTED]> wrote: >> Both. First and foremost I am looking for any scenarios people are >> using now for svn that I didn't cover. After that I can probably add >> some DVCS-specific things. But the problem with that is my DVCS >> experience is limited and thus I don't want to add a scenario that > > So try to listen to people that actually use these tools and are > trying to help you. > I am and why I will add either Thomas' or Barry's scenario. >> seems whizbang cool but in real life is never used; premature >> optimization and all that. > > As I mentioned early in my mail, all the scenarios I described were > specifically meant to expose common situations that we go through in > our workflow. I'm not picking weird things to try favoring any > specific tool, even because I believe all tools should support these > very basic desires. > I didn't think you were picking scenarios that were odd, but I am sure you also have an IT staff to make sure your workflow can support all of that (see my reply to Barry). >> As I said, one of the scenarios already says patches can be whatever >> the DVCS supports the best; plain diffs, branches, etc. And the >> comments for that scenario will point out any perks from that feature. > > """ > This scenario to meant to represent the steps required for a non-core > developer who has a one-off patch they want to create from a read-only > checkout. > """ > > Ok, so would you mind to expand that to describe that the tool should > send the history of the "one-off patch", and what it means to not send > it? > "Send" as in automatically submit? > Otherwise you're really comparing oranges and apples. If I send you > "svn diff" or "bzr diff", you get a plain diff. Merging this will not > carry the history of who made the chances, what were the incremental > steps, and will handle conflicts without context, which may be way > more boring to perform than when you actually have full history > information. That's not the same as using "bzr send". > Hey, if what ``bzr send`` generates can be uploaded to bugs.python.org, then that is what will be listed in the scenario. > Again, that's a real world situation, not something I'm making up to > favor bzr. I'm pretty sure hg should have something similar too (and > git does for sure). > >> As for the "via mail" feature, I use Gmail so it doesn't mean anything to >> me. =) > > Please ask Tim to teach you how the "mail" word got in "Gmail". ;-) I have learned to ignore my uncle for years so it won't do much good. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XXX do we need a new policy?
On Mon, Nov 3, 2008 at 7:35 PM, Benjamin Peterson <[EMAIL PROTECTED]> wrote: > On Mon, Nov 3, 2008 at 6:04 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: >> On Mon, Nov 3, 2008 at 3:49 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote: >>> On Nov 3, 2008, at 6:39 PM, Benjamin Peterson wrote: >>> Grepping through Python's sources tells me that we have over 2,000 "XXX" comments. The thing that irks me about them is that the have a very slow rate of being resolved, since they usually act more as "notes to self" rather than easily attainable tasks. So, I propose that we adopt a policy similar to Twisted's: All "XXX" comments must have an issue in the tracker and an accompanying link with the source code. That way we'll have a forum for discussing the changes and deciding whether they are reasonable enough to implemented. >>> >>> We have a very similar policy here at work. Sadly I don't think it does >>> much on actually resolving the issues. XXX bugs tend to be pretty minor in >>> the scheme of things and they're almost always lower on the priority list >>> than everything else. >>> >>> That being said, we recognize that XXX bugs incur "technical debt" and >>> reducing that debt is something we're devoting Real Time to doing. >>> >>> I see that Guido is not keen on the idea, and I'm not sure my observations >>> help sway things one way or the other. OTOH, it would be nice if at least >>> we always add our own identifier (initials, nick, email address) and a date >>> to the XXX so we at least know who was talking about what. >> >> At Google we use TODO(): Blah, blah. I don't think ading a >> date would help much but I wouldn't be opposed to this. > > That reminds me of the other problem with XXX. They get out of date > without being removed. Not that often. > I've even seen an XXX comment followed by > another asking, "Is this still valid?". That's a clue though that the code being commented is extremely hairy -- if the second commenter couldn't deduce whether the first comment was still valid, a double red flag is well worth having! > You're probably right that adding a date would help much unless we > agreed to remove old comments with little value after a year or so. I disagree. They should be removed when the issue they refer to is removed. No sooner, no later. Simply removing every XXX comment older than a year would not be helpful. The code base is so large that over 2000 XXX doesn't faze me particular. There are over 4000 files in the Python 2.6 source code tarball! The right thing to do with XXX comments is to read them when you're in their vicinity, and to act when the urge becomes too strong to deal with any one in particular. Dealing with them en masse is just asking for a migraine. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XXX do we need a new policy?
From: "Guido van Rossum" <[EMAIL PROTECTED]> The right thing to do with XXX comments is to read them when you're in their vicinity, and to act when the urge becomes too strong to deal with any one in particular. Dealing with them en masse is just asking for a migraine. I concur. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Looking for VCS usage scenarios
Brett Cannon writes: > I have yet to have met anyone who thinks git is great while having > used another DVCS as extensively (and I mean I have never found > someone who has used two DVCSs extensively). When XEmacs was considering changing from CVS, I used Darcs as my primary VCS for about 4 months, including a mammoth (>1MB patch) merge. Since Dec 2007, Mercurial has been the official XEmacs VCS. Nowadays I'm more management than developer but I love git, and will not use either Darcs or Mercurial for any project where git is an option. (Somebody else did the work of moving the CVS history, so they got to choose Mercurial -- in hindsight, it would have been worth doing the work) I don't know if that counts as "extensive". I like git because (1) I like the model of exposing the commit DAG directly as a graph of objects. (2) It's very fast. (3) It does not promote a particular style of development. Both merging parallel branch tips and rebasing to serialize branches on the trunk are well-supported. (Mercurial and especially Bazaar do support the merging style better than git does.) (4) Branching is cheap and fast. I typically have a subbranch for almost every typo/minor fix I do in a working branch, which I then cherrypick into the mainline. (This workflow avoids merge conflicts due to cherrypicking typo fixes directly from the subbranch. Mercurial makes such cherrypicking relatively inconvenient, and I often make mistakes and commit too much in the wrong branch. In Darcs this can be very painful because of dependencies the cherrypick drags in.) Switching branches is a sub-second operation until the diff gets to be about 15-20 files. (5) All branches are explicit. You commit to the current branch. (6) Files to commit must be named in the commit command, marked with an add command, or included via the --all option. (7) A fairly natural, if ugly, syntax for specifying revisions, ranges, and various operations on ranges in log and diff commands. No "revision numbers" that vary randomly according to workspace. I dislike Darcs because (1) The DAG is implicit. (2) It's slow. (3) I never know what I'll get when I ask to pull a single patch; Darcs's criteria for dependency are opaque, at least to me. (4) It's hard to script and really likes to be used interactively. I dislike Mercurial because (1) It strongly encourages a commit-then-merge style which results in a large number of "merge turds" in the history. Since most "merges" succeed because the changes are in different files, these are very annoying to me. (2) The default revision numbering typically results in rather bizarre diffs near merges, but there is no easy way to specify a particular parent (except the first) without looking up the log. (3) Commits everything in the workspace by default. (4) Commit is silent by default, so you don't realize how much you have committed until you push ... and have succeeded so you can no longer roll it back safely. (5) Creates new branches without being asked, which then need to be merged, thus strongly encouraging the commit-then-merge style. (6) I don't trust its compute-ancestors-separately-per-file merge algorithm. If this really works, there's nothing wrong in principle with CVS! (7) A lot of features require plugins, and the result is command proliferation, though unlike git only "porcelain" is exposed. I haven't used Bazaar beyond "bzr pull" of Mailman once a week or so, so I don't dislike it. Things I have observed or have seen discussed on the bazaar mailing list that you might want to consider: (1) The UI is as baroque as git's, once you consider all the plugins and GUIs that are available. Lots of different workspace styles (ordinary branching, stacked branching, looms -- similar to quilts?, lightweight checkouts, ...) are supported with a corresponding increase in subcommand count and/or options. (2) New repo formats are added frequently, and taking advantage of new features often requires upgrading your repo format. So-called lightweight checkouts can be especially annoying as they involve leaving the history on the server, making distributed work problematic. (3) Bazaar is very good at supporting the kind of refactoring that involves lots of file/directory renames and/or splitting/combining. (4) Bazaar is claimed to have especially good merging support. (5) Bazaar has an idiosyncratic log format that displays branches and merges "nicely" by choosing a principal branch, and indenting subsidiary branches. This view changes depending on the repo, AIUI. Some people prefer to leave that to a separate command (a graphical DAG viewer or something like "git-show-branches"). (6) In some common use patterns (eg, "bzr log | less"), Bazaar currently does not scale. > >. It is guaranteed to scale (unless Python gets to b
Re: [Python-Dev] Optionally using GMP to implement long if available
> Martin> On Windows, the GMP binaries would be incorporated into > Martin> pythonxy.dll. This would force anybody providing a copy of > Martin> pythonxy.dll to also provide the sources of GMP. > > As I understand it the proposal was to allow people to substitute GMP for > Python's long implementation. Just deliver binaries with the Python long > version if you don't want to distribute the GMP source. Ah, as an option, it could work. > OTOH, it should be > no big deal to drop a zip archive of the GMP sources which correspond to the > code bound into the DLL. How would end users then extract the sources from the DLL? How would they learn that they even have them in the first place? Also, people would complain about the increase in size - it's 3.2MB as a zip file (1,7M as .tar.bz2). > OTOOH, doesn't Windows support dynamic linking? > Can't pythonxy.dll dynamically link to a gmpMN.dll? How would that help in not having to distribute the source? Dynamic linking still requires that the code is available at run-time. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
"Martin v. Löwis" writes: > Stephen J. Turnbull wrote: > > Thomas Wouters writes: > > > > > Neither of those (shipping sources or dynamically linking to > > > GMP) would solve the LGPL issue. People who distribute that > > > build of Python would still be held by the LGPL -- such as > > > shipping any sources that they embed that Python into. > > > > No, that's exactly what the "L" in "LGPL" means. You only have to > > ship the sources to any object module (library or program) actually > > containing GMP code, including any modifications you make to them. So > > if GMP is kept entirely in a separate library and you don't borrow any > > code from it, the rest of your code is not affected by the LGPL. > > Sure. However, when you ship pythonxy.dll to your users, and it links > with gmp.dll, you *will* have to ship gmp.dll to your users [and] > then you have to include the source (of GMP, not Python). Right. There is definitely an administrative cost here, one that Python itself doesn't impose. This may not be a big deal for some downstream projects, but that is for each project to decide. I agree, it is quite reasonable for Python to prefer to avoid the issue by allowing downstream to add GMP or not as it likes, and simplify its own maintenance burden by only providing the simple portable good- enough-for-government-work implementation. Thomas's wording strongly suggested to me that he thought that the presence of gmp.dll would force a project to include not only GMP source, but Python source *and* even my Killer-App's source. That's not true, and that's the only issue I was trying to address. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Optionally using GMP to implement long if available
Stephen J. Turnbull wrote: > Thomas Wouters writes: > > > Neither of those (shipping sources or dynamically linking to GMP) would > > solve the LGPL issue. People who distribute that build of Python would > still > > be held by the LGPL -- such as shipping any sources that they embed that > > Python into. > > No, that's exactly what the "L" in "LGPL" means. You only have to > ship the sources to any object module (library or program) actually > containing GMP code, including any modifications you make to them. So > if GMP is kept entirely in a separate library and you don't borrow any > code from it, the rest of your code is not affected by the LGPL. Sure. However, when you ship pythonxy.dll to your users, and it links with gmp.dll, you *will* have to ship gmp.dll to your users, as well - they just won't accept having to download gmp.dll from elsewhere (they may not even know what Python is). So then you have to include the source (of GMP, not Python). The L is really only about "include source just from the library (gmp), not the application (Python)". Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] XXX do we need a new policy?
> I see that Guido is not keen on the idea, and I'm not sure my > observations help sway things one way or the other. OTOH, it would be > nice if at least we always add our own identifier (initials, nick, email > address) and a date to the XXX so we at least know who was talking about > what. I find it fairly easy to use "svn annotate" to learn about the source of an XXX comment. In many cases, the XXX comment is fairly obvious, anyway, so knowing who added it, and when, doesn't provide much useful information. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
