Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #61334 > unrolled thread

Re: interactive help on the base object

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: interactive help on the base object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-08 23:48 +0000
    Re: interactive help on the base object Denis McMahon <denismfmcmahon@gmail.com> - 2013-12-09 00:45 +0000
      Re: interactive help on the base object Mark Janssen <dreamingforward@gmail.com> - 2013-12-08 17:09 -0800
      Re: interactive help on the base object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-09 01:38 +0000
      Re: interactive help on the base object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-09 01:43 +0000
        Re: interactive help on the base object Steven D'Aprano <steve@pearwood.info> - 2013-12-09 02:31 +0000
          Re: interactive help on the base object Mark Janssen <dreamingforward@gmail.com> - 2013-12-08 18:41 -0800
            Re: interactive help on the base object rusi <rustompmody@gmail.com> - 2013-12-08 18:58 -0800
              Re: interactive help on the base object Steven D'Aprano <steve@pearwood.info> - 2013-12-09 04:16 +0000
                Re: interactive help on the base object rusi <rustompmody@gmail.com> - 2013-12-08 20:46 -0800
                  Re: interactive help on the base object rurpy@yahoo.com - 2013-12-08 21:26 -0800
                    Re: interactive help on the base object rusi <rustompmody@gmail.com> - 2013-12-08 22:44 -0800
                      Re: interactive help on the base object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-09 09:44 +0000
            Re: interactive help on the base object Steven D'Aprano <steve@pearwood.info> - 2013-12-09 05:44 +0000
              Re: interactive help on the base object Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2013-12-09 02:31 -0500
                Re: interactive help on the base object Chris Angelico <rosuav@gmail.com> - 2013-12-09 18:39 +1100
                  Re: interactive help on the base object Alan Bawden <alan@scooby-doo.csail.mit.edu> - 2013-12-10 00:34 -0500
                  Re: interactive help on the base object Chris Angelico <rosuav@gmail.com> - 2013-12-10 16:44 +1100
          Re: interactive help on the base object Chris Angelico <rosuav@gmail.com> - 2013-12-09 13:57 +1100
      Re: interactive help on the base object Terry Reedy <tjreedy@udel.edu> - 2013-12-09 00:00 -0500
      Re: interactive help on the base object Mark Lawrence <breamoreboy@yahoo.co.uk> - 2013-12-09 23:48 +0000
    Re: interactive help on the base object Steven D'Aprano <steve@pearwood.info> - 2013-12-09 01:58 +0000

Page 1 of 2  [1] 2  Next page →

#61334 — Re: interactive help on the base object

On 07/12/2013 01:35, Terry Reedy wrote:
> On 12/6/2013 12:03 PM, Mark Lawrence wrote:
>> Is it just me, or is this basically useless?
>>
>>  >>> help(object)
>> Help on class object in module builtins:
>>
>> class object
>>   |  The most base type
>
> Given that this can be interpreted as 'least desirable', it could
> definitely be improved.
>
>> Surely a few more words,
>
> How about something like.
>
> '''The default top superclass for all Python classes.
>
> Its methods are inherited by all classes unless overriden.
> '''
>
> When you have 1 or more concrete suggestions for the docstring, open a
> tracker issue.
>

Terry's suggestion above remains odds on favourite on the grounds that 
there have been no other suggestions.  I'll give it another day, then 
raise a tracker issue, unless the overwhelming smell of pot that has 
been drifting around this thread knocks me unconscious.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [next] | [standalone]

#61338

On Sun, 08 Dec 2013 23:48:57 +0000, Mark Lawrence wrote:

>>>  >>> help(object)
>>> Help on class object in module builtins:
>>>
>>> class object
>>>   |  The most base type

 
>> '''The default top superclass for all Python classes.
>> Its methods are inherited by all classes unless overriden.
>> '''

> Terry's suggestion above remains odds on favourite on the grounds that
> there have been no other suggestions.  I'll give it another day, then
> raise a tracker issue, unless the overwhelming smell of pot that has
> been drifting around this thread knocks me unconscious.

