[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 gp.bol...@computer.org 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 rep...@bugs.python.org 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 gp.bol...@computer.org 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 rep...@bugs.python.org 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 gp.bol...@computer.org 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 rep...@bugs.python.org 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 gp.bol...@computer.org: 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 rep...@bugs.python.org 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: //user:password@host:port/url-path Some or all of the parts user:password@, :password, :port, and /url-path 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()
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
[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
