[issue36787] Python3 regresison: String formatting of None object
Gawain Bolton added the comment: Note: I have a patch which fixes this. -- ___ Python tracker <https://bugs.python.org/issue36787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue36787] Python3 regresison: String formatting of None object
New submission from Gawain Bolton : Python 2.7.16 (default, Apr 6 2019, 01:42:57) [GCC 8.3.0] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> print('{:^10}'.format(None)) None However this does not work with Python3: Python 3.7.3 (default, Apr 3 2019, 05:39:12) [GCC 8.3.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> print('{:^10}'.format(None)) Traceback (most recent call last): File "", line 1, in TypeError: unsupported format string passed to NoneType.__format__ Given that the None type is output as a string, it makes sense for string formatting options to be usable with it. It also makes code less fragile and avoids having to write special cases for when values could be None. -- components: Library (Lib) messages: 341355 nosy: Gawain Bolton priority: normal severity: normal status: open title: Python3 regresison: String formatting of None object type: behavior ___ Python tracker <https://bugs.python.org/issue36787> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6713] Integer & Long types: Performance improvement of 1.6x to 2x for base 10 conversions
Gawain Bolton added the comment: Here's a modified version of the patch to Objects/intobject.c which __does__ use the two-digits-at-a-time optimization. Compared to the int_decimal_conversion_trunk.patch, my tests show a further 12.5% improvement with two digit numbers - positive or negative and more than 8% overall using different sizes all the way up to sys.maxint. I admit, there is a slight increase in code complexity. However, I disagree that the optimization is machine/compiler dependent as there are fundamentally half as many divisions. I hope I don't come across as unappreciative, on the contrary the fundamental ideas is to special case base 10 conversions and get a speed boost by leveraging the compiler and the int_decimal_conversion_trunk.patch does this nicely. I do think it would be unfortunately to not go a little further though - just because we can do better with little effort, we can save a few CPU cycles which means saving time, money and all of this can only be good for the planet. ;-) -- Added file: http://bugs.python.org/file14935/int_decimal_conversion_trunk.patch2 ___ Python tracker <http://bugs.python.org/issue6713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6713] Integer & Long types: Performance improvement of 1.6x to 2x for base 10 conversions
Gawain Bolton added the comment: Mark, I haven't tried your latest patch but I tried your patch3 and obtained the same performance improvement for long integers, namely 3.1x faster. This is truly an excellent improvement, my hat's off to you! As for the basic integers, I'm working on another patch which improves performance even more but by all means, go ahead with your improvement for long integers. -- ___ Python tracker <http://bugs.python.org/issue6713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6713] Integer & Long types: Performance improvement of 1.6x to 2x for base 10 conversions
Gawain Bolton added the comment: Yes I agree it would be a good idea to have one definition and one instantiation of the _decimal_digit_table[] and BitLengthTable[32] arrays. Where do you suggest these tables could be put? I'll be happy to provide an updated patch if you can let me know. -- ___ Python tracker <http://bugs.python.org/issue6713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6713] Integer & Long types: Performance improvement of 1.6x to 2x for base 10 conversions
New submission from Gawain Bolton : Converting integer & long types to their ASCII representation is a task which can be quite CPU intensive due to the division & modulo operations. For long integers having hundreds or thousands of digits, this can take a truly significant amount of CPU time. I have written a special case for base 10 conversions which allows for two improvements. 1) Two digits can be converted at a time, thus reducing the number of div/mod operations by two. 2) An optimizing compiler can avoid performing a division operation when the divisor is hardcoded. The expensive division operation can be replaced by a much faster multiplication operation. My tests show an improvement of 1.6x to 1.8x improvement for integer types and 2x improvement for longs. Note that because integers are displayed using fprintf(), the performance improvement is only seen when __repr__() is called. Patch is provided against trunk. It is somewhat difficult to read the patch in one or two places due to the use of tabs. -- components: Interpreter Core files: base10_conversion_performance_patch.txt messages: 91636 nosy: gawain severity: normal status: open title: Integer & Long types: Performance improvement of 1.6x to 2x for base 10 conversions type: performance versions: Python 2.7 Added file: http://bugs.python.org/file14736/base10_conversion_performance_patch.txt ___ Python tracker <http://bugs.python.org/issue6713> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2195] urlparse() does not handle URLs with port numbers properly
Gawain Bolton added the comment: On the contrary, RFC 1738 does mention the port number in section 3.1. Common Internet Scheme Syntax: While the syntax for the rest of the URL may vary depending on the particular scheme selected, URL schemes that involve the direct use of an IP-based protocol to a specified host on the Internet use a common syntax for the scheme-specific data: //:@:/ Some or all of the parts ":@", ":", ":", and "/" may be excluded. The scheme specific data start with a double slash "//" to indicate that it complies with the common Internet scheme syntax. I agree with Christos Georgiou's suggestion that if the a default scheme is passed AND the default scheme is a URL scheme, then the scheme should be identified as being before "://". __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2195> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2195] urlparse() does not handle URLs with port numbers properly
Changes by Gawain Bolton: -- title: urlparse() -> urlparse() does not handle URLs with port numbers properly __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2195> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2195] urlparse()
New submission from Gawain Bolton: The urlparse() function in urlparse module does not handle URLs without an explicit scheme and with port numbers. The following works as expected: >>> urlparse.urlparse('foo.bar.com','http').scheme 'http' But if the URL has a port number then the scheme is wrong: >>> urlparse.urlparse('foo.bar.com:8080','http').scheme 'foo.bar.com' I have read RFC 1808 and its description of the parsing of the scheme also has this bug. From what I can figure, the parsing algorithm needs to search for the scheme before the substring "://" and not just ":". -- components: Library (Lib) messages: 63054 nosy: gawain severity: normal status: open title: urlparse() type: behavior versions: Python 2.5 __ Tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2195> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com