[issue39416] Document default numeric string formats
New submission from Karl O. Pinc : Seems sane to put _some_ restrictions on the string representations of the Numeric classes. This would be a change to the Python language specification. Suggestions made in a pull request. See the email thread: Subject: Documenting Python's float.__str__() https://mail.python.org/archives/list/python-...@python.org/thread/FV22TKT3S2Q3P7PNN6MCXI6IX3HRRNAL/ -- assignee: docs@python components: Documentation messages: 360442 nosy: docs@python, kop priority: normal severity: normal status: open title: Document default numeric string formats ___ Python tracker <https://bugs.python.org/issue39416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39416] Document default numeric string formats
Change by Karl O. Pinc : -- keywords: +patch pull_requests: +17498 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18111 ___ Python tracker <https://bugs.python.org/issue39416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39416] Document default numeric string formats
Karl O. Pinc added the comment: On Wed, 22 Jan 2020 06:09:41 + "Eric V. Smith" wrote: > Eric V. Smith added the comment: > > Is the lack of this documentation causing some confusion somewhere? > This isn't rhetorical, I'm genuinely curious what problem you're > trying to solve. I'd say no, there's no real confusion anywhere. This started with a search for documentation on Python's default string representation for float. This accidentally wound up on the python-dev mailing list and became a more general discussion during which I suggested that some fundamentals are clear. This is pretty much just a follow-up to that discussion. > Is there any mainstream programming language where the basics of what > you've laid out aren't true? It all seems pretty obvious to me. For > example, I can't see anyone looking at this and saying "Ah, base 10. > That's why it's producing the output I'm seeing." Well, I just got done looking at YAML which has a lot of base-related syntax including base 60. :) The problem that would be solved is that it's easy to rely on the default Numeric output formats. Most output probably does not go through a formatter, although this may change now that f-strings are so easy. Anyway, this would guarantee "normal output" for numbers, even when switching between Python implementations. Likewise, immutability of value when round-tripping through a string is also obvious. But is still an important property. So if these properties are important then include them in the spec. That's what specs are for. (I could probably find some non-mainstream languages (scheme perhaps) that have specs which include similar documentation. You pretty have to have a formatter in compiled languages, so those won't specify a default. Anyway, it shouldn't matter what other language specs do.) I understand if nobody sees this as a real problem. And I don't want to stand up as a big proponent. I'll point out the argument here and let others decide. Regards, Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein -- ___ Python tracker <https://bugs.python.org/issue39416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39416] Document default numeric string formats
Change by Karl O. Pinc : -- pull_requests: +21809 pull_request: https://github.com/python/cpython/pull/22867 ___ Python tracker <https://bugs.python.org/issue39416> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23814] argparse: Parser level defaults do not always override argument level defaults
New submission from Karl O. Pinc:
In the argparse library parser library, contrary to the documentation,
parser-level defaults do not always override argument-level defaults.
https://docs.python.org/3.5/library/argparse.html#argparse.ArgumentParser.set_defaults
says "Note that parser-level defaults always override argument-level defaults:"
(And so does the python 3.3 docs.)
The docs then provide this example:
>>> parser = argparse.ArgumentParser()
>>> parser.add_argument('--foo', default='bar')
>>> parser.set_defaults(foo='spam')
>>> parser.parse_args([])
Namespace(foo='spam')
But it is only true that parser-level defaults override argument-level
defaults when they are established after the argument is added.
The output below shows an argument level default overrideing
a parser level default.
$ python3
Python 3.3.2 (default, Jun 4 2014, 11:36:37)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-4)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import argparse
>>> parser = argparse.ArgumentParser()
>>> parser.set_defaults(foo='spam')
>>> parser.add_argument('--foo', default='bar')
_StoreAction(option_strings=['--foo'], dest='foo', nargs=None, const=None,
default='bar', type=None, choices=None, help=None, metavar=None)
>>> parser.parse_args([])
Namespace(foo='bar')
It seems that whichever default is set last is the one which is used.
Or perhaps there are not argument level defaults and parser level
defaults, there are just defaults, period. (It might, possibly,
be nice if there _were_ both argument and parser level defaults
and parser level defaults had priority. Then this would not be
a documentation bug.)
--
assignee: docs@python
components: Documentation
messages: 239632
nosy: docs@python, kop
priority: normal
severity: normal
status: open
title: argparse: Parser level defaults do not always override argument level
defaults
type: behavior
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue23814>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
