Pete Wicken added the comment:
I've opened a PR that should hopefully address this issue.
--
___
Python tracker
<https://bugs.python.org/issue33433>
___
___
Change by Pete Wicken :
--
keywords: +patch
pull_requests: +24799
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/26172
___
Python tracker
<https://bugs.python.org/issu
Change by Pete Wicken :
--
pull_requests: +24255
pull_request: https://github.com/python/cpython/pull/25536
___
Python tracker
<https://bugs.python.org/issue28
Change by Pete Wicken :
--
pull_requests: +24252
pull_request: https://github.com/python/cpython/pull/25533
___
Python tracker
<https://bugs.python.org/issue28
Change by Pete Wicken :
--
pull_requests: +24251
pull_request: https://github.com/python/cpython/pull/25532
___
Python tracker
<https://bugs.python.org/issue28
Pete Wicken added the comment:
Out of curiosity, why is there not much we can do? I'm not familiar enough with
Python's C code to appreciate the difficulty of making the builtins available
at the point where the pickle save is run when exiting. The fact that this
segfaults in the 3.8
New submission from Pete Wicken :
Originally found as an issue in Lib/shelve.py; if we attempt to pickle a
builtin as the program is exiting then Modules/_pickle.c will fail at the point
of the PyImport_Import in save_global. In CPython3.8 this causes a segfault, in
CPython3.9
Pete Wicken added the comment:
The patch for this has been merged - I guess this can be closed now?
--
___
Python tracker
<https://bugs.python.org/issue28
Change by Pete Wicken :
--
nosy: +Wicken
___
Python tracker
<https://bugs.python.org/issue33433>
___
___
Python-bugs-list mailing list
Unsubscribe:
Pete Wicken added the comment:
Ok it was bugging me that they were different, so I also added the same logic
for IPv6Networks.
--
___
Python tracker
<https://bugs.python.org/issue28
Pete Wicken added the comment:
I've had a go at implementing this. I did not implement for IPv6 as this was
not mentioned here, but it seems like it would make sense for it as well. I can
add that in too if you like.
--
___
Python tracker
<ht
Change by Pete Wicken :
--
keywords: +patch
nosy: +Wicken
nosy_count: 5.0 -> 6.0
pull_requests: +18112
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/18757
___
Python tracker
<https://bugs.python.org/i
Change by Pete Wicken :
--
pull_requests: +18053
pull_request: https://github.com/python/cpython/pull/18691
___
Python tracker
<https://bugs.python.org/issue39
Change by Pete Wicken :
--
pull_requests: -18050
___
Python tracker
<https://bugs.python.org/issue39710>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Pete Wicken :
--
nosy: +Wicken
nosy_count: 3.0 -> 4.0
pull_requests: +18050
pull_request: https://github.com/python/cpython/pull/18691
___
Python tracker
<https://bugs.python.org/issu
Pete Wicken added the comment:
In addition to my previous comment, I think a more generic "is_special" could
cover everything in the IANA special purpose address table for ease of checking
anything that isn't publicly available IP.
--
Change by Pete Wicken :
--
components: +Library (Lib)
type: -> behavior
versions: +Python 3.9
___
Python tracker
<https://bugs.python.org/issue38750>
___
_
New submission from Pete Wicken :
As alluded to in issue bpo-38655, the behaviour for getting categorising IPv4
networks is inconsistent with the IANA guideline, which the docs say it follows.
I'm proposing we either change the documentation so that it describes the
behaviour that should
Pete Wicken added the comment:
Looks like this happens because the is_private method that gets called is from
_BaseNetwork, which checks if the network address '0.0.0.0' and the broadcast
address '255.255.255.255' are both private, which they are as 0.0.0.0 falls
into 0.0.0.0/8.
I think
Change by Pete Wicken :
--
keywords: +patch
pull_requests: +16548
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/17036
___
Python tracker
<https://bugs.python.org/issu
Pete Wicken added the comment:
Given the comments above I appreciate that this is actually due to the padding
being the total field width rather than the padding of the digits themselves.
Having revised the documentation again, I believe this following line is
explaining it:
"
New submission from Pete Wicken :
When formatting an integer as a hexadecimal value, the '#' alternate form
modifier inserts a preceding '0x'.
If this is used in combination with padding modifiers, the '0x' is counted as
part of the overall width, which does not feel like the natural
22 matches
Mail list logo
