python typeerror: non-empty format string passed to object.__format__

Get code examples instantly right from your google search results with the Grepper Chrome Extension.

>>> bytes.__format__ is object.__format__
True
>>> '{:20}'.format(object())
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__

>>> '{!s:20s}'.format(b"Hi")
"b'Hi'               "
>>> '{!s:20s}'.format(object())
'<object object at 0x1100b9080>'

var = '{!s:20s}'.format(b "Hi")
print(var)

Hi

def fun():
   pass
x = fun()
print(x)
print('{:.0f}'.format(x))

TypeError: non - empty format string passed to object.__format__

#Python 3. x
   '{:10}'.format(b 'delftstack')

#Python 3.x
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-12-1909c614b7f5> in <module>()
----> 1 '{:10}'.format(b'delftstack')

TypeError: unsupported format string passed to bytes.__format__

#Python 3. x
b 'delftstack'

#Python 3. x
   '{:.0f}'.format(None)

images_name = '{}/{:03d}_image.jpg'.format(target, i)

format_str = '{}: Step {:d}, Loss = {:.2f} ({:.1f} examples/sec; {:.3f} sec/batch)'
print(format_str.format(datetime.now(), step,
   loss_value, examples_per_sec, duration))

@app.route("/sell", methods = ["GET", "POST"])
@login_required
def sell():
   ""
"Sell shares of stock."
""
if request.method == "POST":
   stock = lookup(request.form.get("symbol"))
if not stock:
   return apology("invalid symbol!")

stock_query = db.execute("SELECT stock_symbol FROM transactions WHERE user_id=:uid", uid = session["user_id"])
for i in range(len(stock_query)):
   if stock_query[i]["stock_symbol"] != stock["symbol"]:
   return apology("You don't have any shares of that stock!")

share_query = db.execute("SELECT no_of_shares FROM transactions WHERE user_id=:uid", uid = session["user_id"])
for i in range(len(share_query)):
   if share_query[i]["no_of_shares"] < int(request.form.get("shares")):
   return apology("You don't have enough shares of that stock for this!")

share_query = db.execute("SELECT no_of_shares FROM transactions WHERE user_id=:uid AND stock_symbol=:ssymbol", uid = session["user_id"], ssymbol = stock["symbol"])
if share_query[0]["no_of_shares"] - int(request.form.get("shares")) == 0:
   share_query = db.execute("DELETE FROM transactions WHERE user_id=:uid AND stock_symbol=:ssymbol", uid = session["user_id"], ssymbol = stock["symbol"])

user_cash = db.execute("SELECT cash FROM users WHERE id=:uid", uid = session["user_id"])
total_cash = user_cash[0]["cash"] + (stock["price"] * int(request.form.get("shares")))
update_query = db.execute("UPDATE users SET cash=:cash WHERE id=:uid", cash = total_cash, uid = session["user_id"])

return render_template("index.html")

elif request.method == "GET":
   return render_template("sell.html")

{% extends "layout.html" %}

{% block title %}
    Sell
{% endblock %}

{% block main %}
    <form action="{{ url_for('sell') }}" method="post">
        <fieldset>
            <div class="form-group">
                <input autocomplete="off" autofocus class="form-control" name="symbol" type="text" placeholder="Symbol"/>
            </div>
            <div class="form-group">
                <input autocomplete="off" autofocus class="form-control" name="shares" type="number" placeholder="Shares"/>
            </div>
            <div class="form-group">
                <button class="btn btn-default" type="submit">Sell</button>
            </div>
       </fieldset>
    </form>
{% endblock %}

{% extends "layout.html" %}

{% block title %}
    Portfolio
{% endblock %}

{% block main %}
    <table class="table table-striped">
        <thead>
            <tr>
                <th>Symbol</th>
                <th>Name</th>
                <th>Shares</th>
                <th>Price</th>
                <th>TOTAL</th>
            </tr>
        </thead>
        <tfoot>
            <tr>
                <td colspan="4"></td>
                <td><b>{{ "${:,.2f}".format(grand_total) }}</b></td>
            </tr>
        </tfoot>
        <tbody>
            {% for i in transactions_info %}
            <tr>
                <td>{{ i.stock_symbol }}</td>
                <td>{{ i.stock_name }}</td>
                <td>{{ i.no_of_shares }}</td>
                <td>{{ "${:,.2f}".format(i.stock_price) }}</td>
                <td>{{ "${:,.2f}".format(i.no_of_shares * i.stock_price) }}</td>
            {% endfor %}
            </tr>
            <tr>
                <td colspan="4">CASH</td>
                <td>{{ "${:,.2f}".format(users_info[0]["cash"]) }}</td>
            </tr>
        </tbody>
    </table>
{% endblock %}

$ python3 -c "'{0:s}'.format(b'qwe')"
Traceback (most recent call last):
  File "<string>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__

Spent many hours to detect bug in my code.

Bytes don 't support formatting codes, so they are passed through to object, which doesn'
t support any formatting codes, and produces the error message you see.Since all other built in types reject invalid codes with a message that mentions their type, I think bytes should too.This would change the message to:

   ValueError: Unknown format code 's'