""" The root class for all Python classes. Its methods are inherited by 
all classes unless overriden. """

-- 
Denis McMahon, denismfmcmahon@gmail.com

[toc] | [prev] | [next] | [standalone]

#61339

>>>>  >>> help(object)
>>>> Help on class object in module builtins:
>>>>
>>>> class object
>>>>   |  The most base type
>
>>> '''The default top superclass for all Python classes.
>>> Its methods are inherited by all classes unless overriden.
>>> '''
>
> """ The root class for all Python classes. Its methods are inherited by
> all classes unless overriden. """

*sits back*.
-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#61340

On 09/12/2013 01:09, Mark Janssen wrote:
>>>>>   >>> help(object)
>>>>> Help on class object in module builtins:
>>>>>
>>>>> class object
>>>>>    |  The most base type
>>
>>>> '''The default top superclass for all Python classes.
>>>> Its methods are inherited by all classes unless overriden.
>>>> '''
>>
>> """ The root class for all Python classes. Its methods are inherited by
>> all classes unless overriden. """
>
> *sits back*.
>

Why?  If a newbie is encouraged, as everybody is, to use help at the 
interactive prompt, then surely them seeing "The most base type" when 
typing "help(object)" is of no use to them at all.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#61341

On 09/12/2013 00:45, Denis McMahon wrote:
> On Sun, 08 Dec 2013 23:48:57 +0000, Mark Lawrence wrote:
>
>>>>   >>> help(object)
>>>> Help on class object in module builtins:
>>>>
>>>> class object
>>>>    |  The most base type
>
>
>>> '''The default top superclass for all Python classes.
>>> Its methods are inherited by all classes unless overriden.
>>> '''
>
>> Terry's suggestion above remains odds on favourite on the grounds that
>> there have been no other suggestions.  I'll give it another day, then
>> raise a tracker issue, unless the overwhelming smell of pot that has
>> been drifting around this thread knocks me unconscious.
>
> """ The root class for all Python classes. Its methods are inherited by
> all classes unless overriden. """
>

Thanks Denis, you've reminded me why I asked in the first place.  What 
methods, if any does it provide?  Are they all abstract? etc??? 
Personally I'm not really interested, but a newbie might well be and 
hence might wonder what the hell is going on.  If and only if the 
situation can be improved I'll raise an issue, if not I'll quietly let 
it drop, and consider more important things, like why are Australia 
currently thrashing England at cricket? :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#61345

On Mon, 09 Dec 2013 01:43:43 +0000, Mark Lawrence wrote about object:

> What methods, if any does it provide?  Are they all abstract? etc???


Pretty much nothing useful :-)

py> dir(object)
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', 
'__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', 
'__subclasshook__']


What few methods there are typically do nothing, or nothing interesting. 
A few implement basic functionality, e.g. __eq__ performs equality based 
on identity (an object is equal to itself and nothing else).



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#61347

>> What methods, if any does it provide?  Are they all abstract? etc???
>
> Pretty much nothing useful :-)
>
> py> dir(object)
> [...]
>

So (prodding the student), Why does everything inherit from Object if
it provides no functionality?

Practicality-beats-purity-yours?

-- 
MarkJ
Tacoma, Washington

[toc] | [prev] | [next] | [standalone]

#61350

On Monday, December 9, 2013 8:11:47 AM UTC+5:30, zipher wrote:
> >> What methods, if any does it provide?  Are they all abstract? etc???
> > Pretty much nothing useful :-)
> > py> dir(object)
> > [...]

> So (prodding the student), Why does everything inherit from Object if
> it provides no functionality?

Thats right.  What does a collection object like [] or the empty set ∅
(assuming the unicode-gods will allow and bless that) do when it
collects nothing?  Lets make sure all lists and sets start non-empty.

And why have a stupid number like 0 when it counts nothing?
Lets go back to roman numerals which is so much more…


> Practicality-beats-purity-yours?

Practical!!⸮¿¡

PS Can some kind soul inform me whether I could convince GG to unicode my post?

