[Python-Dev] bpo-34788 needs a review
Hello 2019-06-03 I have created PR https://github.com/python/cpython/pull/13772 , which adds IPv6 scoped addresses support to ipaddress module. It is very critical to everyone, who is dealing with IPv6 networking. For example, in salt project they use patched module. So, it would be very nice to have my changes merged and avoid such a workarounds. Here is link to the bug - https://bugs.python.org/issue34788. Please, pay attention to this issue. KR Oleksandr Pavliuk ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YGQPPICZHAV33UD3I3MHLDKH2MHKIRWZ/
[Python-Dev] bpo-37468: make install no longer install wininst-*.exe files
Hi, I modified Makefile.pre.in to avoid installing wininst-*.exe files, since these files are only useful on Windows: the distutils bdist_wininst command only works on Windows. https://bugs.python.org/issue37468 I made the assumption that "make install" is only used on Unix, not on Windows. I never tried to build Python in Cygwin or MinGW on Windows. If someone knows these platforms, and consider that wininst-*.exe should still be installed on these platforms, please propose a pull request for bpo-37468. By the way, bdist_wininst is now deprecated in Python 3.8: wheel packages are now preferred. https://bugs.python.org/issue37481 Victor -- Night gathers, and now my watch begins. It shall not end until my death. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/53T647PT4F5QZ5NOX2GDLMMPC5EPJY4Y/
[Python-Dev] Re: bpo-34788 needs a review
On 7/15/2019 3:55 AM, Sasha Pavlyuk wrote: Hello 2019-06-03 I have created PR https://github.com/python/cpython/pull/13772 , which adds IPv6 scoped addresses support to ipaddress module. It is very critical to everyone, who is dealing with IPv6 networking. For example, in salt project they use patched module. So, it would be very nice to have my changes merged and avoid such a workarounds. Here is link to the bug - https://bugs.python.org/issue34788. Please, pay attention to this issue. The ipaddress maintainer seems not to be very active currently. Having an enhancement issue mismarked as documentation (fixed) might have discouraged anyone else from taking a look. -- Terry Jan Reedy ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/DHNR77IOFE6ZYFM7UJKT7UCNKC4ZUMFT/
[Python-Dev] Re: What is a public API?
On Jul 13, 2019, at 19:09, Raymond Hettinger wrote: > > In some modules, we've been careful to use both __all__ and to use an > underscore prefix to indicate private variables and helper functions > (collections and random for example). IMO, when a module has shown that > care, future maintainers should stick with that practice. > > The calendar module is an example of where that care was taken for many years > and then a recent patch went against that practice. This came to my > attention when an end-user questioned which functions were for internal use > only and posted their question on Twitter. On the tracker, I then made a > simple request to restore the module's convention but you seem steadfastly > resistant to the suggestion. > > When we do have evidence of user confusion (as in the case with the calendar > module), we should just fix it. IMO, it would be an undue burden on the user > to have to check every method in dir() against the contents of __all__ to > determine what is public (see below). Also, as a maintainer of the module, I > would not have found it obvious whether the functions were public or not. > The non-public functions look just like the public ones. > > It's true that the practices across the standard library have historically > been loose and varied (__all__ wasn't always used and wasn't always kept > up-to-date, some modules took care with private underscore names and some > didn't). To me this has mostly worked out fine and didn't require a strict > rule for all modules everywhere. IMO, there is no need to sweep through the > library and change long-standing policies on existing modules. EIBTI Shameless plug: https://public.readthedocs.io/en/latest/ -Barry signature.asc Description: Message signed with OpenPGP ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XVIS6XYLJ7EEKFLOY2KIT4ARLPTDV3M7/
