Re: Repair was successful
Lourival Beltrão Medical Physicist Supervisor Radiation Protection Nuclear Engineer *** Go green, make sense Please consider the environment before printing this e-mail. The contents of this e-mail message (including any attachments) are confidential and are intended to be conveyed for the use of the recipient to whom it is addressed only. If you receive this transmission in error, please notify the sender of this immediately and delete the message from your system. Any distribution, reproduction, or use of this message by someone other than the recipient is not authorized and may be unlawful. From: Lourival Beltrão Martins Jr Sent: Tuesday, September 1, 2020 10:07 To: python-list@python.org Subject: Repair was successful Hello, Good Morning! I have python 3.7 installed on my laptop and I did the download the 3.8.5 version. The message "Repair installation" appears all times when I open Spyder 4.0. Could you help me to fix this issue? Thank you very much! Beltrão Enviado do Correio<https://go.microsoft.com/fwlink/?LinkId=550986> para Windows 10 -- https://mail.python.org/mailman/listinfo/python-list
[issue39326] Python-3.8.1 "test_importlib" failed
Darryl Hall Jr added the comment: @Divyansh_tiwari I had the same issue, but on Python-3.8.3. I ran `sudo apt-get install zlib1g-dev` then `sudo apt-get install zlibc`. After installing those 2 packages, I reran `make test` and had test results = success. I hope this might work for you as well. -- nosy: +Darryl Hall Jr status: pending -> open ___ Python tracker <https://bugs.python.org/issue39326> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
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 for the '%s' % x and ''.format() operations (and string.Template(), of course). I would not like to see different syntaxes randomly applied to different examples that happen to involve formatting, but where that's not the emphasis. -- ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
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 the docs should be updated to use the newer syntax. In general, I think we should update the docs, and we've delayed long enough for the general application of f-strings. There will be cases to be wary of, certainly. I'm thinking especially of calls to the logging methods, or anywhere else doing delayed formatting. (Not that I can think of others off the top of my head.) -- ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
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 is made to prefer one over others, it's worth making that decision separately, and then using separate PRs to deal with updates to different parts of the docs. Added Julien Palard to the issue; I'd value input on this. -- nosy: +JulienPalard ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38351] Modernize email example from %-formatting to f-string
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 only specific examples? -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue38351> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38255] Replace "method" with "attribute" in the description of super()
Change by Fred L. Drake, Jr. : -- versions: +Python 3.9 ___ Python tracker <https://bugs.python.org/issue38255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38255] Replace "method" with "attribute" in the description of super()
Change by Fred L. Drake, Jr. : -- versions: +Python 3.8 ___ Python tracker <https://bugs.python.org/issue38255> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37741] importlib.metadata docs not showing up in the module index
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 tracker <https://bugs.python.org/issue37741> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34226] cgi.parse_multipart() requires undocumented CONTENT-LENGTH in Python 3.7
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue34226> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14149] argparse: Document how to use argument names that are not Python identifiers
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/issue14149> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36705] Unexpected Behaviour of pprint.pprint
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 -> closed ___ Python tracker <https://bugs.python.org/issue36705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36532] Example of logging.formatter with new str.format style
Fred L. Drake, Jr. added the comment: Good catch, Vinay! Thanks. -- ___ Python tracker <https://bugs.python.org/issue36532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36532] Example of logging.formatter with new str.format style
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue36532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9883] minidom: AttributeError: DocumentFragment instance has no attribute 'writexml'
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/issue9883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36418] urllib.parse.*Result: support _replace for additional computed addresses
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue36418> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31822] Document that urllib.parse.{Defrag, Split, Parse}Result are namedtuples
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/issue31822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31822] Document that urllib.parse.{Defrag, Split, Parse}Result are namedtuples
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 ___ Python tracker <https://bugs.python.org/issue31822> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36132] Python cannot access hci_channel field in sockaddr_hci
Andrew P. Lentvorski, Jr. added the comment: It's up to you how you folks want to deal with this, but classifying it as a "bug" for those versions in bugfix is likely acceptable. You already have to call bind with a tuple, so as long as it is *optional* to add an extra field to that tuple (and I can't imagine that any fix would not do that as it would break existing code), it's not going to break things. However, since nobody seems to have felt the need to file this, fixing this in 3.8 is probably just fine. -- ___ Python tracker <https://bugs.python.org/issue36132> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36138] Improve documentation about converting datetime.timedelta to scalars
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue36138> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36132] Python cannot access hci_channel field in sockaddr_hci
New submission from Andrew P. Lentvorski, Jr. :
On Linux, sockaddr_hci is:
struct sockaddr_hci {
sa_family_t hci_family;
unsigned short hci_dev;
unsigned short hci_channel;
};
Unfortunately, it seems like python does not allow any way to initialize
hci_channel, so you can't use a user channel socket (hci_channel == 0) or a
monitor channel. There is probably a larger discussion of how to enable people
to use a new field that appears in a structure like this, but that's above my
pay grade ...
Even worse, this appears to have been known for a while (since 2013 at least!
by Chromium), but while people complained, nobody actually took the time to
file it upstream with Python.
So, I'm filing it upstream. Hopefully this is easy to fix by someone who knows
what's up.
Thanks.
See:
https://chromium.googlesource.com/chromiumos/platform/btsocket/+/factory-4455.B
https://github.com/w3h/isf/blob/master/lib/thirdparty/scapy/layers/bluetooth.py
class BluetoothUserSocket(SuperSocket):
desc = "read/write H4 over a Bluetooth user channel"
def __init__(self, adapter=0):
# s = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_RAW,
socket.BTPROTO_HCI)
# s.bind((0,1))
# yeah, if only
# thanks to Python's weak ass socket and bind implementations, we have
# to call down into libc with ctypes
sockaddr_hcip = POINTER(sockaddr_hci)
cdll.LoadLibrary("libc.so.6")
libc = CDLL("libc.so.6")
socket_c = libc.socket
socket_c.argtypes = (c_int, c_int, c_int);
socket_c.restype = c_int
bind = libc.bind
bind.argtypes = (c_int, POINTER(sockaddr_hci), c_int)
bind.restype = c_int
## actual code
s = socket_c(31, 3, 1) # (AF_BLUETOOTH, SOCK_RAW, HCI_CHANNEL_USER)
if s < 0:
raise BluetoothSocketError("Unable to open PF_BLUETOOTH socket")
sa = sockaddr_hci()
sa.sin_family = 31 # AF_BLUETOOTH
sa.hci_dev = adapter # adapter index
sa.hci_channel = 1 # HCI_USER_CHANNEL
r = bind(s, sockaddr_hcip(sa), sizeof(sa))
--
components: Library (Lib)
messages: 336743
nosy: bsder
priority: normal
severity: normal
status: open
title: Python cannot access hci_channel field in sockaddr_hci
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue36132>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35831] Format Spec example says limited to 3.1+ but works in 2.7
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 interpreter available to show the exception
that's raised.
No change is required.
--
nosy: +fdrake
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue35831>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33381] Incorrect documentation for strftime()/strptime() format code %f
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue33381> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11233] clarifying Availability: Unix
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/issue11233> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34789] doc xml.sax.make_parser expects a list not just any sequence
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. My thought is that a PR is more about the patch than about the workflow; a different patch can be handled in a separate PR, and review & discussion are used to determine which PR should be applied where. -- ___ Python tracker <https://bugs.python.org/issue34789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34789] doc xml.sax.make_parser expects a list not just any sequence
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/issue34789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34789] doc xml.sax.make_parser expects a list not just any sequence
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 (or any iterable) by calling list() on the passed-in value, starting with 3.8. The patch provided looks good for versions in maintenance. (It would also be fine for 3.8 if there's no interest in generalizing the code to accept arbitrary iterables). -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue34789> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15474] Differentiate decorator and decorator factory in docs
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 through me if you like. -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue15474> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33869] doc Add set, frozen set, and tuple entries to Glossary
Change by Fred L. Drake, Jr. : -- nosy: +fdrake ___ Python tracker <https://bugs.python.org/issue33869> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33832] Make "magic methods" a little more discoverable in the docs
Change by Fred L. Drake, Jr. : -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue33832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33832] Make "magic methods" a little more discoverable in the docs
Fred L. Drake, Jr. added the comment: Indeed, I did not. Fixed now. I hope. -- nosy: +rhettinger ___ Python tracker <https://bugs.python.org/issue33832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33832] Make "magic methods" a little more discoverable in the docs
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 should decide on just one of these terms and fix references that use the other. I agree this can be a source of confusion, but having two terms for the same concept is a bug. I don't think we need to change references to "the __something__ method", because those are specific. We only need to decide on and consistently use the categorical term for these methods when referring to the entire category. -- nosy: +fdrake -pablogsal, rhettinger ___ Python tracker <https://bugs.python.org/issue33832> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
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 on all applicable branches and moved on. But the longer something stays the same (like you said, for 18 years now), the more surprising a fix can be when something (however foolishly and unlikely it seems) relied on the old, broken behavior falls apart because of the change. Please don't think we don't appreciate your contribution; we do. I hope you'll continue to be observant and catch bugs (even little ones!), and provide fixes. Feel free to reach out if you'd like to discuss this further. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
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 -- ___ Python tracker <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
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/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
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). -- ___ Python tracker <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33274] minidom removeAttributeNode returns None
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 desirable at all), so the lack of conformance with the W3C spec doesn't seem significant in practice. -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33274> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1644818] Allow built-in packages and submodules as well as top-level modules
Change by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue1644818> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32706] test_check_hostname() of test_ftplib started to fail randomly
Change by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32706> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
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.python.org> <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
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/96a5e50a5de3683b2afd6d680c7ecc4b525986f6 -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
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, maybe? -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32143] os.statvfs lacks f_fsid
Change by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32143> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31803] Remove not portable time.clock(), replaced by time.perf_counter() and time.process_time()
Change by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31766] Python 3.5 missing from documentation
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: +fdrake ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29400] Add instruction level tracing via sys.settrace
Change by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29400> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source"
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, it might > prove reasonable Egads, look at that formatting! Somedays I miss my VT-100 terminals and sane line handling. -Fred -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31055] All Sphinx generated pages could have a new "Edit This Page" link adjacent to the existing "Show Source"
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 master branch, instead of the maintenance branches (e.g. 2.7, 3.5 or > 3.6). > > If "Edit This Page" link takes you to edit the documentation in branches other > than "master", that's not desirable workflow. > > If "Edit This Page" link takes you to edit the master branch, it can be > confusing > to the contributor since the content on "master" might be different. I wonder if a better solution lies somewhere between the original suggestion and just not including such a link. 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, it might prove reasonable to try applying the diff between the modified and original text to the HEADs of each maintenance branch. If the diff doesn't apply, the (possibly new) contributor can be offered a chance to deal with edits to each version (which might be a bit much). At any rate, the diff could be used to construct a temporary branch, b.p.o issue, and PR. This would allow us to provide the contributor with a way to see that their suggested changes are being considered, and we're less likely to lose them in a wall of email. There'd be a bit of work to make all this play out, though. -Fred -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue31055> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9883] minidom: AttributeError: DocumentFragment instance has no attribute 'writexml'
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 <rep...@bugs.python.org> <http://bugs.python.org/issue9883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29996] Use terminal width by default in pprint
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 be in a minority among the Unix command line tools that I use. Raymond's point about potentially confusing students is an important one, though. If adaptive behavior is sufficiently desirable, the module should check the value of an environment variable, and default to the current behavior. PYTHONADAPTIVEPPRINT ? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29996] Use terminal width by default in pprint
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.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29996> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29997] Suggested changes for https://docs.python.org/3.6/extending/extending.html
Changes by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29997> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27879] add os.syncfs()
Changes by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue27879> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9285] Add a profile decorator to profile and cProfile
Changes by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: -fdrake ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue9285> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29614] Additional implementation alternative to DictReader
New submission from Kirk Cieszkiewicz Jr.: As discussed in the following: https://bugs.python.org/issue17537 https://mail.python.org/pipermail/python-ideas/2013-January/018844.html DictReader has a feature that will destroy data without warning if fieldnames had duplicate values (manual or automatic entries) Proposing renaming and re-implementation of DictReader class to instead return enumerate style output with a child class of DictReader to specifically return a dict object. -- components: Library (Lib) messages: 288318 nosy: Kirk Cieszkiewicz Jr. priority: normal severity: normal status: open title: Additional implementation alternative to DictReader type: enhancement versions: Python 2.7, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29614> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29601] Need reST markup for enum types
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/issue29601> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28617] Why isn't "in" called a comparison operation?
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 "containment tests" or something similar. -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28617> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19795] Formatting of True/False/None in docs
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> <http://bugs.python.org/issue19795> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28278] Make `weakref.WeakKeyDictionary.__repr__` meaningful
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 convinced they'd be all that valuable, either. Interesting mappings are often too well populated to deal with using repr. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28278> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27495] Pretty printing sorting for set and frozenset instances
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/issue27495> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: i'm a python newbie & wrote my first script, can someone critique it?
Thanks for your reply!
On Saturday, June 11, 2016 at 2:41:39 PM UTC-4, MRAB wrote:
> Drop the next 3 comment lines. They add visual clutter, and no useful info.
> > ###
> > # REFERENCE MODULES
> > ###
I'm not going to argue minor points at length, because others have said the
same thing here, but I will push back a little and explain that what you guys
consider visual clutter, I find helps me to visually break up and quickly
identify sections in my code, which is why I like those separators.
> There's an easier to make the repeated string: "+" * 79
> >
> > print("+++")
Thanks, that's a good tip. In this case I might prefer showing the full line of
+s because that way, wysiwyg, it's just easier to visualize the output.
Thanks again for the input. . . I will further digest what you all said and
study some more (including the docstrings)
--
https://mail.python.org/mailman/listinfo/python-list
Re: i'm a python newbie & wrote my first script, can someone critique it?
For those who don't want to have to wade through comments, here is a version
without so many comments:
# For Python 3.x
# This script creates multiple numbered empty folders
# in the desired location. To change the folder names
# or location, edit function get_default_options.
import datetime
import os
import errno
import sys
###
# EDIT VALUES HERE TO CUSTOMIZE THE OUTPUT
def get_default_options():
dict = {
"s_for_python_version": "3",
"s_folder_path_template": "C:/temp/test/MP3 Disk {count:03}",
"i_from_count": 3,
"i_to_count": 7,
}
return dict
###
def get_exact_python_version():
s_version = ".".join(map(str, sys.version_info[:3]))
s_version = s_version.strip()
return s_version
def get_general_python_version():
s_version = get_exact_python_version()
return s_version[0]
def exit_if_wrong_python_version(s_right_version):
s_current_version = get_general_python_version()
if (s_current_version != s_right_version):
print(
"Wrong Python version ({}), "
"this script should be run using "
"Python {}.x, Exiting..."
"".format(s_current_version, s_right_version))
sys.exit()
def get_script_filename():
return sys.argv[0]
def get_timestamp():
return datetime.datetime.strftime(datetime.datetime.now(), '%Y-%m-%d
%H:%M:%S')
def create_folder(s_path):
try:
os.makedirs(s_path, exist_ok=True)
except (FileExistsError, IsADirectoryError) as e:
print("FileExistsError IN makedirs")
raise
return False
except OSError as exception:
print("ERROR #" + str(exception.errno) + "IN makedirs")
raise
return False
print("" + get_timestamp() + " " + "Created folder: " + s_path + "")
def create_folders(
s_folder_path_template:str="",
i_from_count:int=1,
i_to_count:int=0
):
i_count=0
for i_loop in range(i_from_count, i_to_count + 1):
create_folder(s_folder_path_template.format(count=i_loop))
i_count += 1
return i_count
def main():
options_dict = get_default_options()
exit_if_wrong_python_version(options_dict["s_for_python_version"])
print("+++")
print("" + get_timestamp() + " " + get_script_filename() + " started.")
i_total_created = create_folders(
options_dict["s_folder_path_template"],
options_dict["i_from_count"],
options_dict["i_to_count"])
print("" + get_timestamp() + " " + str(i_total_created) + " folders
created.")
print("" + get_timestamp() + " " + get_script_filename() + " finished.")
if __name__ == '__main__':
main()
--
https://mail.python.org/mailman/listinfo/python-list
Re: i'm a python newbie & wrote my first script, can someone critique it?
Thanks to everyone for your replies. I see my script was as horrific as I
feared, but I read all the responses and made a few changes. I'm not 100% sold
on not checking types, but took it out, because it made sense that other
programmers might want to use some custom type with my functions for their own
nefarious purposes.
One question I have is, can someone point me to a full listing of all the error
types I can trap for? It seems like a Pandora's box, trying to think of all
the things that could go wrong, which is why I originally just printed the
error #. Is it better to not trap errors, and let the stack trace tell what
went wrong? Does it give all the information on the error type etc.?
Anyway, for those charitable (or masochistic, or both) enough to critique my
code again, here is the updated version:
# For Python 3.x
# This script creates multiple numbered empty folders
# in the desired location. To change the folder names
# or location, edit function get_default_options.
###
# REFERENCE MODULES
###
import datetime
import os
import errno
import sys
###
# SUPPORT FUNCTIONS
###
# returns: dictionary containing options for this script
def get_default_options():
dict = {
"s_for_python_version": "3",
"s_folder_path_template": "C:/temp/test/MP3 Disk {count:03}",
"i_from_count": 3,
"i_to_count": 7,
}
return dict
# returns: string containing exact version #, eg "3.5.1"
# TODO: update to use
# sys.version_info[:3] by itself gives a three-element tuple.
# Probably easier to use than thestring version.
# A couple alternatives:
# sys.version[:5] or perhaps a bit safer -- sys.version.split()[0] both
directly give you the
# string version. (Note this uses version not version_info.)
def get_exact_python_version():
s_version = ".".join(map(str, sys.version_info[:3]))
s_version = s_version.strip()
return s_version
# returns: string containing general version #, eg "3"
# TODO: return to the left of first "."
def get_general_python_version():
s_version = get_exact_python_version()
return s_version[0]
# checks python version
# if it's wrong then gracefully exit before it blows up
# (damn, python 2.x still complains with syntax errors!!)
#
# receives:
# s_right_version (string) = python version # to check against
#
# TODO: more granular check, eg if version >= 3.5.0
def exit_if_wrong_python_version(s_right_version):
s_current_version = get_general_python_version()
if (s_current_version != s_right_version):
print(
"Wrong Python version ({}), "
"this script should be run using "
"Python {}.x, Exiting..."
"".format(s_current_version, s_right_version))
sys.exit() # SAME AS os._exit(0)
# assists in script readability
# returns: string containing name of the current script
def get_script_filename():
return sys.argv[0]
# returns: string containing the current date/time in the format eg 2016-05-22
13:01:55
def get_timestamp():
return datetime.datetime.strftime(datetime.datetime.now(), '%Y-%m-%d
%H:%M:%S')
# creates a folder at the specified path
# receives:
# s_path (string) = full path of folder to create
def create_folder(s_path):
try:
os.makedirs(s_path, exist_ok=True)
except (FileExistsError, IsADirectoryError) as e:
print("FileExistsError IN makedirs")
raise
return False
except OSError as exception:
print("ERROR #" + str(exception.errno) + "IN makedirs")
raise
return False
print("" + get_timestamp() + " " + "Created folder: " + s_path + "")
# creates multiple numbered folders named per template
# receives:
# s_folder_path_template (string) = template containing full path of folder
to create,
# where "{count:n}" is replaced by the
folder count (n digits)
# i_from_count (int) = number to begin counting at
# i_to_count (int) = number to stop counting after
#
# returns: count of folders created, 0 if error or none
def create_folders(
s_folder_path_template:str="",
i_from_count:int=1,
i_to_count:int=0
):
i_count=0
for i_loop in range(i_from_count, i_to_count + 1):
create_folder(s_folder_path_template.format(count=i_loop))
i_count += 1
return i_count
###
# MAIN LOGIC
###
def main():
options_dict = get_default_options()
exit_if_wrong_python_version(options_dict["s_for_python_version"])
i'm a python newbie & wrote my first script, can someone critique it?
Is this group appropriate for that kind of thing?
(If not sorry for posting this here.)
So I wanted to start learning Python, and there is s much information
online, which is a little overwhelming. I really learn best from doing,
especially if it's something actually useful. I needed to create a bunch of
empty folders, so I figured it was a good exercise to start learning Python.
Now that it's done, I am wondering what kind of things I could do better.
Here is the code:
# WELCOME TO MY FIRST PYTHON SCRIPT!
# FIRST OF ALL, IT ***WORKS***!!! YAY!
# I AM A VBA AND JAVASCRIPT PROGRAMMER,
# SO IT IS PROBABLY NOT VERY "PYTHONIC",
# SO PLEASE FEEL FREE TO TEAR THE SCRIPT A NEW ONE
# AFTER YOU ARE SHOCKED BY THIS BAD CODE,
# ALL I ASK IS THAT IF YOU THINK SOMETHING IS BAD,
# PLEASE POST AN EXAMPLE OF THE "CORRECT" WAY OF DOING IT
# COMING FROM VBA, I KNOW A LITTLE OOP,
# BUT NOT C++ C# JAVA STUFF LIKE "INTERFACES" AND "ABSTRACT BASE CLASSES"
# SO IF YOU GET INTO SUCH TERMINOLOGY MY EYES MIGHT START TO GLAZE OVER
# UNLESS YOU CARE TO EXPLAIN THAT TOO
# GLOBAL VALUES
sForPythonVersion="3"
#sFolderPathTemplate = "c:\\myscripts\\MP3 Disc "
sFolderPathTemplate = "c:\\temp\\MP3 Disc "
iFromCount = 1
iToCount = 250
iCountWidth = 3
# SUPPORT FUNCTIONS
#
//
def is_string(myVar): # is_string IS MORE READABLE THAN isinstance (PLAIN
ENGLISH!)
#PYTHON 3 IS NOT LIKING THIS: return ( isinstance(myVar, str) or
isinstance(myVar, unicode) )
#PYTHON 3 IS NOT LIKING THIS: return isinstance(myVar, basestr)
return isinstance(myVar, str)
#
//
# THIS IS SOME SAMPLE FUNCTION FROM A BOOK I AM READING "PYTHON IN EASY STEPS"
def strip_one_space(s):
if s.endswith(" "): s = s[:-1]
if s.startswith(" "): s = s[1:]
return s
#
//
def get_exact_python_version():
import sys
sVersion = ".".join(map(str, sys.version_info[:3]))
sVersion = sVersion.strip()
return sVersion
#
//
# TO DO: RETURN TO THE LEFT OF FIRST "."
def get_python_version():
sVersion = get_exact_python_version()
return sVersion[0:1]
#
//
# CHECK PYTHON VERSION, IF IT'S WRONG THEN GRACEFULLY EXIT BEFORE IT BLOWS UP
# (DAMN, PYTHON 2.x STILL COMPLAINS WITH SYNTAX ERRORS!!)
# MAYBE THIS COULD STILL BE USEFUL FOR CHECKING THE SUB-VERSION, IN THAT CASE
# TO DO: MORE GRANULAR CHECK, EG IF VERSION >= 3.5.0
def exit_if_wrong_python_version(sRightVersion):
import os
sCurrentVersion = get_python_version()
if (sCurrentVersion != sRightVersion):
print("" +
"Wrong Python version (" +
sCurrentVersion +
"), this script should be run using Python " +
sRightVersion +
".x. Exiting..."
)
os._exit(0)
#
//
def get_script_filename():
import os
return os.path.basename(__file__)
#
//
def get_timestamp():
import datetime
return datetime.datetime.strftime(datetime.datetime.now(), '%Y-%m-%d
%H:%M:%S')
#
//
def create_folder(sPath):
import os
import errno
#if not os.path.exists(directory):
#os.makedirs(directory)
try:
os.makedirs(sPath, exist_ok=True)
except OSError as exception:
#if exception.errno != errno.EEXIST:
print("ERROR #" + str(exception.errno) + "IN makedirs")
raise
#
[issue18085] Verifying refcounts.dat
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 don't know whether Serhiy verified everything when he made his changes or not; that's not explicit in the issue or commit comments. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue18085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9755] Fix refcounting details in Py3k C API documentation
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/issue9755> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23116] Python Tutorial 4.7.1: Improve ask_ok() to cover more input values
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/issue23116> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
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.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26526] In parsermodule.c, replace over 2KLOC of hand-crafted validation code, with a DFA
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 tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26526> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26247] Document Chrome/Chromium for python2.7
Fred L. Drake, Jr. added the comment: LGTM Thanks for getting this documented! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26247] Document Chrome/Chromium for python2.7
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 of text noting the addition is less discoverable for documentation processors, I believe it to be sufficient. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26247] Document Chrome/Chromium for python2.7
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. See http://bugs.python.org/issue26366 for further discussion on the use of ``versionadded::``. -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26247> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate
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 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26366> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate
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/issue26366> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate
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 we clarify the documentation for the current annotations to the intended use is more consistently understood, or should we leave it as-is? 2. Are other distinct kinds of annotations (such as per-parameter notes) needed? If so, we'll need to consider specific reader / information-content needs and determine how they should be marked using new constructs. This is independent of implementation, which is likely straightforward. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26366> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate
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 status quo is sacred, then > there is nothing more to discuss. Status quo is not sacred, but does have some value. Changing how busy people do things is non-trivial. > But if anyone reading this is open to the idea, please re-read my previous > comment in this thread. The quoted LaTeX docs are clear, but I still > believe my “all changes = (deprecated-removed changes) + (added > changes) + (other changes)” interpretation makes more sense than the > LaTeX definition. > > I also think it is more helpful to the *reader*--which, I respectfully > suggest, > should be the basis for any documentation’s guidelines--by marking up > changes according to this grouping. I think we all agree that the documentation is for the reader. > It’s not my desire to be troublesome by making one more appeal. > I simply want to point out that just because somebody wrote the > LaTeX definitions a long time ago doesn’t mean that we cannot > rewrite them. They were written by somebody just like us, after all. As the person who wrote them, I don't consider them sacred or unchangeable. Having some rational basis for whatever we use is good, and it should be clearly documented clearly. > If it’s not obvious by now, I feel strongly about good semantic markup. We're on the same page here. > The purpose of semantic markup is to describe what something *is*. > I just think that changes form a hierarchy, with a generic “change” as > something of the base class, and “deprecated”, “removed”, and “added” > as specializations. Again, agreed. That doesn't imply that the specializations encompass all changes, though. For some, 'versionchanged' is reasonable. Part of the problem is getting the granularity right. The initial intent was that 'version*' were annotations for the enclosing object (function, class, method, etc.). If we want to have something more granular (parameter added / deprecated / whatever), we should have distinct markup for that. That could look something like: .. parameteradded:: alternate 3.6 Further explanation goes here. It's helpful to think of these annotations as pronouns; the antecedent needs to be clear before they can be interpreted correctly. It sounds like that needs to be clarified in the documentation, and possibly provision added for a more fine-grained form of annotation. -Fred -- nosy: +fdrake title: Use “.. versionadded” over “.. versionchanged” where appropriate -> Use “.. versionadded” over “.. versionchanged” where appropriate ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26366> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26094] ConfigParser.get() doc to be updated according to the configparser.py header doc
Changes by Fred L. Drake, Jr. <fdr...@gmail.com>: -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26094> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26124] shlex.quote and pipes.quote do not quote shell keywords
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 this clear in the documentation is reasonable. -- nosy: +fdrake ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26124> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24067] Weakproxy is an instance of collections.Iterator
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 not to be exposed. You've convinced me hashability for proxies isn't desirable. Let's stick with the status quo on this. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24067] Weakproxy is an instance of collections.Iterator
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 equality), but anything beyond that seems unwise. Not sure whether that would really be enough to help real use cases. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24067] Weakproxy is an instance of collections.Iterator
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 for mutable objects. In particular, mutable objects can become equal; if the hashes were computed for the proxies before that happened, the hashes would be inappropriate later. That's pretty important. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24067 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22721] pprint output for sets and dicts is not stable
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2174] xml.sax.xmlreader does not support the InputSource protocol
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7434] general pprint rewrite
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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2292] Missing *-unpacking generalizations
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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: Why my ; continuator idea is better for debugging too.
In article 85795$54978fe1$5419aafe$2...@news.ziggo.nl, skybuck2000 @hotmail.com says... Hello, In the past I wrote about pascal's ; mistake. ; should be used as a continuator. I just made a programming mistake which solidifies/merits my idea: The programming mistake was this: vBattlefieldLosingWarrior := // modified warrior and brain vSimulatorWinningWarrior := vBattlefieldBattle.Warrior[0]; Code should look like this: vBattlefieldLosingWarrior := TBattlefieldWarrior(vBattlefieldBattle.Warrior[2].Association); // modified warrior and brain vSimulatorWinningWarrior := vBattlefieldBattle.Warrior[0]; Fortunately there was a type mistmatch which hinted me at the programming mistake. The code is a bit messy above so let's make a simpler example to understand, the in my oppinion, dangerous programming mistake: A := B := C; The above statements A := is valid in Delphi's current design. The danger is that B is assigned to A which is not what I wanted, the problem was missing code at A. So the danger is that some day, somebody will write B in such a way that it will accidently be assigned to A. By using ; as a continuator instead of a seperator the code would look as follows: A := B := C Since there was no continuator specified, future-Delphi would have been That is perfectly valid and a good idea too. You can have a string of variables you need to initiate to short cut the coding, plus I also think it compacts the generated code because you only need to load a single register with the initial value. A:=B:=C:=D:=0; All get set the zero.. Jamie -- https://mail.python.org/mailman/listinfo/python-list
[issue22909] [argparse] Using parse_known_args, unknown arg with space in value is interpreted as first positional arg
New submission from Tab Atkins Jr.: If using parse_known_args() to get argument pass-through, and one of the unknown arguments has a value with a space in it (even if quoted!), the entire unknown argument (key=value) will be interpreted as the value of the first positional argument instead. Example: ``` import argparse parser = argparse.ArgumentParser() parser.add_argument(pos, nargs=?, default=None) parser.parse_known_args([--foo='bar']) # (Namespace(pos=None), ['--foo=bar']) # As expected. parse.parse_known_args([--foo='bar baz']) # (Namespace(pos=--foo='bar baz'), []) # What?!? ``` Since *known* arguments with spaces in them are parsed fine, this looks to be regression in a lesser-used feature. -- components: Library (Lib) messages: 231448 nosy: TabAtkins priority: normal severity: normal status: open title: [argparse] Using parse_known_args, unknown arg with space in value is interpreted as first positional arg type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22909 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22721] pprint output for sets and dicts is not stable
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. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue22721 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22721] pprint output for sets and dicts is not stable
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 rep...@bugs.python.org http://bugs.python.org/issue22721 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: GO vs Python
On Sun, Aug 24, 2014 at 9:36 PM, Rodrick Brown rodrick.br...@gmail.com wrote: I spent a few weeks looking at Go and have to say you can see a lot of Python's influence in Go, however my question to this list for others who are doing real work with Go and Python have you encountered any scenarios in which Go outmatched Python in terms of elegance or performance? --RB I use both, Python pays the bills, and I use it at work or on consulting gigs. for most things GO is faster, GO is compiled and that is a huge plus. the Go community is not nearly as large as pythons, there are loads more libraries and tools for python my initial reason for even looking at GO, was because, I noticed that if I wanted to move my largest clients app from Python 2.x to 3.x it was almost a rewrite. and then when I noticed the libraries for python 3.x were limited, and some python 2.x libraries are not even making a 3.x version... Well I got scared, Go started to look attractive, because your no longer comparing GO to the entire python community, it is GO vs python 3... thats just my 2 cents, I like python and it pays my bills... but I hate the way python delt with the 2.x - 3.x, they dropped the ball. -- Sam Fourman Jr. -- https://mail.python.org/mailman/listinfo/python-list
Re: GO vs Python
On Sun, Aug 24, 2014 at 10:07 PM, Chris Angelico ros...@gmail.com wrote: On Mon, Aug 25, 2014 at 12:57 PM, Sam Fourman Jr. sfour...@gmail.com wrote: my initial reason for even looking at GO, was because, I noticed that if I wanted to move my largest clients app from Python 2.x to 3.x it was almost a rewrite. and then when I noticed the libraries for python 3.x were limited, and some python 2.x libraries are not even making a 3.x version... Well I got scared, Go started to look attractive, because your no longer comparing GO to the entire python community, it is GO vs python 3... If your Python 2 - Python 3 transition was almost a rewrite, then either your code is making horribly messy assumptions about bytes vs text everywhere (in which case the pain will happen, Py3 just forces you to deal with it up-front instead of burying your head in the sand and wishing funny characters would go away), or you did the transition wrongly. It's not a complete change of language. And, what libraries are you short of for Python 3? List them! Maybe they do exist now. Nearly everything important does, there are only a handful of large/popular 2.x-only modules. And if you talk about what's missing, you demonstrate the need for those ports, which might be the impetus someone needs to make it available. There's way too much vague FUD about Python 3. Everyone who complains does so with oh, there aren't many libraries for Python 3, not with PyFooBar isn't available for Python 3, which would actually be useful. ChrisA -- https://mail.python.org/mailman/listinfo/python-list Thanks your your input chris, honestly it was the end of 2012 when I looked into a large py3 port for a client. I wrote a very large web project on Cheetah, and at the time there wasnt a Py3 port... Now I get that back when I wrote this code years before, I should have chose something else.. I remember doing some browsing around, and the pooco people that make jinja2 were not fans of python3(I forget the blog post), I got scared because a very large portion of my income was based on a single client... So since we were having scalability issues anyway, I moved them to GO, and it was a Win - Win, the GO standard lib does so much, and the scalability gains we received over python were so large, that we were able to reduce out AWS bill so much that I could hire another coder. I really like python, and we use it a ton, but a python like compiled language did wonders for us when we needed it most. Sam Fourman Jr. -- Sam Fourman Jr. -- https://mail.python.org/mailman/listinfo/python-list
[issue20803] struct.pack_into writes 0x00 for pad bytes
New submission from Andrew P. Lentvorski, Jr.:
This code did something unexpected to me:
a = bytearray('1234')
a
bytearray(b'1234')
struct.pack_into('xBxB', a, 0, 0x59, 0x5A)
a
bytearray(b'\x00Y\x00Z')
The unexpected part was that the 'x' pad byte formatter actually *overwrote*
the bytes to 0 rather than leaving them alone.
Not necessarily a bug, but the fact that the pad byte writes 0x00 rather than
being untouched/ignored should be documented.
--
components: Interpreter Core
messages: 212416
nosy: bsder
priority: normal
severity: normal
status: open
title: struct.pack_into writes 0x00 for pad bytes
type: behavior
versions: Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20803
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20783] bytearray init fails when \x00 is present
New submission from Andrew P. Lentvorski, Jr.: The byte array init fails when \x00 is present This fails: ggRAM = bytearray(RAM_SIZE_BYTES, '\x00'*RAM_SIZE_BYTES) However, this works: ggRAM = bytearray(RAM_SIZE_BYTES) ggRAM[:] = '\x00'*RAM_SIZE_BYTES -- components: Interpreter Core messages: 212281 nosy: bsder priority: normal severity: normal status: open title: bytearray init fails when \x00 is present type: behavior versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20783 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20783] bytearray init fails when \x00 is present
Andrew P. Lentvorski, Jr. added the comment:
Ayup, I are an idiot. Sorry.
ggRAM = bytearray('\x00'*RAM_SIZE_BYTES)
Works fine.
--
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20783
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20783] bytearray init fails when \x00 is present
Changes by Andrew P. Lentvorski, Jr. bs...@allcaps.org: -- resolution: - invalid ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20783 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20771] Download Talkray...
New submission from Alfonso Andalon Jr.: Download this http://talkray.com/dl/ee -- messages: 212199 nosy: Alfonso.Andalon.Jr. priority: normal severity: normal status: open title: Download Talkray... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20771 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20590] Download Talkray...
New submission from Alfonso Andalon Jr.: Download this http://talkray.com/dl/ee -- messages: 210897 nosy: Alfonso.Andalon.Jr. priority: normal severity: normal status: open title: Download Talkray... ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20590 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19100] Use backslashreplace in pprint
Changes by Fred L. Drake, Jr. fdr...@gmail.com: -- assignee: - fdrake ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue19100 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19504] Change customise to customize.
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 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
Re: basic maze problem with turtle
On Sun, Oct 13, 2013 at 11:44 PM, Gary Herron gary.her...@islandtraining.com wrote: On 10/13/2013 03:03 PM, Denis McMahon wrote: Except perhaps Nikos. Nikos can probably write you extremely elegant one line python solutions to any coding problem you describe to him. His solutions might suffer the very minor flaw of not working, but they're guaranteed to be Nikos certified aesthetically pure, and hence far superior to any solution more mundane coders might produce. That was uncalled for. There is already too much Nikos-bashing and Nikos-basher-bashing (and so on) in this newsgroup without dredging up even more in this completely unrelated request. Gary Herron -- https://mail.python.org/**mailman/listinfo/python-listhttps://mail.python.org/mailman/listinfo/python-list Who the hell is Nikos? I hear reference to this guy ALL the time, is he a troll or a python god? this simply isn't clear.. I have only been on this list a few months. -- Sam Fourman Jr. -- https://mail.python.org/mailman/listinfo/python-list