[toc] | [prev] | [next] | [standalone]

#61355

On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote:


> PS Can some kind soul inform me whether I could convince GG to unicode
> my post?

Does GG not give you some way of inspecting the post's full headers?

Anyway, here you go:

Content-Type: text/plain; charset=UTF-8


Your plan succeeded.

Personally, I wouldn't stress too much about this. While it would be 
nice, and desirable, for GG to always use UTF-8 instead of picking a 
different encoding based on the phase of the moon, the main thing is that 
it picks a valid encoding. So far I see no reason to accuse GG of using 
an invalid encoding. Valid but legacy encodings are better than 
mojibake :-)


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#61356

Thanks for the info.

On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote:
> On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote:

> > PS Can some kind soul inform me whether I could convince GG to unicode
> > my post?

> Does GG not give you some way of inspecting the post's full headers?

Well I spent half hour looking around -- both inside GG and of course
searching before asking.

> Anyway, here you go:

> Content-Type: text/plain; charset=UTF-8

> Your plan succeeded.

> Personally, I wouldn't stress too much about this. While it would be 
> nice, and desirable, for GG to always use UTF-8 instead of picking a 
> different encoding based on the phase of the moon, the main thing is that 
> it picks a valid encoding. So far I see no reason to accuse GG of using 
> an invalid encoding. Valid but legacy encodings are better than 
> mojibake :-)

Heh! I'm hardly a heavy-duty user of unicode -- just keeping track of bugs 
and workarounds. I am of course using 'bug' in a wide pragmatic sense of
preventing communication.

Mojibake is a technical problem.
Non (human) communication is a more fundamental problem.
Keeping an eye on the latter is (for me) a bigger issue than the former.

[toc] | [prev] | [next] | [standalone]

#61363

On 12/08/2013 09:46 PM, rusi wrote:
> On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote:
>> On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote:
>[...]
>> Does GG not give you some way of inspecting the post's full headers?
> 
> Well I spent half hour looking around -- both inside GG and of course
> searching before asking.

If you click on the little "down" triangle to the right
of the "reply" button for a message, you'll get a menu
that includes "Show Original".  You can see the headers
including the "Content-Type:" in that original.

Of course this means you have to post first and find out 
after...

[toc] | [prev] | [next] | [standalone]

#61365

On Monday, December 9, 2013 10:56:28 AM UTC+5:30, ru...@yahoo.com wrote:
> On 12/08/2013 09:46 PM, rusi wrote:
> > On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote:
> >> On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote:
> >[...]
> >> Does GG not give you some way of inspecting the post's full headers?
> > Well I spent half hour looking around -- both inside GG and of course
> > searching before asking.

> If you click on the little "down" triangle to the right
> of the "reply" button for a message, you'll get a menu
> that includes "Show Original".  You can see the headers
> including the "Content-Type:" in that original.

Thanks rurpy -- I only looked for how one may set and not just what is.

So now I look at my own post in GG and see

Content-Type: text/plain; charset=UTF-8

So far so good.

However when I point firefox at my own post in the archive
https://mail.python.org/pipermail/python-list/2013-December/662015.html

firefox shows encoding as Windows-1252.

Note Ive looked at a dozen random pages and for all FF shows encoding as
utf-8 except the python list archive ones which show as Win 1252

Note looking into the html I see
<META http-equiv="Content-Type" content="text/html; charset=us-ascii">

How us-ascii becomes Win-1252 is outside the reach of my meagre intelligence!

Though I still suspect something is not quite right with the python
mailing-list and/or archive in respect of char encodings.

[Am I beginning to sound like jmf is my guru :-) ]

[toc] | [prev] | [next] | [standalone]

#61376

