Benjamin Peterson wrote:
> 2010/2/13 Jake McGuire :
>> I have a local patch, but wanted to see if anyone had ideas or
>> experience weighing these tradeoffs.
>
> Interning is really only useful because it speeds up dictionary
> lookups for identifiers. A better idea would be to just attach the
> s
2010/2/13 Jake McGuire :
> I have a local patch, but wanted to see if anyone had ideas or
> experience weighing these tradeoffs.
Interning is really only useful because it speeds up dictionary
lookups for identifiers. A better idea would be to just attach the
same filename object in compiling and
Has anyone come up with rules of thumb for what to intern and what the
performance implications of interning are?
I'm working on profiling App Engine again, and since they don't allow
marshall I have to modify pstats to save the profile via pickle.
While trying to get profiles under 1MB, I noticed
On Sat, Feb 13, 2010 at 12:14 PM, "Martin v. Löwis" wrote:
> >> But isn't that just a theoretical property? I know that's how 2to3
> >> started, but who, other than the committers, actually accesses the 2to3
> >> repo?
> >
> > It's used in 3to2 for example.
>
> That doesn't really seem to be the c
On Feb 13, 2010, at 1:43 PM, Benjamin Peterson wrote:
> 2010/2/13 Dirkjan Ochtman :
>> On Sat, Feb 13, 2010 at 17:14, Barry Warsaw wrote:
>>> Does hg support an equivalent of 'bzr split'?
>>>
>>> % bzr split --help
>>> Purpose: Split a subdirectory of a tree into a separate tree.
>>> Usage: bz
> The other thing is that we will loose some vcs history and some
> history granularity by switching development to the trunk version,
> since just the svnmerged revisions will be converted.
I suppose it might be possible to fake the history of Lib/lib2to3 with
commits that didn't actually happen,
2010/2/13 "Martin v. Löwis" :
>>> But isn't that just a theoretical property? I know that's how 2to3
>>> started, but who, other than the committers, actually accesses the 2to3
>>> repo?
>>
>> It's used in 3to2 for example.
>
> That doesn't really seem to be the case. AFAICT, 3to2 is a hg
> reposit
2010/2/13 Dirkjan Ochtman :
> On Sat, Feb 13, 2010 at 17:14, Barry Warsaw wrote:
>> Does hg support an equivalent of 'bzr split'?
>>
>> % bzr split --help
>> Purpose: Split a subdirectory of a tree into a separate tree.
>> Usage: bzr split TREE
>>
>> Options:
>> --usage Show usage messag
On Sat, Feb 13, 2010 at 12:53, "Martin v. Löwis" wrote:
> Dirkjan: if you agree to such a strategy, please mention that in the PEP.
Having a pushlog and/or including the pusher in the email sounds like
a good idea, I'll add something to that effect to the PEP. I slightly
prefer adding it to the c
On Sat, Feb 13, 2010 at 17:14, Barry Warsaw wrote:
> Does hg support an equivalent of 'bzr split'?
>
> % bzr split --help
> Purpose: Split a subdirectory of a tree into a separate tree.
> Usage: bzr split TREE
>
> Options:
> --usage Show usage message and options.
> -v, --verbose Displ
On Fri, Feb 12, 2010 at 8:01 PM, Glyph Lefkowitz
wrote:
> On Feb 11, 2010, at 1:11 PM, Guido van Rossum wrote:
>
>> I have skimmed this thread (hence this reply to the first rather than
>> the last message), but in general I am baffled by the hostility of
>> testing framework developers towards th
>> But isn't that just a theoretical property? I know that's how 2to3
>> started, but who, other than the committers, actually accesses the 2to3
>> repo?
>
> It's used in 3to2 for example.
That doesn't really seem to be the case. AFAICT, 3to2 is a hg
repository, with no inherent connection to the
2010/2/13 "Martin v. Löwis" :
>> I personally like 2to3 in a separate repo because it fits well with my
>> view that 2to3 is an extra application that happens to also be
>> distributed with python.
>
> But isn't that just a theoretical property? I know that's how 2to3
> started, but who, other than
On Feb 13, 2010, at 1:31 AM, Martin v. Löwis wrote:
>>> On Fri, Feb 12, 2010 at 11:17, "Martin v. Löwis" wrote:
IMO, it is realistic to predict that this will not actually happen. If
we can agree to give up the 2to3 sandbox, we should incorporate
find_pattern into the tree, and per
On 13/02/2010 16:03, Rafael Villar Burke (Pachi) wrote:
There's some more content here:
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip
But I don't use it myself, just knew about its existance. Surely
Dirkjan can make all the pieces fit nicely :).
The hook code looks like it'
On 13/02/2010 15:25, "Martin v. Löwis" wrote:
Mozilla's pushlog can be seen here:
http://hg.mozilla.org/mozilla-central/pushloghtml
And its code is avaliable here:
http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip/pushlog-feed.py
Dirkjan is its author, so I suppose he was a
> Mozilla's pushlog can be seen here:
>
> http://hg.mozilla.org/mozilla-central/pushloghtml
>
> And its code is avaliable here:
> http://hg.mozilla.org/users/bsmedberg_mozilla.com/hgpoller/file/tip/pushlog-feed.py
>
> Dirkjan is its author, so I suppose he was already thinking about having a
> s
Antoine Pitrou pitrou.net> writes:
>
> Martin v. Löwis v.loewis.de> writes:
> >
> > Alterntively, the email notification sent to python-checkins could could
> > report who the pusher was.
>
> This sounds reasonable, assuming it doesn't disclose any private information.
There are already made
Martin v. Löwis v.loewis.de> writes:
>
> Alterntively, the email notification sent to python-checkins could could
> report who the pusher was.
This sounds reasonable, assuming it doesn't disclose any private information.
Regards
Antoine.
___
Python
I recently set up a Mercurial hosting solution myself, and noticed that
there is no audit trail of who had been writing to the "master" clone.
There are commit messages, but they could be fake (even misleading to a
different committer).
The threat I'm concerned about is that of a stolen SSH key. I
On Sat, 2010-02-13 at 10:42 +, Antoine Pitrou wrote:
> Robert Collins robertcollins.net> writes:
> >
> > I'm not personally very keen on inspecting everything in self.__dict__,
> > I suspect it would tickle bugs in other unittest extensions. However I'm
> > not really /against/ it - I don't t
Robert Collins robertcollins.net> writes:
>
> I'm not personally very keen on inspecting everything in self.__dict__,
> I suspect it would tickle bugs in other unittest extensions. However I'm
> not really /against/ it - I don't think it will result in bad test
> behaviour or isolation issues. So
R. David Murray wrote:
On Thu, 11 Feb 2010 12:41:37 +, Michael Foord
wrote:
On 11/02/2010 12:30, Nick Coghlan wrote:
The test framework might promise to do the following for each test:
with get_module_cm(test_instance): # However identified
with get_class_cm(test_instance): # How
On Fri, 2010-02-12 at 12:27 -0800, Guido van Rossum wrote:
> On Fri, Feb 12, 2010 at 12:20 PM, wrote:
> > The idea is that you're declaring what the tests need in order to work.
> > You're not explicitly defining the order in which things are set up and torn
> > down. That is left up to another
On Sat, 2010-02-13 at 01:04 +, Michael Foord wrote:
> > However from this example I *cannot* guess whether those resources are
> > set up and torn down per test or per test class.
> This particular example is the equivalent of setUpClass - so by
> declaring the resource as a class attribute
25 matches
Mail list logo
