On Mon, 28 Feb 2011 10:08:26 -0500
Barry Warsaw wrote:
>
> >BTW, I had not heard of hgeditor before, and wrote a small hg extension to
> >do what you want (with HG: prefix :) before I saw that others had already
> >replied with hgeditor. The extension had 10 lines of code.
>
> We should find a
On Mon, 28 Feb 2011 00:10:10 +0100
Adrian Buehlmann wrote:
>
> Here, the Workbench window [1] starts in under 2s (Windows 7 x64 on
> Intel Core2 Quad). As installed with the x64 msi (installs true 64 bit
> exe's, including 64 bit command line hg).
>
> There's quite a lot of demand loading behind
Hello,
In preparation for the hg switch, I would recommend that, if you have
any feature branches managed with svnmerge, you sync them with the py3k
branch before we switch. That way, it will make it easier to "bridge
the gap" when you create a new repository for your work after the
switch (the s
On Mon, 28 Feb 2011 13:36:11 -0500
Terry Reedy wrote:
>
> > + an existing branch. The pusher then has to merge the superfetatory heads
>
> 'superfetatory'? I have no idea of what this is, neither does
> merriam-webster.com ;-).
There are some Google hits, though... Not sure if they are of pe
Le lundi 28 février 2011 à 13:56 -0600, Benjamin Peterson a écrit :
> 2011/2/28 Antoine Pitrou :
> > On Mon, 28 Feb 2011 13:36:11 -0500
> > Terry Reedy wrote:
> >>
> >> > + an existing branch. The pusher then has to merge the superfetatory
> >> >
On Mon, 28 Feb 2011 16:07:48 -0500
Barry Warsaw wrote:
> On Feb 28, 2011, at 04:15 PM, Antoine Pitrou wrote:
>
> >On Mon, 28 Feb 2011 10:08:26 -0500
> >Barry Warsaw wrote:
> >>
> >> >BTW, I had not heard of hgeditor before, and wrote a small hg exten
Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit :
> > In preparation for the hg switch, I would recommend that, if you have
> > any feature branches managed with svnmerge, you sync them with the py3k
> > branch before we switch. That way, it will make it easier to "bridge
> > the
On Mon, 28 Feb 2011 23:54:46 +0100
"Martin v. Löwis" wrote:
> Am 28.02.2011 23:45, schrieb Antoine Pitrou:
> > Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit :
> >>> In preparation for the hg switch, I would recommend that, if you hav
On Mon, 28 Feb 2011 23:03:51 +0100
brett.cannon wrote:
> +try:
> +subprocess.call([cmd, '-W', 'default', '-bb', '-E', '-m', 'test',
> '-r',
> + '-w', '-u', 'all', '-j',
> + str(multiprocessing.cpu_count())])
> +finally:
> +os
On Tue, 1 Mar 2011 23:36:38 +1000
Nick Coghlan wrote:
> On Tue, Mar 1, 2011 at 8:03 AM, brett.cannon
> wrote:
> > brett.cannon pushed 3e5a61adb41d to devinabox:
> >
> > http://hg.python.org/devinabox/rev/3e5a61adb41d
> > changeset: 8:3e5a61adb41d
> > user: Brett Cannon
> > date:
On Tue, 1 Mar 2011 16:52:58 +0200
Eli Bendersky wrote:
> The PEP (http://www.python.org/dev/peps/pep-0385/) says in "Timeline":
>
> 2010-03-05: final conversion (tentative)
>
> I assume 2011-03-05 is meant here.
Oh... I guess I was a bit optimistic.
Thanks for noticing
Antoine.
On Tue, 01 Mar 2011 21:36:29 +0100
Éric Araujo wrote:
> > user: Antoine Pitrou
> > date:Tue Mar 01 20:51:42 2011 +0100
> > summary:
> > Update instructions to use the new "server-side clone" button
>
> That’s seriously aweso
Hello,
In
http://mail.python.org/pipermail/python-committers/2011-February/001340.html, I
was asking whether it would be useful to make a survey of past contributors, as
in:
First, we did a survey of all our past developers who had left
the project, asking them why they had lef
On Tue, 1 Mar 2011 17:12:14 -0500
Jesse Noller wrote:
> On Tue, Mar 1, 2011 at 4:24 PM, Antoine Pitrou wrote:
> >
> > Hello,
> >
> > In
> > http://mail.python.org/pipermail/python-committers/2011-February/001340.html,
> > I was asking whether it w
On Tue, 1 Mar 2011 16:23:42 -0600
Benjamin Peterson wrote:
> 2011/3/1 Antoine Pitrou :
> >
> > Hello,
> >
> > In
> > http://mail.python.org/pipermail/python-committers/2011-February/001340.html,
> > I was asking whether it would be useful to make a
Le mardi 01 mars 2011 à 16:41 -0600, Benjamin Peterson a écrit :
> 2011/3/1 Antoine Pitrou :
> > On Tue, 1 Mar 2011 16:23:42 -0600
> > Benjamin Peterson wrote:
> >> 2011/3/1 Antoine Pitrou :
> >> >
> >> > Hello,
> >> >
> >>
On Tue, 1 Mar 2011 16:49:42 -0600
s...@pobox.com wrote:
>
> Antoine> We already have "make test" and "make buildbottest" in addition
> Antoine> to "./python -m test". I think another subtly different way of
> Antoine> running the tests would be a nuisance.
>
> I see nothing wrong with
On Tue, 1 Mar 2011 17:05:25 -0600
s...@pobox.com wrote:
>
> Antoine> Well, "make buildbottest" should do the trick.
>
> Perhaps it should be given a somewhat less specialized sounding name...
It *is* specialized since it's meant primarily for the buildbots :)
It happens to be usable by anyon
On Wed, 02 Mar 2011 00:45:51 +0100
"Martin v. Löwis" wrote:
> >> I believe we agreed at the language summit last year (or maybe even the
> >> year before) that "python" would always be python2.x, and "python3"
> >> would be python3.x.
> >>
> >> And by "always" we indeed meant forever. To do othe
On Mon, 28 Feb 2011 23:03:50 +0100
brett.cannon wrote:
> +
> +if sys.platform == 'win32':
> +print("See the devguide's Getting Set Up guide for building under
> Windows")
Actually, you can also build from the command line under Windows:
using Tools/buildbot/build.bat or Tools/buildbot/build-
On Tue, 1 Mar 2011 20:43:27 -0800
Guido van Rossum wrote:
>
> But I wouldn't be surprised if some people had regrets about the way
> the community works (I can recall at least one such case) and it would
> be useful to learn from those occasions, if they'll let us. And the
> numbers might tell us
Hello,
On Tue, 01 Mar 2011 19:25:00 -0800
Westley Martínez wrote:
>
> If I got a message like that in my mailbox I would be rather annoyed,
> mark it as spam, and be less likely to contribute again.
Yes, I think that's a risk. Do you think of a wording that could
alleviate such perception?
Th
On Wed, 2 Mar 2011 14:29:18 +0200
Andrew Svetlov wrote:
> SVN is very bad instrument to contribute or follow an issue patches.
Will Mercurial make things more attractive?
> And, of course, very long lifecycle of the most issues greatly reduces
> enthusisasm.
True. I believe we are improving th
On Thu, 3 Mar 2011 09:24:29 -0800
Raymond Hettinger wrote:
>
> On Mar 3, 2011, at 4:40 AM, anatoly techtonik wrote:
>
> > How about official RoadMap? There is no visibility into what's going
> > on in Python development. New people can' t jump in and help do bring
> > some features faster. http:
On Fri, 04 Mar 2011 09:35:38 +0100
"Martin v. Löwis" wrote:
> Google Summer of Code is coming up again, and we will again
> be participating. Arc Riley will setup infrastructure later
> today, and we need to start thinking about possible projects.
We've had a couple of people asking questions abo
On Fri, 04 Mar 2011 13:40:16 +0100
Victor Stinner wrote:
> > I am still bothered by the fact that,
> >
> > >>> import faulthandler
> > >>> faulthandler.enable()
> > >>> import sys
> > >>> sys.stderr.close()
> > >>> sys.stderr = open('logs/error.log', 'wb')
> > >>> faulthandler.sigsegv()
> >
> >
On Fri, 04 Mar 2011 22:45:24 +0100
"Martin v. Löwis" wrote:
> > It's not really needed; but since it works with 6+ hex digits there might
> > be false positives.
>
> I searched the messages, and it turns out that primarily long numbers
> would give false positives:
>
> Python 1.6a2 (#7, Apr 24
Le vendredi 04 mars 2011 à 14:03 -0800, Santoso Wijaya a écrit :
> [...] publishing patches by referring to a remote repository,
> rather than uploading the diff.
>
>
> Is this a recommended workflow at this point, or should we
> generate/attach patch files still? Both, for experi
On Fri, 04 Mar 2011 16:51:15 -0500
David Malcolm wrote:
> On Fri, 2011-03-04 at 18:17 +0100, Georg Brandl wrote:
> > On 04.03.2011 13:59, Victor Stinner wrote:
> > > Hi,
> > >
> > > Does the bug tracker will continue to support rX links after the
> > > migration to Mercurial?
> >
> > Yes.
On Sat, 5 Mar 2011 08:36:04 -0800
Daniel Stutzbach wrote:
> On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney
> wrote:
>
> > If those were to be removed from .hgignore then there would be a high
> > likelihood of someone doing "hg addremove" and inadvertently tracking them.
> > The purpose of .hgigno
On Sat, 05 Mar 2011 18:26:29 +
Michael Foord wrote:
> On 28/02/2011 21:59, "Martin v. Löwis" wrote:
> That's one of the big advantages that Jenkins (nee Hudson) has over
> buildbot - drilling down into individual test failures through the
> web ui. Your test run needs to generat
On Sun, 6 Mar 2011 08:51:01 +1100
Neil Hodgson wrote:
> Georg Brandl:
>
> > I'm very happy to announce that the core Python repository switch
> > to Mercurial is complete and the new repository at
> > http://hg.python.org/cpython/ is now officially open for cloning,
>
>OK, I just performed a
Le dimanche 06 mars 2011 à 09:27 +1100, Neil Hodgson a écrit :
> Antoine Pitrou:
>
> > It mimicks their settings in the SVN repository, so it should be ok.
>
>It doesn't match how they are checked out by svn since they have
> the property svn:eol-style set to '
On Sun, 6 Mar 2011 10:27:14 +1100
Neil Hodgson wrote:
>To minimize differences from previous behaviour, it is probably
> best to mimic svn more closely by changing .hgeol to either have all
> the project files as native or allow fall through to the default ** =
> native.
If it's only cosmetic
On Sun, 06 Mar 2011 00:37:32 +0100
"Martin v. Löwis" wrote:
> What is the recommended merge flow if I want to make this change to
> all branches?
- on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain 2.5)
- on the other hand: 3.1 -> 3.2 -> default
Regards
Antoine.
__
On Sun, 06 Mar 2011 00:44:03 +0100
"Martin v. Löwis" wrote:
> How should patches be applied to the cpython repository if they
> land in more than one branch?
>
> More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and
> default - how do I apply the patches and how do I merge?
(repo
hg.python.org/hooks/rev/d2aca4834bb9
> [0;33mchangeset: 48:d2aca4834bb9[0m
> user: Antoine Pitrou
> date:Sun Mar 06 02:36:25 2011 +0100
> summary:
> Hopefully fix the issue where notification of merges to buildbot
> wouldn't notify all changed files (becau
On Sun, 06 Mar 2011 04:54:06 +0100
Jesus Cea wrote:
> I would rather prefer to promote the "-A" parameter to SSH (to use the
> local SSH agent be used from the remote development machine) instead of
> uploading private keys.
That's not a good answer to the question, since it cannot apply to
machi
Hi,
> I assume Stefan was referring to the features/py3k-cdecimal clone
> rather than the cpython one. This is going to happen with all the
> server-side clones - we really only want "default" in the clone, but
> the maintenance branches will come along for the ride. There are
> actually a few t
On Sun, 6 Mar 2011 21:58:24 +1000
Nick Coghlan wrote:
> On Sun, Mar 6, 2011 at 7:37 PM, ned.deily wrote:
> > http://hg.python.org/devguide/rev/ad3278cfc5f6
> > changeset: 376:ad3278cfc5f6
> > user: Ned Deily
> > date: Sun Mar 06 01:37:13 2011 -0800
> > summary:
> > More miscell
On Sun, 6 Mar 2011 08:17:35 -0600
Benjamin Peterson wrote:
> I wonder if we couldn't kill the "cpython" repo name in the commit
> mails. I find it wastes space for the commit message in the subject
> line, and it's pretty obvious it's the cpython repo from the branch
> name.
Well, right now commi
On Mon, 7 Mar 2011 00:52:08 +1000
Nick Coghlan wrote:
>
> I'm actually OK with the status quo, but if we were going to change
> it, I would continue to leave (default) out.
>
> Completely unqualified = cpython default
> Only branch name = cpython branch
> Only repository name = other repository
On Mon, 7 Mar 2011 01:11:24 +1000
Nick Coghlan wrote:
>
> [python-checkins] Lorem ipsum dolor sit amet
> [python-checkins] (3.1): Lorem ipsum dolor sit amet
> [python-checkins] devguide: Lorem ipsum dolor sit amet
> [python-checkins] devguide (hg_migration): Lorem ipsum dolor sit amet
If you rea
Le dimanche 06 mars 2011 à 09:50 -0600, s...@pobox.com a écrit :
> Antoine> "Martin v. Löwis" wrote:
> >> What is the recommended merge flow if I want to make this change to
> >> all branches?
>
> Antoine> - on one hand: 2.5 -> 2.6 -> 2.7 (if you still want to maintain
> Antoine>
On Sun, 6 Mar 2011 17:32:40 +0100 (CET)
martin.v.loewis wrote:
>
> -def find_bases(data, rev):
> +def hg_splitpatch(data):
> +patches = []
> +filename = None
> +for line in data.splitlines(True):
> +if line.startswith('diff -r'):
Now I understand why you would like to disco
On Sun, 06 Mar 2011 16:52:54 +
Michael Foord wrote:
> On 06/03/2011 13:14, Antoine Pitrou wrote:
> > On Sun, 6 Mar 2011 21:58:24 +1000
> > Nick Coghlan wrote:
> >
> >> On Sun, Mar 6, 2011 at 7:37 PM, ned.deily
> >> wrote:
> >>
Le dimanche 06 mars 2011 à 11:34 -0600, s...@pobox.com a écrit :
> Assume I have separate 3.1 and 3.2 sandboxes
> which are sibling directories of each other, and that I commit a change to
> my 3.1 sandbox, how do I merge the change from 3.1 to 3.2? Assume I don't
> understand the instructions lat
On Sun, 06 Mar 2011 18:23:58 +0100
"Martin v. Löwis" wrote:
> >> -def find_bases(data, rev):
> >> +def hg_splitpatch(data):
> >> +patches = []
> >> +filename = None
> >> +for line in data.splitlines(True):
> >> +if line.startswith('diff -r'):
> >
> > Now I understand why you wo
Beside Martin's answer, you might want to read:
http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html
or perhaps:
http://hginit.com/
Regards
Antoine.
Le dimanche 06 mars 2011 à 14:46 -0600, s...@pobox.com a écrit :
> Antoine> Yes, there is. You can simply push to your 3.2 repo
On Mon, 7 Mar 2011 19:14:55 +1000
Nick Coghlan wrote:
> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
> wrote:
> >
> > Especially since, AIUI, deprecations are suppressed by default now.
>
> True, but developers are expected to run their tests with them enabled.
Where do we actually docume
On Mon, 7 Mar 2011 11:40:04 + (UTC)
Vinay Sajip wrote:
> I want to maintain several working copies, as sometimes I have to make bugfix
> changes across several revisions. Since we are supposed to use
> forward-porting,
> I tried to set up a 2.5 clone,
Vinay, 2.5 has been long closed for bug
On Mon, 7 Mar 2011 12:04:18 -0500
Barry Warsaw wrote:
> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
>
> >If we can get to a mode where non-committers can push to a "fork" on
> >hg.python.org, we can dodge the patch format issue by having folks post
> >"pull requests" for that fork instaed.
>
On Mon, 07 Mar 2011 19:29:51 +0100
Éric Araujo wrote:
> Hello,
>
> > changeset: 68315:b9d76846bb1c
> > branch: 2.6
> > parent: 68264:50166a4bcfc6
> > user:Vinay Sajip
> > date:Mon Mar 07 15:02:11 2011 +
> > summary:
> > Issue #11424: Fix bug in determining child
On Mon, 7 Mar 2011 13:04:11 -0500
Barry Warsaw wrote:
> On Mar 07, 2011, at 06:31 PM, Antoine Pitrou wrote:
>
> >On Mon, 7 Mar 2011 12:04:18 -0500
> >Barry Warsaw wrote:
> >> On Mar 07, 2011, at 11:44 AM, Tres Seaver wrote:
> >>
> >> >If we can
On Mon, 07 Mar 2011 14:45:57 -0500
Terry Reedy wrote:
> On 3/7/2011 9:47 AM, Antoine Pitrou wrote:
> > On Mon, 7 Mar 2011 19:14:55 +1000
> > Nick Coghlan wrote:
> >> On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel
> >> wrote:
> >>>
> >>
On Tue, 08 Mar 2011 09:38:27 +0100
"Martin v. Löwis" wrote:
> > However, as Michael points out, you can have your tools generate the
> > patch. For example, it shouldn't be too hard to add a dynamic patch
> > generator to Roundup (although I haven't thought about the UI or the
> > CPU burden).
>
On Tue, 08 Mar 2011 12:23:54 +0100
local wrote:
> +
> +VERBS = r'(?:\b(?Pclose[sd]?|closing|fixe[sd]|fixing|fix)\s+)?'
> +ISSUE_PATTERN = re.compile(r'%s(?:#|\bissue|\bbug)\s*(?P[0-9]+)'
> + % VERBS, re.I)
This should only match numbers with 4 and 5 figures IMO.
Otherwis
Ouch. I fear this message may be repeated several times :/
Sorry for the spam, if that happens...
Regards
Antoine.
On Tue, 08 Mar 2011 19:32:20 +
Python tracker wrote:
>
>
> You are not a registered user.
>
> Unknown address: python-dev@python.org
>
_
Well, after a couple of days with the "cpython" prefix stripped, I have
to say that I find it much less practical than it was before. Any other
opinions?
Regards
Antoine.
On Mon, 7 Mar 2011 01:11:24 +1000
Nick Coghlan wrote:
> On Mon, Mar 7, 2011 at 12:56 AM, Antoine Pitrou
Le mardi 08 mars 2011 à 14:51 -0600, s...@pobox.com a écrit :
> Antoine> Ouch. I fear this message may be repeated several times :/
> Antoine> Sorry for the spam, if that happens...
>
> Do you want me to reject or discard future messages to python-dev from
> roundup-admin?
Hopefully there won
On Tue, 08 Mar 2011 15:07:29 -0500
Terry Reedy wrote:
>
> > +If "closes" or "fixes" (with alternative verb forms like "fixing"
> > +allowed too) is prepended, the issue is automatically closed as
> > +"fixed".
>
> Fix may be too broad. "This patch fixes the first part of the issue."
Ok, it has
On Wed, 9 Mar 2011 19:42:36 +0100
Giampaolo Rodolà wrote:
> > Actually, why not put up a web page of "upcoming changes" somewhere, that
> > lists major decisions with user impact that were taken on python-dev?
>
> I think "what's new" serves this purpose properly.
> Usually, every time I commit a
On Wed, 9 Mar 2011 18:20:01 -0500
James Y Knight wrote:
> It's well known that OpenSSL is incompatible with the GPL. [1] Python (from
> 2.6) is *always* linked against openssl, instead of waiting for you to
> "import ssl".
>
> Doesn't this mean it's now impossible (rather, a license violation)
Hello,
> I've noticed since version 3.2 python doesn't fold -0:
Indeed, see http://bugs.python.org/issue11244
Regards
Antoine.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http:/
On Thu, 10 Mar 2011 12:18:22 +0100
Sturla Molden wrote:
>
> Obvious usecases for volatile are:
>
> - Implementation of a spinlock, where register allocation is detrimental.
> - A buffer that is filled from the "outside" with some DMA mechanism.
> - Real-time programs and games where order of exe
On Thu, 10 Mar 2011 21:29:59 +0100
Éric Araujo wrote:
> Hi,
>
> >> changeset: 68315:b9d76846bb1c
> >> branch: 2.6
> >> parent: 68264:50166a4bcfc6
> >> user:Vinay Sajip
> >> date:Mon Mar 07 15:02:11 2011 +
> >> summary:
> >> Issue #11424: Fix bug in determining c
On Thu, 10 Mar 2011 02:17:34 + (UTC)
Eugene Toder wrote:
> > Indeed, see http://bugs.python.org/issue11244
>
> Yes, I've noticed that too. However, if I'm not missing something, your
> patches
> do not address folding of -0.
>
> Btw, there's an alternative approach to allow "recursive" cons
On Thu, 10 Mar 2011 15:46:11 PST
Bill Janssen wrote:
> David Bolen wrote:
>
> > Bill Janssen writes:
> >
> > > I'm trying to get a new buildbot in the swim of things, and it keeps
> > > getting into this state where the buildslave process seems caught in an
> > > endless loop. Perhaps someone
On Wed, 09 Mar 2011 07:15:07 +0100
Stefan Behnel wrote:
>
> Actually, why not put up a web page of "upcoming changes" somewhere, that
> lists major decisions with user impact that were taken on python-dev?
> Including a link to the relevant discussion and decision. Often enough,
> decisions ar
On Fri, 11 Mar 2011 15:53:03 -0500
Tres Seaver wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 03/11/2011 03:24 PM, Antoine Pitrou wrote:
> > On Wed, 09 Mar 2011 07:15:07 +0100
> > Stefan Behnel wrote:
> >>
> >> Actually, why not put up
On Wed, 9 Mar 2011 15:40:56 -0500
Doug Hellmann wrote:
>
> The original request from the board was for the communications team to write
> the messages, but I think it is more appropriate for the people doing the
> work to talk about it. [...]
>
> I asked Michael to add this topic to the agenda
On Fri, 11 Mar 2011 22:56:49 +0100
Antoine Pitrou wrote:
> On Fri, 11 Mar 2011 15:53:03 -0500
> Tres Seaver wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > On 03/11/2011 03:24 PM, Antoine Pitrou wrote:
> > > On Wed, 09 Mar 2011 07
Hello,
> I recall several occasions where the peephole optimizer was subtly
> buggy -- on one occasion the bug remained undetected for at least a
> whole release cycle. (Sorry, I can't recall the details.) In fact, the
> bug reported in http://bugs.python.org/issue11244 is another example
> of ho
Hello,
> Am I missing something? Does SETUP_LOOP serve any other purpose?
Not to my knowledge.
> Similarly, it looks like BREAK_LOOP and CONTINUE_LOOP are just jumps
> that respect try/finally blocks (i.e. jumping out of try executes
> finally). Is there more semantics to them than this?
There
On Sat, 12 Mar 2011 16:55:30 +0100
Éric Araujo wrote:
> > I have a deprecation warning that I need to make an error in 3.4.
>
> A neat trick to remember to do those changes is using a test that fails
> if something does not raise a DeprecationWarning if sys.version_info[:2]
> == (3, 3), or an err
Hello,
> Finally: There appears to be some disagreement on who said what, in
> particular Raymond claims that he told Antoine not to commit whereas
> Antoine claims he did not hear this feedback. I'm guessing it happened
> in IRC (#python-dev), which is intentionally not logged anywhere.
Raymond
On Sat, 12 Mar 2011 13:08:26 -0500
Raymond Hettinger wrote:
> I would like to withdraw my suggestion for the recursive constant folding
> patch to be reverted. I value social harmony much more than a decision about
> whether a particular patch is a good idea. I apologize to anyone who is
> up
On Sun, 13 Mar 2011 00:24:07 +0200
Nadeem Vawda wrote:
> On Sat, Mar 12, 2011 at 1:29 PM, "Martin v. Löwis" wrote:
> > Isn't that command correct only if you are merging into default?
> > ISTM that it should be "hg revert -ar ".
>
> In general, yes. However, the existing text refers specifically
On Sat, 12 Mar 2011 23:43:52 +0100
Éric Araujo wrote:
> > hg revert -ar default
>
> You can’t combine the -r option with other options. (Yes, it’s a known
> bug.)
Are you sure? It just worked here:
$ hg rev -ar default
reverting README
(perhaps you're thinking of -R instead?)
> On an unrelat
On Sun, 13 Mar 2011 09:28:28 -0400
Nick Coghlan wrote:
>
> > The mercurial-recommended way is that you just push your changes to cpython
> > when done, which puts all your individual commits into Python's history.
> >
> > I tried to find an official statement on which way it should be in the
> >
On Sun, 13 Mar 2011 01:34:21 +0100
benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/52940f7f3726
> changeset: 68416:52940f7f3726
> user:Benjamin Peterson
> date:Sat Mar 12 18:35:23 2011 -0600
> summary:
> bump ast version
>
> files:
> Python/Python-ast.c
>
> dif
On Mon, 14 Mar 2011 06:29:09 -0400
Eric Smith wrote:
> On 03/14/2011 02:33 AM, Greg Ewing wrote:
> > Tim Lesher wrote:
> >
> >> Because named tuple prefixes a single underscore to its added method
> >> names (_asdict, _replace, and _make), those methods' docstrings are
> >> omitted from pydoc:
> >
On Mon, 14 Mar 2011 06:01:17 -0400
Nick Coghlan wrote:
> On Sun, Mar 13, 2011 at 6:29 PM, antoine.pitrou
> wrote:
> > .. index:: single: Py_Initialize()
> >
> > - This is a no-op when called for a second time. It is safe to call this
> > function
> > - before calling :c:func:`Py_Initial
On Mon, 14 Mar 2011 17:16:11 +0100
reid.kleckner wrote:
> @@ -265,34 +271,43 @@
>generates enough output to a pipe such that it blocks waiting
>for the OS pipe buffer to accept more data.
>
> + .. versionchanged:: 3.2
> + *timeout* was added.
Unless you plan to borrow som
On Mon, 14 Mar 2011 17:59:27 +0100
Jesus Cea wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Traditionally I could see who was the committer who push change to the
> buildbots. This info seems not to be (easily) available.
That info was lost quite before the hg migration, when the
On Mon, 14 Mar 2011 15:39:55 -0400
Tarek Ziadé wrote:
> Hey,
>
> I just wanted to summarize what we've started at the sprint (and
> hopefully finish 1 to 7 this week):
>
> 1/ distutils2 is merged as the "packaging" Python package in the
> standard library
Why does it get yet another name?
We al
On Mon, 14 Mar 2011 18:00:50 -0400
Tarek Ziadé wrote:
>
> And it's also a good way to prevent any conflict with 3.3 : the
> standalone version for 2.4 to 3.2 is "distutils2", and people won't
> have to deal with the same package being in the stdlib and at PyPI.
> (like json vs simplejson, unittes
On Tue, 15 Mar 2011 15:29:59 +0100
brian.curtin wrote:
> +
> +def test_gz_ext(self):
[...]
> +
> +def test_bz2_ext(self):
[...]
> +
> +def test_Gz_ext(self):
> +self.do_test_use_builtin_open("abcd.Gz", 6)
> +
> +def test_Bz2_ext(self):
> +self.do_test_use_builtin_op
On Tue, 15 Mar 2011 11:17:18 -0400
Nick Coghlan wrote:
> On Tue, Mar 15, 2011 at 10:22 AM, Michael Foord
> wrote:
> > On 15/03/2011 07:59, Nick Coghlan wrote:
> >> While I actually think the current API design is a decent compromise,
> >> another option to consider would be to move the underscore
On Tue, 15 Mar 2011 04:19:24 +0100
ezio.melotti wrote:
> Modules/_ctypes/libffi/src/powerpc/ffi_darwin.c
> Modules/_ctypes/libffi_osx/powerpc/ppc-ffi_darwin.c
libffi is a third-party library and you should probably not introduce
gratuitous changes in these files. It will make tracking changes
On Tue, 15 Mar 2011 18:46:37 -0400
Lennart Regebro wrote:
>
> > Right - and that's why the deprecation period is not about supporting
> > multiple versions, but to reduce the need for people to adjust their
> > code on a quick notice.
>
> I think we need to adjust PEP 5 then. We can't keep on br
On Wed, 16 Mar 2011 02:00:42 +0100
Jesus Cea wrote:
>
> The standard approach in mercurial is for her to pull the changes and to
> do a merge before trying to push again (and hope nobody else "raced" her
> again, this time).
This is indeed the standard approach, so I'm not sure what the point of
On Wed, 16 Mar 2011 02:37:21 +0100
Jesus Cea wrote:
>
> Maybe a simple "try to keep the history lineal, as possible" and "feel
> free to merge heads in the standard mercurial way".
Well, can you propose a patch to add or improve wording?
> For instance, merging between branches (in which direct
On Tue, 15 Mar 2011 21:16:58 -0400
Lennart Regebro wrote:
> On Tue, Mar 15, 2011 at 19:14, Antoine Pitrou wrote:
> > Beside, if you need long-term support, there is a well-known solution:
> > turn to a company that provides such support. That company can be called
> &
Hi,
> We (me and Carl Meyer) did some experimentation with encoding behavior
> on Python 3. Carl did some hacking on getting virtualenv running on
> Python 3 and it turned out that his version of virtualenv did not work
> on Python 3 on my server either. So none of the virtulenv installation
Hello,
> I think devguide's suggested interbranch workflow introduces too much
> complexity for too little payoff.
>
> If I need to make a fix to 3.2, I can't just fix it. I would need to also
> merge the changeset into 3.3 and then revert it, and then commit both. There
> is not much payof
On Thu, 17 Mar 2011 09:24:26 -0400
"R. David Murray" wrote:
>
> It would be great if rebase did work with share, that would make a
> push race basically a non-issue for me.
rebase as well as strip destroy some history, meaning some of your
shared clones may end up having their working copy based
On Thu, 17 Mar 2011 01:01:30 +0100
nick.coghlan wrote:
> http://hg.python.org/cpython/rev/e3fb176add41
> changeset: 68628:e3fb176add41
> user:Nick Coghlan
> date:Wed Mar 16 19:52:14 2011 -0400
> summary:
> Exercise crashers to ensure they are still covering known error cases
>
On Thu, 17 Mar 2011 10:50:24 -0400
"R. David Murray" wrote:
> On Thu, 17 Mar 2011 14:33:00 +0100, Antoine Pitrou
> wrote:
> > On Thu, 17 Mar 2011 09:24:26 -0400
> > "R. David Murray" wrote:
> > >
> > > It would be great if rebas
On Thu, 17 Mar 2011 19:23:30 -0400
Terry Reedy wrote:
> People should retest their stuff with
> each micro (bugfix) release anyway.
I'm not sure they should. The point of having micro releases is that
they don't bring any visible change in behaviour - apart from fixing
bugs, that is.
Regards
A
3401 - 3500 of 4909 matches
Mail list logo
