Re: print & string formatting

*Folks,I get a lot confused while using print functions in Python.For example, I get the same results for the following code:str = "one two three"print strprint "%s" %(str)So, what is the need to use the second method which I see being used in many programs I am referring to* well 1) that is more

print & string formatting

Folks, I get a lot confused while using print functions in Python. For example, I get the same results for the following code: str = "one two three" print str print "%s" %(str) So, what is the need to use the second method which I see being used in many programs I am referring to --

[issue33731] string formatting that produces floats with preset precision while respecting locale

Eric V. Smith added the comment: You can always use the locale module, although of course that's not as convenient: >>> locale.format('%.2f', 1.891) '1.89' I'm open to suggests on backward compatible ways to implement this for python 3.8. It would probably involve a new letter, and need to

[issue33731] string formatting that produces floats with preset precision while respecting locale

, eric.smith priority: normal severity: normal status: open title: string formatting that produces floats with preset precision while respecting locale type: enhancement versions: Python 3.6 ___ Python tracke

Re: String Formatting with new .format()

On Thu, Mar 29, 2018 at 1:54 AM, Dan Stromberg wrote: > On Wed, Mar 28, 2018 at 7:30 AM, Ganesh Pal wrote: >>> >>> Or maybe they're not giving the same result. I'm a little confused here. >>> >> >> >> My Bad and Apologies , I should be fined for

Re: String Formatting with new .format()

On Wed, Mar 28, 2018 at 7:30 AM, Ganesh Pal wrote: >> >> Or maybe they're not giving the same result. I'm a little confused here. >> > > > My Bad and Apologies , I should be fined for pasting wrong question. > > Actually I wanted to know if its ok to use just empty {}

Re: String Formatting with new .format()

"Ganesh Pal" wrote in message news:CACT3xuUmOzR=5G9=zaf3fp2lytbgjv74vsyjfsvsifo77lf...@mail.gmail.com... Actually I wanted to know if its ok to use just empty {} with .format() or use {} with values i.e {0} {1} both will give the same results anyway The benefit of using empty {} is that

Re: String Formatting with new .format()

> > Or maybe they're not giving the same result. I'm a little confused here. > My Bad and Apologies , I should be fined for pasting wrong question. Actually I wanted to know if its ok to use just empty {} with .format() or use {} with values i.e {0} {1} both will give the same results

Re: String Formatting with new .format()

On 03/26/2018 09:37 AM, Ganesh Pal wrote: > Hi Team, > > Just a quick suggestion, on string formatting with .format() which of the > below is better , given both give the same result . No they don't. Look more closely at the output. >>>> attempts = 1 >>>&

Re: String Formatting with new .format()

> > > Or maybe they're not giving the same result. I'm a little confused here. > > Thanks Chris, for the reply they appear to give the same result . -- https://mail.python.org/mailman/listinfo/python-list

Re: String Formatting with new .format()

在 2018年3月26日星期一 UTC+8下午11:37:46，Ganesh Pal写道： > Hi Team, > > Just a quick suggestion, on string formatting with .format() which of the > below is better , given both give the same result . > > >>> attempts = 1 > >>> msg2 = "Hello" > >>

Re: String Formatting with new .format()

On Tue, Mar 27, 2018 at 2:37 AM, Ganesh Pal <ganesh1...@gmail.com> wrote: > Hi Team, > > Just a quick suggestion, on string formatting with .format() which of the > below is better , given both give the same result . > >>>> attempts = 1 >>>> msg2 = &q

String Formatting with new .format()

Hi Team, Just a quick suggestion, on string formatting with .format() which of the below is better , given both give the same result . >>> attempts = 1 >>> msg2 = "Hello" >>> print "Retry attempt:{0} for error:{1}".format(attempts,msg2) Retry

Re: String formatting

Was "Accessing parent objects." On 03/25/2018 12:26 PM, Jugurtha Hadjar wrote: >> print("I am {0.__class__.__name__} foo".format(self)) > > I prefer keyword arguments, but if I used it that way I'd do: > > print("I am {0} foo".format(self.__class__.__name__)) These are contrived examples. In

[issue33092] The bytecode for f-string formatting is inefficient.

Serhiy Storchaka <storchaka+cpyt...@gmail.com> added the comment: I wouldn't say this more efficient. Instead one instruction you would need to execute two instructions. If I implemented f-string formatting I would add four simple opcodes for str(), repr(), ascii() and format(). Bu

[issue33092] The bytecode for f-string formatting is inefficient.

Antoine Pitrou added the comment: > I would suggest that a simper interpreter with smaller, simpler bytecodes is > a worthy goal in itself. +1 from me. Though I'm curious about performance changes as well :-) -- nosy: +pitrou ___

[issue33092] The bytecode for f-string formatting is inefficient.

Mark Shannon added the comment: Even if doesn't speed things up by a significant amount, I would suggest that a simper interpreter with smaller, simpler bytecodes is a worthy goal in itself. -- ___ Python tracker

[issue33092] The bytecode for f-string formatting is inefficient.

Change by Mark Shannon : -- keywords: +patch pull_requests: +5893 stage: -> patch review ___ Python tracker ___

[issue33092] The bytecode for f-string formatting is inefficient.

Eric V. Smith added the comment: Would this change really have a performance impact? Not saying it wouldn't, but if we're going to add bytecodes we should know the answer in advance. -- nosy: +eric.smith ___ Python tracker

[issue33092] The bytecode for f-string formatting is inefficient.

ssions in the standard library, just the bytecode FORMAT_SIMPLE need be executed. -- components: Interpreter Core messages: 314000 nosy: Mark.Shannon priority: normal severity: normal status: open title: The bytecode for f-string formatting is inefficient. type: performance versions: Pyth

[issue20150] API change in string formatting with :s option should be documented in What's New.

Cheryl Sabella added the comment: I believe this has been added to the 3.4 What's New already: object.__format__() no longer accepts non-empty format strings, it now raises a TypeError instead. Using a non-empty string has been deprecated since Python 3.2. This change has

[issue29568] undefined parsing behavior with the old style string formatting

