On 12.03.2011 17:09, Eric Smith wrote:
On 03/12/2011 10:55 AM, É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]
I'm experimenting with creating some local branches for things I'd
like to work on during the sprints this week, and have a couple of
questions about the associated workflow.
1. While the feature branches are active, is it correct that I can't
use a bare hg push any more, since I don't want to
On Sun, Mar 13, 2011 at 8:25 PM, Nick Coghlan ncogh...@gmail.com wrote:
1. While the feature branches are active, is it correct that I can't
use a bare hg push any more, since I don't want to push the feature
branches to hg.python.org? Instead, I need to name all the branches I
want to push
On Sun, Mar 13, 2011 at 12:25, Nick Coghlan ncogh...@gmail.com wrote:
I'm experimenting with creating some local branches for things I'd
like to work on during the sprints this week, and have a couple of
questions about the associated workflow.
By local branches, do you mean named branches
On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull step...@xemacs.org wrote:
2. Once I'm done with the feature branch, I need to nuke it somehow
(e.g. by enabling the mq extension to gain access to hg strip
command)
You may *want* to do that, but hg branch obsolete-branch;
hg commit -m I'm
On 13 March 2011 03:00, Raymond Hettinger raymond.hettin...@gmail.com wrote:
But in Python 3 this solution is no longer available. How bad is that?
I'm not sure. But I'd like to at least get the issue out in the open.
Python3.2 should be substantially better in this regard.
It no longer
On Sun, Mar 13, 2011 at 13:25, Nick Coghlan ncogh...@gmail.com wrote:
I'm experimenting with creating some local branches for things I'd
like to work on during the sprints this week, and have a couple of
questions about the associated workflow.
The way to do this, IMHO, is just create a
On Sun, Mar 13, 2011 at 8:32 AM, Eli Bendersky eli...@gmail.com wrote:
The way to do this, IMHO, is just create a local clone and work on it. Then
you can keep checking partial changes in without ever worrying about
accidentally modifying the official repo. Especially if some of this work is
Am 13.03.11 07:25, schrieb Nick Coghlan:
I'm experimenting with creating some local branches for things I'd
like to work on during the sprints this week, and have a couple of
questions about the associated workflow.
1. While the feature branches are active, is it correct that I can't
use a bare
You are not permitted to edit property stage of class issue.Return-Path: python-dev@python.org
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za
You are not permitted to edit property stage of class issue.Return-Path: python-dev@python.org
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za
You are not permitted to edit property stage of class issue.Return-Path: python-dev@python.org
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za
You are not permitted to edit property stage of class issue.Return-Path: python-dev@python.org
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
by psf.upfronthosting.co.za
On Sun, Mar 13, 2011 at 14:41, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Mar 13, 2011 at 8:32 AM, Eli Bendersky eli...@gmail.com wrote:
The way to do this, IMHO, is just create a local clone and work on it.
Then
you can keep checking partial changes in without ever worrying about
On Sun, Mar 13, 2011 at 8:47 AM, Martin v. Löwis mar...@v.loewis.de wrote:
Am 13.03.11 07:25, schrieb Nick Coghlan:
2. Once I'm done with the feature branch, I need to nuke it somehow
(e.g. by enabling the mq extension to gain access to hg strip
command)
I think this will need
On Sun, 13 Mar 2011 09:28:28 -0400
Nick Coghlan ncogh...@gmail.com 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
On 03/13/2011 06:49 AM, Georg Brandl wrote:
On 12.03.2011 17:09, Eric Smith wrote:
On 03/12/2011 10:55 AM, É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
2011/3/13 Antoine Pitrou solip...@pitrou.net:
On Sun, 13 Mar 2011 09:28:28 -0400
Nick Coghlan ncogh...@gmail.com 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
On Sun, Mar 13, 2011 at 9:05 PM, Nick Coghlan ncogh...@gmail.com wrote:
On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull step...@xemacs.org
wrote:
You may *want* to do that, but hg branch obsolete-branch;
hg commit -m I'm done --close should also do the trick of getting
it out of the
On Sun, Mar 13, 2011 at 9:32 PM, Eli Bendersky eli...@gmail.com wrote:
The way to do this, IMHO, is just create a local clone and work on it. Then
you can keep checking partial changes in without ever worrying about
accidentally modifying the official repo. Especially if some of this work is
tl;dr: +1 for pushing only clean changesets.
Le 13/03/2011 14:44, Antoine Pitrou a écrit :
I think we (python-dev) will need to take a decision on this.
My personal opinion is that we don't want to see all intermediate
commits which led to a patch (or feature) in the main repo. It may
also
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 (which then allows Rietveld review
of the patch).
On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum gu...@python.org wrote:
I recently advised a Googler who was sorting a large dataset and
running out of memory. My analysis of the situation was that he was
sorting a huge list of short lines of the form shortstring,integer
with a key function
On Sun, 13 Mar 2011 01:34:21 +0100
benjamin.peterson python-check...@python.org wrote:
http://hg.python.org/cpython/rev/52940f7f3726
changeset: 68416:52940f7f3726
user:Benjamin Peterson benja...@python.org
date:Sat Mar 12 18:35:23 2011 -0600
summary:
bump ast version
2011/3/13 Antoine Pitrou solip...@pitrou.net:
On Sun, 13 Mar 2011 01:34:21 +0100
benjamin.peterson python-check...@python.org wrote:
http://hg.python.org/cpython/rev/52940f7f3726
changeset: 68416:52940f7f3726
user: Benjamin Peterson benja...@python.org
date: Sat Mar 12
A revision number is, indeed, local to the working repository. A changeset
ID, however is global.
From Mercurial's documentation:
Revision numbers referring to changesets are very likely to be different in
another copy of a repository. Do not use them to talk about changesets with
other people.
On Sat, Mar 12, 2011 at 9:17 PM, Terry Reedy tjre...@udel.edu wrote:
But in this case, they are much slower. To be faster, one would need
something like key=lambda p,q:p*(lcm//q), where lcm is the least common
multiple of of all the q's (denominators). For the example above, lcm = 700.
But
On 3/13/2011 2:05 PM, Daniel Stutzbach wrote:
On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum gu...@python.org
mailto:gu...@python.org wrote:
I recently advised a Googler who was sorting a large dataset and
running out of memory. My analysis of the situation was that he was
[I mentioned this to Raymond Hettinger after his PyCon talk, and I
promised a bug and hopefully a patch. I don't see an obvious solution,
though, so I'll ask here first.]
Because named tuple prefixes a single underscore to its added method
names (_asdict, _replace, and _make), those methods'
2011/3/13 Tim Lesher tles...@gmail.com:
[I mentioned this to Raymond Hettinger after his PyCon talk, and I
promised a bug and hopefully a patch. I don't see an obvious solution,
though, so I'll ask here first.]
Because named tuple prefixes a single underscore to its added method
names
On Mon, Mar 14, 2011 at 12:41 PM, Tim Lesher tles...@gmail.com wrote:
[I mentioned this to Raymond Hettinger after his PyCon talk, and I
promised a bug and hopefully a patch. I don't see an obvious solution,
though, so I'll ask here first.]
Because named tuple prefixes a single underscore to
On Mon, Mar 14, 2011 at 12:57 PM, James Mills
prolo...@shortcircuit.net.au wrote:
[output omitted; it excludes _asdict, _replace, and _make]
Sorry I missed this bit :)
Works for me. Python 3.2 on 32bit Linux.
Scrap that :)
cheers
James
--
-- James Mills
--
-- Problems are solved by method
Addendum: this looks related to bug 1189811.
http://bugs.python.org/issue1189811
That issue seems to hinge on the definition of private.
--
Tim Lesher tles...@gmail.com
___
Python-Dev mailing list
Python-Dev@python.org
33 matches
Mail list logo