for object of type 'bytes'

Would that have lessened your confusion sufficiently ?

Yes, I think we should implement this
for object.__format__.Marking as easy.

Here 's a patch. Changes in test_builtin might be redundant, but I added them anyway.

I left a comment on Rietveld, but repeating it here because for me those messages often go to spam:

I think you want to make this more general, by modifying the message for the TypeError that follows. Any type that doesn't provide it's own __format__ should produce an error when using a non-empty format string.

For example:

>>> format({}, 'a')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: non-empty format string passed to object.__format__

Would be better as:
TypeError: non-empty format string passed to __format__ for object of type "class <'dict'>"

(Or some prettier way to print out the type).

Background:

format(obj, fmt) eventually calls object.__format__(obj, fmt) if obj (or one of its bases) does not implement __format__. The behavior of object.__format__ is basically:

def __format__(self, fmt):
    return str(self).__format__(fmt)

So the caller of format() thought they were passing in a format string specific to obj, but it is interpreted as a format string for str.

This is not correct, or at least confusing. The format string is supposed to be type specific. However in this case the object is being changed (to type str), but the format string which was to be applied to its original type is now being passed to str.

This is an actual problem that occurred in the migration from 3.0 -> 3.1 and from 2.6 -> 2.7 with complex. In the earlier versions, complex did not have a __format__ method, but it does in the latter versions. So this code:
>>> format(1+1j, '10s')
'(1+1j)    '
worked in 2.6 and 3.0, but gives an error in 2.7 and 3.1:
>>> format(1+1j, '10s')
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: Unknown format code 's' for object of type 'complex'

Proposal:
object.__format__ should give an error if a non-empty format string is specified. In 2.7 and 3.2 make this a PendingDeprecationWarning, in 3.3 make it a DeprecationWarning, and in 3.4 make it an error.

Modify the documentation to make this behavior clear, and let the user know that if they want this behavior they should say:

format(str(obj), '10s')

or the equivalent:

"{0!s:10}".format(obj)

That is, the conversion to str should be explicit.

Proposed patch attached.I need to add tests and docs.

issue7994 - 0. diff is against trunk.

Patch with Misc / NEWS.

The patch looks reasonable.I built on it with the following changes:

   1. Added some extra test cases to cover Unicode format strings,
   since the code was changed to handle these as well.
2. Changed test_builtin.py by
s / m[0].message.message / str(w[0].message) / , since
BaseException.message was deprecated in 2.6.

I also have the following general comments:

   1. PEP 3101 explicitly defines the string conversion
for
object.__format__.What is the rationale behind this ? Should
we find out before making this change ?
   2. I don 't think the comments in '
abstract.c ' and '
typeobject.c '
explaining that the warning will eventually become an error are
needed.I think it would be better to open separate issues
for
these migration steps as they can be tracked easier and will be
more visible.
3. test_unicode, test_str have cases that trigger the added
warning.Should they be altered now or when(
   if) this becomes
an error ?

"The story of {0}, {1}, and {c}".format(a, b, c = d)

print(format(10.0, "7.3g"))

"My name is {0}".format('Fred')

"My name is {0} :-{{}}".format('Fred')

"My name is Fred :-{}"

David is correct.

It's often easiest to think about the builtin format() instead of str.format(). Notice below that the format specifier has to make sense for the object being formatted:

>>> import datetime
>>> now = datetime.datetime.now()

>>> format('somestring', '.12s')
'somestring '

# "works", but not what you want because it calls now.strftime('.12s'):
>>> format(now, '.12s')
'.12s'

# better:
>>> format(now, '%Y-%m-%d') # better
'2014-03-19'

# int doesn't know what '.12s' format spec means:
>>> format(3, '.12s')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
      ValueError: Unknown format code 's' for object of type 'int'

      # None doesn't have an __format__, so object.__format__ rejects it:
      >>> format(None, '.12s')
      Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
            TypeError: non-empty format string passed to object.__format__

            # just like a random class doesn't have an __format__:
            >>> class F: pass
            ...
            >>> format(F(), '.12s')
            Traceback (most recent call last):
            File "<stdin>", line 1, in <module>
                  TypeError: non-empty format string passed to object.__format__


                  Tangentially related:

                  The best you can do here, given your use case, is to argue that None needs an __format__ that understands str's format specifiers, because you like to mix str and None. But maybe someone else likes to mix int and None. Maybe None should understand int's format specifiers, and not str's:

                  >>> format(42000, ',d')
                  '42,000'
                  >>> format('42000', ',d')
                  Traceback (most recent call last):
                  File "<stdin>", line 1, in <module>
                        ValueError: Unknown format code 'd' for object of type 'str'

                        Why would "format(None, '.12s')" make any more sense than "format(None, ',d')"? Since we can't guess, we chose an error.

>>> bytes.__format__ is object.__format__
True
>>> '{:20}'.format(object())
Traceback (most recent call last):
  File "", line 1, in 
TypeError: non-empty format string passed to object.__format__

>>> '{!s:20s}'.format(b"Hi")
"b'Hi'               "
>>> '{!s:20s}'.format(object())
'