Xiang Zhang added the comment: New changeset 9f8ad3f39e0a92ed37d012b9dd237399524f0d51 by Xiang Zhang (Serhiy Storchaka) in branch 'master': bpo-29568: Disable any characters between two percents for escaped percent "%%" in the format string for classic string formatting. (GH-

[issue29568] undefined parsing behavior with the old style string formatting

Changes by Larry Hastings : -- pull_requests: -588 ___ Python tracker ___ ___

[issue29568] undefined parsing behavior with the old style string formatting

Changes by Larry Hastings : -- pull_requests: +588 ___ Python tracker ___ ___

[issue29568] undefined parsing behavior with the old style string formatting

Changes by Xiang Zhang : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___

[issue29568] undefined parsing behavior with the old style string formatting

Changes by Serhiy Storchaka : -- pull_requests: +422 ___ Python tracker ___ ___

[issue29568] undefined parsing behavior with the old style string formatting

Jerry Dimitrov added the comment: Thanks for the documentation reference. Can we at least add this link reference [1] as a note or something like that into those documentation sections: [2] https://docs.python.org/2/library/stdtypes.html#string-formatting and [3] https://docs.python.org/3

[issue29568] undefined parsing behavior with the old style string formatting

Serhiy Storchaka added the comment: Here is a patch. -- keywords: +patch stage: -> patch review versions: -Python 2.7, Python 3.5, Python 3.6 Added file: http://bugs.python.org/file46640/format-percent.patch ___ Python tracker

[issue29568] undefined parsing behavior with the old style string formatting

Xiang Zhang added the comment: Or even not fix it in develop branch. -- ___ Python tracker ___ ___

[issue29568] undefined parsing behavior with the old style string formatting

Xiang Zhang added the comment: The documentation[1] explicitly states using % to do string format could be error-prone and recommends using str.format(). So +1 on no change in maintenance branches. [1] https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting

[issue29568] undefined parsing behavior with the old style string formatting

Serhiy Storchaka added the comment: Yes, it is what I want. Current behavior is just an artefact of the implementation. I have doubts that any other implementation of printf-like formatting has such behavior. Bytes formatting starves from the same issue. >>> b'% %' % {} b'%' But there are

[issue29568] undefined parsing behavior with the old style string formatting

R. David Murray added the comment: I don't think we should change the behavior in maintenance branches. I take it what you want to do is make it so that if the parser ends up thinking it is seeing '%%' but there is stuff between the two %s, that's an error? -- nosy: +r.david.murray

[issue29568] undefined parsing behavior with the old style string formatting

Serhiy Storchaka added the comment: In this example characters between percents are parsed as for any conversion specifier but ignored and '%(a) %' is formatted to '%'. '(a)' specifies a mapping key, ' ' is a conversion flag, the second '%' is a conversion type. >>> '%(a) d' % {'a': 123} '

[issue29568] undefined parsing behavior with the old style string formatting

to the documentation for string formatting and the relevant PEPs, there is no additional info about this particular case. I want to say thank you to Yhg1s, JustASlacker, Jerub and lz1irq for discovering this 'bug/feature' and the additional information about it. Please let me know if this

Re: % string formatting - what special method is used for %d?

Ian Kelly wrote: > On Sat, Dec 10, 2016 at 11:40 PM, Veek M wrote: >> Well take a look at this: >> ### >> #!/usr/bin/python >> >> class Foo(int): >> def __init__(self, value): >> self.value = value >> >> def

Re: % string formatting - what special method is used for %d?

On Sat, Dec 10, 2016 at 11:40 PM, Veek M wrote: > Well take a look at this: > ### > #!/usr/bin/python > > class Foo(int): > def __init__(self, value): > self.value = value > > def __str__(self): > print '__str__'

Re: % string formatting - what special method is used for %d?

Steve D'Aprano wrote: > On Sat, 10 Dec 2016 06:06 pm, Veek M wrote: > >> When we do: >> >> print '%s %d' % ('hello', 10) >> >> what special method is being invoked internally within the string- >> format-specifier? > > %d requires the argument to be an int, or able to be converted to int >

Re: % string formatting - what special method is used for %d?

On Sat, 10 Dec 2016 06:06 pm, Veek M wrote: > When we do: > > print '%s %d' % ('hello', 10) > > what special method is being invoked internally within the string- > format-specifier? %d requires the argument to be an int, or able to be converted to int using the __int__ special method. py>

% string formatting - what special method is used for %d?

When we do: print '%s %d' % ('hello', 10) what special method is being invoked internally within the string- format-specifier? format() invokes format__ print invokes __str__ I'm basically trying to make sense of: raise TypeError('urkle urkle %s' % list(dictionary)) <=> raise

Re: logging TypeError: not all arguments converted during string formatting

gging/__init__.py", line 828, in format return fmt.format(record) File "/usr/lib/python3.4/logging/__init__.py", line 565, in format record.message = record.getMessage() File "/usr/lib/python3.4/logging/__init__.py", line 328, in getMessage msg = msg

Re: logging TypeError: not all arguments converted during string formatting

File "C:\Continuum\Anaconda3\lib\logging\__init__.py", line 330, in getMessage msg = msg % self.args TypeError: not all arguments converted during string formatting [snip] File "C:\Users\dweng\PycharmProjects\lumar_ingestion\ingestion_workflow_modules\import_to_dataframe.p

logging TypeError: not all arguments converted during string formatting

n fmt.format(record) File "C:\Continuum\Anaconda3\lib\logging\__init__.py", line 567, in format record.message = record.getMessage() File "C:\Continuum\Anaconda3\lib\logging\__init__.py", line 330, in getMessage msg = msg % self.args TypeError: not all arguments conver

[issue13410] String formatting bug in interactive mode

Changes by Serhiy Storchaka : -- nosy: +benjamin.peterson resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue13410] String formatting bug in interactive mode

Roundup Robot added the comment: New changeset a06654ca0134 by Serhiy Storchaka in branch '2.7': Issue #13410: Fixed a bug in PyUnicode_Format where it failed to properly https://hg.python.org/cpython/rev/a06654ca0134 -- nosy: +python-dev ___ Python

[issue13410] String formatting bug in interactive mode

Serhiy Storchaka added the comment: The issue for str was fixed in issue15516. The issue for unicode is not fixed yet. -- nosy: +serhiy.storchaka ___ Python tracker

Re: TypeError: not all arguments converted during string formatting

On Wed, Feb 17, 2016 at 7:32 PM, Chris Angelico wrote: > The print statement/function happily accepts multiple arguments, and > will join them according to a set of predefined rules. The logging > functions don't have those rules, so they take one message and some > optional

Re: TypeError: not all arguments converted during string formatting

On Thu, Feb 18, 2016 at 12:58 AM, Ganesh Pal <ganesh1...@gmail.com> wrote: > Iam on python 2.6 and Linux , I had replaced print out, err ret with > logging.info(out, err ,ret) in the below code . I am getting > > "TypeError: not all arguments converted during string

