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:
IMO these should be called __asdict__, __replace__ and
__make__. Users are perfectly entitled to make up their
own sing
Addendum: this looks related to bug 1189811.
http://bugs.python.org/issue1189811
That issue seems to hinge on the definition of "private".
--
Tim Lesher
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-
On Mon, Mar 14, 2011 at 12:57 PM, James Mills
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"
On Mon, Mar 14, 2011 at 12:41 PM, Tim Lesher 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 its added met
2011/3/13 Tim Lesher :
> [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
[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' docst
On 3/13/2011 2:05 PM, Daniel Stutzbach wrote:
On Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum 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
sorting a huge list of
On Sat, Mar 12, 2011 at 9:17 PM, Terry Reedy 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 for longer li
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.
2011/3/13 Antoine Pitrou :
> 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
>>
>> f
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 Sat, Mar 12, 2011 at 3:44 PM, Guido van Rossum 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 that retur
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).
Regard
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
> a
On Sun, Mar 13, 2011 at 9:32 PM, Eli Bendersky 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
> experimental
On Sun, Mar 13, 2011 at 9:05 PM, Nick Coghlan wrote:
> On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull
> 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 way of most commands.
>
> Ala
2011/3/13 Antoine Pitrou :
> 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
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 a
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, Mar 13, 2011 at 8:47 AM, "Martin v. Löwis" 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 reconsidertion. Appa
On Sun, Mar 13, 2011 at 14:41, Nick Coghlan wrote:
> On Sun, Mar 13, 2011 at 8:32 AM, Eli Bendersky 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 off
You are not permitted to edit property stage of class issue.Return-Path:
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 (Postfix) with ESMTPS id E18F4
You are not permitted to edit property stage of class issue.Return-Path:
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 (Postfix) with ESMTPS id D03D1
You are not permitted to edit property stage of class issue.Return-Path:
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 (Postfix) with ESMTPS id 07599
You are not permitted to edit property stage of class issue.Return-Path:
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 (Postfix) with ESMTPS id 2E3A1
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
On Sun, Mar 13, 2011 at 8:32 AM, Eli Bendersky 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
> experimental a
On Sun, Mar 13, 2011 at 13:25, Nick Coghlan 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 local clone and wor
On 13 March 2011 03:00, Raymond Hettinger 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 wraps key objects aroun
On Sun, Mar 13, 2011 at 7:56 AM, Stephen J. Turnbull 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 done"
On Sun, Mar 13, 2011 at 12:25, Nick Coghlan 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 (using the hg branc
On Sun, Mar 13, 2011 at 8:25 PM, Nick Coghlan 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 explicitly.
M
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 p
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_
34 matches
Mail list logo
