Re: [Python-Dev] Rethinking intern() and its data structure
On Friday, 10 April 2009 at 15:05, P.J. Eby wrote: > At 06:52 PM 4/10/2009 +1000, Nick Coghlan wrote: >> This problem (slow application startup times due to too many imports at >> startup, which can in turn can be due to top level imports for library >> or framework functionality that a given application doesn't actually >> use) is actually the main reason I sometimes wish for a nice, solid lazy >> module import mechanism that manages to avoid the potential deadlock >> problems created by using import statements inside functions. I'd love to see that too. I imagine it would be beneficial for many python applications. > Have you tried http://pypi.python.org/pypi/Importing ? Or more > specifically, > http://peak.telecommunity.com/DevCenter/Importing#lazy-imports ? Here's what we do in Mercurial, which is a little more user-friendly, but possibly too magical for general use (but provides us a very nice speedup): http://www.selenic.com/repo/index.cgi/hg/file/tip/mercurial/demandimport.py#l1 It's nice and small, and it is invisible to the rest of the code, but it's probably too aggressive for all users. The biggest problem is probably that ImportErrors are deferred until first access, which trips up modules that do things like try: import foo except ImportError import fallback as foo of which there are a few. The mercurial module maintains a blacklist as a bandaid, but it'd be great to have a real fix. ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On Sunday, 06 February 2011 at 12:13, Brett Cannon wrote: > On Sun, Feb 6, 2011 at 08:15, Antoine Pitrou wrote: > > On Sun, 06 Feb 2011 02:10:15 +0100 > > brett.cannon wrote: > >> > >> To create your patch, you should generate a unified diff from your > >> checkout's > >> top-level directory:: > >> > >> - svn diff > patch.diff > >> + hg outgoing --path > patch.diff > > > > Should be --patch. > > The problem is that it will show one several patch per changeset, which > > is normally not what you want (it's a pity "hg out" doesn't have an > > option to collapse them all). > > Yeah, that is a perk of mq. > > > > >> If your work needs some new files to be added to the source tree, remember > >> -to ``svn add`` them before generating the patch:: > >> +to ``hg add`` them before generating the patch:: > >> > >> - svn add Lib/newfile.py > >> - svn diff > patch.diff > >> + hg add Lib/newfile.py > >> + hg outgoing --patch > patch.diff > > > > You should commit before using "outgoing", otherwise the added file is > > not in the repo (and therefore not in the patch). > > > > The problem with hg (and other DVCSes) is that allows for *several* > > local workflows, and therefore it's harder to advocate one of them in > > such tutorial docs. I wonder what Georg and Dirkjan suggest. I just happened to see this message and don't really know the context -- you may not want to use any extensions here. But my 'rdiff' extension does let you create diffs between your working directory and upstream, and collapses your changesets into a single diff. http://mercurial.selenic.com/wiki/RdiffExtension ___ 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] devguide: Basic instructions on how to generate a patch with hg for non-committers.
On Monday, 07 February 2011 at 15:46, Antoine Pitrou wrote: > On Mon, 07 Feb 2011 14:34:35 + > Michael Foord wrote: > > >>> > > >> And from the description it sounds like rdiff will be very useful for > > >> our usecase. > > > I'm not sure it is really. When you commit multiple changesets > > > locally you really want to use something like named branches or mq to > > > track them. Advocating rdiff is advocating something SVN-like, it's not > > > very helpful IMO. > > > > > > > Although often you want to merge in a single commit and erase the commit > > history of the branch you worked in (as discussed previously). > > Yes, but apparently rdiff compares the *working copy* rather than the > local repository. Also, AFAIU rdiff will compare against the tip of the Rdiff is meant to make diff work against remote repositories the way it already does on local ones. So it *can* produce a diff between the working directory and a remote revision, just as regular diff can do for a local revision. But it can also produce diffs between any local revision and any remote revision. > remote, which is probably not what you based your work on. And if you If you're talking about named branches, I think I agree (rdiff predates a lot of the work done in hg to support named branches). I assume you think the right target is the most recent remote revision on the named branch you're working against? (rdiff does accept symbolic names for remote revisions, including branch names) > have to specify revisions by hand, it kind of defeats the point (you > want hg to track changes by itself, which is why you want to use one > of named branches / bookmarks / mq / etc.). rdiff is somewhat orthogonal to bookmarks/mq/etc. It's really just a convenient wrapper for outgoing. ___ 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] combined hg incoming patch
On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote: > I'd like to experiment with adding Rietveld support for reviewing > remote repositories. For that, I'd need to create a single patch > (programmatically) that covers all incoming changes. 'hg incoming -p' > mostly works, but it may provide multiple patches for a single file, > which I think would harm the review (since some changes may be superseded in > a separate patch). > > So I would need to compute the most recent revision in both repositories, and > then create a diff between the default head > of the remote repository and that base revision. You might like the rdiff extension, which does essentially this. http://mercurial.selenic.com/wiki/RdiffExtension ___ 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] combined hg incoming patch
On 2011-03-07, at 2:18 PM, Martin v. Löwis wrote: > Am 07.03.2011 23:09, schrieb Brendan Cully: >> On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote: >> >>> I'd like to experiment with adding Rietveld support for reviewing >>> remote repositories. For that, I'd need to create a single patch >>> (programmatically) that covers all incoming changes. 'hg incoming -p' >>> mostly works, but it may provide multiple patches for a single file, >>> which I think would harm the review (since some changes may be superseded >>> in a separate patch). >>> >>> So I would need to compute the most recent revision in both repositories, >>> and then create a diff between the default head >>> of the remote repository and that base revision. >> >> You might like the rdiff extension, which does essentially this. >> >> http://mercurial.selenic.com/wiki/RdiffExtension > > I've looked at it, and it does something different. It computes the diff > between the local tip and the remote tip. What I want is a diff between the > common ancestor between the two, and the remote tip. Ah right. Well, I think this shell should work (with hg new enough to have revsets): hg in --bundle tmp.bundle hg diff -r 'outgoing(.)' -R tmp.bundle ___ 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] combined hg incoming patch
On 2011-03-07, at 2:30 PM, Brendan Cully wrote: > On 2011-03-07, at 2:18 PM, Martin v. Löwis wrote: > >> Am 07.03.2011 23:09, schrieb Brendan Cully: >>> On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote: >>> >>>> I'd like to experiment with adding Rietveld support for reviewing >>>> remote repositories. For that, I'd need to create a single patch >>>> (programmatically) that covers all incoming changes. 'hg incoming -p' >>>> mostly works, but it may provide multiple patches for a single file, >>>> which I think would harm the review (since some changes may be superseded >>>> in a separate patch). >>>> >>>> So I would need to compute the most recent revision in both repositories, >>>> and then create a diff between the default head >>>> of the remote repository and that base revision. >>> >>> You might like the rdiff extension, which does essentially this. >>> >>> http://mercurial.selenic.com/wiki/RdiffExtension >> >> I've looked at it, and it does something different. It computes the diff >> between the local tip and the remote tip. What I want is a diff between the >> common ancestor between the two, and the remote tip. > > Ah right. Well, I think this shell should work (with hg new enough to have > revsets): > > hg in --bundle tmp.bundle > hg diff -r 'outgoing(.)' -R tmp.bundle Sorry, I didn't think that through. Revsets still have the power though: hg -R tmp.bundle diff -r'ancestor(.,default)' -r default (assuming your local repo is at the tip of default) ___ 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] combined hg incoming patch
On 2011-03-08, at 1:03 AM, Martin v. Löwis wrote: >> Sorry, I didn't think that through. Revsets still have the power though: >> >> hg -R tmp.bundle diff -r'ancestor(.,default)' -r default >> >> (assuming your local repo is at the tip of default) > > I can't make this work. I'm using hg 1.6.4, which does have revsets and > (including ancestor). Still, with this command, I get > > martin@mira:~/work/3k$ LANG=C hg -R tmp.bundle diff -r'ancestor(.,default)' > -r default > abort: unknown revision 'ancestor(.,default)'! It looks like that was fixed a week after 1.6.4 was released, here: http://hg.intevation.org/mercurial/crew/rev/2063d36b406e It should work in 1.7. ___ 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] Impaired Usability of the Mercurial Source Viewer
On 2011-03-31, at 8:44 PM, Antoine Pitrou wrote:
> On Thu, 31 Mar 2011 18:20:53 -0700
> Raymond Hettinger wrote:
>>
>> Surely, we at least have control over our own CSS.
>> At http://hg.python.org/cpython/static/style-paper.css
>> there are two lines that control the alternating bars:
>>
>> .parity0 { background-color: #f0f0f0; }
>> .parity1 { background-color: white; }
>>
>> One of those could be changed to match the other so that we
>> at can at least get a solid background.
>
> It also applies to the changelog and therefore would make the changelog
> uglier (you had already asked me to make that change and I reverted it
> after I tried it). The changelog is, IMHO, a bit more important than the
> source viewer.
>
> Impacting only the source viewer looks like it would require a patch
> to the generation logic, although I could be mistaken.
It shouldn't. You just need to change the template. The easiest thing to do is
probably to copy the 'paper' style into a new directory, adjust your hgweb
style parameter to point to it, and edit the 'fileline' entry in the 'map' file
for your new style.
smime.p7s
Description: S/MIME cryptographic 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
