> But Python tests lack coverage stats, so it is hard to say anything.
FYI: http://coverage.livinglogic.de/
Regards
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.or
On Sat, Jul 3, 2010 at 3:26 PM, Victor Stinner
wrote:
>
> In the worst case, a function rejects valid data. If I have to choose, I
> prefer to reject valid data than a security vulnerability. But audioop has
> tests and I don't think that my patch breaks anything :-)
But Python tests lack coverag
>> That tutorial is not ~100 pages. It's actually a good tutorial.
> That's why I posted it here, but it still >80 pages in my browser.
Perhaps you meant 80 screens, or a different tutorial. hginit is a short
tutorial useful for Subversion users who don’t have the time to read the
hgbook.
Regards
> 2, throwing away local changes is not that easy in Mercurial,
>if you have committed them already. There are extensions to
>uncommit, but they are discouraged and have limitations. So it's
>best to throw away everything and start over fresh, which is
>faster if you have a pristine
Am 04.07.2010 00:56, schrieb Antoine Pitrou:
> On Sun, 04 Jul 2010 00:51:58 +0200
> "Martin v. Löwis" wrote:
> I'd love to see a more detailed description of this, including why
> someone new to Mercurial would choose one over the other.
>>>
I think someone new to Mercurial shouldn't
> My question is basically the same as Terry Reedy's, but I'm going to
> phrase it a bit differently:
>
> This is perhaps a naive question, but why do you create a second local
> clone instead of just creating a branch?
IIUC, if you create a named branch, the branch will become globally
visible w
> This is perhaps a naive question, but hat do you gain with the
> intermediate mirror clone of upstream? (Other than filling more of your
> disk?)
In addition to the answer you got: this way of working is also the
process that I arrived at, independently.
I see two uses, both based around the pr
On Sun, 04 Jul 2010 00:51:58 +0200
"Martin v. Löwis" wrote:
> >>> I'd love to see a more detailed description of this, including why
> >>> someone new to Mercurial would choose one over the other.
> >
> >> I think someone new to Mercurial shouldn't choose either one.
> >
> >> Just sit back and w
>>> I'd love to see a more detailed description of this, including why
>>> someone new to Mercurial would choose one over the other.
>
>> I think someone new to Mercurial shouldn't choose either one.
>
>> Just sit back and wait for the real migration to happen.
>
> I would say that using the SVN
Am 03.07.2010 16:34, schrieb Christian Heimes:
> Am 03.07.2010 09:00, schrieb "Martin v. Löwis":
>>> I'm trying to test out a patch to add a timeout in subprocess.py on
>>> Windows, so I need to build Python with Visual Studio. The docs say
>>> the files in PCBuild/ work with VC 9 and newer.
>>
>>
On Sat, Jul 3, 2010 at 11:36 AM, Tres Seaver wrote:
> - - Create a "pristine" clone of the trunk (one where I never commit any
> changes):
>
> $ cd $python_repo
> $ hg clone http://code.python.org/hg/trunk/ pytrunk-upstream
>
> - - Create a local clone from that repository:
>
> $ hg clone pyt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Terry Reedy wrote:
> This is perhaps a naive question, but hat do you gain with the
> intermediate mirror clone of upstream? (Other than filling more of your
> disk?)
I gain having my local changes be in a "scratchpad" repsitory, which I
can discar
On Sat, 03 Jul 2010 14:16:08 -0400
Terry Reedy wrote:
>
> This is perhaps a naive question, but hat do you gain with the
> intermediate mirror clone of upstream? (Other than filling more of your
> disk?)
Filling less of your disk, actually, since local clones use hardlinks.
Also, pulling less
On 7/3/2010 12:36 PM, Tres Seaver wrote:
I would say that using the SVN mirror is a fine way to experiment with
using hg against the Python sources to develop and test patches. Here
is the setup I have used for work against trunk (I have a parallel pair
of repositories for the release2.6-maint
On 7/3/2010 10:34 AM, Christian Heimes wrote:
Which docs did you look at specifically that said "and newer"? That
would be a bug.
The readme.txt in the PCbuild directory contains the sentence "Microsoft
Visual C++ 2008 Express Edition is required at the very least". The
wording could be interp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
> Am 02.07.2010 15:09, schrieb Fred Drake:
>> On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou wrote:
>>> The two sets of repositories use different conversion tools and rules.
>>> They have nothing in common (different changeset
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martin v. Löwis wrote:
>> Can somebody comment on how much ongoing effort is required to keep that
>> mirror running?
>
> As everybody else indicated: none (I believe).
OK, cool. I have certainly had no issues using it when working as a
non-committ
Am 03.07.2010 01:54, schrieb "Martin v. Löwis":
>> I don't know about "try" -- personally I don't see a difference for
>> the release procedure, no matter where the source comes from.
>
> I guess you haven't done a release yet, then :-)
That's possible :)
> Assuming you are going to use
>
> htt
On Sat, Jul 3, 2010 at 12:00 AM, "Martin v. Löwis" wrote:
>> I'm trying to test out a patch to add a timeout in subprocess.py on
>> Windows, so I need to build Python with Visual Studio. The docs say
>> the files in PCBuild/ work with VC 9 and newer.
>
> Which docs did you look at specifically th
Am 03.07.2010 09:00, schrieb "Martin v. Löwis":
>> I'm trying to test out a patch to add a timeout in subprocess.py on
>> Windows, so I need to build Python with Visual Studio. The docs say
>> the files in PCBuild/ work with VC 9 and newer.
>
> Which docs did you look at specifically that said "a
On Sat, 3 Jul 2010 14:40:57 +0200
Victor Stinner wrote:
> Le samedi 03 juillet 2010 14:26:53, Victor Stinner a écrit :
> > In the worst case, a function rejects valid data. If I have to choose, I
> > prefer to reject valid data than a security vulnerability. But audioop has
> > tests and I don't t
Le samedi 03 juillet 2010 14:26:53, Victor Stinner a écrit :
> In the worst case, a function rejects valid data. If I have to choose, I
> prefer to reject valid data than a security vulnerability. But audioop has
> tests and I don't think that my patch breaks anything :-)
I checked the test suite:
On Sat, Jul 3, 2010 at 7:05 AM, Dirkjan Ochtman wrote:
> On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull wrote:
>> The point of submodules a la git is subtly different. It is that you
>> can mix and match *known versions* of the modules. So, eg, in order
>> to work on recent urllib, maybe you
On Fri, Jul 2, 2010 at 11:40 PM, Nick Coghlan wrote:
> On Sat, Jul 3, 2010 at 1:28 PM, Benjamin Peterson wrote:
>> This is just a note that we have one bug blocking 2.7 final at the
>> moment: http://bugs.python.org/issue9144
>
> I added Jesse to the nosy list for that as well.
>
> Cheers,
> Nick
Le samedi 03 juillet 2010 12:17:16, Mark Dickinson a écrit :
> On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson
wrote:
> > This is just a note that we have one bug blocking 2.7 final at the
> > moment: http://bugs.python.org/issue9144
>
> I've just made http://bugs.python.org/issue7673 a releas
On Sat, Jul 3, 2010 at 12:53, Stephen J. Turnbull wrote:
> The point of submodules a la git is subtly different. It is that you
> can mix and match *known versions* of the modules. So, eg, in order
> to work on recent urllib, maybe you need a recent *but stable* email
> but you don't want any of
Brett Cannon writes:
> Mercurial has subrepo support, but that doesn't justify the need to
> have every module in its own repository so they can be checked out
> individually.
The point of submodules a la git is subtly different. It is that you
can mix and match *known versions* of the module
On Sat, 3 Jul 2010 11:17:16 +0100
Mark Dickinson wrote:
> On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson wrote:
> > This is just a note that we have one bug blocking 2.7 final at the
> > moment: http://bugs.python.org/issue9144
>
> I've just made http://bugs.python.org/issue7673 a release blo
On Sat, Jul 3, 2010 at 4:28 AM, Benjamin Peterson wrote:
> This is just a note that we have one bug blocking 2.7 final at the
> moment: http://bugs.python.org/issue9144
I've just made http://bugs.python.org/issue7673 a release blocker too,
I'm afraid. It's a potential security vulnerability in t
Steve Holden writes:
> If the wave were to result in good documentation about how to *get*
> ready that would be an amazingly useful contribution.
I'm a coauthor of PEP 374 and of http://emacswiki.org/BzrForEmacsDevs.
I think that I can have a document adapted from the Python dev FAQ,
possibly
> I'm trying to test out a patch to add a timeout in subprocess.py on
> Windows, so I need to build Python with Visual Studio. The docs say
> the files in PCBuild/ work with VC 9 and newer.
Which docs did you look at specifically that said "and newer"? That
would be a bug.
> I downloaded Visual
31 matches
Mail list logo
