[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
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
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
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"
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-
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
On Mar 13, 2011, at 7: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.]
Just make a tracker entry and assign it to me.
I'll take a look and see
On Mon, Mar 14, 2011 at 2: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:
>
> IMO these should be called __asdict__, __replace__ and
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:
IMO these should be called __asdict__, __replace__ and
__make__. Users are p
> No, probably we should add some sort of __yes_i_am_public__ override
> attribute that pydoc looks for. It's such a pity that those methods
> have to have underscores...
My opinion is that pydoc should use __dir__ (namedtuple does not
currently use it but could).
Regards
On Mon, Mar 14, 2011 at 6:43 AM, Éric Araujo wrote:
>> No, probably we should add some sort of __yes_i_am_public__ override
>> attribute that pydoc looks for. It's such a pity that those methods
>> have to have underscores...
>
> My opinion is that pydoc should use __dir__ (namedtuple does not
> c
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 03/14/2011 07:46 AM, Antoine Pitrou wrote:
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
On Mon, Mar 14, 2011 at 05:45, Nick Coghlan wrote:
> There are two relatively simple ways forward I can see:
>
> A. Add a __public__ attribute that pydoc (and import *) understand.
> This would overrride the default "this is private" detection and add
> affected names to the public list (without n
Nick Coghlan wrote:
True, but all those underscores are a PITA to type and read for
methods that are meant to be called directly.
Matter of taste, I suppose. I don't find them all that
bothersome, and a double underscore name stands out very
clearly as being part of the infrastructure rather t
On Tue, 15 Mar 2011 09:54:23 +1300, Greg Ewing
wrote:
> Nick Coghlan wrote:
>
> > True, but all those underscores are a PITA to type and read for
> > methods that are meant to be called directly.
>
> Matter of taste, I suppose. I don't find them all that
> bothersome, and a double underscore na
On Tue, Mar 15, 2011 at 9:48 AM, R. David Murray wrote:
> But directly calling a __xxx__ method in Python is a very
> unusual thing to do. It would be extremely odd to have that
> be the expected way to call a method on a class.
Can't namedtuple be improved to support the named fields _and_
have
On 3/14/2011 8:44 PM, James Mills wrote:
On Tue, Mar 15, 2011 at 9:48 AM, R. David Murray wrote:
But directly calling a __xxx__ method in Python is a very
unusual thing to do. It would be extremely odd to have that
be the expected way to call a method on a class.
Can't namedtuple be improved
On 3/14/2011 9:23 PM, Eric Smith wrote:
On 3/14/2011 8:44 PM, James Mills wrote:
On Tue, Mar 15, 2011 at 9:48 AM, R. David
Murray wrote:
But directly calling a __xxx__ method in Python is a very
unusual thing to do. It would be extremely odd to have that
be the expected way to call a method on
On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy wrote:
>> How would that work if you had a field named "replace"? I think
>> Raymond's current design is as good as it's going to get.
>
> 'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift
> the '_' from '_replace'. No gain. I
On 03/14/2011 10:02 PM, James Mills wrote:
On Tue, Mar 15, 2011 at 11:50 AM, Terry Reedy wrote:
How would that work if you had a field named "replace"? I think
Raymond's current design is as good as it's going to get.
'as_dict' is an unlikely fieldname. 're_place' is too, but that just shift
On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith wrote:
> The field names are not always under direct control of the developer, such
> as when they are database column names. Not that using _replace completely
> gets rid of this problem, but I agree with Raymond's decision that a field
> name can be an
On Mon, Mar 14, 2011 at 08:28, Tim Lesher wrote:
> On Mon, Mar 14, 2011 at 05:45, Nick Coghlan wrote:
>> There are two relatively simple ways forward I can see:
>>
>> A. Add a __public__ attribute that pydoc (and import *) understand.
>> This would overrride the default "this is private" detectio
On 15/03/2011 07:59, Nick Coghlan wrote:
On Tue, Mar 15, 2011 at 6:20 PM, Eric Smith wrote:
The field names are not always under direct control of the developer, such
as when they are database column names. Not that using _replace completely
gets rid of this problem, but I agree with Raymond's
On Tue, Mar 15, 2011 at 9:42 AM, Tim Lesher wrote:
> 2. Add a new class attribute that uses the same mechanism, with a
> different name (e.g., __api__).
> Pro: fairly easy to explain; because it doesn't share a name with
> __all__ its semantics can be tweaked without confusing people.
> Con: sligh
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 to the
>> *end* (as_dict_, replace_, make_) as is sometimes done
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, Mar 15, 2011 at 11:24, Antoine Pitrou wrote:
> Wouldn't a decorator be adequate?
>
> @pydoc.public_api
> def _asdict(self):
> """some docstring"""
> ...
That was my first attempt. Unfortunately, it didn't work well with
classmethods or immutable data members, and forci
On Tue, Mar 15, 2011 at 11:15, Nick Coghlan wrote:
> The challenge here is how it would interact with inheritance. pydoc
> couldn't use normal attribute lookup, it would have to walk the MRO
> manually, only applying __api__ to the specific class that defined it.
Great catch. I know pydoc already
On Tue, Mar 15, 2011 at 12:27 PM, Tim Lesher wrote:
> Overall, this is becoming more interesting than I'd thought at first.
> Is this something that should require a PEP?
Yeah, just to thrash out the semantics and give some visibility into
the design decisions.
Cheers,
Nick.
--
Nick Coghlan
One of simplest and least invasive ways to get help()
to show the underscore methods and attributes is to
make pydoc aware of named tuples by checking for the
presence of _fields.
* That leaves the named tuple code as simple as possible
(which is important because the self-documenting code
is e
On 3/15/2011 11:17 AM, 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 to the
*end* (as_dict_, r
Nick Coghlan wrote:
The challenge here is how it would interact with inheritance. pydoc
couldn't use normal attribute lookup, it would have to walk the MRO
manually,
This is an instance of a pattern that I've encountered a
few times in things that I've done: you have a class
attribute containi
Tim Lesher wrote:
Any test cases should definitely throw some diamond-pattern or even
more degenerate cases at the implementation. What *is* the worst case
for MRO complexity?
I don't think that's an issue -- the MRO gets flattened into
a list at class creation time, so code that walks it nev
On 15/03/2011 19:57, Greg Ewing wrote:
Nick Coghlan wrote:
The challenge here is how it would interact with inheritance. pydoc
couldn't use normal attribute lookup, it would have to walk the MRO
manually,
This is an instance of a pattern that I've encountered a
few times in things that I've d
35 matches
Mail list logo
