[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 library code to figure out what to override and what to duplicate in order to get the output I want. That seems like a needlessly high barrier for such a common (and apparently oft-requested) format. -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. """ OPTION_SEPARATOR = ', ' METAVAR_SEPARATOR = ' ' def _format_action_invocation(self, action): """Format action help without repeating the argument metavar """ if not action.option_strings or action.nargs == 0: return super()._format_action_invocation(action) default = self._get_default_metavar_for_optional(action) args_string = self._format_args(action, default) options_string = self.OPTION_SEPARATOR.join(action.option_strings) return options_string + self.METAVAR_SEPARATOR + args_string -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 we could add a HelpFormatter subclass that changes one (or two methods) >such as _format_action_invocation. Subclassing the formatter is the accepted >way of adding help features. If it was done in a subclass, how would people be expected to get the new behavior *and* that of the other subclasses? For example, someone with pre-formatted description and epilog text is currently directed to use the RawDescriptionHelpFormatter subclass. If they also wanted to avoid repeat metavars, and that behavior was implemented in another subclass, would they be expected to write a third subclass inheriting from both module-defined subclasses? To me, multiclassing seems rather heavyweight for a simple behavior change like this one, but yes, I recognize that argparse's current code uses that approach. Pity, that. >Of course people can use such a subclass without it being part of the >standard module. Technically: sure. But practically: not so much. An application would have to subclass and override _format_action_invocation(), which (judging by the leading underscore) appears to be intended as private to the module. Even the module doc string says so: """ (Also note that HelpFormatter and RawDescriptionHelpFormatter are only considered public as object names -- the API of the formatter objects is still considered an implementation detail.) """ So, a subclass that isn't part of the standard module is implicity and explicitly discouraged by the module itself. If we're married to the module's current policy for formatter tweaks, I guess that leaves a module-defined subclass as the only option. Here is an example that works: class OneMetavarHelpFormatter(argparse.HelpFormatter): """A formatter that avoids repeating action argument metavars. """ def _format_action_invocation(self, action): "Format action help without repeating the argument metavar" if not action.option_strings or action.nargs == 0: return super()._format_action_invocation(action) default = self._get_default_metavar_for_optional(action) args_string = self._format_args(action, default) return ', '.join(action.option_strings) + ' ' + args_string -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-world example that would lead someone to think otherwise. Is there a program with a short & long form option where only one of those accepts an argument? If such a thing does exist somewhere, the current behavior seems even worse in that case: it shows the METAVAR alongside both forms, despite only one form accepting an argument. >Also, showing the METAVAR more than one is a norm. For example, see this >excerpt from "man grep": I disagree about that being a norm. Counterexamples include: cp -t, --target-directory=DIRECTORY mv -S, --suffix=SUFFIX ls -T, --tabsize=COLS man -L, --locale=LOCALE And, as Jeremy pointed out, we are not discussing man pages here, but command line help text. Even grep does it the way I suggest: grep -e, --regexp=PATTERNS grep -f, --file=FILE grep -m, --max-count=NUM (etc.) More importantly, even if we do accept the current behavior as potentially useful, do we really want Python's standard library to prescribe it? Should the application developer not be given an easy way for her program to display cleaner, simpler, more space-efficient help text? -- ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Print the given string. By repeating the metavars, the formatter wastes horizontal space, making the following side-effects more likely: - The easy-to-read tabular format is undermined by overlapping text columns. - An action and its description are split apart, onto separate lines. - Fewer actions can fit on the screen at once. - The user is presented with extra noise (repeat text) to read through. I think the DRY principle is worth considering here. Help text would be cleaner, more compact, and easier to read if formatted like this: -t, --task ARGUMENT Perform a task with the given argument. -p, --print STRINGPrint the given string. Obviously, actions with especially long option strings or metavars could still trigger line breaks, but they would be much less common and still easier to read without the repeat text. I am aware of ArgumentParser's formatter_class option, but unfortunately, it is of little help here. Since the default formatter class reserves every stage of its work as a private implementation detail, I cannot safely subclass it to get the behavior I want. My choices are apparently to either re-implement an unreasonably large swath of its code in my own formatter class, or override the private _format_action_invocation() method in a subclass and risk future breakage (and still have to re-implement more code than is reasonable.) Would it make sense to give HelpFormatter a "don't repeat yourself" option? (For example, a boolean class attribute could be overridden by a subclass and would be a small change to the existing code.) Alternatively, if nobody is attached to the current behavior, would it make sense to simply change HelpFormatter such that it never repeats itself? -- components: Library (Lib) messages: 401110 nosy: forest priority: normal severity: normal status: open title: argparse repeats itself when formatting help metavars type: behavior versions: Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45110> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 methods, the way to find the appropriate chunksize is by manually checking different sizes and observing the program behavior. For library developers, you have to hope that you set an reasonable value that will work okay across different hardware, operating systems, and task characteristics. Generally, users of these methods want maximum throughput. It would be great if the map-like methods could adapt their chunksize towards that goal. Something along the lines of this: n_items = 0 queue = Queue(N) while True: chunk = tuple(itertools.islice(iterable, chunk_size)) if chunk: queue.put(chunk) n_items += chunk_size i += 1 if i % 10: time_delta = max(time.perf_counter() - t0, 0.0001) current_rate = n_items / time_delta # chunk_size is always either growing or shrinking, if # the shrinking led to a faster rate, keep # shrinking. Same with growing. If the rate decreased, # reverse directions if current_rate < last_rate: multiplier = 1 / multiplier chunk_size = int(min(max(chunk_size * multiplier, 1), upper_bound)) last_rate = current_rate n_items = 0 t0 = time.perf_counter() Would such a feature be desirable? -- components: macOS messages: 360126 nosy: fgregg, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: add option to make chunksize adaptive for multiprocessing.pool methods ___ Python tracker <https://bugs.python.org/issue39362> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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
If so, I'm happy to prepare a PR for adding some tests for this behavior.
On Sat, Jun 16, 2018 at 2:22 AM Raymond Hettinger
wrote:
>
> Raymond Hettinger added the comment:
>
> It's true the concrete set API differs in some ways from the Set abstract
> base class followed by dictviews. The concrete set-to-set operators are
> restricted to only work with other sets, leaving the named set methods
> (union, intersection, difference, etc) to accept any iterable. In
> contrast, the Set abstract base class only has operators and those are
> specifically allowed to accept any iterable.
>
> It may not seem harmonious, but those were intentional and long-standing
> design decisions. The restriction on concrete set operators to only work
> with other sets can be traced back to bad experiences with the += operator
> for lists accepting any iterable (allowing mistakes like s+='abc' when
> s.append('abc') was intended).
>
> Different choices were made in the design of the abstract Set API. In
> order to be useful, that API can't make as strong of a restriction, so it
> allows any iterable to be used as inputs to the operators. Also note that
> the abstract Set API doesn't have the named set methods (union,
> intersection, difference, etc), so the burden of falls on the operators to
> support iterables. IIRC, the reason that the named set methods were
> omitted was to make it easier to implement conforming classes that could
> interoperate with one another. For more details on the design of the
> collections ABCs, see Guido's PEP on the subject (that's where he explains
> was problem the abstract classes where intended to solve and some of design
> considerations).
>
> One can argue with those design decisions, but that ship sailed a long
> time ago and it would no longer be possible to change either set or Set
> without breaking existing code. The existing behaviors are intentional,
> venerable, tested, and guaranteed.
>
> --
> nosy: +rhettinger
> resolution: -> not a bug
> stage: -> resolved
> status: open -> closed
>
> ___
> Python tracker
> <https://bugs.python.org/issue33874>
> ___
>
--
___
Python tracker
<https://bugs.python.org/issue33874>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue33874 added a number of tests for dictview
set operators, but none covering the examples raised here.
--
___
Python tracker
<https://bugs.python.org/issue33874>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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' and 'list'
>>> set() & [] does **not** return set() it raises a TypeError
--
___
Python tracker
<https://bugs.python.org/issue33874>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 "", line 1, in
TypeError: unsupported operand type(s) for &: 'set' and 'list'
>>> set() & []
set()
>>> {}.keys() & frozenset([])
set()
>>> frozenset([]) & {}.keys()
set()
>>> set() & frozenset([])
set()
>>> frozenset([]) & set()
frozenset()
Similar for |, ^, -
>>> [1, 2, 3] - {2:None}.keys()
{1, 3}
Is perhaps particularly surprising
The operators <, <=, >, >= do work as expected.
>>> [1, 2, 3] > {}.keys()
Traceback (most recent call last):
File "", line 1, in
TypeError: unorderable types: list() > dict_keys()
I'm not sure if these differences between dictviews and set/frozenset should be
considered bugs. If no, it may be good to document that the behavior is
different.
--
components: Library (Lib)
messages: 319696
nosy: fgregg
priority: normal
severity: normal
status: open
title: dictviews set operations do not follow pattern of set or frozenset
versions: Python 3.8
___
Python tracker
<https://bugs.python.org/issue33874>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ready for your review. Please let me know if there's anything else I can do. Thanks, Forest -- ___ Python tracker <https://bugs.python.org/issue27575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 intersections of multisets. I started with the collections.Counter object, but the current intersection method is too slow. As Counter is a subclass of dict, I thought that I could significantly speed it up by taking advantage of keys intersections. I've been able to verify that if key intersection was roughly similar in speed to set intersection, than that would be very helpful. However, the current speed of key intersection does not make that practicable. I can, of course, cast the keys to sets before intersecting, but as David points out that casting is what is taking significant time. slow dictionary intersection for becoming larger dicts is becoming a problem for me -- nosy: +fgregg ___ Python tracker <https://bugs.python.org/issue27575> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 1238.50.2) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (compatibility version 1.0.0, current version 125.2.0) otool -L $(python3.6 -c 'import _dbm;print(_dbm.__file__)') /Library/Frameworks/Python.framework/Versions/3.6/lib/python3.6/lib-dynload/_ dbm.cpython-36m-darwin.so: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/dedupe-examples/blob/master/csv_example/csv_example.py [2] https://github.com/dedupeio/dedupe/issues/571 [3] https://github.com/dedupeio/dedupe-examples/issues/54 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <rep...@bugs.python.org> <http://bugs.python.org/issue30388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <rep...@bugs.python.org> <http://bugs.python.org/issue30388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30388] ndbm can't iterate through values on OS X
Changes by Forest Gregg <fgr...@gmail.com>: -- type: -> behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/api.py", line 281, in _blockData for block in viewvalues(blocks): File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/_collections_abc.py", line 693, in __iter__ for key in self._mapping: File "/Library/Frameworks/Python.framework/Versions/3.5/lib/python3.5/shelve.py", line 95, in __iter__ for k in self.dict.keys(): SystemError: Negative size passed to PyBytes_FromStringAndSize I've confirmed that this works with Python 3.6.1. All the Python versions were installed from homebrew. I cannot reproduce on linux on windows machines. I've attached a zip file of the ndbm files that python created. -- components: Library (Lib) files: ndbm.zip messages: 293858 nosy: Forest Gregg priority: normal severity: normal status: open title: ndbm can't iterate through values on OS X versions: Python 3.5 Added file: http://bugs.python.org/file46872/ndbm.zip ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30388> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 of the encapsulated parts, on a line by itself or as the prefix of any line." -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 traverse the list from most recent to least recent, but there might be more efficient ways to do it.) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (defective) outer message. This file from the test_email suite demonstrates the problem: Python-3.5.0/Lib/test/test_email/data/msg_15.txt Consequentially, the inner multipart/alternative message is parsed with is_multipart() returning False, and a truncated payload. Moreover, unit tests like test_same_boundary_inner_outer() expect to find the StartBoundaryNotFoundDefect defect on the inner message in that file, which seems wrong to me, since the inner message is not defective. According to the RFCs, the outer message should have been generated with a boundary string that does not appear anywhere in its encoded body (including the inner message). The outer message is therefore the defective one. -- components: email messages: 255309 nosy: barry, forest, r.david.murray priority: normal severity: normal status: open title: email parser ignores inner multipart boundary when outer message duplicates it type: behavior versions: Python 2.7, Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 will still be recognized if an inner multipart message is missing its boundary markers (for example if the inner message was truncated). It does not describe any circumstances under which the inner message's boundary markers should be ignored when they are present. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue25728> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6721] Locks in python standard library should be sanitized on fork
Changes by Forest Bond for...@alittletooquiet.net: -- nosy: +forest_atq ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6721 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: 184247 nosy: barry, forest, r.david.murray priority: normal severity: normal status: open title: email.parser module has no attribute BytesFeedParser versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue17431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 httplib in my application. Thanks, Forest -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net added the comment: Sure thing. I'll send it via e-mail later today. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net added the comment: Okay, Contributor Agreement sent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net added the comment: Hi, Johannes. You can assume the Python license for this patch. -Forest -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 broad testing against many different server-side implementations. Is there harm in applying the patch and fixing bugs that get reported? Thanks, Forest -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net added the comment: Looks like bgamari and I stepped on each other's requests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 if applicable [checat]. * Write documentation. I can have this done in a week or so, but I'd like to have some confidence that it will be applied if I spend the time on it. Thanks, Forest -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3831] Multiprocessing: Expose underlying pipe in queues
Changes by Forest Wilkinson pyth...@tibit.com: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3831 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net added the comment: Okay, I'll submit against py3k. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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, right? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net added the comment: As http.formdata? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 time, feel free). Thanks, Forest -- keywords: +patch Added file: http://bugs.python.org/file17546/http_formdata.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 client side). Thanks, Forest -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net added the comment: Here's a new patch. -- Added file: http://bugs.python.org/file17547/http_formdata.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 this won't: headers = dict(msg) body = msg.get_body() I'm not sure what the best way to deal with this is. Maybe instead of get_body we should have get_request_data which returns both headers and body. That would provide simpler semantics. Thoughts? Thanks, Forest -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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. -- Added file: http://bugs.python.org/file17548/http_formdata.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8896] email.encoders.encode_base64 sets payload to bytes, should set to str
New submission from Forest Bond for...@alittletooquiet.net: 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 nosy: forest_atq priority: normal severity: normal status: open title: email.encoders.encode_base64 sets payload to bytes, should set to str versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file17550/python-email-encoders-base64-str.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net added the comment: See issue8896 for email.encoders fix. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?
Forest Bond for...@alittletooquiet.net 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 rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8896] email.encoders.encode_base64 sets payload to bytes, should set to str
Forest Bond for...@alittletooquiet.net added the comment: Duplicate. See issue4768. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8896 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4768] email.generator.Generator object bytes/str crash - b64encode() bug?
Forest Bond for...@alittletooquiet.net added the comment: Note that my patch is roughly the same as the original posted by haypo. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4768 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 -- nosy: +forest_atq Added file: http://bugs.python.org/file17543/rfc2388.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3244] multipart/form-data encoding
Forest Bond for...@alittletooquiet.net 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 rep...@bugs.python.org http://bugs.python.org/issue3244 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3143] Make the left sidebar in the doc collapsible
Forest Wilkinson for...@users.sourceforge.net 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, does it only avoid the problem in the official python documentation? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3143 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7527] Standard Library documentation fails to mention that string.Formatter, etc. are new in Python 2.6
New submission from Forest Bond for...@alittletooquiet.net: 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 severity: normal status: open title: Standard Library documentation fails to mention that string.Formatter, etc. are new in Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7527] Standard Library documentation fails to mention that string.Formatter, etc. are new in Python 2.6
Forest Bond for...@alittletooquiet.net added the comment: Ah, I didn't see it there. Oh well, do what seems right. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7527 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1488934] file.write + closed pipe = no error
Changes by Forest Bond for...@alittletooquiet.net: -- nosy: +forest_atq versions: +Python 2.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1488934 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3143] development docs waste a lot of horizontal space on left nav bar
Forest Wilkinson for...@users.sourceforge.net 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 rep...@bugs.python.org http://bugs.python.org/issue3143 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Forest Wilkinson for...@users.sourceforge.net 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 way to find the oldest key, which I think I'd need for an LRU cache. I didn't notice one in the patch. Perhaps I simply missed something. Shouldn't popitem() allow the caller to choose which end from which to pop? -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Forest Wilkinson for...@users.sourceforge.net 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 retain the signature of dict.popitem(). I think I'll take this matter to python-dev. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5397] PEP 372: OrderedDict
Forest Wilkinson for...@users.sourceforge.net added the comment: Agreed here. Thanks, gents. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5397 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1641] asyncore delayed calls feature
Forest Wilkinson for...@users.sourceforge.net 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 loop() accept an optional task list argument, as it already does with the socket map? That would keep with the spirit of asyncore and make things easier for those of us who use multiple event loops in multiple threads. Josiah, is your updated sched module the one described in this blog post? Is there an issue in the bug tracker about it? http://chouyu-31.livejournal.com/316112.html ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1194378] sendmsg() and recvmsg() for C socket module
Changes by Forest Wilkinson for...@users.sourceforge.net: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1194378 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4690] asyncore calls handle_write() on closed sockets when use_poll=True
New submission from Forest Wilkinson for...@users.sourceforge.net:
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. If handle_close() calls close(), as asyncore's
default implementation does, the subsequent handle_write() will fail and
generate an EBADF (bad file descriptor) exception. If handle_error()
also calls close(), as asyncore's default implementation does, this will
mean close() gets called twice on the same socket.
I am attaching example code which demonstrates the problem on Linux
2.6.24 using python 2.5.2, 2.5.3rc1, and 2.6. In one window, run
pollwritefail.py. In another window, establish a TCP connection to port
12345 and immediately close it without reading or writing. This can be
done from within the python interactive interpreter like this:
import socket
s=socket.socket( socket.AF_INET, socket.SOCK_STREAM); s.connect(
('localhost', 12345)); s.close()
The output from pollwritefail.py will look like this:
writable() - asyncore asked if we have data to write
handle_read() - asyncore asked us to read
handle_close() - asyncore said the remote host closed connection
close() - we are closing our end of the connection
handle_write() - asyncore asked us to write
handle_error() - asyncore exception: (9, 'Bad file descriptor')
close() - we are closing our end of the connection
IMHO, two things need fixing here:
1. When writable() returns True, the next handler asyncore calls should
be handle_write(). Calling other handlers in between risks invalidating
the writable() return value.
2. After close(), asyncore should not call handle_write(), even if
writable() would return true.
--
components: Library (Lib)
files: pollwritefail.py
messages: 78003
nosy: forest
severity: normal
status: open
title: asyncore calls handle_write() on closed sockets when use_poll=True
type: behavior
versions: Python 2.5, Python 2.5.3, Python 2.6
Added file: http://bugs.python.org/file12390/pollwritefail.py
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4690
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2944] asyncore doesn't handle connection refused correctly
Changes by Forest Wilkinson for...@users.sourceforge.net: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2944 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1856] shutdown (exit) can hang or segfault with daemon threads running
Changes by Forest Wilkinson for...@users.sourceforge.net: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1856 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1720705] thread + import = crashes?
Changes by Forest Wilkinson for...@users.sourceforge.net: -- nosy: +forest ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1720705 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 2.x versions, if that code followed the example in the official docs: class http_request_handler(asynchat.async_chat): def __init__(self, conn, addr, sessions, log): asynchat.async_chat.__init__(self, conn=conn) The change also breaks the 2.6 docs, as they have not been updated to reflect the newly renamed parameter. http://docs.python.org/dev/library/asynchat.html#id1 The change appears to come from Nadeem Vawda as part of issue1519. (See msg57989.) I expect that existing python code could be modified to work around the problem by using positional args instead of keyword args. However, I didn't expect to have to update my working code to accommodate such a change in the python 2.x code line. I agree that 'sock' is a better name for the parameter, especially since it matches the same in asyncore.dispatcher, but should the change really happen before python 3.0? If so, let's at least update the docs. -- components: Library (Lib) messages: 73405 nosy: forest, nvawda severity: normal status: open title: asynchat async_chat __init__() arguments changed in python 2.6 versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3904 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 code would be nice, but isn't really necessary. Simple strings would suffice. It's easy enough for application code to read the strings from the appropriate files. Of course, the ssl module (or an underlying library) would need a way to determine the data format within the strings. Unfortunately, I didn't notice an equivalent of SSL_CTX_use_PrivateKey_file() that accepts a file's contents instead of its path. SSL_CTX_use_RSAPrivateKey() looks like the next best thing. much of the mechanism of a Certificate object is already there; perhaps adding an opaque Key object wouldn't be too bad. That's encouraging. From the openssl docs I've read so far, it looks like certificates and keys have several formats and use patterns. That seems to me like another argument in favor of supporting separate Certificate and Key objects, even if they're only minimally implemented to begin with. In other words, I don't imagine the presence of Certificate and Key objects would muck up the ssl module's api. In order to keep compatibility with socket.ssl, perhaps any new certificate and key objects should be accepted as alternatives to the existing certfile and keyfile args, but the latter should still be allowed? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 connections arrive, which is a problem for servers that bind to their socket and drop privileges as soon as they start up. In other words, the new ssl module's API prevents its use in servers that follow best practices that are prevalent in the unix world. If SSLSocket() and ssl.wrap_socket() were updated to accept private keys as strings (or open file-like objects or some such), the problem would go away. Moreover, it would allow a program to keep private keys cached in memory, which might slightly improve performance over reading them from the file system on every new connection. -- components: Library (Lib) messages: 72891 nosy: forest severity: normal status: open title: ssl.wrap_socket() is incompatible with unprivileged servers, due to keyfile requirement type: security versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 requirement ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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.python.org/issue3823 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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/bar'.rpartition(u'/') (u'/foo', u'/', u'bar') '/foo/bar'.rpartition(u'/') (u'', u'/', u'foo/bar') -- components: None messages: 72259 nosy: forest_atq severity: normal status: open title: str.rpartition fails silently with unicode argument versions: Python 2.5 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3751 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 space, at the expense of the pertinent information. This makes it harder to get much use out of a docs window placed next to my editor window, since I am now forced to switch active windows and/or scroll around the docs window in order to read the section I'm working with. In a few cases, it leaves space for so few words per line that even the visible part of the docs actually become harder to read (especially with text justification). For comparison, here are screen shots from the old and new documentation: http://hestiafire.org/forest/img/doc25.png http://hestiafire.org/forest/img/doc26.png Is this side bar going to be present in the final release of the python 2.6 docs? I hope not. It's a significant loss in readability, IMHO. -- assignee: georg.brandl components: Documentation messages: 68412 nosy: forest, georg.brandl severity: normal status: open title: development docs waste a lot of horizontal space on left nav bar versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3143 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1641] asyncore delayed calls feature
Changes by Forest Wilkinson [EMAIL PROTECTED]: -- nosy: +forest __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1641 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
