Fun with python string formatting

[Axy via Python-list]

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 such an output:


Hello, World!

Someone might need a booze to catch sight of arguments and css classes 
in the source statement, okay: let it be Aligote markup.


Although I haven't implemented HTML rendering yet (my actual needs were 
reST and Markdown), this does generate plain text and Markdown now.


However, I'm discouraged at the moment. Without nested markup the 
implementation is very small and nice. With more or less complex 
formatting, such as nested lists, there's a need to analyse upper level 
statements and to enforce some rules. Also, there's a pain with 
indentation, but that's mainly because I was too lazy and based my 
implementation on previous work instead of writing a better one from 
scratch.


There are some undefined points such as how to render paragraphs. Use 
strict {p:text} directive or just split literal text by doubly newlines.


Can't decide whether to cut down all the complexity and revert recursion 
level to 2 or proceed with rich markup.


Anyway, below is the rendered specification in plain text. Here's the 
source code 
https://github.com/declassed-art/clabate/blob/main/clabate/extras/aligote.py 
and the specification 
https://github.com/declassed-art/clabate/blob/main/clabate/examples/aligote_spec.py


If this looks funny and you have any crazy ideas what can be added to or 
changed in the specification, let me know.


Axy.


Aligote markup specification


Headings


{h1:heading}


{h2:heading}


{h3:heading}


{h4:heading}


{h5:heading}


{h6:heading}


Styles
--

{b:bold text}

{i:italic text}

{b:bold and {i:italic} text}

{i:italic and {b:bold} text}

{u:underline text}

{s:strike-through text}

{sub:subscript text}

{sup:superscript text}

Links
-

{link[optional text]:URL}

Examples:

