[issue45110] argparse repeats itself when formatting help metavars

Forest added the comment: >Subclassing a help formatter is preferred because it minimizes the chance of >hurting existing users. Fair enough. Whatever the approach, I hope argparse can be made to support this through a simple, documented interface. I had to grovel through standard l

[issue45110] argparse repeats itself when formatting help metavars

Forest added the comment: To be clear, I wrote those examples to be non-invasive, not patch proposals. A cleaner approach would be possible if patching argparse is an option. (I believe the patch in #42980 proposes such an approach.) -- ___ Python

[issue45110] argparse repeats itself when formatting help metavars

Forest added the comment: Here's another working example, allowing alternate separator strings (as requested in #33389) via subclassing: class OneMetavarHelpFormatter(argparse.HelpFormatter): """A formatter that avoids repeating action metavars. &quo

[issue45110] argparse repeats itself when formatting help metavars

Forest added the comment: On Mon, 06 Sep 2021 04:58:38 +, paul j3 wrote: >This repeat has been a part of argparse from the beginning, so I can't >see changing the default behavior. Yes, I guessed as much, which is why I first suggested making it optional. >But

[issue45110] argparse repeats itself when formatting help metavars

Forest added the comment: By the way, I would be happy to submit a patch, either to remove the repeat text or to make it optional via an easily overridden class attribute. -- ___ Python tracker <https://bugs.python.org/issue45

[issue45110] argparse repeats itself when formatting help metavars

Forest added the comment: On Mon, 06 Sep 2021 03:11:16 +, Raymond Hettinger wrote: >The repetition helps improve understanding because not everyone would assume >that a METAVAR shown once would automatically also apply to its long form. I'm struggling to think of a real-wo

[issue45110] argparse repeats itself when formatting help metavars

New submission from Forest : When argparse actions have multiple option strings and at least one argument, the default formatter presents them like this: -t ARGUMENT, --task ARGUMENT Perform a task with the given argument. -p STRING, --print STRING

[issue39362] add option to make chunksize adaptive for multiprocessing.pool methods

Change by Forest : -- components: +Library (Lib) -macOS type: -> enhancement ___ Python tracker <https://bugs.python.org/issue39362> ___ ___ Python-bugs-lis

[issue39362] add option to make chunksize adaptive for multiprocessing.pool methods

New submission from Forest : In the multiprocessing Pool methods like map, chunksize determines the trade-off between computation per task and inter-process communication. Setting chunksize appropriately has a large effect on efficiency. However, for users directly interacting with the map

[issue33874] dictviews set operations do not follow pattern of set or frozenset

Forest added the comment: Thank you very much for thorough explanation! It really helped me understand the issue. Since this is the intended behavior, would it be good to add some tests for the behavior? I would have found those tests helpful in working on https://bugs.python.org/issue27575

[issue33874] dictviews set operations do not follow pattern of set or frozenset

Forest added the comment: Issue https://bugs.python.org/issue24413 also flags a difference in the behavior between dictviews and sets/frozensets. "for non-iterable object x, set().__or__(x) raises NotImplementedError, but {}.keys().__or__(x) raises TypeError" Issue https://bugs.

[issue33874] dictviews set operations do not follow pattern of set or frozenset

Forest added the comment: Sorry there was a typo in the first example block: It should be >>> {}.keys() & [] set() >>> set() & [] Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for &: 'set'

[issue33874] dictviews set operations do not follow pattern of set or frozenset

New submission from Forest : Views of dictionary keys and items admit set operations, but the behavior of operations differs significantly from that of set and frozenset. >>> {}.keys() & [] set() >>> set() & [] Traceback (most recent call last): File ""

[issue27575] dict viewkeys intersection slow for large dicts

Forest added the comment: Hi Raymond, I've created a PR here: https://github.com/python/cpython/pull/7696, and I've verified that there are tests for all the code paths. I reached out to Daniel Hsu and he has given his blessing to help push this forward. I think this is read

[issue27575] dict viewkeys intersection slow for large dicts

Change by Forest : -- pull_requests: +7311 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue27575> ___ ___ Python-bugs-list mai

[issue27575] dict viewkeys intersection slow for large dicts

Forest added the comment: Is there anything helpful I can do to help close this issue? Maybe convert it into a github PR? Since Raymond asked for cases where this issue is a problem, I'll add the case that brought me here. I have an application where I need to do thousands of intersec

[issue30388] ndbm can't iterate through values on OS X

Forest Gregg added the comment: A different user: otool -L $(python3.6 -c 'import _dbm;print(_dbm.file)') /usr/local/var/pyenv/versions/3.6.1/lib/python3.6/lib-dynload/_dbm.cpython-36m-darwin.so: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version

[issue30388] ndbm can't iterate through values on OS X

Forest Gregg added the comment: >From one user who had problems under both 3.5 and 3.6 otool -L $(python3.5 -c 'import _dbm;print(_dbm.__file__)') /Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/lib-dynload/_dbm.cpython-35m-darwin.so: /usr/lib/libSystem.B.dylib (

[issue30388] ndbm can't iterate through values on OS X

Forest Gregg added the comment: I have been trying to make a small reproducible example, but haven't been able to isolate it. Running this script [1] csv_example on mac os x under either py27 or py3 does seem *often* cause this problem [2], [3]: [1] https://github.com/dedupeio/d

[issue30388] ndbm can't iterate through values on OS X

Forest Gregg added the comment: Very sorry for the ambiguity. The bug appears for both python 3.5 and python 3.6.1 on OS X. I have not tried other versions of python on OS X. -- ___ Python tracker <http://bugs.python.org/issue30

[issue30388] ndbm can't iterate through values on OS X

Forest Gregg added the comment: The ndbm db's two files (in the attachment) have the following size tmp___otctx 0 bytes tmp___otctx.db 12857344 bytes -- ___ Python tracker <http://bugs.python.org/is

[issue30388] ndbm can't iterate through values on OS X

Changes by Forest Gregg : -- type: -> behavior ___ Python tracker <http://bugs.python.org/issue30388> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue30388] ndbm can't iterate through values on OS X

New submission from Forest Gregg: On Mac OS 10.12.4, a large shelve, backed by ndbm, can be created. But when I attempt to iterate through the values of the shelve it raises this exception: File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/site-packages/dedupe/a

[issue25728] email parser ignores inner multipart boundary when outer message duplicates it

Forest added the comment: > The library can't successfully parse such a message It could successfully parse such a message, if it matched against inner message boundaries before outer message boundaries. (One implementation would be to keep a list of all ancestor boundaries and trav

[issue25728] email parser ignores inner multipart boundary when outer message duplicates it

Forest added the comment: RFC 2046 says that the outer message is defective, since it uses a boundary delimiter that is quite obviously present inside one of the encapsulated parts: https://tools.ietf.org/html/rfc2046#section-5.1 "The boundary delimiter MUST NOT appear inside any o

[issue25728] email parser ignores inner multipart boundary when outer message duplicates it

Forest added the comment: I thought at first that this might be deliberate behavior in order to comply with RFC 2046 section 5.1.2. https://tools.ietf.org/html/rfc2046#section-5.1.2 After carefully re-reading that section, I see that it is just making sure an outer message's boundary

[issue25728] email parser ignores inner multipart boundary when outer message duplicates it

New submission from Forest: When a multipart message erroneously defines a boundary string that conflicts with an inner message's boundary string, the parser ignores the (correct) inner message's boundary, and treats all matching boundary lines as if they belong to the (defect

[issue6721] Locks in python standard library should be sanitized on fork

Changes by Forest Bond : -- nosy: +forest_atq ___ Python tracker <http://bugs.python.org/issue6721> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue17431] email.parser module has no attribute BytesFeedParser

New submission from Forest Wilkinson: The docs claim that email.parser.BytesFeedParser exists, but it doesn't. Looks like email.feedparser.FeedParser is imported into the email.parser module, but someone forgot to do the same for BytesFeedParser. -- components: email messages: 1

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi Senthil Kumaran, Thanks for the feedback & patch. I agree having support in urllib probably makes some sense. But why not implement basic support elsewhere and then tie it into urllib so those of us using something else can also use it? I'm using h

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Okay, Contributor Agreement sent. -- ___ Python tracker <http://bugs.python.org/issue3244> ___ ___ Python-bugs-list mailin

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Sure thing. I'll send it via e-mail later today. -- ___ Python tracker <http://bugs.python.org/issue3244> ___ ___ Pytho

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, Johannes. You can assume the Python license for this patch. -Forest -- ___ Python tracker <http://bugs.python.org/issue3

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, So is the following enough to get this applied? If so, I'm game. * Review RFC and enforce Content-Encoding: binary if applicable [checat]. * Generate CR+LF line endings [checat]. * Review RFC and address "line-splitting and header-folding"

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Looks like bgamari and I stepped on each other's requests. -- ___ Python tracker <http://bugs.python.org/issue3244> ___ ___

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, Sorry for the long delay. I have tested against a Python web application using restish via various WSGI web servers (CherryPy, wsgiref) and I have not seen problems. It may cause problems with other server-side implementations. I will not have time to do

[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by Forest Wilkinson : -- nosy: +forest ___ Python tracker <http://bugs.python.org/issue3831> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Forest Bond added the comment: Note that my patch is roughly the same as the original posted by haypo. -- ___ Python tracker <http://bugs.python.org/issue4

[issue8896] email.encoders.encode_base64 sets payload to bytes, should set to str

Forest Bond added the comment: Duplicate. See issue4768. -- status: open -> closed ___ Python tracker <http://bugs.python.org/issue8896> ___ ___ Python-

[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?

Forest Bond added the comment: Attaching patch from reported duplicate issue8896. -- nosy: +forest_atq Added file: http://bugs.python.org/file17551/python-email-encoders-base64-str.patch ___ Python tracker <http://bugs.python.org/issue4

[issue3244] multipart/form-data encoding

Forest Bond added the comment: I don't think Python trunk has the encoders issue, as that is related to the base64 moving to the bytes type. -- ___ Python tracker <http://bugs.python.org/i

[issue3244] multipart/form-data encoding

Forest Bond added the comment: See issue8896 for email.encoders fix. -- ___ Python tracker <http://bugs.python.org/issue3244> ___ ___ Python-bugs-list mailin

[issue8896] email.encoders.encode_base64 sets payload to bytes, should set to str

New submission from Forest Bond : Ran into this while tackling issue3244. Encoded payload members should not be bytes. In the case of base64, we should have an ascii string. -- components: Library (Lib) files: python-email-encoders-base64-str.patch keywords: patch messages: 107055

[issue3244] multipart/form-data encoding

Forest Bond added the comment: New patch: * Renames class to FormData. * Replaces method get_body with get_request_data to simplify semantics. * Drops changes to email.encoders. I'll create a new ticket to deal with that bug. Note that tests here fail without that fix. --

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hm, there is one issue. The example in the docstring wouldn't work. You have to get the headers *after* the body, because the boundary isn't generated until the body has been. So this would work: body = msg.get_body() headers = dict(msg) But

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Here's a new patch. -- Added file: http://bugs.python.org/file17547/http_formdata.patch ___ Python tracker <http://bugs.python.org/i

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Éric, Sorry, I just read your message. I'll post a new patch with a module docstring. I believe cgi.FieldStorage is only useful for parsing (i.e. on the server side). MIMEMultipartFormData is for generating multipart/form-data messages (i.e. on the c

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, Patch attached. Let me know what needs fixing. I had to fix a bug in email.encoders for my tests to pass. I have not run the full test suite at this point (need to build py3k to do that, maybe I'll have time later today, but if someone else has

[issue3244] multipart/form-data encoding

Forest Bond added the comment: As http.formdata? -- ___ Python tracker <http://bugs.python.org/issue3244> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Should the module be called rfc2388 or should it go into email.mime as formdata? It seems odd to put something HTML/HTTP related into email.mime, but maybe that would be fine. In any case, httplib docs should probably point to this module with an example

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Okay, I'll submit against py3k. -- ___ Python tracker <http://bugs.python.org/issue3244> ___ ___ Python-bugs-list m

[issue3244] multipart/form-data encoding

Forest Bond added the comment: I haven't yet touched Python 3.0, and may not have time to dig in at the moment. It wouldn't be suitable to provide a patch against 2.7? -- ___ Python tracker <http://bugs.python.

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Oh, hm, looks like I left a hard-coded name="files" in attach_file. I'll fix that in the patch after I've received any other feedback. -- ___ Python tracker <http://bu

[issue3244] multipart/form-data encoding

Forest Bond added the comment: Hi, I believe the attached implementation is reasonable. I'm not sure if it should be called "email.mime.formdata", "rfc2388", etc. I'd be happy to attach a proper patch with tests given some quick feedback. Thanks, Forest

[issue3143] Make the left sidebar in the doc collapsible

Forest Wilkinson added the comment: I just noticed Ezio's change to the title of this bug. Does the proposed fix address the original bug title ("docs waste a lot of horizontal space on left nav bar") for third-party packages that use docutils to generate their docs? Or, doe

[issue7527] Standard Library documentation fails to mention that string.Formatter, etc. are new in Python 2.6

Forest Bond added the comment: Ah, I didn't see it there. Oh well, do what seems right. -- ___ Python tracker <http://bugs.python.org/issue7527> ___ ___

[issue7527] Standard Library documentation fails to mention that string.Formatter, etc. are new in Python 2.6

New submission from Forest Bond : This page: http://docs.python.org/library/string.html ... should mention that the Formatter class and any associated functions are new in Python 2.6. -- assignee: georg.brandl components: Documentation messages: 96493 nosy: forest_atq, georg.brandl

[issue1488934] file.write + closed pipe = no error

Changes by Forest Bond : -- nosy: +forest_atq versions: +Python 2.6 ___ Python tracker <http://bugs.python.org/issue1488934> ___ ___ Python-bugs-list mailin

[issue3143] development docs waste a lot of horizontal space on left nav bar

Forest Wilkinson added the comment: It is relative to the resolution of the user's browser window. Don't make the mistake of assuming that everyone keeps their browser maximized. :) -- ___ Python tracker <http://bugs.python.

[issue5397] PEP 372: OrderedDict

Forest Wilkinson added the comment: Agreed here. Thanks, gents. ___ Python tracker <http://bugs.python.org/issue5397> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue5397] PEP 372: OrderedDict

Forest Wilkinson added the comment: > Shouldn't popitem() allow the caller to choose which end from > which to pop? Thinking it through a bit more, and LRU cache would actually need to access the oldest item without necessarily removing it. Besides, popitem() should probably

[issue5397] PEP 372: OrderedDict

Forest Wilkinson added the comment: I was just reading the PEP, and caught this bit: "Does OrderedDict.popitem() return a particular key/value pair? Yes. It pops-off the most recently inserted new key and its corresponding value." Okay, but I'd also like a convenient and fast

[issue1641] asyncore delayed calls feature

Forest Wilkinson added the comment: I'm looking forward to having this functionality in asyncore. It would help me remove some unwanted hackery from my own code. Giampaolo, I'm concerned that your patch uses a global 'tasks' list which cannot be overriden. Shouldn't

[issue1194378] sendmsg() and recvmsg() for C socket module

Changes by Forest Wilkinson : -- nosy: +forest ___ Python tracker <http://bugs.python.org/issue1194378> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue2944] asyncore doesn't handle connection refused correctly

Changes by Forest Wilkinson : -- nosy: +forest ___ Python tracker <http://bugs.python.org/issue2944> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue4690] asyncore calls handle_write() on closed sockets when use_poll=True

New submission from Forest Wilkinson : With use_poll=True on linux, asyncore calls handle_write() after the socket has been closed. More specifically, it looks like asyncore dispatches handle_read() and handle_close() events between the writable() test and the corresponding handle_write() call

[issue1720705] thread + import => crashes?

Changes by Forest Wilkinson : -- nosy: +forest ___ Python tracker <http://bugs.python.org/issue1720705> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Changes by Forest Wilkinson : -- nosy: +forest ___ Python tracker <http://bugs.python.org/issue1856> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue1533164] Installed but not listed *.pyo break bdist_rpm

Changes by Forest Wilkinson <[EMAIL PROTECTED]>: -- nosy: +forest ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1533164> ___ __

[issue3904] asynchat async_chat __init__() arguments changed in python 2.6

New submission from Forest Wilkinson <[EMAIL PROTECTED]>: In python 2.6rc2, the async_chat.__init__() parameters have changed. The first arg was called 'conn' in python 2.5, and it is now called 'sock'. This change breaks code that worked with previous python

[issue2550] SO_REUSEADDR doesn't have the same semantics on Windows as on Unix

Changes by Forest Wilkinson <[EMAIL PROTECTED]>: -- nosy: +forest ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2550> ___ __

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

Forest Wilkinson <[EMAIL PROTECTED]> added the comment: Simon: I wish I could offer guidance here, but I'm afraid that I too am reading some of these openssl man pages for the first time. I agree that writing to a temporary file would be bad. Accepting file-like objects from python

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

Forest Wilkinson <[EMAIL PROTECTED]> added the comment: This problem also exists in the add-on ssl module for python < 2.6: http://pypi.python.org/pypi/ssl/ ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.py

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

Changes by Forest Wilkinson <[EMAIL PROTECTED]>: -- nosy: +janssen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3823> ___ __

[issue3823] ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile requirement

Changes by Forest Wilkinson <[EMAIL PROTECTED]>: -- title: ssl.wrap_socket() is incompatible with unprivileged servers, due to keyfile requirement -> ssl.wrap_socket() is incompatible with servers that drop privileges, due to keyfile re

[issue3823] ssl.wrap_socket() is incompatible with unprivileged servers, due to keyfile requirement

New submission from Forest Wilkinson <[EMAIL PROTECTED]>: SSLSocket() and ssl.wrap_socket() accept private keys only as paths to their location on the file system. This means that a server can only support SSL if it has read access to its private key file at the time when client conne

[issue3751] str.rpartition fails silently with unicode argument

New submission from Forest Bond <[EMAIL PROTECTED]>: Python 2.5.2 (r252:60911, Jul 31 2008, 17:28:52) [GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> u'/foo

[issue3143] development docs waste a lot of horizontal space on left nav bar

New submission from Forest Wilkinson <[EMAIL PROTECTED]>: I was just browsing the development docs, and noticed that the new left-side navigation bar wastes a lot of horizontal space on the web page. It fills nearly a third of my browser window (at its usual size) with useless blank spa

[issue2632] performance problem in socket._fileobject.read

Changes by Forest Wilkinson <[EMAIL PROTECTED]>: -- nosy: +forest __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2632> __ ___ Python-bugs

[issue1641] asyncore delayed calls feature

Changes by Forest Wilkinson <[EMAIL PROTECTED]>: -- nosy: +forest __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1641> __ ___ Python-bugs