On 09/12/2013 06:44, rusi wrote:
> On Monday, December 9, 2013 10:56:28 AM UTC+5:30, ru...@yahoo.com wrote:
>> On 12/08/2013 09:46 PM, rusi wrote:
>>> On Monday, December 9, 2013 9:46:30 AM UTC+5:30, Steven D'Aprano wrote:
>>>> On Sun, 08 Dec 2013 18:58:09 -0800, rusi wrote:
>>> [...]
>>>> Does GG not give you some way of inspecting the post's full headers?
>>> Well I spent half hour looking around -- both inside GG and of course
>>> searching before asking.
>
>> If you click on the little "down" triangle to the right
>> of the "reply" button for a message, you'll get a menu
>> that includes "Show Original".  You can see the headers
>> including the "Content-Type:" in that original.
>
> Thanks rurpy -- I only looked for how one may set and not just what is.
>
> So now I look at my own post in GG and see
>
> Content-Type: text/plain; charset=UTF-8
>
> So far so good.
>
> However when I point firefox at my own post in the archive
> https://mail.python.org/pipermail/python-list/2013-December/662015.html
>
> firefox shows encoding as Windows-1252.
>
> Note Ive looked at a dozen random pages and for all FF shows encoding as
> utf-8 except the python list archive ones which show as Win 1252
>
> Note looking into the html I see
> <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
>
> How us-ascii becomes Win-1252 is outside the reach of my meagre intelligence!
>
> Though I still suspect something is not quite right with the python
> mailing-list and/or archive in respect of char encodings.
>
> [Am I beginning to sound like jmf is my guru :-) ]
>

I'd mention that I never seem to have a problem using Thunderbird on 
Windows 7, but I won't as I don't want to be accused of bullying, hating 
GG, or whatever.  Doh!!! :)

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#61364

On Sun, 08 Dec 2013 18:41:47 -0800, Mark Janssen wrote:

>>> What methods, if any does it provide?  Are they all abstract? etc???
>>
>> Pretty much nothing useful :-)
>>
>> py> dir(object)
>> [...]
>>
>>
> So (prodding the student), Why does everything inherit from Object if it
> provides no functionality?

You cut out the part of my post where I explained that object does in 
fact provide a minimal set of useful functionality. The example I gave 
was __eq__ (equal), but there is also __ne__ (not equal), __hash__ 
(hashing), __str__ and __repr__ (although many classes will wish to 
override them) and a few more. They're useful, even necessary, but hardly 
exciting.

The other reasons for inheriting from object include:

- If all classes are part of a single hierarchy, it must logically end at 
one (or more, if you support multiple inheritance, which Python does) 
bases classes. (Unless there are loops, which are generally prohibited in 
all OOP systems I know of). The simplest way to do this is with a single 
base class.

- Pragmatism: it was the easiest way to unify types and classes way back 
in Python 2.2, prior to which there was no single hierarchy and all 
classes were (in a sense) distinct.

Pedants will of course realise that Python 2 has *two* object 
hierarchies, classic classes which don't share a base class, and types 
(a.k.a. "new style classes") which do. In Python 3, classic classes are 
gone, and there is a single class hierarchy with object the base.


There may be other reasons.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#61366

Steven D'Aprano <steve@pearwood.info> writes:

> - If all classes are part of a single hierarchy, it must logically end at 
> one (or more, if you support multiple inheritance, which Python does) 
> bases classes. (Unless there are loops, which are generally prohibited in 
> all OOP systems I know of). The simplest way to do this is with a single 
> base class.

The original Lisp Machine "Flavors" system (one of the ancestors of the
Common Lisp Object System) allowed inheritance to be an arbitrary
directed graph -- possibly with cycles.

I don't believe that this was done for any deep principled reason, but
rather it was just permitted because the algorithm for computing method
resolution order didn't actually care whether there were inheritance
cycles -- it still terminated and returned an ordered list of component
classes.

I do not remember seeing any code that made use of this ability, so
don't ask me if it was good for anything, but it was definitely there...

-- 
Alan Bawden

[toc] | [prev] | [next] | [standalone]

#61368

On Mon, Dec 9, 2013 at 6:31 PM, Alan Bawden
<alan@scooby-doo.csail.mit.edu> wrote:
> I don't believe that this was done for any deep principled reason, but
> rather it was just permitted because the algorithm for computing method
> resolution order didn't actually care whether there were inheritance
> cycles -- it still terminated and returned an ordered list of component
> classes.

