Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Python's core types are immutable by design, as other users have pointed out:</p> <pre><code>&gt;&gt;&gt; int.frobnicate = lambda self: whatever() Traceback (most recent call last): File "&lt;stdin&gt;", line 1, in &lt;module&gt; TypeError: can't set attributes of built-in/extension type 'int' </code></pre> <p>You certainly <em>could</em> achieve the effect you describe by making a subclass, since user-defined types in Python are mutable by default.</p> <pre><code>&gt;&gt;&gt; class MyInt(int): ... def frobnicate(self): ... print 'frobnicating %r' % self ... &gt;&gt;&gt; five = MyInt(5) &gt;&gt;&gt; five.frobnicate() frobnicating 5 &gt;&gt;&gt; five + 8 13 </code></pre> <p>There's no need to make the <code>MyInt</code> subclass public, either; one could just as well define it inline directly in the function or method that constructs the instance.</p> <p>There are certainly a few situations where Python programmers who are fluent in the idiom consider this sort of subclassing the right thing to do. For instance, <code>os.stat()</code> returns a <code>tuple</code> subclass that adds named members, precisely in order to address the sort of readability concern you refer to in your example.</p> <pre><code>&gt;&gt;&gt; import os &gt;&gt;&gt; st = os.stat('.') &gt;&gt;&gt; st (16877, 34996226, 65024L, 69, 1000, 1000, 4096, 1223697425, 1223699268, 1223699268) &gt;&gt;&gt; st[6] 4096 &gt;&gt;&gt; st.st_size 4096 </code></pre> <p>That said, in the specific example you give, I don't believe that subclassing <code>float</code> in <code>item.price</code> (or elsewhere) would be very likely to be considered the Pythonic thing to do. I <em>can</em> easily imagine somebody deciding to add a <code>price_should_equal()</code> method to <code>item</code> if that were the primary use case; if one were looking for something more general, perhaps it might make more sense to use named arguments to make the intended meaning clearer, as in</p> <pre><code>should_equal(observed=item.price, expected=19.99) </code></pre> <p>or something along those lines. It's a bit verbose, but no doubt it could be improved upon. A possible advantage to such an approach over Ruby-style monkey-patching is that <code>should_equal()</code> could easily perform its comparison on any type, not just <code>int</code> or <code>float</code>. But perhaps I'm getting too caught up in the details of the particular example that you happened to provide.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload