Fun with python string formatting

Hi all, what do you see looking at format string syntax https://docs.python.org/3/library/string.html#formatstrings ? In particular, at something like this: {h[1].red.jumbo-header:Hello, World!} Yes, this is syntactically correct statement and if we tweak Formatter methods, we can generate

[issue400507] Fix for bug PR#341 (string formatting overflow)

Change by admin : ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue400507] Fix for bug PR#341 (string formatting overflow)

Change by admin : -- github: None -> 32430 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: I'm going to close this. If you have a more concrete proposal, either re-open this or bring it up on python-ideas. -- resolution: -> rejected stage: -> resolved status: pending -> closed ___ Python tracker

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Change by Eric V. Smith : -- status: open -> pending ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: I forgot to update here: > PEP at https://github.com/python/peps/pull/2295 For the record, PEP 682 has been accepted. -- ___ Python tracker

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: x does not change. sorry. I also haven't figured out the implementation in my head yet. I want to provide some functionality to provide consistent indentation while using formatting . For example """ test {multi_line_text} """.format(multi_line_text,

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: I’m sorry, I don’t understand your proposal. Please answer my question about what “x” would be equal to under your proposed change. -- ___ Python tracker

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: Sorry, Can't edit comments Please see the code example below ``` Class A: def get_something_string(): return textwrap.dedent("""\ test text2 test text3 test text4""") textwrap.dedent(f"""\ test text1 {A.get_something_string()} test

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

textwrap.dedent("""\ test text2 test text3 test text4""") x = f"""\ test text1 {A.get_something_string()} test text5 test text6""" The duplicate use of dedent is to show an example. Thought I need

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: What would x be equal to here: def get_something_string(): return textwrap.dedent("""\ test text2 test text3 test text4""") x = f"""\ test text1 {get_something_string()} test text5 test text6""" ? With

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: "<<" This marks that line. ignore it -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: What would the presence of "<<" do? You haven't described your proposal. -- ___ Python tracker ___

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: If it's only for version 3.11, what do you think of the default behavior of the dedent method being changed? The method description says: > Remove any common leading whitespace from every line in `text`. ``` def get_something_string(): return textwrap.dedent("""\

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: What is the flag you mention? What would it do? This sounds like a new feature, which can only go in to 3.11. -- nosy: +eric.smith ___ Python tracker

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: Sorry, it's an indent , not an intent . -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

