[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: I'm attaching a patch that delivers the basic functionality in str.format. This patch is against trunk, although it will probably work elsewhere. DO NOT USE THIS PATCH IN ANY SERIOUS WORK It doesn't implement all of the needed functionality

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: Also note that this patch causes a few tests to fail, since they're trying to ensure that '{}'.format will fail. If we go forward I'll address that too, of course. -- message_count: 15.0 - 16.0

[issue5348] Documentation of format implies only strings and numbers are acceptable arguments

Eric Smith e...@trueblade.com added the comment: I looked and don't see where this error is. In fact, I don't see format() mentioned at all on the 2.6.1 page for builtin functions (http://docs.python.org/library/functions.html), which is a problem. What page are you looking

[issue5316] Buildbot failures in test_site

Eric Smith e...@trueblade.com added the comment: Trial and error shows it's test_sdist.py. -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5316

[issue5247] Unhelpful error message with str.format()

Eric Smith e...@trueblade.com added the comment: I'm getting ready to commit this. Does it need a test? I poked around and didn't see any tests that validate exception text, but maybe there are some I missed. I tend to think it shouldn't have a test, but I'm not sure what the norm

[issue5247] Unhelpful error message with str.format()

Eric Smith e...@trueblade.com added the comment: Committed in: r69806 (trunk) r69807 (release26-maint) r69808 (py3k) r69809 (release30-maint) -- resolution: - accepted stage: - committed/rejected status: open - closed ___ Python tracker rep

[issue5247] Unhelpful error message with str.format()

Eric Smith e...@trueblade.com added the comment: I've gone back and read PEP 3101. To use its terminology, I think the error message should be something like: Unknown presentation type %c for type %s. I'm not sure where I got the original wording conversion type. It's true that it's sometimes

[issue5247] Unhelpful error message with str.format()

Eric Smith e...@trueblade.com added the comment: The attached patch (against trunk) changes the message. However, it has at least one unintended consequence. If you have an object with no __format__, it gets converted to a string, which is then formatted. So you get: '{0:^10}'.format(0j

[issue5247] Unhelpful error message with str.format()

Eric Smith e...@trueblade.com added the comment: With this patch, I changed it to format code, and made it more in line with Antoine's original suggested message. I'm okay with format code or formatting code, but if we do use either of those wordings, we should change the documentation to match

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: auto_number_formatter_2.py lets you experiment with this with a syntax more similar to what ''.format() looks like: $ ./python Python 2.7a0 (trunk:69608, Feb 14 2009, 04:51:18) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type help

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: Okay, one last version. This one lets you use object access within the replacement string: from auto_number_formatter_3 import formatter as _ _('{} {} {}').format(3, 'pi', 3.14) '3 pi 3.14' _('{:#b} {!r:^10} {.imag}').format(3, 'pi', 3j+1

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: The attached file is a mostly working version that inherits from string.Formatter. It has the following shortcomings, which would all be addressed if we go forward: - Doesn't handle escaping '{' or '}' - Doesn't handle conversion specifiers, like

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: Right. The colon would be required if there's a format specifier. Or an exclamation if there's just a conversion specifier: {!r}{:f}{!s:^10}.format('foo', 3, 10) would give: 'foo'3.0010 I've attached a new version that includes

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: Terry J. Reedy wrote: Terry J. Reedy tjre...@udel.edu added the comment: All I am requesting is that '{} {} {}'.format(3, 'pi', 3.14) work as '%s %s %s' % (3, 'pi', 3.14) '3 pi 3.14' '{0} {1} {2}'.format(3, 'pi', 3.14) '3 pi 3.14' do

[issue5247] Unhelpful error message with str.format()

Eric Smith e...@trueblade.com added the comment: I agree. I'm not sure on backporting this. I'll work on a patch. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5247

[issue5247] Unhelpful error message with str.format()

Changes by Eric Smith e...@trueblade.com: -- assignee: - eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5247 ___ ___ Python-bugs-list

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Changes by Eric Smith e...@trueblade.com: -- assignee: - eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5237 ___ ___ Python-bugs-list

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: It's easy enough to implement. Although the 'all-or-nothing' aspect is a little tough, I'll have to give it some thought. Maybe the best way to do this is to first create a string.Formatter subclass that implements it. I'll play with it and see

[issue5237] Allow auto-numbered replacement fields in str.format() strings

Eric Smith e...@trueblade.com added the comment: How is: '{d}{s}{f}'.format(3, 'foo', 3.14) more unclear than: '%d%s%f' % (3, 'foo', 3.14) ? But the more I think about it, the more I think it would have to be: '{:d}{:s}{:f}'.format(3, 'foo', 3.14) Since {0:0} is a legitimate format string, I

[issue5122] test_tcl and test_ttk_guionly don't like each other

Eric Smith e...@trueblade.com added the comment: The current patch (protect_tk_loading.diff) looks reasonable to me, and it solves my problem with the tests hanging. So I'd suggest you commit the patch, insofar it improves on the current situation. I'm not an expert in tk, however. So if you're

[issue5122] test_tcl and test_ttk_guionly don't like each other

Eric Smith e...@trueblade.com added the comment: protect_tk_loading.diff works for me. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5122 ___ ___ Python

[issue5122] test_tcl and test_ttk_guionly don't like each other

Eric Smith e...@trueblade.com added the comment: Yes, I have these installed: tcl-8.4.13-3.fc6 tcl-devel-8.4.13-3.fc6 tk-8.4.13-3.fc6 tk-devel-8.4.13-3.fc6 When I run ./python Lib/test/regrtest.py test_tcl test_ttk_guionly, it hangs. ___ Python tracker rep

[issue5122] test_tcl and test_ttk_guionly don't like each other

Eric Smith e...@trueblade.com added the comment: The patch does solve the problem for me. It no longer hangs when running either: ./python Lib/test/regrtest.py test_tcl test_ttk_guionly or: ./python Lib/test/regrtest.py - ... test_traceback test_transformer test_ttk_guionly

[issue5122] test_tcl and test_ttk_guionly don't like each other

Eric Smith e...@trueblade.com added the comment: The second patch (checking_for_failed_tk_load.diff) also works for me. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5122

[issue5122] test_tcl and test_ttk_guionly don't like each other

Eric Smith e...@trueblade.com added the comment: With the second patch installed, your code snippet does indeed hang for me. With the third patch installed, I get: [trunk]$ ./python Python 2.7a0 (trunk:69369M, Feb 6 2009, 14:59:32) [GCC 4.1.2 20070626 (Red Hat 4.1.2-13)] on linux2 Type help

[issue4285] Use a named tuple for sys.version_info

Eric Smith e...@trueblade.com added the comment: Committed in r69331 (trunk) and r69346 (py3k). -- resolution: - accepted status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4285

[issue4285] Use a named tuple for sys.version_info

Eric Smith e...@trueblade.com added the comment: The doc string for sys includes: version_info -- version information as a tuple I'm not sure changing this to ... as a structseq makes it any more useful, but it's more correct. Does anyone have a preference? I'd use the same wording

[issue4285] Use a named tuple for sys.version_info

Eric Smith e...@trueblade.com added the comment: ... as a named tuple works for me. I'll go with that. Thanks! ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4285

[issue4285] Use a named tuple for sys.version_info

Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4285 ___ ___ Python-bugs-list mailing

[issue4285] Use a named tuple for sys.version_info

Changes by Eric Smith e...@trueblade.com: -- assignee: brett.cannon - eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4285 ___ ___ Python

[issue4701] range objects becomes hashable after attribute access

Eric Smith e...@trueblade.com added the comment: Perhaps the path of least resistance is to change PyObject_Hash to be yet another place where PyType_Ready will be called implicitly if it hasn't been called already? I think that's the best thing to do. It would bring PyObject_Hash in line

[issue4701] range objects becomes hashable after attribute access

Changes by Eric Smith e...@trueblade.com: -- nosy: +eric.smith ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4701 ___ ___ Python-bugs-list mailing

[issue4482] 10e667.__format__('+') should return 'inf'

Changes by Eric Smith [EMAIL PROTECTED]: -- assignee: - eric.smith nosy: +eric.smith ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue4482 ___ ___ Python

[issue3982] support .format for bytes

Eric Smith [EMAIL PROTECTED] added the comment: I don't think that b'...'.format() is a good idea. Programmers will continue to mix characters and bytes since .format() target are characters. b''.format() would return bytes, not a string. This is also how it works in 2.6. I'm also not sold

[issue3982] support .format for bytes

Eric Smith [EMAIL PROTECTED] added the comment: Yes, it would be easy to add. Maybe bring this up on python-dev (or python-3000) to get consensus? Are we in feature freeze for 3.0? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3982

[issue3721] invalid literal for int() with base 16: ''

Eric Smith [EMAIL PROTECTED] added the comment: The test fails for me on 2.5.1 (stock Mac OS 10.5.4) in the same way as described in this bug. In 2.6 (r66230) the test succeeds. I recommend we close this. -- nosy: +eric.smith ___ Python tracker

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

Eric Smith [EMAIL PROTECTED] added the comment: Unfortunately, I missed the window to get these into 3.0 and 2.6. Better luck for 3.1 and 2.7! -- versions: +Python 2.7, Python 3.1 -Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http

[issue3595] Windows base64 Decode

Eric Smith [EMAIL PROTECTED] added the comment: Please upload your script, or (preferably) some small test code. I suspect the problem is related to line endings and binary versus text files. -- nosy: +eric.smith ___ Python tracker [EMAIL PROTECTED

[issue1222] locale.format bug if thousand separator is space (french separator as example)

Eric Smith [EMAIL PROTECTED] added the comment: I'd recommend breaking the patch into the 3 parts mentioned in msg61929, then committing the first 2 parts. That should make the 3rd part much easier to evaluate. ___ Python tracker [EMAIL PROTECTED] http

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith [EMAIL PROTECTED] added the comment: I agree. That's one of the reasons I un-assigned it to me. Well, that and I couldn't get it to pass all tests. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772

[issue3411] str.format() on negative floats

Eric Smith [EMAIL PROTECTED] added the comment: Thanks for catching this. I was not skipping the leading sign char when looking for the decimal point in the string, which was causing me to incorrectly determine that a decimal wasn't present. Fixed in r65125 (trunk) and r65126 (py3k

[issue2772] Add PendingDeprecationWarning for % formatting

Changes by Eric Smith [EMAIL PROTECTED]: -- assignee: eric.smith - ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2772 ___ ___ Python-bugs-list mailing

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

Eric Smith [EMAIL PROTECTED] added the comment: Implemented for trunk in r65069; for py3k in r65073. -- resolution: - accepted status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3382

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

Eric Smith [EMAIL PROTECTED] added the comment: Changes backed out, pending fixing on Windows. -- resolution: accepted - status: closed - open ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3382

[issue3382] Make '%F' and float.__format__('F') convert results to upper case.

New submission from Eric Smith [EMAIL PROTECTED]: See http://mail.python.org/pipermail/python-dev/2008-July/081242.html for the discussion. Basically, 'F' did the same as 'f' because it was assumed that neither would ever produce an exponent. But they do, for numbers greater than about 1e50

[issue3083] Add alternate (#) formatting for bin, oct, hex output for str.format()

Eric Smith [EMAIL PROTECTED] added the comment: Implemented in trunk in r64958 and r64984; in py3k in r64960 and r64985. -- resolution: - accepted status: open - closed type: - feature request ___ Python tracker [EMAIL PROTECTED] http

[issue3140] str.format({0:n}) poss. bug with setlocale()

Eric Smith [EMAIL PROTECTED] added the comment: Fixed in r64499 (trunk) and r64500 (py3k). I now get: import locale locale.setlocale(locale.LC_ALL, en_US.UTF-8) 'en_US.UTF-8' for x in (123,1234,12345,123456,1234567,12345678,123456789,1234567890,12345678900): ... print([{0:20n}].format(x

[issue3186] bin(long) doesn't have a trailing 'L'

Eric Smith [EMAIL PROTECTED] added the comment: See http://mail.python.org/pipermail/python-dev/2008-February/077062.html, where Guido endorses my approach to implementing bin() without the trailing L for longs. Note that he also agrees with not adding a __bin__ function, which was implemented

[issue3140] str.format({0:n}) poss. bug with setlocale()

Eric Smith [EMAIL PROTECTED] added the comment: I'd say that's a bug. I'll look at it. -- components: +Interpreter Core nosy: +talin ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3140

[issue3140] str.format({0:n}) poss. bug with setlocale()

Changes by Eric Smith [EMAIL PROTECTED]: -- versions: +Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3140 ___ ___ Python-bugs-list mailing

[issue3083] Add alternate (#) formatting for bin, oct, hex output for str.format()

New submission from Eric Smith [EMAIL PROTECTED]: Per Guido in http://mail.python.org/pipermail/python-3000/2008-May/013912.html, add this to the PEP 3101 (Advanced String Formatting) implementation. This will add the prefixes 0b, 0o, and 0x. -- assignee: eric.smith components

[issue2630] repr() should not escape non-ASCII characters

Changes by Eric Smith [EMAIL PROTECTED]: -- nosy: +eric.smith ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2630 ___ ___ Python-bugs-list mailing list

[issue2598] { +(}.format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format

Eric Smith [EMAIL PROTECTED] added the comment: After discussing this with Talin, we've decided this is works as designed. The problem, if any, is that **{' +(': 44} is allowed as a parameter. I think that perhaps that should be an error, but I haven't had time to research if this is already

[issue2598] { +(}.format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format

Eric Smith [EMAIL PROTECTED] added the comment: I should have been clearer. By The problem, if any, is that **{' +(': 44} is allowed as a parameter, I meant in general, for all function/method calls. It's not an issue that's restricted to str.format

[issue2337] Backport oct() and hex() to use __index__

Changes by Eric Smith [EMAIL PROTECTED]: -- nosy: +eric.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2337 __ ___ Python-bugs-list mailing list Unsubscribe

[issue2836] str.format() documentation needs to be backported to 2.6

New submission from Eric Smith [EMAIL PROTECTED]: 3.0 has documentation for str.format(), but that documentation is missing in 2.6. The 2.6 what's new document: http://docs.python.org/dev/whatsnew/2.6.html also has an XXX reference to this: Consult the 2.6 documentation for a complete list

[issue2836] str.format() documentation needs to be backported to 2.6

Eric Smith [EMAIL PROTECTED] added the comment: When backporting to 2.6, this needs to be documented for both str and unicode. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2836

[issue2802] str.format() :n integer output

Eric Smith [EMAIL PROTECTED] added the comment: Implemented in 2.6 as r63078. I'll port this to py3k shortly. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2802 __ ___ Python

[issue2802] str.format() :n integer output

Eric Smith [EMAIL PROTECTED] added the comment: Implemented in 3.0 as r63093. I'm closing this issue. I added the C code that does the grouping insertion as _PyString_InsertThousandsGrouping and _PyUnicode_InsertThousandsGrouping (in 3.0). This might be useful to others, although the API

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith [EMAIL PROTECTED] added the comment: The attached patch (percent_formatting_pending_deprecation_0.diff) adds both the simple global lock to unicode_mod() and changes warnings.py to use .format() instead of % formatting. I think this is good enough. We should add a warning

[issue2802] str.format() :n integer output

Eric Smith [EMAIL PROTECTED] added the comment: The reason for this is that 'n' is defined in PEP 3101 as being a float format only, and the rule is that if an integer sees a float format, it does a float conversion and then prints the float with the supplied format. I'd be okay with adding 'n

[issue2802] str.format() :n integer output

Eric Smith [EMAIL PROTECTED] added the comment: It isn't hard (in Python): code deleted It's more complex, because the 3 is locale dependent, and is allowed to be something like 3, then 2, then 3, then 1, repeating until the start of the string. See _group() in Lib/locale.py. In any event

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith [EMAIL PROTECTED] added the comment: I'm not sure Py_EnterRecursiveCall is what I want, because that allows the recursion to happen, but just aborts it when it gets too deep. What I want to achieve is to have the warning not called if it's the warning that's being formatted. I coded

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith [EMAIL PROTECTED] added the comment: That would make user code warning that uses '%' brittle. However, if we warn about it, I think it's ok. True enough. Then I think we should go with: 1. Use .format() in the warnings module. 2. Tell the users not to use % formatting in user code

[issue2598] { +(}.format(**{' +(': 44}) should produce ValueError: invalid identifier, ' +(' in format

Changes by Eric Smith [EMAIL PROTECTED]: -- assignee: - eric.smith nosy: +eric.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2598 __ ___ Python-bugs-list

[issue2772] Add PendingDeprecationWarning for % formatting

New submission from Eric Smith [EMAIL PROTECTED]: Per http://mail.python.org/pipermail/python-3000/2008-April/013094.html, add a PendingDeprecationWarning to 3.0 for % formatting. The attached patch implements this for 3.0. For 2.6, it should only be a PendingDeprecationWarning if -3 warnings

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith [EMAIL PROTECTED] added the comment: Right. But is it worth adding per-thread machinery to this? I was going to do that, but it seemed like overkill. Upon further reflection, however, I think you may be right. I'll remove the easy keyword! -- keywords: -easy

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith [EMAIL PROTECTED] added the comment: Since we're just trying to prevent this function from recursing (indirectly) into itself, I think all of the logic can go here. What would you suggest the function _PyErr_InErrorProcessing do differently? I think the real issue is: Does

[issue2772] Add PendingDeprecationWarning for % formatting

Eric Smith [EMAIL PROTECTED] added the comment: Well, the first thing to check for is Py_Py3kWarning. Then do the extra logic and execution speed. In 3.0, it's always a PendingDeprecationWarning, so that won't work. The test needs to be: if not recursing and warning_is_not_suppressed

[issue2526] str.format() :n format does not appear to work for int and float

Eric Smith [EMAIL PROTECTED] added the comment: Committed fix in r62586. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2526

[issue1222] locale.format bug if thousand separator is space (french separator as example)

Changes by Eric Smith [EMAIL PROTECTED]: -- nosy: +eric.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1222 __ ___ Python-bugs-list mailing list Unsubscribe

[issue2416] % string formatting does not support %b

Eric Smith [EMAIL PROTECTED] added the comment: On the python-3000 list we decided not to add new features to % formatting, since it will be deprecated in favor of str.format. -- resolution: - wont fix status: open - closed __ Tracker [EMAIL PROTECTED

[issue2416] % string formatting does not support %b

Eric Smith [EMAIL PROTECTED] added the comment: I should have noted that the PEP was modified to remove %b and %#b formatting. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2416

[issue1745] Backport of PEP 3102 keyword-only arguments to 2.6

Eric Smith [EMAIL PROTECTED] added the comment: The patch doesn't apply cleanly for me. I can fix the non-clean patch, but another error is that obj2ast_arguments doesn't call arguments() with the correct parameters. If I pass in NULL's for the new params, all tests pass, but that just tells

[issue2526] str.format() :n format does not appear to work

Eric Smith [EMAIL PROTECTED] added the comment: I'm looking into it. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2526 __ ___ Python-bugs-list mailing list Unsubscribe: http

[issue2526] str.format() :n format does not appear to work for int and float

Eric Smith [EMAIL PROTECTED] added the comment: The same issue exists with floats: # continuing the example locale.format(%g, 12345, True) '12,345' {0:n}.format(12345.0) '12345' The same issue exists in 2.6. -- title: str.format() :n format does not appear to work - str.format() :n

[issue2477] parser support for future import of unicode_strings

Changes by Eric Smith [EMAIL PROTECTED]: -- nosy: +eric.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2477 __ ___ Python-bugs-list mailing list Unsubscribe

[issue2436] Should __future__ print_function be valid in 3.0?

New submission from Eric Smith [EMAIL PROTECTED]: Should this be accepted in 3.0, and become a no-op: from __future__ import print_function ? It might make using code in 2.6 and 3.0 easier, since you would not have to delete this line. I note that: from __future__ import with_statement

[issue2436] Should __future__ print_function be valid in 3.0?

Eric Smith [EMAIL PROTECTED] added the comment: Implemented in r61682. -- resolution: accepted - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2436

[issue1745] Backport of PEP 3102 keyword-only arguments to 2.6

Changes by Eric Smith [EMAIL PROTECTED]: -- nosy: +eric.smith __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1745 __ ___ Python-bugs-list mailing list Unsubscribe

[issue2412] Check 2to3 for support of print function.

New submission from Eric Smith [EMAIL PROTECTED]: Issue 1633807 is a backport of the print function to 2.6, using a __future__ import. Once it is committed, we need to ensure that 2to3 does the right thing (namely, nothing) with print functions in modules that have the __future__ import

[issue2416] % string formatting does not support %b

New submission from Eric Smith [EMAIL PROTECTED]: PEP 3127 Integer Literal Support and Syntax says that % string formatting should support %b. This needs to be added to both 2.6 and 3.0. It needs to support the forms %b and %#b. -- assignee: eric.smith components: Interpreter Core

[issue2264] empty specifier for float.__format__ does not always print at least one decimal digit

Eric Smith [EMAIL PROTECTED] added the comment: Fixed checked in as r61434. -- resolution: - fixed status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue2264

[issue1633807] from __future__ import print_function

Changes by Eric Smith [EMAIL PROTECTED]: -- nosy: +eric.smith _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1633807 _ ___ Python-bugs-list mailing list

[issue1633807] from __future__ import print_function

Eric Smith [EMAIL PROTECTED] added the comment: I'm going to review Anthony's patch and attempt to get it working in the current trunk. I'm going to start by adding some print tests to 3.0, then backport. _ Tracker [EMAIL PROTECTED] http://bugs.python.org

[issue2264] empty specifier for float.__format__ does not always print at least one decimal digit

Eric Smith [EMAIL PROTECTED] added the comment: I think the best way to handle this is to add a new format code to PyOS_ascii_formatd, which implements this behavior. There can be no backward compatibility issues, because PyOS_ascii_formatd currently ensures its format specifier type code

[issue2264] empty specifier for float.__format__ does not always print at least one decimal digit

New submission from Eric Smith [EMAIL PROTECTED]: PEP 3101 specifies that the empty format presentation type for float will always print at least one digit after the decimal point, but it does not do that if the number is output with an exponent: works: format(3.0, '') '3.0' fails: format

[issue1600] str.format() produces different output on different platforms (Py30a2)

Eric Smith [EMAIL PROTECTED] added the comment: Issue closed with commit r60909. Fixed as suggested by Mark Dickinson: The exponent always contains at least two digits, and only as many more digits as necessary to represent the exponent. -- resolution: - fixed status: open - closed

[issue1600] str.format() produces different output on different platforms (Py30a2)

Eric Smith added the comment: Checked in as r60909. I started with Mark's patch, but added code to both increase or decrease the number of zeros, as needed. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1600

[issue1600] str.format() produces different output on different platforms (Py30a2)

Eric Smith added the comment: Given Mark Dickinson's input, I think we should follow it. That effectively means leaving the Linux/MacOS input as is, and modifying the Windows output. I'll work up a patch, but I'd still like to get some input on changing the output of existing, working code

<    3   4   5   6   7   8