[issue11166] No exit when daemon thread is running.
Dan Mahn dan.m...@digidescorp.com added the comment: Seems to be fixed in RC3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11166 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11247] e
Changes by Dan Mahn dan.m...@digidescorp.com: -- nosy: dmahn priority: normal severity: normal status: open title: e ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11247] Error sending packets to multicast IPV4 address
New submission from Dan Mahn dan.m...@digidescorp.com: Can't send UDP packet to multicast address. See traceback. s.sendto( bytearray, (227.5.6.7, 6543)) socket.error: [Errno 10065] A socket operation was attempted to an unreachable host -- components: +None title: e - Error sending packets to multicast IPV4 address type: - behavior versions: +Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11247] Error sending packets to multicast IPV4 address
Dan Mahn dan.m...@digidescorp.com added the comment: This has occurred in RC3 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11247 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11166] No exit when daemon thread is running.
New submission from Dan Mahn dan.m...@digidescorp.com: I have a python-based test script that creates a daemon thread. The foreground basically runs a loop of commands, while the daemon thread sends some UDP data on the network. To stop the script, I use Control-C. This is running under 64-bit Windows (Vista) with 64-bit Python. This script was developed under Python version 3.0, and has been running fine with 3.1. I downloaded 3.2RC1 and noticed that the script does not exit with the typical Ctrl-C. I also tried 3.2RC2, which had the same effect. If I do not start the background thread, the test exits normally. If I use Python 3.1, but I don't set the daemon attribute on the background thread, the operation duplicates the problem. Therefore, I believe there is a problem with 3.2 handling of daemon threads. -- components: None messages: 128260 nosy: dmahn priority: normal severity: normal status: open title: No exit when daemon thread is running. type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11166 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5468] urlencode does not handle bytes, and could easily handle alternate encodings
Dan Mahn dan.m...@digidescorp.com added the comment:
Hello. Thanks for the feedback.
With regards to RFC 2396, I see this:
http://www.ietf.org/rfc/rfc2396.txt
There is a second translation for some resources: the sequence of
octets defined by a component of the URI is subsequently used to
represent a sequence of characters. A 'charset' defines this mapping.
There are many charsets in use in Internet protocols. For example,
UTF-8 [UTF-8] defines a mapping from sequences of octets to sequences
of characters in the repertoire of ISO 10646.
To me, that text does not indicate that URLs are always encoded in
UTF-8. It indicates that URL information may be encoded in character
sets ('charset') other than ASCII, and when it is, the values must be
sent as escaped values. Here, I note the specific words many charsets
in use and For example, before the reference to UTF-8.
I have also done a few tests, and have found that in practice, browsers
do not always encode URLs as UTF-8. This actually seems to differ as to
what part of the URL is being encoded. For instance, my Firefox will
encode the path portion of a URL as UTF-8, but encode the query string
as Latin-1.
I think that the general idea is ... URL data must be encoded into
ASCII, but as to what the data is that is being encoded ... That may be
of some charset which may be application-defined. And in the most
general sense, I would argue that the data could simply be binary data.
(Actually, Latin-1 pretty much uses all the codes from 0 to 255, so
it's very much like plain binary data anyway.)
I hope that clarifies what I am reading in RFC 2396.
In addition, quote_plus() already handles all the cases I placed into
urlencode(). I suppose the actual test cases may be debatable, but I
did specifically choose tests with data which would be recognized as
something other then UTF-8.
Jeremy Hylton wrote:
Jeremy Hylton jer...@alum.mit.edu added the comment:
I'm not sure I understand the part of the code that deals with binary
strings. I agree the current behavior is odd. RFC 2396 says that
non-ascii characters must be encoded as utf-8 and then percent escaped.
In the test case you started with, you encoded b'\xa0\x24'. It doesn't
seem like this should be allowed, since it is not valid utf-8.
--
nosy: +jhylton
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5468
___
--
title: urlencode does not handle bytes, and could easily handle alternate
encodings - urlencode does not handle bytes, and could easily handle
alternate encodings
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5468
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5468] urlencode does not handle bytes, and could easily handle alternate encodings
New submission from Dan Mahn dan.m...@digidescorp.com: urllib.parse.urlencode() uses quote_plus() extensively to create a complete query string, but doesn't effectively/properly take advantage of the flexibility built into quote_plus(). Namely: 1) Instances of type bytes are not properly encoded, as str() is used prior to passing to quote_plus(). This creates a nonsensical string such as b'1234', while quote_plus() can handle these types properly if passed intact. The ability to encode this type is particularly useful for putting binary data into the query string, or for pre-encoded text which you may want to encode in a non-standard character encoding. 2) Sometimes it would be desirable to encode query strings entirely in latin-1 or possibly ascii instead of utf-8. Adding the extra parameters now present on quote_plus() can easily give that extra functionality. I have attached a new version of urlencode() that provides both of the above fixes/enhancements. Additionally, an unused codepath in the existing function has been eliminated/cleaned up. Some doctests are included as well. -- components: Library (Lib) files: new_urlencode.py message_count: 1.0 messages: 83434 nosy: dmahn nosy_count: 1.0 severity: normal status: open title: urlencode does not handle bytes, and could easily handle alternate encodings type: behavior versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file13294/new_urlencode.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5468] urlencode does not handle bytes, and could easily handle alternate encodings
Dan Mahn dan.m...@digidescorp.com added the comment: I also made some tests for the new code that could be added to the unit tests in test_urllib.py -- message_count: 1.0 - 2.0 Added file: http://bugs.python.org/file13298/new_urlencode_tests.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5468 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