{link:http://declassed.art}

{link[Declassed Art]:http://declassed.art}

Rendered as:

http://declassed.art

Declassed Art (http://declassed.art)


Lists
-

Unordered lists
---

{ul:
    {li:item one, can be markup}
    {li:item two
    can be multi-line}
    {li:etc}
}

Rendered as:

* item one, can be {b:markup}
* item two
  can be multi-line
* etc

Ordered lists
-

{ol:
    {li:item one}
    {li:item two}
    {li:etc}
}

Rendered as:

1. item one
2. item two
3. etc

Nested lists


{ul:
    {li:item one}
    {li:item two}
    {ol:
    {li:item one,
    multi-line}
    {li:item two}
    }
    {li:etc}
}

Rendered as:

* item one
* item two
    1. item one,
   multi-line
    2. item two
* etc

Optional arguments
--

XXX Markdown does not support arbitrary numbering, does it?

{ol:
    {li[3]:item 3}
    {li[5]:item 5
    {ol:
    {li:ordinal is rendered as 5.1}
    {li[3]:ordinal is rendered as 5.3}
    {li[5][5]:ordinal is rendered as 5.5}
    {li: ordinal is rendered as 5.6}
    }
    }
}

Rendered as:

3. item 3
5. item 5
   5.1. ordinal is rendered as 5.1
   5.3. ordinal is rendered as 5.3
   5.5. ordinal is rendered as 5.5
   5.6. ordinal is rendered as 5.6

Optional argument for unordered list is the bullet character.
Default is `*`:
{ul:
    {li:item 1}
    {li[+]:item 2}
    {li[-]:item 3}
}

Rendered as:

* item 1
+ item 2
- item 3

Quirks
--

{ol:
    {li:item one}

    Basically, lists may contain any literal text.
    In terms of python formatting this is not an error,
    but that's not good for rendering.

    {li:item two}
}

Rendered as:

1. item one

Basically, lists may contain any literal text.
In terms of python formatting this is not an error,
but that's not good for rendering.

2. item two

Syntax highlighting
---

{python:
    print('Hello, world!')
}

Rendered as:


    print('Hello, world!')
--
https://mail.python.org/mailman/listinfo/python-list

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

[admin]

Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[admin]

Change by admin :


--
github: None -> 32430

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

Change by Eric V. Smith :


--
status: open -> pending

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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, consistent_indent=True)

It's just a suggestion.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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 text5
test text6""")
```

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[김준환]

김준환  added the comment:

No, I know `textwrap.dedent` as a convenience function used for code 
readability. But to have the result I want, I currently need to do something 
like this:
If it's a method inside a class, it's even more ugly.

Class A:
 def get_something_string():
 return 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 needed a consistent dedent for every line while using the string 
formatting feature.

--

___
Python tracker 
<https://bugs.python.org/issue46992>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 3.10 it is: ' test text1\n test text2\ntest text3\ntest text4\n
 test text5\n test text6'

Are you proposing to change that?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

Eric V. Smith  added the comment:

What would the presence of "<<" do? You haven't described your proposal.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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("""\
 test text2
 test text3
 test text4""")

textwrap.dedent(f"""\
 test text1
 {get_something_string()} <<
 test text5
 test text6""")
```
I think it should work assuming that the indentation of 
{get_something_string()} and the indentation of test text2 are on the same line.

--
versions:  -Python 3.10, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[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
test text4""")

textwrap.dedent(f"""\
test text1
{get_something_string()}
test text5
test text6""")
```

I look forward to the following results.

```
test text1
test text2
test text3
test text4
test text5
test text6
```

But the actual result is:
```
test text1
test text2
test text3
test text4
test text5
test text6
```

I understand that this code works in this way because the intent of the string 
defined inside the method is different from the intent of the string outside 
the method.

However, regular users, like me, will think of having a consistent intent 
result value. (because they believe dedent will clear a consistent intent)

If you are concerned that the existing code will be broken, I can implement 
the function using the flag parameter.

If you agree with my opinion, I will submit a PR.

--
components: Library (Lib)
messages: 414972
nosy: xncbf12
priority: normal
severity: normal
status: open
title: If use textwrap.dedent with string formatting, may get unintended 
sentences.
type: behavior
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9

___
Python tracker 
<https://bugs.python.org/issue46992>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

John Belmonte  added the comment:

PEP at https://github.com/python/peps/pull/2295

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

John Belmonte  added the comment:

Thank you Mark and Eric.

> I'll note that the paper is proposing a 'z' modifier to the sign, so I guess 
> for us that would translate to: [sign[optional-z]] instead of just sign.  I'd 
> have to noodle through the differences between that the proposed [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 "own" 
> the string formatting, taking that responsibility away from mpdecimal, but 
> there are already other reasons to do that."""

In the PR I was able to avoid taking that on by preprocessing the format string 
before handing it to mpdecimal.  The code was already doing such things to 
handle the NULL fill character.

--

___
Python tracker 
<https://bugs.python.org/issue45995>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Eric V. Smith]

Eric V. Smith  added the comment:

Wow, thanks, Mark!

I'm generally in favor. The selling points to me are that it needs to happen 
post-rounding, and the C++ discussion. It would be better if this were already 
accepted in C++. I'll note that the paper is proposing a 'z' modifier to the 
sign, so I guess for us that would translate to: [sign[optional-z]] instead of 
just sign. I'd have to noodle through the differences between that the proposed 
[sign][~]. I guess this would all be worked out in a PEP.

My only reservation is Mark's 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."""

If Mark is okay with that (right back at you, Mark!), then I think a PEP is the 
next step. It doesn't need to be huge, sort of like PEP 378.

--

___
Python tracker 
<https://bugs.python.org/issue45995>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Mark Dickinson]

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 still likely some iterations needed 
I'm satisfied that this is technically feasible.

But I'm afraid that's the easy part. If this is to go in, the other problem we 
still have to solve is achieving some consensus among the core developers that 
this is worth doing. Right now, judging by comments on this issue, I think I'm 
the only core dev who thinks this is a good idea; others are lukewarm at best, 
and I'm not willing to unilaterally approve and merge these changes without 
something closer to a consensus. There are a couple of ways forward here:

- Post the proposal on python-ideas to get wider visibility and feedback. If 
everyone agrees this is a great idea (from experience, this seems an unlikely 
outcome), then we can go ahead and merge. Otherwise we'd likely need a PEP to 
move forward.

- Bypass the python-ideas step, write the PEP, discuss in the appropriate 
forums, and then submit to the SC for approval / rejection.

- Convince Eric Smith. :-) With apologies to Eric for singling him out: Eric 
could reasonably be described as the steward/maintainer of the formatting 
machinery, so if he's persuaded, that's good enough for me.

The fact that you've already created a working implementation so that people 
can experiment is a bonus when it comes to trying to sell this to others.

I don't have the bandwidth to write a PEP, but I would be happy to act as PEP 
sponsor.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Irit Katriel]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Peder Bergebakken Sundt]

Change by Peder Bergebakken Sundt :


--
type:  -> crash

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Peder Bergebakken Sundt]

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: Library (Lib)
files: repro.py
messages: 40
nosy: pbsds
priority: normal
severity: normal
status: open
title: argparse subparser help text is not escaped before string formatting
versions: Python 3.10, Python 3.7, Python 3.8, Python 3.9
Added file: https://bugs.python.org/file50569/repro.py

___
Python tracker 
<https://bugs.python.org/issue46453>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

John Belmonte  added the comment:

Mark, would you give it a review this month?  (PR has been marked stale.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks, John. I should have time to review within the next week or so.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Mark Dickinson]

Change by Mark Dickinson :


--
assignee:  -> mark.dickinson

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

John Belmonte  added the comment:

implemented float and Decimal-- PR is ready for review

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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 
mpdecimal (and why the existing source copy inside Python doesn't count as a 
fork):
  https://bugs.python.org/issue45708#msg405895
  https://github.com/python/cpython/pull/29438

If I understand correctly, the PR for supporting underscore separators in 
Decimal formatting is only taking control of generating a mpd_spec_t from the 
spec string.  Formatting itself is still done by mpd_qformat_spec().

So there's outstanding work to also pull the formatting code itself into 
_decimal.c.  (And this is wanted anyway to reconcile existing libmpdec 
formatting modifications:  
https://github.com/python/cpython/commit/298131a44896a4fec1ea829814ad52409d59aba5)

And this is all because vendors have the crazy practice of unbundling libmpdec 
from Python.  (If a project is bundling the source of another, there may be 
some reason...?)

--

___
Python tracker 
<https://bugs.python.org/issue45995>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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 implementation can defeat it by intentionally failing if 
unknown bits are encountered, but the code in question doesn't appear to be 
doing this.)

> You can round explicitly before formatting
>
>>>> '%5.1f' % (round(-.1, 1) + 0.0)

Yes, I have experience with it.

  1. even as a one-off, it's questionable.  If someone accidentally changes the 
precision in only one of the spec string or round call, that's a bug.
  2. since applications and libraries may pass around format specs, and because 
of (1), you'll try to make a programmatic solution.  Now you're parsing format 
spec strings.
  3. while a programmatic solution can be done for a function API like format() 
that takes a separate spec and value, there is no sane way to wrap f-strings

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Eric V. Smith]

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 reasons (new code setting 
the flag being used in old versions of python without it), but we'd need to 
research. I saw a similar discussion within the last few years, but of course 
now I can't find it. Maybe old versions would correctly ignore the new bit 
being set.

This proposal becomes less interesting if we'd need to add a new function to 
support it. Although I guess we could do something that's internal-only.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Eric V. Smith]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Steven D'Aprano]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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.

For example, the dtoa case is as simple as this change to format_float_short():

/* coerce negative zero to positive */
if (sign == 1 && ((digits_len == 0 && decpt == -1) ||
  (digits_len == 1 && digits[0] == '0'))) {
sign = 0;
}

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Serhiy Storchaka]

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 would be better to round up, down, toward 
zero or infinity (seed for example issue44884).

You can round explicitly before formatting, but this solution is also 
applicable for this issue:

>>> '%5.1f' % (round(-.1, 1) + 0.0)
'  0.0'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Mark Dickinson]

Mark Dickinson  added the comment:

I'd support having this functionality available for `format` and for f-strings. 
(As Steven says, changing %-formatting doesn't seem viable.) It really _is_ 
awkward to do this in any other way, and I'm reliably informed that normal 
people don't expect to see negative zeros in formatted numeric output.

It did take me a few minutes to get my head around the idea that 
`f"{-0.01:+.1f}"` would return `"+0.0"` rather than `"-0.0"` or `" 0.0"` or 
just plain `"0.0"` under this proposal, but I agree that it seems like the only 
thing that can be consistent and make sense.

I'm not 100% convinced by the particular spelling proposed, but I don't have 
anything better to suggest. If C++ might be going with a "z", would it make 
sense to do the same for Python?

I don't forsee any implementation 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.

--

___
Python tracker 
<https://bugs.python.org/issue45995>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Mark Dickinson]

Change by Mark Dickinson :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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 for C++20, but a consensus proposal is promised 
for C++23.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Steven D'Aprano]

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 format method and f-strings. (I suspect that 
unless you get immediate and uncontroversial agreement from multiple core 
developers, you may need to take it for further discussion and perhaps even a 
PEP.)

What you call a "distraction" I consider to be critical part of the display. 
The numbers you are displaying actually are negative, and rounding them for 
display does not change that. So they ought to show the minus sign. So I'm not 
really very sympathetic to this feature request.

--
nosy: +steven.daprano
versions: +Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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 make use of anything in the current formatting spec regarding precision, 
normalizing negative zero would need to be a proper option of the formatting 
spec.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[Serhiy Storchaka]

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, serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45995] string formatting: normalize negative zero

[John Belmonte]

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' % -.1
'  0.0'

format spec before:
  format_spec ::=  
[[fill]align][sign][#][0][width][grouping_option][.precision][type]
after:
  format_spec ::=  
[[fill]align][sign][~][#][0][width][grouping_option][.precision][type]
  where '~' is only allowed for number types

implementation: if '~' is present in the spec, add 0 to the value after 
applying precision

--
components: Library (Lib)
messages: 407792
nosy: John Belmonte
priority: normal
severity: normal
status: open
title: string formatting: normalize negative zero
type: enhancement

___
Python tracker 
<https://bugs.python.org/issue45995>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mark Shannon]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44683] String formatting

[Dennis Sweeney]

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'
>>> '{0[apple]}'.format(A()) # passes a string
key = 'apple'
'apple'
>>> '{0["1"]}'.format(A()) # passes the length-3 string including double-quotes
key = '"1"'
'apple'

There's no clear way to use str.format() to get the value for the string key 
"1". However, I don't think it makes sense to backwards-incompatibly change the 
behavior to pass the string "1" instead of the integer 1, since a common use is 
indexing with integers like

>>> "{0[0]}{0[2]}{0[4]}".format(("a", "b", "c, "d", "e"))
'ace'

This is an edge case, but it is aligned with the specification: according to 
https://docs.python.org/3/library/string.html#format-string-syntax,

"""Because arg_name is not quote-delimited, it is not possible to specify 
arbitrary dictionary keys (e.g., the strings '10' or ':-]') within a format 
string."""

--
nosy: +Dennis Sweeney

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44683] String formatting

[Mykyta]

Change by Mykyta :


Removed file: https://bugs.python.org/file50166/1.png

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44683] String formatting

[Mykyta]

New submission from Mykyta :

The formatting does not work correctly.

I have a dict with string representations of integers as keys, such as {'1': 
'a'} and trying to format it this way: '{0[1]}' and KeyError occurs. But I 
think it should not as '{0[a]}'.format(a) works properly 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 formatting
type: behavior
versions: Python 3.9
Added file: https://bugs.python.org/file50166/1.png

___
Python tracker 
<https://bugs.python.org/issue44683>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry Davis]

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 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry Davis]

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'
>>> format(1234.1234, '._4f')
'1234.123_4'
>>> format(1234.1234, '.f')  # still not allowed
'1234.123_4'
>>> format(1234.1234, '_.f')  # still not allowed

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry Davis]

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 
> consistency?)

Yes, but not for consistency with the above usage, instead it's so both 
fractional and integral underscores can be specified on their own.

Here is my attempt at updating the format spec. The only problem I have with it 
is that it allows a naked '.'; I don't know how to specify "dot must be 
followed by one or both of 'float_grouping' and 'precision'".

Current:
format_spec ::=  
[[fill]align][sign][#][0][width][grouping_option][.precision][type]

Proposed:
format_spec ::=  
[[fill]align][sign][#][0][width][grouping_option][.[float_grouping][precision]][type]
fill::=  
align   ::=  "<" | ">" | "=" | "^"
sign::=  "+" | "-" | " "
width   ::=  digit+
grouping_option ::=  "_" | ","
float_grouping  ::=  "_"
precision   ::=  digit+
type::=  "b" | "c" | "d" | "e" | "E" | "f" | "F" | "g" | "G" | "n" 
| "o" | "s" | "x" | "X" | "%"

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 :-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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'
>>> format(12_34_56.12_34_56, '_.f')# Fractional component only   
'123_456.123456'

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 
https://www.python.org/dev/peps/pep-0606/ and it was rejected.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry Davis]

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 other discussion of this idea that anyone can remember.

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...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

STINNER Victor  added the comment:

How backward incompatible and annoying would it be to modify the behavior of 
the existing "_f" format?

Do you see use cases which only want to group digits in the integer part but 
not the fractional part?

According to 
https://discuss.python.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 advantage of changing "_f" format is to keep backward compatibility: Python 
3.9 and older would not group digits in the fractional part, but at least they 
don't fail with an error. If you write code with "_._f" format, you need a 
fallback code path for Python 3.9 and older:

if sys.version_info >= (3, 10):
   text = f"my {...} very {...} long {...} and {...} complex {...} format 
string: x={x:_._f}"
else:
   text = f"my {...} very {...} long {...} and {...} complex {...} format 
string: x={x:_f}"

Or:

text = f"my {...} very {...} long {...} and {...} complex {...} format string:" 
+ (f"x={x:_f}" if sys.version_info >= (3, 10) else "x={x:_f}")

Or many other variants.

The main drawback is the risk to break tests relying on the exact output.

About the separator character and the number of digits per group, IMO there is 
no standard working in all countries and all languages. But since we have a 
strict rule of 3 digits with "_" separator, I am fine with doing the same for 
the fractional part. It's an "arbitrary" choice, but at least, it's consistent.

People wanting a different format per locale/language should write their own 
function. Once enough people will agree on such API, we can consider to add it 
to the stdlib. But for now, IMO 3 digits with "_" is good enough.

By the way, I agree that it's hard to read numbers with many digits in the 
decimal part ;-)

>>> f"{1/7:_.30f}"
'0.142857142857142849212692681249'

>>> f"{10**10+1/7:_.10f}"
'10_000_000_000.1428565979'

--

___
Python tracker 
<https://bugs.python.org/issue43624>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

STINNER Victor  added the comment:

> If we do anything for float, we should do the same for decimal.Decimal.

and complex ;-)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

Eric V. Smith  added the comment:

If we do anything for float, we should do the same for decimal.Decimal.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

Change by Eric V. Smith :


--
nosy: +eric.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Dominic Davis-Foster]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +vstinner

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 separators to the 
right of the decimal point."""
— Google Style Guide https://developers.google.com/style/numbers

The CRC math handbook uses groups of five after the decimal point.
See §1.2.4 in 
http://dl.icdst.org/pdfs/files/2a2cbcfc89598fd83c315ce45c1ee663.pdf


NIST Guide for using SI units:  """The digits of numerical values having more 
than four digits on either side of the decimal marker are separated into groups 
of three using a thin, fixed space counting from both the left and right of the 
decimal marker. For example, 15 739.012 53 is highly preferred to 15739.01253. 
Commas are not used to separate digits into groups of three. (See Sec. 
10.5.3.)"""
— page vi in https://physics.nist.gov/cuu/pdf/sp811.pdf#10.5.2

StackExchange question on the topic:
https://math.stackexchange.com/questions/182775/convention-of-digit-grouping-after-decimal-point

The important reference, ISO 8:1 discusses this in section 7, "Printing 
rules", but the standard is not publicly available.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Terry Davis]

New submission from Terry Davis :

Proposal:
Enable this
>>> format(12_34_56.12_34_56, '_._f')
'123_456.123_456'

Where now only this is possible
>>> format(12_34_56.12_34_56, '_.f')
'123_456.123456'


Based on the discussion in the Ideas forum, three core devs support this 
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 2021-05-03.
https://www.python.org/dev/peps/pep-0619/#id5

--
components: Interpreter Core
messages: 389508
nosy: Terry Davis
priority: normal
severity: normal
status: open
title: Add underscore as a decimal separator for string formatting
type: enhancement
versions: Python 3.10

___
Python tracker 
<https://bugs.python.org/issue43624>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Petr Viktorin]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Petr Viktorin]

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 missing?

--
nosy: +petr.viktorin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Shubham Upreti]

Shubham Upreti  added the comment:

Should i take this issue?

--
nosy: +shubh07

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Benjamin Peterson]

Change by Benjamin Peterson :


--
keywords: +easy
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Gordon P. Hemsley]

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 not support a 'u' option and my 
archaeology suggests that such support was removed in Python 2.4. It seems this 
has flown under the radar for quite some time.

--
assignee: docs@python
components: Documentation
messages: 371474
nosy: alexandre.vassalotti, benjamin.peterson, berker.peksag, christian.heimes, 
docs@python, eli.bendersky, ezio.melotti, georg.brandl, gphemsley, 
martin.panter, ncoghlan, rhettinger
priority: normal
severity: normal
status: open
title: Documentation still mentions 'u' string formatting option
type: behavior
versions: Python 3.10, Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 
3.9

___
Python tracker 
<https://bugs.python.org/issue40971>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38657] Clarify numeric padding behavior in string formatting

[Mark Dickinson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38657] Clarify numeric padding behavior in string formatting

[miss-islington]

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


--

___
Python tracker 
<https://bugs.python.org/issue38657>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38657] Clarify numeric padding behavior in string formatting

[miss-islington]

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


--

___
Python tracker 
<https://bugs.python.org/issue38657>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38657] Clarify numeric padding behavior in string formatting

[miss-islington]

Change by miss-islington :


--
pull_requests: +17958
pull_request: https://github.com/python/cpython/pull/18588

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38657] Clarify numeric padding behavior in string formatting

[miss-islington]

Change by miss-islington :


--
pull_requests: +17957
pull_request: https://github.com/python/cpython/pull/18587

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38657] Clarify numeric padding behavior in string formatting

[miss-islington]

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


--
nosy: +miss-islington

___
Python tracker 
<https://bugs.python.org/issue38657>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue38657] Clarify numeric padding behavior in string formatting

[Eric V. Smith]

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/issue38657>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Cédric Krier]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36787] Python3 regresison: String formatting of None object

[Eric V. Smith]

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 that doesn't apply to it should be an error. If you 
want to support strings or None, then it's your job to ensure the conversion.

As issue7994 says, one of the big drivers of this change (I'll argue it's 
really a bugfix) was that you could never add __format__ to  class if it didn't 
previously have one. Or if you did, it would have to support at least the 
string format spec, since there might be code that formatted it with "^10", for 
example.

As things currently stand, we could add __format__ to NoneType and have "T/F" 
mean convert to "True" or "False". If NoneTypes were already format-able with 
"^10", this change wouldn't be possible.

--
assignee:  -> eric.smith
resolution:  -> not a bug
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36787] Python3 regresison: String formatting of None object

[Zachary Ware]

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.

See issue7994 for the background on the change that produced this behavior.

--
nosy: +eric.smith, zach.ware
versions: +Python 3.8

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36787] Python3 regresison: String formatting of None object

[Gawain Bolton]

Gawain Bolton  added the comment:

Note: I have a patch which fixes this.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue36787] Python3 regresison: String formatting of None object

[Gawain Bolton]

New submission from Gawain Bolton :

Python 2.7.16 (default, Apr  6 2019, 01:42:57)
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.  
  
>>> print('{:^10}'.format(None))
   None

However this does not work with Python3:
Python 3.7.3 (default, Apr  3 2019, 05:39:12)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.  
  
>>> 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  
 string formatting options to be 
usable with it.  It also makes code 
 less fragile and avoids having to write special cases for when 
values 
could be None.

--
components: Library (Lib)
messages: 341355
nosy: Gawain Bolton
priority: normal
severity: normal
status: open
title: Python3 regresison: String formatting of None object
type: behavior

___
Python tracker 
<https://bugs.python.org/issue36787>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eric V. Smith]

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 wouldn't recommend making any changes.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Matthew Barnett]

Matthew Barnett  added the comment:

A similar issue exists with centring:

>>> format(42, '^020')
'0420'

--
nosy: +mrabarnett

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

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')
'4200'
>>> '%-020x' % 42
'2a  '
>>> format(42, '<020x')
'2a00'
>>> '%-020g' % 1.2e-8
'1.2e-08 '
>>> format(1.2e-8, '<020')
'1.2e-080'
>>> format(1.2e-8, '<020g')
'1.2e-0800000'
>>> format(1.2e-8, '<020e')
'1.20e-08'

New-style string formatting produces the result that looks like a correctly 
formatted number, but it represents incorrect number.

I think that zero padding should not be allowed for left-aligned format for 
numbers (except the 'f' format). Zero padding is already disallowed for complex 
numbers.

--
components: Interpreter Core
messages: 332231
nosy: eric.smith, serhiy.storchaka
priority: normal
severity: normal
status: open
title: String formatting produces incorrect result with left-aligned 
zero-padded format

___
Python tracker 
<https://bugs.python.org/issue35546>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Stefan Krah]

Change by Stefan Krah :


--
nosy: +skrah

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[James Emerton]

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 the locale specific 'n' format 
types.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Raymond Hettinger]

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 string formatting.  I'll defer to those with more experience 
using locale -- I just have a vague recollection of this being an area fraught 
with landmines.

--
nosy: +rhettinger

___
Python tracker 
<https://bugs.python.org/issue33731>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[James Emerton]

James Emerton  added the comment:

So far, I've implemented this for Decimal

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

Change by Roundup Robot :


--
keywords: +patch
pull_requests: +8118
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[James Emerton]

Change by James Emerton :


--
nosy: +jemerton

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tal Einat]

Change by Tal Einat :


--
nosy:  -taleinat

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tal Einat]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: print & string formatting

[Sharan Basappa]

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 variables after builtin classes ("str" is the name of 
> Python's string class).
> 
> >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
> 
> For a bare "%s", one would normally just write str(s) where "s" is your 
> string 
> variable.
> 
> The % formatting is usually for (a) more complex messages or (b) separating 
> the 
> message format from the values. Example:
> 
>   print("The time is %s and the place is %s." % (when, where))
> 
> Instead of the much harder to read and maintain:
> 
>   print("The time is", str(when), "and the place is", str(where), ".")
> 
> Cheers,
> Cameron Simpson 

Thanks. I thin I understand.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print & string formatting

[Thomas Jollans]

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 classes ("str" is the name
> of Python's string class).
> 
>> 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
> 
> For a bare "%s", one would normally just write str(s) where "s" is your
> string variable.
> 
> The % formatting is usually for (a) more complex messages or (b)
> separating the message format from the values. Example:
> 
>  print("The time is %s and the place is %s." % (when, where))
> 
> Instead of the much harder to read and maintain:
> 
>  print("The time is", str(when), "and the place is", str(where), ".")

Also, the output is different (there's an extra space before the full stop)

> 
> Cheers,
> Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: print & string formatting

[Cameron Simpson]

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).



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


For a bare "%s", one would normally just write str(s) where "s" is your string 
variable.


The % formatting is usually for (a) more complex messages or (b) separating the 
message format from the values. Example:


 print("The time is %s and the place is %s." % (when, where))

Instead of the much harder to read and maintain:

 print("The time is", str(when), "and the place is", str(where), ".")

Cheers,
Cameron Simpson 
--
https://mail.python.org/mailman/listinfo/python-list

Re: print & string formatting

[Chris Angelico]

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 I see being used in many programs I am referring to*
>
> well
> 1) that is more convenient than concatenation ""+x+""
> 2) no need for casting
> x = 64
> "%d" %(x)
> 3) the .format() or f'' makes it simpler and reflects the real spirit of py
> "{}".format(y) # no need to specify s or d etc

Not sure what you mean by "the real spirit of Python", but you can use
%s with literally any object at all, and it'll work - in fact, it'll
do the same thing that {} does in a format string.

But yes, the point of the formatting operations is to do more than
just format a string.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list