[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
Seppo Yli-Olli <seppo.yli-o...@iki.fi> added the comment: I don't personally know enough of CPython (I barely know enough C) to do the patches but I'd just comment that as this might increase complexity of implementation and wide char API's are used, it might be prudent to make sure the new implementation works with some more exotic input than fits into ASCII. PendingFileRenameOperations can contain any valid Windows path. Microsoft also warns that the end null byte can be redacted in some cases by the party storing the data. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32587] Make REG_MULTI_SZ support PendingFileRenameOperations
New submission from Seppo Yli-Olli <seppo.yli-o...@iki.fi>: MSDN documents that REG_MULTI_SZ is not supposed to have \0\0 anywhere else than in the end. The comment in https://github.com/python/cpython/blob/a5293b4ff2c1b5446947b4986f98ecf5d52432d4/PC/winreg.c#L504 clearly shows that Python has the assumption that this specification is actually correct. However, Microsoft is violating it eg in https://technet.microsoft.com/en-us/library/cc960241.aspx which prevents you from reading that registry key in Python at all. This is a list which is treated as pairs: """ foo meep bar """ so you can have empty items which in Windows semantics means "remove this file". This results in a string like "foo\0\0meep\0\bar\0\0". I'm proposing relaxing Python registry handling semantics because it's clearly Microsoft isn't following this either -- messages: 310202 nosy: nanonyme priority: normal severity: normal status: open title: Make REG_MULTI_SZ support PendingFileRenameOperations ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue32587> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Seppo Yli-Olli added the comment:
Since Renata's ERRATA was unclear to whether or not this was *actually* removed
(please point to a changeset if the option was removed):
If the option is no longer required by Pidgin and that was the original reason
to have it in the first, there's really no reason *not* to remove this, no?
Eg this code
int main() { return 0; }
Fails to compile on MingW gcc 4.6 and 4.7 when passing -mno-cygwin to gcc. The
solution that distutils does not work with current versions of MingW (and GCC)
for good is unacceptable so the only working solution is removal of no-cygwin.
Just that GCC 4.4 would support the flag does not change this bug one way or
the other.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12641
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Seppo Yli-Olli added the comment: ERRATA Misunderstood the meaning of ERRATA, please ignore my last post. Roumen Petrov wrote: Where is written that compiler is gcc ? Yes this is current distutils code but please review my set of patches I kinda like the using --target-help for finding out if -mno-cygwin is supported assuming --target-help is supported by all GCC's. I disliked the version-based approach since back from 2011 since it seems fragile to me. I'm noo sure if it falls into the category of lightweight checks Eric asked for in #msg146499 but at least more lightweight than my proposal of trying to compile a sample program with the compiler. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12641] Remove -mno-cygwin from distutils
Seppo Yli-Olli seppo.ylio...@gmail.com added the comment: Would it be practical to have a trivial compilation test to see if we are capable of using GCC with -mno-cygwin and if so, use it, otherwise drop off? I think GNU autotools uses a similar strategy for detecting compiler capabilities. -- nosy: +Seppo.Yli-Olli ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12641 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12430] Pip fails to fetch from mirror if PyPi checksum times out
New submission from Seppo Yli-Olli seppo.ylio...@gmail.com: Checksums need to be mirrored as well, otherwise having mirrors is a waste of money because PyPi main server being slow ends up with whole download failing. If this is the wrong bug tracker, please advice me to the right one so this can be resolved. -- components: None files: pip.log messages: 139357 nosy: Seppo.Yli-Olli priority: normal severity: normal status: open title: Pip fails to fetch from mirror if PyPi checksum times out versions: Python 2.7 Added file: http://bugs.python.org/file22507/pip.log ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12430 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12430] Pip fails to fetch from mirror if PyPi checksum times out
Changes by Seppo Yli-Olli seppo.ylio...@gmail.com: -- type: - feature request ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12430 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
