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 l
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
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
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 cum
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 mess
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 pro
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
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 t
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
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
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
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
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
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 success
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 ma
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
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:
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
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
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
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
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:
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
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 l
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 eff
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
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
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 co
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
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
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
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 pr
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
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
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
Changes by Ben Finney <ben+pyt...@benfinney.id.au>:
--
nosy: +bignose
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue25392>
___
_
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
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
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
Ben Finney added the comment:
Possibly related to issue9969.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23297
___
___
Python-bugs-list
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
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
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
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
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
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
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
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
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
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
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
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
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
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
54 matches
Mail list logo