How does that work, exactly? How do you have a class inherit
(ultimately) from itself, and how does that impact the component class
list?

ChrisA

[toc] | [prev] | [next] | [standalone]

#61445

Chris Angelico <rosuav@gmail.com> writes:
> How does that work, exactly? How do you have a class inherit
> (ultimately) from itself, and how does that impact the component class
> list?

How does it work "exactly"?  You're asking me about a feature I never
made use of, in a system I have no source for, and that I haven't used
in over 25 years!  If it wasn't mentioned in a parenthetical comment in
the 32-year-old documentation I still have on my bookshelf (Lisp Machine
Manual, 4th edition, July 1981, blue cover), I wouldn't trust my own
memory that such a thing ever even existed.

So you're not getting anything "exact" here!

I have no idea exactly how it worked, but imagine something that walked
the superclass graph _as_ _if_ it was a tree, collected classes in some
order, and that just skips any class it encounters for the second time.
That results in _some_ linear ordering of all the classes you can reach
from the starting class.  Now use that.

Now the results aren't going to be very good by modern standards.  As
the Common Lisp Object System, Dylan, Python, and others, have all
discovered, you really want something that is at _least_ a topological
sort of the superclass graph -- and there is no topological sort at all
unless your superclass graph is acyclic.

But even if the results aren't up to modern standards, you can write a
hell of a lot of code before the deficiencies have hurt enough people
enough times to motivate you to do better.  After all modern Python
classes didn't start using their current ordering until Python 2.3.

-- 
Alan Bawden

[toc] | [prev] | [next] | [standalone]

#61446

On Tue, Dec 10, 2013 at 4:27 PM, Alan Bawden
<alan@scooby-doo.csail.mit.edu> wrote:
> Chris Angelico <rosuav@gmail.com> writes:
>
>> On Mon, Dec 9, 2013 at 6:31 PM, Alan Bawden
>> ...
>> How does that work, exactly? How do you have a class inherit
>> (ultimately) from itself, and how does that impact the component class
>> list?
>
> How does it work "exactly"?  You're asking me about a feature I never
> made use of, in a system I have no source for, and that I haven't used
> in over 25 years!  If it wasn't mentioned in a parenthetical comment in
> the 32-year-old documentation I still have on my bookshelf (Lisp Machine
> Manual, 4th edition, July 1981, blue cover), I wouldn't trust my own
> memory that such a thing ever even existed.
>
> So you're not getting anything "exact" here!

LOL!

> I have no idea exactly how it worked, but imagine something that walked
> the superclass graph _as_ _if_ it was a tree, collected classes in some
> order, and that just skips any class it encounters for the second time.
> That results in _some_ linear ordering of all the classes you can reach
> from the starting class.  Now use that.

Ow, that sounds a bit... weird. I think I prefer an acyclic graph for
inheritance! A few weirdnesses are necessary for bootstrapping -
type(object) is type, type(type) is type, and type.__bases__ =
(object,) - but normally every type should be created before all
instances of it, and every superclass before all its subclasses.

But of course, *multiple* inheritance is always weird. I've worked in
some detail with four systems (C++, Python, Pike, Java), and they're
all quite different in how they handle MI. Java says "There is no
MI... but you can implement multiple interfaces". C++ says "There is
MI and there is virtual MI, and if one of them doesn't do your head
in, the other will". Python says "It's all about method resolution,
instance data is separate, so make sure everything cooperates". Pike
says "If both parents define a method, super() will return an array of
methods, but that's okay because arrays are callable". It's a
fundamentally tricky problem, largely because every real-world analogy
we can muster is going to end up looking more like composition than
inheritance (a guided missile is-a bomb and is-a rocket, but it's just
as valid to say it is-a rocket and it has-a bomb).

ChrisA

[toc] | [prev] | [next] | [standalone]

#61349

