On 1/20/2020 10:59 PM, Karl O. Pinc wrote:
Hello,
There appears to be extremely minimal documentation on how floats are
formatted on output. All I really see is that float.__str__() is
float.__repr__(). So that means that float->str->float does not
result in a different value.
It would be nic
21.01.20 10:37, Eric V. Smith пише:
For what it's worth, float's repr internally uses a format of '.17g'.
So, format(value, '.17g') will be equal to repr(f), where f is any float.
It was in Python 2, but since Python 3.1 it returns the shortest
unambiguous representation, which may be shorter
On Mon, Jan 20, 2020 at 09:59:07PM -0600, Karl O. Pinc wrote:
> It would be nice if the output format for float was documented, to the
> extent this is possible.
I don't think we should make any promises about the repr() of floats.
We've already changed the format at least twice:
- once to swit
On 1/21/2020 4:32 AM, Serhiy Storchaka wrote:
21.01.20 10:37, Eric V. Smith пише:
For what it's worth, float's repr internally uses a format of '.17g'.
So, format(value, '.17g') will be equal to repr(f), where f is any
float.
It was in Python 2, but since Python 3.1 it returns the shortest
u
On Tue, 21 Jan 2020 21:09:57 +1100
Steven D'Aprano wrote:
> On Mon, Jan 20, 2020 at 09:59:07PM -0600, Karl O. Pinc wrote:
>
> > It would be nice if the output format for float was documented, to
> > the extent this is possible.
>
> I don't think we should make any promises about the repr() of
On Tue, Jan 21, 2020 at 09:01:29AM -0600, Karl O. Pinc wrote:
> Understood. But you still might want to document, or even define in the
> language, that you're outputting the shortest unambiguous
> representation.
I'm not even sure I would want to do that. That would make it a language
guarante
On 1/21/2020 11:52 AM, Steven D'Aprano wrote:
I don't really care whether there's documentation for __str__() or
__repr__() or something else. I'm just thinking that there should
be some way to guarantee a well defined "useful" float output
formatting.
https://docs.python.org/3/library/stdtypes
On Wed, Jan 22, 2020 at 4:03 AM Eric V. Smith wrote:
> The reason repr adds the '.0' that 'g' does not is to avoid this problem:
>
> >>> type(eval(repr(17.0))) == type(17.0)
> True
> >>> type(eval(format(17.0, '.17g'))) == type(17.0)
> False
>
The OP wasn't asking about eval, though, but about
On 1/21/2020 1:32 PM, Chris Angelico wrote:
On Wed, Jan 22, 2020 at 4:03 AM Eric V. Smith wrote:
The reason repr adds the '.0' that 'g' does not is to avoid this problem:
>>> type(eval(repr(17.0))) == type(17.0)
True
>>> type(eval(format(17.0, '.17g'))) == type(17.0)
False
The OP wasn't
21.01.20 12:37, Eric V. Smith пише:
Yes (I wrote a lot of that), but '.17g' doesn't mean to always show 17
digits. See
https://github.com/python/cpython/blob/master/Python/pystrtod.c#L825
where the repr (which is format_code =='r') is translated to format_code
= 'g' and precision = 17.
But I
On 1/21/2020 2:02 PM, Serhiy Storchaka wrote:
21.01.20 12:37, Eric V. Smith пише:
Yes (I wrote a lot of that), but '.17g' doesn't mean to always show
17 digits. See
https://github.com/python/cpython/blob/master/Python/pystrtod.c#L825
where the repr (which is format_code =='r') is translated to
[Serhiy Storchaka]
> This is not the only difference between '.17g' and repr().
>
> >>> '%.17g' % 1.23456789
> '1.23456788'
> >>> format(1.23456789, '.17g')
> '1.23456788'
> >>> repr(1.23456789)
> '1.23456789'
More amazingly ;-), repr() isn't even always the same as a %g format
spe
I am really confused on writing python and what app I need to write it in any
tips or any ideas for apps??
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/l
Hi Zak, and welcome!
This list is for discussing the current and future development of the
CPython interpreter, not a general help-desk for Python beginners.
When you signed up to this email list, the signup page says:
Do not post general Python questions to this list. For help with
Py
On Tue, 21 Jan 2020 09:01:29 -0600
"Karl O. Pinc" wrote:
> I guess I will advocate for _some_ specification built into Python's
> definition. Otherwise everybody should _always_ build their own
> formatter; lest they wake up one morning and find that int zero prints
> as "+0".
Having made a sug
15 matches
Mail list logo
