[issue26362] Approved API for creating a temporary file path
Ben Finney added the comment: > tempfile.mktemp() still exists and works without raising a deprecation > warning. Of course it's still marked as deprecated in the docs. Right. So, the issue is not resolved: Functionality to create a temporary file path is maintained in the standard library (good) but the public API for it is unsupported. > Does anyone still want this tempfile.makepath() function? That's a proposed name. But yes, a supported function in the `tempfile` standard library module, which does what's described in this issue. > Or can this issue be closed? The issue remains unresolved. Unless you can point us to something new which resolves this? So no, while unresolved, this bug report should not be closed. -- ___ Python tracker <https://bugs.python.org/issue26362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23297] Clarify error when ‘tokenize.detect_encoding’ receives text
Ben Finney added the comment: On 28-Apr-2019, Berker Peksag wrote: > The original problem has already been solved by making > tokenize.generate_tokens() public in issue 12486. I don't understand how that would affect the resolution of this issue. Isn't the correct resolution here going to entail correct implementation in ‘file.readline’? -- ___ Python tracker <https://bugs.python.org/issue23297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33130] functools.reduce signature uses `iterable`, documentation should use the same term
Ben Finney added the comment: Hah, sorry to use a local-filesystem URL. (Hooray for locally-installed developer documentation!) The same section is online at https://docs.python.org/3/library/functools.html#functools.reduce . -- ___ Python tracker <https://bugs.python.org/issue33130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33130] functools.reduce signature uses `iterable`, documentation should use the same term
Ben Finney added the comment: The library documentation (e.g. file:///usr/share/doc/python3/html/library/functools.html#functools.reduce ) also has this dissonance: > functools.reduce(`function`, `iterable` [, `initializer` ]) > >Apply function of two arguments cumulatively to the items of `sequence`, > from left to right, so as to reduce the sequence to a single value. -- nosy: +bignose title: functools.reduce signature/docstring discordance -> functools.reduce signature uses `iterable`, documentation should use the same term ___ Python tracker <https://bugs.python.org/issue33130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Ben Finney added the comment: On Thu, 2018-06-14 23:46 +, Aaron Meurer wrote: > Couldn't such a tool exist outside the standard library. I've tried writing such a tool. It would ideally re-use as much as feasible of the functionality that assembles the usage message. But that is hampered by the fact the usage message generation is not easily accessible from outside. I am hoping that, in order to re-use that functionality, a common set of “take the argument collection as input, generate a document structure” functionality can be factored out for other use — initially, for generating a manual page. So this bug report asks for that work to be done in the ‘argparse’ library. > Installing the manpage is a separate concern. Yes, I agree. That is not part of this bug report. -- ___ Python tracker <https://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Ben Finney added the comment: On Thu, 2018-06-14 20:02 +, Pablo Galindo Salgado wrote: > The (possible) confusion is the existence of a manpage only available > though argparse (`./python foo.py --manpage`) This report isn't asking for that. (I see only one person proposing such an interface, and even that person said it's not a good idea.) So please don't conflate that with the original bug report. > I am not sure how many people do something like `./python poc_2.py > output > && man ./output` to **read** the manpage. Right, I am not asking for anything like that; I'm not asking that ‘argparse’ grow a way to read a manual page,. I am asking only for a standard way to programmatically generate that manual page from the information ‘argparse’ already knows. > >This is asking that the ‘argparse’ library should have an API to > >create a manual page, for use in the build system. > > At this point argparse is user facing in the sense that once configured, > it provides functionality for the user of the command line application. > My opinion is that it will be weird to have it provide also APIs for > creating man pages (which is a developer utility). Creating an argument parser itself is already a developer activity, and we don't see that as weird that ‘argparse’ allows for that. I'm arguing that the library already knows how to turn the argument collection into a user-facing document (the usage message), and a manual page is a different way of rendering that same internal data. So that's why ‘argparse’ is a consistent place to have that functionality. > My humble opinion is > that it if argparse starts to provide APIs for usage at install time is > not "doing one thing and doing it well". That API already exists: the specific ‘ArgumentParser’ is available to be imported for a program which defines one. So, the library already provides APIs for usage at install time (or any other run-time). I am asking to make that API more useful for the distribution of programs. -- ___ Python tracker <https://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Ben Finney added the comment: On 14-Jun-2018, Pablo Galindo Salgado wrote: > I think this should be something that is not included in argparse > itself. I can imagine a scenario in which the manpage is accessible > through `./python foo.py --manpage` but the manpage is not installed > systemwide. This bug report is not asking that ‘argparse’ install a manual page, and it is not asking for any new command-line option in programs. So I don't know the relevance of that point. > This will be very confusing for users. What would cause that confusion? This is not something that would change how ‘argparse’ parses its arguments, so I don't know what you're referring to. > Generating a man page in a build script sounds like something that > should be on its own or as a help function of the build system. This is asking that the ‘argparse’ library should have an API to create a manual page, for use in the build system. The reason to have it in the ‘argparse’ library is that the library already knows how to build a single document (the ‘--help’ output) from the collection of arguments, so this would be just another rendering of that information. It makes sense to have it in the ‘argparse’ library as an API for other tools to use. -- ___ Python tracker <https://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21720] "TypeError: Item in ``from list'' not a string" message
Ben Finney <ben+pyt...@benfinney.id.au> added the comment: On 23-Oct-2017, Serhiy Storchaka wrote: > Is it all with this issue? I accept Nick's reasoning: > As a general principle, we don't give value information in type > errors, since the error is structural rather than value based. as sufficient to reject my requested improvement to the message. The change in <URL:https://hg.python.org/cpython/rev/7dd0910e8fbf> is good enough, IMO. -- status: pending -> open ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue21720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Correct the parsing of a test case docstring.
Ben Finney added the comment: > I have already created such a pull requests. It is bidirectionally linked to > this ticket. I hope the PSF can start accepting contributions without that laundering, but until then: thank you for taking that on. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Correct the parsing of a test case docstring.
Ben Finney added the comment: > if you upload a patch generated from your branch here, someone else will > create the github PR so we can get it processed. The branch has several commits. I have generated the patches, and am now uploading them as a tarball. It may be easier to simply merge from the Git branch, https://rocketgit.com/user/benf_wspdigital/cpython/source/log/branch/wip,issue,issue30181_parse-docstring-using-pydoc -- Added file: http://bugs.python.org/file46859/issue30181-fix.cfc063a9.tar.gz ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Correct the parsing of a test case docstring.
Ben Finney added the comment: > No, your contribution will not be rejected by "you don't maintain the repo on > GitHub", everyone can send the patch (PR) to python/cpython. I am glad to know that. I won't be maintaining a GitHub account because I disagree with the terms of service. > Ben, if you have any problem about how to get on with GitHub, I can help you > […] Thank you for the offer. My problem with how to get on with GitHub is I don't accept their terms of service :-) How do we proceed? Git is a *decentralised* VCS, it should not be a barrier that I make the contribution from a different repository host. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Correct the parsing of a test case docstring.
Ben Finney added the comment: Apparently there is some consternation about my bugs.python.org identity. This is Ben Finney of WSP Digital, in Melbourne, Australia. A GitHub account is wholly irrelevant to this account. A GitHub account is wholly irrelevant to accepting the PSF CLA. This bugs.python.org account `benf_wspdigital` does not mention a GitHub account, and that's the way I want to keep it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26362] Approved API for creating a temporary file path
Ben Finney added the comment: On 01-May-2017, Serhiy Storchaka wrote: > tempfile.mktemp() is not much more useful that just a function that > generates some names which unlikely matches the names of existing > files the directory. Yes. That is already useful enough to be in the standard library, and it is there. It is also maintained and implemented in one place, behind an unpublished API (by using ‘next(tempfile._get_candidate_names())’). Don't get distracted by the way ‘tempfile.mktemp’ creates files; that's irrelevant to this issue. None of the use cases presented here care at all about the file created, and never use that file. They *only* want the name, generated by that standard-library algorithm. The proposal in this issue is to have a public standard library API, which I'm calling ‘tempfile.makepath’, to access that existing maintained standard-library functionality. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26362] Approved API for creating a temporary file path
Ben Finney added the comment: On 01-May-2017, R. David Murray wrote: > You are depending on a non-portable feature of os.rename there What's the non-portable dependency? If you mean the expectation that ‘os.rename’ will be atomic on success: the documentation promises “If successful, the renaming will be an atomic operation”, without any non-compatibility caveat <URL:https://docs.python.org/3/library/os.html#os.rename>. If you mean the ‘except OSError’ clause: that's not a dependency of this example. It is handling a case that is documented to occur on some platforms. On platforms that don't have that behaviour, the clause is not a dependency of this use case. Neither of those is germane to the use case being demonstrated: the need for a temporary filesystem path as generated by ‘tempfile.mktemp’. > so I'm not convinced this makes a good use case for the Python > stdlib. Note that Tim Chase is *not* presenting a use case for ‘os.rename’, but rather a use case for ‘tempfile.mktemp’. For that purpose it seems a valid use case. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Correct the parsing of a test case docstring.
Ben Finney added the comment: On 2017-05-01 17:45, Louie Lu wrote: > Ben, the process of submitting PR was migrated to GitHub Thank you. I'll re-base my branch onto the master branch found at the GitHub repository. > you will need to use a GitHub account to do it I don't maintain repositories at GitHub. Does that mean the contribution must be rejected? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Correct the parsing of a test case docstring.
Ben Finney added the comment: Howdy R. David, Okay, I have put together a series of commits to address this bug. The changes are in my personal fork of the ‘cpython’ repository, so this is a pull request from ‘wip/issue/issue30181_parse-docstring-using-pydoc’ in that repository. The following changes since commit 8550803dfba4cf7018ee7415593ceb34c52923e6: Backed out changeset f23fa1f7b68f (2017-02-10 14:19:36 +0100) are available in the git repository at: https://benf_wspdigi...@bitbucket.org/benf_wspdigital/cpython.git for you to fetch changes up to c2de731582a9da1147a300a991890ff663891e75: Parse the test case docstring using `pydoc.splitdoc`. (2017-05-01 16:55:52 +1000) (from the branch description for wip/issue/issue30181_parse-docstring-using-pydoc local branch) Correct the parsing of a test case docstring. Ben Finney (4): Add test cases for single-line test case docstring. Add test cases for stripping surrounding space for shortDescription. Add test cases for test case docstring with surrounding newlines. Parse the test case docstring using `pydoc.splitdoc`. Lib/unittest/case.py | 34 -- Lib/unittest/test/test_case.py | 42 ++ Lib/unittest/test/test_functiontestcase.py | 58 +- 3 files changed, 115 insertions(+), 19 deletions(-) -- title: Incorrect parsing of test case docstring -> Correct the parsing of a test case docstring. ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Incorrect parsing of test case docstring
Ben Finney added the comment: > This is because unittest.TestCase method `shortDescription()` will only > return the first line of docstring Yes, that is the “docstring synopsis” I referred to. PEP 257 has a section specifically about how tools should parse a docstring: https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation In particular, note that “ Blank lines should be removed from the beginning and end of the docstring.” So, the “first line of the docstring“ for the example ‘test_reverse_returns_expected_text’ is the text “Should return expected reverse text.”. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30181] Incorrect parsing of test case docstring
New submission from Ben Finney: The docstring of a test case is not correctly parsed for display. The attached ‘test_foo.py’ module contains two test case functions. Both docstrings conform to PEP 257 <https://www.python.org/dev/peps/pep-0257/>: they have a single-line synopsis and some extra text in a new paragraph. However, only one of the functions has its docstring synopsis used in the output: = == FAIL: test_lower_returns_expected_code (test_foo.Foo_TestCase) Should return expected code. -- Traceback (most recent call last): […] == FAIL: test_reverse_returns_expected_text (test_foo.Foo_TestCase) -- Traceback (most recent call last): […] -- Ran 2 tests in 0.001s = This violates the docstring parsing as described in PEP 257. The synopsis should be obtained by, first, stripping leading and trailing whitespace from the docstring; then, from that stripped text, taking the first line as the synopsis. So the expected output for ‘test_foo.Foo_TestCase. test_reverse_returns_expected_text’ should include its docstring synopsis, “Should return expected reverse text.” -- components: Library (Lib) files: test_foo.py messages: 292387 nosy: benf_wspdigital priority: normal severity: normal status: open title: Incorrect parsing of test case docstring type: behavior versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46831/test_foo.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30181> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21720] "TypeError: Item in ``from list'' not a string" message
Ben Finney added the comment:
On 16-Oct-2016, Roundup Robot wrote:
> New changeset 7dd0910e8fbf by Berker Peksag in branch '2.7':
> Issue #21720: Improve exception message when the type of fromlist is unicode
> https://hg.python.org/cpython/rev/7dd0910e8fbf
This is an improvement, but it still should IMO show *which* item
caused the error.
Can it state “Item in from list must be str, not {type}: {item!r}”?
That would show the exact item so the reader has a better chance at
finding where it came from.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21720>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21720] "TypeError: Item in ``from list'' not a string" message
Ben Finney added the comment: On 12-Oct-2016, Nick Coghlan wrote: > In this case, I think just reporting the first failing item is fine, > and mentioning the type of that item in the error message is the > most useful additional information we can provide to make things > easier to debug. Yes; also, the type expected, so the user knows what's different from expected. That is, the error message should say exactly what type is expected *and* exactly what type failed that check. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21720> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12916] Add inspect.splitdoc
Ben Finney added the comment: Am I right that this: > pydoc doesn't have public API other than its CLI and the help() function. > […] On the other hand, there are already functions related to splitdoc() > in the inspect module […]. > There is no rush to make splitdoc() public. We can improve pydoc in 3.5 > and 3.6 timeline and then decide what's should be part of the public API. represents the latest on this issue? We now have the alpha phase of Python 3.6. Can we get a resolution that makes ‘splitdoc’ public somewhere? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15660] Clarify 0 prefix for width specifier in str.format doc,
Ben Finney added the comment: Terry Reedy wrote: > If the spec string is still available, it could be searched and the message > adjusted if '=' is not present. That proposal should be a new issue if > someone wants to push it. Done now, see Issue 27772. -- nosy: +bignose ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue15660> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27772] Refer to actual format string when creating “zero padding” error message
New submission from Ben Finney: When using a format specifier with leading zero, the format spec mini-language (as documented at https://docs.python.org/3/library/string.html#format-specification-mini-language>) says: > '=' […] becomes the default when ‘0’ immediately precedes the field width. When the ‘=’ option is only implied, the error message “ValueError: '=' alignment not allowed in string format specifier” becomes surprising and incomprehensible to someone who does not know that implied behaviour. In issue 15560, Terry Reedy says: > If the spec string is still available, it could be searched and the message > adjusted if '=' is not present. That proposal should be a new issue if > someone wants to push it. This issue raises that proposal. The error message should be changed so that: * It makes sense whether or not the ‘=’ option is explicit in the format specifier. Or: * Different messages are produced when the ‘=’ option is explicit versus when it is implicit. I think the former option is better, but either will satisfy this request. -- messages: 272827 nosy: bignose priority: normal severity: normal status: open title: Refer to actual format string when creating “zero padding” error message versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27043] Describe what ‘inspect.cleandoc’ does to synopsis line.
Ben Finney added the comment: On 27-May-2016, Nathan Harold wrote: > > Split version (cleandoc2.patch): > >Clean up indentation from docstrings that are indented to line up >with blocks of code. > >All leading whitespace is removed from the first line. Any >leading whitespace that can be uniformly removed from the second >line onwards is removed. Empty lines at the beginning and end are >subsequently removed. Also, all tabs are expanded to spaces. That looks good to me. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27043] Describe what ‘inspect.cleandoc’ does to synopsis line.
Ben Finney added the comment: On Fri, May 27, 2016, at 02:58, Nathan Harold wrote: > Here's my shot at a revision (corresponding patch attached): Thanks for that. The only improvement I'd ask for is to more clearly separate the description into two paragraphs: overall description of the effect of the function; then, detailed description of the specific transformations. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27043] Describe what ‘inspect.cleandoc’ does to synopsis line.
New submission from Ben Finney: The library documentation for ‘inspect.cleandoc’ describes the transformation that occurs to “the second line onwards”, but makes no mention of what processing occurs to the synopsis (first) line. Please update the library documentation for this function, to explicitly describe how it processes each of the different parts of a docstring. If possible, this should be guided by PEP 257's discussion of how indentation is transformed: https://www.python.org/dev/peps/pep-0257/#handling-docstring-indentation -- assignee: docs@python components: Documentation messages: 265741 nosy: bignose, docs@python priority: normal severity: normal status: open title: Describe what ‘inspect.cleandoc’ does to synopsis line. type: enhancement versions: Python 2.7, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27043> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Changes by Ben Finney <ben+pyt...@benfinney.id.au>: -- versions: +Python 3.6 -Python 2.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14102] argparse: add ability to create a man page
Ben Finney added the comment: Oz Tiram wrote: > I doubt if the correct place for formatting a man page should be in > argparse.py itself. My solution is an extension of Andial's brecht solution Thank you for that, Oz. I see an easy seam to refactor this work into separate concerns. The formatting of a man page from the parser for the command, can be coupled to the ‘argparse’ module since it is dependent only on an ArgumentParser plus some extra properties for populating the man page. The building of one man page should not, IMO, be so tightly coupled to a Python distribution. There may be several different commands installed by one distribution. Each man page's fields should mostly come from the parser for the command, not from the distribution metadata. Instead, the build process should be told which parser to use for generating each of the man pages. I propose to work on Oz's module and produce a man page formatter for exactly one ArgumentParser, as an enhancement for ‘argparse’. -- nosy: +bignose ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14102> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26490] Leading “0” allowed, only for decimal zero
Ben Finney added the comment: > rationale unknown That's quite a pity. The inconsistency catches people out, and the docs do not make clear why an exception is made. > but any number of zeroes is still unambiguously zero. Of course. But the same is true for “0003 is unambiguously three”, yet that's invalid syntax. I won't contest closing this report. But the above is not an explanation for the inconsistency. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26490] Leading “0” allowed, only for decimal zero
New submission from Ben Finney: The language reference carves out a special case for decimal zero literals: they may have leading “0” digits. Non-zero decimal literals may not. This is apparently deliberate: Note that leading zeros in a non-zero decimal number are not allowed. This is for disambiguation with C-style octal literals, which Python used before version 3.0. reference/lexical_analysis.html#integer-literals But the expressed rationale (“for disambiguation with C-style octal literals”) does not explain making decimal zero special compared with non-zero. Is there a good reason for this inconsistency:: # valid syntax for zero literal 0003# SyntaxError 0123# SyntaxError To my reading, they should all cause SyntaxError. What is the rationale for the special case of the first one? -- components: Interpreter Core messages: 261227 nosy: bignose priority: normal severity: normal status: open title: Leading “0” allowed, only for decimal zero type: behavior versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26490> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26362] Approved API for creating a temporary file path
Ben Finney added the comment: Serhiy Storchaka > mktemp is deprecated, and I think we will get rid of it when 2.7 will be out > of use. That's fine. This is not a request to retain ‘tempfile.mktemp’. I confused matters in my initial message, so your confusion is understandable on this point. To repeat: The request is for a “get the next path generated by a ‘tempfile._get_candidate_names’ generator”, with an approved and documented public API. One suggested name is ‘tempfile.makepath’. > Do you want to add new deprecated from the start function? No. I'm asking for already-implemented and currently-maintained (i.e. not deprecated) standard library code, that is currently neither public nor documented, to gain a public API. Ethan Furman: > I don't see any problem with this. Patches welcome. Thank you, I'll work on a patch soon. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26362] Approved API for creating a temporary file path
Ben Finney added the comment: > I have read the thread on Python-list Thank you, and thanks for linking to that discussion. > and still don't understand the purpose of your idea. The purpose is to get a public API for making temporary filesystem paths with the same properties as are produced by ‘tempfile’, specifically as produced by a ‘tempfile._get_candidate_names’ generator. The paths will be used in unit tests and will never touch the filesystem. Some have suggested using ‘uuid’ or other random-generator APIs. Using an API that isn't explicitly designed to produce valid filesystem paths is both risky (the algorithm may not exactly produce the right behaviour), and confusing (a reader seeing use of an unrelated API will not find it obvious why that API was used for generating a filesystem path). The unit tests need paths with properties that are already implemented in ‘tempfile’, so it seems unreasonable to suggest that functionality should be re-implemented elsewhere since it is already in the standard library. The request is for a “get the next path generated by a ‘tempfile._get_candidate_names’ generator”, with an approved and documented public API. One suggested name is ‘tempfile.makepath’. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26362] Approved API for creating a temporary file path
Ben Finney added the comment:
An example::
import io
import tempfile
names = tempfile._get_candidate_names()
def test_frobnicates_configured_spungfile():
""" ‘foo’ should frobnicate the configured spungfile. """
fake_file_path = os.path.join(tempfile.gettempdir(), names.next())
fake_file = io.BytesIO("Lorem ipsum, dolor sit amet".encode("utf-8"))
patch_builtins_open(
when_accessing_path=fake_file_path,
provide_file=fake_file)
system_under_test.config.spungfile_path = fake_file_path
system_under_test.foo()
assert_correctly_frobnicated(fake_file)
With a supported standard library API for this – ‘tempfile.makepath’
for example – the generation of the filesystem path would change from
four separate function calls::
names = tempfile._get_candidate_names()
fake_file_path = os.path.join(tempfile.gettempdir(), names.next())
to a simple function call::
fake_file_path = tempfile.makepath()
and have the benefit of not reaching in to a private API.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26362>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26362] Approved API for creating a temporary file path
Ben Finney added the comment: It has been pointed out that `tempfile.mktemp` does in fact access the filesystem, to query whether the entry exists. So this request would be best met by exposing a simple “get a new return value from the `tempfile._RandomNameSequence` instance” function. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26362] Approved API for creating a temporary file path
New submission from Ben Finney: The security issues of `tempfile.mktemp` are clear when the return value is used to create a filesystem entry. The documentation and docstrings (and even some comments on past issues) are correct o deprecate its use for that purpose. The function has a use which doers not have security implications: generating test data. When a test case wants to generate unpredictable, unique, valid filesystem paths – and *never access those paths* on the filesystem – the `tempfile.mktemp` function is right there and is very useful. The `tempfile._RandomNameSequence` class would also be useful, but its name also makes clear that it is not part of the library public API. Please make that functionality available for the purpose of *only* generating filesystem paths as `tempfile._RandomNameSequence` does, in a public, supported, non-deprecated API. -- components: Library (Lib) messages: 260291 nosy: bignose priority: normal severity: normal status: open title: Approved API for creating a temporary file path type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25392] setup.py --quiet doesn't silence "no previously-included directories" warnings from MANIFEST.in
Changes by Ben Finney <ben+pyt...@benfinney.id.au>: -- nosy: +bignose ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25392> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24651] Mock.assert* API is in user namespace
Changes by Ben Finney ben+pyt...@benfinney.id.au: -- nosy: +bignose ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24651 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23297] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
New submission from Ben Finney: In `tokenize.detect_encoding` is the following code:: first = read_or_stop() if first.startswith(BOM_UTF8): # … The `read_or_stop` function is defined as:: def read_or_stop(): try: return readline() except StopIteration: return b'' So, on catching ``StopIteration``, the return value will be a byte string. The `detect_encoding` code then immediately calls `sartswith`, which fails:: File /usr/lib/python3.4/tokenize.py, line 409, in detect_encoding if first.startswith(BOM_UTF8): TypeError: startswith first arg must be str or a tuple of str, not bytes One or both of those locations in the code is wrong. Either `read_or_stop` should never return a byte string; or `detect_encoding` should not assume it can call `startswith` on the result. -- components: Library (Lib) messages: 234471 nosy: bignose priority: normal severity: normal status: open title: ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string type: crash versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23296] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
New submission from Ben Finney: In `tokenize.detect_encoding` is the following code:: first = read_or_stop() if first.startswith(BOM_UTF8): # … The `read_or_stop` function is defined as:: def read_or_stop(): try: return readline() except StopIteration: return b'' So, on catching ``StopIteration``, the return value will be a byte string. The `detect_encoding` code then immediately calls `sartswith`, which fails:: File /usr/lib/python3.4/tokenize.py, line 409, in detect_encoding if first.startswith(BOM_UTF8): TypeError: startswith first arg must be str or a tuple of str, not bytes One or both of those locations in the code is wrong. Either `read_or_stop` should never return a byte string; or `detect_encoding` should not assume it can call `startswith` on the result. -- components: Library (Lib) messages: 234470 nosy: bignose priority: normal severity: normal status: open title: ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23296 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23297] ‘tokenize.detect_encoding’ is confused between text and bytes: no ‘startswith’ method on a byte string
Ben Finney added the comment: Possibly related to issue9969. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue23297 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21720] TypeError: Item in ``from list'' not a string message
Ben Finney added the comment: Is there room for a better resolution: fix the API so that Unicode objects are accepted in the ‘fromlist’ items? -- nosy: +bignose ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21720 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21720] TypeError: Item in ``from list'' not a string message
Changes by Ben Finney ben+pyt...@benfinney.id.au: ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21720 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22843] doc error: 6.2.4. Match Objects
Ben Finney added the comment: The current wording of the passage “Match objects always have a boolean value of True” implies that the value compares equal to the ‘True’ constant. That implication is incorrect. I disagree with R. David Murray; if we want to say that a value is considered true *in a boolean context*, that's very different from saying it has the “True” value. Georg, “evaluates true in a boolean context” has the meaning you're seeking; it is chosen precisely because it does *not* imply equality to the True constant. -- nosy: +bignose ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22843 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12916] Add inspect.splitdoc
Changes by Ben Finney ben+pyt...@benfinney.id.au: -- nosy: +bignose ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12916 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18956] Document useful functions in ‘pydoc’ module
New submission from Ben Finney: The library documentation for ‘pydoc’ expects that the ‘pydoc’ module will only ever be run as a command-line program. This ignores the general usefulness of several of the functions in that module when imported from the library. The documentation should describe at least the following functions: * pydoc.getdoc * pydoc.synopsis * pydoc.splitdoc The following would be useful also: * pydoc.classname * pydoc.cram * pydoc.allmethods -- assignee: docs@python components: Documentation messages: 197138 nosy: bignose, docs@python priority: normal severity: normal status: open title: Document useful functions in ‘pydoc’ module type: enhancement versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue18956 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12645] test.support. import_fresh_module - incorrect doc
Ben Finney added the comment: On 01-Aug-2013, Eli Bendersky wrote: Ben, would you like to provide an updated patch? Unfortunately, contributions are not accepted under the Apache Software Foundation License (as I had thought), but also require assigning extra privileges to the Python Software Foundation under a special agreement. I'm not able to do this in good conscience, so it seems the Python Software Foundation will reject my contribution. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12645] test.support. import_fresh_module - incorrect doc
Ben Finney added the comment: I'm reading the existing `test.support.import_fresh_module` docstring, and have re-formatted it for PEP 257 compliance and for reading clarity. -- keywords: +patch nosy: +bignose Added file: http://bugs.python.org/file30857/issue12645.reformat_docstring.9d22bc60bd4f.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12645] test.support. import_fresh_module - incorrect doc
Ben Finney added the comment: import_fresh_module raises an ImportError if *name* can't be imported, or returns None if the fresh module is not found. The implementation doesn't seem to raise ImportError when a module import fails. Instead, from what I can tell, it captures any ImportError and returns None. So should the documentation (user docs and docstring) reflect this? Or have I mis-read the implementation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12645 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15731] Mechanism for inheriting docstrings and signatures
Ben Finney added the comment: Attached is a patch which is more comprehensive (covering the additional locations pointed out to me by ncoghlan), and also consolidating the details into the library documentation so they're not verbosely repeated in so many places. I agree with Nick's position that the docstrings are not the place to go into great detail about the significance and background of the issues. So the docstrings in this patch are accurate, but terse; the details are in the library documentation. -- keywords: +patch nosy: +bignose Added file: http://bugs.python.org/file26910/issue8810_reconcile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15731] Mechanism for inheriting docstrings and signatures
Ben Finney added the comment: Apologies, my previous comment and patch was sent to the wrong issue (should have gone to #8810). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue15731 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8810] TZ offset description is unclear in docs
Ben Finney added the comment: Attached is a patch which is more comprehensive (covering the additional locations pointed out to me by ncoghlan), and also consolidating the details into the library documentation so they're not verbosely repeated in so many places. I agree with Nick's position that the docstrings are not the place to go into great detail about the significance and background of the issues. So the docstrings in this patch are accurate, but terse; the details are in the library documentation. -- Added file: http://bugs.python.org/file26911/issue8810_reconcile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8810] TZ offset description is unclear in docs
Ben Finney added the comment: Here is an updated patch. I examined the implementation in the code for UTC offset and DST handling, and updated the code comments, the docstrings, and the library documentation. -- keywords: +patch nosy: +bignose, ncoghlan Added file: http://bugs.python.org/file26908/issue8810_reconcile_docs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8810 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12750] datetime.datetime timezone problems
Changes by Ben Finney ben+pyt...@benfinney.id.au: -- nosy: +bignose ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12750 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12756] datetime.datetime.utcnow should return a UTC timestamp
New submission from Ben Finney ben+pyt...@benfinney.id.au: = $ date -u +'%F %T %s %z' 2011-08-16 06:42:12 1313476932 + $ python -c 'import sys, datetime; now = datetime.datetime.utcnow(); sys.stdout.write(now.strftime(%F %T %s %z))' 2011-08-16 06:42:12 1313440932 = The documentation for ‘datetime.datetime.utcnow’ says “Return a new datetime representing UTC day and time.” The resulting object should be in the UTC timezone, not a naive no-timezone value. This results in programs specifically requesting UTC time with ‘utcnow’, but then Python treating the return value as representing local time since it is not marked with the UTC timezone. -- components: Library (Lib) messages: 142164 nosy: Daniel.O'Connor, bignose, r.david.murray priority: normal severity: normal status: open title: datetime.datetime.utcnow should return a UTC timestamp type: feature request versions: Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12756 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
