Fred L. Drake, Jr. added the comment:
I'd like to see consistent usage by default, with specific examples using the
older forms as appropriate. The use cases Raymond identified are worth
discussing (and the tutorial may be a good place for this), and well as
mentioned in the reference docs
Fred L. Drake, Jr. added the comment:
Definitely agree with Eric on this; code modernization is definitely on the
risky side, so judicious updates are important. (Of course, not updating is
also a risk, eventually. But not much of one in this case.)
This issue is really about whether
Fred L. Drake, Jr. added the comment:
I agree that it's less invasive and easier to review.
My question (and it's just that) is whether we've made a decision to prefer one
formatting syntax over others (outside of examples discussing the formatting
approaches themselves).
If a decision
Fred L. Drake, Jr. added the comment:
Does it make sense to change just one example?
I'm not sure what the long-term stance is on whether %-formatting should be
replaced at this point, but shouldn't this be a matter of which string
formatting approach we want overall, rather than adjusting
Change by Fred L. Drake, Jr. :
--
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue38255>
___
___
Python-bugs-list mailing list
Unsub
Change by Fred L. Drake, Jr. :
--
versions: +Python 3.8
___
Python tracker
<https://bugs.python.org/issue38255>
___
___
Python-bugs-list mailing list
Unsub
Fred L. Drake, Jr. added the comment:
Provisional status should not cause a module or other API element to be omitted
from the indexes. So long as it's marked provisional where it's described, it
should be locatable.
--
nosy: +fdrake
___
Python
Change by Fred L. Drake, Jr. :
--
nosy: +fdrake
___
Python tracker
<https://bugs.python.org/issue34226>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Fred L. Drake, Jr. :
--
versions: +Python 3.7, Python 3.8, Python 3.9 -Python 3.2, Python 3.3
___
Python tracker
<https://bugs.python.org/issue14
Fred L. Drake, Jr. added the comment:
Eric nailed it; pprint was not designed as a replacement for print, and was
never intended to serve that purpose.
Rejecting as out of scope.
--
resolution: -> rejected
stage: -> resolved
status: open -&g
Fred L. Drake, Jr. added the comment:
Good catch, Vinay! Thanks.
--
___
Python tracker
<https://bugs.python.org/issue36532>
___
___
Python-bugs-list mailin
Change by Fred L. Drake, Jr. :
--
nosy: +fdrake
___
Python tracker
<https://bugs.python.org/issue36532>
___
___
Python-bugs-list mailing list
Unsubscribe:
Fred L. Drake, Jr. added the comment:
Updated target to Python 3.8, since this has aged a bit.
--
versions: +Python 3.8 -Python 3.5
___
Python tracker
<https://bugs.python.org/issue9
Change by Fred L. Drake, Jr. :
--
nosy: +fdrake
___
Python tracker
<https://bugs.python.org/issue36418>
___
___
Python-bugs-list mailing list
Unsubscribe:
Fred L. Drake, Jr. added the comment:
To clarify: I'm not suggesting that an API expansion should be considered as
part of this issue.
--
___
Python tracker
<https://bugs.python.org/issue31
Fred L. Drake, Jr. added the comment:
Unfortunately, when the implementation was migrated to use
collections.namedtuple (a benefit), the _replace method wasn't extended to
support the additional computed addresses for these types.
That would really be useful.
--
nosy: +fdrake
Change by Fred L. Drake, Jr. :
--
nosy: +fdrake
___
Python tracker
<https://bugs.python.org/issue36138>
___
___
Python-bugs-list mailing list
Unsubscribe:
Fred L. Drake, Jr. added the comment:
The 3.X docs generally don't refer to the 2.X series.
What that comment is pointing out is that leaving the field identifier out (the
number inside the {...} placeholder syntax) was not in the 3.0, but added in
3.1.
Unfortunately, I don't have a 3.0
Change by Fred L. Drake, Jr. :
--
nosy: +fdrake
___
Python tracker
<https://bugs.python.org/issue33381>
___
___
Python-bugs-list mailing list
Unsubscribe:
Fred L. Drake, Jr. added the comment:
A PR for this would be good, and would certainly accelerate getting this
accomplished. Thanks, Cheryl!
--
nosy: +fdrake
___
Python tracker
<https://bugs.python.org/issue11
Fred L. Drake, Jr. added the comment:
The existing PR can be re-targeted to merge to a maintenance branch (I'd be
inclined to merge manually, myself, but will have to check the current devguide
to make sure that's still allowed).
A new PR can be made for the non-documentation fix for master
Fred L. Drake, Jr. added the comment:
It probably makes more sense to keep that PR for the maintenance branches, and
create a new branch / PR to land on master.
--
___
Python tracker
<https://bugs.python.org/issue34
Fred L. Drake, Jr. added the comment:
I'm just going to presume this issue has been around a long time, but I think
that's a pretty safe presumption.
Accepting a general sequence instead of only a list would reasonable, and I'd
support a fix that caused the code to accept a general sequence
Fred L. Drake, Jr. added the comment:
I like Éric's terminology; giving a concrete name to the concept makes it a lot
easier to grasp, and this doesn't require inventing any new component terms.
Andrés, if you'd like to tackle this, that's great! I'd be happy to for you to
bounce drafts
Change by Fred L. Drake, Jr. :
--
nosy: +fdrake
___
Python tracker
<https://bugs.python.org/issue33869>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Fred L. Drake, Jr. :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue33832>
___
___
Python-bugs-list mailing list
Unsubscribe:
Fred L. Drake, Jr. added the comment:
Indeed, I did not. Fixed now. I hope.
--
nosy: +rhettinger
___
Python tracker
<https://bugs.python.org/issue33
Fred L. Drake, Jr. added the comment:
A quick grep on the 3.7 branch indicates that the standard documentation
includes each of the terms "magic method" and "special method" about the same
number of times. (I didn't check for instances that wrapped lines.)
Perhaps we s
Fred L. Drake, Jr. added the comment:
> I saw what looked to me like a bug that's been in the code for 18 years,
> and I saw that it was a simple fix.
And you're right: It is a bug, the fix is simple, and the risk is low.
Ten years ago, I'd have probably just landed the fix
Fred L. Drake, Jr. added the comment:
New changeset 5bfa058e65897567889354d7eb34af2b93a20f18 by Fred Drake
(arikrupnik) in branch 'master':
bpo-33274: Compliance with DOM L1: return removed attribute (#7465)
https://github.com/python/cpython/commit/5bfa058e65897567889354d7eb34af2b93a20f18
Fred L. Drake, Jr. added the comment:
I should stop relying on wetware memory; it's not working out. Sorry for the
mis-information.
--
___
Python tracker
<https://bugs.python.org/issue33
Fred L. Drake, Jr. added the comment:
Python 2.7 is in security-fix-only mode, and this doesn't fit that. While I
wouldn't object to a note in the documentation, see my comments in my patch
review (there's just no place for it to go
Fred L. Drake, Jr. <fdr...@gmail.com> added the comment:
While I've no strong objection to updating to follow the specification, I also
don't see any real value here. The current minidom implementation has been
considered sufficient for many years now (if you consider the DOM des
Change by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue1644818>
___
_
Change by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32706>
___
_
Fred L. Drake, Jr. <fdr...@gmail.com> added the comment:
This has landed on master and will be part of Python 3.7.
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.
Fred L. Drake, Jr. <fdr...@gmail.com> added the comment:
New changeset 96a5e50a5de3683b2afd6d680c7ecc4b525986f6 by Fred Drake (Giuseppe
Scrivano) in branch 'master':
bpo-32143: add f_fsid to os.statvfs() (#4571)
https://github.com/python/cpython/commit/96a5e50a5de3683b2afd6d680c7ecc4b52
Fred L. Drake, Jr. <fdr...@gmail.com> added the comment:
I think Giuseppe's patch is good, but there's a Windows failure on AppVeyor, so
I'm a little wary. It doesn't look related, but I haven't looked at Python on
Windows since... 2001,
Change by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue32143>
___
_
Change by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31803>
___
_
Fred L. Drake, Jr. <fdr...@gmail.com> added the comment:
The 3.5 docs should really remain in the main docs UI via the pulldown as long
as it's so widely used. The fact that it won't be changing much just means it
can be served efficiently.
--
nosy: +
Change by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue29400>
___
_
Fred L. Drake, Jr. added the comment:
On Thu, Jul 27, 2017 at 3:01 PM, Fred L. Drake, Jr.
<rep...@bugs.python.org> wrote:
> If the link went to an edit form with the version of the content the
> user was reading,
> and includes an explanation of the multiple-versions issue, i
Fred L. Drake, Jr. added the comment:
On Thu, Jul 27, 2017 at 1:03 PM, Mariatta Wijaya <rep...@bugs.python.org> wrote:
> I don't think we should add this link.
>
> When we make edits to the docs, even simple typo fixes, it should first be
> done
> in the m
Fred L. Drake, Jr. added the comment:
I agree that writexml should be available for document fragments.
I doubt the additional level of indentation should be added, as you've included
in point 2.
--
nosy: +fdrake
___
Python tracker <
Fred L. Drake, Jr. added the comment:
I wouldn't go so far as to say it's never come up; it's something I've thought
about a number of times, and I've waffled on it a few times.
It's not fundamentally unreasonable to want it to adapt to the current terminal
window, though I think it would
Fred L. Drake, Jr. added the comment:
This is not a problem for doctests, since the output stream is not a terminal;
the check for terminal-ness seems reasonable. (Though I don't have any idea if
it works on Windows, but it seems properly factored
Changes by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29997>
___
_
Changes by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue27879>
___
_
Changes by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: -fdrake
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue9285>
___
_
Fred L. Drake, Jr. added the comment:
Is there some special treatment you think should be given to specific enum
values as well?
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Fred L. Drake, Jr. added the comment:
"in" and "not in" are not comparisons, regardless of implementation mechanics
(which could change).
They aren't really dependent on iteration, though they often correlate with
iteration.
I'd rather see them described as "contai
Fred L. Drake, Jr. added the comment:
Without the star would be right. ReST does not support nested markup, and in
this case, I don't think it would make sense anyway.
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
Fred L. Drake, Jr. added the comment:
I don't recall that the issues discussed here were considered when these
classes were added; functionality was the issue at the time.
I'm not particularly opposed to adding a more data-ful repr for the
weakref-oriented mappings, but I'm not really
Fred L. Drake, Jr. added the comment:
+1
It could reasonably be argued that not sorting is a bug for already-released
3.x versions.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Fred L. Drake, Jr. added the comment:
I don't think this is a duplicate of issue 9755; this relates to verifying the
data, and that revolves around possible process improvements.
Whether this issue should be closed is tied to whether the file has been
verified, as the issue title suggests.
I
Fred L. Drake, Jr. added the comment:
As mentioned in issue 18085, the original file was not generated, but crafted
by hand (though I don't think that really matters).
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/
Fred L. Drake, Jr. added the comment:
+1 for ValueError instead of OSError.
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Fred L. Drake, Jr. added the comment:
I've read through this, but haven't applied the patch & run tests (that's what
buildbots are for).
No objections.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.o
Fred L. Drake, Jr. added the comment:
I see your message to python-dev, and apologize for taking so long to get to
this.
I do intend to read through your changes, and hope to be able to make time
while I'm at PyCon this coming week.
--
___
Python
Fred L. Drake, Jr. added the comment:
LGTM
Thanks for getting this documented!
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Fred L. Drake, Jr. added the comment:
Sorry; I guess I wasn't clear.
``versionadded::`` and ``versionchanged::`` are applied to specific API points
(modules, classes, methods, attributes) that are identified structurally in the
documentation. That isn't the case for this.
While a bit
Fred L. Drake, Jr. added the comment:
The ``versionadded::`` directive should only be used to annotate descriptions
of new API entries. While it would be correctly applied to the ``Chrome`` and
``Chromium`` classes, those are not separately documented here, but are only
listed in the table
Fred L. Drake, Jr. added the comment:
For anyone following along only via the tracker, it's worth noting that
proposals for new markup are welcome on the docs mailing list. More
information is available at:
https://mail.python.org/mailman/listinfo/docs
Fred L. Drake, Jr. added the comment:
If no one is planning to propose specific new markup for more fine-grained
version annotations, this issue can be closed.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Fred L. Drake, Jr. added the comment:
Another reason to value the status-quo in this case is that this isn't just
a matter for the Python documentation; it's about the recommended usage for
the markup, which is used by many other packages.
Questions that should be discussed include:
1. Should
Fred L. Drake, Jr. added the comment:
On Fri, Feb 19, 2016 at 10:02 AM, Tony R. <rep...@bugs.python.org> wrote:
> Holy crap! You all used to use LaTeX?! :D
Python's documentation has a long & colorful history. :-)
> Well then, if this is the sort of place where the stat
Changes by Fred L. Drake, Jr. <fdr...@gmail.com>:
--
nosy: +fdrake
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue26094>
___
_
Fred L. Drake, Jr. added the comment:
It's not at all obvious that the intention is to ensure such an argument should
be treated only as a command external to the shell.
If an application really wants to ensure the command is not handled as a shell
built-in, it should use shell=False.
Making
Fred L. Drake, Jr. added the comment:
Clearly I've been away from this code for a long time.
The hash support for ref objects is definitely a very special case, only
intended to support WeakKeyDictionary. We that class implemented in C, we'd
probably want the hash support for refs
Fred L. Drake, Jr. added the comment:
I don't see any reason for proxy objects to be less hashable than ref objects.
As for the p == p case, where the referent has expired, returning True if p is
p seems acceptable (along with False inequalities, and True for other
comparisons allowing
Fred L. Drake, Jr. added the comment:
ref objects behave differently: they inherit their referent's hash
value when alive, and remember it. proxy objects could be made to
behave the same way.
They could, yes, but that would break the proxy behavior, and the hash --
equality behavior
Fred L. Drake, Jr. added the comment:
Sorry for the delay. pprint_safe_key.patch looks good to me.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22721
Fred L. Drake, Jr. added the comment:
Given that this has languished this long, patching historical releases seems
pointless.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2174
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
nosy: -fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7434
___
___
Python-bugs-list
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
nosy: -fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2292
___
___
Python-bugs-list
Fred L. Drake, Jr. added the comment:
Sorting by the repr sounds good, but if some dict keys or set members are
strings containing single-quotes, the primary sort will be on the type of quote
used for the repr, which would be surprising and significantly less useful
Fred L. Drake, Jr. added the comment:
Stability in output order from pprint is very useful in doctests (yes, some
people write documentation that they test).
I think fixing any output stability issues would be very worthwhile.
--
___
Python tracker
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
assignee: - fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19100
___
___
Python-bugs
Fred L. Drake, Jr. added the comment:
Not a foolish consistency; Guido ruled long ago that American spellings should
be used.
--
nosy: +fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue19504
Fred L. Drake, Jr. added the comment:
Advising the reader to be aware of the security warnings in the API
documentation seems sufficient.
JSON isn't intended to support arbitrary data, and that's what this section is
discussing. Another section about data interchange with other applications
Fred L. Drake, Jr. added the comment:
When I read ... that can take almost any Python object ..., I don't think
the recommendation is about just a few types.
The Zope and ZODB communities certainly use pickle extensively, we're aware of
the security implications, and we send pickled data
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
nosy: -fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18840
___
___
Python-bugs-list
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
nosy: +fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18501
___
___
Python-bugs-list
Fred L. Drake, Jr. added the comment:
From v5 of the patch:
+ A context managers that temporarily replaces the :data:`sys.stdin` /
+ :data:`sys.stdout` / :data:`sys.stderr` stream with :class:`io.StringIO`
+ object.
I'd go with singular nouns instead of trying to map across them
Fred L. Drake, Jr. added the comment:
Joining the documentation for captured_stderr and captured_stdout makes
sense, as they can really use a single example, and the usage is
completely parallel.
I'd rather see captured_stdin handled separately, perhaps with some
additional comments
Fred L. Drake, Jr. added the comment:
+1 for issue17987_4.patch
Thanks, Dmi!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17987
Fred L. Drake, Jr. added the comment:
I'm a little surprised that still exists.
The first version was generated manually.
--
nosy: +fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18085
Fred L. Drake, Jr. added the comment:
Were I adding that today, I'd use a more verbose (but more standard)
format, like configparser or JSON. If any further use is going to be
made of it, that should be considered. Colon-delimited is a pretty
fragile format
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
resolution: - rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17995
New submission from Fred L. Drake, Jr.:
The captured_stderr and captured_stdin context managers aren't documented, and
should be.
--
assignee: docs@python
components: Documentation
keywords: easy
messages: 189311
nosy: docs@python, fdrake
priority: normal
severity: normal
stage: needs
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
nosy: +fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17950
___
___
Python-bugs-list
Changes by Fred L. Drake, Jr. fdr...@gmail.com:
--
nosy: -fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17868
___
___
Python-bugs-list
Fred L. Drake, Jr. added the comment:
Let's just update the docstring:
Concrete date/time and related types.
See also http://dir.yahoo.com/Reference/calendars/
For a primer on DST, including many current DST rules, see
http://webexhibits.org/daylightsaving/
Sources for time zone and DST data
Changes by Fred L. Drake, Jr. f...@fdrake.net:
--
nosy: +fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2175
___
___
Python-bugs-list
Fred L. Drake, Jr. added the comment:
I like this.
It would be especially nice if it were smart enough to split the segments after
sequences of line-ends (r'(\r?\n)+').
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17150
Fred L. Drake, Jr. added the comment:
Better (IMO):
Wrap the meta-characters in brackets for a literal match. For example,
``'[?]'`` matches the character ``'?'``.
--
nosy: +fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Changes by Fred L. Drake, Jr. f...@fdrake.net:
--
nosy: +fdrake
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15120
___
___
Python-bugs-list
Fred L. Drake, Jr. f...@fdrake.net added the comment:
Developers with existing code can reasonably be expected to look it up
based on what they're currently importing, so an entry that points to
the new recommended practice is good.
--
nosy: +fdrake
Fred L. Drake, Jr. f...@fdrake.net added the comment:
Removing Lightweight and changing the first paragraph to (something like)
:mod:`xml.dom.minidom` is an implementation of the Document Object Model
interface. The API is slightly simpler than the full W3C DOM, but the
implementation has
1 - 100 of 248 matches
Mail list logo