StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
10114654
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2012-04-11T22:06:35.663
FavoriteCount
0
LastActivityDate
2012-04-11T22:06:35.663
LastEditDate
LastEditorUserId
0
OwnerUserId
65696
ParentId
10113358
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
If I had to derive the reasoning from first principles, I might think about it in terms of the <a href="http://docs.python.org/reference/datamodel.html#slots" rel="nofollow"><code>__slots__</code></a> mechanism. Some kinds of classes only need a tiny number of attributes, and the set of attributes is always fixed for every instance, and so the flexibility of a "dict" like user attributes capability would be wasteful of cpu (looking up dynamically named attributes) and space (the overhead of an empty dict, small but non-zero), which can really add up to a lot of overhead if there are a large number of instances. of course this is exactly the problem the <code>__slots__</code> mechanism solves. space is allocated on the object for the attributes defined in slots. if there's a <code>__dict__</code> attribute, non-slot attributes can be found there, and if there's no <code>__dict__</code> attribute, you get neither the dynamic attributes nor the cost of the unneeded dict object (which is an additional heap object other than the instance itself). As for why <code>object</code> itself does not have a slot for <code>__dict__</code>, well, even if a subclass indicated that they didn't need the <code>__dict__</code> slot, if they inherit from a class that does, then the instance must still have a <code>__dict__</code>; if <code>object</code> had a <code>__dict__</code> then absolutely every class would also pay the price of having a <code>__dict__</code>, even if they didn't need it. Instead; subclasses get <code>__dict__</code> (and <code>__weakref__</code>, for analogous reasons) unless they themselves define a <code>__slots__</code> class attribute. And why would you need a plain-ol instance of <code>object</code> at all? Do you just need a bag of attributes? well then use a <code>dict</code>. If you actually need an object of some kind with behaviors and attributes, then you are making a subclass anyways. About the only reason I can ever imagine using <code>object()</code> instead of a subclass of <code>object</code>, is when the only feature of the instance that is of interest is its identity. This would come up when a function takes arguments, and for which <code>None</code> or some other obvious sentinel value should be understood as distinct from the default: <pre><code>BAR_DEFAULT = object() def foo(bar=BAR_DEFAULT): if bar is BAR_DEFAULT: #... </code></pre> In which case you neither need nor particularly want attributes on the instance of <code>object</code>, 
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POwhy 'object' class doesn't have user set attributes
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USSingleNegationElimination
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. POwhy 'object' class doesn't have user set attributes
 singulars
 PostTypePostTypeId
 PTQuestion
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
2. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTAcceptedByOriginator
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.