[issue18032] Optimization for set/frozenset.issubset()
Bruno Cauet added the comment:
Here is an updated patch based on Dustin's work with Josh's comments. I also
added a test which takes forever on an unpatched python interpreter.
Since it's a performance issue, I've benchmarked the results. They don't change
for the most part (argument is a set or a dict) but they're way better for
iterables.
For every type of argument I test 1 case where "set.issubset" returns True and
1 case where it returns False.
(a) simple argument (results unchanged)
$ ./python -m timeit -s "s1 = set(range(1000)); s2 = set(range(1000))"
"s1.issubset(s2)"
Unpatched: 1 loops, best of 3: 63.7 usec per loop
Patched: 1 loops, best of 3: 63.5 usec per loop
$ ./python -m timeit -s "s1 = set(range(1000)); s2 = set(range(1, 1000))"
"s1.issubset(s2)"
Unpatched: 100 loops, best of 3: 0.248 usec per loop
Patched: 100 loops, best of 3: 0.25 usec per loop
$ ./python -m timeit -s "s1 = set(range(1000)); s2 =
dict(enumerate(range(1000)))" "s1.issubset(s2)"
Unpatched: 1 loops, best of 3: 107 usec per loop
Patched: 1 loops, best of 3: 108 usec per loop
$ ./python -m timeit -s "s1 = set(range(1000)); s2 = dict(enumerate(range(1,
1000)))" "s1.issubset(s2)"
Unpatched: 1 loops, best of 3: 43.5 usec per loop
Patched: 1 loops, best of 3: 42.6 usec per loop
(b) iterable argument (speed improvement)
1) no improvements/slight degradation when everything must be consumed
$ ./python -m timeit -s "s1 = set(range(1000))" "s1.issubset(range(1000))"
Unpatched: 1000 loops, best of 3: 263 usec per loop
Patched: 1000 loops, best of 3: 263 usec per loop
$ ./python -m timeit -s "s1 = set(range(1000))" "s1.issubset(range(1, 1000))"
Unpatched: 1 loops, best of 3: 201 usec per loop
Patched: 1000 loops, best of 3: 259 usec per loop
$ ./python -m timeit -s "s1 = set(range(100))" "s1.issubset(range(1, 1000))"
Unpatched: 1000 loops, best of 3: 198 usec per loop
Patched: 1000 loops, best of 3: 218 usec per loop
2) tremendous improvements when it can return early
$ ./python -m timeit -s "s1 = set(range(100))" "s1.issubset(range(1000))"
Unpatched: 1000 loops, best of 3: 209 usec per loop
Patched: 10 loops, best of 3: 12.1 usec per loop
$ ./python -m timeit -s "s1 = set('a'); s2 = ['a'] + ['b'] * 1"
"s1.issubset(s2)"
Unpatched: 1000 loops, best of 3: 368 usec per loop
Patched: 100 loops, best of 3: 0.934 usec per loop
$ ./python -m timeit -s "s1 = set('a'); from itertools import repeat"
"s1.issubset(repeat('a'))"
Unpatched: NEVER FINISHES
Patched: 100 loops, best of 3: 1.33 usec per loop
--
nosy: +bru, haypo
Added file:
http://bugs.python.org/file37295/0001-Improve-set.issubset-performance-on-iterables.patch
___
Python tracker
<http://bugs.python.org/issue18032>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1703178] link_objects in setup.cfg crashes build
Bruno Cauet added the comment: There's a small typo in the comments: +# make sure cmd.link_objects is turned into a list +# is it's a string Should be: +# make sure cmd.link_objects is turned into a list +# if it's a string -- nosy: +bru ___ Python tracker <http://bugs.python.org/issue1703178> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23017] string.printable.isprintable() returns False
Bruno Cauet added the comment: Here is a simple fix for the issue, plus a test. It does not break any unit test but this raises a backwards-compatibility problem. Therefore I wouldn't advise using it for Python 3.4 but only 3.5+. -- keywords: +patch nosy: +bru versions: +Python 3.5 Added file: http://bugs.python.org/file37398/0001-Fix-string.printable-respect-POSIX-spec.patch ___ Python tracker <http://bugs.python.org/issue23017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18032] Optimization for set/frozenset.issubset()
Bruno Cauet added the comment: Serhiy, that sounds good but I think that you have forgotten to attach the mentioned patch. -- ___ Python tracker <http://bugs.python.org/issue18032> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23192] Generator return value ignored in lambda function
Bruno Cauet added the comment: Here are the operations being emitted (line, macro used and eventual argument): >>> f = lambda: (yield 5) 3487: ADDOP_O LOAD_CONST e->v.Num.n 3472: ADDOP YIELD_VALUE 1907: ADDOP_IN_SCOPE POP_TOP 4349: ADDOP_O LOAD_CONST Py_None 4350: ADDOP RETURN_VALUE 1457: ADDOP_O LOAD_CONST (PyObject*)co 1458: ADDOP_O LOAD_CONST qualname 1459: ADDOP_I MAKE_FUNCTION args 4349: ADDOP_O LOAD_CONST Py_None 4350: ADDOP RETURN_VALUE >>> def g(): return (yield 5) ... 3487: ADDOP_O LOAD_CONST e->v.Num.n 3472: ADDOP YIELD_VALUE 2533: ADDOP RETURN_VALUE 1457: ADDOP_O LOAD_CONST (PyObject*)co 1458: ADDOP_O LOAD_CONST qualname 1459: ADDOP_I MAKE_FUNCTION args 4349: ADDOP_O LOAD_CONST Py_None 4350: ADDOP RETURN_VALUE So there's an extra POP_TOP + LOAD_CONST Py_NONE for the lambda version that throws away the "123" (in the exemple). The attached patch (0001-...) fixes it. However please note that I'm not knowledgable about that part of the code and devised the patch empirically. Moreover a test should probably added but I did not know where (test_dis? tried and failed... see patch 0002-...). -- keywords: +patch nosy: +bru Added file: http://bugs.python.org/file38298/0001-lambda-generators-don-t-throw-away-stack-top.patch ___ Python tracker <http://bugs.python.org/issue23192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23192] Generator return value ignored in lambda function
Changes by Bruno Cauet : Added file: http://bugs.python.org/file38299/0002-lambda-generator-fix-try-to-add-a-dis-test.patch ___ Python tracker <http://bugs.python.org/issue23192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23192] Generator return value ignored in lambda function
Bruno Cauet added the comment: Here is a working test, testing yield by lambda & function as well as lambda and function yielding from those. -- Added file: http://bugs.python.org/file38440/0001-Add-tests-for-issue-23192.patch ___ Python tracker <http://bugs.python.org/issue23192> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23640] Enum.from_bytes() is broken
Bruno Cauet added the comment:
Hi,
I feel like this behaviour does not only affect IntEnum & related but anything
that inherits from int.
Example:
>>> class foo(int):
... def __init__(self, value, base=10):
... if value == 2:
... raise ValueError("not that!!")
... super(foo, self).__init__(value, base=base)
...
>>> x = foo.from_bytes(b"\2", "big")
>>> x
2
>>> type(x)
foo
2 solutions come to mind:
- always return an int, and not the type. deleting
Objects/longobjects.c:4845,4866 does the job.
- instantiate the required type with the value as the (sole?) argument,
correctly initializing the object to be returned. In Serhyi's example this
results in x == AddressFamily.AF_UNIX. the same lines are concerned.
--
nosy: +bru
___
Python tracker
<http://bugs.python.org/issue23640>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23640] Enum.from_bytes() is broken
Bruno Cauet added the comment: I took the liberty of putting together a small patch which makes from_bytes() call & return type(value_found) if type != long (Serhiy's & my 2nd solution). Ethan: in that case, type.from_bytes() would always return an int, and not resort to build-a-pseudo-int, right? That way not overriding from_bytes() would not result in strange behaviour. -- Added file: http://bugs.python.org/file38447/0001-int.from_bytes-calls-constructor-for-subclasses.patch ___ Python tracker <http://bugs.python.org/issue23640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23640] Enum.from_bytes() is broken
Bruno Cauet added the comment: I'm not sure how you can have both, those two seem opposite to me: - if 'from_bytes' returns the same type as the class it is called on then the instantiation of the result object should go through its constructor (patch proposed) - if the subclass should override base class behaviour then there is no reason for Enum.from_bytes to return the same type as the class it is called on, and therefore it should be made a classmethod. 2015-03-30 18:02 GMT+02:00 Ethan Furman : > > Ethan Furman added the comment: > > 'from_bytes' is a classmethod. As such, it should return the same type as > the class it is called on. If that wasn't the intent it would be a > staticmethod instead. > > It is the responsibility of the subclass to override base class behavior, > not the other way around. > > -- > > ___ > Python tracker > <http://bugs.python.org/issue23640> > ___ > -- ___ Python tracker <http://bugs.python.org/issue23640> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