Re: TypeError: not all arguments converted during string formatting

print out, err ret with > logging.info(out, err ,ret) in the below code . I am getting > > "TypeError: not all arguments converted during string formatting" > error any quick suggestion > > > try: > out, err, ret = run(cmd, timeout=60) >

TypeError: not all arguments converted during string formatting

Hi Team, Iam on python 2.6 and Linux , I had replaced print out, err ret with logging.info(out, err ,ret) in the below code . I am getting "TypeError: not all arguments converted during string formatting" error any quick suggestion try: out, err, ret = run(cmd,

[issue8060] PEP 3101 string formatting missing engineering presentation type for floating point

Serge Stroobandt added the comment: As per https://bugs.python.org/issue26223#msg259772 , can we please reopen this? I kind of hate it when *real* issues are kept closed for years (6!) until another lost soul comes by with the same itch... -- nosy: +serge.stroobandt versions: +Python

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Documentation task added as issue #25179. Thanks to Martin for the great code reviews. -- resolution: -> fixed status: open -> closed ___ Python tracker

[issue24965] Implement PEP 498: Literal String Formatting

Roundup Robot added the comment: New changeset a10d37f04569 by Eric V. Smith in branch 'default': Issue #24965: Implement PEP 498 "Literal String Interpolation". Documentation is still needed, I'll open an issue for that. https://hg.python.org/cpython/rev/a10d37f04569 --

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: I changed the generated code to call: format(x [, spec]) instead of: x.__format__(spec) The reason is that the correct way to call __format__ is actually: type(x).__format__(x, spec) That is, the __format__ lookup is done on the type, not the instance. From

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Cleaned up the error handling in fstring_expression_compile so it's easier to verify and more robust in the face of future changes. Added a test for an un-doubled '}', which is an error in a top-level literal (and ends a nested expression). Modified existing

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Hopefully the last version. -- Added file: http://bugs.python.org/file40495/pep-498-8.diff ___ Python tracker ___

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: > Martin Panter added the comment: > > Another strange error message (though maybe the new test changes you > mentioned caught this): > f'{3:{10}' # Actually missing a closing bracket '}' > File "", line 1 > SyntaxError: f-string: unexpected '}' Yes,

[issue24965] Implement PEP 498: Literal String Formatting

Martin Panter added the comment: Another strange error message (though maybe the new test changes you mentioned caught this): >>> f'{3:{10}' # Actually missing a closing bracket '}' File "", line 1 SyntaxError: f-string: unexpected '}' -- ___

[issue24965] Implement PEP 498: Literal String Formatting

Martin Panter added the comment: I left a few more comments on Reitveld. Checking the error messages does make me feel a lot more comfortable though. -- ___ Python tracker

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: I rewrote the format_spec parser to recursively call the f-string parser, so any oddness in what's allowed in a format_spec is gone. It took way longer than I thought, but the code is better for it. -- Added file:

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Simplified error handling, fixed 2 memory leaks. All tests now pass with no leaks. This should be the final version. -- Added file: http://bugs.python.org/file40484/pep-498-7.diff ___ Python tracker

[issue24965] Implement PEP 498: Literal String Formatting

Changes by Yury Selivanov : -- nosy: +elvis ___ Python tracker ___ ___ Python-bugs-list

[issue24965] Implement PEP 498: Literal String Formatting

Martin Panter added the comment: Regarding the null terminator, I was mainly smoke testing your code. :) Maybe it would be too hard to support properly. Although I could imagine someone doing things like this: >>> d = {b"key\x00": "value"} >>> f"key={d[b'key\x00']}" # Oops, escape code at

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: I'll probably ensure that all of the parsing errors contain "format string" or "f-string" or similar. That way the regex check is easier, and the user can search for it more easily. It remains to be seen how these are referenced in the documentation.

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: After discussing it with Guido, I've removed the ability to combine 'f' with 'u'. -- ___ Python tracker ___

[issue24965] Implement PEP 498: Literal String Formatting

Jelle Zijlstra added the comment: Thanks! Here are a few more cases I came across with the existing implementation: >>> f"{'a\\'b'}" File "", line 1 SyntaxError: missing '}' in format string expression I believe this is valid and should produce "a'b". >>> f"{x!s!s}" File "", line 1

