FAQ
Is it bad practice to use this
logger.error(self.preset_file + ' could not be stored - ' +
sys.exc_info()[1])
Instead of this?
logger.error('{file} could not be stored -
{error}'.format(file=self.preset_file, error=sys.exc_info()[1]))

Other than the case where a variable isn't a string (format() converts
variables to strings, automatically, right?) and when a variable is used
a bunch of times, concatenation is fine, but somehow, it seems wrong.
Sorry if this seems a bit silly, but I'm a novice when it comes to
design. Plus, there's not really supposed to be "more than one way to do
it" in Python.

Search Discussions

  • John Gordon at Jul 8, 2011 at 8:23 pm

    In <mailman.785.1310156331.1164.python-list at python.org> Andrew Berg <bahamutzero8825 at gmail.com> writes:

    Is it bad practice to use this
    logger.error(self.preset_file + ' could not be stored - ' +
    sys.exc_info()[1])
    Instead of this?
    logger.error('{file} could not be stored -
    {error}'.format(file=self.preset_file, error=sys.exc_info()[1]))
    Other than the case where a variable isn't a string (format() converts
    variables to strings, automatically, right?) and when a variable is used
    a bunch of times, concatenation is fine, but somehow, it seems wrong.
    Sorry if this seems a bit silly, but I'm a novice when it comes to
    design. Plus, there's not really supposed to be "more than one way to do
    it" in Python.
    Concatenation feels ugly/clunky to me.

    I prefer this usage:

    logger.error('%s could not be stored - %s' % \
    (self.preset_file, sys.exc_info()[1]))

    --
    John Gordon A is for Amy, who fell down the stairs
    gordon at panix.com B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
  • Ben Finney at Jul 8, 2011 at 10:50 pm

    John Gordon <gordon at panix.com> writes:

    I prefer this usage:

    logger.error('%s could not be stored - %s' % \
    (self.preset_file, sys.exc_info()[1]))
    That can be improved by learning two things:

    * The backslash-linebreak is ugly and fragile, and almost never needed,
    since Python knows to continue a statement if any bracketing syntax
    (parens, brackets, braces, triple quotes, etc.) is still open.

    So you can continue a statement over multiple lines by introducing
    some bracketing syntax at an appropriate place. In this case, you
    don't even need to add any bracketing syntax, since the function
    parens are still open.

    * The ?%? string formatting operator is superseded in current Python
    versions by the more flexible ?format? method of string objects.

    So:

    logger.error(
    '{0} could not be stored - {1}'.format(
    (self.preset_file, sys.exc_info()[1]))

    I usually prefer to use named placeholders instead of positional, but
    this duplicates your original.

    --
    \ ?We have clumsy, sputtering, inefficient brains?. It is a |
    `\ *struggle* to be rational and objective, and failures are not |
    _o__) evidence for an alternative reality.? ?Paul Z. Myers, 2010-10-14 |
    Ben Finney
  • Dan Stromberg at Jul 8, 2011 at 11:02 pm

    On Fri, Jul 8, 2011 at 3:50 PM, Ben Finney wrote:

    * The ?%? string formatting operator is superseded in current Python
    versions by the more flexible ?format? method of string objects.
    AFAIK, % formatting is the only kind of formatting that works portably
    across all of CPythons 2.5, 2.6, 2.7, 3.0, 3.1, 3.2; Pypy and Jython.

    So I'm still writing new code using %.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110708/84222ff3/attachment.html>
  • Ben Finney at Jul 8, 2011 at 11:15 pm

    Ben Finney <ben+python at benfinney.id.au> writes:

    logger.error(
    '{0} could not be stored - {1}'.format(
    (self.preset_file, sys.exc_info()[1]))

    I usually prefer to use named placeholders instead of positional, but
    this duplicates your original.
    Ah, I see that the OP *did* use named placeholders. So, even better:

    logger.error(
    '{file} could not be stored - {error}'.format(
    file=self.preset_file, error=sys.exc_info()[1]))

    --
    \ ?Those who write software only for pay should go hurt some |
    `\ other field.? ?Erik Naggum, in _gnu.misc.discuss_ |
    _o__) |
    Ben Finney
  • Thorsten Kampe at Jul 9, 2011 at 4:23 am
    * John Gordon (Fri, 8 Jul 2011 20:23:52 +0000 (UTC))
    I prefer this usage:

    logger.error('%s could not be stored - %s' % \
    (self.preset_file, sys.exc_info()[1]))
    The syntax for formatting logging messages according to the
    documentation is:

    Logger.error(msg, *args)

    NOT

    Logger.error(msg % (*args))

    Thorsten
  • Andrew Berg at Jul 10, 2011 at 6:45 am
    How should I go about switching from concatenation to string formatting
    for this?

    avs.write(demux_filter + field_filter + fpsin_filter + i2pfilter +
    dn_filter + fpsout_filter + trim_filter + info_filter)

    I can think of a few ways, but none of them are pretty.

    - --
    CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
  • Steven D'Aprano at Jul 10, 2011 at 1:42 pm

    Andrew Berg wrote:

    How should I go about switching from concatenation to string formatting
    for this?

    avs.write(demux_filter + field_filter + fpsin_filter + i2pfilter +
    dn_filter + fpsout_filter + trim_filter + info_filter)

    I can think of a few ways, but none of them are pretty.
    fields = (demux_filter, field_filter, fpsin_filter, i2pfilter,
    dn_filter, fpsout_filter, trim_filter, info_filter)
    avs.write("%s"*len(fields) % fields)

    works for me.




    --
    Steven
  • Roy Smith at Jul 10, 2011 at 2:33 pm
    In article <mailman.828.1310280324.1164.python-list at python.org>,
    Andrew Berg wrote:
    How should I go about switching from concatenation to string formatting
    for this?

    avs.write(demux_filter + field_filter + fpsin_filter + i2pfilter +
    dn_filter + fpsout_filter + trim_filter + info_filter)

    I can think of a few ways, but none of them are pretty.
    The canonical way to do that would be something like

    fields = [demux_filter,
    field_filter,
    fpsin_filter,
    i2pfilter,
    dn_filter,
    fpsout_filter,
    trim_filter,
    info_filter]
    avs.write(''.join(fields))
  • Steven D'Aprano at Jul 10, 2011 at 10:48 pm

    Roy Smith wrote:

    The canonical way to do that would be something like

    fields = [demux_filter,
    field_filter,
    fpsin_filter,
    i2pfilter,
    dn_filter,
    fpsout_filter,
    trim_filter,
    info_filter]
    avs.write(''.join(fields))
    I can't believe I didn't think of that. I must be getting sick. (The sore
    throat, stuffy nose and puffy eyes may also be a sign.)

    Yes, ''.join() is far to be preferred over my solution using "%s".



    --
    Steven
  • Andrew Berg at Jul 10, 2011 at 11:24 pm

    On 2011.07.10 09:33 AM, Roy Smith wrote:
    The canonical way to do that would be something like

    fields = [demux_filter, field_filter, fpsin_filter, i2pfilter,
    dn_filter, fpsout_filter, trim_filter, info_filter]
    avs.write(''.join(fields))
    That would look really awful (IMO) if the strings weren't intended to be
    on separate lines (I use embedded newlines instead of joining them with
    newlines in order to prevent blank lines whenever a certain filter isn't
    used). In this particular case, they are, so even though it uses a lot
    of whitespace, it does match the layout of its output.

    - --
    CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
  • Billy Mays at Jul 8, 2011 at 8:57 pm

    On 07/08/2011 04:18 PM, Andrew Berg wrote:
    Is it bad practice to use this
    logger.error(self.preset_file + ' could not be stored - ' +
    sys.exc_info()[1])
    Instead of this?
    logger.error('{file} could not be stored -
    {error}'.format(file=self.preset_file, error=sys.exc_info()[1]))

    Other than the case where a variable isn't a string (format() converts
    variables to strings, automatically, right?) and when a variable is used
    a bunch of times, concatenation is fine, but somehow, it seems wrong.
    Sorry if this seems a bit silly, but I'm a novice when it comes to
    design. Plus, there's not really supposed to be "more than one way to do
    it" in Python.
    If it means anything, I think concatenation is faster.

    __TIMES__
    a() - 0.09s
    b() - 0.09s
    c() - 54.80s
    d() - 5.50s

    Code is below:

    def a(v):
    out = ""
    for i in xrange(1000000):
    out += v
    return len(out)

    def b(v):
    out = ""
    for i in xrange(100000):
    out += v+v+v+v+v+v+v+v+v+v
    return len(out)

    def c(v):
    out = ""
    for i in xrange(1000000):
    out = "%s%s" % (out, v)
    return len(out)

    def d(v):
    out = ""
    for i in xrange(100000):
    out = "%s%s%s%s%s%s%s%s%s%s%s" % (out,v,v,v,v,v,v,v,v,v,v)
    return len(out)

    print "a", a('xxxxxxxxxx')
    print "b", b('xxxxxxxxxx')
    print "c", c('xxxxxxxxxx')
    print "d", d('xxxxxxxxxx')

    import profile

    profile.run("a('xxxxxxxxxx')")
    profile.run("b('xxxxxxxxxx')")
    profile.run("c('xxxxxxxxxx')")
    profile.run("d('xxxxxxxxxx')")
  • Steven D'Aprano at Jul 9, 2011 at 5:30 am

    Billy Mays wrote:

    If it means anything, I think concatenation is faster.
    You are measuring the speed of an implementation-specific optimization.
    You'll likely get *very* different results with Jython or IronPython, or
    old versions of CPython, or even if you use instance attributes instead of
    local variables.

    It also doesn't generalise: only appends are optimized, not prepends.

    Worse, the optimization can be defeated by accidents of your operating
    system's memory management, so code that runs snappily and fast on one
    machine will run SLLLOOOOOOWWWWWWWWWWWWWWWLY on another.

    This is not a hypothetical risk. People have been burned by this in real
    life:

    http://www.gossamer-threads.com/lists/python/dev/771948

    If you're interested in learning about the optimization:

    http://utcc.utoronto.ca/~cks/space/blog/python/ExaminingStringConcatOpt




    --
    Steven
  • Ian Kelly at Jul 9, 2011 at 6:04 am

    On Fri, Jul 8, 2011 at 11:30 PM, Steven D'Aprano wrote:
    Billy Mays wrote:
    If it means anything, I think concatenation is faster.
    You are measuring the speed of an implementation-specific optimization.
    You'll likely get *very* different results with Jython or IronPython, or
    old versions of CPython, or even if you use instance attributes instead of
    local variables.

    It also doesn't generalise: only appends are optimized, not prepends.
    Indeed:

    $ python -m timeit -s "v = 'x' * 10; out = ''" "out = out + v"
    1000000 loops, best of 3: 6.59 usec per loop

    $ python -m timeit -s "v = 'x' * 10; out = ''" "out = v + out"
    100000 loops, best of 3: 268 usec per loop

    Good to know. I had no idea such an optimization existed.

    Cheers,
    Ian
  • Chris Angelico at Jul 9, 2011 at 6:16 am

    On Sat, Jul 9, 2011 at 3:30 PM, Steven D'Aprano wrote:
    It also doesn't generalise: only appends are optimized, not prepends.

    If you're interested in learning about the optimization:

    http://utcc.utoronto.ca/~cks/space/blog/python/ExaminingStringConcatOpt
    From that page:
    "Also, this is only for plain (byte) strings, not for Unicode strings;
    as of Python 2.4.2, Unicode string concatenation remains
    un-optimized."

    Has the same optimization been implemented for Unicode? The page
    doesn't mention Python 3 at all, and I would guess that the realloc
    optimization would work fine for both types of string.

    ChrisA
  • Ian Kelly at Jul 9, 2011 at 6:29 am

    On Sat, Jul 9, 2011 at 12:16 AM, Chris Angelico wrote:
    Has the same optimization been implemented for Unicode? The page
    doesn't mention Python 3 at all, and I would guess that the realloc
    optimization would work fine for both types of string.
    Seems to be implemented for strs in 3.2, but not unicode in 2.7.
  • Benjamin Kaplan at Jul 8, 2011 at 9:23 pm

    On Fri, Jul 8, 2011 at 1:18 PM, Andrew Berg wrote:

    Is it bad practice to use this
    logger.error(self.preset_file + ' could not be stored - ' +
    sys.exc_info()[1])
    Instead of this?
    logger.error('{file} could not be stored -
    {error}'.format(file=self.preset_file, error=sys.exc_info()[1]))

    Other than the case where a variable isn't a string (format() converts
    variables to strings, automatically, right?) and when a variable is used
    a bunch of times, concatenation is fine, but somehow, it seems wrong.
    Sorry if this seems a bit silly, but I'm a novice when it comes to
    design. Plus, there's not really supposed to be "more than one way to do
    it" in Python.
    String formatting is the One Right Way here. It's fine to use string
    concatenation for a few things, but the operation is O(n^2) because each
    concat occurs one at a time: Python allocates space for a string the size of
    the first 2 things, copies the contents over. Then allocate a string the
    size of that string plus the third string and copy the contents over. It can
    get pretty slow if you're building a really big string With string
    formatting, Python creates a single string large enough to copy all the
    formatting arguements in and then copies the contents over once.

    Also, string formatting (especially using the new syntax like you are) is
    much clearer because there's less noise (the quotes all over the place and
    the plusses) and it's better for dealing with internationalization if you
    need to do that.
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: <http://mail.python.org/pipermail/python-list/attachments/20110708/34b35b52/attachment.html>
  • Ian Kelly at Jul 8, 2011 at 9:38 pm

    On Fri, Jul 8, 2011 at 3:23 PM, Benjamin Kaplan wrote:
    String formatting is the One Right Way here.?It's fine to use string
    concatenation for a few things, but?the operation is O(n^2) because each
    concat occurs?one at a time: Python allocates space for a string the size of
    the first 2 things, copies the contents over. Then?allocate a string the
    size of that string plus the third string and copy the contents over. It can
    get pretty slow if you're building a really big string?With string
    formatting, Python?creates a single string large enough to copy all?the
    formatting arguements in and then copies?the contents over once.
    This argument doesn't really fly, because a string formatting
    operation is typically used as an alternative for a constant number of
    concatenations, not O(n) concatenations. As such, either approach
    would be O(n) for a single instance.

    In the case that you do need to do O(n) concatenations, it is usually
    best to use a StringIO object, or to build a list and then call
    str.join.
    Also, string formatting (especially using the new syntax like you are) is
    much clearer because there's less noise (the quotes all over the place and
    the plusses) and?it's better for dealing with internationalization if you
    need to do that.
    This is the real reason to prefer string formatting over
    concatenation. It's also much less clutter to be able to use the %s
    placeholder rather than having to call str() on everything.
  • Ben Finney at Jul 8, 2011 at 10:59 pm

    Andrew Berg <bahamutzero8825 at gmail.com> writes:

    Is it bad practice to use this
    logger.error(self.preset_file + ' could not be stored - ' +
    sys.exc_info()[1])
    This is not necessarily bad practice, but there are not many points in
    its favour. It's inflexible and makes the eventual formatting harder to
    discern.
    Instead of this?
    logger.error('{file} could not be stored -
    {error}'.format(file=self.preset_file, error=sys.exc_info()[1]))
    With the caveat that the formatting of that line should be using PEP 8
    indentation for clarity:

    logger.error(
    '{file} could not be stored - {error}'.format(
    file=self.preset_file, error=sys.exc_info()[1]))
    Other than the case where a variable isn't a string (format() converts
    variables to strings, automatically, right?)
    If you don't specify a conversion in the placeholder, it will default to
    ?str?, yes.
    and when a variable is used a bunch of times, concatenation is fine,
    I don't see any argument for concatenation there; using a variable a
    bunch of times works just fine with the ?format? method.
    but somehow, it seems wrong. Sorry if this seems a bit silly, but I'm
    a novice when it comes to design. Plus, there's not really supposed to
    be "more than one way to do it" in Python.
    There is often more than one way to do it. The Zen of Python is explicit
    that there should be one obvious way to do it (and preferably only one).

    The ?OOW? in ?TOOWTDI? is not ?only one way?, but ?one obvious way?.

    The presence of multiple ways to format strings (the ?%? operator, the
    ?format? method) is for backward compatibility with code written before
    the current recommended ?format? method.

    Backward compatibility is a common reason for more than one way to do it
    in Python. It's just preferable that all but one of them should be
    non-obvious :-)

    --
    \ ?The whole area of [treating source code as intellectual |
    `\ property] is almost assuring a customer that you are not going |
    _o__) to do any innovation in the future.? ?Gary Barnett |
    Ben Finney
  • Andrew Berg at Jul 8, 2011 at 11:29 pm

    On 2011.07.08 05:59 PM, Ben Finney wrote:
    With the caveat that the formatting of that line should be using PEP 8
    indentation for clarity:
    PEP 8 isn't bad, but I don't agree with everything in it. Certain lines
    look good in chunks, some don't, at least to me. It's quite likely I'm
    going to be writing 98%, if not more, of this project's code, so what
    looks good to me matters more than a standard (as long as the code
    works). Obviously, if I need to work in a team, then things change.
    and when a variable is used a bunch of times, concatenation is fine,
    I prefaced that sentence with "Other than the case", as in "except for
    the following case(s)".
    There is often more than one way to do it. The Zen of Python is explicit
    that there should be one obvious way to do it (and preferably only one).
    I meant in contrast to the idea of intentionally having multiple ways to
    do something, all with roughly equal merit.


    On 2011.07.08 04:38 PM, Ian Kelly wrote:
    Also, string formatting (especially using the new syntax like you are)
    is much clearer because there's less noise (the quotes all over the
    place and the plusses)
    I don't find it that much clearer unless there are a lot of chunks.
    and it's better for dealing with internationalization if you need to
    do that.
    I hadn't thought of that. That's probably the best reason to use string
    formatting.


    Thanks, everyone.
  • Steven D'Aprano at Jul 9, 2011 at 5:12 am

    Andrew Berg wrote:

    Is it bad practice to use this
    logger.error(self.preset_file + ' could not be stored - ' +
    sys.exc_info()[1])
    Instead of this?
    logger.error('{file} could not be stored -
    {error}'.format(file=self.preset_file, error=sys.exc_info()[1]))

    Other than the case where a variable isn't a string (format() converts
    variables to strings, automatically, right?)
    Not exactly, but more or less. format() has type codes, just like % string
    interpolation:

    '{0:d}'.format(1)
    '1'
    '{0:d}'.format(None)
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    ValueError: Unknown format code 'd' for object of type 'str'
    '%d' % 1
    '1'
    '%d' % None
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: %d format: a number is required, not NoneType

    If you don't give a type code, format converts any object to string (if
    possible).

    and when a variable is used
    a bunch of times, concatenation is fine, but somehow, it seems wrong.
    I don't like long chains of string concatenation, but short chains seem okay
    to me. One or two plus signs seems fine to my eyes, three at the most. Any
    more than that, I'd look at replacing it with % interpolation, the
    str.join() idiom, the string.Template class, or str.format.

    That's five ways of building strings.

    Of course, *repeated* string concatenation risks being slow -- not just a
    little slow, but potentially MASSIVELY slow, hundreds or thousands of times
    slower that alternatives. Fortunately recent versions of CPython tend to
    avoid this (which makes it all the more mysterious when the slow-down does
    strike), but other Pythons like Jython and IronPython may not. So it's best
    to limit string concatenation to one or two strings.

    And finally, if you're concatenating string literals, you can use implicit
    concatenation (*six* ways):
    s = ("hello "
    ... "world"
    ... "!")
    s
    'hello world!'

    Sorry if this seems a bit silly, but I'm a novice when it comes to
    design. Plus, there's not really supposed to be "more than one way to do
    it" in Python.
    On the contrary -- there are many different examples of "more than one way
    to do it". The claim that Python has "only one way" to do things comes from
    the Perl community, and is wrong.

    It is true that Python doesn't deliberately add multiple ways of doing
    things just for the sake of being different, or because they're cool,
    although of course that's a subjective judgement. (Some people think that
    functional programming idioms such as map and filter fall into that
    category, wrongly in my opinion.) In any case, it's clear that Python
    supports many ways of doing "the same thing", not all of which are exactly
    equivalent:

    # e.g. copy a list
    blist = list(alist)
    blist = alist[:]
    blist[:] = alist # assumes blist already exists
    blist = copy.copy(alist)
    blist = copy.deepcopy(alist)
    blist = []; blist.extend(alist)
    blist = [x for x in alist] # don't do this


    Hardly "only one way" :)



    --
    Steven
  • Vinay Sajip at Jul 9, 2011 at 11:06 am

    Andrew Berg <bahamutzero8825 <at> gmail.com> writes:

    Other than the case where a variable isn't a string (format() converts
    variables to strings, automatically, right?) and when a variable is used
    a bunch of times, concatenation is fine, but somehow, it seems wrong.
    Sorry if this seems a bit silly, but I'm a novice when it comes to
    design. Plus, there's not really supposed to be "more than one way to do
    it" in Python.
    In a logging context at least, using the form like

    logger.debug("formatting message with %s", "arguments")

    rather than

    logger.debug("formatting message with %s" % "arguments")

    means that the formatting is deferred by logging until it is actually needed. If
    the message never gets output because of the logging configuration in use, then
    the formatting is never done. This optimisation won't matter in most cases, but
    it will in some scenarios.

    By the way, logging primarily uses %-formatting instead of the newer
    {}-formatting, because it pre-dates {}-formatting. In more recent versions of
    Python, all of Python's three formatting styles are supported - see

    http://plumberjack.blogspot.com/2010/10/supporting-alternative-formatting.html

    Also by the way - Python doesn't say there shouldn't be more than one way to do
    things - just that there should be one *obvious* way (from the Zen of Python).

    Regards,

    Vinay Sajip
  • Andrew Berg at Jul 9, 2011 at 10:02 pm

    On 2011.07.09 06:06 AM, Vinay Sajip wrote:
    In a logging context at least, using the form like

    logger.debug("formatting message with %s", "arguments")

    rather than

    logger.debug("formatting message with %s" % "arguments")
    How would I do that with the newer formatting? I've tried:
    logger.info('Binary preset file {file} successfully stored.', {file :
    queue[0].preset_file})
    (global name 'file' not defined)
    and
    logger.info('Binary preset file {file} successfully stored.',
    file=queue[0].preset_file)
    (unexpected keyword 'file')
    By the way, logging primarily uses %-formatting instead of the newer
    {}-formatting, because it pre-dates {}-formatting. In more recent versions of
    Python, all of Python's three formatting styles are supported - see
    I've noticed. :-)
    log_formatter = logging.Formatter('{asctime} - __main__ - {funcName} -
    line {lineno} - {levelname} - {message}', style='{')
  • Andrew Berg at Jul 10, 2011 at 3:23 am

    On 2011.07.09 09:54 PM, Dennis Lee Bieber wrote:
    "file" is a built-in (related to "open").
    It is? What is it?
    type(file)
    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    NameError: name 'file' is not defined

    I don't see it in the docs as a built-in function, constant or type.

    - --
    CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
  • Andrew Berg at Jul 10, 2011 at 6:15 am

    On 2011.07.10 12:55 AM, Dennis Lee Bieber wrote:
    Maybe it's been removed, but from the help file for my installation
    help(file) returns a NameError in 3.2. It shows up as a built-in
    function in the 2.7 docs, but not in the py3k docs. It's not mentioned
    in any of the "what's new" sections of the docs for any version since
    2.2, though.

    - --
    CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
  • Andrew Berg at Jul 10, 2011 at 4:04 am

    On 2011.07.09 09:54 PM, Dennis Lee Bieber wrote:
    "file" is a built-in (related to "open"). Also:
    Traceback (most recent call last): File
    "C:\Users\Bahamut\workspace\Disillusion\disillusion.py", line 178, in
    <module> save_preset() File
    "C:\Users\Bahamut\workspace\Disillusion\disillusion.py", line 169, in
    save_preset logger.info('Binary preset file {barf} successfully
    stored.', barf=queue[0].preset_file) File
    "C:\Python32\lib\logging\__init__.py", line 1229, in info
    self._log(INFO, msg, args, **kwargs) TypeError: _log() got an
    unexpected keyword argument 'barf'
    Is barf built-in as well?

    - --
    CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
  • Andrew Berg at Jul 10, 2011 at 4:53 am

    On 2011.07.09 11:04 PM, Andrew Berg wrote:
    Is barf built-in as well?
    That came off more hostile than I wanted, so I'll rephrase it:

    I doubt it has anything to do with built-ins, since it fails on a
    variable name that obviously does not reference a built-in.
    - --
    CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
  • Vinay Sajip at Jul 10, 2011 at 7:23 am

    Andrew Berg <bahamutzero8825 <at> gmail.com> writes:

    How would I do that with the newer formatting? I've tried:
    There are examples in the blog post I linked to earlier:

    http://plumberjack.blogspot.com/2010/10/supporting-alternative-formatting.html

    Regards,

    Vinay Sajip
  • Andrew Berg at Jul 10, 2011 at 7:50 am

    On 2011.07.10 02:23 AM, Vinay Sajip wrote:
    There are examples in the blog post I linked to earlier:
    It seems that would require logutils. I'm trying to keep dependencies to
    a minimum in my project, but I'll take a look at logutils and see if
    there's anything else I could use. Thanks.

    - --
    CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB
  • Vinay Sajip at Jul 10, 2011 at 9:47 am

    Andrew Berg <bahamutzero8825 <at> gmail.com> writes:
    On 2011.07.10 02:23 AM, Vinay Sajip wrote:
    There are examples in the blog post I linked to earlier:
    It seems that would require logutils. I'm trying to keep dependencies to
    a minimum in my project, but I'll take a look at logutils and see if
    there's anything else I could use. Thanks.
    You don't need logutils, just the BraceMessage class - which is shown in the
    blog post (around 10 lines). Feel free to use it with copy and paste :-)

    Regards,

    Vinay Sajip
  • Andrew Berg at Jul 10, 2011 at 10:10 am

    On 2011.07.10 04:47 AM, Vinay Sajip wrote:
    You don't need logutils, just the BraceMessage class - which is
    shown in the blog post (around 10 lines). Feel free to use it with
    copy and paste :-)
    I didn't realize that was the actual class when I first read it. Thanks.

    - --
    CPython 3.2 | Windows NT 6.1.7601.17592 | Thunderbird 5.0
    PGP/GPG Public Key ID: 0xF88E034060A78FCB

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppython-list @
categoriespython
postedJul 8, '11 at 8:18p
activeJul 10, '11 at 11:24p
posts31
users12
websitepython.org

People

Translate

site design / logo © 2022 Grokbase