New submission from 김준환 : If use textwrap.dedent with string formatting, may get unintended sentences. For example, a sentence like this: ``` import textwrap def get_something_string(): return textwrap.dedent("""\ test text2 test text3

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: PEP at https://github.com/python/peps/pull/2295 -- ___ Python tracker ___ ___ Python-bugs-list

[issue45995] string formatting: normalize negative zero

sed [sign][~]. The C++ paper proposes [sign][z] (i.e. you can have the `z` alone without an explicit +/-), and this is what I implemented in the Python PR. My original proposal with tilde was discarded. > My only reservation is Mark's comment: """For Decimal, we'd need to &qu

[issue45995] string formatting: normalize negative zero

'd need to "own" the string formatting, taking that responsibility away from mpdecimal, but there are already other reasons to do that.""" If Mark is okay with that (right back at you, Mark!), then I think a PEP is the next step. It doesn

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: [John] > Mark, would you give it a review this month? Apologies; my holiday-break free time was nobbled from unexpected quarters. I can't promise to find time this month, but I can promise to try. I did at least skim through the PR, and while there are

[issue46453] argparse subparser help text is not escaped before string formatting

Irit Katriel added the comment: This is a feature. See https://docs.python.org/3/library/argparse.html#help -- nosy: +iritkatriel resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker

[issue46453] argparse subparser help text is not escaped before string formatting

Change by Peder Bergebakken Sundt : -- type: -> crash ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46453] argparse subparser help text is not escaped before string formatting

New submission from Peder Bergebakken Sundt : The `help` text in add_argument of a subparser in argparse can not contain a `%`, as it will affect string formatting. This often results in an exception. See repro.py for a reproduction, tested in Python 3.7 - 3.10. -- components

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: Mark, would you give it a review this month? (PR has been marked stale.) -- ___ Python tracker ___

[issue45995] string formatting: normalize negative zero

Mark Dickinson added the comment: Thanks, John. I should have time to review within the next week or so. -- ___ Python tracker ___

[issue45995] string formatting: normalize negative zero

Change by Mark Dickinson : -- assignee: -> mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: implemented float and Decimal-- PR is ready for review -- ___ Python tracker ___ ___

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: potential short-term solution for Decimal: if negative zero option is set and sign is negative: pre-round into a temp using mpd_qrescale() if mpd_iszero(temp): change sign to positive -- ___

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: > For Decimal, we'd need to "own" the string formatting, taking that > responsibility away from mpdecimal, but there are already other reasons to do > that. After some digging, I believe this is the background on forking pieces of

[issue45995] string formatting: normalize negative zero

Change by John Belmonte : -- keywords: +patch nosy: +jbelmonte nosy_count: 5.0 -> 6.0 pull_requests: +28274 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30049 ___ Python tracker

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: I'll share a draft PR soon (excluding Decimal), so far it's still looking straightforward. > Maybe old versions would correctly ignore the new bit being set. That's one of the benefits of using bit flags in an ABI: backward-compatible extensibility. (An

[issue45995] string formatting: normalize negative zero

Eric V. Smith added the comment: PyOS_double_to_string is part of the stable ABI. I don't recall if we're allowed to add new bitfield flags to a stable ABI function. We'd use a new Py_DTSF_NORMALIZE_NEGATIVE_0 flag for this feature. I suspect we can't add a flag, due to comparability

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: I see now. PyOS_double_to_string() could gain the extra flag to coerce negative zero but, out of the three formatting methods, only format() and f-string would use the flag. -- ___ Python tracker

[issue45995] string formatting: normalize negative zero

Eric V. Smith added the comment: %-formatting already doesn't support some formats that float.__format__ does, for example ','. So I agree we shouldn't modify %-formatting. I don't have much of an opinion on whether changing __format__ is a good idea or not. --

[issue45995] string formatting: normalize negative zero

Steven D'Aprano added the comment: Sorry John, I don't understand your comment about "treating %-formatting specifically". Isn't the point here not to change %-formatting at all? -- ___ Python tracker

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: > changing %-formatting doesn't seem viable I'm concerned about treating %-formatting specially. As far as float/complex, the logical and efficient place to put this change seems to be PyOS_double_to_string(), which affects all three formatting options.

[issue45995] string formatting: normalize negative zero

Serhiy Storchaka added the comment: Well, it makes sense for negative zero produced by rounding. But if we add a special support for this case, it would be useful to have some control on the type of rounding. Currently floats are rounded to the nearest decimal number, but in some cases it

[issue45995] string formatting: normalize negative zero

difficulties for float and complex types. For Decimal, we'd need to "own" the string formatting, taking that responsibility away from mpdecimal, but there are already other reasons to do that. Once we've done that, again the implementation doesn't seem onerous. -- __

[issue45995] string formatting: normalize negative zero

Change by Mark Dickinson : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: Here is the same proposal made for C++ `std::format`: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1496r2.pdf It makes fair arguments for the feature's use, and explains why the problem is hard to work around. It was withdrawn by the author

[issue45995] string formatting: normalize negative zero

Steven D'Aprano added the comment: It was decided long ago that % formatting would not be enhanced with new features. I think that it is supposed to match the standard C formatting codes, and nothing else. So this is unlikely to be approved for % formatting. It *might* be approved for the

[issue45995] string formatting: normalize negative zero

John Belmonte added the comment: > To normalize negative 0.0 to 0.0 you can just add 0.0. yes, I'm aware-- see "implementation" in the original post > there is no need to change all formatting specifications For adding 0 to work, it must be done after the rounding. That means if you want

[issue45995] string formatting: normalize negative zero

Serhiy Storchaka added the comment: To normalize negative 0.0 to 0.0 you can just add 0.0. It will work with any method of converting floats to string, there is no need to change all formatting specifications. >>> x = -0.0 >>> x -0.0 >>> x + 0.0 0.0 -- nosy: +mark.dickinson,

[issue45995] string formatting: normalize negative zero

New submission from John Belmonte : proposal: add a string formatting option to normalize negative 0 values to 0 use case: rounded display of a float that is nominally 0, where the distraction of a flashing minus sign from minute changes around 0 is unwanted example: >>> '%~5.1f'

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

Mark Shannon added the comment: No significant change in performance https://gist.github.com/markshannon/34a780d65e69b5a573a83f3fdb0139aa I think this merely indicates that there are little to no f-strings in the pyperformance benchmark suite. --

[issue44683] String formatting

Dennis Sweeney added the comment: If I understand correctly, this shows the behavior you're objecting to: >>> class A: ... def __getitem__(self, key): ... print(f"{key = }") ... return "apple" ... ... >>> '{0[1]}'.format(A()) # passes an integer key = 1 'apple' >>>

[issue44683] String formatting

Change by Mykyta : Removed file: https://bugs.python.org/file50166/1.png ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue44683] String formatting

with a = {'a': '1'} and '{0[1]}'.format(a) works properly with a = {1: 'a'}. Adding quotation marks does not help, KeyError occurs with '"1"'. -- components: Unicode files: 1.png messages: 397867 nosy: NickP, ezio.melotti, vstinner priority: normal severity: normal status: open title: String

[issue43624] Add underscore as a decimal separator for string formatting

Terry Davis added the comment: If no one else has any comments, I'll assume there is consensus and start working on this. I have not contributed to CPython before, nor have I worked on production C code, so it may be a while before I get anywhere. -- versions: +Python 3.11 -Python

[issue43624] Add underscore as a decimal separator for string formatting

Terry Davis added the comment: Current behavior: >>> format(1234.1234, '_f') '1_234.123400' >>> format(1234.1234, ',f') '1,234.123400' New behavior: >>> format(1234.1234, ',._f') '1,234.123_400' >>> format(1234.1234, '_._f') '1_234.123_400' >>> format(1234.1234, '._f') '1234.123_400' >>>

[issue43624] Add underscore as a decimal separator for string formatting

STINNER Victor added the comment: I'm now confused. Would you mind to give examples of all proposed formats and the expected output? -- ___ Python tracker ___

[issue43624] Add underscore as a decimal separator for string formatting

Terry Davis added the comment: Victor, > '_.f' would be the same as '_f'? No, the example in my original post is wrong, '_.f' isn't allowed now. The proposal should use '_f' to describe the current behavior. > Should "._f" be allowed to only add underscores in the fractional part? (for >

[issue43624] Add underscore as a decimal separator for string formatting

STINNER Victor added the comment: Raymond: > I prefer Terry's original proposal which is backwards compatible (...) Well ok, that's what I expected. Backward compatibility usually wins all other arguments in Python :-) But I had to ask the question :-) --

[issue43624] Add underscore as a decimal separator for string formatting

STINNER Victor added the comment: '_.f' would be the same as '_f'? Should "._f" be allowed to only add underscores in the fractional part? (for consistency?) -- ___ Python tracker

[issue43624] Add underscore as a decimal separator for string formatting

Eric V. Smith added the comment: I agree with Raymond. We can't make a change that would modify existing program output. Which is unfortunate, but such is life. And I'd prefer to see groupings of 5 on the right, but I realize I might be in the minority. --

[issue43624] Add underscore as a decimal separator for string formatting

Raymond Hettinger added the comment: I prefer Terry's original proposal which is backwards compatible and gives the user control over whether separator is to be applied to the fractional component. >>> format(12_34_56.12_34_56, '_._f') # Whole and fractional '123_456.123_456' >>>

[issue43624] Add underscore as a decimal separator for string formatting

STINNER Victor added the comment: > On the other hand, I suppose it would be possible to have a feature flag that > can be used to disable decimal underscores in 3.10 to prevent test failures. > Just spitballing... I wrote PEP 606 -- Python Compatibility Version

[issue43624] Add underscore as a decimal separator for string formatting

Terry Davis added the comment: Good point Victor, though I wonder how likely it is that a person using 3.10 would only use this particular new feature, and have an otherwise backwards-compatible codebase. This isn't something that I asked about out of necessity, and there hasn't been any

[issue43624] Add underscore as a decimal separator for string formatting

.org/t/add-underscore-as-a-thousandths-separator-for-string-formatting/7407 discussion, grouping digits was first designed for integers, and the fractional part of floats was simply ignored/forgotten. I mean, it doesn't sound like a deliberate choice to not group digits in the fractional part. The

[issue43624] Add underscore as a decimal separator for string formatting

STINNER Victor added the comment: > If we do anything for float, we should do the same for decimal.Decimal. and complex ;-) -- ___ Python tracker ___

[issue43624] Add underscore as a decimal separator for string formatting

Eric V. Smith added the comment: If we do anything for float, we should do the same for decimal.Decimal. -- ___ Python tracker ___

[issue43624] Add underscore as a decimal separator for string formatting

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43624] Add underscore as a decimal separator for string formatting

Dominic Davis-Foster added the comment: ISO 8-1:2009 recommends groups of three digits either side of the decimal sign. -- nosy: +domdfcoding ___ Python tracker ___

[issue43624] Add underscore as a decimal separator for string formatting

Change by STINNER Victor : -- nosy: +vstinner ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue43624] Add underscore as a decimal separator for string formatting

Raymond Hettinger added the comment: Some brief research === """ in numbers four or more digits long, use commas to set off groups of three digits, counting leftward from the decimal point, in the standard American style. For long decimal numbers, do not use any digit-group

[issue43624] Add underscore as a decimal separator for string formatting

Raymond Hettinger added the comment: IIRC there is ISO recommending that after the decimal point, digits be arranged in groups of five. I think is also how printed reference tables are typically formatted. -- nosy: +mark.dickinson, rhettinger, serhiy.storchaka

[issue43624] Add underscore as a decimal separator for string formatting

s addition. https://discuss.python.org/t/add-underscore-as-a-thousandths-separator-for-string-formatting/7407 I'm willing to give this a try if someone points me to where to add tests and where the float formatting code is. This would be my first CPython contribution. The feature freeze for 3.10 is

[issue40971] Documentation still mentions 'u' string formatting option

Petr Viktorin added the comment: I'm closing the issue. Please comment or reopen if I missed something. -- resolution: -> not a bug stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue40971] Documentation still mentions 'u' string formatting option

Petr Viktorin added the comment: AFAICS, Python 3 suports '%u' for printf-style formatting: Python 3.8.3 (default, May 29 2020, 00:00:00) [GCC 10.1.1 20200507 (Red Hat 10.1.1-1)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> '%u' % 6 '6' What am I

[issue40971] Documentation still mentions 'u' string formatting option

Shubham Upreti added the comment: Should i take this issue? -- nosy: +shubh07 ___ Python tracker ___ ___ Python-bugs-list mailing

[issue40971] Documentation still mentions 'u' string formatting option

Change by Benjamin Peterson : -- keywords: +easy stage: -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue40971] Documentation still mentions 'u' string formatting option

New submission from Gordon P. Hemsley : https://docs.python.org/3/library/stdtypes.html#old-string-formatting still lists the 'u' string formatting option, described as "Obsolete type – it is identical to 'd'." and linking to PEP 237. However, testing indicates that Python 3 does n

[issue38657] Clarify numeric padding behavior in string formatting

Mark Dickinson added the comment: It looks as though this has been addressed, and can be closed. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue38657] Clarify numeric padding behavior in string formatting

miss-islington added the comment: New changeset 09db1da63f866afff8a64ae3c60acdcd6bc80501 by Miss Islington (bot) in branch '3.7': bpo-38657: Clarify numeric padding behaviour in string formatting (GH-17036) https://github.com/python/cpython/commit/09db1da63f866afff8a64ae3c60acdcd6bc80501

[issue38657] Clarify numeric padding behavior in string formatting

miss-islington added the comment: New changeset a2075121217e809c9a5511f6ca225c12f340de0c by Miss Islington (bot) in branch '3.8': bpo-38657: Clarify numeric padding behaviour in string formatting (GH-17036) https://github.com/python/cpython/commit/a2075121217e809c9a5511f6ca225c12f340de0c

[issue38657] Clarify numeric padding behavior in string formatting

Change by miss-islington : -- pull_requests: +17958 pull_request: https://github.com/python/cpython/pull/18588 ___ Python tracker ___

[issue38657] Clarify numeric padding behavior in string formatting

Change by miss-islington : -- pull_requests: +17957 pull_request: https://github.com/python/cpython/pull/18587 ___ Python tracker ___

[issue38657] Clarify numeric padding behavior in string formatting

miss-islington added the comment: New changeset 424e5686d82235e08f8108b8bbe034bc91421689 by Pete Wicken in branch 'master': bpo-38657: Clarify numeric padding behaviour in string formatting (GH-17036) https://github.com/python/cpython/commit/424e5686d82235e08f8108b8bbe034bc91421689

[issue38657] Clarify numeric padding behavior in string formatting

Change by Eric V. Smith : -- title: String format for hexadecimal notation breaks padding with alternative form -> Clarify numeric padding behavior in string formatting ___ Python tracker <https://bugs.python.org/issu

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

Cédric Krier added the comment: I think PR-15275 will solves this issue also as you could use: >>> locale.setlocale(locale.LC_ALL, 'fr_FR') >>> locale.localize('{:.2f}'.format(1.891)) '1,89' -- nosy: +ced ___ Python tracker

[issue36787] Python3 regresison: String formatting of None object

Eric V. Smith added the comment: This behavior isn't going to change. As Zach says, if you want to convert any value to a string, use !s. We want to fail as soon as possible: if a class (such as NoneType) doesn't implement __format__, then trying to format an instance with a format spec

[issue36787] Python3 regresison: String formatting of None object

Zachary Ware added the comment: You can use `!s` to be sure that the object is a string: >>> '{!s:^10}'.format(None) ' None ' I think it's unlikely the behavior of NoneType.__format__ will be changed, but I'm adding Eric Smith to make that determination as the maintainer of str.format.

[issue36787] Python3 regresison: String formatting of None object

Gawain Bolton added the comment: Note: I have a patch which fixes this. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue36787] Python3 regresison: String formatting of None object

>>> print('{:^10}'.format(None)) Traceback (most recent call last): File "", line 1, in TypeError: unsupported format string passed to NoneType.__format__ Given that the None type is output as a string, it makes sense for

[issue35546] String formatting produces incorrect result with left-aligned zero-padded format

Eric V. Smith added the comment: I think this falls in to the consenting adults category. You can also do things like: >>> format(42, '->3') '-42' But why bother preventing this? It is unfortunate that %-formatting and .__format__() are different in this regard, but at this point I

[issue35546] String formatting produces incorrect result with left-aligned zero-padded format

Matthew Barnett added the comment: A similar issue exists with centring: >>> format(42, '^020') '0420' -- nosy: +mrabarnett ___ Python tracker ___

[issue35546] String formatting produces incorrect result with left-aligned zero-padded format

New submission from Serhiy Storchaka : Compare printf-style string formatting and new-style string formatting. >>> '%-020d' % 42 '42 ' >>> format(42, '<020') '4200' >>> format(42, '<020d') '42

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

Change by Stefan Krah : -- nosy: +skrah ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

James Emerton added the comment: @rhettinger See #34311 about formatting Decimals using locale.format(). I'd like to see the problem fixed in one place or the other. Also, this is seems relatively straightforward to implement as it's really just a combination of the fixed precision 'f' and

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

Raymond Hettinger added the comment: I would like to see locale() remain somewhat decoupled from the rest of string formatting. IIRC locale() is finicky especially when concurrency is involved. I think a best practice is for an app to address locale issues explicitly rather than inside

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

James Emerton added the comment: So far, I've implemented this for Decimal -- ___ Python tracker ___ ___ Python-bugs-list mailing

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

Change by Roundup Robot : -- keywords: +patch pull_requests: +8118 stage: -> patch review ___ Python tracker ___ ___

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

Change by James Emerton : -- nosy: +jemerton ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Change by Tal Einat : -- nosy: -taleinat ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

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

Tal Einat added the comment: Mark, since you have a working version of this, perhaps you can supply some performance benchmark results to help in making a decision? -- nosy: +taleinat ___ Python tracker

Re: print & string formatting

On Sunday, 22 July 2018 10:24:55 UTC+5:30, Cameron Simpson wrote: > On 21Jul2018 21:33, Sharan Basappa wrote: > >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" > > Pleasetry not to name

Re: print & string formatting

On 22/07/18 06:54, Cameron Simpson wrote: > On 21Jul2018 21:33, Sharan Basappa wrote: >> 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" > > Pleasetry not to name variables after builtin

Re: print & string formatting

On 21Jul2018 21:33, Sharan Basappa wrote: 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" Pleasetry not to name variables after builtin classes ("str" is the name of Python's string class).

Re: print & string formatting

On Sun, Jul 22, 2018 at 2:53 PM, Abdur-Rahmaan Janhangeer wrote: > *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

  1   2   3   4   5   6   7   8   9   10   >