[issue24965] Implement PEP 498: Literal String Formatting

Jelle Zijlstra added the comment: Is this behavior intentional? >>> str = len >>> x = 'foo' >>> f'{x!s}' '3' >>> '{!s}'.format(x) 'foo' Or similarly: >>> import builtins >>> del builtins.repr >>> f'{x!r}' Traceback (most recent call last): File "", line 1, in NameError: name 'repr' is not

[issue24965] Implement PEP 498: Literal String Formatting

Jelle Zijlstra added the comment: I've started working on implementing this feature in Cython and I'd like to confirm a few edge cases: - f'{ {1: 2\N{RIGHT CURLY BRACKET}[1]}' == '2' (string escape rules work even within the expressions) - f'{ '''foo''' }' is a syntax error - f'{ """foo

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: This patch fixes triple-quoted strings, plus a few bugs. I'm going to commit it tomorrow, barring any unforeseen issues. -- Added file: http://bugs.python.org/file40447/pep-498-5.diff ___ Python tracker

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Yes, Jelle, you are correct in all 3 cases. Remember that the steps are to extract the string from the source code, decode backslash escapes, and only then treat it as an f-string. For the first case, without the 'f' prefix: '{ {1: 2\N{RIGHT CURLY

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Agreed on checking the error messages better. Especially since even the simplest of errors (like leaving out a quote) results in a syntax error in parsing the string, not parsing inside the f-string. I'll look at it eventually. --

[issue24965] Implement PEP 498: Literal String Formatting

Martin Panter added the comment: Regarding wrong error messages, I’ve learnt the hard way that it is often best to use assertRaisesRegex() instead of assertRaises(), to ensure that the actual exception you have in mind is being triggered, rather than a typo or something. Though that might

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: This one has been fixed: >>> f"{'a\\'b'}" "a'b" This one was a bug that I previously fixed, that Martin pointed out: >>> f"{x!s!s}" File "", line 1 SyntaxError: invalid character following conversion character And this is the same bug: >>> f"{x!s{y}}" File

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Both of those are known (to me!) byproducts of the current implementation. If my crazy idea of adding opcodes to speed up f-strings flies, then this issue will go away. I consider this a corner case that doesn't need to be addressed before committing this

[issue24965] Implement PEP 498: Literal String Formatting

Martin Panter added the comment: I’m actually trying out your patch now. A couple strange errors and observations: >>> f"{'{'}" # Why is this allowed in an outer format expression-- '{' >>> f"{3:{'{'}>10}" # --but not inside a format specifier? SyntaxError: nesting of '{' in format specifier

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Thanks again, Martin. I've found 4 bugs so far, based on your suggested tests. The ones I haven't fixed are: 'fur' strings don't work (something in the lexer), and triple quoted strings don't work correctly. I'm working on both of those, and should have an

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: It turns out 'fur' strings aren't a thing, because 'ur' strings aren't. >From tokenizer.c: /* ur"" and ru"" are not supported */ And the PEP: https://www.python.org/dev/peps/pep-0414/#exclusion-of-raw-unicode-literals I'll add a test to make sure this fails.

[issue24965] Implement PEP 498: Literal String Formatting

Martin Panter added the comment: Another version of that AST that is better for my digestion: f'a={a}' Module(body=[Expr( value=JoinedStr(values=[ Str(s='a='), FormattedValue( value=Name(id='a', ctx=Load()), conversion=0,

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Thanks, Martin. I've posted my replies. I'll add some more tests, and work on the triple quoted string bug. -- ___ Python tracker

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: I discussed it with Guido and added 'F' to the PEP. -- ___ Python tracker ___

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: This version does dynamic allocation for the expression list, and fixes some memory leaks and early decrefs. I think it's complete, but I'll take some more passes through it checking for leaks. -- ___ Python

[issue24965] Implement PEP 498: Literal String Formatting

Changes by Eric V. Smith : Added file: http://bugs.python.org/file40430/pep-498-4.diff ___ Python tracker ___

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: The good news is that the performance is pretty good, and finally I have a case where I can beat %-formatting: $ ./python.bat -mtimeit -s 'a=2' "'%s' % a" 100 loops, best of 3: 0.883 usec per loop $ ./python.bat -mtimeit -s 'a=2' '"{}".format(a)' 100

[issue24965] Implement PEP 498: Literal String Formatting

Changes by Eric V. Smith : Removed file: http://bugs.python.org/file40302/pep-498.diff ___ Python tracker ___

[issue24965] Implement PEP 498: Literal String Formatting

Changes by Eric V. Smith : Removed file: http://bugs.python.org/file40316/pep-498-1.diff ___ Python tracker ___

[issue24965] Implement PEP 498: Literal String Formatting

Changes by Eric V. Smith : Removed file: http://bugs.python.org/file40317/pep-498-2.diff ___ Python tracker ___

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: This implements the accepted PEP 498. The only other real change I plan on making is to do dynamic memory allocation when building the expressions that make up a JoinedStr AST node. The code has all of the places to do that already laid out, it's just a matter

[issue24965] Implement PEP 498: Literal String Formatting

Barry A. Warsaw added the comment: On Sep 09, 2015, at 11:57 PM, Eric V. Smith wrote: >There's one nit where I accept 'f' and 'F', but the PEP just says 'f'. I'm >not sure if we should accept the upper case version. I'd think not, but all >of the other ones (b, r, and u) do. I think it should

[issue24965] Implement PEP 498: Literal String Formatting

Roundup Robot added the comment: New changeset a0194ec4195c by Eric V. Smith in branch 'default': Removed Implementation Limitations section. While the version of the code on http://bugs.python.org/issue24965 has the 255 expression limitation, I'm going to remove this limit. The i18n section

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Fixed validate_exprs bug. -- Added file: http://bugs.python.org/file40316/pep-498-1.diff ___ Python tracker ___

[issue24965] Implement PEP 498: Literal String Formatting

Changes by Yury Selivanov : -- nosy: +yselivanov ___ Python tracker ___ ___

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: Make sure f-strings are identified as literals in error messages. -- Added file: http://bugs.python.org/file40317/pep-498-2.diff ___ Python tracker

[issue24965] Implement PEP 498: Literal String Formatting

title: Implement PEP 498: Literal String Formatting type: enhancement versions: Python 3.6 Added file: http://bugs.python.org/file40302/pep-498.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24965

[issue24965] Implement PEP 498: Literal String Formatting

Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24965 ___ ___ Python-bugs-list mailing

[issue24965] Implement PEP 498: Literal String Formatting

Eric V. Smith added the comment: One thing I've done in this implementation is to build up a string to pass to str.format(), instead of using the original string. This new string uses positional parameters instead of named parameters. I had originally proposed to add a string.interpolate() to

Re: Cheat sheet for the new string formatting?

On 09/06/2015 13:15, Skip Montanaro wrote: One thing which seems obvious now is that since format() delegates to the individual types for formatting, much of the documentation of this stuff must now be delegated to the individual types. However, I can't find anything about the formatting syntax

Re: Cheat sheet for the new string formatting?

Skip Why don't floats support {:.Ns}? (I know I can use {!s}.) random832 Why would they? The old style didn't support %.Ns either. Well, the old style does, though it appears the N is ignored: %5s % -0.00666762259822 '-0.00666762259822' It doesn't raise an exception though. (This is with

Re: Cheat sheet for the new string formatting?

On Tue, Jun 9, 2015, at 08:15, Skip Montanaro wrote: Skip Why don't floats support {:.Ns}? (I know I can use {!s}.) random832 Why would they? The old style didn't support %.Ns either. Well, the old style does, though it appears the N is ignored: %5s % -0.00666762259822

Re: Cheat sheet for the new string formatting?

On Tue, Jun 9, 2015 at 7:29 AM, random...@fastmail.us wrote: Where have you looked? Have you read https://docs.python.org/3/library/string.html#formatspec ? Yes, but I missed the None section. I looked closely at 'g', but didn't see anything like this is the default. I will admit I was a bit

Cheat sheet for the new string formatting?

I have so far ignored the new string formatting (you know, the stuff with all the braces, dots and brackets that make Python strings look like Perl code wink). I am still only using Python 2.7, but have recently started forcing myself to use the print() function. I figure maybe I should also start

Re: Cheat sheet for the new string formatting?

It just means significant digits in the general format, which alternates between 10-exponent notation and plain decimal notation. https://docs.python.org/3.4/library/string.html#format-specification-mini-language '{:.3}'.format(0.356785) '3.57e-05' '{:.3}'.format(0.00356785)

<    1   2   3   4   5   6   7   8   9   10   >