[issue6906] Tkinter sets an unicode environment variable on win32
Jon Foster added the comment: This bug also breaks code that uses the subprocess module, e.g.: env = os.environ.copy() env['MY_VARIABLE'] = 'MY_VAL' subprocess.Popen(... , env=env) Fails on Windows 7 with an error that the environment can only contain strings. The offending variables are TK_LIBRARY and TCL_LIBRARY, which have Unicode strings as their values. I'm using Python 2.6.2. (The subprocess module should probably be fixed to use CreateProcessW and handle Unicode, but that's a separate issue). -- nosy: +JonFoster ___ Python tracker <http://bugs.python.org/issue6906> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18802] ipaddress documentation errors
New submission from Jon Foster: I recently looked at using the ipaddress module in a project, and noticed some discrepencies between the code and the documentation, and some things that weren't documented. A patch to fix these is attached. * The IPv4Network.__init__ documentation wrongly claims that "/0.0.0.0" would be interpreted as a host mask i.e. "/32". It's actually interpreted as a net mask, i.e. "/0". * The IPv[46]Network.netmask property is not documented * The IPv[46]Network.hostmask property is wrongly called "host mask" (with a space!) in the docs * The IPv[46]Network.hostmask property is wrongly documented as a string but it's actually an IPv[46]Address * The IPv6Network.__init__ documentation wrongly claims that a netmask can be specified, but this is not supported by the code. The code only supports prefix lengths. * The documentation should explain how network objects are ordered, since it's not obvious. * The documentation should explain how interface objects are compared, both with other interface objects and with address objects, as it's not obvious. * It's probably a good idea to document that you can't always pass a IPv4Interface object to a function that expects a IPv4Address. * It would be nice to mention that address, network and interface objects are all hashable. Kind regards, Jon -- components: Library (Lib) files: ipaddress_docs_v1.patch keywords: patch messages: 195822 nosy: jongfoster priority: normal severity: normal status: open title: ipaddress documentation errors versions: Python 3.4 Added file: http://bugs.python.org/file31410/ipaddress_docs_v1.patch ___ Python tracker <http://bugs.python.org/issue18802> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18802] ipaddress documentation errors
Jon Foster added the comment: (If this is accepted, please consider it for backport to 3.3 too. It is just a documentation improvement). -- type: -> enhancement versions: +Python 3.3 ___ Python tracker <http://bugs.python.org/issue18802> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18805] ipaddress netmask/hostmask parsing bugs
New submission from Jon Foster:
Short version:
Validation of netmasks and hostmasks in IPv4Network is wrong: it rejects many
valid netmasks, it accepts many invalid netmasks and hostmasks, and it sometimes
throws the wrong exception. Patch attached.
Long version:
Wrongly rejecting hostmasks
---
Creating IPv4Network objects using a hostmask only works for 3 of the 31
possible hostmasks.
It works fine for /8, /16, and /24 networks, but anything else fails. E.g.
first let's
calculate the hostmask for a /21 network:
>>> from ipaddress import IPv4Network
>>> IPv4Network('0.0.0.0/21').hostmask
IPv4Address('0.0.7.255')
Then try using it:
>> IPv4Network('0.0.0.0/0.0.7.255')
Traceback (most recent call last):
File "", line 1, in
File "c:\Python33\lib\ipaddress.py", line 1443, in __init__
% addr[1])
ipaddress.NetmaskValueError: '0.0.7.255' is not a valid netmask
The problem is that there is a list of "_valid_mask_octets". Although the
values listed
are correct for netmasks, they are wrong for host masks. In binary, a netmask
has 1s
in the most significant bits and 0s everywhere else; a hostmask has
0s
in the most significant bits and 1s everywhere else. So netmasks
have
octet values 0b, 0b1110, 0b1100, etc, whereas hostmasks have
octet values 0b, 0b0111, 0b0011, etc.
Wrongly accepting hostmasks
---
Once the individual octets have been validated, the hostmask validation just
checks
the first octet is less than the last octet. This accepts values like
"0.255.0.255",
which is not a valid hostmask. The IPv4Network object then has wierd
nonsensical
values.
Wrongly accepting netmasks
---
Once the individual octets have been validated, the netmask validation just
checks
each octet is no greater than the one before. This accepts values like
"254.192.128.0",
which is not a valid netmask. The IPv4Network object then has wierd nonsensical
values.
Inconsistent parsing
The existing validation code includes its own parsing code. If the
netmask/hostmask
passes that vaildation, it then goes into _ip_int_from_string() to be parsed and
used. _ip_int_from_string() checks things that aren't caught by the validation
code, leading to AddressValueError being thrown when NetmaskValueError was
expected:
>>> IPv4Network('1.2.0.0/0.0.0255.255')
Traceback (most recent call last):
File "", line 1, in
File "c:\Python33\lib\ipaddress.py", line 1440, in __init__
self._ip_int_from_string(addr[1]) ^ self._ALL_ONES)
File "c:\Python33\lib\ipaddress.py", line 1055, in _ip_int_from_string
raise AddressValueError("%s in %r" % (exc, ip_str)) from None
ipaddress.AddressValueError: At most 3 characters permitted in '0255' in
'0.0.0255.255'
The correct fix for this one is obviously to use the same parser in all the
places
we parse the netmask/hostmask.
The patch
-
I'm attaching a patch, with tests, that fixes these issues. Reusing the
existing
_ip_int_from_string() function to parse the netmask/hostmask simplified the
validation code a lot.
My hope is that this patch is suitable for a backport to 3.3, as well as trunk.
--
components: Library (Lib)
files: ipaddress_masks_v1.patch
keywords: patch
messages: 195846
nosy: jongfoster, ncoghlan, pmoody
priority: normal
severity: normal
status: open
title: ipaddress netmask/hostmask parsing bugs
type: behavior
versions: Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31415/ipaddress_masks_v1.patch
___
Python tracker
<http://bugs.python.org/issue18805>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16531] Allow IPNetwork to take a tuple
Changes by Jon Foster : -- nosy: +jongfoster ___ Python tracker <http://bugs.python.org/issue16531> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6930] [PATCH] PyUnicode_DecodeUTF16 docs wrong (byteorder param)
New submission from Jon Foster : The documentation for the C API function PyUnicode_DecodeUTF16() does not match the code. If *byteorder is 1 or -1, the documentation says that the function looks for a BOM. It doesn't. This patch updates the documentation to match the code. (Also, I just realised that the docs for PyUnicode_DecodeUTF32() have the exact same bug. That is NOT fixed by this patch). This patch also clarifies the PyUnicode_EncodeUTF16() docs. -- assignee: georg.brandl components: Documentation files: unicodedocs.patch keywords: patch messages: 92764 nosy: JonFoster, georg.brandl severity: normal status: open title: [PATCH] PyUnicode_DecodeUTF16 docs wrong (byteorder param) type: behavior versions: Python 2.6, Python 2.7 Added file: http://bugs.python.org/file14910/unicodedocs.patch ___ Python tracker <http://bugs.python.org/issue6930> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