On Mon, Dec 9, 2013 at 1:41 PM, Mark Janssen <dreamingforward@gmail.com> wrote:
>>> What methods, if any does it provide?  Are they all abstract? etc???
>>
>> Pretty much nothing useful :-)
>>
>> py> dir(object)
>> [...]
>>
>
> So (prodding the student), Why does everything inherit from Object if
> it provides no functionality?
>
> Practicality-beats-purity-yours?

Nothing useful to call directly. An int has some useful methods in Python:

>>> (258).to_bytes(2,"little")
b'\x02\x01'

So does a list:

>>> [1,4,1,5,9].count(1)
2

But there's nothing you'd normally want to call from object itself
(except maybe __repr__). There *are*, however, important pieces of
default functionality. Steven mentioned __eq__, and there's also its
pair __hash__. The default system works because the root type provides
implementations of those two functions:

>>> a = object()
>>> b = object()
>>> a == b
False
>>> d = {a:"A", b:"B"}
>>> d[a]
'A'

And it's important that these sorts of things work, because otherwise
a simple Python class would look like this:

class Foo:
    def __new__(self): pass
    def __init__(self): pass
    def __hash__(self): return id(self)
    def __eq__(self, other): return self is other
    # ...

This repetition is exactly what inheritance is good at solving.
Therefore putting that functionality into a base class makes sense;
and since everything MUST have these functions to be able to be used
plausibly, putting them in the lowest base class of all makes the most
sense.

ChrisA

[toc] | [prev] | [next] | [standalone]

#61357

On 12/8/2013 8:43 PM, Mark Lawrence wrote:
> On 09/12/2013 00:45, Denis McMahon wrote:
>> On Sun, 08 Dec 2013 23:48:57 +0000, Mark Lawrence wrote:
>>
>>>>>   >>> help(object)
>>>>> Help on class object in module builtins:
>>>>>
>>>>> class object
>>>>>    |  The most base type
>>
>>
>>>> '''The default top superclass for all Python classes.
>>>> Its methods are inherited by all classes unless overriden.
>>>> '''

I said 'top' instead of 'bottom' or 'base' to loosen up thinking a bit. 
I did not expect Mark to make a mound out of that flip.

>>> Terry's suggestion above remains odds on favourite on the grounds that
>>> there have been no other suggestions.  I'll give it another day, then
>>> raise a tracker issue, unless the overwhelming smell of pot that has
>>> been drifting around this thread knocks me unconscious.
>>
>> """ The root class for all Python classes. Its methods are inherited by
>> all classes unless overriden. """

'Root' is even better, since it does not depend on whether a tree is 
drawn up or down. Thanks.

> Thanks Denis, you've reminded me why I asked in the first place.  What
> methods, if any does it provide?

Good question.
 >>> dir(object)
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', 
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', 
'__init__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', 
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', 
'__subclasshook__']

>  Are they all abstract? etc???

No.

> Personally I'm not really interested, but a newbie might well be and
> hence might wonder what the hell is going on.

For everything else, help lists the special name methods directly 
associated with the object, along with docstrings.

 >>> help(C)
Help on class C in module __main__:

class C(builtins.object)
  |  Data descriptors defined here:
  |
  |  __dict__
  |      dictionary for instance variables (if defined)
  |
  |  __weakref__
  |      list of weak references to the object (if defined)

I think help should do the same for object

 >>> object.__hash__.__doc__
'x.__hash__() <==> hash(x)'

is equivalent to

  | __abs__(...)
  |      x.__abs__() <==> abs(x)

etc printed for help(int)

The fact that __dict__ does not exist for object but is only added for 
subclasses explains why one must subclass object to get instances that 
allow attributes.

 >>> o = object()
 >>> o.a = 1
Traceback (most recent call last):
   File "<pyshell#8>", line 1, in <module>
     o.a = 1
AttributeError: 'object' object has no attribute 'a'
 >>> c = C()
 >>> c.a=1

> If and only if the
> situation can be improved I'll raise an issue

I think it can be. If you prefer me to open the issue, say so.
We should look for existing issues, and closed issues that rejected change.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web