[issue23041] csv needs more quoting rules
Samwyse added the comment: I just signed the contributor agreement. (Thought I had done that last year but I don’t see any emails. Is there any place to check?) I agree that round-tripping should Bebe possible for any value of quoting. Hopefully this will finally get done before its eighth birthday. -- ___ Python tracker <https://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1492] BaseHTTPServer hard-codes Content-Type for error messages
Changes by samwyse: -- components: +Library (Lib) type: -> behavior versions: +Python 2.4, Python 2.5, Python 2.6, Python 3.0 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1492> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
New submission from samwyse:
RFC 2616 sec 8.2.3 states, "An origin server that sends a 100 (Continue)
response MUST ultimately send a final status code, once the request body
is received and processed, unless it terminates the transport connection
prematurely." The obvious way to do this is to invoke the
'send_response' method twice, once with a code of 100, then with the
final code. However, BaseHTTPServer will always send two headers
('Server' and 'Date') when it send a response. One possible fix is to
add an option to the method to suppress sending headers; another is to
add the following code to the 'send_response' method, immediately prior
to the calls to 'self.send_header':
if code == 100:
return
The more paranoid among us may wish to use this code instead:
if code == 100:
expectation = self.headers.get('Expect', "")
if expectation.lower() == '100-continue':
return
--
components: Library (Lib)
messages: 57783
nosy: samwyse
severity: normal
status: open
title: BaseHTTPServer incorrectly implements response code 100
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1491>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1492] BaseHTTPServer hard-codes Content-Type for error messages
New submission from samwyse:
The send_error method always sends a Content-Type of 'text/html'. Other
content types are both possible and desirable. For example, someone
writing a REST server might wish to send XML error messages. Following
the example of DEFAULT_ERROR_MESSAGE, I propose adding the following in
the appropriate places:
91a92,94
> # Default error content-type
> DEFAULT_ERROR_TYPE = 'text/html'
>
345c348
< self.send_header("Content-Type", "text/html")
---
> self.send_header("Content-Type", error_message_type)
351a355
> error_message_type = DEFAULT_ERROR_TYPE
--
messages: 57784
nosy: samwyse
severity: normal
status: open
title: BaseHTTPServer hard-codes Content-Type for error messages
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1492>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6321] Reload Python modules when running programs
samwyse added the comment: [issue5847] fixed in 2.7/3.1 -- resolution: -> out of date status: open -> closed ___ Python tracker <http://bugs.python.org/issue6321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6321] Reload Python modules when running programs
samwyse added the comment: As it happens, I do use Windows and almost exclusively start IDLE via right-clicks on .py files. I've never seen the behavior you describe documented anywhere. On Aug 15, 2010, at 1:37 PM, Cherniavsky Beni wrote: > > Cherniavsky Beni added the comment: > > When you run a program using F5 in IDLE, > it completely restarts the underlying interpreter! > If you meant a different way of running, please elaborate. > > (Exception: it uses the same interpreter if you're running "idle -n"; this > commonly happens on Windows if you rightclick->Edit with IDLE... a .py file - > just don't use that.) > > -- > nosy: +cben > > ___ > Python tracker > <http://bugs.python.org/issue6321> > ___ -- ___ Python tracker <http://bugs.python.org/issue6321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10178] PEP 378 uses replace where translate may work better
New submission from samwyse :
PEP 378 states;
format(n, "6,f").replace(",", "X").replace(".", ",").replace("X", ".")
This is complex and relatively slow. A better technique, which IMHO the
proposal should high-lighted, would be:
swap_commas_and_periods = bytes.maketrans(b',.', b'.,')
format(n, "6,f").translate(swap_commas_and_periods)
While performing the maketrans each time a string is formatted is slower than
the triple replace, calling it once and caching the result is faster. I have
tested with with the 3.1 interpreter; example timings follow.
>>> Timer("""
'1,234,567.89'.replace(',', 'X').replace('.', ',').replace('X', '.')
""").timeit()
3.0645400462908015
>>> Timer("""
'1,234,567.89'.translate(swap_commas_and_periods)
""", """
swap_commas_and_periods = bytes.maketrans(b',.', b'.,')
""").timeit()
2.276630409730846
>>> Timer("""
'1,234,567.89'.translate(bytes.maketrans(b',.', b'.,'))
""").timeit()
3.760715677551161
--
assignee: d...@python
components: Documentation
messages: 119427
nosy: d...@python, samwyse
priority: normal
severity: normal
status: open
title: PEP 378 uses replace where translate may work better
type: behavior
versions: Python 2.7, Python 3.1
___
Python tracker
<http://bugs.python.org/issue10178>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10178] PEP 378 uses replace where translate may work better
samwyse added the comment: The text in question is also talking about the problems with using 'replace' to swap pairs of characters, so a better, alternate, process would be valuable, especially for anyone unaware of the translate method. -- ___ Python tracker <http://bugs.python.org/issue10178> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
samwyse added the comment: Refactoring sounds like a good idea. Someone would need to check how other web servers log this, if at all. You're probably right about the HTTP/0.9 as well. The main reason to send a 100 response is because the client sent an "Expect: 100-continue" header, and won't send data until either it receives the header or a timeout expires. The server is expected to validate the received headers before sending the response, although it is allowed to send it in any event. __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1491> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
samwyse <[EMAIL PROTECTED]> added the comment:
Although any given implementation of an HTTP server is likely to serve
up its headers in a predicable, repeatable, order, I don't think that
we should specify a particular order in the test suite. Section 4.2
of RFC 2616 specifically states, "The order in which header fields
with differing field names are received is not significant." So, I
dislike these (and similar) statements in the patch:
+self.assertTrue(result[1].startswith('Server: '))
+self.assertTrue(result[2].startswith('Date: '))
+self.assertTrue(result[3].startswith('Content-Type: '))
I think it would be better to say this:
+self.assertEqual(sum(r.startswith('Server: ') for r in
result[1:-1]), 1)
+self.assertEqual(sum(r.startswith('Date: ') for r in result[1:-1]), 1)
+self.assertEqual(sum(r.startswith('Content-Type: ') for r in
result[1:-1]), 1)
or even this:
+# Verify that certain message headers occur exactly once.
+for fieldName in 'Server: ', 'Date: ', 'Content-Type: ':
+self.assertEqual(sum(r.startswith(fieldName) for r in
result[1:-1]), 1)
(Note that in test_with_continue_1_1, you'd need to say result[2:-1].)
On Sat, May 10, 2008 at 2:34 PM, Jeremy Thurgood <[EMAIL PROTECTED]> wrote:
>
> Jeremy Thurgood <[EMAIL PROTECTED]> added the comment:
>
> Added handling for "Expect: 100-continue" header to
> BaseHTTPRequestHandler. By default, any request that has this header
> gets a 100 Continue response (with no other headers) before
> do_WHATEVER() is called. By overriding handle_expect_100(), you can
> reject incoming requests instead of sending a 100 Continue if you so desire.
>
> Refactoring as per comments above was also performed.
>
> Note: This patch changes the default behaviour in the case where both
> the client and the server claim to support HTTP/1.1 from doing nothing
> in the case of an "Expect: 100-continue" header on the request to
> sending a 100 Continue response and then completing the request as normal.
>
> --
> keywords: +patch
> nosy: +jerith
> Added file: http://bugs.python.org/file10269/BaseHTTPServer_continue.patch
>
> __
> Tracker <[EMAIL PROTECTED]>
> <http://bugs.python.org/issue1491>
> __
>
__
Tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue1491>
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1491] BaseHTTPServer incorrectly implements response code 100
samwyse <[EMAIL PROTECTED]> added the comment: In the attached file, I've refactored the entire BaseHTTPRequestHandlerTestCase class. In doing so, I couldn't help but notice that we're expecting HTTP/1.1 responses when sending HTTP/1.0 requests. RFC 2616 is unclear about whether this is legitimate, but I'm not going to tackle it tonight. Added file: http://bugs.python.org/file10278/BaseHTTPRequestHandlerTestCase.py __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1491> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43556] fix attr names for ast.expr and ast.stmt
New submission from Samwyse : In Doc/library/ast.rst, the lineno and end_col attributes are repeated; the second set should have 'end_' prefixed to them. Also, there's a minor indentation error in the RST file. # diff ast.rst ast.rst~ 78c78 < col_offset --- > col_offset 83c83 < :attr:`lineno`, :attr:`col_offset`, :attr:`end_lineno`, and :attr:`end_col_offset` --- > :attr:`lineno`, :attr:`col_offset`, :attr:`lineno`, and > :attr:`col_offset` -- assignee: docs@python components: Documentation messages: 389077 nosy: docs@python, samwyse priority: normal severity: normal status: open title: fix attr names for ast.expr and ast.stmt type: enhancement versions: Python 3.9 ___ Python tracker <https://bugs.python.org/issue43556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44882] add .rollback() for in-place filters
New submission from Samwyse : Sometimes bad things happen when processing an in-place filter, leaving an empty or incomplete input file and a backup file that needs to recovered. The FileInput class has all the information needed to do this, but it is in private instance variables. A .rollback() method could close the current file and rename the backup file to its original name. For example: for line in fileinput.input(inplace=True): try: ... except SomeError: fileinput.rollback(close=False) # continue with next file A simplistic implementation could be: def rollback(self, close=True): if self._backupfilename: os.rename(self._backupfilename, self.filename) self._backupfilename = None if close: self.close() else: self.nextfile() -- components: Library (Lib) messages: 399361 nosy: samwyse priority: normal severity: normal status: open title: add .rollback() for in-place filters type: enhancement versions: Python 3.10, Python 3.11, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44882] add FileInput.rollback() for in-place filters
Change by Samwyse : -- title: add .rollback() for in-place filters -> add FileInput.rollback() for in-place filters ___ Python tracker <https://bugs.python.org/issue44882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45656] argparse bug: prefix_chars argument to add_argument_group doesn't really work
New submission from Samwyse : Using the prefix_chars argument to parser.add_argument_group causes usage information to print correctly, but the resulting parser doesn't recognize the options. The included program reproduces the issue; it produces the following output on my system. --- python version 3.6.8 (default, Sep 26 2019, 11:57:09) [GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] --- test using prefix_chars='-/' with ArgumentParser --- show help info usage: test-1 [-h] [-foo FOO] [/bar BAR] optional arguments: -h, --help show this help message and exit -foo FOO /bar BAR --- try parsing something Namespace(bar='b', foo='f') --- test using prefix_chars='-/' with an argument group --- show help info usage: test-2 [-h] [-foo FOO] [/bar BAR] optional arguments: -h, --help show this help message and exit other arguments: -foo FOO /bar BAR --- try parsing something usage: test-2 [-h] [-foo FOO] [/bar BAR] test-2: error: unrecognized arguments: /bar b -- components: Library (Lib) files: argparser-bug.py messages: 405217 nosy: samwyse priority: normal severity: normal status: open title: argparse bug: prefix_chars argument to add_argument_group doesn't really work type: behavior versions: Python 3.6 Added file: https://bugs.python.org/file50410/argparser-bug.py ___ Python tracker <https://bugs.python.org/issue45656> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29940] Add follow_wrapped=True option to help()
New submission from Samwyse: The help(obj) function uses the type of obj to create its result. This is less than helpful when requesting help on a wrapped object. Since 3.5, inspect.signature() and inspect.from_callable() have a follow_wrapped option to get around similar issues. Adding the option to help() would prevent surprising behavior while still allowing current behavior to be used when needed. See http://stackoverflow.com/a/17705456/603136 for more. -- components: Library (Lib) messages: 290782 nosy: samwyse priority: normal severity: normal status: open title: Add follow_wrapped=True option to help() type: enhancement versions: Python 2.7, Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <http://bugs.python.org/issue29940> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33158] Add fileobj property to csv reader and writer objects
New submission from Samwyse : Many objects have properties that allow access to the arguments used to create them. In particular, file objects have a name property that returns the name used when opening a file. A fileobj property would be convenient, as you otherwise, for example, need to pass an extra argument to routines that need both the csv object and the underlying file object. Adopting this enhancement would also provide consistency with the dialect constructer argument, which is available as an object property. Changing the fileobj while the csv object is in use would open a can of worms, so this should be a read-only property. Optionally, the fileobj property could be reflected in the DictReader and DictWriter classes, but the value would be accessible via the .reader and .writer properties of those classes. -- components: Library (Lib) messages: 314538 nosy: samwyse priority: normal severity: normal status: open title: Add fileobj property to csv reader and writer objects type: enhancement versions: Python 2.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33158> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18191] urllib2/urllib.parse.splitport does not handle IPv6 correctly
Samwyse added the comment: Fixes Serhiy Storchaka's complaints, removes duplicate test. -- nosy: +samwyse Added file: http://bugs.python.org/file31013/test_urlparse.diff ___ Python tracker <http://bugs.python.org/issue18191> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18191] urllib2/urllib.parse.splitport does not handle IPv6 correctly
Samwyse added the comment: Handles "raw" IPv6 URLs -- Added file: http://bugs.python.org/file31015/urllib.diff ___ Python tracker <http://bugs.python.org/issue18191> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15289] Adding __getitem__ as a class method doesn't work as expected
New submission from samwyse : I'm using a class as a decorator, and saving information in a class variable. I wanted to access the information via a __getitem__ class method, but using conventional syntax doesn't work on a class. The following exception is thrown when the attached script is run. Traceback (most recent call last): File "/Users/sam/Documents/forth.py", line 34, in print Alias["f'"] TypeError: 'type' object has no attribute '__getitem__' -- components: None files: 20120607.py messages: 164926 nosy: samwyse priority: normal severity: normal status: open title: Adding __getitem__ as a class method doesn't work as expected type: behavior versions: Python 2.7 Added file: http://bugs.python.org/file26309/20120607.py ___ Python tracker <http://bugs.python.org/issue15289> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15289] Adding __getitem__ as a class method doesn't work as expected
samwyse added the comment: Thanks, Eric. Based on what you said, I was able to get the desired behavior by creating a metaclass. -- Added file: http://bugs.python.org/file26343/Issue15289.py ___ Python tracker <http://bugs.python.org/issue15289> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus
Changes by samwyse : -- nosy: +samwyse ___ Python tracker <http://bugs.python.org/issue13866> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13866] {urllib, urllib.parse}.urlencode should not use quote_plus
samwyse added the comment:
Since no one else seems willing to do it, here's a patch that adds a
'quote_via' keyword parameter to the urlencode function.
>>> import urllib.parse
>>> query={"foo": "+ "}
>>> urllib.parse.urlencode(query)
'foo=%2B+'
>>> urllib.parse.urlencode(query, quote_via=urllib.parse.quote)
'foo=%2B%20'
--
keywords: +patch
Added file: http://bugs.python.org/file26378/urllib_parse.diff
___
Python tracker
<http://bugs.python.org/issue13866>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear
New submission from samwyse :
The doc string for url encode states:
The query arg may be either a string or a bytes type. When query arg is a
string, the safe, encoding and error parameters are sent to the quote_via
function for encoding
IMHO, this implies that the argument can be a string. Note that the preceding
paragraphs starts out with "If the query arg is a sequence of two-element
tuples". I think that it should read:
The components of the query arg may be either a string or a bytes
type. When query arg is a string, the safe, encoding and error
parameters are sent to the quote_via function for encoding.
--
components: Library (Lib)
messages: 165440
nosy: samwyse
priority: normal
severity: normal
status: open
title: {urllib,urllib.parse}.urlencode.__doc__ is unclear
type: behavior
versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue15350>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15327] Argparse: main arguments and subparser arguments indistinguishable
samwyse added the comment:
The Namespace object contains a combined list of all of the arguments, from
both the main parser and the subparser. I don't see any way to resolve
identically name augments without breaking a lot of code that relies on the
current behavior. I would instead propose that anyone needing to distinguish
between identically named args in nested parsers use distinct names as the
primary name of the argument, and the non-distictive name as an alias. For
example:
parser.add_argument('--verbose(main)', '--verbose', ...)
Running the attached file produces the following output.
# using non-distinctive args
['--verbose', 'command'] => Namespace(command='command', verbose=True)
['command', '--verbose'] => Namespace(command='command', verbose=True)
['--verbose', 'command', '--verbose'] => Namespace(command='command',
verbose=True)
# using distinctive args
['--verbose', 'command'] => Namespace(command='command', verbose(main)=True,
verbose(subcommand)=False)
['command', '--verbose'] => Namespace(command='command', verbose(main)=False,
verbose(subcommand)=True)
['--verbose', 'command', '--verbose'] => Namespace(command='command',
verbose(main)=True, verbose(subcommand)=True)
--
nosy: +samwyse
Added file: http://bugs.python.org/file26379/argparsetest.py
___
Python tracker
<http://bugs.python.org/issue15327>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15327] Argparse: main arguments and subparser arguments indistinguishable
samwyse added the comment:
One change and one minor problem with my suggestion.
First, you don't need the second alias, since it's a prefix of the argument
name. Also, HelpFormatter._format_actions_usage ends with a bit of code
labeled "clean up separators for mutually exclusive groups"; it removes matched
parentheses from the argument names. :( I'd recommend that you instead use
one of the following (all of which I've tested):
parser.add_argument('--verbose[main]', ...)
parser.add_argument('--verbose{main}', ...)
parser.add_argument('--verbose', ...)
--
___
Python tracker
<http://bugs.python.org/issue15327>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16122] Allow *open* to accept file-like objects
New submission from samwyse: I'm once again frustrated by a third-party module that only accepts filenames, not already-opened file-like objects. This prevents me from passing in StringIO objects or any of the standard file streams. Currently, *open()* function accepts strings or (in Python 3.X) integers. I propose that *open()* accept "file-like" objects, either returning them unchanged, or by returning a wrapper object. While there are many different types of file-like objects, they all have one characteristic in common: the presence of a .close() method. A non-wrapped version of open() could be as simple as this: try: file = original_open(name, mode, buffering) except TypeError: if hasattr(name, 'close'): return name raise Returning a wrapper object would be slightly more complicated, but would allow the wrapped object to remain open even after the wrapper is closed. -- components: IO messages: 171908 nosy: samwyse priority: normal severity: normal status: open title: Allow *open* to accept file-like objects type: enhancement versions: Python 2.7, Python 3.5 ___ Python tracker <http://bugs.python.org/issue16122> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue15350] {urllib,urllib.parse}.urlencode.__doc__ is unclear
samwyse added the comment: Look good. I'd fix the last line, however: "sent the quote_plus" -> "sent to the quote_plus function", maybe. On Fri, Sep 28, 2012 at 6:18 AM, Brian Brazil wrote: > > Brian Brazil added the comment: > > How does the attached patch look? > > I also reworded the first line to be a bit clearer, and be under 80 chars. > > -- > keywords: +patch > nosy: +bbrazil > Added file: http://bugs.python.org/file27329/issue15350.patch > > ___ > Python tracker > <http://bugs.python.org/issue15350> > ___ -- ___ Python tracker <http://bugs.python.org/issue15350> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21413] urllib.request.urlopen dies on non-basic/digest auth schemes
New submission from Samwyse: In Python 2.x, this opens an NTLM protected URL: opener = urllib2.build_opener(proxy_handler, auth_NTLM, auth_digest, auth_basic) urllib2.install_opener(opener) response = urllib2.urlopen(url) In Python 3.x, this raises an error: opener = urllib.request.build_opener(proxy_handler, auth_NTLM, auth_digest, auth_basic) urllib.request.install_opener(opener) response = urllib.request.urlopen(url) The error is: ValueError: AbstractDigestAuthHandler does not support the following scheme: 'NTLM' Removing auth_digest from the list of handlers allows the code to work. -- components: Library (Lib) messages: 217734 nosy: samwyse priority: normal severity: normal status: open title: urllib.request.urlopen dies on non-basic/digest auth schemes versions: Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue21413> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3058] Let SimpleXMLRPCServer pass client_address to called functions.
samwyse added the comment:
A more general solution would be to pass the RequestHandler instance as
a parameter to the dispatch function. This would allow the function to
pick out more than just the client address. To avoid breaking
pre-existing code, this should be made optional, perhaps by adding a
keyword to the register_function method. Something like this:
def __init__(...):
self._include_request = set()
def register_function(..., include_request=False):
self._include_request.add(method)
Later, the dispatch function would be invoked like this:
kwds = {}
if method in self._include_request:
kwds.update(request=self)
[...]
return self.instance._dispatch(method, params, **kwds)
[...]
return func(client_address, *params, **kwds)
--
nosy: +samwyse
___
Python tracker
<http://bugs.python.org/issue3058>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6321] Reload Python modules when running programs
New submission from samwyse : Every time IDLE is asked to run a program, it doesn't ensure that the modules referenced by the program are completely loaded. This can cause problems if one of those modules is also being edited, because once it is loaded, any subsequent changes are not compiled and re-loaded. PyUnit faced a similar problem and solved it with a custom importer (http://pyunit.sourceforge.net/notes/reloading.html). Ideally, the custom importer would be used in two places: The obvious choice is when a program is run, unloading when it returns. The less obvious is when the Python Shell window is opened, since import statements can be run from there as well. Closing that window should cause all such imports to be unloaded. Of course, care must be taken to insure that all run commands are properly nested within the lifetime of a shell window. -- components: IDLE messages: 89593 nosy: samwyse severity: normal status: open title: Reload Python modules when running programs type: feature request versions: Python 3.0 ___ Python tracker <http://bugs.python.org/issue6321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3058] Let SimpleXMLRPCServer pass client_address to called functions.
samwyse added the comment: More importantly, the dispatch method is now part of the SimpleXMLRPCDispatcher, which (as a mix-in class) has no direct access to the RequestHandler instance that comprises the request. This breaks Victor's and my idea, unless one is willing to subclass SimpleXMLRPCRequestHandler to provide a_dispatch method. The ability to do this, however, is only provided for backward compatibility and I doubt it could be part of a general solution. On Thu, Jul 8, 2010 at 11:33 PM, Terry J. Reedy wrote: > > Terry J. Reedy added the comment: > > In 3.x, class SimpleXMLRPCServer lives in module xmlrpc.server > > -- > nosy: +tjreedy > versions: +Python 3.2 -Python 2.5 > > ___ > Python tracker > <http://bugs.python.org/issue3058> > ___ > -- Added file: http://bugs.python.org/file17956/unnamed ___ Python tracker <http://bugs.python.org/issue3058> ___More importantly, the dispatch method is now part of the SimpleXMLRPCDispatcher, which (as a mix-in class) has no direct access to the RequestHandler instance that comprises the request.  This breaks Victor's and my idea, unless one is willing to subclass SimpleXMLRPCRequestHandler to provide a_dispatch method.  The ability to do this, however, is only provided for backward compatibility and I doubt it could be part of a general solution. On Thu, Jul 8, 2010 at 11:33 PM, Terry J. Reedy <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> wrote: Terry J. Reedy <mailto:tjre...@udel.edu";>tjre...@udel.edu> added the comment: In 3.x, class  SimpleXMLRPCServer lives in module xmlrpc.server -- nosy: +tjreedy versions: +Python 3.2 -Python 2.5 ___ Python tracker <mailto:rep...@bugs.python.org";>rep...@bugs.python.org> <http://bugs.python.org/issue3058"; target="_blank">http://bugs.python.org/issue3058> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17229] unable to discover preferred HTTPConnection class
New submission from Samwyse: When a URL is opened, the opener-director is responsible for locating the proper handler for the specified protocol. Frequently, an existing protocol handler will be subclassed and then added to the collection maintained by the director. When urlopen is called, the specified request is immediately handed off to the director's "open" method which finds the correct handler and invokes the protocol-specific XXX_open method. At least in the case of the HTTP protocols, if an error occurs then the director is called again to find and invoke a handler for the error; these handlers generally open a new connection after adding headers to avoid the error going forward. Finally, it is important to note that at the present time, the HTTP handlers in urllib2 are built using a class (infourl) that isn't prepared to deal with a persistent connection, so they always add a "Connection: close" header to the request. Unfortunately, NTLM only certifies the current connection, meaning that a "Connection: keep-alive" header must be used to keep it open throughout the authentication process. Furthermore, because the opener director only provides a do_open method, there is no way to discover the type of connection without also opening it. This means that the HTTPNtlmAuthHandler cannot use the normal HTTPHandler and must therefore must hardcode the HTTPConnection class. If a custom class is required for whatever reason, the only way to cause it to be used is to monkey-patch the code. For an example, see http://code.google.com/p/python-ntlm/source/browse/trunk/python26/ntlm_examples/test_ntlmauth.py This can be avoided if, instead of putting the instantiation of the desired HTTP connection class inline, the HTTPHandler classes used a class instance variable. Something like the following should work without breaking any existing code: class HTTPHandler(AbstractHTTPHandler): _connection = httplib.HTTPConnection @property def connection(self): """Returns the class of connection being handled.""" return self._connection def http_open(self, req): return self.do_open(_connection, req) http_request = AbstractHTTPHandler.do_request_ -- components: Library (Lib) messages: 182343 nosy: samwyse priority: normal severity: normal status: open title: unable to discover preferred HTTPConnection class versions: 3rd party, Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue17229> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
New submission from Samwyse:
The csv module currently implements four quoting rules for dialects:
QUOTE_MINIMAL, QUOTE_ALL, QUOTE_NONNUMERIC and QUOTE_NONE. These rules treat
values of None the same as an empty string, i.e. by outputting two consecutive
quotes. I propose the addition of two new rules, QUOTE_NOTNULL and
QUOTE_STRINGS. The former behaves like QUOTE_ALL while the later behaves like
QUOTE_NONNUMERIC, except that in both cases values of None are output as an
empty field. Examples follow.
Current behavior (which will remain unchanged)
>>> csv.register_dialect('quote_all', quoting=csv.QUOTE_ALL)
>>> csv.writer(sys.stdout, dialect='quote_all').writerow(['foo', None, 42])
"foo","","42"
>>> csv.register_dialect('quote_nonnumeric', quoting=csv.QUOTE_NONNUMERIC)
>>> csv.writer(sys.stdout, dialect='quote_nonnumeric').writerow(['foo', None,
>>> 42])
"foo","",42
Proposed behavior
>>> csv.register_dialect('quote_notnull', quoting=csv.QUOTE_NOTNULL)
>>> csv.writer(sys.stdout, dialect='quote_notnull').writerow(['foo', None, 42])
"foo",,"42"
>>> csv.register_dialect('quote_strings', quoting=csv.QUOTE_STRINGS)
>>> csv.writer(sys.stdout, dialect='quote_strings').writerow(['foo', None, 42])
"foo",,42
--
components: Library (Lib)
messages: 232560
nosy: samwyse
priority: normal
severity: normal
status: open
title: csv needs more quoting rules
type: enhancement
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue23041>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Samwyse added the comment:
David: That's not a problem for me.
Sorry I can't provide real patches, but I'm not in a position to compile (much
less test) the C implementation of _csv. I've looked at the code online and
below are the changes that I think need to be made. My use cases don't require
special handing when reading empty fields, so the only changes I've made are to
the code for writers. I did verify that the reader code mostly only checks for
QUOTE_NOTNULL when parsing. This means that completely empty fields will
continue to load as zero-length strings, not None. I won't stand in the way of
anyone wanting to "fix" that for these new rules.
typedef enum {
QUOTE_MINIMAL, QUOTE_ALL, QUOTE_NONNUMERIC, QUOTE_NONE,
QUOTE_STRINGS, QUOTE_NOTNULL
} QuoteStyle;
static StyleDesc quote_styles[] = {
{ QUOTE_MINIMAL,"QUOTE_MINIMAL" },
{ QUOTE_ALL,"QUOTE_ALL" },
{ QUOTE_NONNUMERIC, "QUOTE_NONNUMERIC" },
{ QUOTE_NONE, "QUOTE_NONE" },
{ QUOTE_STRINGS,"QUOTE_STRINGS" },
{ QUOTE_NOTNULL,"QUOTE_NOTNULL" },
{ 0 }
};
switch (dialect->quoting) {
case QUOTE_NONNUMERIC:
quoted = !PyNumber_Check(field);
break;
case QUOTE_ALL:
quoted = 1;
break;
case QUOTE_STRINGS:
quoted = PyString_Check(field);
break;
case QUOTE_NOTNULL:
quoted = field != Py_None;
break;
default:
quoted = 0;
break;
}
"csv.QUOTE_MINIMAL means only when required, for example, when a\n"
"field contains either the quotechar or the delimiter\n"
"csv.QUOTE_ALL means that quotes are always placed around fields.\n"
"csv.QUOTE_NONNUMERIC means that quotes are always placed around\n"
"fields which do not parse as integers or floating point\n"
"numbers.\n"
"csv.QUOTE_STRINGS means that quotes are always placed around\n"
"fields which are strings. Note that the Python value None\n"
"is not a string.\n"
"csv.QUOTE_NOTNULL means that quotes are only placed around fields\n"
"that are not the Python value None.\n"
--
___
Python tracker
<http://bugs.python.org/issue23041>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Samwyse added the comment: Yes, it's based on a real-world need. I work for a Fortune 500 company and we have an internal tool that exports CSV files using what I've described as the QUOTE_NOTNULL rules. I need to create similar files for re-importation. Right now, I have to post-process the output of my Python program to get it right. I added in the QUOTE_STRINGS rule for completeness. I think these two new rules would be useful for anyone wanting to create sparse CSV files. -- ___ Python tracker <http://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23059] sort misc help topics in cmd
New submission from Samwyse: I've discovered that do_help method of cmd.Cmd prints the documented and undocumented commands in sorted order, but does not sort the miscellaneous topics. This would be an easy fix, just change "self.print_topics(self.misc_header, help.keys(),15,80)" to use "sorted(help.keys())". -- components: Library (Lib) messages: 232680 nosy: samwyse priority: normal severity: normal status: open title: sort misc help topics in cmd versions: Python 3.5 ___ Python tracker <http://bugs.python.org/issue23059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23041] csv needs more quoting rules
Samwyse added the comment: Skip, I don't have any visibility into how the Java program I'm feeding data into works, I'm just trying to replicate the csv files that it exports as accurately as possible. It has several other quirks, but I can replicate all of them using Dialects; this is the only "feature" I can't. The files I'm looking at have quoted strings and numbers, but there aren't any quoted empty strings. I'm using a DictWriter to create similar csv files, where missing keys are treated as values of None, so I'd like those printed without quotes. If we also want to print empty strings without quotes, that wouldn't impact me at all. Besides my selfish needs, this could be useful to anyone wanting to reduce the save of csv files that have lots of empty fields, but wants to quote all non-empty values. This may be an empty set, I don't know. -- ___ Python tracker <http://bugs.python.org/issue23041> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23059] cmd module should sort misc help topics
Changes by Samwyse : -- title: sort misc help topics in cmd -> cmd module should sort misc help topics ___ Python tracker <http://bugs.python.org/issue23059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25760] TextWrapper fails to split 'two-and-a-half-hour' correctly
New submission from Samwyse:
Single character words in a hyphenated phrase are not split correctly. The
root issue it the wordsep_re class variable. To reproduce, run the following:
>>> import textwrap
>>> textwrap.TextWrapper.wordsep_re.split('two-and-a-half-hour')
['', 'two-', 'and-a', '-half-', 'hour']
It works if 'a' is replaces with two or more alphabetic characters.
>>> textwrap.TextWrapper.wordsep_re.split('two-and-aa-half-hour')
['', 'two-', '', 'and-', '', 'aa-', '', 'half-', 'hour']
The problem is in this part of the pattern: (?=\w+[^0-9\W])
I confess that I don't understand the situation that would require that
complicated of a pattern. Why wouldn't (?=\w) would work?
--
components: Library (Lib)
messages: 28
nosy: samwyse
priority: normal
severity: normal
status: open
title: TextWrapper fails to split 'two-and-a-half-hour' correctly
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4
___
Python tracker
<http://bugs.python.org/issue25760>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26299] wsgiref.util FileWrapper raises ValueError: I/O operation on closed file.
New submission from Samwyse: While developing, I am using wsgiref.simple_server. Using to serve static content isn't working. The attached program demonstrates the issue. Run it and connect to http://127.0.0.1:8000/. You will see three buttons. Clicking on 'wsgi.filewrapper' causes the FileWrapper class found in wsgiref.util to be used, while clicking on 'PEP 0333' uses code suggested in PEP 0333 (https://www.python.org/dev/peps/pep-0333/#id36). Both of these fail. Clicking on 'slurp' causes the entire file to loaded and returned in a list. This works. When an application returns an instance of environ['wsgi.file_wrapper'], or creates it's own iterator, an error is raised during the initial read of the file. Reading the entire file and returning a single-element list (the 'slurp' technique) works, but is impractical for larger files. I've tested this with both Python 2.7.9 and 3.4.3 under Windows 7 (my laptop) and 3.4.3 under Alpine Linux (a Docker instance). -- components: Library (Lib) files: wsgitest.py messages: 259685 nosy: samwyse priority: normal severity: normal status: open title: wsgiref.util FileWrapper raises ValueError: I/O operation on closed file. versions: Python 2.7, Python 3.4 Added file: http://bugs.python.org/file41828/wsgitest.py ___ Python tracker <http://bugs.python.org/issue26299> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
