Am 22.03.2011 03:43, schrieb Stephen J. Turnbull:
> "Martin v. Löwis" writes:
>
> > Not if the changes you want to suppress are actually also on the same
> > branch as the one whose mainline you are trying to see (which they
> > typically are, with the branch typically being "default").
>
> Th
Am 22.03.2011 02:02, schrieb Eugene Toder:
>> Not if the changes you want to suppress are actually also on the same
>> branch as the one whose mainline you are trying to see (which they
>> typically are, with the branch typically being "default").
>
> Right, that would amount to not using named bra
"Martin v. Löwis", 21.03.2011 23:44:
Am 21.03.2011 11:58, schrieb Stefan Behnel:
Guido van Rossum, 21.03.2011 03:46:
Thanks for the clarifications. I now have a much better understanding
of what Cython is. But I'm not sold. For one, your attitude about
strict language compatibility worries me w
Greg Ewing writes:
> There should be a hierarchy of changesets, so you can look at the top
> level and get the big picture, while being able to drill down into the
> details when you need to.
Yes, that's exactly what Bazaar does. Perhaps the Python team can make a
big request to Mercurial to imp
On 2011-03-22, Steven D'Aprano wrote:
> Tim Delaney wrote:
>
>> You'd end up using more horizontal space, but we all seem to have
>> widescreen monitors these days.
>
> Not even close to "we all".
Fair enough - that was a fairly stupid statement on my part. Blame it
on being on dial-up (26kbps!)
Ben Finney writes:
> As a user of Bazaar primarily, that's addressing the problem in the
> wrong place: why rewrite *my* history, which is useful to me as is, when
> the other person is using Bazaar and so doesn't see revisions they don't
> care about?
Speaking for myself, I rewrite my git hi
On Mar 21, 2011, at 10:10 PM, Senthil Kumaran wrote:
> Doug Hellmann wrote:
>> We are nearly ready to launch the new blog for python-dev.
>
> Cool. But I always thought planet.python.org was a kind of blog for
> python-dev. How will python-dev blog be different? Will add additional
> redundancy
On Mon, Mar 21, 2011 at 10:10 PM, Senthil Kumaran wrote:
> Doug Hellmann wrote:
>> We are nearly ready to launch the new blog for python-dev.
>
> Cool. But I always thought planet.python.org was a kind of blog for
> python-dev. How will python-dev blog be different? Will add additional
> redundanc
"Martin v. Löwis" writes:
> Not if the changes you want to suppress are actually also on the same
> branch as the one whose mainline you are trying to see (which they
> typically are, with the branch typically being "default").
There is no "also on" with Mercurial named branches. Every commit
On Tue, Mar 22, 2011 at 3:10 PM, Senthil Kumaran wrote:
> Doug Hellmann wrote:
>> We are nearly ready to launch the new blog for python-dev.
>
> Cool. But I always thought planet.python.org was a kind of blog for
> python-dev. How will python-dev blog be different? Will add additional
> redundancy
On Mon, Mar 21, 2011 at 09:06:22PM -0400, David Malcolm wrote:
>
> Other ideas that occur:
> - does rpmlint check for encoding yet?
> - what to do e.g. about canonicalization? What happens if one rpm
> provide a feature named "café" (where the "é" is U+00E9) and another rpm
> requires a featu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Senthil,
On 03/21/2011 09:57 PM, Senthil Kumaran wrote:
> - In the above issue, why is two same bitbutket urls are provided. (It
> is redundant).
I updated the patch, and the second time around the "remote hg repo" box
was empty. I wasn't sure wha
Doug Hellmann wrote:
> We are nearly ready to launch the new blog for python-dev.
Cool. But I always thought planet.python.org was a kind of blog for
python-dev. How will python-dev blog be different? Will add additional
redundancy to my RSS reader which gets planet posts as well as
individual po
On Tue, Mar 22, 2011 at 9:02 AM, Guido van Rossum wrote:
> On Mon, Mar 21, 2011 at 5:10 PM, Éric Araujo wrote:
>> Le 13/03/2011 19:03, "Martin v. Löwis" a écrit :
>>> I've added a feature in the bug tracker where submitters can post
>>> Mercurial repository URLs, and then repeatedly create patche
We are nearly ready to launch the new blog for python-dev. If you have a
personal blog where you talk about your Python work, we would like to include a
link in the sidebar as part of our blog-roll. Send me the URL (off-list) and
I'll make sure you are included.
Doug
__
[CCing Panu Matilainen, the maintainer of rpm, or, at least rpm 4.*,
which is what all major distributions are using AIUI]
On Mon, 2011-03-21 at 10:50 +0100, "Martin v. Löwis" wrote:
> Am 21.03.2011 07:37, schrieb Prashant Kumar:
> > Hello,
> > My name is Prashant Kumar and I've worked on por
R. David Murray writes:
> The workflow in svn "can" "require" this same thing: before committing,
> you do an svn up and run the test suite.
No, it can't. That's not good enough, if you care about tree-wide
consistency, because svn's approach has a race condition. You say you
don't care, but
On 3/21/2011 7:14 AM, Nick Coghlan wrote:
hg broadens the check and complains if *any* files are not up to date
on any of the branches being pushed, thus making it a requirement to
do a hg pull and merge on all affected branches before the hg push can
succeed. In theory, this provides an opportu
On Mon, Mar 21, 2011 at 5:10 PM, Éric Araujo wrote:
> Le 13/03/2011 19:03, "Martin v. Löwis" a écrit :
>> I've added a feature in the bug tracker where submitters can post
>> Mercurial repository URLs, and then repeatedly create patches. Roundup
>> will extract the current patch (cpython-default:s
> Not if the changes you want to suppress are actually also on the same
> branch as the one whose mainline you are trying to see (which they
> typically are, with the branch typically being "default").
Right, that would amount to not using named branches. But if you
develop on a named feature-bran
> But now that I think about it, I guess it's a lot easier to miss a place
> like PyArg_Parse*() when manually migrating code. The conversion of the
> type string is really not obvious and the C compiler can't provide any
> help.
I actually have a GCC extension allowing the compiler to detect typ
Am 22.03.2011 01:08, schrieb Eugene Toder:
>> Bazaar apparently has a notion of mainline whereas Mercurial believes
>> that all changesets are created equal. The tools are different.
>
> Mercurial has named branches. When viewing history you can restrict it
> to just one named branch, which, I th
Eugene Toder wrote:
Mercurial has named branches. When viewing history you can restrict it
to just one named branch, which, I think, will have an effect similar
to "mainline".
So with Hg, could you get the same effect by pushing your
local changes into a temporary named branch, and then
mergin
Le 13/03/2011 19:03, "Martin v. Löwis" a écrit :
> I've added a feature in the bug tracker where submitters can post
> Mercurial repository URLs, and then repeatedly create patches. Roundup
> will extract the current patch (cpython-default:submitter-default),
> and attach the patch to the issue (
> Bazaar apparently has a notion of mainline whereas Mercurial believes
> that all changesets are created equal. The tools are different.
Mercurial has named branches. When viewing history you can restrict it
to just one named branch, which, I think, will have an effect similar
to "mainline".
Eu
Le 22/03/2011 00:46, Greg Ewing a écrit :
> Ben Finney wrote:
>> That seems to me the ideal: preserve all revision history for those
>> cases when some user will care about it, but *present* history cleanly
>> by default.
>
> Seems to me the basic problem here is the way Mercurial
> presents you w
Ben Finney wrote:
That seems to me the ideal: preserve all revision history for those
cases when some user will care about it, but *present* history cleanly
by default.
Seems to me the basic problem here is the way Mercurial
presents you with a big pile of changesets and not much
way of imposi
On Mon, Mar 21, 2011 at 4:06 PM, rndblnch wrote:
> Greg Ewing canterbury.ac.nz> writes:
>> Guido van Rossum wrote:
>> > Ok. Will you hvae time to port your patches to 3.3?
>> I'm not sure -- I'll see what I can do.
>
> If this can help, I have written a script that transforms greg's patch into a
On Mon, 21 Mar 2011 17:06:09 -0600
Maciej Fijalkowski wrote:
>
> Indeed, sorry, I didn't follow too closely. It's worth considering
> what would be the obvious next goal. This repo changed (and I believe
> you're the main person according to the change log) to provide python
> 3 support. On the o
Greg Ewing canterbury.ac.nz> writes:
> Guido van Rossum wrote:
> > Ok. Will you hvae time to port your patches to 3.3?
> I'm not sure -- I'll see what I can do.
If this can help, I have written a script that transforms greg's patch into a
patch that applies on cpython current tip.
The script is a
On Mon, Mar 21, 2011 at 4:27 PM, Antoine Pitrou wrote:
> Le lundi 21 mars 2011 à 16:21 -0600, Maciej Fijalkowski a écrit :
>> The original idea was to converge and have the
>> common repo on hg.python.org, but since unladen run out of steam,
>> nobody bothered to update the hg.python.org one so we
On Mon, Mar 21, 2011 at 3:44 PM, "Martin v. Löwis" wrote:
> Am 21.03.2011 11:58, schrieb Stefan Behnel:
>> [long post ahead, again]
>>
>> Guido van Rossum, 21.03.2011 03:46:
>>> Thanks for the clarifications. I now have a much better understanding
>>> of what Cython is. But I'm not sold. For one,
On Mon, 21 Mar 2011 23:35:30 +0100
"Martin v. Löwis" wrote:
>
> Having to be nitpicking here "not how you (Antoine) want us to work".
> "We" aren't using mercurial long enough to make such a statement.
Well, being directive and giving strong workflow indications seems to
be what many people are
> Well, it's "should", not "must" ;)
> When writing this, I had in mind that other projects have different
> workflows, where indeed people never collapse and many tiny changesets
> (which are only significant as part of a bigger work) end up in the main
> history. The point is to signal that it's
Tim Delaney wrote:
You'd end up using more horizontal space, but we all seem to have
widescreen monitors these days.
Not even close to "we all".
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
Am 21.03.2011 11:58, schrieb Stefan Behnel:
> [long post ahead, again]
>
> Guido van Rossum, 21.03.2011 03:46:
>> Thanks for the clarifications. I now have a much better understanding
>> of what Cython is. But I'm not sold. For one, your attitude about
>> strict language compatibility worries me w
> Would you say it's worth a GSoC project to get some of the Python stdlib
> modules compiled and/or some of the C modules rewritten in Cython?
I'm almost as excited as Michael: *if* you can get upfront agreement of
some distribution creator to integrate the code, then it's a great
project. Alter
>> 3. Several benchmarks (at least the Django and Twisted ones) have
>> dependencies which are not (yet) ported to 3.x and porting those
>> dependencies during GSoC as part of this project is an unrealistic
>> goal. Should those benchmarks, at least for now, be ignored?
>>
>
> IMHO: Yes. I think M
On Tue, Mar 22, 2011 at 6:01 AM, r.david.murray
wrote:
> http://hg.python.org/cpython/rev/7d5d859c959e
> changeset: 68817:7d5d859c959e
> user: R David Murray
> date: Mon Mar 21 16:01:23 2011 -0400
> summary:
> Prepare for move of email tests.
>
> files:
> .hgeol
>
> diff --git a
Le lundi 21 mars 2011 à 16:21 -0600, Maciej Fijalkowski a écrit :
> The original idea was to converge and have the
> common repo on hg.python.org, but since unladen run out of steam,
> nobody bothered to update the hg.python.org one so we continued on our
> own.
I'm not sure who is "nobody" in tha
On 22/03/2011 12:04 AM, Paul Moore wrote:
I haven't had time to read the PEP yet, so my apologies if this is
made explicit there, but is the launcher expected to be solely for
implementing file associations? I thought there had been discussions
of using it to start the interactive interpreter, an
On Mon, Mar 21, 2011 at 2:24 PM, DasIch wrote:
> On Mon, Mar 21, 2011 at 7:48 PM, Antoine Pitrou wrote:
>> On Mon, 21 Mar 2011 19:33:55 +0100
>> DasIch wrote:
>>>
>>> 3. Several benchmarks (at least the Django and Twisted ones) have
>>> dependencies which are not (yet) ported to 3.x and porting
> One of the key elements here is the way we use python-checkins for
> after-the-fact review.
I think this can be achieved with a better email hook. I would propose
that there will be one email message per push per branch (rather than
one per changeset). For each branch, it should report what chan
> However, what some of us requesting is that the "SHOULD collapse"
> in the devguide is changed to a "MAY collapse", making it strictly
> an option of the committer. If there is one substantial change,
> a typo change, and three merges, asking for a collapse of the typo
> change is IMO complicati
> I know I would be sorely tempted to use hg export + hg import (and
> extensive testing after the latter of course) so that the approved
> changes can land with a single thud in the core repo. But maybe I'm a
> dinosaur?
I certainly agree that there are cases where collapsing changes is
desirable
On Mon, Mar 21, 2011 at 2:20 PM, M.-A. Lemburg wrote:
> Nadeem Vawda wrote:
>> [snip]
>
> Since you'll be adding new IP to Python, the new code you write should
> contain your copyright and the standard PSF contributor agreement
> notice, e.g.
>
> """
> (c) Copyright 2011 by Nadeem Vawda. Licensed
On Mon, Mar 21, 2011 at 3:00 PM, Nick Coghlan wrote:
> On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum wrote:
>> Let's say I'm working on a fairly substantial feature that may take
>> weeks to complete. My way of working is to explore different
>> approaches until I'm happy. I like to make chec
> I don't think that is the main source of complexity.
>
> The more difficult and fragile part of the workflows are:
> * requiring commits to be cross-linked between branches
> * and wanting changesets to be collapsed or rebased
> (two operations that destroy and rewrite history).
I think there
On Tue, Mar 22, 2011 at 7:51 AM, Guido van Rossum wrote:
> Let's say I'm working on a fairly substantial feature that may take
> weeks to complete. My way of working is to explore different
> approaches until I'm happy. I like to make checkpoints while I'm
> exploring so that I can easily backtrac
On Mon, 21 Mar 2011 22:47:19 +0100
"Martin v. Löwis" wrote:
> > ISTM, there has been substantial mission creep from
> > the workflow described in the PEP. If the current workflow
> > had been described there, I don't think it would have been
> > readily accepted.
>
> I don't think PEP 385 actua
On Tue, 22 Mar 2011 07:32:33 +1000
Nick Coghlan wrote:
>
> As far as the second point goes, I'm coming to the view that we should
> avoid rebase/strip/rollback when intending to push to the main
> repository, and do long term work in *separate* cloned repositories.
> Then an rdiff with the releva
On Tue, Mar 22, 2011 at 7:25 AM, Barry Warsaw wrote:
> On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
>
>>I'd rather take a look at the final aggregate patch to see if it looks
>>correct, actually. It's easy to have incremental changes which look
>>good but lead to a questionable patch in the
On Mon, Mar 21, 2011 at 2:31 PM, Antoine Pitrou wrote:
> On Mon, 21 Mar 2011 17:25:05 -0400
> Barry Warsaw wrote:
>> On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
>>
>> >I'd rather take a look at the final aggregate patch to see if it looks
>> >correct, actually. It's easy to have increment
> It does so at the *tree* level, not at an individual file level.
Thanks - I stand corrected. I was thinking about the file level only (at
which it doesn't do server-side merging - right?).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.
> ISTM, there has been substantial mission creep from
> the workflow described in the PEP. If the current workflow
> had been described there, I don't think it would have been
> readily accepted.
I don't think PEP 385 actually *was* accepted at all (PEP 374
was, selecting Mercurial). I had meant
On Tue, Mar 22, 2011 at 3:16 AM, Raymond Hettinger
wrote:
> I don't think that is the main source of complexity.
> The more difficult and fragile part of the workflows are:
> * requiring commits to be cross-linked between branches
> * and wanting changesets to be collapsed or rebased
> (two oper
On Mon, 21 Mar 2011 17:25:05 -0400
Barry Warsaw wrote:
> On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
>
> >I'd rather take a look at the final aggregate patch to see if it looks
> >correct, actually. It's easy to have incremental changes which look
> >good but lead to a questionable patch
On Mar 21, 2011, at 09:53 PM, Antoine Pitrou wrote:
>I'd rather take a look at the final aggregate patch to see if it looks
>correct, actually. It's easy to have incremental changes which look
>good but lead to a questionable patch in the end. Better to review it
>in aggregate, IMO.
I think it wo
On 2011-03-22, Ben Finney wrote:
> That seems to me the ideal: preserve all revision history for those
> cases when some user will care about it, but *present* history cleanly
> by default.
>
> Whether adding support in Mercurial or Git for similar
> clean-presentation-by-default would obviate th
2011/3/21 Raymond Hettinger :
>
> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>
> People love it because it's a very powerful tool. People hate it because it
> allows you to shoot yourself in the foot.
>
> There's a certain irony in this. The original motivation for version
> control
>
On Mar 19, 2011, at 01:51 PM, Antoine Pitrou wrote:
>On Fri, 18 Mar 2011 20:12:19 -0700
>Toshio Kuratomi wrote:
>> There is a section in PEP8 about __version__ but it serves a slightly
>> different purpose there:
>>
>> """
>> Version Bookkeeping
>>
>> If you have to have Subversion, CVS, or
On Mar 18, 2011, at 07:40 PM, Guido van Rossum wrote:
>On Fri, Mar 18, 2011 at 7:28 PM, Greg Ewing
>wrote:
>> Tres Seaver wrote:
>>
>>> I'm not even sure why you would want __version__ in 99% of modules: in
>>> the ordinary cases, a module's version should be either the Python
>>> version (for
On Mon, 21 Mar 2011 16:33:31 -0400
Barry Warsaw wrote:
> Each of those would be
> represented by a changeset in my local line of development, and by a side
> branch in the mainline DAG once my merge is completed. You might want to dig
> into that sideline to see if indeed I addressed the issues i
Victor Stinner writes:
> Le lundi 14 mars 2011 à 15:36 -0400, David Bolen a écrit :
>>
>> Speaking of bbreport, I sometimes use the published page on that site
>> (http://code.google.com/p/bbreport/wiki/PythonBuildbotReport) to check
>> over things, but looking at it today, it seems to most recen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/21/2011 04:33 PM, Barry Warsaw wrote:
> On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
>
>> On Mon, 21 Mar 2011 14:29:54 -0400
>> Barry Warsaw wrote:
I don't think many hg users advocate rebase, really. AFAICT the
Mercurial
On Mar 21, 2011, at 07:38 PM, Antoine Pitrou wrote:
>On Mon, 21 Mar 2011 14:29:54 -0400
>Barry Warsaw wrote:
>> >
>> >I don't think many hg users advocate rebase, really. AFAICT the
>> >Mercurial developers themselves don't seem to use it (they do use mq,
>> >OTOH).
>>
>> I guess that begs the q
On Mon, Mar 21, 2011 at 7:48 PM, Antoine Pitrou wrote:
> On Mon, 21 Mar 2011 19:33:55 +0100
> DasIch wrote:
>>
>> 3. Several benchmarks (at least the Django and Twisted ones) have
>> dependencies which are not (yet) ported to 3.x and porting those
>> dependencies during GSoC as part of this proje
On Mar 22, 2011, at 06:57 AM, Ben Finney wrote:
>Barry Warsaw writes:
>
>> There's something I don't understand about rebase. It seems like most
>> git and hg users I hear from advocate rebase, while (ISTM) few Bazaar
>> users do.
>>
>> I'd like to understand whether that's a cultural thing or wh
On Mar 21, 2011, at 08:58 PM, Georg Brandl wrote:
>On 21.03.2011 20:09, s...@pobox.com wrote:
>>
>> Daniel> If every developer's intermediate commits make it into the main
>> Daniel> repository, it's hard to go back to an older revision to test
>> Daniel> something, because many of th
On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>Keeping the repository clean makes it easier to use a bisection search to
>hunt down the introduction of a bug. If every developer's intermediate
>commits make it into the main repository, it's hard to go back to an older
>revision to test s
On 21.03.2011 20:09, s...@pobox.com wrote:
>
> Daniel> If every developer's intermediate commits make it into the main
> Daniel> repository, it's hard to go back to an older revision to test
> Daniel> something, because many of the older revisions will be broken in
> Daniel> some w
Barry Warsaw writes:
> There's something I don't understand about rebase. It seems like most
> git and hg users I hear from advocate rebase, while (ISTM) few Bazaar
> users do.
>
> I'd like to understand whether that's a cultural thing or whether it's
> a byproduct of some aspect of the respectiv
On 21.03.2011 20:40, Raymond Hettinger wrote:
>
> On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>>
>>
>> People love it because it's a very powerful tool. People hate it because it
>> allows you to shoot yourself in the foot.
>
> There's a certain irony in this. The original motivation
On Mon, 21 Mar 2011 12:40:08 -0700
Raymond Hettinger wrote:
>
> Now we seem to be advocating a complex, fragile workflow that
> is hard to learn, hard to get right, that let's you shoot yourself in
> the foot, and that has rebasing/collapsing steps that destroy and
> rewrite history (an possibl
On Mar 21, 2011, at 11:56 AM, Daniel Stutzbach wrote:
>
> People love it because it's a very powerful tool. People hate it because it
> allows you to shoot yourself in the foot.
There's a certain irony in this. The original motivation for version control
was to be a safety rope, to serve as
On Mon, 21 Mar 2011 14:30:45 -0500
s...@pobox.com wrote:
>
> >> Is there any value in them as regression tests (maybe with more
> >> elaborate inputs and/or longer runtimes)?
>
> Antoine> You mean to check behaviour or to check for performance
> Antoine> regressions?
>
> Both. S
>> Is there any value in them as regression tests (maybe with more
>> elaborate inputs and/or longer runtimes)?
Antoine> You mean to check behaviour or to check for performance
Antoine> regressions?
Both. Semantic regressions, and secondarily, performance regressions.
I can unde
Le lundi 21 mars 2011 à 14:06 -0500, s...@pobox.com a écrit :
> Antoine> Why not reuse the benchmarks in
> Antoine> http://hg.python.org/benchmarks/ ?
>
> These looks like basically the same benchmarks as the Unladen Swallow folks
> put together, right?
Yes, it's basically the continuation of
Daniel> If every developer's intermediate commits make it into the main
Daniel> repository, it's hard to go back to an older revision to test
Daniel> something, because many of the older revisions will be broken in
Daniel> some way.
This is what I discovered with my trivial doc pa
Antoine> Why not reuse the benchmarks in
Antoine> http://hg.python.org/benchmarks/ ?
These looks like basically the same benchmarks as the Unladen Swallow folks
put together, right? Is there any value in them as regression tests (maybe
with more elaborate inputs and/or longer runtimes)?
Le lundi 21 mars 2011 à 14:51 -0400, Jesse Noller a écrit :
> On Mon, Mar 21, 2011 at 2:48 PM, Antoine Pitrou wrote:
> > On Mon, 21 Mar 2011 19:33:55 +0100
> > DasIch wrote:
> >>
> >> 3. Several benchmarks (at least the Django and Twisted ones) have
> >> dependencies which are not (yet) ported to
On Sun, Mar 20, 2011 at 9:39 AM, Georg Brandl wrote:
> Now, "hg pull --rebase" prevents that by "re-basing" the A-B history
> line onto the latest remote head. After rebasing, the history looks
> like this:
>
> ... --- X --- C --- D --- E --- A' --- B'
>
Rebasing also allows you to collapse the
Le lundi 21 mars 2011 à 11:33 -0700, Daniel Stutzbach a écrit :
> On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou
> wrote:
> We cannot emulate "svnmerge" for porting between branches,
> though - and
> I doubt bzr can do it. That's because merges in common DVCSes
> a
On Mon, Mar 21, 2011 at 2:48 PM, Antoine Pitrou wrote:
> On Mon, 21 Mar 2011 19:33:55 +0100
> DasIch wrote:
>>
>> 3. Several benchmarks (at least the Django and Twisted ones) have
>> dependencies which are not (yet) ported to 3.x and porting those
>> dependencies during GSoC as part of this proje
Some remarks below.
On Mon, Mar 21, 2011 at 2:33 PM, DasIch wrote:
> Hello Guys,
> I'm interested in participating in the Google Summer of Code this year
> and I've been looking at projects in the Wiki, particularly
> speed.pypy.org[1] as I'm very interested in the current VM
> development. Howev
On Mon, 21 Mar 2011 19:33:55 +0100
DasIch wrote:
>
> 3. Several benchmarks (at least the Django and Twisted ones) have
> dependencies which are not (yet) ported to 3.x and porting those
> dependencies during GSoC as part of this project is an unrealistic
> goal. Should those benchmarks, at least
On Mon, Mar 21, 2011 at 12:33 PM, DasIch wrote:
> Hello Guys,
> I'm interested in participating in the Google Summer of Code this year
> and I've been looking at projects in the Wiki, particularly
> speed.pypy.org[1] as I'm very interested in the current VM
> development. However given my knowledg
On Mon, 21 Mar 2011 14:29:54 -0400
Barry Warsaw wrote:
> >
> >I don't think many hg users advocate rebase, really. AFAICT the
> >Mercurial developers themselves don't seem to use it (they do use mq,
> >OTOH).
>
> I guess that begs the question then. ;)
>
> What harm would there be in relaxing
Hello Guys,
I'm interested in participating in the Google Summer of Code this year
and I've been looking at projects in the Wiki, particularly
speed.pypy.org[1] as I'm very interested in the current VM
development. However given my knowledge that project raised several
questions:
1. Up until now t
On Mon, Mar 21, 2011 at 8:38 AM, Antoine Pitrou wrote:
> We cannot emulate "svnmerge" for porting between branches, though - and
> I doubt bzr can do it. That's because merges in common DVCSes are based
> on the DAG, while svnmerge is a prettily ad-hoc free-form thing.
The equivalent way to how
On Mar 21, 2011, at 06:07 PM, Antoine Pitrou wrote:
>On Mon, 21 Mar 2011 12:20:15 -0400
>Barry Warsaw wrote:
>> On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
>>
>> >On 20.03.2011 16:21, Guido van Rossum wrote:
>> >> What is "rebase"? Why does everyone want it and hate it at the same time?
>>
[skipping the whole long discussion]
>
> Cython is meant to compile Python code. A "cython version" would just be a
> pure Python module, usable with all other implementations, but with type
> annotations that make it compile to more optimal C code. Type annotations
> can be provided in an externa
On 21/03/2011 17:47, Stefan Behnel wrote:
Stefan Behnel, 21.03.2011 11:58:
Guido van Rossum, 21.03.2011 03:46:
Have you tried replacing selected stdlib modules with their
Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
what about Enthought's Python distros?) Depending on
On Mar 21, 2011, at 01:19 PM, R. David Murray wrote:
>So you are worried about the small window between me doing an 'svn up',
>seeing no changes, and doing an 'svn ci'? I suppose that is a legitimate
>concern, but considering the fact that if the same thing happens in hg,
>the only difference is
Stefan Behnel, 21.03.2011 11:58:
Guido van Rossum, 21.03.2011 03:46:
Have you tried replacing selected stdlib modules with their
Cython-optimized equivalents in some of the NumPy/SciPy distros? (E.g.
what about Enthought's Python distros?) Depending on how well that
goes I might warm up to Cytho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/21/2011 10:55 AM, Stephen J. Turnbull wrote:
> s...@pobox.com writes:
>
> > I believe it runs counter to the professed intention of the switch
> > away from a centralized version control system, to make it easier
> > for more people to contri
On Mon, 21 Mar 2011 15:59:51 +0100, Adrian Buehlmann wrote:
> On 2011-03-21 14:40, R. David Murray wrote:
> > On Mon, 21 Mar 2011 18:33:00 +0900, "Stephen J. Turnbull"
> > wrote:
> >> R. David Murray writes:
> >> > On Mon, 21 Mar 2011 14:07:46 +0900, "Stephen J. Turnbull"
> >> wrote:
> >> >
On Mar 21, 2011, at 8:25 AM, Barry Warsaw wrote:
>
> Does Mercurial have a way of acting like a centralized vcs to the end user,
> the way Bazaar does? IOW, if Skip or others were more comfortable with a
> centralized workflow (which is entirely valid imo), can they set up their
> local workspac
On Mon, 21 Mar 2011 12:20:15 -0400
Barry Warsaw wrote:
> On Mar 20, 2011, at 04:39 PM, Georg Brandl wrote:
>
> >On 20.03.2011 16:21, Guido van Rossum wrote:
> >> What is "rebase"? Why does everyone want it and hate it at the same time?
> >
> >Basically, rebase is a way to avoid having pointless m
On 21 March 2011 16:20, Barry Warsaw wrote:
> It could be that some aspect of the tools causes A and B to not be hidden as
> well as they should, so that when looking at the history for example, the fact
> that A and B exist is a jarring or annoying artifact that would be better if
> they didn't e
1 - 100 of 140 matches
Mail list logo
