[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
Change by John Florian : -- nosy: -John Florian ___ Python tracker <https://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35989] ipaddress.IPv4Network allows prefix > 32
New submission from John Florian :
I wanted a simple is_valid_ipv4_network() function, so I wrote one and a bunch
of unit tests where I discovered that I can legally:
>>> n = IPv4Network(('192.168.123.234', 12345678))
>>> n
IPv4Network('192.168.123.234/12345678')
>>> n.prefixlen
12345678
>>> n.max_prefixlen
32
I assume this is a bug.
--
messages: 335460
nosy: John Florian
priority: normal
severity: normal
status: open
title: ipaddress.IPv4Network allows prefix > 32
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35989>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue35990] ipaddress.IPv4Interface won't accept 2-tuple (address, mask)
New submission from John Florian :
The docs say """The meaning of address is as in the constructor of IPv4Network,
except that arbitrary host addresses are always accepted."""
However, that doesn't seem to be entirely true:
>>> tup1 = ('192.168.123.234', 24)
>>> tup2 = ('192.168.123.234', '255.255.255.0')
>>> IPv4Network(tup1, strict=False)
IPv4Network('192.168.123.0/24')
>>> IPv4Network(tup2, strict=False)
IPv4Network('192.168.123.0/24')
>>> IPv4Interface(tup1)
IPv4Interface('192.168.123.234/24')
>>> IPv4Interface(tup2)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib64/python3.7/ipaddress.py", line 1391, in __init__
self._prefixlen = int(address[1])
ValueError: invalid literal for int() with base 10: '255.255.255.0'
--
messages: 335474
nosy: John Florian
priority: normal
severity: normal
status: open
title: ipaddress.IPv4Interface won't accept 2-tuple (address, mask)
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue35990>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
John Florian added the comment: I just stumbled onto this though I'm not writing for Windows. Instead, I'm on Fedora 25 with Python 3.5.2 and I went nearly crazy tracing down what seemed to be inconsistent behavior. My use case has Python using NamedTemporaryFile(delete=True) in a CM to produce content fed into a subprocess. The code had been reliably working and then it just didn't. The only thing changing was the content being written, an rendered Jinja2 template. I believe the fate is determined by the content length. In debugging another problem, I'd been trivializing the template and once it got down to about 3k (rendered) the subprocess began seeing a file whose length was 0 bytes. Make the template bigger and all works again. Calling close() resolves the issue, but of course requires delete=False which removed much of the value of this object. Preliminary testing looks like flush() may also resolve the issue. Have I just been naive and getting lucky all along because this is expected or is there something else fishy here worth investigation? ------ nosy: +John Florian ___ Python tracker <http://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14243] tempfile.NamedTemporaryFile not particularly useful on Windows
John Florian added the comment: Okay Nick. Thanks for the detailed info. I suspected buffering was a factor, but wasn't certain. Would it be worthwhile pursuing a note in the docs or would that constitute clutter over what should be a standard assumption? I was thrown off course for all the prior uses without issues, but in hindsight I don't know offhand how many involved a subprocess. -- ___ Python tracker <http://bugs.python.org/issue14243> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
